大型企业非常努力地确保其服务的持续运行，原因很简单——重大的服务中断会损害品牌形象，并将客户转向具有更好记录的竞争产品。建立可靠的互联网服务是一个技术难题，但对于企业领导者来说，这也是一个人力挑战。激励工程团队投入可靠性工作的动力可能很困难，因为这往往被认为不如开发新功能来得令人兴奋。
在大规模运营中，激励措施至关重要。顶尖科技公司雇佣数千名员工，并运营数百项互联网服务。多年来，他们想出了聪明的方法，以确保工程师们构建可靠的系统。本文讨论了在历史上最成功的科技公司中行之有效的人力工程技术。这些方法可以应用于您的公司，无论您是员工还是领导者。
转动幸运轮
AWS的运营评审是每周的会议，向全公司开放。每次会议上，都会转动一个“幸运轮”，随机选择一个AWS服务进行现场评审。被评审的团队必须回答来自经验丰富的运营领导者关于其仪表板和指标的尖锐问题。会议吸引了数百名员工、数十名董事和几位副总裁参与。
这激励每个团队达到基本的运营能力水平。即使个别团队被选中的概率较低（在AWS中不到1%），作为团队的经理或技术负责人，您也不想在运气用尽的那天在公司一半员工面前显得无知。
定期审核您的可靠性指标是重要的。积极关注运营健康的领导者会为整个组织树立这样的基调。转动幸运轮只是实现这一目标的一个工具。
定义可衡量的可靠性目标
您可能希望实现“高可用性”或“99.999%”，但这对您的客户真正意味着什么？实时交互（如聊天）的延迟容忍度远低于异步工作负载（如训练机器学习模型、上传视频）。您的目标应反映客户所关心的内容。
在审核团队的指标时，要求他们描述可衡量的可靠性目标。确保您理解——他们也理解——为何选择这些目标。然后，让他们使用仪表板证明这些目标正在实现。拥有可衡量的目标将帮助您以数据驱动的方式优先考虑可靠性工作。
关注问题的检测是个好主意。如果您在他们的仪表板上看到异常，请要求他们解释问题，同时询问他们的值班人员是否已被通知。理想情况下，您应该在客户意识到问题之前就发现异常。
拥抱混乱
云服务韧性中最具革命性的思维转变之一就是在生产环境中引入故障的概念。Netflix将这一概念正式化为“混沌工程”，而这个理念正如其名称一样酷炫。
Netflix希望激励工程师构建容错系统，而不依赖于微观管理。他们推理认为，如果系统性故障成为常态而非例外，工程师就别无选择，只能构建容错系统。虽然这个过程需要时间，但在Netflix，个别服务器到整个可用区域都会在生产环境中定期“下线”。每项服务都被期望能够自动吸收这些故障，而不影响服务的可用性。
这种策略成本高昂且复杂。但如果您推出的产品绝对需要高可用性，那么在生产环境中引入故障是获得类似“正确性证明”的有效方法。如果您的产品需要这个，尽早引入它。此时引入它将是最简单和最便宜的。
如果混沌工程看起来过于极端，您至少应该要求团队每年进行一次或两次“游戏日”（模拟故障演练），或者在任何重大功能发布前进行。在游戏日中，您将有三个指定角色——第一个角色模拟故障，第二个角色在不知道故障原因的情况下修复它，第三个角色观察并做详细记录。之后，整个团队应聚在一起，进行模拟事件的事后分析。游戏日将揭示您系统处理故障的不足，以及工程师处理故障的不足。
建立严格的事后分析流程
公司的事后分析流程揭示了其文化的许多方面。每家顶尖科技公司都要求团队为重大故障撰写事后分析报告。报告应描述事件、探讨其根本原因并识别预防措施。事后分析应严谨，并达到高标准，但过程决不能单独指责个人。事后分析的撰写是一项纠正性练习，而非惩罚性练习。如果一位工程师犯了错误，必然存在导致该错误发生的潜在问题。也许您需要更好的测试，或在关键系统周围建立更好的保护措施。深入挖掘这些系统性缺陷并加以修复。
设计一个稳健的事后分析流程本身可以成为一篇独立的文章，但可以肯定的是，拥有这样一个流程将大大有助于防止下一次故障的发生。
奖励可靠性工作
如果工程师们认为只有新功能才能获得升职和加薪，可靠性工作将被搁置。大多数工程师无论资历如何，都应为运营卓越做出贡献。在绩效评估中奖励可靠性改进。对您最资深的工程师负责，确保他们所负责系统的稳定性。
虽然这一建议看似显而易见，但实际上却容易被忽视。
结论
在本文中，我们探讨了一些将可靠性嵌入公司文化的基本工具。初创公司和早期阶段的公司通常不会优先考虑可靠性。这可以理解——您的新兴公司必须高度关注产品市场契合度，以确保生存。然而，一旦您拥有了稳定的客户群，公司的未来就依赖于保持信任。人们通过可靠性来赢得信任，互联网服务也是如此。
