通过卓越生产实现复杂系统中的可持续运营

本文要点

• 对于团队来说，想要持久地服务客户不仅需要不断改进工具，更需要文化和流程的变革。

• 我们可以设定一些服务级别目标，通过它们衡量客户体验，并在严重影响客户的事故发生时获得警报。这样一来就能减少来自客户的抱怨。

• 团队可以在收集数据、追踪事件、整理资料的过程中调试并理解他们的复杂系统。

• 要允许团队自由、集体地讨论风险，才能提升工作效率。

• 团队可以通过定量风险分析来确定修复工作的优先级，从而更顺畅地提供服务。

[网站可靠性工程（SRE）]和开发团队需要直面问题，找出需要排除的隐患。SRE的一部分工作是在不断变化的业务需求背景下帮助维持卓越的生产力。——Sheerin等，网站可靠性手册

生产所有权意味着开发组件或服务的团队需要随时待命，这是确保软件质量和缩短开发反馈流程的最佳实践。如果能用好所有权这种方法，它可以为工程师带来动力和自主性，满足我们掌控全局、做出优秀成果的渴望，并为用户提供更好的体验。

但在实践中，团队经常没有经过适当的培训，也没有足够的福利保障，却仍然需要随叫随到。没有准备就突然增加团队的责任负担会降低服务的可靠性，使团队士气低落，并促使成员互相推卸责任。团队成员还往往缺乏关键技能来处理新的难题，难以跟上局势变化，也没时间去学习并补足自身的缺陷。一个问题在于，团队的责任加重了，得到的权力却没有跟上。虽然人们本能地会想到花钱解决问题，但购买更多工具并不能填补我们团队的能力或结构的空白。工具只能帮助我们自动化现有工作流程，却不能教我们学习新技能或调整流程来解决现有问题。

为了掌握生产所有权方法的主动权，团队需要发展运行生产系统所需的技能，并为此制定一套路线规划。我们需要的不仅是生产所有权，我们还需要卓越的生产力。卓越生产是一套需要学习的技能组合，团队学会这套技能后就能自信地适应不断变化的环境。它带来的不仅仅是工具的变化，更是成员、文化和流程的变革。

图片来源：Emily Griffin（@emilywithcurls），下同

运维工作事不关己是不行的

有些开发团队会把他们的运维工作外包出去，没有采用生产所有权方法，结果与运维越来越走不到一条线上。这些团队只追求更快开发出新的功能，也不管运维是不是接受。运维工作需要的人力干预越来越多，团队人手愈加紧缺。而负责运维的团队本来应该保持系统运行并扩展系统能力，可现在却要分出精力、深夜加班、拖着疲倦的身躯去收拾各种残局。如果一项服务需要耗尽运维它的所有人员的精力，那么它肯定不能长时间正常运作。

如果开发和运维团队中间隔着一道高墙，那么两边都会丧失宏观层面的必要视角。产品上线前需要手动测试，配置需要人工调整，故障需要手动排查，而且多个团队之间的摩擦让复杂的故障需要更长时间才能解决。团队最终要么应付大量手动、繁琐、容易出错的操作，要么发展出错误的自动化流程，反而加剧了风险——例如，出现生产故障后他们只是简单地重新启动，而不检查为什么它会停下来。这种不断重复的故障/修复循环，或者说苦力活，会随着服务的规模扩大而带来更大的负担，白白浪费团队的血汗与泪水。对于使用专用 SRE 团队的组织以及更传统的使用系统管理员团队的组织来说，运维团队很容易就会疲于奔命。

随着时间的推移，运维挑战也将拖累产品开发工作，因为开发和运维之间的知识与工具互不相通，意味着各个团队难以理解并修复生产中的故障，甚至不知道哪些故障优先级更高。生产所有权方法是很有意义的：它能消除反馈循环，让开发团队感受到自己的决策给运维带来的痛苦，并在团队中引入运维技能，而不是对运维工作不管不问。

仅仅让所有人随时待命是不行的

只让开发团队随叫随到还不够，需要提前做一些准备工作才能让他们发挥作用。几十年前开始，IT 企业将开发和运维的工作切割开来，希望通过专业化来提高效率。现代化的流程又想将这两种功能强行合并在一起来提升敏捷度，但这个目标可不是一夜就能实现的。现在，组合而来的 DevOps 团队需要做的运维任务所需的技能和直觉，通常与开发团队的习惯截然不同。团队可能会面对大量的警报和人工干预工作，让人更感到运维工作没什么价值可言。想要减少警报数量、减少人工干预需要融汇运用开发和运维技能，因此许多开发人员拒绝在团队中引入生产所有权方法。

