运维的85条规则( 二 )


31.只做对业务最好的事情,哪怕这件事是让你滚蛋……
【运维的85条规则】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 的热迁移技术)达人 。


推荐阅读