语言 Chinese, Simplified

SEO Title

可靠性文化如何帮助团队构建更可靠的系统和流程。

当我们考虑可靠性时，我们通常会从系统的角度来考虑可靠性。现实情况是，可靠性始于人。通过鼓励站点可靠性工程师 (SRE)、事件响应人员、应用程序开发人员和其他团队成员主动考虑可靠性，我们可以更好地准备识别和修复故障模式。

在本节中，我们将解释什么是可靠性文化，如何培养和发展可靠性文化，以及它如何帮助提高我们的流程和系统的可靠性。

什么是可靠性文化？

可靠性文化是组织的每个成员都朝着最大化其服务、流程和人员可用性的共同目标而努力的文化。团队成员专注于提高其服务的可用性和性能，降低停机风险，并尽快响应事件以减少停机时间。

传统上，软件工程团队对待可靠性的方式与对待测试的方式相同：作为开发生命周期中的一个不同阶段。这导致可靠性成为质量保证 (QA) 和运营团队的唯一责任。随着系统变得越来越复杂和开发速度加快，可靠性不仅成为测试人员和运营团队之间的共同责任，而且成为构建应用程序的开发人员、领导这些团队的工程经理、解决客户痛点的产品经理，甚至是高管之间的共同责任负责预算和启动公司范围内的计划。所有这些团队都必须在使组织的服务更可靠的目标上保持一致，以便更好地为客户服务，我们将这种组织范围内的关注称为“可靠性文化”。

但是为什么我们需要一个专注于可靠性的整个文化呢？难道我们不能编写更多的自动化测试用例，或者将一个工具插入我们的 CI/CD 管道来为我们测试我们的应用程序吗？一方面，可靠性受到软件开发生命周期 (SDLC) 的所有阶段的影响，从设计一直到部署。在 SDLC 后期修复缺陷和故障模式的成本更高，特别是如果它们最终导致生产事故。

其次，现代应用程序和系统更加复杂，并且具有更多相互关联的部分。虽然传统测试擅长测试单个组件，但它不足以全面测试整个系统。提高可靠性意味着测试和加强这些复杂的相互作用，以防止一个组件的故障导致整个系统瘫痪。

最后，组织倾向于优先考虑其他计划而不是可靠性，例如缩短开发周期和快速发布新功能。这并不是因为可靠性不重要，而是因为它不是许多团队的首要任务。如果没有来自组织的强烈激励，提高可靠性的努力和举措就不太可能保持势头。更快的功能开发甚至可以通过使系统更不可靠来阻碍可靠性工作。

是什么推动了可靠性文化？

可靠性文化最终集中在一个目标上：提供最佳的客户体验。这种对客户的独特关注指导可靠性的所有其他方面，从开发更具弹性的应用程序和系统，到培训 SRE 以更有效地响应事件。当客户满意度和可靠性之间存在明显的相关性时，组织就会更有动力投入所需的时间、精力和预算，以使系统和流程更加可靠。它还将可靠性工作与公司的核心使命直接联系起来，进一步巩固了它作为一项重要实践的地位。

[“为什么我们需要可靠”的答案]只有一个词：信任！信任是我们能提供的最重要的东西。为了使我们的平台可行，我们的客户必须相信我们将可用，为了让我们赢得客户的信任，我们必须可靠。

如何发展和培养可靠性文化

建立可靠性文化所需的时间和精力与组织的规模成正比。即使在个人习惯于快速转向的初创公司中，确保每个人都在同一个目标上保持一致也是一项挑战。在建立可靠性文化时，我们需要考虑我们的目标。

从你的使命宣言开始

提高可靠性的主要目标是保持我们的系统和服务可用。频繁的中断会导致收入损失、客户信任度下降，以及用于响应事件而不是改进我们的产品或服务的工程时间。但是，尽管这是所有组织的一个重要目标，但它并不总是组织文化的一个引人注目的驱动力。那是什么？

这个问题的答案应该与组织的使命宣言密切相关。如果我们没有使命宣言或目标，我们应该从关注客户开始。我们如何提供最佳的客户体验，以及如何将其转化为我们组织的日常工作？

