SEO / GEO 工作自动化部署与实践规范（三十）：从异常修复到事故控制面——SLO、Circuit Breaker、Kill Switch、Break Glass 与 Incident Command

创见日期：2026年9月25日

第（二十九）篇完成以后，我们已经拥有 Execution Journal → Reconciliation Engine → DLQ → Repair Queue → Operator Console。这套体系解决的是：一笔事务出了问题之后，系统能不能发现它、定位它、修复它，并最终验证真实世界重新收敛。

但生产系统还存在更危险的一类事故。问题不再是 1 个 WordPress Command 失败，而可能变成：50 个 Command 同时失败、200 个任务开始重试、多个 Agent 持续生成新的副作用、WordPress API 错误率持续上升、Cloudflare 请求不断超时、Database 写入开始排队、DLQ 与 Repair Queue 同时膨胀。

如果系统仍然按照第（二十九）篇的逻辑一笔一笔 Repair，它可能根本来不及，甚至会出现“恢复机制本身开始扩大事故”。

Dependency Failure
↓
Retry
↓
More Load
↓
More Failure
↓
More Retry
↓
Systemic Failure

这时系统面对的已经不是 Transaction Failure，而是 Production Incident。

因此，第（三十）篇要解决的问题是：当局部异常开始转化为系统性故障时，AI Agent 平台怎样知道应该停止正常运行？

一、从“事务失败”到“系统事故”，关键变化是什么？

第（二十九）篇主要处理 Command A failed 或 Saga B drifted；Incident 则通常表现为 Failure Pattern：异常不再是独立事件，而开始呈现相关性、持续性和扩散性。

例如过去十分钟 WordPress publish error rate 从 1%、2%、8%、21% 上升到 47%，同时 Retry Queue、DLQ、API latency 与 Worker backlog 都快速上升。如果系统仍把每次失败当成 Independent Failure，它就只会持续 retry，而意识不到依赖本身可能正在故障。

因此 Incident Control Plane 的第一个职责不是修复，而是 Recognize Pattern。

二、为什么 SLO 必须放在事故控制面的最前面？

很多系统的告警来自 CPU、Queue、Error Count 等内部指标，这些指标有价值，但不能直接回答“用户真正受到影响了吗”。

Google SRE 长期使用 SLI、SLO 与 Error Budget 作为可靠性管理基础，并强调 SLO 应真正参与组织决策，而不只是 Dashboard KPI。

SLO Healthy
→ Normal Operation

SLO Degrading
→ Elevated Monitoring

Error Budget Burning Fast
→ Restrict Risk

Error Budget Exhausted
→ Freeze High-Risk Change

因此 SLO 在本项目中应该成为 Production Control Input。

三、SEO / GEO Automation 的 SLO 到底测什么？

传统 Web Service 常见 Availability、Latency、Error Rate。但 SEO / GEO 自动化除了基础设施 SLO，还需要 Business Execution SLO，因为 API 200 并不代表任务正确，例如 wrong content version published 仍然属于严重失败。

SLI	关注点	示例
Availability	服务能否执行	Command Bus 可用率
Timeliness	是否及时完成	发布事务完成时间
Correctness	状态是否正确	正确版本正式发布
Convergence	最终是否收敛	Repair 后 Desired=Observed
Safety	是否产生危险副作用	重复发布/越权操作率

四、本项目建议建立四层 SLO

Level 1：Infrastructure SLO：Command Bus availability、Database availability、Worker processing latency、Queue delay。

Level 2：Execution SLO：例如 99% commands reach terminal state within X minutes。

Level 3：Business Transaction SLO：例如 99.9% approved website publishing transactions reach verified published state without duplicate side effects。

Level 4：Safety SLO：Unauthorized production side effects = 0；Duplicate irreversible actions = 0；Unreviewed high-risk publishing = 0。

