生产事故发生时，工程师的平均反应时间不是被技术卡住的——是被自己的肾上腺素。谷歌SRE团队跟踪了2000+起P0级故障后发现，前10分钟的决策质量直接决定恢复时长，而多数人在这10分钟里只做了一件事：疯狂刷新监控面板。

这套被内部称为「Triage Tree」的决策框架，本质上是一份「大脑宕机时的操作清单」。第一步不是查日志，而是确认「影响范围」——1%的用户报错和100%的服务挂掉，后续动作完全不同。第二步锁定「最近变更」，83%的生产事故与部署相关，这个时间点查CI/CD流水线比grep日志快得多。

第三步是谷歌SRE总监Emil Stolarsky反复强调的：「先止血，再解剖」。他见过太多团队一边服务还在熔断，一边试图理解根因，结果两头落空。框架要求前10分钟只做止损动作——回滚、限流、切流量，根因分析留给事后复盘。

第四步和第五步分别对应「通知升级」与「记录时间线」，但有个细节很多人忽略：通知必须按预设的on-call链执行，而不是在Slack里@所有人。Stolarsky的原话是，「混乱时的广播只会制造更多混乱」。

这套框架现在被整理成开源决策树，但评论区最高赞的反馈来自一位Netflix工程师：「真正救命的不是树，是凌晨3点有人把树打印出来贴在显示器旁边。」