incident-management

# 事故管理 事故响应、根本原因分析、事后复盘及构建弹性事故管理流程的综合指南。 ## 目录 - [事故生命周期](#incident-lifecycle) - [严重性分类](#severity-classification) - [事故响应角色](#incident-response-roles) - [沟通协议](#communication-protocols) - [根本原因分析](#root-cause-analysis) - [事后复盘](#post-incident-reviews) - [值班管理](#on-call-management) - [事故管理工具](#incident-management-tools) - [运行手册开发](#runbook-development) - [指标与改进](#metrics-and-improvement) ## 事故生命周期 ### 事故状态 检测 → 已确认 → 调查中 → 已识别 → 解决中 → 已解决 → 已关闭 检测： - 触发自动警报 - 收到用户报告 - 主动监控识别出异常 确认： - 值班工程师确认收到通知 - 目标：P1 级 < 5 分钟 调查： - 收集症状和证据 - 检查近期变更 - 查看日志和指标 - 识别受影响组件 识别： - 形成根本原因假设 - 确定影响范围 - 确定修复方案或临时规避措施 解决： - 实施修复或规避措施 - 验证服务恢复 - 监控是否复发 关闭： - 确认无进一步影响 - 记录解决方案 - 安排事后复盘 ### 事故响应工作流 yaml 阶段 1：检测与分诊 (0-5 分钟) 操作： - 警报触发或用户报告问题 - 值班人员在 5 分钟内确认 - 初步严重性评估 - 创建事故工单 - 必要时呼叫额外响应人员 关键问题： - 用户侧的影响是什么？ - 多少用户/客户受到影响？ - 数据是否有风险？ - 情况是否在恶化？ 阶段 2：调查 (5-30 分钟) 操作： - 加入事故作战室 (Slack/Zoom) - 指派事故指挥官角色 - 查看近期变更（部署、配置） - 检查监控仪表盘 - 查询错误日志 - 追踪受影响的请求 - 形成初步假设 关键问题： - 最近有什么变化？ - 日志显示什么？ - 依赖项是否健康？ - 我们能重现这个问题吗？ 阶段 3：缓解 (30-60 分钟) 操作： - 实施修复或规避措施 - 必要时回滚近期变更 - 如果是容量问题则扩展资源