导读

良好的架构有助于最小化或避免故障的影响。运营实践定义了如何处理不可避免的事故并快速恢复。但事后呢？如何确保真正的根本原因已被追查，并且已计划实施有效的预防措施？如何将每一次事故转化为学习机会？共同责任模型和第三方软件供应商在其中扮演什么角色？本次讨论将分享关于根本原因分析和纠错（COE）的思维模型和经验，以便您能在自己的组织中推动有效的实践。

演讲精华

以下是小编为您整理的本次演讲的精华。

大家下午好。我们今天来讨论一下在亚马逊云科技发生事故时的处理流程和事后分析。我们有两个主要目标。首先，作为亚马逊云科技的客户，你们可能偶尔会遇到亚马逊云科技端的事故，并需要使用亚马逊云科技健康状况仪表板，与亚马逊云科技支持团队合作。我们希望为你们提供一些背景信息，让你们了解这些事故幕后发生的情况。

其次，你们很可能也为自己的客户提供服务，因此可能会遇到自己的事故。通过分享我们的流程，你们可能会获得一些宝贵的经验，并应用到自己的业务中。

演讲者承认，许多与会者都曾经历过事故，强调这种情况的普遍性。他介绍了Gavin，一位在亚马逊云科技工作了13年以上的高级主管工程师，曾在负载均衡、DNS和最近的应用程序恢复控制器团队工作。值得注意的是，Gavin是亚马逊云科技的核心领导者，相当于事故指挥官。

Giorgio则在亚马逊云科技支持组织工作，他们的团队在事故期间与演讲者的团队密切合作。演讲者所在的团队专注于缓解问题，而Giorgio的团队则负责了解发生了什么、与客户沟通，并确保客户能够尽快恢复正常运营。

本次演讲的议程如下:首先，他们将讨论从事件触发到解决的整个流程。接下来，他们将介绍事后分析或回顾阶段，包括定义和实施行动项目。最后，他们将讨论如何将一个团队对影响他们的事件的事后分析与整个组织共享，将其转化为全公司的学习机会，而不仅仅是公司的一小部分。

关于第一阶段，即事件本身，演讲者解释说，亚马逊云科技的服务团队已经设置了指标、警报和合成监控(金丝雀)，以检测问题。此外，亚马逊云科技还采用了聚合警报，以识别同时影响多个服务的事故。这种方法旨在协调各方的努力，避免多个团队进行重复的调查。

亚马逊云科技还会跟踪客户驱动的指标，如流量趋势和支持联系，这些可能会指示潜在的问题。演讲者分享了一个轶事，说在2008-2009年，一位工程师在一个周末就构建了一个监控整个亚马逊云科技的仪表板，这成为了亚马逊云科技对其服务可见性的核心。

仪表板显示了每个服务的关键指标，使亚马逊云科技能够识别单一服务问题(通常由相应团队处理)或多服务问题(触发事故响应团队的协调响应)。

当事件发生时，亚马逊云科技通常会在几分钟内检测到，并自动启动事故响应主管、支持团队、受影响服务、核心领导(如果严重)和一组“常见嫌疑人”(服务所有者)。目标是通过协调服务端的工作来尽可能缩短恢复时间，同时亚马逊云科技支持端则专注于与客户沟通并提供解决方案指导。

演讲者强调，在事故期间，并行调查而不是串行调查的重要性。如果出现多个假设，团队应该同时探索，而不是过早收敛到单一假设。

由召集人和事故响应团队主导的技术电话会议，优先考虑缓解问题而非根本原因分析。会议礼仪至关重要，例如静音以避免背景噪音。亚马逊云科技使用视频会议系统来识别并静音参与者(如有需要)。可能会为团队建立单独的电话会议，以深入讨论复杂问题。

技术票证是亚马逊云科技票证系统中的一个日志，用于不可变地记录事件期间的观察结果和采取的行动。参与者会经常被提醒在票证中记录他们的见解和假设。

亚马逊云科技支持团队在事故期间的目标是监控案例趋势、阅读客户的影响报告，并验证内部调查与客户体验是否一致。外部通信，包括起草和定义公开更新的内容，都是通过这个团队协调的。

会向客户提供恢复指南，建议他们可以采取的缓解措施，例如停止并替换实例、远离受影响的可用区，或排除故障资源。团队还会分享通用的最佳实践，并为特殊边缘案例与客户配对工程师。

指挥中心工具提供了一个集中的视图，显示正在进行的事件，包括元数据、案例矩阵(支持案例和社交媒体提及)以及概览，让支持工程师能够快速了解情况。

在事件通信方面，亚马逊云科技力求在准确性、为客户提供足够详细信息以做出明智决策和速度之间取得平衡。他们最初优先考虑准确性和速度，一旦确信事件正在发生就立即进行通信。更加个性化的仪表板有助于将通知针对性地发送给受影响的客户。

亚马逊云科技正在探索在开始调查潜在问题时就通知客户的选择，让客户能够将这一信号纳入他们的监控流程。

内部通信分为两个流:一个是高度技术性的，针对熟悉内部服务名称和术语的团队;另一个是定期发布的公告，以更易于理解的格式总结情况，供支持客户的一线团队使用。

对外，亚马逊云科技会通报服务状态、提供如何应对的建议，并定期更新计划和潜在根本原因。

回到技术电话会议，一旦发现问题，重点就转移到缓解策略上。常见的方法包括远离故障(例如，从机群中移除有问题的主机)、回滚最近的更改、重启服务(即使没有已知的根本原因)以及主动扩大容量。

在缓解问题后，亚马逊云科技会与支持团队合作，验证客户是否认为问题已经解决。他们会评估再次发生的风险，暂停部署管道和变更管理流程，并寻找其他可能受影响的系统，尤其是在其他区域。

