系统运维秘诀：变化，监控，扩展（技术篇）(1)

编者按：本文是SixApart的MySQL DBA，Dormando在2008年总结的一套运维秘诀。编者前日看到Google系统管理员Tom Limoncelli在Everything Sysadmin上推荐这篇文章，并表示这篇文章的内容在今天仍然适用。阅读之下，发现的确是篇难得的好文章，有大量的经验分享总结。现在51CTO系统频道特将本文全文翻译过来，当作给各位运维读者们的2011新年礼物。

51CTO推荐专题：系统运维秘诀

完全理解本文内容需要一定的运维经验。您可能对这些文章也会感兴趣：

1. 系统管理员必须了解的六大铁律
2. 系统管理员都应该知道的系统常识
3. 漫谈运维：半神半仙亦民工

以下为正文。

在运维管理的过程中，我发现了很多有价值的秘诀，本文是这些秘诀的一个总结。虽然这些秘诀可能比较“唯心”，但是我还是把它们总结出来了，相信它们会对你有帮助的。

Dormando的运维秘诀分成以下三大篇：

1. 技术篇
2. 交流篇
3. 实践篇

下面先从技术篇开始。交流篇和实践篇会陆续整理放出。

技术篇

为变化而设计

◆Google的秘诀是正确的——“为变化而设计”。“变化”就是不得不部署新的软件，升级现有的软件，进行扩展，设备损坏，以及人员流动等。

◆每一件事情都是在寻找平衡点。你也许会认为把你的系统和某个操作系统或某个Linux发行版牢牢地绑定在一起是一个好主意，但事实上这跟把它们完全隔离一样糟。如果实在有必要，你可以进行分层，并使用一点间接性。

◆这并不意味着你的系统必须是平台无关的。其实我们的目的很简单：一变二，二变二十，一个系统必须可以应对各种突发事件。也就是说，如果一个系统管理员被公共汽车撞了，你有应对的方案！如果挂载的硬盘出现故障了，你有应对的方案！如果某些人运行了rm -rf /，你也有应对的方案！增量的进行变更。记得安全更新，以及保持内容更新。

使用自动的，可重复的构建过程

◆不要手动构建任何东西。如果你一定需要手动构建，那么就做两遍，在做第二遍的时候把用到所有的命令都提取出来。

◆下面这一点十分重要：将新硬件上线到生产环境的过程不应该超过15分钟，而且这个过程必须足够简单。否则，当一个服务器出现故障，而没有人知道如何更换它的时候，你就该倒霉了。

◆下面这一条是普世真理：这个世界上不存在“一次性”的服务器构建。即使你的服务器只需要构建一次，但只要你构建过一次，就一定会有第二次。比如，当它损坏的时候，或者你必须进行一次重大的升级才能让它在在接下来的两年时间里更加稳定的时候。

◆测试，检查新构建好的服务器。这应该是比较容易的，因为你的构建过程都是自动化的，对吧！

◆脚本化的构建，意味着从某个Linux发行版的V3升级到V4应该是很快的。安装
V4，对脚本进行测试。如果有问题，参考文档并修复它，直到它可以再次正常工作。这最多应该是一个星期的工作，而不是一个长达一年的浩大工程（因为那时，刚刚完成的V5已经发布了！）

使用冗余

◆容易重新构建，并不意味着你可以忽视冗余。跳转盒，邮件服务器，计费网关，等等。如果其中的一半挂掉了却并不造成客户的宕机，生活将会变得更加简单。

◆按照以上方针来做的话，当某个设备在凌晨3点出现故障的时候，你可以“以后再处理那个出现故障的设备！”，把冗余的机器先替换上去。

◆下面这一条是个聊胜于无的解决方案：Rsync。DRBD也许也不是一个完美的解决方案，但是它可以提供令人称奇的服务。（参考阅读：DRBD笔记，DRBD实例1，DRBD实例2）

使用备份

◆备份是个严肃的话题。使用硬盘，烧录磁带。压缩它们，移动它们，并行地运行。对每一样东西进行备份！

◆如果你的构建过程是自动的，整个过程都可以被备份。如果到目前为止的几条你都做到了，那么一个真正的“灾难恢复”计划也许并不是那么遥不可及的。

服务器租用/服务器托管中国五强！虚拟主机域名注册顶级提供商！15年品质保障！--亿恩科技[ENKJ.COM]