市场上有许多工具声称自己能降低 DevOps 或生产所有权的负面影响，结果只是把水搅得更浑浊，给系统带来了更多噪音而已。必须有一个系统方案来教育所有参与生产的团队成员，否则所有不常见的问题最后都得推给团队中少数几位专家来解决。就算这些专家更希望分享信息而非垄断信息，他们的工作也总会被打断，当然也没时间写出完整的文档。如果持续集成和交付指标只关注软件的发布速率，忽视软件的质量，那么它就是一个陷阱。

如果团队无法理解系统在生产环境下为何失败，那么检测和修复故障事件的耗时将会很漫长。为了提升团队部署软件时的信心，团队必须确保软件部署到生产环境时不会崩溃。否则，在https://cloudplatformonline.com/rs/248-TPC-286/images/DORA-State of DevOps.pdf">更改失败率较高的环境中，团队辛苦工作的成果会在高负载情况下反复回滚，难以升级。虽说把运维工作的压力分担到团队所有成员身上会更加公平，但真正要减轻运维负担只能设法减少突发故障、打破故障/修复的恶性循环。

专业的系统工程自有其价值，需要花时间学习，以前这项技能常常被轻视了。产品开发人员需要有一套很好的框架来制定流程或修复错误，以尽可能减少噪声。就算团队有时间处理苦力活和其他形式的运维债，也需要提前做好规划。可以把苦力活比作是技术债务在运维侧支付的利息；只还利息并不会减少未偿还的本金。相比没有权力的运维团队来说，生产所有权是更好的战略，但生产中痛苦的程度还是一样的。混合团队肯定会更公平地分担生产中痛苦的压力，但更好的方案是减轻痛苦的程度。当我们偿还技术和运维债务时，客户和开发团队都会受益。

更好的方法：卓越生产

所谓卓越生产，不是试图通过工具或强制团队合并来解决生产所有权问题，而是一种以人为本的全新方法。

卓越生产是一套技能和实践，能使团队对生产的所有权充满信心。卓越生产技能往往出自 SRE 团队或负责 SRE 职务的个体，但这并不是专属于他们的领域。消除生产所有权的反馈循环意味着我们要将这些技能传授给我们团队中的所有成员。在生产所有权体系下，运维是所有人共同的责任，而不是“别人的问题”。每位团队成员都需要在运维和卓越生产领域具备基本认识，即使这不是他们的主要工作。当团队成员培养这些技能时需要得到支持和奖励。

为了让团队及其支撑的服务长期正常运作，有四大关键因素需要考虑。首先，团队必须就哪些事件能提高用户满意度的问题达成一致，并忽略其他无关问题引发的警报。其次，他们必须提高他们探索生产健康度的能力，要从用户出现痛苦的迹象开始探索，而非从潜在成因入手。第三，他们必须确保彼此合作并分享知识，进而还能培训新的成员。最后，他们需要一个框架来确定哪些风险需要补救，以保证系统足够可靠，持续满足客户需求。

1. 衡量重要的事情

想要减轻运维工作的压力，首先要从减少噪音和加强警报与真实的用户问题之间的相关性入手。服务级别目标（SLO）是 SRE 实践的基石，它能用来创建一个反馈循环，以保障系统正常运行，持续满足用户的期望。SLO 的核心思想是将失败看作是正常的事情，我们需要定义一个可接受的失败级别，不要为了追求完美而浪费开发的灵活性。正如 Charity Majors 所说，“你的系统一直处于一种部分不足的状态。现在，有很多很多东西做错了甚至坏掉了，而且你还不知道。” 我们不用让每个系统中所有出现小故障的噪声都发出警报，而是要在宏观层面上应对影响用户满意度的故障模式。

因此，我们需要通过用户每次与我们的系统交互时获得的体验质量来量化每位用户的期望。然后我们要从总体上衡量所有用户的满意度。我们可以测量延迟和错误率，记录放弃率等因素，并通过用户访谈等直接反馈来着手制定这种服务水平指标（SLI）。

