“谈故障色变”到有章可循：美图 SRE 故障应急与复盘实践

1. 石鹏(东方德胜)

2. 讲师介绍石鹏(东方德胜) 高级运维经理从业十余年，一直从事运维相关的工作。 2016年加入美图公司，现任美图SRE负责人，目前整体负责美图公司线上服务的稳定性保障工作。曾多次参与或主导过美图公司多项基础设施、运维架构的调整和改造，在监控、灾备、故障管理、稳定性运营等方面有一定的经验积累和行业输出。致力于推广SRE、稳定性运营相关的理念及实践，编著有「SRE系统建设指南」图谱，参与过业界多个SRE、DevOps 相关案例集/期刊/标准/白皮书的编纂或供稿。业界多个技术峰会的分享嘉宾、金牌讲师或出品人， SRE 精英联盟成员。中国信通院「稳定性保障实验室」认证专家，应急工作组组长。

3.

4. 你是否会“谈故障色变”？遇到故障慌不慌？为什么？

5. 不慌会慌

6. 洞察本质，掌握规律体系建设，主动出击目录有章可循，有条不紊吃堑长智，举一反三或许是最后一次分享 AI含量超低的这个主题了哈哈

7. 简介：深刻洞察故障的本质，分析和理解故障发生的规律。学习和总结稳定性保障相关的框架和方法，进而指导展开一系列的工作。

8. SRE的核心职责与企业发展的关系 + 安全稳定性安全生产让企业活着 + 效率 × 成本降本增效让企业获得优势

9. 构建「大框架」：可靠性工程全生命周期

10. 稳定性运营的「全景图」 Pre-MTBF MTTI MTBF MTTK MTTF MTTV MTTR Post-MTBF MTBF 故障改进故障预防故障发现故障定界/定位故障恢复灾备预案监控告警日志分析故障隔离故障复盘容量评估常规巡检监控分析容灾切换改进验收架构设计用户反馈链路跟踪服务限流故障模拟监控覆盖舆情感知场景复现服务降级混沌工程持续交付智能预测根因定位异常熔断周边清查建设/演练/OnCall 应急响应复盘/改进/OnCall

11. 建立对故障的正确认识异常是常态 • 系统失效/异常的必然性 • 所有的干预手段都有代价为何会发生常见的原因 • 单机故障 • 配置变更 • 负载变化 • 强依赖 • 人为错误 • 时延增加 • 资源耗尽 From：FaceBook – Fail at Scale

12. 稳定性的度量&工作目标常用度量指标：MTTR ➢ 细化MTTR MTTR 平均恢复时间平均识别时间平均定位时间平均恢复时间平均验证时间 MTTI MTTK MTTF MTTV 降低 ➢ 我们的目标 MTTR 平均恢复时间 MTTI MTTK MTTF MTTV

13. 稳定性的度量&工作目标常用度量指标：MTTR ➢ 如何达成目标 MTTR 平均恢复时间平均识别时间平均定位时间平均恢复时间平均验证时间 MTTI MTTK MTTF MTTV 多管齐下 MTTI 工具赋能 MTTK 完备预案一键应急紧密协作 MTTF 自动校验 MTTV

14. 稳定性的度量&工作目标关于SLO的设立合理分级与差异化与业务价值的联动机制 ❖不同业务场景需要设置不同的SLO目标 ❖核心业务与非核心业务的SLO应区别对待 ❖用户体验关键路径应设置更高的SLO要求 ❖建立分级服务矩阵，明确各级别SLO边界 ❖SLO应与业务KPI建立明确的联系与映射关系 ❖量化SLO违规对业务影响的具体损失 ❖建立SLO违规的快速响应与升级机制 ❖定期评估SLO对业务实际贡献，避免过度投入两种常见的「可用性」定义方法这种方法关注服务在特定时间段内的运行状态，通常用于传统IT系统 SLO 指标完善可衡量 SLO文化与团队协作 ❖单一可用性指标不足以全面反映系统稳定性 ❖应结合延迟、成功率、吞吐量等多维度指标 ❖所有SLO必须是可量化、可监测的 ❖设立「错误预算」作为创新与稳定的平衡机制 ❖技术团队与业务团队共同参与SLO制定过程 ❖建立跨团队的SLO共识与责任共担机制 ❖SLO达成情况应作为团队OKR的重要指标 ❖持续改进SLO体系，适应业务发展与技术变化和基础设施服务。这种方法关注服务请求的成功率，更适合微服务架构和现代分布式系统，能更准确反映用户体验。