这个问题应该是整个组织的头等大事，尤其是在产品团队、工程团队、客户支持团队和执行团队中。每个团队都应该意识到他们的角色和职责如何为客户体验做出贡献。例如，如果工程师编写的代码优化不佳，这可能会导致性能下降和延迟增加，从而导致客户放弃产品。通过围绕客户构建可靠性，我们可以更轻松地开始思考不同团队如何影响可靠性目标。

为了让团队保持一致，我们应该经常重复我们的使命宣言。在会议、员工入职和规划新计划时突出显示它。如果对我们的可靠性目标或目标产生疑问，我们应该始终将它们与客户联系起来。

识别并响应回击

组织变革通常会遇到一些阻力。您可能会听到以下论点：可靠性测试太复杂，需要花费宝贵的时间进行功能开发，或者您已经忙于事件管理。虽然投资可靠性确实需要前期投资，但它带来的好处大大超过了成本。这些包括：

减少影响客户的事件和中断，从而带来更好的客户体验。
更少的待命事件和紧急页面，减轻工程师的压力。
降低了高严重性错误进入生产的风险，使工程师能够专注于功能开发和其他增值任务。

在开发生命周期的早期提高可靠性

团队通常直到软件开发生命周期 (SDLC) 后期才考虑可靠性。传统上，工程团队将可靠性测试的责任留给了 QA。随着现代应用程序的复杂性和快速发展，这个过程不再是可扩展的或完全有效的。它不仅会为生产设置障碍并减慢发布周期，而且无法找到现代系统中存在的意外且独特的故障模式。

解决方案是向左移动，以便在整个 SDLC 中进行可靠性测试，而不仅仅是在最后。在规划新功能或新服务时，我们早在需求收集阶段就开始规划我们想要提供的客户体验。产品经理在开发开始之前设定对服务质量的期望，SRE 和应用程序开发人员定义指标来衡量和跟踪对这些要求的合规性，然后我们不断测试我们在整个开发过程中满足这些要求的能力。

通过及早优先考虑可靠性，对提高可靠性的关注自然会影响到参与开发过程的每个团队。这使我们能够尽早开始发现和解决缺陷，鼓励良好的开发实践，并降低问题进入生产的风险。这也有经济利益，因为稍后在 SDLC 中修复错误的成本更高。

采用支持可靠性文化的实践

文化是重要的一步，但我们也需要工具来帮助我们将文化付诸实践。在可靠性方面，我们需要一种方法来确保我们的响应团队准备好处理事件，我们的系统对技术故障具有弹性，并且我们对可靠性实践的关注能够为业务带来明确的投资回报 (ROI)。我们这样做的方式是使用混沌工程。

混沌工程是故意将故障注入系统，观察系统如何响应，使用这些观察来提高其可靠性，并验证我们的弹性机制是否有效的实践。虽然“系统”通常指的是技术系统（尤其是分布式系统），但我们也可以使用混沌工程来验证组织系统和流程。这包括事件管理和响应、灾难恢复和故障排除流程。

Chaos Engineering 可帮助团队主动测试可靠性威胁，并在开发过程的早期解决它们，从而降低事件或中断的风险。这包括测试事件响应计划、验证系统是否可以故障转移到冗余或备份系统，以及许多其他场景。

使用 GameDays 和 FireDrills 练习失败

采用可靠性文化的最大挑战之一是保持这种做法。可靠性不是一次就能实现的：它必须定期维护和验证。做到这一点的最佳方法是使用混沌工程定期主动地测试系统和流程。事实上，持续运行混沌实验的团队比从未进行过实验或运行临时实验的团队具有更高的可用性水平。