理想情况下，我们的产品经理和客户成就团队能得知用户最关心哪些工作流程，还有大致上多大的延迟或错误率阈值会让客户呼叫支持热线。将这些指标转换为机器可识别的阈值后（例如，“如果交互在 300 毫秒内完成，搭配 HTTP 200 代码，结果就很好”或“如果数据在过去 24 小时内更新过，则此数据记录就够新” ），就可以分析整个系统的实时和历史性能。例如，我们可以为我们的系统设定一个目标，即每三个月内符合条件的活动有 99.9％是成功的：意味着每段时期内每 1000 个事件有 1 个错误预算。

设置好性能目标并在一段时期内为预期错误建立预算后，就能调整系统，使其忽略小的可以自我解决的波动，并只在系统显著超过标记边界时发送警报了。只有在实时错误率上升到将在接下来的几个小时内让错误超出预算时，系统才会寻求人工干预。我们可以尝试调整我们的工程优先级，看看是否能获得更大的容忍度和更快的响应速度，或者当我们超出了可接受的故障水平时可以重新回来关注可靠性指标。如果团队长期超出错误预算，用户抱怨不停，那么团队可能需要优先考虑修复基础架构，而不是开发新功能。

团队需要有一套成文共识，在 SLO 出现问题时共同解决问题，这样就为可靠性工作提供了系统层面的支持。一个合理平衡的 SLO 应该让用户在遇到罕见错误时从容淡定，稍后重试就能继续工作，而不是让用户面对持续断线的服务不得不打给支持服务，乃至取消已有的交易。

随着用户期望的变化，以及速度和可靠性之间的平衡出现新的选择，SLO 可能会发生变化。但以用户为本的 SLO 无论多么粗糙，都比陷在一大堆跟用户没什么关系的指标里要强得多。

3. 可观察的调试工作

消除了较低级别的警报后，如果系统发现我们的服务不符合 SLO 指标该怎么办？我们需要调试并深入了解流量中的哪些子集正在经历或导致问题。发现问题后我们要制定解决方案，然后付诸实践并验证一切是否恢复正常。

调试的能力与可观察性这个概念密切相关；可观察性指的是我们的系统要有足够的遥测能力，使我们能够在不干扰系统或修改其代码的前提下监测其内部状态。在充分了解我们的系统及其性能的前提下，我们希望通过假设检验来解释并解决用户遭遇问题的结果差异。现在需要 500 毫秒的请求改进到 250 毫秒后会有什么效果？我们能否识别和解决拖慢一部分请求的性能问题来改善体验？

仅仅测量和收集所有数据是不够的。我们必须以新的方式检查数据及其上下文，并用它来诊断问题。我们需要可观察性，因为我们不能只根据事先想到的指标来测量系统。复杂系统故障通常来源于众多因素的新组合，而非一系列不变的成因。正因如此，我们经常无法在较小规模的临时环境中重现生产故障，无法提前预测故障。

不管我们采用何种可观察性方法，都一定要搞清楚请求流经我们分布式系统的具体路径。请求遍历微服务的每处足迹都是我们必须监控的潜在故障点。可以采用带有元数据的宽事件、分布式跟踪、指标或日志的方法。每种方法都在工具支持、数据粒度、灵活性和上下文方面做了某种取舍。我们经常需要多组可以很好地协同工作的工具，以获得所需的全套功能。如果我们无法将线索锁定到用户流程失败的特定实例上，最熟练的问题专家也将一筹莫展。

如果遥测系统具备足够的灵活性和保真度，我们就不需要为了分析服务的行为而让它一直断线。我们可以尽快恢复对用户的服务，相信我们以后可以重现问题并调试。这样我们就能自动化快速处理一大类故障，例如断开损坏的区域或回退错误的更新，并在正常工作期间调查出错的位置。当人们不需要完全调试并实时解决所有故障时，系统的运维能力就会随之提升。

4. 协作和建设技能

就算有一套完善的 SLO 和观测工具，也不一定能形成可持续的系统。调试和运行系统都需要人力参与。没有人天生就知道如何调试，所以工程师都或多或少要学习相关知识。随着系统和技术不断发展，所有人都需要不断学习新的见解。

重点在于制定培训计划、编写关于常见诊断出发点的最新文档，并经常回顾之前的工作，但回顾时不能把之前的错误归咎于某个人头上。服务所有权并不等于自私和孤岛，它意味着逐渐在团队间分享专业知识。最重要的是，团队必须营造一种心理上感到安全的氛围，使团队成员和外部人员可以直截了当指出问题。这使个体能够更深刻地理解问题，并通过新的视角来解决问题。

