2012年我在领英（LinkedIn）担任SRE时，曾设计过一个可自行修复并从过往事件中学习的系统。当时的AI能力与如今相去甚远，那个系统仅停留在原型阶段，但如今这已成为现实。这些工具能完成所有工作：检查告警、提出假设、查询遥测数据、关联近期部署，甚至自行实施修复。尽管我很乐于看到这一幕，但我有个重大担忧：我们正与自己的系统逐渐脱节。

2012年我在LinkedIn做SRE时，设计过一套能自我修复并从之前事故中学习的系统。当时AI能力远不如现在，它一直只是原型；如今这已变成现实。

这类AI事故响应工具会做很多事：检查告警、提出假设、查询遥测数据、关联近期部署，甚至自己动手实施修复。我虽然乐于看到这些，但有个主要担忧：我们正在和自己的系统脱节。工具越擅长解决常规事故，人类响应者练习的机会就越少；一旦出现模糊、高严重度、自动化无法解决的事故，接手的工程师会很难受。

这些工具通常被叫作“AI SRE”——这个叫法我并不太喜欢。它们确实有很多好处，尤其当它们凌晨自己处理掉一起常规事件，你不用为容量问题被叫醒时，感觉像魔法。问题在于，常规事件正是响应者“安全地”建立对系统运行和故障方式直觉的机会。AI遇到从未见过、无法解决的疑难事故时，工程师终究要接手，可当时的练习量已经比不上从前了。

人因研究者Lisanne Bainbridge在1983年那篇著名的论文《自动化的反讽》中描述了这个悖论：自动化让操作者少了练习常规工作的机会，却仍要他们为新的异常情况负责。她由此认为，自动化之后的操作者反而需要更熟练、也受更多训练。

我预测，未来几年多数事故的平均MTTR会因AI事故响应而下降，但复杂事故的解决时间会飙升，因为响应者已经摸不准自己的系统，调查起来会很吃力。

可以从航空业找启发。飞行自动化承担了大部分驾驶，但飞行员仍要为自动化应付不来的情况负责：发动机失效、仪表不可靠、中断起飞、失速等异常。这些情况极少见：现代涡轮发动机每10万发动机飞行小时发生不到一次空中停车。少到一名商业飞行员整个职业生涯可能都只在模拟器里遇到过，从未在真实航班上经历。可故障一旦发生，飞行员必须快速正确应对。复兴航空235号班机起飞后不久，右发动机螺旋桨自动顺桨；飞机本可靠左发动机继续飞行，但机组误判了故障。飞机失速，在首个警告后仅117秒坠毁。所以民航飞行员会定期回模拟器复训罕见紧急情况。按美国FAA规定，机长每六个月要完成复训或熟练检查，项目包括起飞时发动机失效。

多数软件事故不危及性命，但没理由因此不磨练手艺。制造这个问题的自动化技术，也可以用来帮助我们补上缺口。

我所在的Rootly与Uptime Labs合作，把这个想法落到逼真的模拟训练里：工程师坐在模拟电商故障的事故指挥席上，一边用可观测性工具，一边在Slack里和LLM扮演的相关人员协调。仿真很真实，你得一边调查故障、维持响应秩序，还要应付CEO和客服。练习的正是事故中最要紧的能力：在信息不完整时理清状况、清楚沟通、协调人员、实际统筹整场响应。

能不能让AI当教练？响应者可以请智能体解释它执行过的步骤、查看过的信号和诊断依据。但解释和观察替代不了练习。看塞雷娜·威廉姆斯打球也许能学到点东西，但学网球得上场打才行，事故响应也一样。

我职业生涯里有五年多在办一所软件工程学校，核心是“做中学”。学校是线下实体，但没有老师；学生做项目而不是听课。Dropbox告诉我，他们招去的毕业生排障仍然太生疏，于是我就设计了一些项目，给学生一套坏掉的基础设施，让他们自己诊断和修复。对大多数动手类技能，动手教育远胜于被动听课。

随着LLM承担越来越多工作，工程团队存在积累“理解债”的风险：系统实际运作方式与响应者理解之间的差距会不断拉大。工程师应当定期接触自己照看的系统，处理不熟悉的故障，练习在压力下工作，演练SEV0事件中所需的协调与沟通。桌面演练和混沌工程并不新鲜，但在LLM时代，练习变得更加重要。