对于 production secret leaked、unauthorized DNS change、mass deletion、unapproved mass publish 等事件，更合理的是 Zero Tolerance Event，而不是普通百分比。

五、Error Budget 的真正价值：告诉系统“什么时候不该继续创新”

Error Budget 的价值不是允许系统“故意失败”，而是建立一个客观机制：How much unreliability can we tolerate?

当可靠性低于目标时，平台不应继续把发布速度放在最高优先级，而应允许策略进入 Freeze Publishing，把变化能力留给可靠性恢复与安全修复。

六、从 Error Budget 进一步进入 Burn Rate

只看“本月用了多少 Error Budget”反应可能太慢。真正危险的是 Burn Rate：错误预算正在以多快速度被消耗。

因此事故检测应该同时关注：

Error Budget Remaining
+
Burn Rate
+
Blast Radius

七、Incident Detection 不等于“收到一个 Alert”

Alert 只是 Signal；Incident 是 Correlated Operational Condition。

例如 WordPress 5xx、Retry Queue 上升、Publish latency 上升、DLQ 上升，可能不是四个问题，而是同一个依赖事故的四种症状。

因此需要 Incident Correlation Engine，把 Signals、Events、Symptoms、Dependencies 聚合成 Incident Candidate。

八、事故检测应该优先看“症状”，而不是猜根因

Google SRE 的事故管理实践强调，告警应优先围绕用户可感知的症状与可操作影响，而不是只围绕内部实现原因。

SEO / GEO 自动化应优先关注 Publishing Success、Correctness、Duplicate Rate、Approval Bypass、Convergence、Monitoring Coverage，而不是只关注 CPU、RAM 与 HTTP request 数量。

九、建议建立 Automation Incident Severity

级别	定义	示例
SEV0	极端安全/控制事故	Secret 泄露、失控删除、控制面失效
SEV1	大范围生产影响	批量错误发布、关键系统不可用
SEV2	局部严重影响	单渠道大面积失败、DLQ 快速增长
SEV3	有限影响	小范围降级，可正常 Repair

这些等级属于本项目设计，不是 Google、AWS 或 Microsoft 的统一行业等级。核心目的不是命名，而是让每个 Severity 绑定明确动作。

十、Severity 不能只由“错误数量”决定

建议至少考虑 Impact、Scope、Velocity、Reversibility、Safety、Visibility、Duration。

100 个 Monitoring Record 创建失败但文章全部正确发布，可能只是 SEV2；只有 3 个 Command，却执行 Cloudflare DNS destructive change，则可能达到 SEV0/SEV1。

Incident Severity 是风险函数，不是计数函数。

十一、Retry 什么时候必须停止？

Transient Failure 可以 Retry + Backoff，但如果持续失败，不断重试可能扩大故障。AWS 对 Circuit Breaker Pattern 的说明明确指出，持续对已反复 timeout 或失败的依赖继续重试，会增加网络争用和资源消耗。

Failure
↓
Retry
↓
Retry Budget
↓
Circuit Breaker

十二、Circuit Breaker：第一层自动止血机制

Circuit Breaker 的控制范围应该是 Dependency / Capability Scope，例如 wordpress.publish、github.create_pr、cloudflare.purge、database.write、wechat.create_draft。

当 failure threshold exceeded 时，停止继续向该依赖发请求。它的本质不是 Fix dependency，而是 Stop making dependency worse。

十三、Circuit Breaker 推荐采用三态模型

CLOSED
↓
OPEN
↓
HALF_OPEN
↓
CLOSED

CLOSED：正常执行。

OPEN：依赖被认为异常，请求直接 fail fast、queue、defer 或 fallback。

HALF_OPEN：只允许少量 Probe Request 验证恢复；成功后 CLOSED，失败则重新 OPEN。

十四、Circuit Breaker 必须按能力拆分，不能“一坏全坏”

WordPress Media Upload 失败，不代表 WordPress Read 也失败，更不意味着 GitHub Archive 必须停止。

