运维的运维的85条规则条规则
2007 年,时任虚拟世界游戏公司 Vivaty 运维副总裁的 Jon Prall 在他的个人博客上发表过一篇《运维的85条规
则》。2010 年他跳槽到视频电话公司 Tango 之初,做了两处更新,兹翻译如下
1.容量第一,优化第二——这条规则在故障发生时生效。在宕机的时候别研究什么优化,先恢复设备。
2.保留所有可以捕获的记录——以 PostgresQL 为例,包括有 WAL 文件,Slony 复制,快照技术,基于硬盘的 DB 版本(快照
附带的)
3.不要因为优化引入更多问题。通常我们解决问题时做出来的东西都会转变成之后运维工作的负担。请确认为运维工作开发的
那些工具已经完全交付使用。这些东西经常无法正常运行结果要返回开发组重来。更重要的,这种变更请求通常会打破团队原
本安排好的工作计划。
4.保持简单,不要让事情变得太复杂,聪明的你一定可以做到的。
5.谨慎使用缓存以保护那些难以水平扩展的资源。当然,如果你可以水平扩展它,那么给他加缓存层就不用考虑太多。一旦用
上了缓存层,它的目的应该是提高最终用户的访问性能,而不是增加网站的容量。否则,你不过是给自己加上了一个新的非常
不可靠的瓶颈。他们潜在的负面影响可能危及整个系统。事实上缓存层失效带来的,经常是雪崩式的级联故障。
6.不要什么都自己写代码实现,也不要什么都从厂家买——要在适当的时候采用适当的工具。
7.谈判——和真正有实力的厂家谈判的唯一办法就是提前做好功课,准备好一切可行项。这样一旦有必要,你可以从你的首选
厂家里选择离开。不用搞虚张声势那套了。
8.永远要准备好 N+1 的服务器。如果 N 等于 1,那么不管什么情况都不要动用这个 +1 的设备,专职等待 N 失效后的接管。
当你使用冗余的服务器来均衡负载的时候,就只有49%或者更少的容量可管理了。通常我们会获得 N+2 的机会——一定要好
好利用起来。
9.数据丢失是任何一家公司都不敢冒的风险——这是一条普遍真理。丢失数据造成的损耗远远超过用于保证数据不丢失的花
费。
10.随时随地的并行化——这是一种很重要的思维方式。比如,如果 MogileFS 设置为位置感知的方式并且需要实时复制,那
么每个 MogileFS 服务器都必须可以复制自己的数据到负载均衡器指定的另一端。只要有可能,尽量实现这种多对多的方式。
11.RTFM——就在今天我还要阅读一对 RAID 卡的说明书来比较他们微妙的差异。魔鬼在于细节。像做家庭作业一样读文档
吧!
12.了解每一层上的瓶颈以及如何发现瓶颈。必须要知道你是在磁盘,内存,还是 CPU 上受限制了,搞清楚这个其实挺简单
的。
13.要有一个固定的容量管理流程——而且是主动式的,不是被动式的。要知道系统的弱点在哪里,让实际负荷曲线跑到容量
曲线之上是极度危险的。
14.不促成失败,也不惧怕改变。
15.不要吸进你自己的废气。别以为你现在的工作结果会变成未来你如何工作的动力。
16.运维人员要写的代码是运维工具,而不是应用软件。
17.不要低估运维团队中项目经理、技术作者、金融分析师的价值。这些人通常比你给的工资值钱多了。
18.监控所有的东西——报警只用在异动的时候,其他的都记录下来供趋势分析。
19.要有一个固定的流程来查看每个地方的趋势数据。
20.不要让监控太吵闹,那样很快就变得没作用了。
21.确保你的监控系统简单易用到公司里每个人都能上手。监控数据指标转换成为业务指标、市场指标和销售指标等等的频率
可能高的让你吃惊。
22.只在可以做出相应改变的地方做总结,否则就是白白浪费时间。
23.总结要公开,同时附上事件相关的数据。这样大家可以很容易的找到总结的关键点并且跳转到对应数据。
24.要让技术的每一个点都有人员在负责。
25.同时为这些负责人准备好备份人员。
26.不断发招聘——哪怕没有名额了。