8-1_第17章-识别过载并从中恢复.md

PART III 流程

SRE不仅仅是技术实践的集合-它是一种需要一致且逻辑的流程的文化。本节介绍了SRE中应用的流程的一些重要元素:管理运维和开发工作，从过载中恢复，构建和管理与开发合作伙伴和客户的关系以及实施实际的变更管理。

如果您是SRE的负责人，那么本部分将为您提供指导，以帮助您创建团队成功实施第二部分所涵盖的实践所需的空间和环境。

第17章

识别并从过载中恢复

由Maria-Hendrike Peetz，Luis Quesada Torres和Marilia Melo与Diane Bates撰写

当SRE团队运行平稳时，团队成员应该感觉自己可以轻松地处理所有工作。他们应该能够进行故障单工作，并且还有时间从事长期项目，这使得将来管理服务变得更加容易。

但是有时候情况会影响团队的工作目标。团队成员长期生病请假或转入新团队。组织为SRE交付了新的生产范围的程序。对服务或更大系统的更改带来了新的技术挑战。随着工作量的增加，团队成员开始工作更长的时间来处理故障单和呼叫，并花费更少的时间进行工程工作。整个团队在努力工作时开始感到压力和沮丧，但感觉不到自己正在取得进步。反过来，压力会使人们犯更多错误，从而影响可靠性，并最终影响最终用户。简而言之，团队失去了调节日常工作和有效管理服务的能力。

此时，团队需要找到摆脱这种超载状态的方法。他们需要重新平衡工作量，以便团队成员可以专注于基本的工程工作。

"运维负载"是一个术语，用于描述使系统和服务保持最佳性能运行的持续维护任务。有三种不同类型的操作负载:呼叫，故障单和正在进行的运维职责。呼叫通常需要立即关注，与紧急问题相关的故障单可能会有紧迫的期限。呼叫和紧急故障单都会中断SRE从事支持团队运维职责的工程项目。因此，我们将它们称为"中断"。[Site Reliability Engineering]的第29章讨论了管理团队将复杂系统维持在功能状态时自然产生的中断的技术。

当操作负载超过团队的管理能力时，团队最终会处于运维过载(也称为工作过载)状态。当团队无法在关键优先事项上取得进展时，团队就处于运维超负荷状态，因为紧急问题不断抢占项目工作。除了降低团队的优先级和改善服务质量之外，过载还会增加工程师犯错的机会。¹

团队之间的操作过载阈值可能会有所不同。Google SRE团队将运维工作的时间限制为工程师的50％。一个成功的SRE团队必须有信心，从长远来看，他们将能够完成所需的工程项目，以减轻他们管理的服务的运维负担。

本章介绍了Google的团队如何从以运维过载为特征的困难局势发展为管理良好的工作负荷。两个案例研究显示了运维超负荷对团队健康的有害影响，以及团队如何更改其日常任务，以便他们可以专注于长期影响重大的项目。在案例研究1中，当一个正收缩团队的剩余成员无法跟上工作量时，就会导致过载。在案例研究2中，一个团队遭受感知超载-一种与运维超载具有相同效果的状态，但其开始时对实际工作负载的误解。

这些案例研究着重介绍了适用于两个Google SRE团队的特定操作，但第366页的"缓解过载的策略"部分提供了适用于任何公司或组织的识别和缓解过载的实践。因此，本章对过载团队的经理或任何关心过载的SRE团队都应该是有用的。

从负载到过载

无论其起源如何，过载都是一种职业压力，会削弱生产力。如果任其发展，可能会导致严重疾病。对于SRE团队，运维负荷通常是认知上困难的任务(例如调试内存泄漏或分段错误)和许多小任务的组合需要频繁的上下文切换(通过配额请求，启动二进制部署等)。

当团队没有足够的时间来处理所有这些任务时，通常会发生工作超负荷的情况，这是客观的现实，即分配给团队的任务数量无法在给定的期限内完成每个任务。感觉到的超负荷更为主观，并且在团队中的每个人感到他们的工作过多时发生。通常在短时间内发生几项组织或工作变更时会发生这种情况，但是团队几乎没有机会与领导层就变更进行沟通。