wordpress.read
wordpress.create_draft
wordpress.publish
wordpress.media_upload

github.read
github.write

cloudflare.purge
cloudflare.dns_write

系统可以让 wordpress.publish=OPEN，同时保持 wordpress.read=CLOSED，从而继续进行 Reconciliation。

十五、Circuit Breaker 与 Permission System 是两件事

Capability 回答：May this Agent do this? Circuit Breaker 回答：Should the platform currently allow anyone to do this?

Decision = APPROVED
AND
Capability = VALID
AND
Circuit = CLOSED
AND
Incident Policy = ALLOW
→ Execute

这说明第（三十）篇加入的是 Runtime Safety Constraint。

十六、Degraded Mode：系统不一定只有“运行”和“停止”

NORMAL
↓
DEGRADED
↓
READ_ONLY
↓
FROZEN

NORMAL：全部功能允许。

DEGRADED：暂停自动生成图片、批量内容刷新、低优先级实验等非关键能力，但保留 Monitoring、Reconciliation 与 Critical Repair。

READ_ONLY：允许 Research、Monitoring、Observation、Analytics、Reconciliation，禁止 Publish、Update、Delete、Deploy。

FROZEN：除 Incident Recovery 外，全部生产副作用停止。

十七、Kill Switch 与 Circuit Breaker 完全不同

Circuit Breaker 是 Automatic、Scoped、Dependency-Aware；Kill Switch 则是 Explicit、High Authority、System-Wide or Domain-Wide。

例如 wordpress.publish circuit=OPEN 只影响 WordPress Publishing，而 GLOBAL_PRODUCTION_WRITE_KILL_SWITCH=ON 则可以同时禁止 WordPress Publish、GitHub Write、Cloudflare Change、Database Mutation、Email Send、WeChat Publish 等高风险副作用。

十八、Kill Switch 必须 Easy / Obvious / Fast

Google SRE 在讨论自动扩缩容时建议保留 Kill Switch 与 Manual Override，并强调 Kill Switch 应容易找到、明显、快速且有完善文档。本文借用这一运行控制原则设计自动化生产控制面。

Emergency Stop 不应依赖“找工程师 → 改代码 → Commit → PR → Deploy”这样的正常变更链路。

Operator
↓
Authenticated Console
↓
STOP PRODUCTION WRITES
↓
Policy Store
↓
Action Gateway
↓
Immediate Enforcement

十九、Kill Switch 不应该直接 Kill Process

直接 kill worker 可能制造 Outcome Unknown、Orphan Command、Partial Saga。更合理的是 Stop New Side Effects，并让 In-Flight Transaction 到达 Safe Boundary 或 Pause Before Pivot。

Kill Switch 应控制 Capability Admission 与 Command Dispatch，而不是简单 Destroy Processes。

二十、需要设计多个 Kill Switch，而不是只有一个红色按钮

GLOBAL_WRITE_STOP
PUBLISHING_STOP
DEPLOYMENT_STOP
AUTONOMOUS_ACTION_STOP
DELETE_STOP

这样 Incident Commander 可以执行 Stop Minimum Necessary Scope，而不是 Shutdown Everything。

二十一、Kill Switch 还必须有 Fail-Safe 默认值

如果 Kill Switch Policy Store 无法读取，高风险 production write、delete、publish、deploy、DNS 等更适合 Fail Closed：Control Plane Unknown → Reject High-Risk Side Effect。

对于 Read、Monitoring、Observation、Health Check 等能力，则可以根据风险设计 Fail Open。

二十二、Kill Switch 本身也是 Tier-0 系统

如果 Emergency Stop 完全依赖正在故障的 Command Bus，就可能出现 Operator 按下 Kill 后，Kill Command 也排在拥堵队列中。

