翻译于 2013/06/14 16:44
运维的 85 条军规 已翻译 100%
加载中
这篇文章原发于
2007年6月，后来我一直都没有更新。然而，这个规则列表至今仍然十分适用。我打算马上对这篇文章进行更新。。。
运维85条军规
1) 承载能力优先 ——随后再进行优化 —— 不遵守这条规则必定带来故障停机时间。不要在故障停机时间的压力下进行优化——要先集中精力提高承载能力。
2) 以Postgres为例，一定要确保你的每一个网络都能匹配得上你的WAL文件、Slony复制、快照技术以及基于磁盘的DB版本化（快照的衍生品）
3) 不要把问题‘优化’到你的架构之中。为了解决问题而新加进来的一些东西往往后来都会变成运维沉重的负担。 要确保在运维工程化中开发出来的工具交接完整。过后再回头进行进一步的开发往往不灵。更重要的是，变更请求可能会破坏已经安排好的工程计划。
运维85条军规
1) 承载能力优先 ——随后再进行优化 —— 不遵守这条规则必定带来故障停机时间。不要在故障停机时间的压力下进行优化——要先集中精力提高承载能力。
2) 以Postgres为例，一定要确保你的每一个网络都能匹配得上你的WAL文件、Slony复制、快照技术以及基于磁盘的DB版本化（快照的衍生品）
3) 不要把问题‘优化’到你的架构之中。为了解决问题而新加进来的一些东西往往后来都会变成运维沉重的负担。 要确保在运维工程化中开发出来的工具交接完整。过后再回头进行进一步的开发往往不灵。更重要的是，变更请求可能会破坏已经安排好的工程计划。
4） 保持简单。保持简单，因为你很聪明 别把事搞的太复杂 因为你行的。
(译者:KISS 原则 Keep It Simple, Stupid)
5）应该非常谨慎地使用
缓存
，为了保护资源一致性，它很难进行水平缩放。
如果你作的是一个可以横向扩展的东西，
明智或审慎的做法是不要添加的缓存层。
如果非要使用，它应该是为最终用户获得性能，
不是为了赢得一个网站的容量;
6） 不要所有代码都自己写; 不要所有东西都外包; 在合适的时间使用合适的工具,完成你的工作.
(译者: 不要重复造轮子)
7)协商-真正有效的谈判唯一方式是先作一些调研,制定一些可行的性方案.这样你可以挑选你的首席开发商,如果你真的需要. 别虚张声势.
翻译于 2013/06/14 20:12
8）一直保持N+1。如果N=1，无论任何情况下不要轻易使用+1，这个1只用于当N down机情况下。当使用冗余服务器来承载负载时候，不要让你的系统超过49%的负荷。当有机会能只用N+2的架构时候，使用它。
9）数据丢失不是任何一个公司所能承担的风险--这是举世所知的真理。数据丢失造成的损失远远大于保持数据不丢失所花的成本。10）无论何时何地尽可能并行化。这是复路考虑最重要的手段。比如，如果利用MogileFS来做位置感知，并且需要实时的复制数据，一个可行的方法是每一台MogileFS服务器可以复制它的数据去MogileFS的负载均衡中心。尽可能多的启用多的平行。
翻译于 2013/06/17 10:22
11）阅读手册。至今，我还是坚持要先通读RAID卡的手册，以确认是否有什么细微的差别。恶魔都隐藏在细节里。做足功课吧！
12）知道瓶颈所在，并知道怎么去定位它，一层层排查，查找是不是硬盘、内存或者cpu的阻塞了。通常这个很简单。
13)定期做系统容量管理程序。积极一点。如果没有容量数据的曲线，你很难知道你系统的薄弱之处。
14）不要促成失败，不要害怕改变。
15）别挖陷阱给自己跳。不要认为你的工作成果将能作为未来的工作的动力。
16 ）运维人员写的代码应该是运维工具，而不是应用软件。
12）知道瓶颈所在，并知道怎么去定位它，一层层排查，查找是不是硬盘、内存或者cpu的阻塞了。通常这个很简单。
13)定期做系统容量管理程序。积极一点。如果没有容量数据的曲线，你很难知道你系统的薄弱之处。
14）不要促成失败，不要害怕改变。
15）别挖陷阱给自己跳。不要认为你的工作成果将能作为未来的工作的动力。
16 ）运维人员写的代码应该是运维工具，而不是应用软件。
翻译于 2013/06/20 15:16
17）在运维团队中，不要低估了项目管理、文档撰写以及财务分析人员的价值。他们比给予工资更有价值。
18）监控一切。报警异常问题。其他部分记录数据用来做趋势分析信息。
19）定期的流程查看各个地方的趋势数据。
20）不要把监控弄的很乱，不然他就没有啥意义了。
21）要确保监控系统简单到让公司的每个人都能上手。你可能会很吃惊监控数据指标转换成为业务指标、市场指标和销售等等指标有多频繁。
22 ） 只在可以做出相应改善的地方做检查。 否则就不要浪费时间了。
18）监控一切。报警异常问题。其他部分记录数据用来做趋势分析信息。
19）定期的流程查看各个地方的趋势数据。
20）不要把监控弄的很乱，不然他就没有啥意义了。
21）要确保监控系统简单到让公司的每个人都能上手。你可能会很吃惊监控数据指标转换成为业务指标、市场指标和销售等等指标有多频繁。
22 ） 只在可以做出相应改善的地方做检查。 否则就不要浪费时间了。
翻译于 2013/06/20 15:38
23）公开你的检查报告，并附上相关数据，以便他人可以容易的阅读到关键点，并能关联到响应的数据。
24）在每一个技术点都分配人手。
25）要给重要人员配备后备人手。
26）要不断的招聘。甚至是当你没有名额，也要一直招聘。
27）要严于律己。无论你有多聪明或者你认为你多NB，你也要不断的提高自己。
28 ）要尽可能多的把自己和其他公司做比较。眼光要往外看。
24）在每一个技术点都分配人手。
25）要给重要人员配备后备人手。
26）要不断的招聘。甚至是当你没有名额，也要一直招聘。
27）要严于律己。无论你有多聪明或者你认为你多NB，你也要不断的提高自己。
28 ）要尽可能多的把自己和其他公司做比较。眼光要往外看。
翻译于 2013/06/20 15:53
29) 挑选一个展会或回忆，只有一个，一年一次，去参加。如果展会一年举办多次，之参加一次。
30) 购买你需要的，而非你想要的。永远都不要摘掉企业这顶帽子带上“什么对我是最简单最安全的”这顶帽子。
31)永远只做最生意有益的事情，即使这意味着你需要离开。
32)正式问责机制——记录承诺，标记它们，揭示为兑现的承诺。
33) 你不应失败两次以上。恐惧感有点好处。但要知道长期犯错和无意犯错的区别。
34无情一些——你的对手如此。
35)视工作为在你完成时需要签上你的名字。这也意味着完成你的工作。
36)变得对别人有用。
37)与初创公司合作——提供你的专业技术和规模，你将获得免费的产品作为回报，有时甚或一生。
30) 购买你需要的，而非你想要的。永远都不要摘掉企业这顶帽子带上“什么对我是最简单最安全的”这顶帽子。
31)永远只做最生意有益的事情，即使这意味着你需要离开。
32)正式问责机制——记录承诺，标记它们，揭示为兑现的承诺。
33) 你不应失败两次以上。恐惧感有点好处。但要知道长期犯错和无意犯错的区别。
34无情一些——你的对手如此。
35)视工作为在你完成时需要签上你的名字。这也意味着完成你的工作。
36)变得对别人有用。
37)与初创公司合作——提供你的专业技术和规模，你将获得免费的产品作为回报，有时甚或一生。
翻译于 2013/06/14 13:11
38）容量是一个业务/产品问题。这意外着每个页面、每个请求、每次登录的网络成本等等在做正确的业务/产品决策时候都必须是都透明
39)一直打破预算。运维团队通常是最大的花费者。通常没有收入没有达到预算，但是运维团队可以有很多方法来延期采购。
40）过去能正常的做的事，不见得现在或者未来都会正常。所以做的时候，先用工具测试一下。
41）文档化。把所有东西都写成文档。要让新人挨个去问怎么做事。
42）用一张大尺寸的图绘制你数据中心的网络拓扑。
43 ）用一张图描绘出你每一个产品的业务流程图。
39)一直打破预算。运维团队通常是最大的花费者。通常没有收入没有达到预算，但是运维团队可以有很多方法来延期采购。
40）过去能正常的做的事，不见得现在或者未来都会正常。所以做的时候，先用工具测试一下。
41）文档化。把所有东西都写成文档。要让新人挨个去问怎么做事。
42）用一张大尺寸的图绘制你数据中心的网络拓扑。
43 ）用一张图描绘出你每一个产品的业务流程图。
翻译于 2013/06/20 16:22
44) Faq-O-Matic, Wiki, 在这里人们可以很容易的发布“这是如何修复这个”的文章，并让它容易被找到的地方。这里是技术编写者能派上用场的地方，但是，最重要的是使文档更容易，即使是非正式的。
45) 确保所有人，任何人都可以被替换。
46)多数人在家里做的比在办公室里更多，有些人则不然。
47)捆绑下单——你可以要求更多折扣，更好的条款等等。当你成批购进硬件时。你可以要求一切——最低价格，备件包，租赁期限，只要他们还没有得到订单。
48)同你的供货商保持长期关系——确保你在下份工作时依然能够联系他们。
45) 确保所有人，任何人都可以被替换。
46)多数人在家里做的比在办公室里更多，有些人则不然。
47)捆绑下单——你可以要求更多折扣，更好的条款等等。当你成批购进硬件时。你可以要求一切——最低价格，备件包，租赁期限，只要他们还没有得到订单。
48)同你的供货商保持长期关系——确保你在下份工作时依然能够联系他们。
翻译于 2013/06/14 11:55
49）给运维团队的每一个人配置可以用来远程工作的超级装备：掌上电脑、无线上网卡、24英寸液晶显示器等等。雇佣大拿得到回报要远大于远程雇佣的本地人员。记住运维工程师都是用电达人，能充分的利用屏幕上的每一个像素点。
50)完全陷入IT标准的泥潭。直到Mac运行office 2007和outlook，你必须运行windows。间断的。除非全用mac本，否则这会破坏会议日程表、联系人或者邮件列表的办公效率。如果有个员工愿意工作的在 xp环境。这是非常少。这条法则，现在是陈旧的/未公认的，陷入泥潭不一定是最好的方法。这个列表非常的07化。
51 ）有个合理的采购流程。知道你的预算，确信能管好它。从财务得到实际的金额。在技术驱动的预算/报告和财务驱动的预算/报告直接往往有一定的差距。作为一个搞的运维管理者要能形成模型把这些差距计入销售总成本中。一个理解这些事情的CFO有助于推动业务决策。
翻译于 2013/06/20 17:05
加载中
删除一条评论
评论删除后，数据将无法恢复
深圳市奥思网络科技有限公司版权所有
粤ICP备12009483号
评论(24)
引用来自“linuxess”的评论
41条翻译有误，应该是：不要让新人挨个去问怎么做事。
引用来自“LimSteven”的评论
咦,各大网站现在都开始转载oschina的翻译文章了啊...
引用来自“奇葩100”的评论
引用来自“上海志彦科技有限公司”的评论
对于运营来说，不可多得，运用在各个方面
引用来自“上海志彦科技有限公司”的评论
对于运营来说，不可多得，运用在各个方面