跨团队互动不仅局限于上下游关系，还涉及诸如如客户支持、产品开发和 SRE 等部门。如果客户支持工程师一报出虚警就被人指责，他们就不太敢上报问题了，进而影响问题的检测和解决。

在学习过程中有一点是非常需要重视的，那就是每个人都在生产环境中有自己擅长和负责的部分。然而，许多生产所有权的方法都是毫无弹性的教条主义，让所有开发人员 7x24 候命。开发人员不愿参与压力过大且打乱自己生活节奏的流程。可他们又害怕如果不参与这些流程的话，就会被指责推卸责任甚至丢了工作，结果团队就只能被赶鸭子上架，团队精神荡然无存。

生产所有权需要由所有类型的工程师共同分担，少数几种特定类型的工程师是不够的。参与生产不见得就是简单粗暴地随时待命，而可以有许多不同的形式：例如让难以随时待命的成员负责后勤支持，或者让晚上需要照顾家人的成员仅在工作时间待命。还有可能是让一位虔诚的犹太人不用在安息日候命，或者在一位经理跑业务时不去打扰他。团队可以共同协作，根据各个成员的背景和需求公平分担生产所有权的压力。

5. 风险分析

卓越生产的最后一个要素是预测和解决给我们系统的性能带来风险的结构性问题。我们可以在危机发生之前识别潜在故障的性能瓶颈和类别。积极主动的策略就是在发现潜在故障点后知道怎样用软依赖替换硬依赖以避免故障。同样，我们应该主动优化关键路径，不应该等到用户抱怨系统太慢时才动手。我们仍然需要一部分错误预算来处理新的系统故障，但同时必须努力解决系统中的已知风险。

诀窍在于确定哪些风险是最关键的，然后就解决它们。在 20 世纪 60 年代，美国阿波罗登月计划整理了已知风险清单，并努力确保这些风险积累起来仍然处于计划的安全参数范围内。在现代，Google SRE 团队发展出了检查风险和排序风险优先级的方法。他们创造了一个定量风险分析框架，通过风险的检测/修复时间、影响的严重程度及其频率或可能性的积分来做评估。

我们可能无法控制所有事件的发生频率，但我们可以缩短响应时间、减轻负面效应，或减少受影响的用户数量。例如，我们可以使用 canary 部署或功能标记来减少不良更改对用户的影响，并在必要时快速回退到旧版本。一项改进是否成功取决于它是否减少了一般用户的糟糕体验。canary 部署策略可能会减少与部署相关的服务中断时间，从每月一次两小时的中断，影响 100％的用户（平均每位用户每月两小时），减到每月一次半小时的中断，只影响 5％的用户（平均每位用户每月 1.5 分钟）。

我们需要迅速解决那些消耗大量错误预算的风险，因为它们可能会导致系统的灾难性故障，并让我们的错误预算严重超支。如果我们的错误预算处于超支状态，可以把其他大批较小的风险推到以后再处理。通过定量分析充分利用错误预算的话，所有风险都会被解决掉；有了定量分析就更容易区分先后，并在开发新功能之前先解决已有的风险。

然而，针对特定风险条件的风险分析往往无法找到所有风险具备的共性。缺乏衡量标准、缺乏可观察性和缺乏协作（卓越生产的其他三个关键方面）是几大系统性风险，它们会让故障时间更久，更难预知，从而加剧了其他风险的影响。

生产支持不一定是痛苦的工作

成功的生产所有权和 DevOps 长期方法需要以卓越生产的形式变革组织文化。如果团队具有明确的可靠性测量手段和调试新问题的能力，拥有促进知识传播的文化以及主动降低风险的方法，那么团队就更有更好的持久作战能力。虽然工具可以用来帮助系统更加可靠，但文化和人才才是最重要的投资。

如果没有成熟的可观察性和协作实践，系统将在技术债务的重压下崩溃，人员和资金投入再多也无济于事。工程团队的领导者必须负责创建可持续服务用户需求和健康业务的团队结构和技术系统。生产所有权和卓越生产的结构能够帮助现代开发团队取得成功。我们不能指望失去能力的运维团队能够自动获得成功。

作者介绍

Liz Fong-Jones 是一名开发人员支持者、劳工和道德组织管理者，还是一位拥有超过 15 年经验的网站可靠性工程师。她是 Honeycomb.io 的 SRE 和可观察性社区的推动者；她的 SRE 工作经历包括 Google Cloud Load Balancer 到 Google Flights 等产品。

原文链接：

Sustainable Operations in Complex Systems with Production Excellence