因此 Emergency Control Plane 最好拥有 Separate Path，至少在逻辑上避免完全依赖普通执行路径，并确保 Stop 比 Start 拥有更少依赖。

二十三、Break Glass 是什么？

当 Normal IAM、Policy Engine、Approval System 本身不可用时，正常治理流程可能阻止 Operator 修复生产系统。这时需要 Break Glass：Emergency Privileged Access。

Break Glass 不是“超级管理员方便入口”，而是 Last Resort Control。

二十四、Break Glass 应该与日常管理员身份完全分开

Normal Operator 与 Emergency Operator 应分离。Emergency 身份应 rarely used、strongly protected、independently monitored、regularly tested。

二十五、Break Glass 不能绕过 Audit

紧急权限可以绕过 normal approval，但绝不能绕过 audit。相反，它应该拥有 Stronger Audit：

break_glass_session_id
incident_id
operator
reason
requested_scope
granted_scope
started_at
expires_at
commands
resources
before_state
after_state
revoked_at
reviewer

Break Glass Activated 应自动创建 Incident Event，必要时升级 Severity。

二十六、Break Glass 权限必须短生命周期

Emergency Identity
↓
Explicit Activation
↓
Short TTL
↓
Limited Scope
↓
Auto Expire

例如只允许 cloudflare.rollback，TTL 30 minutes，而不是 All systems forever。Break Glass 的目标是 restore control，而不是 replace governance。

二十七、谁决定“这是 Incident”？

不能让每个 Agent 自己宣布 SEV1。建议加入 Incident Manager / Incident Detector，接收 SLO signals、Burn Rate、Circuit states、DLQ growth、Drift rate、Safety events、Security signals，再生成 Incident Candidate。

只有满足 Incident Policy 后才进入 OPEN INCIDENT。

二十八、Incident Command：事故必须只有一个协调中心

当事故同时涉及 WordPress、GitHub、Cloudflare、Database、Agent Runtime、Monitoring 时，如果多人同时 rollback、deploy fix、retry、恢复 circuit、修改 config，就无法知道哪个动作真正改变了状态。

Google 的 Incident Management Guide 强调事故管理的三个核心目标：Coordinate / Communicate / Control，并使用明确的指挥角色。

二十九、本项目建议建立三类 Incident Role

Incident Commander：负责 Severity、Priorities、Scope、Kill Switch、Recovery decision，核心职责是 Control the incident。

Operations Lead：负责 Diagnosis、Mitigation、Rollback、Circuit control、Repair execution，核心职责是 Fix / Contain。

Communications / Record Lead：负责 Timeline、Status update、Decision record、Stakeholder update，核心职责是 Maintain shared truth。

小团队可以一人承担多个角色，但角色逻辑仍应分离。

三十、AI Agent 在事故期间应该做什么？

事故发生时，Agent 不应该继续 maximize automation throughput，而应该切换 Incident Mode。

Incident Mode 下允许 Observe、Read、Analyze、Correlate、Recommend、Reconcile、Generate rollback plan、Generate impact report；限制 Publish、Deploy、Delete、Mass update、Policy change，除非获得 Incident Capability。

三十一、Incident Capability 必须独立于普通 Capability

普通 Capability 如 wordpress.publish 在事故期间可能被冻结，而 Incident Capability 可以更窄地允许 wordpress.unpublish_known_bad_post 或 deploy.rollback_to_known_good_version。

Incident Capability 应更窄、更短、风险更明确、审计更强，而不是简单授予 admin:*。

三十二、进入事故状态以后，优先目标不是 Root Cause

Detect
↓
Contain
↓
Mitigate
↓
Stabilize
↓
Recover
↓
Root Cause

在用户影响仍然扩大的情况下，Mitigation First, Explanation Later。

三十三、SEO / GEO 平台的 Containment 可以是什么？

如果自动发布内容版本错误，Containment 不一定是删除全部文章，更可能是 PUBLISHING_STOP=ON，然后 Freeze pending publishes、Preserve existing pages、Reconcile affected versions。

