这是什么
一款针对功能开关事故的取证工具。它能读取 LaunchDarkly、Unleash、Flagsmith、GrowthBook、你自己的审计表或普通笔记中的变更记录。
功能开关事故取证
找出搞垮生产环境的那次开关变更。
Flag Autopsy 把功能开关的变更记录和错误率或延迟曲线放在一起，找出峰值开始的时刻，并按可能性给每次变更排序。你会得到头号嫌疑、关掉它所用的时间，以及一份可直接放进复盘的报告。
CASE 0421结账错误
- 1pricing_cache 25% → 50%
- 2checkout_v2 0% → 50%头号嫌疑
- 3dark_mode 开启
适合谁
需要尽快知道该回滚哪个开关的值班工程师、发布负责人和 SRE，以及事后撰写复盘的团队。
解决什么问题
错误率飙升时，过去一小时里可能已经改了五个开关。不必再靠猜，你能直接看到哪次变更与峰值吻合，以及证据是什么。
开始尸检
粘贴变更记录，如果有的话再粘贴事故前后的指标。所有分析都在本页完成，不会上传任何内容。
支持 JSON 行、JSON 数组，或类似这样的纯文本行： 14:02 mira turned on checkout_v2 in prod 50%
每行一个时间和数值，例如 14:03,2.9。错误率、5xx 数量或 p95 延迟都可以。可选。
仅在没有指标时需要。例如 14:03 或 2026-10-21 14:03。
结论会显示在这里
粘贴变更记录后点击“开始尸检”，或打开示例案件查看完整报告。
判断依据
分数代表证据，而不是定论。它告诉你应该先查哪里。
峰值检测
每个点都会和它之前各点的中位数比较。当某个值至少达到正常水平的两倍，并且明显超出平常的波动范围时，就视为峰值开始。
时间
峰值前几分钟内的变更得分最高。之后一小时内分数逐渐降低，远晚于开始时间的变更不计入。
前后对比
对每次变更，比较它前后 15 分钟内的指标。上升越明显，分数越高。
影响面
开启开关或提高放量会增加嫌疑，跳得越大越可疑。关闭开关或非生产环境的变更会降低嫌疑。
验证
如果关掉开关后 20 分钟内指标恢复，这就是最有力的证据。
规范
另外还会标出容易引发事故的习惯：跳过预发、放量跳得太猛、反复开关、深夜修改以及没有操作人的变更。
使用方法
导出变更记录
复制开关平台在事故时段内的审计日志，或者按时间手动写下变更。
加入指标
从监控面板导出错误率或延迟，格式为时间和数值。没有指标的话，就填写事故开始时间。
查看结论
查看头号嫌疑、相关证据和图表。标记会准确显示每次变更发生的时间。
分享报告
把报告复制到事故频道，或下载为 Markdown 用于复盘。
注意事项
- 不带时区的时间按原样读取，带时区的时间会换算成 UTC，所以请让两份输入使用同一个时区。
- 纯文本行用英文书写时识别效果最好，JSON 字段则不限语言。
- 时间吻合不等于因果。同一时刻的部署或流量激增不会出现在这里。
- 所有内容都不会离开你的浏览器。分享报告前请删去密钥和个人信息。
常见问题
支持哪些功能开关平台？
只要能复制审计日志的平台都可以。key、flag、environment、user、from、to、rollout 等常见字段名会被自动识别。
没有指标怎么办？
填写事故开始时间即可，变更会只按时间、影响面和环境排序。
为什么预发环境的变更得分为零？
预发环境的变更不可能直接搞垮生产，所以会被排除。不过对之后的生产变更来说，它仍算作经过了预发这一步。
嫌疑度是概率吗？
不是。它是各项证据的加权和，上限为 95，因为这类工具永远无法做到百分之百确定。