15. 《SRE实践白皮书》白皮书中的大框架汇集了多家企业的内部优秀实践，推荐参考。故障全生命周期视角 ➢ 故障前：稳定性建设、OnCall 值守 ➢ 故障中：应急响应、故障恢复 ➢ 故障后：故障复盘、优化改进异常是常态 MTTR – 细化拆解系统失效异常是自然规律，所有的干预手段都有代价。 SLO – 常见的两种定义 ➢ ➢ ➢ ➢ MTTI MTTK MTTF MTTV ➢ 按照不可用时长 ➢ 按照异常请求占比

16. 简介：从被动应对到主动出击，体系化地推进稳定性建设。

17. 未雨绸缪之「体系化建设清单」稳定性运营体系可观测性体系高可用体系应急体系 OnCall轮值监控告警覆盖灾备体系建设应急预案常规巡检监控报表建设容量规划预案演练重点节点保障全链路监控柔性架构设计一键应急例行运营机制监控报表自动化故障自愈混沌工程运营数据智能分析拓扑关联分析流量智能调度预案智能推荐系统风险自动识别故障根因推荐故障自动转移系统智慧应急指挥中心

18. 未雨绸缪之「稳定性运营体系建设」 OnCall轮值常规巡检重点保障运营分析风险识别分组排班基础设施信息收集例行分析容量风险人员互备业务指标目标对齐信息汇总安全隐患明确职责业务服务前置准备数据洞察违规变更值班复盘重点资源重点值守运营报告异常趋势

19. 未雨绸缪之「可观测建设」故障开始 Metrics, tracing, and logging 故障恢复故障排查/处理的主要过程 Metrics Traces Logs ➢ 告诉我们有没有故障 ➢ 告诉我们故障在哪里 ➢ 告诉我们故障原因 ◆监控告警 / 常规巡检 ◆链路跟踪 ◆日志分析 / 事件关联 ◼ ◼ ◼ ◼ 告警通知监控大盘北极星指标基础指标 ◼ ◼ ◼ ◼ 调用链路 APM NPM RUM ◼ ◼ ◼ ◼ ◼ 系统日志组件日志应用日志 Profile日志变更事件

20. 未雨绸缪之「可观测建设」业务监控大盘样例全域SLO大盘单域名SLO报表业务拓扑数据事件数据图文告警-样例

21. 未雨绸缪之「应急预案及预案演练」服务梳理预案梳理沙盘推演预案落地预案演练请求链路多级预案部门协作文档输出无损演练分段分层各个击破 Case推演功能实现轻损演练周边依赖智能调度头脑风暴架构适配单点演练架构风险柔性设计互相挑战工具建设组合演练

22. 未雨绸缪之「SRE工具箱建设」

23. 未雨绸缪之「SRE工具箱建设」 • 能力抽象动作 • 动作注册 • 编排动作预案 • 串行/并行 • 依赖逻辑 • 预案绑定场景 • 多级预案

24. 有章可循有条不紊

25. 故障应急之「原则与建议」每个公司大概都有一支「消防队」统一目标：恢复优先，问题定界 > 根因定位稳定心态：SRE一定要冷静，不要慌流程机制：故障升级、War Room 故障现场：组织协调约定、信息通报机制

26. 故障应急之「机制流程约定」 OnCall接警 / 响应启动影响初判 / 信息周知结构化的事件响应通过结构化的故障应急响应流程框架，可以实现故障处理的标准化、流程化(或自动化)、制度化。排查处理 / WarRoom 故障恢复 / 故障升级故障通报(无论恢复与否) 可以有效降低MTTR、提高故障处理效率，实现组织全层级的响应支持、避免资源瓶颈，规避“响应真空”、降低因故障处理不当带来的影响。