如果 Cloudflare write automation anomaly，则 cloudflare.write=DISABLED、cloudflare.read=ENABLED。

如果 Agent planning anomaly，则 AUTONOMOUS_ACTION_STOP=ON，但继续允许 Monitoring、Research、Operator-approved repair。

这就是 Minimum Necessary Containment。

三十四、Incident Control 需要“Blast Radius”概念

异常必须回答影响了多少：1 Command/1 Article 与 2,400 URLs/3 websites/Cloudflare account 完全不是一个量级。

affected_systems
affected_sites
affected_commands
affected_resources
affected_users
affected_time_window

三十五、系统需要自动生成 Incident Snapshot

Incident 创建时应立即冻结一份 Incident Snapshot：

incident_id
detected_at
severity
trigger
SLO state
error_budget_state
burn_rate
circuit_states
kill_switch_states
active_sagas
running_commands
DLQ depth
repair_queue_depth
recent deployments
recent config changes
recent policy changes
affected systems

事故处理过程中系统状态持续变化，没有 Snapshot 就很难还原事故初始事实。

三十六、事故期间必须冻结哪些变化？

推荐把变更分为 NORMAL_CHANGE、EXPERIMENTAL_CHANGE、RECOVERY_CHANGE、SECURITY_CHANGE。

NORMAL_CHANGE = STOP
EXPERIMENTAL_CHANGE = STOP
RECOVERY_CHANGE = ALLOW
SECURITY_CHANGE = ALLOW

这样不会出现“为了恢复生产，却禁止所有恢复修改”的悖论。

三十七、恢复不能以“错误率下降”为唯一条件

必须定义 Exit Criteria：

SLO burn normalized
dependency health stable
no new safety violations
DLQ growth stopped
critical drift reconciled
rollback/fix verified
monitoring stable for observation window

三十八、Safe Recovery 必须分阶段

INCIDENT
↓
CONTAINED
↓
STABILIZING
↓
RECOVERY_PROBE
↓
PARTIAL_RESTORE
↓
OBSERVATION
↓
NORMAL

不能 FROZEN → NORMAL 一步跳转。

三十九、先恢复 Read，再恢复 Write

Monitoring
↓
Read APIs
↓
Reconciliation
↓
Low-Risk Writes
↓
Draft Creation
↓
Approved Publishing
↓
Autonomous Publishing
↓
High-Risk Mutation

Restore Observability Before Automation。如果连现实状态都看不清，就不应该恢复自动写入。

四十、Circuit Recovery 应采用 Probe，而不是全流量恢复

OPEN
↓
HALF_OPEN
↓
Limited Probe
↓
Stable
↓
CLOSED

对 Agent 系统而言，Probe 可以是 1 Draft、1 Read、1 Cache Purge、1 Test Record，而不是直接恢复数百个 queued commands。

四十一、积压任务恢复时尤其危险

系统停机后，如果 Queue 中积累大量 Command，Circuit 关闭后直接全部 dispatch 可能制造 Recovery Storm。

因此需要 Controlled Drain，例如 5% → 10% → 25% → 50% → 100%，每个阶段检查 SLO、Latency、Error、Burn Rate、Dependency Health 后再扩大。

四十二、事故恢复以后不能立即关闭 Incident

Service Healthy 不等于 Incident Closed。还需要 Verify external state、Reconcile outstanding transactions、Resolve DLQ、Review compensation failures、Close repair items、Revoke break-glass access、Reset kill switch state、Archive timeline。

SERVICE_RECOVERED 与 INCIDENT_CLOSED 必须分开。

四十三、Break Glass 必须在恢复后立即撤销

Incident Exit Checklist 必须包括 Break Glass Revoked，并重新确认 Normal IAM restored、Emergency capability expired、Temporary credentials revoked、Temporary firewall rules removed、Temporary bypass removed。

