【云原生系统故障自愈论文学习】—How to Fight Production Incidents? An Empirical Study on a Large-scale Cloud Service

ACM Symposium on Cloud Computing: ACM SoCC 云计算顶级会议

Abstract

We answer:

(a) why the incidents occurred and how they were resolved

(b) what the gaps were in current processes which caused delayed response

© what automation could help make the services resilient(有弹性的)

Finally, we uncover interesting insights by a novel multi-dimensional(多维的) analysis that correlates different troubleshooting(故障排除) stages (detection, root-causing and mitigation), and provide guidance on how to tackle complex incidents through automation or testing at different granularity.

1 INTRODUCTION

在本文中，我们系统地研究了最近12个月内发生在大规模分布式云服务Microsoft-Teams中的152起高严重性生产事件，该服务在全球有超过2.5亿用户使用。

另外，与以往的研究不同，我们研究了由包括软件缺陷在内的多种类型的根本原因引起的incident，并分析了如何检测和缓解这些incident。

我们首先独立地看一下incident的三个主要阶段：detection、root-causing和mitigation。

• 大概一半的incident可以被现有的检测器成功检测到。收集额外的遥测数据，修复现有监测器的错误，调整监测器的阈值，或增加监测器，可以将自动监测的有效性提高50%。

• 虽然软件bug是一个常见的根本原因，但很大一部分（大约一半）的incident是由与代码无关的问题造成的，如基础设施能力问题、手动部署错误和证书过期。

• 绝大多数（>90%）的incident都在不改变代码的情况下得到了缓解：回滚、基础设施和配置更改、重启服务。

  注意，缓解措施通常是确保服务继续运行的临时措施。许多incident后来通过更持久的措施（如代码修复）得以修复。

当监测器检测事故失败时（监测器出现bug，阈值设置错误，粒度错误），detection会延迟。当修复部署较慢、文档较差、人为参与时，mitigation会延迟。有可能加快检测和缓解的几种技术：微调监控器和增加额外的测试，改进文档和部署/编码实践，自动化缓解：自动证书更新，流量故障转移，自动缩放等。

这项工作的一个重要贡献是对不同粒度下的不同阶段进行了多维分析。

Important Observations：

• 由于监控不力，由软件bug和外部依赖关系引起的incident需要更长的时间才能发现。
• 某些根本原因类别导致的incident在其根本原因类别确定后会迅速缓解。例如，通过回滚和配置更新可以分别快速缓解配置错误和证书过期导致的incident。
• 由某些根本原因引起的incident本质上很难自动监控(比如，需要监控全局状态)。

2 METHODOLOGY

2.1 Incident Selection in Our Study

我们对微软团队在2021年5月15日至2022年5月15日的12个月期间发生的152起符合以下所有条件的高严重性incident（严重程度为0、1和2）进行抽样研究：

• 事件严重级别(2或更低)表明它导致了服务的某些组件的故障，并影响了客户。
• 事件已得到解决或缓解，并将根本原因描述与事件报告相关联。
• 事件有一份完整的事后报告，其中有关于检测和缓解措施的丰富信息

2.2 Categorization Strategy

通常，一个incident会经历三个主要阶段:

1. detection – incident is detected by a service monitor or reported by a customer
2. root cause analysis – investigation by on-call engineers to identify the root cause
3. mitigation – following procedures and executing steps to mitigate the impact of the incident

为了全面理解这一过程，我们首先确定了六个影响事件管理的因素进行研究(如表1所示)。

我们首先随机采样并将152个事件数据集分成三个子集:(1)分类集:60个事件，(2)验证集:30个事件，(3)测试集:62个事件。

首先，给事件的每个factor分配了一个类别，以最好地描述该总结。随后，检查这些类别，并为每个factor确定一个共同的taxonomy。接下来，给验证集贴上标签，以确保没有新的类别出现，并进行另一次讨论，以确定对每个类别有更精细的理解。最后，对测试集进行了标注，并使用Cohen’s kappa来找到标注者之间的一致分数。我们观察到六个分类中的每一个都接近完美的一致性: Root Cause: 0.94, Mitigation: 0.945, Detection Failure: 0.88, Mitigation Failure: 0.94, Automation Opportunities: 0.936, Lessons for Resiliency: 0.98。

