工程师花2周做的AI工具：事故调查从3小时缩到30秒，但有个坑

一个NOC（网络运营中心）老兵花了14天做了一款工具，能把事故调查报告的撰写时间从3小时压到30秒。但他在发布帖子里写了三遍"还没准备好"——这种自我拆台的操作，在硅谷创业叙事里几乎绝迹。

这反而让人想多看两眼。

从"写报告太烦"到"真相太难挖"

Opsrift的起点很朴素。作者@theopsdrift在Reddit自述：postmortem（事后复盘报告）、交接班文档、事故记录——这些活儿耗时长、重复性高，"像用Excel手动对账"。

但做着做着，他发现真正的卡点不是"写"，是"懂"。

写报告只需要把已知信息结构化，但搞清楚事故里到底发生了什么，需要在Jira、PagerDuty、Opsgenie、GitHub之间反复横跳。

一个典型场景：凌晨2点告警响了，值班工程师得同时打开四个标签页，手动对齐时间线——哪次代码提交触发了这次故障？哪个服务的降级是根因，哪个只是症状？

Opsrift想干的就是这个：把散落各处的数据串成一条能看懂的时间线。

现在的功能：AI当"翻译"，不当"替代"

目前平台对接了Jira、PagerDuty、Opsgenie拉取事故数据，同时关联GitHub的部署记录。核心输出是三样东西：

结构化postmortem——秒级生成，不是模板填空，是基于数据关联的叙事；

交接班摘要——把混乱的更新流变成干净的手册；

可复用的runbook（标准操作手册）——从 incident 模式里提炼步骤。

作者给自己划了三条红线：不替代现有工具、不完美做根因分析、不承诺生产级稳定性。定位很明确：现有工具之上的AI层，专门加速调查和文档环节。

登录方式暴露了真实进度——GitHub登录和Slack登录都有bug，只能用邮箱注册。这种"半成品坦诚"在toB工具里反而少见。

作者真正想问的：这是真需求还是伪痛点？

帖子后半段全是开放式问题，几乎像在写用户调研问卷：

「Incident Investigator功能到底有用，还是只是"锦上添花"？」

「输出结果准确到能信吗？」

「真有人愿意把它塞进现有工作流？」

「缺什么才能从"能用"变"必须用"？」

这种姿态和典型AI产品发布形成反差——后者通常先画饼再迭代，Opsrift的作者却反复预警两种死法：要么变成"又一个没人看的dashboard"，要么沦为"AI幻觉生成器"。

他的长期路线图也偏保守：跨事故模式检测、识别不稳定服务、自动关联部署与故障——全是"让数据可行动"，而非"让AI替你做决策"。

为什么这个案例值得盯一眼

SRE（站点可靠性工程）领域有个老问题：工具链越堆越多，调查反而越来越慢。PagerDuty管告警、Jira管工单、GitHub管代码、Datadog管监控——每个都好用，但之间的缝隙全靠人肉填。

Opsrift的解法不新鲜（数据整合层），但切入点精准：不做又一个All-in-One平台，只做"调查加速"这一件事。

风险同样明显。AI生成的postmortem如果事实错误，比没写还糟——工程师会花更多时间验证AI，而非信任它。作者自己也承认"还没解决准确性问题"。

另一个隐患是权限。要跨工具关联数据，意味着需要读取Jira工单、PagerDuty告警、GitHub提交记录——这在安全敏感的企业里是硬门槛。

帖子发布24小时内，评论区出现了几种典型反馈：有人想要On-Call（值班）排班集成，有人质疑AI时间线会不会漏掉关键上下文，还有人直接说"我们内部已经用脚本解决了类似需求"。

作者逐条回复，没有防御姿态。

这种"边做边问"的发布方式，在AI工具泛滥的当下反而成了差异化信号——不是"我做了个颠覆性的东西"，而是"我在解决一个具体的问题，但不确定解对了没有"。

如果你也在SRE或运维团队，会愿意给一个"只加速调查、不替代工具"的AI层开权限吗？还是宁可继续手动对账，至少知道错在哪一步？