四十四、Kill Switch 恢复也必须经过审批

Enable Kill Switch 可以走 fast path；Disable Kill Switch 应走 slower、higher confidence、approved 的恢复路径。

Stop Fast, Resume Carefully。

四十五、Incident Record 需要哪些字段？

incident_id
severity
status
detected_at
declared_at
contained_at
mitigated_at
recovered_at
closed_at
trigger
symptoms
affected_systems
affected_resources
blast_radius
slo
error_budget
burn_rate
circuits_opened
kill_switches
degraded_modes
incident_commander
operations_lead
communications_lead
break_glass_used
break_glass_sessions
actions
decision_log
related_commands
related_sagas
related_deployments
recovery_plan
exit_criteria
root_cause
contributing_factors
postmortem
action_items

Incident 应成为 First-Class Operational Object，而不是散落在聊天记录里的信息。

四十六、Operator Console 必须升级成 Incident Console

第（二十九）篇的 Operator Console 主要展示 DLQ、Repair、Drift、Orphans；第（三十）篇以后还要增加 Current Incident、Severity、SLO Status、Error Budget Burn、Open Circuits、Kill Switch State、Degraded Mode、Active Break Glass、Blast Radius、Incident Timeline、Recovery Stage。

READ          ALLOWED
RESEARCH      ALLOWED
MONITOR       ALLOWED
REPAIR        APPROVAL
PUBLISH       BLOCKED
DEPLOY        BLOCKED
DELETE        BLOCKED

Operator 最需要知道的是：What is currently allowed?

四十七、Incident Mode 必须传播到所有 Agent

不能出现 Orchestrator knows incident，但 Publisher Agent still publishing。Incident State 必须成为 Global Execution Context，并由所有 Action Gateway 读取同一 Incident Policy。

四十八、Incident State 本身也必须版本化

Incident Policy v14 与 v15 可能允许不同能力。如果 Worker 使用旧缓存，就可能形成 policy drift。

因此需要 incident_policy_version，并在高风险 Side Effect 前重新验证当前 Incident Policy。

四十九、如何处理“监控系统自己坏了”？

如果 Monitoring unavailable，系统是否还能继续 Autonomous Publishing？高风险自动化应该把 Observability 当成依赖。

Monitoring Healthy
→ autonomous publishing

Monitoring Partial
→ approved publishing only

Monitoring Blind
→ production write freeze

无法观察的自动化，不应该保持最高自治等级。

五十、AI Agent 自己能不能触发 Kill Switch？

可以，但不能是“LLM 觉得看起来有问题 → global kill”。应经过 Deterministic Policy。

例如 Safety Violation Confirmed AND Blast Radius > threshold，或 SLO Fast Burn AND Multiple Independent Signals，才允许 AUTO_KILL。模糊判断更适合 Recommend Kill → Human Confirm。

五十一、推荐建立四级自动止血动作

Level 0 — Observe：No restriction。

Level 1 — Throttle：Reduce concurrency、Reduce rate、Delay low priority。

Level 2 — Circuit / Degrade：Open affected circuit、Disable optional capabilities。

Level 3 — Freeze：Stop production writes、Keep observation + repair。

Level 4 — Emergency Stop：Global Kill Switch、Incident Command、Break Glass if required。

这让 Incident Response 从 Binary Stop / Go 升级为 Graduated Containment。

五十二、Automation Safety State Machine

NORMAL
↓
WATCH
↓
DEGRADED
↓
INCIDENT
↓
FROZEN
↓
EMERGENCY

恢复则应该经过：

EMERGENCY
↓
FROZEN
↓
RECOVERY
↓
LIMITED
↓
WATCH
↓
NORMAL

五十三、完整架构现在演进到哪里？