27. 故障应急之「现场指挥」科学的现场指挥体系角色定义理性客观识别噪声职责分工信息畅通临场决策矩阵匹配动态调整有效执行组织结构与角色体系 ➢ 明确角色与职责，确保每个参与者定位清晰 ➢ 矩阵匹配，确保关键能力与关键职能的最优组合指挥灵活性与适应机制 ➢ 符合OODA循环(观察-判断-决策-行动)，快速迭代 ➢ 提高组织应对不确定性和复杂场景的韧性，降低因固化流程造成的响应延迟或失效认知管理与决策框架 ➢ 警惕“认知偏差”，防止决策被干扰信息误导 ➢ 结构化决策流程，在高压下维持“功能性理性”，避免瘫痪

28. 故障应急之「常见故障场景及常见手段」服务SLA下降请求超时资源链接失败监控告警分析日志分析链路跟踪关联事件分析预案匹配执行故障单元隔离流量切换软硬件重启资源扩容变更回滚撤销内外部依赖异常单Pod异常系统资源抖动 CDN线路异常用户区域性异常业务流量突增

29. 故障应急之「非常规模式及处置方法」大规模雪崩处置手段 • 降级、限流、熔断基建大面积故障 • 重启、回滚、重建 • 设备替换 AZ级故障 • 容灾切换 Region级故障核心硬件失效稀缺资源耗尽安全攻击操作宗旨 • 确认影响、搞清状况 • 明确优先级 • 清晰动作依赖及顺序 • 控制恢复节奏 • 寻求外部支援

30. 故障应急之「血泪案例分享」

31. 简介：详细分析，根因彻查故障定性、定级、定责优化改进，举一反三案例学习，组织提升周期回顾，数据洞察

32. 复盘改进之「工作清单」模拟复现根因定位整改修复故障复盘故障改进预案完善周边清查经验固化案例学习

33. 复盘改进之「故障复盘」故障复盘-黄金三问 • 我们应该怎么做，才能更快地恢复业务？ • 我们应该怎么做，才能避免再次出现类似问题？ • 我们有哪些好的经验可以总结、提炼，并固化？ • One more thing，我们还能做些什么？

34. 复盘改进之「定级、定性、定责与运作机制」故障定级故障分工作流程故障定性故障定责故障管理工作的组织支撑

35. 复盘改进之「周期回顾与数据洞察」

36. We are on the way to AGI or ASI.

37. 故障管理框架稳定故障运行发生可用性体系/SLIs/SLO/SLA 故障定级/定性/定责改进故障周期回顾验收恢复故障故障改进复盘错误预算/故障分组织结构支撑/故障委员会

38. 故障管理框架-PPTV 目标技术流程组织 Vision Technology Process People 明确OKR目标用OKR目标的行政手段来保障各相关团队在稳定性方面的持续投入，用目标引导结果的达成。多管齐下+敏捷行动 1. 数据支撑：可观测体系、压测平台、稳定性运营平台 2. 服务干预和保障：应急响应平台、容器管理平台 3. 运维元数据平台建设：CMDB、 CP-Meta 4. 各种自动化工具… 流程规范支撑 1. 制定完善的故障管理规范、故障专人对接保障落地 1. 建立中立的故障管理委员会(稳定管理流程，并将其逐步沉淀到工性管理委员会)，构建公开、公具中。正、透明的故障管理环境。 2. 做好流程规范的宣贯，工具的使用引导和运营。 2. 明确接口人，保障各BU在稳定性管理方面的持续投入，保证更紧密的协作、消除因为信息不对称带来的壁垒和阻碍。

39. Deep Thinking

40. 我所看到的几个趋势云原生 • 作为基石，持续发展和深化可观测性 • 融合类方案和一体化平台被更多地认同和实践 LLM Ops • SRE团队引入LLM进行辅助分析、智能决策等 AI Agent MCP/ANP/A2A AI 可信系统 • SRE Agent助力故障响应、根因定位、故障自愈 • MCP：上下文感知模型协议优化云原生应用决策 • ANP：多智能体网络协作提升分布式系统自治水平 • 安全、可解释性、合规性、伦理等成为关注焦点

41. 最后的话：如何面对汹涌的技术浪潮看清本质拥抱变化顺势而为做好定位葆有价值泰然自若云原生平台工程微服务无服务 AI Agent 服务网格可观测低代码/零代码 GitChatBizDevSecFinGreenAIOps….

42.

43. 大模型正在重新定义软件 Large Language Model Is Redefining The Software