摘自《程序员》2008.8
声明：本文所有权属于《程序员》杂志，如本转摘有任何产权方面的问题，请及时联系本人，谢谢！
=============================================
大规模服务设计部署经验谈(下)
文／J a m e s H a m_lto n译／赖翥翔
运营和功能计划
要高效地运营服务，关键在于让构建的系统有效地消除运营团队的绝
大部分管理交互。这样做的目标，是让一个高度可靠的24 x 7小时运行的
服务，由一个8 x 5小时工作的运营团队就足以维护起来。
不过世事难料，一组或者多组系统救火不成，无法恢复上线的事情是
时有发生的。在熟知这些可能性的情况下，实现把损坏的系统标为当机这
个过程的自动化。依赖运营团队手动更新SQL表或者使用特别的技术移
动数据，都会招致灾难。与故障交战正酣时，往往错误也容易迭出。先预
估运营团队需要采取的补救措施，然后预先编写和测试这些过程。一般来
说，开发团队必须将紧急恢复措施自动化，而且他们必须对之进行测试。
显然，百密一疏，并非所有故障都能预估到，但通常一小组恢复措施就可
以用来恢复多种类型的故障。从根本上说，要构建并测试可以根据灾难的
范围和性质以不同方式使用及结合的“恢复内核”。
恢复脚本应当在生产环境中进行测试。这里有一条普适规则，即如果
没经过频繁测试，什么程序都无法正常工作，因此不要实现团队没勇气使
用的任何东西。如果在生活环境中测试风险过高，那么脚本就没有达到能
在紧急情况下使用的标准，或者说在紧急情况下不安全。这里很关键的一
点是，灾难总是可能发生的，由无法按预期结果运行的恢复步骤所导致的
小问题酿成大灾难的例子是屡见不鲜的。要预见到这样的事件，设计出自
动化措施，让服务回复正常状态，而不至于丢失更多数据或损耗更多正常
运行时间。
◆让开发团队承担责任。Amazon也许是沿着这条道路贯彻得最坚定最矢
志不渝的公司了——他们的口号是“你创建就该你管”。这样的立场也许要比
我们会选择的更坚定一些，但这显然是一个正确的大方向。如果不得不频繁在
深更半夜给开发团队打电话，那么你就得做出一套自动化方案。如果需要频繁
给运营团队打电话，那么通常的反应就是要增加运营团队的人手。