大公司非常努力地确保他们的服务不会中断，原因很简单——严重的中断会损害你的品牌，并促使客户选择具有更好记录的竞争产品。
构建可靠的互联网服务是一个技术难题，但对于公司领导者来说，这也是一项人性挑战。激励您的工程团队投资于可靠性工作可能很困难，因为它通常被认为不如开发新功能那么令人兴奋。
从规模上看，激励机制占主导地位。顶级科技公司雇用数千名员工，运营数百项互联网服务。多年来，他们想出了巧妙的方法来确保工程师构建可靠的系统。本文讨论了历史上最成功的科技公司在规模上行之有效的人体工程学技术。无论您是员工还是领导者，您都可以将这些技术应用于您的公司。
旋转轮子
AWS 运营评审是每周一次的会议，面向全公司开放。每次会议都会旋转“幸运之轮”，从数百个 AWS 服务中随机选择一个进行现场评审。接受评审的团队必须回答经验丰富的运营领导提出的有关其仪表板和指标的尖锐问题。数百名员工、数十名董事和数名副总裁出席了会议。
这激励了每个团队都具备一定的运营能力。即使单个团队被选中的概率很低（在 AWS，不到 1%），作为团队的经理或技术主管，你真的不想在运气用完的那天在公司一半的人面前显得一无所知。
定期检查可靠性指标非常重要。 积极关注运营健康的领导者会为整个组织定下基调。旋转轮盘只是实现这一目标的工具之一。
但是你在这些运营评审中做了什么呢？这就引出了下一个问题。
定义可衡量的可靠性目标
您希望拥有“高正常运行时间”或“五个九”，但这对您的客户来说意味着什么？实时交互（聊天）的延迟容忍度远低于异步工作负载（训练机器学习模型、上传视频）。您的目标应该反映客户关心的内容。
当您审查团队的指标时，请他们描述可衡量的可靠性目标。确保您理解（他们也理解）选择这些目标的原因。然后，让他们使用仪表板来证明这些目标正在实现。拥有可衡量的目标将帮助您以数据驱动的方式优先考虑可靠性工作。
专注于发现问题是一个好主意。如果您在他们的仪表板中发现异常，请他们解释问题，同时询问他们是否已将问题通知他们的值班人员。理想情况下，您应该比客户更早意识到问题所在。
拥抱混乱
云弹性方面最具革命性的思维转变之一是将故障注入生产的概念。Netflix 将这一概念正式定为“混沌工程”——这个想法就像名字所暗示的那样酷。
Netflix 希望激励其工程师构建容错系统，而不是诉诸微观管理。他们认为，如果系统故障成为常态而不是例外，工程师就别无选择，只能构建容错系统。虽然这需要时间，但在 Netflix，从单个服务器到整个可用区，任何东西在生产过程中都会经常发生故障。每项服务都应自动吸收此类故障，而不会影响服务可用性。
这种策略既昂贵又复杂。但是，如果你要交付的产品绝对需要高正常运行时间，那么在生产过程中注入故障是一种非常有效的方法，可以获得类似于“正确性证明”的东西。如果你的产品需要这样做，请尽早引入它。它永远不会比现在更容易或更便宜。
如果混沌工程看起来有点过头了，你至少应该要求你的团队每年进行一到两次“游戏日”（模拟中断练习），或者在任何主要功能发布之前进行。在游戏日期间，你将有三个指定角色——第一个角色模拟中断，第二个角色在事先不知道问题所在的情况下修复中断，第三个角色观察并做详细记录。之后，整个团队应该聚在一起对模拟事件进行事后分析（见下文）。游戏日不仅会揭示你的系统处理中断的方式存在差距，还会揭示你的工程师处理中断的方式存在差距。
拥有严格的事后分析流程
一家公司的事后分析流程可以揭示很多关于其文化的信息。每家顶级科技公司都要求团队针对重大中断撰写事后分析报告。报告应描述事件，探究其根本原因并确定预防措施。事后分析应严格且高标准，但该流程不应单挑个人来承担责任。事后分析报告的撰写是一种纠正行为，而不是惩罚行为。如果工程师犯了错误，那么潜在的问题会导致该错误发生。也许您需要更好的测试，或者在关键系统周围设置更好的护栏。深入研究这些系统漏洞并修复它们。
设计一个强大的事后分析流程可以作为其自己的文章的主题，但可以肯定地说，拥有这样一个流程将在很大程度上防止下一次中断。
奖励可靠性工作
如果工程师认为只有新功能才能带来加薪和晋升，那么可靠性工作就会被搁置一旁。大多数工程师都应该为卓越运营做出贡献，无论资历如何。在绩效评估中奖励可靠性改进。让最资深的工程师对他们所监督的系统的稳定性负责。
虽然这个建议看起来很明显，但却很容易被忽视。
结论
在本文中，我们探讨了一些将可靠性融入公司文化的基本工具。初创公司和早期公司通常不会将可靠性作为优先事项。这是可以理解的——你的初出茅庐的公司必须全神贯注于证明产品与市场的契合度才能确保生存。然而，一旦你有了回头客群，你公司的未来就取决于保持信任。人类通过可靠性赢得信任。互联网服务也是如此。
原创文章，作者：王 浩然，如若转载，请注明出处：https://www.dian8dian.com/ren-wei-yin-su-qi-ye-ru-he-yu-fang-yun-zai-nan
