SH

Soloharness

概念 · 故事 · Agent

← 返回概念解读

Concept Fable精修版

事故响应

Incident Response · Operations / security

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

钟楼起烟后,谁先去敲哪一口钟

松岭城有一座钟楼,城里发生紧急情况时,就靠钟声通知各处。小火敲三下,水灾敲五下,城门告急敲七下。平常没人注意这套规矩,因为最好永远用不上。

有天傍晚,钟楼顶层冒出烟。第一个看见的是卖栗子的摊主。他大喊起火了,路人跟着跑,守卫冲向城门,水夫跑去井边,书记官却还在等正式命令。每个人都在动,但没有人知道谁负责判断火势、谁负责封街、谁负责通知医馆。

烟越来越大,真正耽误时间的不是没人帮忙,而是所有人都在按自己的理解帮忙。有人把人群往窄巷赶,有人重复取水,有人跑去找不在城里的塔匠。混乱让小火差点变成大火。

火灭之后,城主没有只问是谁失误。他问了四个问题:谁最先发现,谁确认严重程度,谁有权下令,谁负责对外说明。屋里没人答得完整。

于是城里重新写了一套应急册。第一步是识别:任何人看到烟,都能拉响低级警铃。第二步是分级:值班长在十息内判断是小火、结构风险还是全城警报。第三步是止血:水夫灭火,守卫封街,医馆待命。第四步是沟通:书记官每半刻钟更新一次消息。第五步是恢复和复盘:火灭后检查损失,记录原因,修订规矩。

几个月后,粮仓又起烟。这一次,摊主拉铃,值班长分级,水夫和守卫各就各位,书记官告诉商户绕行。火很快被控制住。没有人显得特别英勇,但每个人都知道自己该做哪一段。

松岭城后来明白,事故响应不是等英雄出现,而是让普通人在混乱里也能按顺序止血、恢复、解释和学习。真正成熟的城市,不是假装不会起火,而是起火时不会失声。

揭示

这个故事讲的是:事故响应

事故响应 Incident Response 是系统发生故障、安全事件、质量事故或业务风险时的一整套处理流程,包括发现、分级、止血、隔离、恢复、沟通、取证和复盘。对 Agent 系统来说,事故响应能避免模型错误、工具误用、数据泄露或流程故障持续扩大,并把一次事故转化为系统改进。

它重要的地方在于:它不只是一个术语,而是在真实 AI / Agent 系统里会反复出现的结构性问题。理解它,才能判断什么时候该加模型,什么时候该改流程,什么时候该补治理。

隐喻映射

  • 钟楼冒烟:AI / Agent 系统出现故障、异常输出、安全事件或业务事故
  • 摊主最先发现:用户、监控、日志或一线人员发现异常
  • 所有人按自己的理解帮忙:没有事故响应流程时的混乱协作
  • 四个问题:发现、分级、决策权和沟通责任
  • 低级警铃:事故触发和告警机制
  • 值班长分级:Incident severity 分级和响应优先级判断
  • 水夫灭火、守卫封街、医馆待命:止血、隔离、恢复和应急资源调度
  • 书记官定时更新:事故沟通机制,避免内部和外部信息混乱
  • 恢复和复盘:Postmortem 与长期修复,把事故转化为系统改进

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

SREsecuritypostmortem