系统运维秘诀.docx

系统运维秘诀：变化，监控，扩展
Dormand。的运维秘诀分成以下三大篇：
技术篇交流篇
实践篇
技术篇
为变化而设计
♦Google的秘诀是正确的一一“为变化而设计"。“变化"就是不得不部署新的软件， 升级现有的软件，进行扩展域的运维一起工作
♦每个领域的运维都有他们自己的专长。网络，数据库，OS。不要忘记彼此多交流！
♦ 一味地墨守陈规是消极的，令人厌烦的。让你的运维们重复的做相同的工作可以很快 的增加他们的流失率。要尊重系统运维们在网络运维们的背后观察学得给人们尝试，学习和成长的机会。
♦注意别给你最优秀的运维安排了太多的活儿。你想要用的运维是那种有能力给自己找 出空闲时间的人。
♦浑水摸鱼者（编者注：原文为bad eggs,直译为坏蛋）。对待他们要足够强硬。大 多数人在帮助之卜是可以完成任务的，但是他们必须要学会独立。
实践篇
现在就修复它，而不是以后再修复它
♦如果-个Web服务器处于脱机状态，不要担心，因为你应该有10个备用的！
♦在-•周中，专门挑出一天来"清理门户"。更换掉所有存在故障的硬件。在欢度周末 之前，确保一切都是完好无损的。
♦如果令人讨厌的小问题突然发生了，在早上要做的第一件事情就是永久性的修复它 们。日志塞满磁盘的情况在上周发生了两次？明天再说吧！如果总是这样，这些问题会堆积 起来……
♦如果你的构建过程是自动化的，充分利用这个优势来修复一些你可以马上修复的问 题，或许也可以批量进行修复。
让每一件事情都自动化
♦人们无法（轻易地）搞乱脚本化的任务。
♦从第二次开始自动化。如果第一次你必须手工来做一件事情，那么把你做的事情写入 一个脚本。
♦带注释的脚本是绝佳的文档。与其把如何安装•些东西的方法详细地写到长达20页 文档中，还不如编写一个可以自解释的脚本。
♦脚本可以被放到自动化的构建过程中。如果要更接近这个目标，应该把•些经常做的 事情都应该变成“零时间”的任务。
只进行必要的变更
♦只做小规模的，独立的变更。
♦如果不是必须改变，那么就保持原样。
♦这也意味着你必须搞清楚什么时候才应该进行变更。找出什么东西是必须要进行变更 的，然后对它进行升级，把它拿出来，让它标准化。
Design for change
♦这里的Design for change （编辑注：技术•的第一条也是Design for change）针 对个人的成长。朝快速解决问题大师的方向努力吧。
♦如果快速解决问题比较困难，那么你可以学习一些基础知识，做出一张清晰的升级路 线图。虽然你的新邮件系统也许并不是你梦想中的、带有强大反垃圾邮件功能的巨大系统; 但是架设两台配置干净的
postfix邮件服务器会比你想象中的效果还要好。
♦大家都倾向于把未完成的项FI放在那里置之不理。这是你要避免的。
尽快地把更新的内容投入实践
♦一般来说，运维工作就是要让代码更好地运行。并行化，建立起回滚重启机制。
♦运行内容包括软件更新，安全补丁，配置变更。
♦使用puppet,其些豆些以及你需要的任何工具对配置进行控制。让它干净，简洁， 并且容易操作。
♦文件数量越少越好。如果只是为了推出一个新的数据库就要在20个文件中分别添加 一行，那么你的方法一定是错误的。创建简单的模板，不要重复编辑需要手工编辑的数据。
规范化，坚持按照规范来行事
♦0S的规范，htlpd的规范，数据库的规范，打包系统的规范。
♦坚持按照这些规范来行事。对一些方法进行调整和改进，让它变得更有意义。
♦永远不要紧抓着主版本不放。如果你的产品功能还没有永久性地冻结，你就必须要按 照规范继续向前推进，把过去的一些事情都抛在脑后。
♦按照规范来做的事情越多，你的工具可以发挥作用的场合就会越多。用于支持其他运 维领域的软件包越多，可以适应的场景也越多。
文档化
♦把流程文档化
♦把产品文档化
♦ Deep Trees 和 Shallow Trees
♦不要让文档出现冗余。如果一个脚本的帮助文档很长，可以进行引用。好的文档是一 个持续改进的过程，它要一直保持准确。
♦把文档和代码，perldoc, pydoc等联系起来。
♦过期的文档是有害的。留出一些时间来更新它们。当新的员工遇到问题的时候，和新 的员工坐下来一起更新文档。
♦适当地使用问题跟踪系统（issue tracking）。为操作历史保留文档是十分重要的， 以避免为了某个
DNS故障的重现去骚扰他人。
使用源代码控制工具
♦使用git或者mercurialo避免使用SVN。
♦把配置文件、脚本等各种东西都放到源代码控制工具中管理起来。
♦为代码迁出提供各种入口。
♦保持迁出的严谨性，精准性和可控制性