快准稳：值得所有运维学习的SRE故障处理经验

在网络上关于 SRE 的讨论中，故障相关的内容比比皆是，但关于故障发生时的应急处理过程的详细讨论却寥寥无几。然而面对故障，故障指挥官一定面临着较大的压力，需要快速、正确地处置故障，应对内外部的挑战。在这篇文章中，我们将重点探讨故障指挥官在故障处理过程中的具体行动思路。

值得注意的是，本文总结了作者在担任故障指挥官时，对故障感知、故障定级、故障处理以及故障恢复等环节的经验和心得，而并未涉及如何预防故障或进行故障复盘的内容。

1、故障感知

众所周知：故障一般来自两个部分的输入：监控系统和用户（客户）报障。

• 首先，监控系统在SRE工作中起着至关重要的作用。监控系统可以实时监测系统的业务指标和性能参数。当系统出现异常或达到预设的条件时，监控系统会自动触发告警并发送给SRE团队。这些告警包括基础设施监控（如服务器负载过高、网络延迟异常、存储空间不足等等），也包括业务层面的监控（如接口成功率、页面白屏化/JS错误等）。

• 其次，客户或用户的报障也是故障的输入来源。当客户或用户在使用系统时遇到问题或异常情况，他们通过电话、即时通信、工单等各种渠道向技术支持团队报障。我们可以通过程序去监控投诉关键字、重点客户客情，当有客情出现时，SRE可以进行故障排查和解决。

涉及监控系统的实现细节，不在此赘述。

2、故障的定级

在处理故障时，首先需要判断故障的影响范围，即确定是否构成故障。这可以通过以下几种方式进行判断：

• 系统维度判断：监控系统提供了实时的系统指标和性能参数，故障指挥官在收到告警后，可以通过监控数据来判断系统是否真实出现异常。例如，关键接口返回码成功率严重下降，关键接口耗时严重上升，由相关的接口指标数据来定义故障的级别。

• 用户维度判断：如果多个用户报告了相似的问题，根据报障的用户数量来判断、根据监控系统所体现的用户维度的数据，判断该故障可能影响了多少客户，从而定义故障的级别。

• 重点客户的反馈判断：重点客户通常是对系统稳定性和性能要求较高的客户。也是业务的重要收入来源， 他们的反馈对于判断故障的影响范围非常重要。如果重点客户反馈了故障或异常情况，可以根据客户的级别、受影响的业务规模、客情反馈情况等来定义故障的级别。

3、故障处理团队的组织

• 判断要卷入谁：
• 模块组件相关性：根据故障的性质和影响范围，确定与故障相关的模块或组件。然后卷入与这些模块或组件直接相关的团队成员，以确保有专业知识和经验来处理故障。
• 最近的可疑的变更团队：如果故障与最近的变更点时间吻合，建议卷入该变更团队。
• 历史出现过相似的问题：历史上出现过相似的问题，可以将当时处理过故障的人员卷入到会议。

• 内部面向客户/用户相关人员：如果故障影响了重要客户或用户，可以单独拉取一个群组来同步与这些客户或用户相关的问题。这个群组应该包括与客户或用户关系密切的团队成员，以便及时响应和解决他们的问题。

• 会议中的挑战：在组织故障处理群组时，确保成员有效沟通和协作至关重要。然而，刚开始拉群时可能会面临以下挑战：

• 信息缺乏同步：由于故障突然发生，每个被拉入群组的成员可能会询问当前问题的情况。故障指挥官可能会需要重复当前的情况。

• 建议在拉入会议时同时创建一个工作群（如企业微信群、微信群），并在群里发布公告，公告里详细说明故障的影响范围、受影响的业务以及故障发生的时间。以免入会人员重复询问。

• 信息不够聚焦：在故障处理群组中，有些技术人员可能会陷入讨论一些细节或不太关键链路的问题。

• 在这种情况下，故障指挥官的角色至关重要，需要确保抓住重点主线：果断打断故障恢复主线无关的问题讨论（如果是疑似问题根因但未确认，可以组织相关人员到分会场讨论），优先恢复受损的业务，而将其他问题放在次要位置。如果故障受损的业务较多，可以考虑根据影响范围、程序等因素进行排序，以便更有效地处理故障。

4、故障的处理

故障发生后，需要指挥、协调相关团队进行及时止损及恢复：

• 讨论制定恢复措施：快速恢复的方法包括流量调度、流量限制、业务降级、紧急扩容、组件重启、版本回退、紧急补丁、数据恢复等。可以根据系统的能力、日常的演练结果等来综合决策。

• 流量调度：业务具备多地/多SET部署能力，当某一部分模块有故障时，及时调度到其他地域/SET来恢复业务