一个事件没有被分到多个类别中。

3 WHAT CAUSES INCIDENTS AND HOW WERE THEY MITIGATED?

3.1 What are the Root Causes?

我们将根因分为了7个类型：

Code bugs

我们观察到的代码bug如下：

1. 代码变更或有缺陷的功能（占代码bug总数的24.4%）：这些问题出现在开发人员更新现有的代码库或部署一个新的功能，该功能通过了现有的测试用例，但包含有问题的代码。
2. 标志和常量（占代码bug总数的24.4%）：当标志设置错误（但由于场景测试不充分而通过测试）导致某些功能无法正常运行时，就会出现这些类型的代码错误。当服务运行状况检查或性能度量的阈值参数值设置不正确时，也会出错。
3. 代码依赖（占代码bug总数的19.5%）：由于大型云服务中不同组件之间的相互依赖关系，一个组件中的代码更改可能会中断依赖组件的功能。当一个组件中的更改无法处理依赖组件的旧代码中的其他属性时，通常会发生代码依赖错误。
4. 数据类型、验证和异常处理（占代码bug总数的17.1%）。
5. 向后代码兼容性（占代码bug总数的14.6%）：比如在API代码更改中，一个blob条目被重命名，但漏掉了一个地方，这阻止了信息流到达用户界面端。

Infrastructure issues

我们将这些基础设施退化问题分为以下几类：

1. CPU容量(33.3%):由于基础设施变更降低了CPU容量，特定应用程序或请求使用了大量CPU，导致特定节点/集群故障，从而导致服务降级，导致CPU利用率急剧上升。
2. 由于高流量导致的容量问题(41.7%)。当服务(内部或外部)接收异常大量的请求或流量时，现有的基础设施通常无法处理负载，因此它开始节流，并产生高延迟。
3. 基础设施规模(16.7%)。在某些情况下，仅使用生产集群的一部分进行操作，这会导致资源过度使用，从而导致依赖于这些资源的应用程序失败。
4. 基础设施维护 (8.3%)。在基础设施维护或迁移过程中，缓存信息可能被意外删除，导致终端用户无法连接该服务。

Deployment errors

1. 证书管理(55.0%)。在部署期间，运维人员要么使用了已经过期的旧证书，要么使用了不正确的证书，从而导致服务无法获取正确的身份验证令牌。另一个常见问题是证书自动轮换，这需要更改证书颁发策略的一些设置，但在部署期间却忽略了这些设置。
2. 错误部署和补丁(25.0%)。运维人员部署了错误的补丁，破坏了一些现有功能或对另一个组件产生了不正确的依赖。
3. 人为错误（20%）。当运维人员在部署过程中的手动步骤出错时，就会出现此问题。

Configuration bugs

1. 错误配置问题(47.4%)。运维人员在配置时出现错误，或者使用了一个较差的配置。
2. 配置变更(42.1%)。
3. 配置同步(10.5%)。If two or more flighting configuration settings operate within the service, then the updated configuration could expire, and the old configuration is used that fails to fetch the right tokens。

Dependency failures

1. 版本不兼容(24.0%)。
2. 服务健康(20.0%)。如果依赖服务的服务质量下降，则下行任务也会失败。
3. 外部代码变更(28.0%)。如果合作团队或远程服务引入了错误的更改，部署了有问题的包，或者更新了一些依赖于Microsoft-Teams配置的设置，则Microsoft-Teams的功能会受到影响。
4. 功能依赖(28.0%)。

Database or network problems

数据库或网络问题大多与容量有关，即云系统无法处理高于正常或预期的用户请求并限制用户的请求。在这些事件中，25%与高往返时间（RTT）或依赖服务中的延迟峰值导致的网络延迟有关。大约31%的事件是由于网络可用性或连接问题导致的。此类事件中的其他44%是由于两种类型的数据库相关问题造成的：25%的事件是由于影响文件操作的数据库中断造成的；19%的事件是由于用户请求负载增加后数据库容量扩展不足而发生的。

Authentication failures

