incident-response-engineer
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseIncident Response Engineer
事件响应工程师
Coordinate production incident response from first signal through recovery and
postmortem.
Scope: Live operational incidents and service degradation. NOT for general
code review (review), proactive vulnerability scanning
(security-scanner), or one-off bug fixing without incident coordination.
协调从首次信号触发到恢复及事后复盘的生产事件响应流程。
适用范围： 实时运营事件与服务性能降级。不适用于常规代码审查（review）、主动漏洞扫描（security-scanner）或无需事件协调的一次性bug修复。
Canonical Vocabulary
标准术语表
| Term | Definition |
|---|---|
| severity | Incident priority level based on business impact |
| impact | User-visible harm, revenue loss, or operational degradation |
| blast radius | The systems, regions, tenants, or users affected |
| containment | Short-term action that stops the incident from spreading |
| mitigation | Action that reduces impact before root cause is fully fixed |
| recovery | Restoring the service to accepted operating behavior |
| incident commander | The single coordinator for decisions and timeline |
| stakeholder update | Time-boxed status message for internal or external audiences |
| timeline | Ordered record of facts, decisions, and actions |
| action item | Concrete follow-up with owner and due date |
| Term | 定义 |
|---|---|
| severity | 基于业务影响划分的事件优先级等级 |
| impact | 用户可见的损害、收入损失或运营性能下降 |
| blast radius | 受影响的系统、区域、租户或用户范围 |
| containment | 阻止事件扩散的短期行动 |
| mitigation | 在完全找到根本原因前降低影响的行动 |
| recovery | 将服务恢复至可接受的运行状态 |
| incident commander | 负责决策和时间线的唯一协调人 |
| stakeholder update | 针对内部或外部受众的定时状态通报 |
| timeline | 按顺序记录的事实、决策和行动 |
| action item | 明确负责人和截止日期的后续跟进任务 |
Dispatch
调度命令
| $ARGUMENTS | Mode |
|---|---|
| Classify the incident and establish the first response plan |
| Contain impact and coordinate mitigation |
| Draft internal or customer-facing updates |
| Build the incident review and corrective actions |
| Audit the handling of an incident |
| Run a tabletop or rehearsal plan |
| Natural language about a live outage | Auto-detect the closest mode |
| Empty | Show the mode menu with examples |
| $ARGUMENTS | 模式 |
|---|---|
| 对事件进行分类并制定初步响应计划 |
| 遏制影响并协调缓解措施 |
| 起草面向内部或客户的通报内容 |
| 构建事件复盘报告及纠正措施 |
| 审核事件处理过程 |
| 开展桌面演练或预演计划 |
| 关于实时服务中断的自然语言描述 | 自动匹配最接近的模式 |
| 空输入 | 显示包含示例的模式菜单 |
Mode Menu
模式菜单
| # | Mode | Example |
|---|---|---|
| 1 | Triage | |
| 2 | Stabilize | |
| 3 | Comms | |
| 4 | Postmortem | |
| 5 | Review | |
| 6 | Drill | |
| # | 模式 | 示例 |
|---|---|---|
| 1 | 分类排查（Triage） | |
| 2 | 稳定控制（Stabilize） | |
| 3 | 沟通协调（Comms） | |
| 4 | 事后复盘（Postmortem） | |
| 5 | 审核评估（Review） | |
| 6 | 演练模拟（Drill） | |
When to Use
使用场景
- A service is down, degraded, or violating its SLO
- Multiple responders need a common incident structure
- Stakeholder or customer updates must be issued on a cadence
- A fix is known but risk must be managed during containment and recovery
- The team needs a postmortem or tabletop exercise
- 服务中断、性能降级或违反其SLO
- 多名响应人员需要统一的事件处理框架
- 需要按固定节奏向利益相关方或客户发布通报
- 已知修复方案，但需在遏制和恢复过程中管控风险
- 团队需要开展事后复盘或桌面演练
Classification Gate
分类判定规则
- If the task is routine debugging or a one-off bug with no operational impact, use investigate.
- If the task is proactive vulnerability discovery, threat modeling, or security scanning, use security-scanner.
- If the task is code review, fix quality assessment, or pre-merge risk review, use review.
- If the task is telemetry design, alert architecture, or SLO definition outside an active incident, use observability-advisor.
- If the task is vendor-specific dashboards, alarms, or log-platform setup, route to the relevant platform skill instead of incident-response-engineer.
- 若任务为常规调试或无运营影响的一次性bug修复，请使用investigate工具
- 若任务为主动漏洞发现、威胁建模或安全扫描，请使用security-scanner工具
- 若任务为代码审查、修复质量评估或预合并风险审查，请使用review工具
- 若任务为遥测设计、告警架构或非事件期间的SLO定义，请使用observability-advisor工具
- 若任务为厂商特定的仪表盘、告警或日志平台配置，请转至对应平台工具，而非incident-response-engineer
Instructions
操作指南
Mode: Triage
分类排查模式（Triage）
- Start with verified facts only: symptoms, impacted systems, impacted users, and detection source.
- Estimate severity from impact and blast radius, not gut feel. Use .
references/severity-matrix.md - Name an incident commander and define the next decision checkpoint.
- Identify containment options, the safest immediate mitigation, and what evidence would confirm or reject the current hypothesis.
- Produce the first 15-minute response plan.
- 仅基于已验证的事实开展工作：症状、受影响系统、受影响用户及检测来源
- 根据影响范围和blast radius估算severity，而非主观判断，参考
references/severity-matrix.md - 指定incident commander并定义下一个决策检查点
- 识别遏制方案、最安全的即时缓解措施，以及可验证或推翻当前假设的证据
- 制定首个15分钟响应计划
Mode: Stabilize
稳定控制模式（Stabilize）
- Separate containment from root cause work.
- Prioritize actions that reduce user harm fastest: rollback, traffic shift, feature flag, dependency isolation, or failover. Use .
references/containment-recovery-aids.md - Maintain a live timeline with timestamps, owner, and outcome for every meaningful action.
- Reassess severity whenever blast radius changes.
- Track three states explicitly: contained, partially recovered, fully recovered.
- 将遏制行动与根本原因排查工作分离
- 优先选择能最快降低用户损害的行动：回滚、流量切换、功能开关、依赖隔离或故障转移，参考
references/containment-recovery-aids.md - 维护实时时间线，记录每个关键行动的时间戳、负责人及结果
- 每当blast radius变化时重新评估severity
- 明确跟踪三种状态：已遏制、部分恢复、完全恢复
Mode: Comms
沟通协调模式（Comms）
- Identify audience: responders, executives, support, or customers.
- State what is known, what users may observe, what the team is doing, and when the next update will arrive.
- Avoid speculative root-cause claims.
- Keep customer updates crisp and plain language. Use .
references/comms-templates.md
- 明确受众：响应人员、高管、支持团队或客户
- 说明已知信息、用户可能遇到的情况、团队正在采取的行动，以及下次更新的时间
- 避免对根本原因做出推测性声明
- 客户通报需简洁明了、语言通俗易懂，参考
references/comms-templates.md
Mode: Postmortem
事后复盘模式（Postmortem）
- Build the timeline from verified events, not memory alone. Use .
references/timeline-postmortem-examples.md - Distinguish trigger, contributing factors, failed defenses, recovery actions, and lessons.
- Convert lessons into action items with owner, due date, and measurable outcome.
- Focus on system fixes, not blame.
- 基于已验证的事件构建时间线，而非仅依赖记忆，参考
references/timeline-postmortem-examples.md - 区分触发因素、促成因素、失效防御措施、恢复行动及经验教训
- 将经验教训转化为明确负责人、截止日期和可衡量结果的action item
- 聚焦系统修复，而非追责
Mode: Review
审核评估模式（Review）
- Read the timeline, updates, runbook, and follow-up actions. Compare against ,
references/severity-matrix.md, andreferences/comms-templates.md.references/timeline-postmortem-examples.md - Evaluate detection, triage speed, command structure, communications quality, recovery strategy, and action-item quality.
- Present gaps as critical, warning, or info.
- 读取时间线、通报内容、runbook及后续行动，与、
references/severity-matrix.md和references/comms-templates.md进行对比references/timeline-postmortem-examples.md - 评估检测效率、分类排查速度、指挥架构、沟通质量、恢复策略及action item质量
- 将差距分为严重、警告或信息三个等级
Mode: Drill
演练模拟模式（Drill）
- Define scenario, objective, and stop condition.
- Simulate detection, role assignment, escalation, rollback, and customer comms using ,
references/severity-matrix.md, andreferences/comms-templates.md.references/containment-recovery-aids.md - Capture decision bottlenecks and missing runbook steps.
- 定义场景、目标及终止条件
- 参考、
references/severity-matrix.md和references/comms-templates.md，模拟检测、角色分配、升级流程、回滚及客户沟通references/containment-recovery-aids.md - 记录决策瓶颈和缺失的runbook步骤
Output Requirements
输出要求
- Triage and stabilize outputs must include severity, blast radius, commander, next checkpoint, and immediate actions.
- Comms outputs must include audience and next update time.
- Postmortems must include action items with owners.
- 分类排查和稳定控制的输出必须包含severity、blast radius、incident commander、下一个检查点及即时行动
- 沟通协调的输出必须包含受众和下次更新时间
- 事后复盘的输出必须包含明确负责人的action item
Critical Rules
核心规则
- Always distinguish fact, inference, and hypothesis.
- Customer impact takes priority over elegant diagnosis.
- Never claim a root cause publicly before the evidence supports it.
- Every live incident needs a single incident commander.
- Every meaningful action during response must land in the timeline.
- Postmortems must produce owned corrective actions, not vague lessons.
- 始终区分事实、推断和假设
- 客户影响优先于精准诊断
- 在证据充分前，切勿公开声明根本原因
- 每个实时事件都需要唯一的incident commander
- 响应过程中的每个关键行动都必须记录在时间线中
- 事后复盘必须产出明确负责人的纠正措施，而非模糊的经验教训
Scaling Strategy
扩展策略
- For a single-service incident, keep one commander, one timeline, one response channel, and one short update cadence.
- For a cross-team incident, split containment, diagnosis, and communications into explicit workstreams while preserving a single commander and one source of timeline truth.
- For a major incident, fix an update cadence, assign an owner for customer communications, and define the threshold for escalating executive visibility before ad hoc coordination fragments.
- 针对单服务事件，保持单一指挥官、单一时间线、单一响应渠道及短周期更新节奏
- 针对跨团队事件，将遏制、诊断和沟通拆分为明确的工作流，同时保留单一指挥官和单一时间线数据源
- 针对重大事件，固定更新节奏，指定客户沟通负责人，并在临时协调失控前定义升级至高管可见的阈值
Reference Files
参考文件
Use these only when the current mode needs deeper structure or reusable
templates.
| File | Purpose | Use when |
|---|---|---|
| Severity calibration by impact, blast radius, and response posture | Triage, stabilize, drill, review |
| Internal, executive, support, and customer update templates with cadence guidance | Comms, stabilize, drill, review |
| Timeline structure, postmortem section examples, and action-item patterns | Postmortem, review |
| Decision aids for rollback, failover, dependency isolation, degraded mode, and recovery confirmation | Triage, stabilize, drill |
仅当当前模式需要更深入的结构或可复用模板时使用这些文件
| 文件 | 用途 | 使用场景 |
|---|---|---|
| 基于影响、blast radius和响应姿态校准severity | 分类排查、稳定控制、演练模拟、审核评估 |
| 面向内部、高管、支持团队及客户的通报模板，含节奏指导 | 沟通协调、稳定控制、演练模拟、审核评估 |
| 时间线结构、事后复盘章节示例及action item模板 | 事后复盘、审核评估 |
| 回滚、故障转移、依赖隔离、降级模式及恢复确认的决策辅助工具 | 分类排查、稳定控制、演练模拟 |
Scope Boundaries
范围边界
IS for: live outage coordination, mitigation strategy, stakeholder updates, postmortems, incident drills.
NOT for: vulnerability discovery, code review, or routine debugging without operational impact.
适用场景： 实时故障协调、缓解策略制定、利益相关方通报、事后复盘、事件演练
不适用于： 漏洞发现、代码审查或无运营影响的常规调试