不清楚在值班时会出现什么问题，或者工作量会是多少。一方面，一张关于磁盘空间用尽的看似无辜的故障单可能会导致对重复发生的垃圾收集作业的深入研究。另一方面，20次呼叫以上的值班风暴可能是监控不佳的情况。当难以估计或预测工作量时，您很容易成为认知偏见的受害者，并错误地估计工作量-例如，您可能认为故障单队列太大而无法在轮班期间完成。即使您可以快速完成所有故障单并且实际工作量很低，但是当您初次查看故障单队列时，您还是会感到超负荷。这种感觉超负荷²本身具有影响您对工作的态度和态度的心理因素。如果您不以有太多工作而先入为主，那么您很可能会潜入并开始尝试通过故障单队列。也许您整天工作并没有完成工作量(因此面临工作超负荷)，但是与开始时不知所措相比，您取得了更大的进步。

累积许多中断会导致工作过载，但这不是必须的。但是，当频繁的中断与外部压力因素结合使用时，大的工作量(甚至是小的工作量)很容易变成感知的过载。这种压力可能是由于担心其他团队成员感到失望，工作缺乏安全感，与工作有关或与个人有冲突，疾病或与健康有关的问题(如缺乏睡眠或运动)而引起的。

如果您的工作没有得到适当的优先排序，那么每个任务似乎都同样紧迫，从而导致实际和可感知的过载。在实际超负荷的情况下，工单和警报的紧急性可能会导致团队成员继续工作，直到他们解决问题为止，即使这样做意味着连续的长时间工作。当团队面临明显的超负荷时，重新安排优先级可以帮助减少紧急工作量，为他们创造空间来通过项目工作解决超负荷的根源。

在分析您的特定情况时，您不必假定工作负载本身需要更改。相反，我们建议您首先量化您的团队所面临的工作，以及它随着时间的变化(或没有变化)。例如，您可以通过团队处理的故障单和呼叫数来衡量工作量。如果您的工作量实际上并没有随着时间的推移而改变，那么团队可能会因为他们认为工作繁重而感到超负荷。为了更全面地了解团队当前的工作量，您可以通过要求每个成员列出他们面临的所有工作任务来收集一次性快照。然后查看团队面临的心理压力因素，例如组织变更或重新安排优先级。完成研究后，您将有一个稳定的基础来做出有关更改工作负载的决策。

第366页的"减轻过载的策略"更多地讨论了如何识别实际过载和感知过载。首先，我们对团队进行了两个案例研究，这些团队认识到他们处于超负荷状态，并采取了缓解措施。

案例研究1:半个团队离开时的工作超负荷

背景

Google的内部存储SRE团队之一负责多种服务的后端，包括Gmail，Google云端硬盘和Google网上论坛以及许多其他内部或面向用户的服务。我们在2016年中期经历了一次危机，当时三分之二的团队(包括最高级的工程师(经理))出于相对完全不相关的原因，在相对较短的时间内转移到其他机会。显然，此事件导致了巨大的工作负载管理问题:可用于覆盖相同运营和项目工作的SRE更少，从而导致过载。我们的工作也遇到了瓶颈，因为每个团队成员的专业知识都被隔离到不同的生产领域。从长远来看，增加新的团队成员和三个实习生可以改善我们的工作量，而增加这些工程师则需要花费大量时间和精力。

问题陈述

前述因素大大降低了团队生产力。我们开始在项目工作上落后，与我们管理的许多服务相关的故障单开始堆积起来。我们没有足够的带宽来解决此积压工作，因为我们的所有工作都被优先级较高的任务占用。不久之后，我们将无法完成我们需要做的所有关键和紧急工作。同时，我们的团队计划很快接受更多的高优先级工作。

如果我们不做一些工作，那么我们不小心开始放弃重要的工作只是时间问题。但是，一旦我们开始卸货，就会遇到一些心理障碍:

• 放弃正在进行的任何工作，就好像我们浪费了我们的精力。大部分待办事项似乎对我们来说都是至关重要的，也值得我们付出努力，因此无限期取消或延迟项目是不合适的。我们没有意识到自己陷入了沉没成本谬误。

• 致力于自动化流程或解决工作负载的根本原因并不像立即处理高优先级中断那样重要。当这项工作被添加到一个已经很大的堆的顶部时，所有的工作都感觉不堪重负。

我们决定要做什么

