1、1SRE体系：快速修复故障的套路张观石 SRE原理与实践作者 资深运维专家和架构师，拥有20年经验；熟悉基于微服务架构的直播业务、音视频业务、海外直播业务的稳定的保障体系。熟悉混合多云架构、可观测性、预案、变更管控、AIOps等领域；信通院分布式系统稳定性实验室高级技术专家，参与编写了信通院信息系统稳定性保障能力建设指南。21.读过的都说好“可用于做SRE面试指南”“用于指导实际项目开展”,读了3遍 送朋友、送客户、送同事2.内容特点 SRE工程体系完整 先进实战案例丰富3案例：3个惨案现场快速修复故障的基本套路套路有多深：掌握故障规律怎么看套路成效45故障案例1 背景：数据库M-S架构，正常

2、主从是同步的。故障描述：某天发现主从不同步了。处理方法1：在修复同步问题时无意中删除了一个文件，DBA用了另外一个备份文件去替代。看起来是一样的文件，然后重启数据库。结果：结果数据库系统启动不起来。62023年1月12日 美国FAA NOTAM系统故障，全美12000个航班被延误或取消故障案例2 背景：机房冷机4主+4备的架构，主机故障可以手工切备机。故障描述：冷却系统缺水，导致4台主冷机服务异常。处理预案1：冷机切到备机系统，发现缺水形成了气阻，备用冷机启动失败。处理方法2：尝试一台台启动，阻力更小 结果：启动不起来，发现冷机设计为4台绑定一起重启，目的是为了批量操作方便。紧急处理：只能远程

3、与现场合作临时改代码逻辑、发布，解除群控逻辑。7某公有云AZ制冷故障，持续13小时故障案例3 背景：业务产品和管控系统都在A、B。两机房容灾部署 故障：机房A挂了，大量迁移到机房B，用户集中迁移业务导致管控系统的并发增加，被限流；预案：给管控系统扩容资源 问题：增加容量的管控系统的一个中间件被部署在故障机房A，扩容操作失败8某公有云AZ制冷故障，持续13小时简单故障场景49服务器磁盘被写满了，处理需要几步，需要多长时间复杂故障场景5 直播平台大活动期间卡顿率上升1%101.怎么排查是哪部分、2.怎么定位是什么原因，什么维度3.怎么修复故障修复的难点在哪？11系统复杂性系统复杂、故障场景多、脆弱

4、性因素多，防不胜防；案例涉及人员众多涉及到众多人员、没有组织协同则混乱出错；有时10几个团队人一起参与问题处理，指挥混乱、信息混乱一个故障影响机房数百个产品和上千个系统修复过程难所用到的各方面能力，任何一环不能掉链子，以为有预案，关键时刻不工作。发现难、定位难、修复难案例：快速修复故障的基本套路设计、预案、应急12针对故障因素/场景设计修复方案专门的修复工具，并打通依赖工具有效的修复方案和工具有接收故障，并执行处理的高效流程，预备资源，人的应急协同有力保障能力：资源、人与流程系统可被修系统做了可被修复的设计可感知、无状态、可切换/调度/容错/降级13可被修复的架构设计 设计便于修复的软硬件架构

5、 系统是可修复的（针对特定的故障场景已经有相应的修复设计）能自愈的尽量容灾自愈，不能自愈必须暴露接口 可修复的架构原则，架构风险治理 标准化、无状态的软件架构 多副本冗余的设计 被隔离迁移、调度切换的能力14故障场景、故障影响、预案是什么、故障预计修复时长问研发：能不能把调度功能开放给运维？各系统可被修复的架构设计&暴露API15节点屏蔽/删除服务组扩缩容变更系统回滚业务降级 微服务后台接入服务切换路由切换接入中台自定义脚本任务脚本运维通道节点屏蔽/删除服务组扩容/缩容名字服务直播间下行流屏蔽切换线路切换档位主播切换上行线路音视频自定义api接入基于事件消费的预案任务执行机制监控内嵌查询基于指

6、标的判断功能文档功能IM人功能统一告警通知功能通用功能架构与预案结合16运维类操作、业务服务类操作预案及预案系统17 有修复的工具及其依赖的工具 有修复的人、及时协作，快速修复高效执行，有力保障：预案不一定很复杂1、问题本质原因：问题/故障解决依赖人的知识经验2、核心要解决的：如何将处理经验通过技术手段固化成一个个可以被直接可执行的预案场景18 01人员保障协作排查、修复、指挥协同、发言 02运维资源保障紧急扩容资源支撑工具 03流程与制度保障定期演练19一键到达：根因推荐与预案关联20预案来源21123通过技术分析、风险识别发现的潜在故障场景演练发现的故障场景企业内部/业界曾经发生的故障场景

