部队式运维之运维军规.doc

部队式运维之运维军规
部队式运维之运维军规
1) 承载能力优先 ——随后再进行优化 —— 不遵守这条规则必定带来故障停机时间。不要在故障停机时间的压力下进行优化——要先集中精力提高承载能力。
2) 以Postgres为例，一定要确保你的每一个网络都能匹配得上你的WAL文件、Slony复制、快照技术以及基于磁盘的DB版本化（快照的衍生品）
3) 不要把问题‘优化’到你的架构之中。为了解决问题而新加进来的一些东西往往后来都会变成运维沉重的负担。 要确保在运维工程化中开发出来的工具交接完整。过后再回头进行进一步的开发往往不灵。更重要的是，变更请求可能会破坏已经安排好的工程计划。
4） 保持简单。保持简单，因为你很聪明 别把事搞的太复杂 因为你行的。
(译者:KISS 原则 Keep It Simple, Stupid)
5）应该非常谨慎地使用缓存，为了保护资源一致性，它很难进行水平缩放。
如果你作的是一个可以横向扩展的东西， 明智或审慎的做法是不要添加的缓存层。 如果非要使用，它应该是为最终用户获得性能， 不是为了赢得一个网站的容量;
6） 不要所有代码都自己写; 不要所有东西都外包; 在合适的时间使用合适的工具,完成你的工作.
(译者: 不要重复造轮子)
7)协商-真正有效的谈判唯一方式是先作一些调研,,如果你真的需要. 别虚张声势.
8）一直保持N+1。如果N=1，无论任何情况下不要轻易使用+1，这个1只用于当N down机情况下。当使用冗余服务器来承载负载时候，不要让
13)定期做系统容量管理程序。积极一点。如果没有容量数据的曲线，你很难知道你系统的薄弱之处。
14）不要促成失败，不要害怕改变。
15）别挖陷阱给自己跳。不要认为你的工作成果将能作为未来的工作的动力。
16 ）运维人员写的代码应该是运维工具，而不是应用软件。
17）在运维团队中，不要低估了项目管理、文档撰写以及财务分析人员的价值。他们比给予工资更有价值。
18）监控一切。报警异常问题。其他部分记录数据用来做趋势分析信息。
19）定期的流程查看各个地方的趋势数据。
20）不要把监控弄的很乱，不然他就没有啥意义了。
21）要确保监控系统简单到让公司的每个人都能上手。你可能会很吃惊监控数据指标转换成为业务指标、市场指标和销售等等指标有多频繁。
22 ） 只在可以做出相应改善的地方做检查。 否则就不要浪费时间了。
23）公开你的检查报告，并附上相关数据，以便他人可以容易的阅读到关键点，并能关联到响应的数据。
24）在每一个技术点都分配人手。
25）要给重要人员配备后备人手。
26）要不断的招聘。甚至是当你没有名额，也要一直招聘。
27）要严于律己。无论你有多聪明或者你认为你多NB
，你也要不断的提高自己。
28 ）要尽可能多的把自己和其他公司做比较。眼光要往外看。
29) 挑选一个展会或回忆，只有一个，一年一次，去参加。如果展会一年举办多次，之参加一次。
30) 购买你需要的，而非你想要的。永远都不要摘掉企业这顶帽子带上“什么对我是最简单最安全的”这顶帽子。
31)永远只做最生意有益的事情，即使这意味着你需要离开。
32)正式问责机制——记录承诺，标记它们，揭示为兑现的承诺。
33) 你不应失败两次以上。恐惧感有点好处。但要知道长期犯错和无意犯错的区别。
34无情一些——你的对手如此。
35)视工作为在你完成时需要签上你的名字。这也意味着完成你的工作。
36)变得对别人有用。
37)与初创公司合作——提供你的专业技术和规模，你将获得免费的产品作为回报，有时甚或一生。
38）容量是一个业务/产品问题。这意外着每个页面、每个请求、每次登录的网络成本等等在做正确的业务/产品决策时候都必须是都透明
39)一直打破预算。运维团队通常是最大的花费者。通常没有收入没有达到预算，但是运维团队可以有很多方法来延期采购。
40）过去能正常的做的事，不见得现在或者未来都会正常。所以做的时候，先用工具测试一下。
41）文档化。把所有东西都写成文档。要让新人挨个去问怎么做事。
42）用一张大尺寸的图绘制你数据中心的网络拓扑。
43 ）用一张图描绘出你每一个产品的业务流程图。
44) Faq-O-Matic, Wiki, 在这里人们可以很容易的发布“这是如何修复这个”的文章，并让它容易被找到的地方。这里是技术编写