Bainbridge当年就建议，定期让操作者手动控制系统，并用模拟来防止技能退化。这就是自动化的反讽：它越成功，人类越没准备好迎接它失效的那一刻。

讨论整体对AI接管常规运维、导致工程师逐渐丧失系统直觉表示担忧，少数乐观者认为抽象层级会自然迁移，不必过度焦虑。

认为过度依赖AI会侵蚀工程师的系统直觉与排查能力

• 许多人指出，随着AI逐步承担常规编码和排障工作，工程师亲手操作的经验越来越少，对代码和系统的心智模型会逐渐弱化，最终面对AI无法解决的极端故障时将无力应对（较多人）
• 有观点认为，这种直觉流失本身就会成为技术债的源头，时间久了连自己写的代码库都会变得像陌生项目，维护成本会不断累积（较多人）
• 也有实际案例提到，部分团队面对简单问题，因过度依赖AI反而绕了远路，本可以用传统排障方式快速解决，体现出工具依赖带来的认知脱节（较多人） > 我给了团队一个现成的解决方案，他们还是花三天对着Claude折腾也没搞定，其实只要一行代码，耐心用老方法排查半小时就能出来（@bob1029）

认为用航空业类比软件运维并不恰当

• 不少人指出，航空场景中飞行员并非飞机的设计和维护者，且飞行系统不会频繁变更，而软件工程师本身既是系统构建者也是运维者，系统还在持续迭代，两种场景的故障处理逻辑完全不同（较多人）
• 也有观点补充，航空业的灾难性事故倒逼出了强制的模拟训练体系，而软件领域即便没有AI，多数公司也不会主动投入资源做故障演练，单纯套用航空类比忽略了行业现实差异（较多人） > 软件领域的失败不会像航空那样致命，而且你操作的系统本身还在随时变化，用航空场景来要求SRE做演练，教的是如何应对故障，而不是如何排查独一无二的根因，这本来就不符合软件工程的逻辑（@smugglerFlynn）

认为AI会摧毁工程师的成长路径而非直接降低故障处理能力

• 部分观点认为，真正的风险不是人在处理极端故障时能力不足，而是AI接管了所有常规工作后，新人失去了从日常实践中积累经验、成长为资深工程师的路径，未来会面临资深人才断层的问题（较多人）
• 另有观点提到，当前行业已经存在大量因人员流动、裁员导致的系统知识流失问题，AI反而可能成为反向补全知识的工具，帮助团队梳理遗留系统的逻辑（少数人） > 我们担心的应该是专家职业路径被破坏，而不是人不会处理故障，那些复杂问题本来就需要深度系统知识，过去需要，未来也还是需要，只是培养专家的路径正在被AI切断（@gnfargbl）

认为应通过工具革新和流程设计适配AI时代

• 有观点提出，不应把AI当成完全的自动化工具，而应采用“半人半机”的模式，让AI辅助人成为系统的主导者，而非让人沦为工具的附庸（较多人）
• 也有建议认为，需要建立新的开发范式，比如更强调架构边界约束、高风险区域的人工审核，以及配套的分析工具帮助工程师快速理解快速迭代的代码库，而非沿用旧的管理方法（较多人）
• 还有意见指出，若要让SRE重视故障演练，需要像航空业一样建立专业资质认证体系，通过强制标准避免企业为了利润压缩必要的培训成本（少数人） > 想要SRE花时间做灾难训练，就得把这项工作纳入职业执照的考核要求，不然没有公司会主动投入，毕竟这类工作既不出彩也不直接产生收益（@solatic）

有价值的补充

• 自动化领域经典论文《自动化的讽刺》早已指出类似问题：当系统自动化程度越高，人类在需要接手时往往越难有效应对，本次讨论的很多观点都是对该论文结论的复现
• 控制转移中的“颠簸式控制权交接”概念值得关注：当AI系统把故障处理权交还给人类时，往往会因为信息传递不充分、人类状态不匹配导致处理效率骤降
• 类似问题在客服领域已经先发生：现在的客服人员大多只能按系统提示的选项操作，即便有能力解决复杂问题也失去了自主处置的权限，软件行业正在重走这条路，失去系统理解力之后，自主处置权也会随之流失
• 有实践者提醒，使用AI时最好只将其作为思路校验或快速总结的工具，盲目信任AI去调试复杂系统很容易陷入无效排查的死循环