文章揭示工程师过度依赖 AI 处理生产事故,导致自身对系统细节理解退化、问题排查能力萎缩的现象与应对策略。
当我还作为一名 SRE 在 LinkedIn 工作时,那是 2012 年的事了,我设计了一个能够自我修复并从过往事件中学习的系统。当时的 AI 能力远非今日可比,这个想法最终只停留在了原型阶段,但现在它已经成为了现实。
这些工具包揽一切:检查告警、形成假设、查询遥测数据、关联近期的部署变更,甚至自行执行修复。我对此感到欣喜,但我有一个重大的担忧:我们正在失去对自己系统的感知。
这些工具在处理常规事件上越高效,人类响应者能够获得的实践机会就越少。而当一个模糊不清、高严重性的事件发生——自动化无法解决的那种——接手处理的工程师将会陷入困境。
这些 AI 辅助的事件响应工具(更常见地被称为"AI SRE"——我不太喜欢这个称呼)在很多方面都表现出色。当它们在深夜处理了一个常规事件,而你无需为此爬起床去处理容量问题时,这种感觉尤其神奇。
问题在于,常规事件也是响应者"安全地"培养对系统行为和故障直觉的方式。当 AI 遇到一个艰难的、前所未见的事件而无法解决时,工程师们将不得不接手,但他们拥有的实践经验会比以前更少。
人类因素研究员 Lisanne Bainbridge 在她 1983 年的著名论文《自动化的讽刺》(The Ironies of Automation)中描述了这个悖论。她解释说,自动化减少了操作员练习常规工作的机会,同时却让他们对新情况和异常情况负责。因此,她认为操作员需要比自动化之前更有技能、接受更多的培训。
在未来,我预测大多数事件的平均 MTTR(平均恢复时间)将会下降——这要归功于 AI 辅助的事件响应——但对于复杂事件,解决时间将会急剧上升,因为事件响应者已经与他们的系统失去了联系,正在艰难地进行调查。
我们可以借鉴航空业的经验。
飞机自动化处理大部分飞行工作,但飞行员仍然对自动化无法处理的情况负责:发动机故障、仪表不可靠、起飞中断、失速以及其他异常情况。
这些事件极为罕见。例如,现代涡轮发动机每 10 万发动机飞行小时经历的空中停车次数不到一次。换句话说,罕见到一名商业飞行员可能在整个职业生涯中都不会在模拟器之外经历一次。
但当故障发生时,飞行员必须迅速而正确地做出反应。例如,在中华航空 235 号航班上,右发动机的螺旋桨在起飞后不久自动收回了(autofeathered)。虽然飞机设计上可以在左发动机单发的情况下继续飞行,但机组人员误判了问题。飞机在首次警告后仅 117 秒就失速坠毁。
航空公司飞行员定期回到模拟器进行稀有紧急情况的演练。根据美国 FAA 的规定,机长必须每六个月完成一次复训或熟练度检查,包括起飞时发动机故障等场景。
虽然大多数软件事件不会威胁生命,但这不是我们不去完善专业技能的理由。事实证明,创造这个问题的技术也可以帮助解决它。
在我工作的 Rootly,我们与 Uptime Labs 合作,通过逼真的事件模拟来应用这个想法。工程师在模拟的电商宕机事件中担任事件指挥官的席位,在使用可观测性工具的同时,与 Slack 中由 LLM 驱动的相关方进行协调。
其结果感觉非常真实。你必须在保持响应有序的同时调查哪里出了问题,还要应对 CEO 和客户支持的压力。你练习的是在事件中真正重要的技能:理解不完整的信息、清晰沟通、协调人员,以及实际运行整个响应过程。
但如果把 AI 用作训练者呢?响应者可以要求一个 Agent 解释它采取的步骤、它检查的信号以及诊断背后的证据。
但解释和观察不能替代实践。你可能会从观看 Serena Williams 打球中学到一些东西,但只有走上球场才能学会打网球,事件响应也不例外。
在我的职业生涯中,有超过一半的时间用于建立一所软件工程学院,围绕着渐进式教育:做中学。这是面对面的,但我们没有老师;学生做项目而不是听讲座。当 Dropbox 告诉我它雇用的毕业生在故障排查方面仍然经验不足时,我创建了一些项目,让学生面对损坏的基础设施,并要求他们诊断和修复。对于大多数实践技能,我相信动手教育比被动讲授要好得多。
随着 LLM 做更多的工作,工程团队可能会积累理解债务(comprehension debt):他们的系统如何运作与响应者对它们的理解之间存在越来越大的差距。
工程师应该定期与他们监控的系统互动、处理陌生的故障、在压力下练习工作,以及排练在 SEV0 期间所需的协调和沟通。桌面推演和混沌工程并不是什么新鲜事,但在 LLM 时代,实践变得比以前更重要了。
研究员 Bainbridge 建议让操作员定期进行实际控制,并使用模拟来防止他们的技能退化。这就是自动化的讽刺——它越成功,当它失败时,人类可能就越没有准备。
AI Labs 负责人兼 Rootly 的 DevRel。前 LinkedIn SRE 和 Holberton School 联合创始人。