会实施短期修复措施，例如为新发现的指标添加额外的警报。会为根本原因分析分配COE(错误纠正文档)，并保留相关数据或日志以供调查。

事后分析阶段涉及审查和事后分析(COE)，遵循以下几个原则。首先，亚马逊云科技以同理心对待，为受影响团队创造一个安全的空间，让他们能够分享细节而不受指责。同理心还包括了解团队在事件期间的知识和背景，以做出适当的改变。

如果在事故期间发现了改进机会，COE可能会由多个团队共同进行事后分析。

COE有几个目的:让最接近失败组件的团队深入了解系统、为新团队成员提供学习机会、在整个组织内分享经验教训、通过彻底了解问题并实施有力的预防措施，重新赢得内部或外部客户的信任。

COE的结构包括影响总结(内部和外部视角)、根本原因分析、观察和经验教训以及行动项目。特别关注事件的检测(是否足够快地检测到)、事件期间的可观察性以及未来检测类似问题的能力。

内部和外部依赖关系也受到密切关注，以确保它们按预期使用和执行，并且考虑了它们的失效模式。

演讲者对“5Why”根本原因分析技术持有复杂态度，建议不要过于严格地遵循。他建议采用树状方法，同时探索多个潜在原因分支，而不是线性分析。

演讲者举了一个例子，说明了线性“5Why”方法的局限性，以及进行更全面分析(考虑配置错误的健康检查、负载均衡算法和可能导致观察到行为的设计决策等因素)的好处。

在根本原因分析之后，亚马逊云科技会通过RCA(根本原因分析)或RFO(征求意见)文档，即亚马逊云科技事件分析，传达调查结果。指导这些文档的原则包括:

1.           关注客户在事件期间的视角和体验。

2.           在质量和速度之间取得平衡，一旦对行动和高级行动项目及其截止日期有了深入了解，就尽快(几天内)交付RCA。

3.           尽可能简化和抽象技术细节，但不影响故事情节或客户对理解的需求。

4.           将RCA视为重新赢得客户信任的机会，通过彻底了解问题并概述适当的预防措施。

RCA产生的行动项目分为三类:

1.           短期行动，在数小时内交付，重点是防止立即复发并缓解运营负载的增加(例如，调整警报灵敏度，更改运行手册)。

2.           中期行动，在数天、数周或数月内交付，涉及更加稳定、通常完全自动化的解决方案，以防止类似的触发因素导致相同的事件。

3.           长期行动，推动系统性变革，彻底消除根本原因。这些行动平衡了为客户和依赖项提供渐进式改进，以及向新服务进行更具破坏性的重新发明或迁移。

亚马逊云科技强调在交付完美的长期解决方案与满足客户期望的现实时间表之间找到正确的平衡，因为长期的努力可能会导致解决现有系统问题的停滞。

在实施行动项目的过程中，亚马逊云科技保持灵活性，承认随着新信息的出现，计划可能会发生变化。然而，他们努力捍卫已承诺的时间表，只在必要时进行小的调整。亚马逊云科技通过“游戏日”来验证修复措施的有效性，模拟原始触发因素以确保预防措施按预期工作。

为了在整个组织内扩大学习成果，亚马逊云科技每周举行一次“亚马逊云科技范围内的运营会议”，由高级领导、首席工程师和杰出工程师出席。在此次会议上，组织内的两到三个COE将被详细审查，以促进跨团队反馈和知识共享。

该会议为初级工程师提供了一个安全的空间来展示他们的COE，培养了一种无指责的学习环境。这些会议的成果包括:

1.           教育与会者并建立机构知识。

2.           确定需要在多个团队中实施集中化变更或计划的组织范围内的问题。

3.           推动共享平台或工具的集中化变更，这可以在不需要单个团队进行破坏性更改的情况下产生广泛影响。

4.           加强和规范指导亚马逊云科技实践的运营原则或原则。

演讲者分享了基于过去事故的学习而编纂的原则示例，例如确保故障不会影响多个区域、在客户之前检测故障以及自动化扩展流程。

在某些情况下，亚马逊云科技基于事故的经验教训开发了新的服务或工具。例如Amazon Route 53(DNS服务)、Elastic Load Balancing、Amazon Certificate Manager和Zonal Shift(用于将流量远离可用区)。

演讲者承认在代码中正确处理重试的重要性，分享了最初实施无效重试策略的个人经历，这可能会通过过度重试而压垮挣扎的服务，从而加剧问题。亚马逊云科技已经将其方法发展为“自适应重试”，它根据只有在重试成功时才会补充的预算来限制重试次数，从而防止重试风暴压垮失败的服务。

该讲座的主要要点包括:

1.           在事故期间迅速召集领导和额外资源，以加快恢复。

2.           尽快与客户沟通，即使最初只有有限的信息。

3.           在活跃事故期间，优先考虑缓解措施而非根本原因分析。

4.           在整个组织内扩大事故的学习成果，以防止再次发生。

5.           以同理心审查事故，了解当时的背景和决策。

6.           建立明确的原则或原则来指导运营并使团队保持一致。

总之，演讲者全面概述了亚马逊云科技在事故处理、事后分析和跨组织扩大学习成果方面的方法。他们强调了协调、沟通、同理心、持续学习以及建立指导原则的重要性，以不断提高运营卓越性和客户信任度。

我们正处在 Agentic AI 爆发前夜。 2025 亚马逊云科技中国峰会提出，企业要从 " 成本优化 " 转向 " 创新驱动 " ，通过完善的数据战略和 AI 云服务，把握全球化机遇。亚马逊将投入 1000 亿美元在 AI 算力、云基础设施等领域，通过领先的技术实力和帮助“中国企业出海“和”服务中国客户创新“的丰富经验，助力企业在 AI 时代突破。