由于访问策略更改或在新生成部署期间推出的其他令牌之间的竞争，会出现身份验证错误。

1. 授权问题(42.9%)。
2. 证书轮换(28.6%)。由于新密钥、令牌或证书的轮换，对服务的调用失败。
3. 身份验证错误(28.6%)。由于访问策略更改，对服务的身份验证请求失败。

3.2 What are the Mitigation Steps?

我们确定了确切的缓解方法，并将其分为7类。

Rollback

1. 代码更改回滚(35%)。
2. 配置项更改回滚(24%)。
3. 新版本回滚(41%)。重新部署较旧的稳定版本。

Infrastructure change

更改基础设施是一种常用的缓解方法，因为它可以快速恢复服务，特别是针对容量和节流问题。在这些基础设施更改中，约44%的事件使用流量故障转移到另一个正常运行的服务组件。流量重定向有三种方式：

1. 故障转移到另一个健康节点(16%)。
2. 故障转移到另一个健康集群(9%)。
3. 故障转移到另一个云区(cloud region)(19%)。

其余的56%的事件则通过节点缩放或节点重启来解决。其中，约31%的事件通过升级节点基础设施以解决过度利用问题，10%的事件使用节点降级策略（例如，删除不正确配置的节点）。剩下15%则是重新启动故障或不健康的节点。

Configuration fix

1. 创建新证书或轮换与现有要求同步的续订证书(25%)。
2. 更改以及重新部署配置文件(20%)。
3. 恢复之前的稳定配置文件(20%)。
4. 修复故障功能(25%): 禁用新功能；恢复功能变更；故障转移到其他类似但稳定的功能。
5. 同步不同服务的相关配置文件(10%)。

Code fix

由于时间的限制，运维人员较少通过修复bug来解决事故。