我们将团队聚集在一个房间里，并列出了团队的所有职责，包括项目积压，运维工作和工单。然后，我们对每个列表项进行了分类。查看我们的每一项工作任务(即使列表几乎不适合白板)也有助于我们确定并重新定义我们的实际优先事项。然后，我们能够找到最小化，移交或消除优先级较低的工作项的方法。

实施

我们确定了不费吹灰之力的自动化技术，尽管它并不重要，但一旦部署，它将大大减少操作负荷。

我们还确定了可以记录的，可以实现自助服务的常见问题。编写客户所需的过程并不需要很长时间，并且从我们的队列中删除了一些重复的工作。

我们尽可能地关闭了许多积压的工单。这些故障单大多数已过时，多余或不像他们所声称的那么紧急。一些故障单是不可操作的监控工件，因此我们修复了相关监控。在某些情况下，我们正在积极解决非关键问题。我们将这些问题放在一边，以便处理更紧急的故障单，但首先记录了我们的进度，因此在再次进行处理之前，我们不会失去上下文。

如有疑问，我们放弃了一项任务，但将其标记为第二阶段的分类。一旦我们的餐盘(几乎)是空的，我们重新访问了这个暂定清单，以决定要恢复的任务。事实证明，这些任务几乎都没有影响力或重要到足以恢复。

在两天的时间内-密集分类的一天，外加记录过程和实现自动化的一天-我们的小得多的团队处理了几个月中断的积压。然后，我们可以处理剩余的少量中断，这些中断与生产中的活动问题有关。

经验教训

我们的团队了解到，鉴别并确定超载是解决它的第一步。我们需要让每个人都在一个房间里并重新评估积压，然后才能帮助我们的团队恢复健康。

为了避免新的中断堆积，我们每两周开始对中断进行一次分类。我们的技术主管会定期检查任务队列，并评估团队是否有超负荷工作的风险。我们决定每个团队成员应拥有10张或更少张open的故障单，以避免超载。如果团队负责人发现团队成员拥有超过10张故障单，他们可以执行以下一项或多项操作:

• 提醒团队关闭过期故障单。

• 与超负荷的团队成员同步并从他们那里卸载故障单。

• 提示各个团队成员解决他们的故障单队列。

• 组织整个团队的一日集中故障单修复。

• 分配工作以修复工单来源，或分配工作以减少将来的工单。

案例研究2:组织和工作负载更改后的感知超载

背景

在此案例研究中，Google SRE团队被划分为两个地点，每个站点都有六到七名值班工程师(有关团队规模的更多讨论，请参见以下内容的站点可靠性工程第11章) 。在悉尼团队运作健康的同时，苏黎世团队却超负荷运转。

在苏黎世团队超负荷工作之前，我们很稳定并且很满足。我们管理的服务数量相对稳定，并且每种服务种类繁多且维护程度很高。虽然我们支持的服务的SLO与它们的外部依赖项的SLO不匹配，但是这种不匹配并没有引起任何问题。我们正在进行许多项目，以改善我们管理的服务(例如，改善负载平衡)。

同时触发因素使苏黎世团队陷入超负荷状态:我们开始采用噪音较大且与Google的通用基础架构集成程度较低的新服务，技术负责人经理和另一位团队成员离开了我们的团队，使两个人短缺。额外的工作量和知识流失的结合引发了更多的问题:

• 对新服务的监控调整和与迁移相关的监控导致每班更多呼叫。这种积累是渐进的，因此我们没有注意到上升的发生。

• SRE对新服务感到相对无助。我们对它们的了解不足，无法做出适当的反应，因此经常需要向开发团队提出问题。尽管超负荷可能需要将服务交还给开发人员，但我们的团队从未将服务交还给开发人员，因此我们并不认为这是可行的选择。

• 一个更小的五人的值班轮调减少了我们通常在运维工作上花费的时间。

• 新的故障单警报解决了最近的团队变更之前存在的问题。尽管过去我们只是简单地忽略了这些问题，但现在我们需要将被忽略的电子邮件警报移至故障单。项目计划没有考虑到这种新的技术债务来源。

