大公司非常努力地确保他们的服务不出故障，原因很简单，重大宕机会损害品牌，并将客户推向具有更好稳定性记录的竞争产品。

构建可靠的互联网服务是一个复杂的技术问题，但对公司领导者来说，这也是一个人力挑战。激励工程团队投入于可靠性工作的难度在于，这类工作往往被认为没有开发新功能那么吸引人。

在大规模运营中，激励机制占主导地位。顶级科技公司雇佣了成千上万的员工，并运营数百个互联网服务。多年来，他们想出了巧妙的方法，确保工程师构建可靠的系统。本文讨论了那些历史上最成功的科技公司在大规模环境中采用的人力管理技术，无论你是员工还是领导者，都可以将这些技术应用于你的公司。

转动命运之轮

AWS的运营评审是每周一次的会议，面向整个公司开放。每次会议都会转动“幸运轮”，随机选择数百个AWS服务中的一个进行实时审查。被抽中的团队必须回答有经验的运营领导提出的关于仪表盘和指标的尖锐问题。会议有数百名员工、数十位总监和几位副总裁参加。

这激励了每个团队具备基本的运营能力。即使某个团队被选中的概率很低(在AWS，低于1%)，但作为团队的经理或技术负责人，你肯定不希望在半个公司面前显得一无所知，尤其是在你“运气不佳”的那一天。

定期审查可靠性指标非常重要。对运营健康状况感兴趣的领导者会为整个企业树立这样的基调。“转动命运之轮”只是实现这一目标的工具之一。

但是，在这些运营评审中你应该做些什么呢?这就引出了下一个关键点。

设定可量化的可靠性目标

你可能希望有“高正常运行时间”或“五个九”(99.999%的可用性)，但这些对你的客户意味着什么呢?实时互动(如聊天)的延迟容忍度远低于异步工作负载(如训练机器学习模型、上传视频)。你的目标应反映客户关心的内容。

在审查团队的指标时，让他们描述可量化的可靠性目标。确保你理解他们为何选择这些目标，也让他们清楚这一点，然后，让他们使用仪表盘证明这些目标已实现。设定可量化的目标有助于你以数据驱动的方式优先考虑可靠性工作。

关注问题的检测非常重要。如果你在他们的仪表盘上看到异常，询问他们问题的原因，同时问他们的值班人员是否接到了通知。理想情况下，你应该在客户发现问题之前就察觉到问题的存在。

拥抱混乱

云计算弹性领域最具革命性的思维转变之一是将故障注入到生产环境中。Netflix将这一概念正式化为“混沌工程”——这个概念和它的名字一样酷。

Netflix希望激励其工程师构建容错系统，而不是通过微观管理来实现。他们认为，如果将系统性故障常态化而不是视为例外，工程师将不得不构建容错系统。虽然花了一些时间实现这一点，但在Netflix，生产环境中从单个服务器到整个可用区都会被常规性地“淘汰”。每个服务都被期望能够自动吸收这些故障，而不影响服务可用性。

这种策略既昂贵又复杂，但如果你发布的产品需要高正常运行时间是绝对必要的，那么在生产环境中注入故障是获得类似“正确性证明”的一种非常有效的方法。如果你的产品需要这样做，尽早引入这一策略。未来不会比现在更简单或更便宜。

如果混沌工程看起来有些过于激进，至少应要求团队每年进行一到两次“演习日”(模拟宕机演练)，或者在推出任何重大功能前进行。在演习日中，会有三种指定角色——第一个角色模拟宕机，第二个角色在事先不知晓问题的情况下修复它，第三个角色观察并做详细记录。事后，整个团队应该聚在一起对模拟事件进行复盘(参见下文)。演习日不仅会揭示系统在处理宕机时的不足，还会暴露出工程师应对这些问题的差距。

制定严格的复盘流程

一个公司的复盘流程能反映出其文化。顶级科技公司都要求团队对重大宕机撰写复盘报告。报告应描述事件、探究根本原因，并提出预防措施。复盘应严格执行并保持高标准，但这一过程不应指责个人。复盘撰写是一种纠正行为，而不是惩罚行为。如果某个工程师犯了错误，意味着存在允许这一错误发生的潜在问题。或许你需要更好的测试流程，或是更完善的关键系统保护措施。深入挖掘这些系统性漏洞并加以修复。

设计一个健全的复盘流程可以单独写成一篇文章，但可以肯定的是，拥有一个这样的流程将大大减少下次宕机的发生。

奖励可靠性工作

如果工程师认为只有开发新功能才能带来加薪和晋升，那么可靠性工作将会被搁置。大多数工程师，无论资历如何，都应为运营卓越做出贡献。在绩效评估中奖励可靠性改进工作。让资深工程师为他们所监督系统的稳定性负责。

虽然这个建议看似显而易见，但却很容易被忽视。

结论

本文探讨了一些将可靠性融入公司文化的基本工具。初创公司和早期阶段的公司通常不会优先考虑可靠性。这可以理解——你们的公司必须专注于验证产品与市场的匹配，以确保生存，然而，一旦你拥有了回头客，你公司的未来将依赖于保持信任。人类通过可靠性赢得信任，互联网服务也是如此。