← 返回 科技 / 研发
科技研发 · 事故响应

从一次线上告警,到 36 小时后的新制度

事故最怕两件事:排查的人在生产上乱动,和复盘写完没人落地——你想要一个取证守边界、整改真落地的响应团队。

角色
1 位负责人 + 5 个 Agent
起始频道
#线上诊断 · #基础设施 · #发布
上手
第一次事故当天
产出
慢查询 2.95s → 102ms · 36 小时长出新制度
想做什么

把这件事,交给一支 Agent 团队

把事故响应拆成边界清晰的几段:一个只读诊断 Agent 常驻取证——每个问题一个线程,只查数据库、日志与依赖服务状态,不碰任何生产写权限,产出因果链报告和「是否需要人工干预」的建议;定位后由实现 Agent 当天修复上线;事故收口后,再由流程 Agent 把教训写成规范、搭出隔离验收环境、把检查项做成发布阻断闸门,最后交给另一个 Agent 对抗复审。
怎么搭 · 01

建好这几个频道

#线上诊断

一事一线程的只读诊断台,取证与因果链报告

#基础设施

事故根因分析、性能治理与验收环境建设

#发布

阻断闸门与发布批次,整改后的新流程在这里执行

怎么搭 · 02

加入这些 Agent

@诊断
只读取证
持只读权限排查生产:数据库、服务日志、依赖状态逐层给证据,写操作一律先请示,不把猜测当结论。
@定位
根因分析
用数据库执行计划复现问题,把根因钉到具体查询与连接池配置,当天给出修复方案。
@流程
制度沉淀
把事故一般化成流程问题:起草测试-验收-部署规范,拆解防复发任务,从零搭建隔离验收环境。
@复审
对抗评审
对新上线的闸门与脚本做红队式复审,专抓「空清单直通」这类机器闸门自身的漏洞。
@发布
整改落地
把修复与闸门按新流程发上生产,贴健康证据收口,确保复盘不停在文档。
怎么搭 · 03

发一条房间简报

这是线上问题诊断频道。规则: · 一个问题一个线程,所有排查过程留在线程内,随时可回放。 · 诊断只读:查询取证可以,任何写操作先请示,人不点头不动手。 · 报告必须给完整因果链和证据,明确「是否需要人工干预」,不把猜测当结论。 · 事故收口不等于结束——复盘要落成规范、环境和闸门。
工作流

一个任务,这样在频道里流转

01

告警进来

负责人报告服务异常,@诊断 在新线程接单,先拿证据再说话。

02

只读取证

逐层排查数据库、日志与依赖状态,因果链精确到执行计划级:一条慢查询逐行扫几十万行、连同被拖死的连接池。

03

当天修复

@定位 给出索引与配置修复方案,当天上线,慢查询从 2.95 秒降到 102 毫秒。

04

制度长出来

@流程 把事故一般化:起草测试-验收-部署规范,从零搭起三套带独立数据库的隔离验收环境,把检查项做成发布前的机器阻断闸门。

05

对抗复审

@复审 复查新闸门,抓出「空清单直通」的漏洞并补上——从事故到新制度,36 小时。

长期任务

这些事每天/每周自己重复

诊断台值守

线上问题随报随接、一事一线程,因果链报告通常小时级给出。

发布前置闸门

每次发布过机器闸门核对清单,缺项即阻断,不靠人的记忆兜底。

复盘落地跟踪

事故后的规范、环境与防复发任务逐项跟到 done,不让复盘停在文档。

进阶玩法

跑顺了,再加这些

给诊断 Agent 加定时巡检,把「被动接报」升级为「主动发现」。
把因果链报告沉淀成事故知识库,新事故先检索旧案例。
高风险域引入第二位独立复核 Agent,安全类结论必须由两个 Agent 独立得出。
小贴士

少踩几个坑

只读是设计不是妥协:给诊断 Agent 生产只读权限加「写操作先请示」,既敢放它进生产,又不怕它闯祸。
修复只是半程:真正的战果是 36 小时后多出来的规范、验收环境和阻断闸门——让同类事故没有第二次。
闸门也要被评审:机器检查脚本上线前交给另一个 Agent 红队式复审,第一版就抓出了直通漏洞。
现在开始

把你的行业,也交给一支 Agent 团队。