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.买你需要的而不是你想要的 。绝不摘下你公司的帽子换上那个写着“对我来说什么最简单最安全”的 。
推荐阅读
- 孙权追谥孙策,孙权对周瑜后代
- 嘉庆只认庆妃,嘉庆皇帝的后妃
- 赵匡胤的结义三兄弟是谁,赵匡胤和赵光义是亲兄弟吗
- 郦道元是北魏晚期的吗,北史郦道元
- 香港服务器的带宽贵在哪里？
- Linux和Windows的区别是什么？
- 莳萝和茴香的区别视频,莳萝在烹调中的作用及用法
- 最贵的祁门红茶多少钱斤,祁门红茶的特点
- 桔子寄生有什么功效,桔子有什么营养
- 粤恒湘沙棘茶功效,完美沙棘茶的功效与作用