用途
Incident Response Engineer 用于协调生产环境事故响应，从首次信号一直贯穿到恢复和事后复盘。其适用范围是正在发生的运营事故和服务降级，目标是在事故期间提供统一的响应结构、定级依据、止损与缓解策略、沟通节奏以及可追踪的复盘产出。
该技能明确不用于：一般的代码审查（review）、主动漏洞扫描（security-scanner）、没有事故协调需求的一次性缺陷修复。
主要能力
技能围绕事故响应中的核心概念组织，包括：
- severity（严重级别）：基于业务影响的事故优先级。
- impact（影响）：用户可见损害、收入损失或运营降级。
- blast radius（影响范围）：受影响的系统、区域、租户或用户。
- containment（止损）：阻止事故扩散的短期行动。
- mitigation（缓解）：在根因完全修复前减少影响的行动。
- recovery（恢复）：使服务回到可接受的运营状态。
- incident commander（事故指挥官）：决策与时间线的唯一协调人。
- stakeholder update（干系人更新）：面向内部或外部受众的限时状态消息。
- timeline（时间线）：事实、决策和行动的有序记录。
- action item（行动项）：带有责任人和截止日期的具体后续事项。
使用方式
该技能提供六种工作模式，也可在描述正在发生的故障时自动匹配最接近的模式；无参数时显示模式菜单与示例。
- triage <signal>：分类事故并建立第一响应计划。
- stabilize <incident>：控制影响并协调缓解。
- comms <incident>：起草内部或面向客户的更新。
- postmortem <incident>：构建事故复盘与纠正措施。
- review <timeline or runbook>：审查事故处理过程。
- drill <scenario>：运行桌面推演或演练计划。
模式菜单示例：
- triage elevated 500s in eu-west checkout
- stabilize auth outage caused by bad deploy
- comms database failover affecting signups
- postmortem queue backlog incident
- review incident timeline from 2026-03-12
- drill primary region outage
各模式的执行要点：
- Triage：从已核实事实出发，记录症状、受影响系统、受影响用户和检测来源；基于影响与影响范围而非直觉估计严重级别，参考 references/severity-matrix.md；指定事故指挥官并定义下一个决策检查点；识别止损选项、最安全的即时缓解措施，以及哪些证据能确认或否定当前假设；产出前 15 分钟响应计划。
- Stabilize：将止损与根因工作分开；优先采取最快减少用户损害的行动，如回滚、流量切换、功能开关、依赖隔离或故障转移，参考 references/containment-recovery-aids.md；维护带时间戳、责任人和结果的活动时间线；影响范围变化时重新评估严重级别；明确跟踪三种状态：已控制、部分恢复、完全恢复。
- Comms：确定受众（响应者、高管、支持团队或客户）；说明已知情况、用户可能观察到什么、团队正在做什么、下一次更新何时到来；避免推测性根因声明；客户更新保持简洁平实，参考 references/comms-templates.md。
- Postmortem：基于已核实事件而非仅凭记忆构建时间线，参考 references/timeline-postmortem-examples.md；区分触发因素、促成因素、失效的防御、恢复行动和教训；将教训转化为带责任人、截止日期和可衡量结果的行动项；关注系统修复而非追责。
- Review：阅读时间线、更新、运行手册和后续行动，对照 references/severity-matrix.md、references/comms-templates.md、references/timeline-postmortem-examples.md；评估检测、分类速度、指挥结构、沟通质量、恢复策略和行动项质量；将差距标记为 critical、warning 或 info。
- Drill：定义场景、目标和停止条件；使用 references/severity-matrix.md、references/comms-templates.md、references/containment-recovery-aids.md 模拟检测、角色分配、升级、回滚和客户沟通；记录决策瓶颈和缺失的运行手册步骤。
输出要求
- Triage 和 stabilize 输出必须包含严重级别、影响范围、指挥官、下一个检查点和即时行动。
- Comms 输出必须包含受众和下一次更新时间。
- Postmortem 必须包含带责任人的行动项。
关键规则
- 始终区分事实、推断和假设。
- 客户影响优先于优雅的诊断。
- 在证据支持之前，绝不公开声称根因。
- 每个正在发生的事故都需要唯一的事故指挥官。
- 响应期间的每个关键动作都必须进入时间线。
- 复盘必须产出有责任人的纠正措施，而不是含糊的教训。
适用场景
在以下情况使用：服务宕机、降级或违反 SLO；多个响应者需要共同的事故结构；必须以固定节奏发布干系人或客户更新；已知修复方案但需要在止损和恢复期间管理风险；团队需要复盘或桌面演练。
分类边界与限制
若任务是常规调试或没有运营影响的一次性缺陷，应使用 investigate。若任务是主动漏洞发现、威胁建模或安全扫描，应使用 security-scanner。若任务是代码审查、修复质量评估或合并前风险审查，应使用 review。若任务是在非活动事故期间设计遥测、告警架构或定义 SLO，应使用 observability-advisor。若任务是特定厂商的仪表盘、告警或日志平台配置，应路由到相应平台技能。
规模策略方面：单服务事故保持一个指挥官、一条时间线、一个响应频道和一个短更新节奏；跨团队事故将止损、诊断和沟通拆分为明确工作流，同时保留唯一指挥官和唯一时间线事实来源；重大事故应固定更新节奏、指定客户沟通负责人，并在临时协调碎片化之前定义升级到高管可见性的阈值。
参考资料文件（仅在当前模式需要更深入结构或可复用模板时使用）：references/severity-matrix.md、references/comms-templates.md、references/timeline-postmortem-examples.md、references/containment-recovery-aids.md。
该技能 IS for：线上故障协调、缓解策略、干系人更新、复盘、事故演练。NOT for：漏洞发现、代码审查或没有运营影响的常规调试。