运维的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.不断发招聘——哪怕没有名额了。
　　27.做自己最严厉的批评者。不管自己或者自认多聪明，总有可以提高的地方。
　　28.多往外看，拿自身的水平和尽量多的公司的职位需求做对比。
　　29.每年参加一个技术交流大会。如果一年有好几个，那选最好的那一个去就够了。
　　30.买你需要的而不是你想要的。绝不摘下你公司的帽子换上那个写着“对我来说什么最简单最安全”的。
　　31.只做对业务最好的事情，哪怕这件事是让你滚蛋……
　　32.问责制度正规化——记录承诺，事后追究没有完成者。
　　33.不允许重复失败。听起来有些过于苛责了。不过要区分不可挽回的失误和失误的差别。
　　34.无情——因为对手都是无情的。
　　35.工作是你要在完成的时候亲自署名的东西。署名同时也意味着完成任务。
　　36.保持对外的可用联络。
　　37.创业的伙伴——告诉他们你的专长和能力范围。你会得到免费的产品回报，有时候是生活中的。
　　38.容量是一个业务/产品问题。也就是说每个页面、上传或者登录等请求的网络消耗，都必须是可见的，以协助完成正确的业务/产品决策。
　　39.一定要打败预算！运维团队总是预算金额最大的挥霍者。公司的收入目标经常达不到，运维团队应该有很多办法来推迟自己的花费。
　　40.过去的经验不一定适用于现在乃至将来——多尝试没错，而且要有恰当的测试工具来做这件事。
　　41.文档——所有事情都应该好好记录成文档。避免团队的新成员绕着圈的找遍全团队逐一了解工作内容。
　　42.画一张超大尺寸的网络拓扑图，描绘你的数据中心。
　　43.为你的每个产品都画一个逻辑流程图。
　　44.维基——让大家可以很容易的发布“如何修复这个问题”的文档并且容易查找。这是技术作者发挥作用的地方，不过维基可以让哪怕非正式的文档或者增增改改的小段落也更好查看。
　　45.确保团队的每个成员，对，是每一个，都是可以替换的。
　　46.有些人在家里干活比在公司的时候还好，但有些人却不行。
　　47.订单打包签订——把硬件需求打包成大订单后再去咨询最大的折扣合同，记得订单里要包括所有一切，比如备件包，租赁条件等等。
　　48.和供应商保持长期联系，哪怕你换到下一份工作的时候也能联系上他们。
　　49.给运维团队每个人都配上一切他们可以远程操控的东西——掌上电脑， 3G 网卡，24 寸 LCD 屏幕……你为有才华的人付出得到的回报，远超过在远程雇佣的现场工程师。记住，运维工程师都是电力狂人，他们知道并且能充分利用屏幕上每个像素。
　　50.除非 Mac 可以运行 office 2007 和 outlook，否则团队里总需要几个 windows。这事很破坏团队的会议安排，联系人管理和邮件列表等等。
　　51.要有一个简化的采购流程——前提是你要了解自己的预算，并且能够管理好。我们可以从财务报告中得到实际。技术驱动的报告和财务驱动的报告之间通常存在差距。一个好的运维经理可以创建一些模型，将这些差别计入销售总成本中。而理解这些的 CFO 才可以帮助推动业务决策。
　　52.周会一定要持续举行，对上周的事件逐一总结和问责。
　　53.创建一个独立的升级系统，来管理那些对运维产生负面影响的代码开发工程。这个想法的来源是：一个同时涉及运维和开发的问题，在运维或者开发的跟踪系统里大多被湮没无视，最后没人理睬，所以给这些问题单独创建一个跟踪系统反而更加简单清楚。
　　54.产品开发从设计开始的每个阶段都要和运维技术相结合。这样，扩展性，监控和可靠性都融入到产品里。这样同时也可以确保运维负责的硬件采购、监控系统按时到位，运行手册即时更新，最后产品按照预计时间上线运行并且都符合运维标准。
　　55.像一个真正的公司一样运作——萨班斯法案，WebTrust 安全审计认证，SAS 70 审计标准，Visa 组织和银行等等。如果你真的成功了，这些都是你不得不打交道的。早点开始这些准备其实很简单，不需要太多的知识。不过就是开发一个工单/任务跟踪工具，然后好好使用。把变更控制和管理放进同样的系统里，好好使用。其他信息也放进来。系统就可以帮助我们找出像“上周变更了什么”这类信息。
　　56.给冗余留空间。一开始或许很难，但是一个没有真正的扩展性和可靠性的系统，才会真正耽误你获得成功的时间。
　　57.买个 Oracle 标准版(或者微软 SQL Server 标准版)是值得的。如果你可以限制住自己不超过标准版的需求，那就绝对值得买，哪怕你刚刚开始创业。
　　58.Postgres 和 MySQL 的免费不错。如果你不是特别在意事务完整性，MySQL 其实挺好的。
　　59.容量设计应该按照每日峰值再上抛 20% 到 30% 的冗余。除非你是个 vmotion(译注：VMWare 的热迁移技术)达人。
　　60.尽量多读一些贸易杂志。它们通常是免费的，只要你填写一些调查问卷就好了。新闻的价值是巨大的。对了，记得让他们投递到你家里，工作的时候读杂志的机会趋近于零。
　　61.注意安全。开发人员不应该有生产线的权限，而应该去做代码复核。这是和运维之间的职责分离。然后运维中应该有人控制设置其他运维人员权限的权限。创建一个员工手册，警告大家违反安全条例会有很严重的后果。从一开始就要记住从物理的、逻辑的、功能的各个方面来保护客户的数据安全和隐私。万一有客户要和你对簿公堂，你回忆起来发现自己只是靠勇气和勤奋来保护客户数据，这感觉可不怎么好。
　　62.控制好访问入口。首先要保证大家可以正常完成工作；其次要确保你知道他们是从哪里进来的。快去实现双因素身份验证方法吧。
　　63.对于人们访问生产环境必经之路的堡垒机和网关，键盘记录是至关重要的。对于 Windows 可能稍微有点难度，不过有些网关可以提供自动截屏功能。
　　64.确保有多种办法登录生产环境。不要期望公司的 在网络中断的时候还能起作用。直接把 架设在生产环境里。
　　65.使用 LDAP 做认证，哪怕你只有 10 台机器，通过复制 passwd 和 shadow 文件的方式来管理，你也要 LDAP 认证。
　　66.不要低估在 UNIX 环境中一台 Windows Server 2008 设备是多么有用。如果只是因为不懂 Windows，那么去学，而不是贬低它。
　　67.不要用那些无效的无线方案浪费大家的时间。公司里所有人都在移动，沙发上，会议室里，门口，到处都要上网。千万维护好你的无线路由。
　　68.总有些人把额外的精力和时间都投入到工作上——直接通过他们的请假单好了。而另一些人恰恰相反只把注意力放在怎么通过自己的请假单。在个人时间安排上，运维人员总是做出巨大的牺牲，他们随时准备凌晨3点爬起床快速响应排障需求。
　　69.通过集中式的 RDBMS 管理你所有的设备资产。然后复制资产，人员，网络，合同等所有数据到异地。没错，要的是一个在线的实时可用的复制，而不是每天晚上备份到磁带。
　　70.自动使用多进程以确认安全，包括操作系统或者产品的上线，文件的推送，日志的分析等。
　　71.自动化操作必须和运维的 RDBMS 数据相关联。
　　72.设备通常有三种状态——离线，服务中，预备。预备状态就是说正在通过 cfengine、rsync 或者其他你在使用的工具完成配置。服务中就是已经运行着流量了。同时还需要一个状态，这个状态下的设备可以在不提供生产服务的情况下收集或者测试数据。
　　73.尊重日志数据。在设备下线或者重建之前，一定要先导出日志。
　　74.如果业务飞速发展让你没有太多时间来做优化，那就尽力锁定一切——进程还能工作，就不要改变它，直到后来有了绝对必要的理由。总之，锁定默认值，等待成长到必要时再审视。
　　75.你永远无法避免运维工程师在你基础设施最关键的地方犯点啥错——比如在哪台机器上不小心执行 rm -rf / 命令。
　　76.为团队保持好玩和有趣的气氛——如果他们不再享受他们的工作，他们就会找别的事情来消遣。要让团队有主人翁意识，运维不是哪个经理的个人任务。
　　77.提供 99.999% 可用性的真正价值在于让我们有能力保持灵活。这意味着当你需要的时候可以充分利用系统冗余。物理变更、设备迁移、代码修改和回退等等都游刃有余。这个对于公司本身价值巨大，甚至比对客户还大。
　　78.如果你能做到 99.999%，那就给客户一个 100% 的SLA承诺。
　　79.不要湮没软件热更新的能力。应该被湮没的是你自己回滚或者转移到旧版本代码的能力。压根就不应该“处理”这种徒劳的失败转移。当事情变得不如人意的时候，你更应该做的是找个大玩意儿来挡住你的肥屁股。CYA（译注：Cover Your Ass，就是前面说的盖屁股） = 保持敏捷 = 成功的公司。
　　80.记住你为客户构建产品的思路里每一步的原因和目的——不管你部署给最终用户的是什么，把这些放在最先考虑，即你所有（基础设施、流程和人员）的设计都是为了提供最好的服务和产品。
　　81.第一次就要成功。很少有机会让你回去重新开始的。重做是对公司资源的巨大浪费。
　　82.多联系业内的合作伙伴、盟友和类似的企业，看看他们的运维是怎么做的。很可能他们碰到了跟你一样的挑战，而解决的更为巧妙。不要害怕分享自己的经验和处理过程，因为别人也会回馈的。
　　83.招人就要招那些足以让自己担心会被挤掉目前工作的，招那些你欣赏和可以学习的榜样，招那些你愿意和他一起工作的。这感觉甚至超过你招聘一个工作考评为A的员工。
　　84.IT 和运维是完全不同的两个概念。一个不错的运维经理应该可以管理好企业 IT，但是一个传统的 IT 工程师很难有能力处理互联网运维任务。
　　85.当你开始一份新工作或者在每年的起始，都应该去争取预算。这不是说滚着那个滋滋响的轮子往前走(应该是指循规蹈矩照本宣科)，而是要一个基于历史数据做出的优秀的文案。如果你正在评估一份新工作，请确认你完完全全的知道预算以及预算的来源。同时，还应该有的是改善这份预算的权利。