一篇关于“AI SRE”的博客文章最近在运维圈流传，作者是Rootly员工、曾任LinkedIn SRE的Sylvain Kalache。他的核心担忧很直接：AI处理常规故障越顺手，工程师练手的机会就越少——等真正复杂、AI搞不定的大事故来了，响应者反而会因为缺乏练习而手忙脚乱。这个判断本身没错，但值得追问一句：现在的AI SRE，到底自动化到了哪一步？
说是“自己修复”，产品文档写的是“等人点头”
原文里有一句话很扎眼：这些工具能“inspect alerts, form hypotheses, query telemetry, correlate recent deployments, and even implement the fix themselves”——甚至自己实施修复。但翻一遍主流产品的官方说明，画风不太一样。
Rootly AI SRE在执行变更前需要人工批准，官方定位是“增强响应者”而不是替代责任人。PagerDuty SRE Agent推荐并执行的是“已批准的工作流”，反复强调人工监督和安全控制。Datadog Bits AI SRE里那个听起来最激进的Kubernetes一键操作能力，目前还标注着“Preview”预览阶段，涉及代码的修复通常仍要走Pull Request走人工审核。
三家产品在“自动修复”这个环节，都留了一道人工闸门。
这不是说AI SRE没用，只是它目前的角色更像一个反应极快的初审员，最后一步的责任还留在人身上。这一点，跟原文给读者的印象有出入。
厂商晒的效率数字，彼此没法比
三家公司各自秀出的成绩单也很好看：Rootly宣传AI SRE能让事故解决速度提升“10倍”；Datadog的博客称Bits Investigation功能能把解决时间降低最多“95%”；PagerDuty给出的数据是使用其平台的组织MTTR平均降低“27%”，MTTA平均改善“66%”。
三个数字，三种口径，谁也不知道对照的基线是什么、统计窗口多长、有没有把拖后腿的复杂故障算进去。
问题不在于数字造假，而在于这些数字全部来自厂商自述，没有独立基准测试，也没有披露P95/P99这类尾部时延、根因识别准确率、自动修复后的回滚率。换句话说，“AI SRE让平均处理速度变快”这句话大概率是真的，但“复杂故障有没有因此变慢”，目前没人给出证据——原文提出的“MTTR悖论”，还停留在理论推演，没有实证支撑。
- 风险.如果企业只盯着平均MTTR选型，很可能买到一个“常规事故很快、复杂事故说不清”的系统，却完全看不出来。
飞行员的复训制度，才是可操作的参照
Kalache拿航空业作类比不是没有道理。现代涡轮发动机的空中停机故障率低于每十万飞行小时一次，稀有到一个机长可能一辈子都不会在真实飞行中遇到，但美国FAA仍然要求机长每六个月完成一次复训或能力核查，其中就包括起飞时引擎失效这类场景。FAA的咨询通告AC 61-137B把这套制度的目的写得很清楚：唤醒那些“不常用但要命”的技能，模拟器能重现现实中难以安全复现的高负荷场景。
这套逻辑挪到软件事故响应里，比“AI取代人”或“人取代AI”的二元焦虑更有操作性——关键不是要不要用AI SRE，而是有没有配套的强制练习机制。Rootly与Uptime Labs合作的事故模拟训练，就是把这个思路落地：工程师在模拟的电商故障里当指挥官，一边用可观测性工具排查，一边应付Slack里由LLM扮演的CEO和客服，练的是判断力和协调能力，而不是背答案。
常规故障交给AI，复杂故障留给人，前提是人得先练够。
这类模拟训练也有边界：再逼真的场景也复现不了生产环境真实的不确定性和真实利益相关方的压力，看AI复盘排障步骤能学到一点东西，但看和练不是一回事。对工程管理者来说，眼下更实际的动作或许是先把“自动修复”和“人工审批”两个环节在合同和SLA里说清楚，再问一句：如果没有强制的定期演练，团队的排障手感，还能撑到下一次大事故来临吗？