• 新的故障单SLO要求我们在三天内处理故障单，这意味着应召集人必须更早解决其在轮班时创建的故障单。³ SLO旨在减少添加到我们的故障单中的故障单数量(几乎被忽略)积压，但产生的副作用可能更糟。现在，SRE感到他们在轮班后无法获得所需的其余部分，因为他们必须立即处理后续工作。这些故障单具有更高的优先级，这也意味着SRE没有足够的时间进行其他运维工作。

在这段时间里，我们的团队被分配了一位新经理，他还管理了另外两个团队。新经理不是值班轮换的一部分，因此没有直接感觉到团队成员正在经历压力。当团队向经理解释情况时，什么都没有改变。团队成员感到自己没有被听到，这使他们感到与管理团队相距遥远。

罚单的超载持续了几个月，使团队成员脾气暴躁，直到整个团队中散发出一连串的不满。

问题陈述

在失去了两个人并接受了更多不同的工作之后，我们的团队感到不堪重负。当我们试图将这种感觉传达给我们的直接经理时，经理不同意。随着长时间的工作，疲惫开始了。生产力正在下降，任务开始累积的速度超过了团队所能解决的速度。现在，感觉到的过载已变成客观过载，使情况变得更糟。

过载造成的情绪压力正在降低士气，并导致一些团队成员精疲力尽。当个人处理过度劳累造成的身体影响(疾病和生产率降低)时，团队中的其他人必须承担更多的工作。每周团队会议分配的工作尚未完成。

然后我们开始假设我们不能依靠别人来完成他们的工作，这削弱了团队内部的信任感和可靠性。结果，我们对人际风险承担(这是影响心理安全的重要因素)感到不安全(请参阅[Site Reliability Engineering]中的第11章)。团队成员没有感到其他团队成员的接受和尊重，因此他们没有彼此自由协作。由于团队的心理安全性下降，协作停止了，从而减慢了信息共享的速度，并进一步导致了效率低下。

团队调查还显示出心理安全感的丧失-团队成员说，他们不觉得自己属于团队。他们不再关心自己的职业发展，团队的晋升率降至历史最低水平。

当高层管理人员为我们分配了新的强制性全公司项目时，我们终于达到了一个突破点。在这一点上，我们重新与管理层进行了有关以新的活力进行过载的对话。一系列讨论表明，我们的不愉快情况不仅仅是工作量过多的结果-我们对团队安全的看法导致我们停止相互信任和合作。

我们决定要做什么

高层管理人员为我们的团队分配了一位新的经理，这三个团队之间没有人共享。新经理使用参与式管理风格改善了团队的心理安全性，以便我们可以再次进行协作。这种方法使团队成员能够积极参与解决团队问题。整个团队，包括我们的直接经理，都进行了一系列简单的团队建设练习，以提高我们团队的效率(其中有些简单到一起喝茶)。⁴因此，我们能够起草一套目标:

短期

减轻压力，改善心理安全，建立健康的工作氛围。

中期

通过培训建立团队成员的自信心。查找导致过载的问题的根本原因。

长期

解决导致级联的持续性问题。

为了设定这些目标，我们必须首先在团队中实现某种基准的心理安全。随着士气的提高，我们开始分享知识，并在彼此的思想基础上寻求解决方案，以控制工作量。

实施

短期行动

长期压力，无论是由于劳累过度还是团队安全感引起的，都会降低生产率并影响人们的健康。因此，我们最重要的短期措施是减轻压力，改善信任和心理安全。一旦减轻了一些压力，团队成员就可以更加清晰地思考并参与推动整个团队前进。在确定过载的一个月内，我们实施了以下措施:

• **启动了半常规圆桌会议来讨论问题。**该团队释放了挫败感，并集体讨论了可能导致超载的原因。

• **找到了一个更好的衡量负载的指标。**我们决定改进我们的原始呼叫数指标。我们自动将故障单分配给了呼叫者，即使转移结束后，呼叫者仍要负责这些故障单。我们的新指标衡量了呼叫者在轮班后解决故障单所需的时间。

• **审核并删除了垃圾邮件警报。**我们查看了警报，并删除了那些不代表用户面临问题的警报。

• **慷慨的安静的警报。**该团队故意不为每个警报寻找来源，而是致力于减轻我们已经知道的被连续寻呼和发出故障单问题的压力。我们使用以下策略:

  --- 浮出水面的警报将保持静音，直到它们被修复。

  --- 警报只能在有限的时间段(通常是一天，有时长达一周)内保持静音。否则，它们可能掩盖中断。

  --- 在几分钟内无法修复的警报已分配给跟踪故障单。

