去孤岛事件管理：让可靠性工程成为每个人的工作

打破孤岛和建立对可靠性分担责任的文化的 4 种最佳实践。 SRE 可能“拥有”可靠性工程。但是，只有在各种其他利益相关者的帮助下，他们才能成功地担任该角色。如果您不能与开发人员、IT 工程师甚至非技术团队（如公关和法律）轻松协作和沟通，您将难以优化可靠性工程。这就是为什么将组织去孤岛化是管理可靠性的关键部分。这就是为什么打破将 SRE 与其他团队分开的孤岛如此重要的原因，以及这样做的实用策略。乍一看，您可能不会认为组织孤岛（意味着不同团队或业务部门之间存在阻碍沟通和协作的部门）是 SRE 的主要挑战。毕竟，就其本质而言，SRE 角色是一种混合角色，它在开发和 IT 运营之间架起了桥梁，这是传统 IT 组织的两个主要组成部分。 SRE 应该同时具备软件工程和 IT 运营技能，以便在他们管理的系统中建立尽可能高的可靠性。然而，仅仅因为 SRE 技能集与其他学科的技能集重叠并不能自动消除 SRE 团队与其他团队之间的孤岛。这些孤岛有持续存在的趋势，原因如下： 不同的目标：SRE 与其他技术团队的目标不同。现代开发团队的主要目标是持续发布软件，而不是优化可靠性。对于 IT 运维，他们的重点是持续部署软件并在事件发生时有效响应（这与工程软件以最小化事件的方式进行设计不同）。独立的团队结构：SRE 不一定作为开发或 IT 运营团队的一部分进行组织。 SRE 往往独立存在，组织成自己的团队，这意味着他们几乎没有与其他技术团队互动的自然机会。

在可靠性工程的 CI/CD 中没有角色：也许是因为 SRE 做不同的工作并且有不同的优先级，它们不能自然地融入指导其他团队工作的 CI/CD 流程。在 CI/CD 管道的任何阶段，SRE 都不会以某种方式将可靠性插入到代码中。除非 SRE 积极与其他利益相关者合作，将可靠性作为整个 CI/CD 管道的优先事项，否则可靠性很容易陷入自己的孤岛（有点像安全性，这也不是标准 CI/CD 管道的默认部分并且只有在您采用 DevSecOps 方法时才能集成）。不同的成功衡量标准：SRE 根据可用性、MTTR、SLO 等指标衡量成功。这些指标对开发人员和 IT 运营人员也可能有些重要。但它们通常不如其他与开发和运营工作更直接相关的指标重要，例如应用程序发布频率和性能指标。 SRE 和其他技术角色之间的脱节当然很重要，因为它阻碍了整个 IT 组织高效和有效地管理可靠性的能力。当 IT 组织的不同部门专注于不同的追求并在可靠性工程上设置不同的优先级时，您最终会组建团队，他们会为自己的个人利益而努力，而不是优化整个业务的结果。值得注意的是，不仅仅是 IT 组织内的孤岛使优化可靠性工程变得更加困难。 SRE 和非技术业务部门之间的分歧可能同样存在问题。例如，SRE 通常不会与公关和法律团队一起工作或密切合作。但是，当事件发生时，与这些团队的沟通至关重要，尤其是在事件对客户产生重大影响的情况下。法律可以帮助 SRE 确定事件的合同影响是什么，或者优先考虑哪些服务中断，以最大程度地减少 SLA 违规的后果。同样，PR 可以与 SRE 一起制定有关中断和预计恢复时间的声明。但同样，仅仅因为 SRE 应该与这些团队合作并不意味着他们这样做。这些非技术团队通常比开发人员和 IT 工程师更远离 SRE。所以，这就是问题所在。真正的问题是：你如何解决它？

以下是在可靠性工程中加强 SRE 与其他利益相关者之间协作的四种方法。您的事件响应手册可能首先关注团队将遵循的技术程序来恢复服务。但理想情况下，剧本还将涵盖其他操作——例如公关团队的沟通工作和法律团队的合同评估——这些都是确保对事件的整体响应所必需的。当您将这些流程构建到您的剧本中时，您可以更轻松地实现 SRE 与其他利益相关者之间的密切协作。 SRE 经常执行各种测试——比如 FMEA 评估——来评估他们管理的系统的可靠性。但这些测试不必由 SRE 单独负责。来自 IT 组织内外的其他利益相关者可以而且应该在识别可靠性弱点和评估系统内潜在故障的影响方面发挥作用。当您将每个人都包括在可靠性测试中时，您就可以建立更强大的共同责任文化。理想情况下，每次开发人员编写新代码行、IT 工程师修改生产服务器或律师更改客户合同条款时，都应该考虑可靠性。但通常情况并非如此，尤其是在可靠性被视为只有 SRE 必须管理的组织中。

为了改变这一点，要求所有利益相关者在每次做出改变时评估可靠性的后果。当考虑可靠性成为每个人的第二天性时，您最终会拥有更健康的可靠性文化，并且 SRE 与组织其他部分之间的障碍更少。最后，即使您努力让所有利益相关者承担可靠性的责任，请记住，您的文化仍然应该保持无可指责。仅仅因为每个人都参与可靠性工程并不意味着当出现问题时，任何一个团队都需要承担责任。围绕可靠性保持无可指责的文化对于确保利益相关者将可靠性不是强加给他们的负担，而是与其他团队合作并加强集体成功的机会非常重要。 SRE 可能专注于可靠性工程，但最终，企业内的每个利益相关者都在构建和管理可靠系统方面发挥作用。充分利用可靠性工程的关键是获得整个组织的支持，以与 SRE 进行协作和社区，并打破传统上将 SRE 与其他人隔离开来的孤岛。