运维团队能从橄榄球教练身上学到什么(节选)

Edmond 是Quora的元老级工程师，他曾带领工程团队应对用户的高速增长，开发核心组件，并为新入职的工程师提供指导和入职说明，同时协调工程实习计划。此前，他曾服务于Ooyala的视频分析团队和Google的搜索质量团队。不久前，他在自己的博客上发布了一篇文章《成功剧本——关于工程，我们从橄榄球教练身上能学到什么》。

Edmond 认为：我们可以采纳Walsh的写剧本策略，将决策制定过程从高压或是高风险情形转移到更受控的环境中。以此，就可减少感情蒙蔽我们的判断，或是时间重压 在我们头上之类的状况。作为工程师，我们甚至可以编写程序剧本，模拟我们的响应，还要测试，以保证剧本足够健壮。

在Edmond看来：

这在大型工程组织中尤为重要，因为任何可能出问题的基础设施都会出问题。

接下来，Edmond列举了一些大型技术公司的例子，说明他们如何在正常时期模拟系统失败和灾难，以应对非常情况：

·        2006 年时，我还在Google工作。Google每年都有持续多日的“灾难恢复测试（Diaster RecoveryTesting - DiRT）”活动。在DiRT演练中，公司会模拟诸如地震、飓风之类的灾难，并验证在断电或者整个数据中心或办公室出现故障中，团队、沟通和关键系统能否 保持正常运转。这个演练会发现单点故障、不可靠的故障切换、过时的应急计划、或是其他没有预料到的错误，还能帮助团队在受控环境下处理这些问题，同时没有 在真正的紧急时刻面对的恐慌和压力。

·        Netflix 构建了Chaos Monkey系统，可以随机关闭自己基础设施中的服务。直接宕掉自己系统中的服务，这看起来好像有违常理，但是他们的配置可以在平时的正常工作时间杀掉服 务，工程师因此可以在办公室里面直接发现架构上的问题，而不是在半夜被叫起来。他们在博客上这么说：“应对重大未知失败的最佳防守，就是经常失败。”

·        Dropbox的工程团队常常为自己的系统增加额外模拟负载。如果他们发现某些系统达到极限、出现问题，他们就能关闭模拟负载，解决问题。相比面对真实的生产环境再去救火，这样的压力要小得多，毕竟生产环境的流量无法直接关闭。

Edmond对上述例子做了总结：

工程组织会假设不可预期和不希望的事情总会发生，他们的策略是：在正常时期，最好先针对这些情况做规划、写剧本，而不是等到事情不可控制时再去处理。

即使与基础设施不相干，在我们的职业生涯中，也会遇到其他高风险、高压力的事情，比如面试、工资协商等等，没那么频繁，但是充满压力，而且影响深远。针对这些情形，写剧本、做准备，是事半功倍之事。

在文末，Edmond列出了一些参考文章，包括： * Google的Kripa Krishan在ACM期刊上发表的《经受不可预期的考验》↩ * Netflix的John Ciancutti在Netflix技术团队博客上发表的《我们使用AWS得到的5个教训》 * Netflix的Cory Bennett和Ariel Tseitlin在Netflix技术团队博客上发表的《放到野外的ChaosMonkey》 * Dropbox的Rajiv Eranki发表的《在Dropbox学到的扩展经验，第一部分》。↩

Edmond Lau还在撰写一本《高效工程师手册》，感兴趣的同学可以去这里下载样章。

InfoQ中文站此前发布过两篇新闻，介绍了豆瓣和下厨房遇到的真实问题：

·        那些年我们犯过的错（一）——豆瓣Xupeng：补齐那丢失的三分钟数据

·        如何恢复丢失的两个月数据——“下厨房”技术团队分析总结6.26数据库事故