• **增加了一个专门负责单个团队的直接经理。**使新经理成为受人尊敬的团队成员，重新建立了对管理层的信任。新经理可以将更多的时间放在单个团队及其成员身上，而不是管理三个团队。

• **重新平衡团队。**通过添加对团队或组织没有先入为主的技术经验丰富的SRE，我们引入了新的视角和值班人员。寻找合适的人绝非易事，但值得付出努力。

• **举办团队活动，例如午餐和棋盘游戏。**谈论与工作无关的话题并一起大笑可以缓解团队的紧张感并提高心理安全性。

中期行动

仅短期解决方案将无法维持健康的氛围-例如，我们的短期策略之一是在没有真正解决问题的情况下使警报保持沉默。在三个月内，我们还采取了以下行动:

• 将运维工作尽可能地限制在值班时间(请参阅Site Reliability Engineering中的第29章)，以便团队可以专注于永久性修复和项目工作。

• 将一项服务的责任交还给其开发团队。

• **彼此培训(和新团队成员)。**尽管培训需要投入时间和精力，但传播知识意味着所有团队成员(以及将来的员工)可以在将来更快地解决问题并解决问题。培训同事提高了我们的信心，因为我们意识到我们实际上对服务非常了解。随着知识的积累，团队成员开始寻找管理服务，提高可靠性和减少过载的新方法。

• **从远程团队引进了SRE，以为我们的一些值班人员配备人员并参加培训。**他们注意到了团队的压力，并提供了一些有价值的新视角。

• 回补了团队中的两个公开职位。

• **随着沉默期满，处理每个警报。**我们讨论了重复的呼叫，这些呼叫在每周的生产会议上没有采取任何行动，导致我们调整警报和/或解决潜在的问题。尽管这些是重要的(也是显而易见的)操作，但是只有在警报静音且不会产生持续的噪音后，我们才有空间进行分析并采取措施。

• **有组织的倾听活动。**管理层(包括跳过级经理和团队负责人)有意识地倾听团队的痛点并找到团队驱动的解决方案。

• **增加的视角。**希望不是一种策略，但它无疑有助于团队士气。有了新成员加入呼叫轮换的承诺，转移到更明确的优先级并结束了产生噪声的项目，团队的情绪得到了改善。

长期行动

为了帮助维持新发现的稳定性，我们目前正在使SLO与它们的服务后端的SLO保持一致，并致力于使服务更加统一。一致性有双重好处:减轻SRE的认知负担，并使编写可跨服务使用的自动化更加容易。我们还将审查已经存在很长时间的服务，并将其更新为当前的生产标准。例如，某些服务在负载下运行不佳，而这些负载在过去几年中显着增加。某些服务需要根据其后端服务策略的更改进行更新。其他服务几年来一直没有更新。

效果

在我们第一次集思广益会议之后的几个月，结果开始浮出水面:呼叫班次变得更加安静，我们的团队设法以小组的形式快速有效地协作处理了一个困难事件。稍后，新的团队成员到达了。当我们在圆桌会议上讨论心理安全性时，新成员表示他们无法想象团队曾经遇到过此类问题。实际上，他们将我们的团队视为温暖，安全的工作场所。在最初的升级大约一年后，最初的超负荷仍然有少量存在，匿名调查显示，团队成员现在认为团队是有效且安全的。

经验教训

更换工作场所可能会对团队中的人员产生心理影响-毕竟，您的队友不是机器。您需要注意团队的压力水平，以便人们开始互相信任，可以一起工作；否则，团队可能会进入过载的恶性循环，从而导致压力，从而阻止您应对过载。

感观上的超负荷实际上是超负荷，对团队的影响与其他因素引起的工作超负荷一样大。在我们的案例中，我们在悉尼的姐妹团队没有遇到相同的问题，与往年相比，我们提供的呼叫数量实际上没有太大变化。取而代之的是，失去了两名团队成员，增加了认知负担，增加了工单噪音以及新的为期三天的工单SLO导致他们感到超载。最后，目标过载和感知过载之间的区别并不重要:少数团队成员的感知过载会很快导致整个团队的过载。