Agent
│
▼
Evidence Plane
│
▼
Risk Engine
│
▼
Governance Decision
│
▼
Decision Trace
│
▼
Capability Issuer
│
▼
Action Gateway / PEP
│
▼
Incident Policy Gate
│
├── Circuit Breaker
├── Degraded Mode
└── Kill Switch
│
▼
Command Bus
│
▼
Execution State Machine
│
▼
Saga Orchestrator
│
├── Idempotency
├── Retry
├── Compensation
└── Outbox
│
▼
Execution Journal
│
▼
Reconciliation Engine
│
├── Drift Detector
├── Orphan Detector
├── DLQ
└── Repair Queue
│
▼
Reliability Control Plane
│
├── SLI / SLO
├── Error Budget
├── Burn Rate
├── Incident Detection
└── Severity Engine
│
▼
Incident Control Plane
│
├── Incident Commander
├── Operations Lead
├── Communications Lead
├── Kill Switch
├── Break Glass
└── Recovery Controller

到这里，系统已经不再只是 AI Agent Platform，而逐渐变成 Production Autonomous Operations Platform。

五十四、本项目的原创判断：自治的上限由“停止能力”决定

很多 Agent 系统都在追求更多权限、更多工具、更多自主执行、更少人工。但生产环境真正的安全上限并不是 Agent 能做多少事，而是：当 Agent 做错、依赖出错、策略出错或系统进入未知状态时，我们能多快阻止它继续做事。

因此 Autonomy 必须与 Interruptibility 同步建设。更强的 Agent 如果没有 Circuit Breaker、Kill Switch、Incident Policy，只意味着错误传播得更快。

五十五、真正成熟的自动化必须满足“两种速度”

正常状态下 Move Fast，事故状态下 Stop Fast，恢复状态下 Resume Slowly。

Execute Fast / Stop Faster / Recover Carefully。

五十六、从 Reliability 到 Resilience

Reliability 关注系统是否稳定工作；Resilience 更进一步关注系统在已经发生严重故障以后，是否还能限制损失并恢复。

Governance
↓
Reliable Execution
↓
Operational Recoverability
↓
Incident Control
↓
Resilience

五十七、第（三十）篇最终结论

第（二十九）篇结束时，我们得到一个判断：可运营系统不是没有异常，而是任何异常都不能悄悄消失。

第（三十）篇再增加一句：韧性系统不是所有异常都继续修复，而是当修复速度赶不上故障扩散速度时，系统知道什么时候停止继续制造新的副作用。

SLO
→ 知道什么叫健康

Incident Detection
→ 知道什么时候不健康

Circuit Breaker
→ 阻止局部故障扩散

Degraded Mode
→ 保留必要能力

Kill Switch
→ 强制停止危险副作用

Incident Command
→ 建立唯一协调中心

Break Glass
→ 正常治理失效时恢复控制

Safe Recovery
→ 分阶段恢复自治

Postmortem
→ 把事故转化为系统能力

整个体系从 AI can act，升级为 AI can act safely，再升级为 AI can fail safely，最终达到：AI Can Be Stopped, Recovered and Trusted Again。

第（三十一）篇预告

当 SLO、Circuit Breaker、Kill Switch、Break Glass 与 Incident Command 建立之后，下一个自然问题是：事故结束以后，系统怎样避免同一种事故再次发生？

第（三十一）篇将进入 Postmortem / Causal Graph / Action Item Governance / Safety Invariant / Regression Guard / Chaos & Game Day，把 Incident Response 继续升级为 Organizational Learning + Reliability Engineering。

来源与延伸阅读

• Google Site Reliability Engineering — The Art of SLOs
• Google SRE Workbook — Error Budget Policy
• Google SRE Workbook — Alerting on SLOs
• Google SRE — Incident Management Guide
• Google SRE Workbook — Managing Load
• AWS Prescriptive Guidance — Circuit Breaker Pattern
• Microsoft Entra — Manage emergency access accounts
• Microsoft Entra — Security operations for privileged accounts