运维团队能从橄榄球教练身上学到什么？

不久前看到一条微博，说的是一个团队去黄山集体旅游，但是为了防止网站出现突发问题，负责运维的同学还要背着沉重的笔记本电脑上山下山。

运维人员确实总是要面对巨大的压力，但是是否有一些方法可以缓解这些压力呢？Quora 的工程师 Edmond Lau 提出了一些解决方法。

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

文章开头，他假设了一个场景：作为一名工程师，在凌晨 3 点收到网站的自动提醒，原来是主数据库出了问题。接下来，他说道：

传呼式职责轮换，就是说工程师轮流承担一线运维职责，应对当周所有与网站相关的警告，这是互联网产品增长阶段要应对的最具压力的经验之一。随时听从召唤，意味着你不论去哪里，都必须让笔记本电脑放在手边，而且随时都可能处理问题，有时处理的是小问题，但有些时候，面对十分严重的问题，而且需要尽快解决。

但他提出一个问题：

即使这种分担职责的方式十分重要，我们能做些什么改善这种情形吗？还有那些必须要在压力和不理想环境下处理完善的情形呢？

接下来，他认为可以从橄榄球教练身上吸取一些经验。

Edmond 引述了旧金山 49 人队前任教练 Bill Walsh 的一个策略“成功剧本”，应用这种策略，Walsh 会针对各种比赛中可能发生的情况，写下应急计划。

在他看来，Walsh 认识到一点：在面对比赛关键时刻时，可能有成千上万球队的粉丝朝你狂吼，对手的球迷也在朝你扔热狗和塑料啤酒杯，宝贵的时间在一分一秒地过去，这时的你很难保持清醒头脑，做出有效决策。Walsh 认为：在面对高度紧张、精神难以集中的比赛时刻，写下剧本有助于去掉制定决策过程。

当时没有其他队伍这么做，这种做法让我们占有了令人惊叹的战术先机。不管境况优劣，写剧本都是最有效的领导工具。这种精明的方式，让我在比赛还没有开始前就已经掌控了比赛。我发现这种方法后，其他球队用了好多年才完全推广开这个理念。

Walsh 最终带领 49 人队获得 3 次超级碗胜利，并两次获得 NFL 年度教练称号。

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

在 Edmond 看来：

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

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

• 2006 年时，我还在 Google 工作。Google 每年都有持续多日的“灾难恢复测试（Diaster Recovery Testing - DiRT）”活动。在 DiRT 演练中，公司会模拟诸如地震、飓风之类的灾难，并验证在断电或者整个数据中心或办公室出现故障中，团队、沟通和关键系统能否保持正常运转。这个演练会发现单点故障、不可靠的故障切换、过时的应急计划、或是其他没有预料到的错误，还能帮助团队在受控环境下处理这些问题，同时没有在真正的紧急时刻面对的恐慌和压力。
• Netflix 构建了 Chaos Monkey 系统，可以随机关闭自己基础设施中的服务。直接宕掉自己系统中的服务，这看起来好像有违常理，但是他们的配置可以在平时的正常工作时间杀掉服务，工程师因此可以在办公室里面直接发现架构上的问题，而不是在半夜被叫起来。他们在博客上这么说：“应对重大未知失败的最佳防守，就是经常失败。”
• Dropbox 的工程团队常常为自己的系统增加额外模拟负载。如果他们发现某些系统达到极限、出现问题，他们就能关闭模拟负载，解决问题。相比面对真实的生产环境再去救火，这样的压力要小得多，毕竟生产环境的流量无法直接关闭。

Edmond 对上述例子做了总结：

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

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

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

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

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

• 那些年我们犯过的错（一）——豆瓣 Xupeng：补齐那丢失的三分钟数据
• 如何恢复丢失的两个月数据——“下厨房”技术团队分析总结 6.26 数据库事故

如果他们事先能够写写剧本，也许就可以避免遇到的严重问题，那个背着笔记本电脑上山的苦逼运维也许就可以放下电脑、放下压力、放下心情，放心轻松了。

如果你是一个运维人员，也欢迎给《那些年我们犯过的错》话题投稿，只要你：

• 回答以下问题：
  • 介绍一下你印象深刻的、你犯过的一个错误。
  • 你是如何发现 / 捕捉到这个错误的？
  • 发生了错误之后，你尝试做了哪些事情？
  • 你是如何从错误的症状跟踪到错误诞生的原因的？
  • 之后，你做了哪些工作防止此类错误再次发生？
• 撰写一段你的个人介绍。
• 发信给 editors@cn.infoq.com ，邮件标题注明《那些年我们犯过的错》投稿，将上述内容粘贴入邮件正文当中。

期待你的来信！