1. 代码变更(42%)。
2. 添加额外的异常处理逻辑(25%)。
3. 添加整个代码模块或抽象方法来包含新资源(例如证书等）(17%)

External fix

1. 回滚变更(29%)。
2. 修复bug(17%)。
3. 合作团队执行各种缓解措施，从修复元数据、重新启动节点/群集到流量重路由，有时还向客户/用户发送通知，要求禁用不受支持的插件(54%)。

Ad-hoc fix

当根本原因很复杂并且OCE不熟悉该问题时，他们会执行一系列临时命令。根据先前步骤的结果，将采取进一步的缓解措施。这些类型的修复程序称为“热修复程序”，可以由内部OCE运行，也可以进而由合作伙伴团队运行。

Transient

如果某些运行状况检查指标超过预定义的阈值，自动监测器就会触发这些事件。我们把这些事件称为假警报。当基础设施条件稳定(例如，网络连接恢复)时，这些事件会自动缓解，系统也会恢复正常。这些事件的自动缓解主要有三个原因：

1. 基础设施的自愈(比如网络的恢复)。
2. 从用户端重启app。
3. 服务健康指标自动恢复。

4 WHAT CAUSES DELAY IN RESPONSE?

在本节中，我们从检测时间(TTD)和缓解时间(TTM)两个方面分析响应时间，以了解关键根本原因和缓解类型。TTM为缓解事件的时间与检测到事件的时间之间的差值。此外，我们从OCE的评论中收集信息，分析了检测和缓解延迟背后的常见原因。

4.1 Response Time Analysis

图3(a)比较了由不同类型的根本原因引起的事件的归一化TTD和TTM，所有事件的TTD和TTM的并集的中位数为“1”。此外，对于每一类根本原因，我们从高和低两个方面去除了10%的异常值。对于每个类别，我们显示了平均TTD和TTM以及标准误差(由红色封顶线表示)。代码bug和依赖项失败的检测和缓解时间明显高于其他根因类型。对于身份验证失败和与数据库/网络相关的问题，检测过程较快，但缓解时间相对较长。另一方面，对于部署错误，检测花费的时间比缓解时间更长。

图3(b)比较了由不同类型的解决步骤引起的事件的归一化TTD和TTM。与根本原因分析类似，我们在此实验中删除了10%的异常值事件。transient和infrastructural change类别的TTD和TTM较短。同样，rollback的TTM较短。有趣的是，external fix的检测和缓解时间十分短，因为大多数缓解步骤要么是回滚，要么是基础设施更改。由于代码或配置修复需要手动操作，因此这些事件的检测和缓解时间较长。同样，正如预期的那样，与rollback/infrastructural change相比，ad-hoc fixes需要更长的时间来缓解事故。

4.2 Reasons for Delay in Detection

4.2.1 How incidents are detected?

• 自动监视程序检测（55%）。这些自动化监视程序由Microsoft的开发人员部署，用于持续监控系统运行状况数据(例如，延迟、CPU使用率、内存使用率)，并在指标超过健康阈值时发出警报。
• 外部用户或客户报告（29%）。
• 内部合作团队确定（10%）。
• Microsoft-Teams的服务团队自己检测到（6%）。

4.2.2 Why automated watchdogs failed?

我们确定了检测失败的主要原因，并将其分为7种类型。

Monitor bugs

1. 总体失败率低于高警戒阈值(25%)。
2. 对事件严重程度的错误诊断(25%)。
3. 测试未能识别该监视器有错误的功能或错误的配置(50%)。

Telemetry coverage

1. 环境相关(31%)。特定类型的云环境需要额外的遥测数据。
2. 服务健康相关(38%)。需要针对资源利用率指标发出其他警报(例如，高CPU使用率或服务停机警报)。
3. 场景相关(31%)。缺少其他基于场景的警报。

External effect or hard to detect

如果事件是由对合作团队的依赖而导致的，并且由于合作伙伴应用程序未能检测到来自其一侧的异常而导致检测延迟，我们将其称为"External Effect"。另一方面，如果事件是由客户或合作伙伴团队通过手动场景测试检测到的(例如，部署问题)，我们将其称为“"Cannot Detect”类别，因为这些事件很难被自动监视器识别。

No watchdogs

在某些情况下，由于合作伙伴的应用程序端缺少监视器，因此未检测到事件。

Not failed or Unclear

如果OCE在事后报告中将延迟故障字段留空，我们将其称为“Unclear”类别。

4.2.3 Detection failure time analysis

如图(a)所示，对于故障复杂且难以识别的事件，检测时间是最高的，尽管此类事件的比例很低。正如预期的那样，在没有自动监测器，或者监测器收集的遥测数据量有限的情况下，检测时间明显偏高。

4.3 Reasons for Delay in Mitigation

我们确定了缓解失败背后的关键原因，并将其分类为7种类型。

Deployment delay

1. 外部人工审批(25%)。
2. 权限问题(25%)。
3. 系统更改缓慢(50%)：配置更改或节点扩展或推出“热修复”需要更长时间才能生效。

Documentation and procedures

缓解进程会因文档不佳或基础设施设置不佳而延迟，可分为三大类：

1. OCE的知识差距(19%)。当严重程度较低或OCE之间没有适当沟通类似事件的解决方法时，OCE没有迅速采取行动。
2. 故障排除指南（TSG）质量(50%)。
3. 基础设施设置不佳(31%)。对于特定环境中的节点自动扩展、流量自动故障转移或自动回滚代码，无法使用正确的设置。

Complex root Cause

我们观察到在根本原因确定方面出现延误的三个原因：

1. 极少发生(18%)：问题可能来自新功能或该特定情况很少见。
2. 无遥测信息(27%)：由于未记录所需的性能指标，因此很难捕获问题。
3. 调试问题(55%)：找出代码更改中的错误需要时间。

Manual effort or external dependency

1. OCE崩溃(14%)：值班工程师们同时执行几个步骤，却没有进行适当的沟通。
2. 误诊(29%)。
3. 部署和配置错误(36%)。
4. 外部依赖：与合作伙伴存在沟通障碍。

Not failed or Unclear

4.3.1 Mitigation failure time analysis

如图(b)所示，具有复杂根源的事件需要较长时间才能缓解，因为OCE没有适当的文档或故障解决指南来解决这些事件。正如预期的那样，如果存在与部署相关的问题，缓解工作将花费更长的时间。如果流程中涉及任何手动步骤，那么缓解也会被延迟。

5 LESSONS LEARNT FOR RESILIENCY

5.1 Automation Opportunities for Future

在每个事故事后报告中，OCE都会提供他们的专业意见，说明可以在服务中添加哪些自动化技术(automation)，以使他们在未来应对类似故障时具有弹性(resilient)。我们将这些自动化策略分类为6种类型(参见图7)。

Manual and configuration test

OCEs提供的大部分自动化建议都与改进各种测试方法有关：

1. 性能测试(12.8%): 使用混沌工程技术进行负载或压力测试。
2. 系统测试(23.1%): 端到端测试以验证系统功能。
3. 情景测试(30.8%): 针对特定类型的用户或部署环境使用特殊和不常见的案例进行测试。
4. 验证测试(12.8%): 消除身份验证模糊性的新测试。
5. 集成测试(7.7%): 确定合作团队的依赖错误。
6. 单元测试(12.8%): 用来验证几个功能或向后代码兼容性。
7. 配置测试: 在推出任何配置更改之前，应测试所有边界条件。

Automated alert/triage

为了消除检测失败，OCEs建议了三种类型的方法来自动化警报或分诊过程：

1. 微调监视器(30%): 适当调整监视器的阈值参数，以便在影响较低时更早发出警报，或者添加新的性能工具和异常检测规则，例如，设置证书即将到期的警报。
2. 改进健康检查(52%): 需要添加更多监视器并扩大现有监视器的遥测覆盖范围。
3. 自动分诊(18%):

Automated deployment

我们观察到两种类型的部署自动化建议：

1. 故障切换自动化(44%)。
2. 自动发布(56%): 避免任何人为干预，从而消除手动步骤中的延迟或错误。

Unclear or no automation required

此情景下，OCE们指出，额外的自动化对服务的弹性没有帮助。大致分为三种类型：

1. 已经存在充足的自动化技术(30%)。
2. 实施自动化比较困难(18%)：如果是生产网络或容量问题，那么设置监视器或测试用例是非常有挑战性的。
3. 自动化技术不适用(52%): 问题出在合作伙伴的应用程序中

如果OCE们表示他们不确定是否可以使用自动化技术，则归为“Unclear”。

5.2 Discussion on Lessons Learnt for Future

我们将从事后分析中OCE们提供的经验教训分为以下七类：

Improve monitoring and testing

对于监测，有三种类型的建议：

1. 添加遥测(54%)：更新现有的监视器以主动跟踪性能和内存使用的增长，以检测某些特定场景的异常，或者创建新的监视器以对错误配置和生产发布问题发出警报；
2. 修复警报(33%)：通过重新调整阈值参数来修复监控器的错误；
3. 更好的仪表板(13%)：加强监控仪表板以跟踪低流量场景。

与5.1节中提到的自动化测试建议类似，有几种类型的测试经验：

1. 监视器测试(13%)
2. 系统测试(33%)
3. 配置测试(20%)
4. 场景测试(20%)
5. 版本测试(27%)：在升级到新的版本时，通过运行适当的测试用例进行兼容性检查。

Behavioral change

OCE们提到了事件管理和工程实践中的各种行为变化，以使服务具有弹性。我们将其大致分为4种类型：

1. 部署实践（33%）：运维人员在敏感环境中推出配置变更或证书时应谨慎行事；
2. 编程实践（34%）：开发人员应仔细阻止所有不支持的场景以避免对客户的影响；
3. RCA和缓解实践（22%）。在敏感环境中执行任何回滚或重启操作之前，OCE应该仔细检查他们是否有正确的权限；
4. 监控实践（11%）：OCE应该关注健康仪表盘，并在改变事件严重性级别之前重新评估容量。

Training and documentation

改进文档的建议如下：

1. 更好的TSG（50%）：应该包括具体的遥测或测试过程的细节，并且在重大变化后应该仔细审查；
2. 更好的事后报告（17%）：消除事后报告之间的依赖性，以快速从历史上类似事件的事后报告中获得有用信息；
3. 更好的API文档（33%）：改进某些现有工具的文档，以帮助合作伙伴团队。

Automated mitigation

建议减少人工干预，建立缓解自动化流程：

1. 证书更新（30%）：证书轮换和更新应该完全自动化，没有任何人工干预；
2. 审计（20%）：证书更新、测试和验证应该定期跟踪和审计；
3. 流量故障转移（20%）：自动化流量管理器对后端节点进行健康检查，并在移除不健康的节点后重新安排流量；
4. 节点扩展（30%）：经常重新评估容量，并建立自动化扩展机制，以便更快地缓解。

External coordination

1. 更好的协调（56%）：在推出突破性变化时，与将受到影响的合作团队建立明确的沟通渠道，或在适用的情况下消除依赖性（例如，消除认证服务依赖，直接获取客户端令牌）；
2. 更好的上报机制（escalation）（44%）：需要更好的上报机制来主动联系合作伙伴团队（例如，通过提前宣布中断或设计自动上报方法）。

6 MULTI-DIMENSIONAL INCIDENT ANALYSIS

让我们考虑一个客户报告的事件，它归因于最近的代码修改。虽然该代码变更没有错误，但由于缺少一个空参数检查，它暴露了一个不兼容的错误。然而，由于服务的相应监控器中的一个不相关的错误，警报并没有启动。这导致了代码被部署到生产环境。鉴于此，值班工程师无法回滚代码的改变，而是应用了一个热修复（hot-fix）来缓解这个问题。

这是一个复杂的决策过程，将根因、依赖项、检测失败等因素联系起来，决定缓解步骤。为了理解这些复杂因素，在本节中，我们通过分析相关因素的分布，从一个多维的角度来看待事件。我们使用Chi-Square检验来确定两个定性因素（比如说根本原因和缓解措施）之间的关联是否具有统计学意义。

Detection Failure and Root cause

在图9中，我们观察与检测失败相关的根本原因是什么。在这里，我们观察到，在没有监控器的情况下，有70%的事件与代码bug有关。同样，在遥测覆盖率低的事件中，有54%的事件也是由代码bug引起的。这表明，由于代码变更引入的bug，在监测和检测服务方面存在固有的困难。 因此，在上新版本之前对代码变更进行重要的测试，而不是依赖监测来维持服务的可靠性。

此外，我们发现现如今的监视器无法检测涉及到服务范围之外的依赖关系的事件。42%的监控器无法检测的事件与依赖性服务的故障有关。这表明现如今的监控器在服务的代码库中是本地化的，也就是说，缺乏全局视角。对于大规模的云来说，未来的监控器将需要捕获跨服务的依赖关系，并将遥测数据传播到所有交互的服务，以便更快地进行根源分析。例如，相关的监控器可以连接起来，并将有关失败服务的消息传递给对方。

Root Cause and Mitigation

在图10中，我们分析了每种类型的根本原因使用了哪些缓解策略。如图所示，回滚是最流行的缓解策略之一。特别是，我们观察到47%的配置错误通过回滚得到缓解，而通过实际的配置修复得到缓解的只有21%。从图3(b)中，我们可以将此归因于回滚比配置修复花费的时间要少得多。然而，这也表明，配置错误主要出现在对以前正确配置的更新中，而不是在生产中由于工作量、流量和依赖性等外部变化而意外失效的配置。因此，如果进行测试，很大一部分错误配置可以被识别。处理错误配置的一个方法是配置验证——检查配置值的指定属性。虽然很有用，但它与服务源代码的动态逻辑是脱节的。另一个解决方案是传统的软件测试。因此，我们需要开发更系统的配置测试方法，不仅要验证值，还要测试可能导致意外服务行为的语法/语义上有效的配置变化。

另外，我们发现，有30%的部署错误事件通过配置修复得到缓解。 我们认为，更好地监测证书到期和自动更新证书的机制可以提高可靠性。最后，我们观察到，在50%的数据库和网络故障中，客户服务依赖于外部团队来修复故障的基础设施。

Mitigation Failure and Lessons

从图11中，我们看到，在21%的案例中，改进文档和OCE训练可以减少事件缓解的手动工作。在这里，我们认为有两种方法：(1) 质量测试：经常使用各种指标监测这些文档的质量，如可读性、停留时间、缓解时间、更新性等；(2) 自动化：将这些人工TSG自动化为工作流（如jupyter笔记本），可以用最小的干预来执行。

对于因文件和程序不完善而导致的缓解失败，我们发现有25%希望在监测方面有所改进。我们可以通过提供监控器跨服务依赖性的全局视图和引入审查监控器阈值的程序来改善这一点。为了缓解部署延迟，如图11所示，我们看到在25%的情况下，部署服务的一些自动化缓解步骤（例如，证书轮换、流量故障转移、自动缩放等）大有益处。因此，这促使未来对自愈云的研究，以动态地管理工作负载变化的基础设施和其他部署活动，如证书管理。这里需要关注的一个关键方面是将服务监测与执行基础设施和部署行动的自动化工作流程联系起来。

Detection Failures and Automation

在图12中，我们查看了由值班工程师确定的自动化机会与影响事件主动检测的检测失败的分布情况。在这里，值得注意的是，57%的监控器无法检测的事件与改进人工测试而不是改进自动警报（23%）有关。同样地，53%的没有监控器或缺乏遥测覆盖的事件也与改进的人工测试有关。 因此，我们认为自动化测试工具可以大大帮助减少人工测试的负担，并增加测试的使用，而不是监测。

findings

⭐️Finding#1: While 40% incidents were root caused to code or configuration bugs, a majority (60%) were caused due to non-code related issues in infrastructure, deployment, and service dependencies.

⭐️Finding#2: Although 40% incidents were caused by code/configuration bugs, nearly 80% of incidents were mitigated without a code or configuration fix

⭐️Finding#3: Mitigation via roll back, infrastructure scaling, and traffic failover account for more than 40% of incidents, indicating their popularity for quick mitigation.

⭐️Finding#4: Even among incidents triaged to external teams, only a minority 17% of incidents were mitigated using a code/configuration fix.

⭐️Finding#5: The time-to-detect code bugs and dependency failures is significantly higher than other root causes, indicating inherent difficulties in monitoring such incidents.

⭐️Finding#6: Manually fixing code and configuration take significantly higher time-to-mitigate, when compared to rolling back changes. This supports the popularity of the latter method for mitigation.

⭐️Finding#7: ≈17% of incidents either lacked monitors or telemetry coverage, both of which result in significant detection delays.

⭐️Finding#8: While complex root causes can affect time-to-mitigate, 30% of incidents had mitigation delays even after identifying the root cause due to poor documentation, procedures, and manual deployment steps.

⭐️Finding#9: Improving testing was a popular choice for automation opportunities, over monitoring, indicating a need to reduce incidents by identifying issues before they reach production services.

⭐️Finding#10: While improving monitoring/testing accounts for majority of the lessons learnt, a significant ≈20% feedback indicated improved documentation, training, and practices for better incident management and service resiliency.

⭐️Finding#11:70% of incidents with no monitors were root caused to code bugs, i.e., it is inherently difficult to monitor regressions introduced due to code changes. ⇒ For code changes, we should improve testing rather than relying on monitoring.

⭐️Finding#12:42% of incidents that cannot be detected by monitoring today, were associated with dependency failures ⇒ There is a need to introduce/increase monitoring coverage and observability across related services.

⭐️Finding#13:47% of configuration bugs mitigated with a rollback compared to a lesser 21% mitigated with a configuration fix; i.e., A large portion of misconfigurations are due to recent changes ⇒ They can be identified by rigorous configuration testing.

⭐️Finding#14:21% of incidents where manual effort delayed mitigation, expected improvements in documentation and training. ⇒ Just like with source code, we need to design new metrics and methods to monitor documentation quality. Also, automating repeating mitigation tasks can reduce manual effort and on-call fatigue.

⭐️Finding#15: 25% of incidents where mitigation delay was due to manual deployment steps, expected automated mitigation steps to manage service infrastructure (like traffic-failover, node reboot, and auto-scaling).

⭐️Finding#16: In more than 50% of incidents that monitors could not detect, OCEs expected an improvement in manual testing over automated alerts (23%). ⇒ Strongly enforcing that a “Shift Left” practice with automated tools to aid testing can reduce on-call effort and expenses – both customer impact and engineering.