缓解过载的策略

有时，外部视角可以很容易地确定团队何时过载。同样，很容易就回顾过去应该采取的行动发表评论。但是，当您经历过载时，如何识别过载呢？当您陷入超负荷状态时，通往健康，友好，快乐的工作氛围的途径很难想象。本节介绍识别和减轻团队负担的实践。

识别过载症状

如果您知道超载的症状，很容易确定超载的团队:

降低团队士气

过载可能表现为骚动和抱怨。有关主题(工作条件，工作满意度，项目，同事和经理)的调查通常反映团队的士气，并在团队超负荷时产生更多的负面结果。与团队负责人定期进行积极的聆听会议可能会发现您没有意识到的问题。主动聆听的基本要素是不加判断地聆听。

团队成员长时间工作和/或生病时工作

无偿加班可能会成为社会心理压力源。领导者应树立一个好榜样:按时工作，生病时待在家里。

更常见的疾病 ⁵

过度劳累的团队成员往往会更容易遭受挫折和生病。

不健康的任务队列

我们建议您定期检查团队的任务队列，以查看积压了多少故障单，谁在处理哪些问题以及哪些任务可以延迟或放弃。如果团队没有按时完成任务，或者紧急情况使您无法定期执行此检查，则团队积累的中断很可能比他们能处理的快。

指标不平衡

一些关键指标可能表明您的团队超负荷了:

• 关闭一个问题的时间周期长

• 花很多时间在琐事上

• 大量时间来解决由呼叫中产生的问题

团队应该共同决定要使用的度量。没有一种万能的方法。每个团队的超载都以不同的方式反映出来。作为经理，在不了解每个人的工作量和工作习惯的情况下，不要对团队施加压力。如果您坚持使用特定的措施，团队成员可能会觉得您不理解工作。例如，如果您根据修复问题所需的天数评估负载，则一个人可能会整天工作以解决问题，而另一个人可能将工作与其他工作一起分配几天。

减少超载并恢复团队健康

阅读标准后，您可能会认为您的团队已经超负荷工作。别失望！本节提供了使您的团队恢复健康状态的想法列表。

总的来说，赋予团队成员更多的控制权和权力可以减少感官上的负担。⁶虽然经理可能会在压力很大的情况下诉诸于微观管理，但重要的是使团队保持循环并共同进行优先排序。⁷此模型假设一个您在管理与团队成员之间以及团队成员之间功能团队的基线。

确定并缓解心理压力源

在修复功能失调的团队时，最重要的是，每个团队成员都需要重新获得心理上的安全感。团队只能行使其个人成员的职责。

您可以从确定和减轻每个人和整个团队的心理压力源⁸开始。您实际上可以控制以下哪些因素？您无法控制团队成员是否患有重大疾病，但是您可以*控制团队的积压(如案例研究1中所示)或静音呼叫(如案例研究2中)的大小。

与您的合作伙伴产品开发团队进行沟通，并让他们知道您的团队超负荷。他们也许能够伸出援手，提供同情心，甚至接管整个项目。

当您的团队成员相互依赖并达到一定水平的心理安全(这样他们就可以承担人际交往的风险)时，您可以给单个团队成员更多的责任*。*发现专业领域并为关键人员和技术线索分配特定技术可以增强他们的自信心，从而使他们能够承担风险。

决策应该透明，并且在可能的情况下民主。每个团队成员都应该对局势有控制感。例如，案例研究2中的集思广益会议帮助团队确定并讨论了问题。

在四分之一时间内对优先级进行分类

一个健康的团队可以对问题进行优先排序和分类。案例研究1提供了此练习的一个很好的例子:团队坐在一个房间里，并查看他们的积压工作。审查帮助他们意识到他们已经超负荷。他们重新安排了工作的优先级，并致力于可以减少某些超负荷工作的任务。案例研究2中的团队现在在每个季度末开会，以计划并确定现有和未来的合作重点。

如果可能，我们建议SRE在其日历上安排"无中断时间"(无呼叫时间)，以便他们有时间从事定性困难的任务，例如开发自动化系统和调查中断的根本原因。在案例研究2中，当远程团队给值班人员一些救济时，团队成员便有宝贵的时间专注于他们的项目。