• 故障隔离：由于IaaS/灰度模块等局部原因造成业务故障时，可以考虑将相关设备/模块剔除以恢复业务。
• 全局限流：故障由于业务流量增长引起，可以考虑在接入层、服务网关等组件上进行限流。限流的阈值可以参考历史峰值或者压测验证过的数值。
• 紧急扩容：故障由于业务流量增长引起，在资源足够、能快速扩容的情况下，可以紧急对业务模块进行扩容。需要注意的是，如果用户或业务调用方有大量的重试行为，此时需要配合限流措施。
• 组件重启：某些组件可能出现了故障，由于某些原因造成了CPU Hang死或者内存驻留，导致系统运营缓慢或业务逻辑错误，可以采用重启来恢复业务。
• 版本回退：当确认故障是由于业务发版引起，可以采用版本回退来恢复业务。
• 紧急补丁：故障因为触发到业务设计上的缺陷而无法使用以上手段恢复。需采用紧急补丁修复。
• 数据恢复：由于问题涉及到数据损坏或丢失，需要进行数据恢复。
• 其他：所采取的其他恢复方案

• 进行恢复措施评估：

• 措施是否得力、有效。恢复业务为第一要务，该措施是否能够有效恢复业务。

• 措施是否相对较优，如果评审中有异议，提出并讨论优化方案。

• 如果恢复方法对业务有影响，卷入利益相关方评估影响是否能够接受。

• 考虑相应的回退措施。

• 及时决策：由于故障对客户的业务有损，所以及时决策非常重要，最小化故障时间有利于减少损失。故障指挥官需要有相应的担当，及时决策相关处置措施的实施。如果涉及到业务流程相关，需要提前考虑紧急变更的业务流程。

• 实施恢复措施：确定恢复措施后，经过关键人员审批后，及时实施到业务环境。如果措施未生效，则需要决策回退。

• 观察判断业务是否恢复：观察关键的监控指标是否恢复，客户的反馈是否消失。

5、故障信息的透明与同步

为了有效向各相关团队同步业务进展，保持统一的口径，需要考虑以下几点：

• 故障由谁来同步比较好：
• 内部：建议由故障指挥官来进行同步，也可以由故障指挥官指派相关的同事来准备文字素材，故障指挥官整合确认后同步。所以对故障指挥官有一定的要求：故障指挥官应熟悉IT系统的基础理论，并对应用系统技术架构有积累，具备严谨的逻辑思考能力，以确保故障形成的原因经得起推敲与挑战。
• 有关是否需要向客户同步进展：建议由故障指挥官（或故障指挥官指派相关人员）提供素材，同步给运营团队或TAM（技术支持经理）来主导，相关对客团队来准备合适的话术，以确保信息清晰易懂。

• 故障信息同步需要包含的内容：故障同步时，因为内部和外部的受众和需求不同，信息口径有一些差异，主要的差异点是如下：

• 内部同步：主要面向组织内部的成员，包括技术团队、管理层和其他相关人员。确保团队成员了解故障的详细情况、进展和解决方案，以便有效地参与故障处理和提供支持。通常会涉及更多的技术细节和操作细节，以满足团队成员对故障处理的需要。

• 外部同步主要面向外部的利益相关者，包括客户、渠道合作伙伴、和其他相关方。信息要足够准确、透明，以便用户了解故障的影响和恢复进展。通常需要使用更简洁、易懂的语言，避免过多的技术细节，以让外部用户感知上透明、可控。

因此，为了满足内部和外部受众的不同需求，故障同步时对不同的内外受众需要采用不同的口径和信息呈现方式。

• 故障指挥官需要在内部同步的内容如下：

• 故障开始时间：什么时候开始的（可以根据监控系统的指标变动时间，极个别情况，监控系统未体现的话也可以根据客户反馈的时间）

• 影响范围：影响了哪些功能，哪些客户，多少设备量、业务量等

• 预计恢复时间：预计什么时候可以恢复，一般在这里要同步一个初步预估的时间。后续可以随着处理的进展来刷新。

• 当前进展情况：怀疑方向是什么，谁在处理，当前处理的进展如何，一般可以先概括一下处理的整体方案，整体方案一共有几步，目前进展到哪一步了。预计什么时候可以执行完。

• 需要哪些帮助：有时候这一点尤其重要，当前执行预案的时候，碰到了什么棘手的问题，需要什么资源。

• 故障指挥官需要向外部同步的信息如下：

• 故障的现象：发生了什么问题，该故障的触发条件是什么。

• 问题原因：故障原因是否已经查明，如果已经查明，简洁地描述原因。

• 问题处理的进展：对故障进行了怎么样的处理，如果有多个恢复止损的步骤，目前进行到第几步了。

• 并预计恢复时间：预计什么时候能够恢复。

• 规避方法：如果在用户侧有办法临时规避，可以告知规避方式。例如业务切换、降级等。

故障恢复后，可以向各相关方推送相关的故障恢复信息。可以参考包含以下信息：

• 内部同步

• 故障现象

• 影响范围

• 故障原因

• 恢复时间及恢复方法

• 外部同步

• 故障现象

• 故障时段

• 官方的故障原因

总 结

多项首批评估结果揭晓！2023年12月15日，中国信通院 DevOps、AIOps 系列标准最新评估结果重磅发布！

点个“在看”，一年不宕机