【51CTO精选译文】编者按：本文是SixApart的MySQL DBA，Dormando在2008年总结的一套运维秘诀。编者前日看到Google系统管理员Tom Limoncelli在Everything Sysadmin上推荐这篇文章，并表示这篇文章的内容在今天仍然适用。阅读之下，发现的确是篇难得的好文章，有大量的经验分享，总结的十分全面。现在51CTO系统频道特将本文全文翻译过来，当作给各位运维读者们的2011新年礼物。以下为正文。
在运维管理的过程中，我发现了很多有价值的秘诀，本文是这些秘诀的一个总结。虽然这些秘诀可能比较“唯心”，但是我还是把它们总结出来了，相信它们会对你有帮助的。
Dormando的运维秘诀分成以下三大篇：
实践篇
现在就修复它，而不是以后再修复它
◆如果一个Web服务器处于脱机状态，不要担心，因为你应该有10个备用的！
◆在一周中，专门挑出一天来“清理门户”。更换掉所有存在故障的硬件。在欢度周末之前，确保一切都是完好无损的。
◆如果令人讨厌的小问题突然发生了，在早上要做的***件事情就是***性的修复它们。日志塞满磁盘的情况在上周发生了两次？明天再说吧！如果总是这样，这些问题会堆积起来……
◆如果你的构建过程是自动化的，充分利用这个优势来修复一些你可以马上修复的问题，或许也可以批量进行修复。
让每一件事情都自动化
◆人们无法（轻易地）搞乱脚本化的任务。
◆从第二次开始自动化。如果***次你必须手工来做一件事情，那么把你做的事情写入一个脚本。
◆带注释的脚本是***的文档。与其把如何安装一些东西的方法详细地写到长达20页文档中，还不如编写一个可以自解释的脚本。
◆脚本可以被放到自动化的构建过程中。如果要更接近这个目标，应该把一些经常做的事情都应该变成“零时间”的任务。
只进行必要的变更
◆只做小规模的，独立的变更。
◆如果不是必须改变，那么就保持原样。
◆这也意味着你必须搞清楚什么时候才应该进行变更。找出什么东西是必须要进行变更的，然后对它进行升级，把它拿出来，让它标准化。
Design for change
◆这里的Design for change（编辑注：技术篇的***条也是Design for change）针对个人的成长。朝快速解决问题大师的方向努力吧。
◆如果快速解决问题比较困难，那么你可以学习一些基础知识，做出一张清晰的升级路线图。虽然你的新邮件系统也许并不是你梦想中的、带有强大反垃圾邮件功能的巨大系统；但是架设两台配置干净的postfix邮件服务器会比你想象中的效果还要好。
◆大家都倾向于把未完成的项目放在那里置之不理。这是你要避免的。
尽快地把更新的内容投入实践
◆一般来说，运维工作就是要让代码更好地运行。并行化，建立起回滚重启机制。
◆运行内容包括软件更新，安全补丁，配置变更。
◆使用puppet，cfengine以及你需要的任何工具对配置进行控制。让它干净，简洁，并且容易操作。
◆文件数量越少越好。如果只是为了推出一个新的数据库就要在20个文件中分别添加一行，那么你的方法一定是错误的。创建简单的模板，不要重复编辑需要手工编辑的数据。
规范化，坚持按照规范来行事
◆OS的规范，httpd的规范，数据库的规范，打包系统的规范。
◆坚持按照这些规范来行事。对一些方法进行调整和改进，让它变得更有意义。
◆永远不要紧抓着主版本不放。如果你的产品功能还没有***性地冻结，你就必须要按照规范继续向前推进，把过去的一些事情都抛在脑后。
◆按照规范来做的事情越多，你的工具可以发挥作用的场合就会越多。用于支持其他运维领域的软件包越多，可以适应的场景也越多。
文档化
◆把流程文档化
◆把产品文档化
◆不要让文档出现冗余。如果一个脚本的帮助文档很长，可以进行引用。好的文档是一个持续改进的过程，它要一直保持准确。
◆把文档和代码，perldoc，pydoc等联系起来。
◆过期的文档是有害的。留出一些时间来更新它们。当新的员工遇到问题的时候，和新的员工坐下来一起更新文档。
◆适当地使用问题跟踪系统（issue tracking）。为操作历史保留文档是十分重要的，以避免为了某个DNS故障的重现去骚扰他人。
使用源代码控制工具
◆使用git或者mercurial。避免使用SVN。
◆把配置文件、脚本等各种东西都放到源代码控制工具中管理起来。
◆为代码迁出提供各种入口。
◆保持迁出的严谨性，精准性和可控制性。禁止提交无法进行审核的变更。应该提交的变更应该是不用源代码控制工具也能容易地进行测试的（在虚拟机环境下，可以直接在一个单独的测试机器上进行测试）。
招聘
◆区分出固执的人和精明的人
◆不要避免聘请“老前辈”。某个领域的“老前辈”可能已经跟不上技术变革的脚步，以至于你可能不想聘请他们。但是，总是要有几个“超级巨星”来压住阵脚的。
◆不要避免聘请新手。我认识的很多人都是从一个真正的新手开始的（包括我自己！实际上，我认为我自己一直是一个新手）。经过这个阶段以后，他们会迅速地成长起来。现在正是确立职业生涯的时候。我相信我们中的绝大多数人都是这样的。当然，不包括那些不学习的人，没有积极性的人，或者入错行的人。
避免提供商锁入，同时和你的提供商保持良好的关系
◆购买专有硬件的主要劣势是提供商锁入，你不得不总是使用这个提供商的产品。这可能是一个特殊的SAN，NAS，也可能是特殊用途的随设备存储，备份系统等等（51CTO推荐阅读：别把鸡蛋放在一个篮子里）。尽量避免发生这种事情。如果你完全按照上面的设计建议来行事，那么应该可以很快地在不同的平台上搭建起测试环境。然后，你可以进行硬件评估，自由地进行选择。
◆如果所有东西都很深奥，都很不明朗，都还没有经过文档化，并且直接依赖于专有的负载均衡器……那么***别用，因为用了你就不自由。
◆对你最终选择的提供商好一点。如果你每一次采购都在价格方面把他们逼到墙角，那么你只能得到一些垃圾硬件了。
◆有时候数据中心有很多潜在的可用资源。尽量把一些免费的远程协助服务写到合同里，比如就更换硬盘驱动器，提供商的出货/RMA条款，以及一些基础硬件的安装等方面的细则进行谈判。我有一个机架的设备，其安装上架的过程我们的人完全没有操心……真的很不错。
给开源一个机会
◆nginx，mongrel，lighttpd，apache，perlbal，mogilefs，memcached，squid，OpenBGPD，PF，IPTables，LVS，MySQL，Postgres，等等。在你选择可信、可靠、昂贵的专有安装程序以前，给开源一个机会。你会发现使用开源软件意味着可以自己添加插件，扩展，代码修复补丁，或者你可以把一些自己无法实现的功能外包出去。在我看来，开源软件是很可靠的，它们通常比巨大负载之下的大型的，昂贵的硬件更可靠。
◆“一分钱一分货”这种思想是一个彻底的谎言。如果你无法让开源软件为你工作，需要协助，你可以找一个提供商。如果你的团队既睿智又积极主动，这些小伙子们想要搞清楚他们的基础设施是如何工作的，那么你一定无法抵挡来自于GPL或BSD系统的诱惑。
◆MySQL和Postgres都不错。如果你要使用它们，可以权衡一下利弊。没有什么东西会在晚上从你的衣橱里爬出来“吃”掉你的数据。与经过测试的、稳定的冗余master<->slave MySQL集群实例相比，其实庞大的、处于脱机状态的Oracle实例更容易把事情搞的一团糟。
◆关于LAMP架构的文章数不胜数。无数知名网站、ISP、甚至企业现在都在使用开源软件。给开源一个机会。最糟糕的结果也不过是浪费一些时间，而***从你那些心惊胆战的提供商们那里获得一些不错的报价。
【51CTO.com译稿，转载请注明原文作译者和出处。】
原文：http://dormando.livejournal.com/484577.html
【编辑推荐】