如果绝对必要，则放弃工作:在案例研究2中，团队将这一职责交还给开发团队，从而放弃了对其中一项服务的值班支持。

保护未来的自己

我们强烈建议建立度量标准以评估团队的工作量。定期检查指标，以确保它们衡量正确的事物。

一旦您的团队摆脱了过载，您可以通过采取措施监控或解决潜在问题来防止将来的过载。例如，案例研究1中的团队现在维护一个轻量级的分类流程，以检测不断增加的任务积压。案例研究2中的团队目前正在制定一项长期计划，以使后端和服务SLO保持一致。

当您的团队处于超负荷状态时，对项目工作进行优先级排序，在你没过载的情况下及时交付比你要交付的更多的重复琐事工作。您将来会获利。

最后，团队中的每个人都应对指示可能出现过载情况的早期预警信号负责(请参阅第366页的"识别过载症状")。如果经理认为团队正在超负荷工作，经理应该坐下来与他们交谈。

结论

在理想的情况下，SRE团队将始终能够使用第一本书中描述的策略来管理中断。但是我们只是人，有时我们的团队达不到理想。本章研究了过载可能消耗团队的一些方式，并讨论了如何在过载时进行检测和响应。

特别是在进行运维工作时，过多的中断很容易导致团队从正常的工作量转移到过载。频繁的中断会导致过载，并且过载会对运行状况和生产率产生负面影响。过载会给团队成员带来心理压力，这会进一步影响工作，导致自我执行周期。

感观的过载是过载的一种特殊形式，无法通过琐事的工作或工作量来衡量。很难查明和消除。

为了使团队的工作负载保持平衡，重要的是不断监控(感观或非感观的)过载。为了更好地服务于用户并做好工作，您需要首先对自己和团队表示尊重。在日常工作中保持健康的平衡对帮助您和您的团队实现这一目标大有帮助。

Footnotes

1. Kara A. Latorella，调查中断: 对Flightdeck性能的影响(弗吉尼亚州汉普顿: 兰里研究中心，1999年)，https: //go.nasa.gov/2Jc50Nh； NTSB，飞机事故报告: NWA DC-9-82 N312RC，底特律都会区，1987年8月16日(编号NTSB / AAR-88 / 05)(华盛顿特区: 全国交通安全局，1988年)，http: //libraryonline.erau.edu/online-full-text/ntsb/aircraft-accident-reports/AAR88-05.pdf。 ↩

2. Emmanuelle Brun和Malgorzata Milczarek，与职业安全与健康有关的新兴社会心理风险的专家预测(西班牙毕尔巴鄂: 欧洲工作安全与卫生局，2007年)，*https://*osha.europa.eu/zh-CN/tools-and-publications/publications/reports/7807118； M. Melchior，I。Niedhammer，LF Berkman和M. Goldberg，"社会心理工作因素和社会关系是否对疾病缺席发挥独立影响?GAZEL队列的六年前瞻性研究"，《流行病学与社区健康杂志》 57，第4期(2003年): 285--93，http: //jech.bmj.com/content/jech/57/4/285.full.pdf。 ↩

3. 就上下文而言，根据估计，SRE每班需要至少再增加一天的故障单跟踪。 ↩

4. 我们使用了基于Project Aristotle的Google程序: http: //bit.ly/2LPemR2。 ↩

5. Kurt GI Wahlstedt和Christer Edling，"邮政分拣站的组织变革-它们对工作满意度，心身投诉和病假的影响"，《工作与压力》，第11期，第11页。 3(1997): 279--91。 ↩

6. 小罗伯特·卡拉塞克(Robert A. Karasek)，"工作需求，工作决策自由度和精神紧张-对工作重新设计的影响"，《管理科学季刊》，第24期，第24页。 2(1979): 285--308。 ↩

7. 弗兰克·邦德(Frank W. Bond)和大卫·邦斯(David Bunce)，"工作控制在减少压力的工作重组干预中发挥了作用"，《职业健康心理学杂志》 6，第6期。 4(2001): 290--302； Toby D. Wall，Paul R. Jackson和Keith Davids，"操作员的工作设计和机器人系统性能: 偶然的田野研究，" 应用心理学杂志 77，第3号(1992年): 353--62。 ↩

8. Brun和Malgorzata，专家预测。 ↩