混沌工程如何帮助建立可靠性文化？答案是帮助团队测试他们对系统的假设，积极寻找提高可靠性的方法，并确保系统能够适应生产条件。这样做的一个常见策略是使用 GameDays，这是故意计划的事件，拥有应用程序或服务的工程师团队（以及其他利益相关者，如团队领导和产品经理）聚在一起对服务进行混沌实验.团队运行实验，观察服务以了解它如何响应，并利用他们的见解来提高服务的弹性。然后，他们将实验自动化，将其添加到他们的实验库中，然后连续运行这些实验以验证他们的系统是否保持弹性。

一个典型的 GameDay 运行时间为 2-4 小时，涉及以下团队成员：

一位领导 GameDay 并决定何时运行或中止实验的成员（“所有者”）。
执行实验的一名成员（“协调员”）。
一名计划实验、定义假设（实验旨在测试什么）并记录结果的成员（“报告者”）。
收集数据（通常来自监控或可观察性工具）并将实验效果与其数据相关联的一名或多名成员（“观察员”）。

为了帮助建立可靠性实践，请定期运行 GameDays。具有高可用性的团队倾向于每周、每月或每季度运行一次实验。一般来说，运行更频繁的 GameDays 可以帮助您更快地实现可靠性目标，因此请考虑安排每周或每两周的 GameDays。
一旦您的团队能够轻松运行计划内的事件，请考虑添加计划外事件。这些被称为 FireDrills。与 GameDay 一样，FireDrill 涉及使用混沌工程来模拟系统上的故障。不同之处在于响应 FireDrill 的团队不知道这是一次演习。这使他们以更现实的方式做出反应，就好像这是一个真实的事件，但保留了在必要时停止和回滚事件的能力。

FireDrills 可以有效地帮助团队：

测量响应时间和平均解决时间 (MTTR)。
确保运行手册是最新的。
练习事件响应程序并建立肌肉记忆。
测试监控仪表板、警报和待命/寻呼系统。

我们建议每周或每两周运行一次 FireDrills，但前提是您的团队已经练习过运行 GameDays。指定能够协调 FireDrill 的领导者，最好是了解被攻击系统的工程团队领导者。这可确保在发生意外情况或需要取消 FireDrill 时始终有人能够快速响应。

从错误中学习

事件会发生，这很好。没有一个系统是完美的。当出现问题时，采取纠正措施并尽快解决根本原因。然后，一旦您的系统正常运行，请对您的响应进行深入调查和评估（称为事后分析）。调查问题的原因、团队为解决问题所采取的步骤、有助于解决问题的指标和其他可观察性数据，以及团队为防止问题再次发生而采取的措施。

失败没关系：混乱即将发生，我们应该寻找失败只是为了学习。那些不舒服的地方是我们学到最多的地方。

事故对工程师来说是一段情绪紧张的时期，尤其是当他们觉得自己是造成事故的人时。进行事后分析时，不要专注于指责。相反，应首先关注使事件发生的过程。这被称为无可指责的事后分析。例如，如果团队成员将不良代码推到生产环境中，那么解决方案可能是更可控的部署管道、更彻底的自动化测试或更严格的同行评审。 “互相指责”只会阻止工程师分享他们的经验和见解，因为他们害怕受到惩罚或报复。

事件是学习和成长的机会。当您解决事件的根本原因时，请使用混沌工程来验证您的修复是否有效。自动化此过程以确保您的系统对故障保持弹性。不仅要在您自己的中断中练习，还要从其他团队和组织经历和记录的事件中练习。

总结一下……

可靠性文化是组织的每个成员都在朝着提高组织可靠性的共同目标而努力的文化。
- 可靠性始于客户。如果没有明确的、以客户为中心的使命宣言，可靠性计划就不太可能成功。
- 构建可靠系统的责任由所有团队共同承担，而不仅仅是工程或 QA。
文化确保可靠性不仅仅是一次性的举措，而是一个持续的过程和组织的一个组成部分。
- GameDay 是留给团队运行一个或多个混沌实验并专注于技术成果的一段时间。
- FireDrill 是一种训练团队的做法，让他们对故意制造的事件做出反应。
通过采用工具来实践可靠性（例如混沌工程工具）并将它们集成到您的日常工作流程中，培养一种可靠性文化。
始终愿意从您和其他人的事件中学习。