技术故障应急协同机制的探索

语言	格式	评分
中文（简体）	.pdf	3
概览
技术故障应急协同机制的探索目录技术故障重要性及定义技术故障的全生命周期如何落地应急协同机制 G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站小结及展望技术故障的重要性及定义 01 G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站 G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站技术故障重要性海恩法则，也被称为Heinrich‘s law，是由德国飞机涡轮机的发明者帕布斯·海恩提出的一个关于飞行安全的法则。这一法则强调，每一起严重事故的背后，必然有29次轻微事故和300起未遂先兆以及1000起事故隐患。这表明，任何严重事故的发生都是经过了一个从苗头到隐患，再到事故的过程，而这个过程的每一个环节都是可以预防的。海恩法则不仅适用于航空领域，也广泛应用于企业的生产管理、安全管理、人资管理等各个领域，其精髓在于“防微杜渐”，即通过及时发现并消除事故的征兆和隐患，来避免重大事故的发生。墨菲定律是一种启发性原则，常被表述为：任何可能出错的事情最终都会出错。其含义是说，无论是因为存在一个错误的方法，或是存在发生某种错误的潜在可能性，只要重复进行某项行动，错误在某个时刻就会发生。可预防不可避免 G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站什么是故障？问题？风险？故障？事故？事件？影响了业务的才是故障？ G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站技术故障在ITIL中的定义 ITIL定义：“服务的意外中断或服务质量的降低” 故障问题 ITIL定义：为“问题”、“已知错误”，问题意味着隐患风险，已知错误意味着主动整改。 : problem 问题（Problem）、故障（Incident）区分： • 故障对用户或业务流程有影响, 必须解决这些故障, 以便可以进行正常的业务活动 • 问题是故障的原因。它们需要调查和分析, 以查明原因, 制定变通办法, 并建议长期解决办法。这减少了未来故障的数量和影响。技术故障的全生命周期 02 G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站 G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站技术故障全生命周期 G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站故障前：未雨绸缪、防微杜渐 • 代码审查：严格执行代码审查流程，确保代码质量符合标准，进行全面的测试，包括单元测试、集成测试、性能测试等，确保软件质量。 • 自动巡检：通过自动化巡检机制，发现软硬件的包括基础资源、应用配置、告警配置，以及运行状态的风险及潜在问题。提升故障处置阶段效率 • 混沌工程：主动引入故障和异常情况，发现系统中的弱点和脆弱性，以及其在面对异常情况时的表现。 • 应急演练：通过模拟突发情况，检验应急预案的有效性，锻炼应急队伍的协同配合，磨合应急管理机制。发现潜在问题并修复 G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站故障中：分秒必争、临危不惧故障响应 GOC总控中心根据故障域高效拉群协同故障定位 SRE基础设施能力提供变更事件监控告警、日志记录、链路分析、在线诊断等发现故障通过监控手段自动化报备人工反馈报备故障止血考察自动化预案的执行重启、切流、降级等故障中 G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站故障后：亡羊补牢、秋后算账向自己学习，不浪费任何一个故障梳理故障时间线发生时间发现时间响应时间定位时间止血时间恢复时间还原故障处理过程发现方式响应方式协同流程初步定位风险升级信息通报启动预案处置方案分析故障根因问题产品需求系统架构代码质量测试覆盖上线操作程序配置系统监控业务操作整理故障改进措施需求/任务改进内容改进人完成日期系统优化监控优化测试优化流程优化《六维复盘术》判定故障级别责任故障级别主责部门次责部门主责任人次责任人责任处罚发送故障报告解决方案故障反思通告时效通告范围如何落地应急协同机制 03 G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站 G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站应急“1-5-10”目标分钟 1 分钟 5 分钟 10 发生发现定位止血/恢复发现故障故障定位故障止损定位：并不是找到了具体的故障原因或故障根源，而是找到了大概的故障位置，可以针对性启动应急处理流程。止血：并不是真正的完全恢复，通常是可以采取快速预案的执行，从而阻断了故障继续扩散。 “1-5-10”源于阿里 G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站标准先行 01 03 04 02 3、定级标准评估技术故障的严重程度，通常根据对业务影响进行量化，对社会舆论的影响情况，以及影响时长综合定级。 4、定责标准确定主次责任，通常根据各个阶段中是否符合，另外也要考虑是否违反规定的红线综合定责。 2、复盘标准明确不同级别复盘方式和流程，通常由GOC组织线下复盘，明确申诉机制和流程。 1、应急标准应急的核心是止损，明确各个角色在故障发生过程中的应急操作流程，报备流程等。 G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站标准落地落地三大障碍 “大事化小、小事化了”，如果老板不追责，系统就是没问题，能瞒着就瞒着，你好我好大家好。低调处理故障不上报明哲保身推脱责任担心承担不起“P0”级的惩罚，能往下压低一级，就绝不老实“认罪”，复盘会花费大量时间为级别扯皮。避重就轻复盘不认级别雪崩的时候没有一篇雪花是无辜的处罚和级别无关联降低报备的成本 G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站故障前-工具平台的核心功能有了标准，还需工具上的支撑预警系统自动化巡检实时检测潜在故障，并快速预警，确保故障被及时、准确地发现并解决。 01 监控系统优化监控的精准度，引入告警确认的ACK机制，简化风险报备流程，一键轻松上报。 02 容量管理基于模型/算法提供容量预估、支持常态化容量验证，通过自动巡检识别容量风险 03 混沌工程 04 通过实验模型的注入，检测系统高可用、发现未知错误，提升系统容错能力。 G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站故障后-工具平台的核心功能深挖原因（5 Why分析法，“丰田五问法则”）案例：丰田汽车公司前副社长大野耐一，如何通过运用5WHY法来找到工厂设备停机的根本原因。有一次，他在生产线上发现机器总是停转，虽然修过多次，但仍不见好转。于是他询问工人机器停机的原因。对话： Q1：为什么机器停了？A1：因为机器超载，保险丝烧断了。 Q2：为什么机器会超载？A2：因为轴承的润滑不足。 Q3：为什么轴承会润滑不足？A3：因为润滑泵失灵了。 Q4：为什么润滑泵会失灵？A4：因为它的轮轴耗损了。 Q5：为什么润滑泵的轮轴会耗损？A5：因为杂质跑到里面去了。故障复盘编写报告发送报告改进措施 G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站技术故障数据洞察 G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站技术故障应急协同机制落地小结及展望 04 G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站 G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站小结故障定义 • 海恩法则：每一起严重事故后背，有29次轻微事故和300起未遂先兆以及1000次事故隐患（可预防） • 墨菲定律：任何可能出错的事情最终都会出错（不可避免） 01 故障生命周期 • 未雨绸缪、防微杜渐：发现潜在问题并修复，提升故障处理阶段效率 • 分秒必争、临危不惧：通过发现、响应、定位、止血快速处理故障 • 亡羊补牢、秋后算账：《六维复盘法》，向自己学习，不浪费任何一个故障 02 落地应急协同机制 • SOP标准先行，及落地障碍的应对策略 • 应急的核心是止损，确定故障应急标准 • 面对复盘时责任推脱，雪崩时没有一篇雪花是无辜的，改进最有效原则定责 • 故障前中后阶段，通过不同的工具建立团队之间的“协作“，快速降低线上MTTR • 数据洞察的目标最大限度增加MTBF（平均无故障时长）和缩短MTTR（平均故障修复时长） 03 G O P S 全球运维大会暨 X O p s 技术创新峰会 2 0 2 4 · 北京站继续探索扁鹊三兄弟 1. 大哥：最好，事前 2. 二哥：次之，事中 3. 扁鹊：最差，事后感谢大家观看 T H A N K S