7、预案功能设计：1.预案管理（增加录入、修改、删除、执行记录）2.基本任务（原子操作）管理：1.可增加、删除、修改原子操作，2.对接管控系统API、运维通道、软件集群，平台脚本编辑等3.预案编排：增加删除步骤、调整顺序，每一步对接基本任务或一些自行动作，参数传递4.预案执行：告警导入、页面引导、一键/逐步执行、每步结果显示、执行前通知、执行后通知，记录执行过程5.预案回退：部分支持灰度执行，也可回退，部分提供恢复现场功能6.预案统计分析：执行次数、时长、效果等7.其他功能：权限控制、执行历史、文档编辑、嵌入通知、嵌入监控、自动拉群等22套路有多深深入故障规律，理解故障命脉23研究规律、有效应对按

8、故障原因进行分类针对原因设计对应预案故障修复是工程不仅靠运维从架构设计、经验 沉淀管控能力编程，决策执行故障修复靠综合能力不仅靠经验、靠预案更需要系统协同有力保障24应对之道25应对方法及案例：灾难型：部署架构高可用，混合云两地三中心直播间上行和下行线路变更型故障：变更红线、变更管控系统容量与负载故障型：1、扩容2、降级、熔断应对案例：混合云弹性，预先弹性、一键扩容；一键降级；123灾难型：容灾高可用l高可用设计l容灾切换，内部与外部切变更型：l变更管控l人机可靠性容量型：l提供更多的资源（扩容）、l把服务消耗的资源减少（优化、降级）故障规律 故障分类及原因分类 灾难型、容量负载型、变更型 灾

9、难型：服务器、机房、交换机、网络等单点不可用 负载型：流量超出预期、性能下降造成资源不足 变更型：应用发版、运维变更、软件基础设施变更、应急基础设施变更、配置变更26某年故障原因分类变更型故障的细分原因故障修复是工程27故障快速修复不是单个部门的事情，是研发、SRE、架构部门共同目标预案平台是把系统各层技术能力加以集成，共同修复产研及架构师l 改变软件系统架构l 服务可配置开关能力l 暴露可修复的功能基础架构/中间件l 实现基础设施、系统运维、组件的架构l 提供可修复的功能SREl 改变架构l 编排能力开发预案一线/NOC预案最频繁的使用者故障生命周期:从苗头到修复的全过程28故障通知故障响应

10、定界定位故障快恢/快恢/止损应急修复故障复盘通知谁，通知渠道通知内容确认响应准备工作影响分析定界分析初因分析预案分工升级流程对内对外应急修复故障的要点29响应阶段考验人员规划、日常训练、人员责任心、组织安排，以及办公基础设施的完备性、响应相关系统的易用和便捷程度，准备步骤是否顺畅等。通知环节最重要的是尽快通知能处理故障的人，提供简要关键信息，通知方式要便于转通知其他后续参与的人。应急修复故障原因排查顺序30 大胆假设 小心求证 迅速排除3132故障MTTRl 单个故障的度量：l 修复过程时长l 故障分级分类l 修复能力级别l 周期性度量：l 故障平均时长l 逐步提升、分析变化过程能力l 发现时

11、长l 响应时长l 定界定位时长l 修复时长l 预案覆盖率l 预案有效率修复能力分级3301在线层层排查02按文档排查修复03多个步骤修复04一键修复05自愈20%自愈越多越好30%预案平台一键修复30%多个步骤修复10%在线层层排查10%按文档排查修复总结 强调故障修复的工程化设计，故障修复也是个工程工作 核心点：预案平台不是单个部门的事情，是研发、架构部门共同的目标。运维研发必须共同建设。支撑保障能力、管控系统的能力不能被忽视 研究故障规律，针对性设计故障修复预案 灾难型、容量型、变更型 要持续度量，看到进步，更重要是看到短板和改进方向34以快速修复为目标，整合系统相关的技术栈各层能力，整合从运维、产研、值班、客服等团队协同，尽快速度修复故障。Thanks开放运维联盟高效运维社区DevOps 时代荣誉出品35