\n\nAI加速开发使运维陷入高频修复循环。本文建议通过事件驱动自动化、智能响应及AI代理处理杂务，帮助团队摆脱“救火”模式，将精力重新投入创新，实现系统自愈。
译自：3 steps to escaping the “break-fix” trap
作者：Cristina Dias
客户和高层管理人员对改进数字服务和新功能的需求，正将数字化运营推向崩溃边缘。业务负责人希望开发团队能定期构建并发布新功能以改进服务。然而，随着 AI 辅助编码工具帮助开发人员满足这些日益增长的期望，它们也给运维团队增加了压力。
部署的代码越多，意味着潜在的故障点就越多。手动管理数字化运营的团队面临被 AI 加速开发所带来的事故量和速度淹没的风险。他们曾经依赖的工作流程正在崩溃，并且面临陷入“故障-修复”陷阱的风险——在这种陷阱中，救火式的工作让他们没有时间重新思考流程以减少未来的事故。
“制造运营复杂性的 AI，同样也可以解决复杂性。”
但这里存在一个悖论：制造运营复杂性的 AI，同样也可以解决复杂性。那些像支持 AI 辅助开发一样，以同样的热情在运营中拥抱 AI 的组织，正在超越那些仍受困于被动响应模式的竞争对手。
“故障-修复”循环是如何根深蒂固的
AI 生成代码的数量和速度导致问题激增，使资深工程师脱离战略性工作，陷入告警分选。当缺乏智能告警过滤、关联、分类和上下文时，团队就会陷入被动响应模式。持续不断的告警噪音让工程师无法确定通知的优先级，他们最终可能会浪费时间处理非问题，而真正的故障却被掩盖了。
如果团队还缺乏自动化工作流或标准化的事故响应协议，这些挑战就会被放大。由于没有固定的工作流，每起事故都被视为偶然事件，这增加了许多运维职能部门最负担不起的低效率。当响应者必须管理多个孤立的工具来进行票据处理、监控、聊天和其他任务时，“故障-修复”循环会变得更加根深蒂固。他们在工具之间切换（即“转椅式”操作）所花费的时间，挤占了处理事故本身的时间。
即使部署了 AI 和自动化，它们也通常被孤立地用于特定的任务或工作流，限制了其价值。根据一份 PagerDuty 的最新报告，报告韧性有所提升的组织大多将其归功于支持全事故生命周期的集成工具或更紧密的系统集成。专业的 AI 代理通过自主管理事故响应、捕获团队内部知识并应用学习成果来防止问题重复出现，从而扩展了这一能力。
不断增加的认知负荷加剧了问题
“故障-修复”循环给 DevOps 工程师带来了沉重的负担。他们不仅被要求实时响应可能并非由他们编写的代码所引发的事故，还需要编写代码、了解其运行方式并持续监控系统行为。
在开发人员现在只需数小时而非数周或数月即可构建原型的时代，这些期望根本不切实际，复杂的依赖关系正将认知负荷推向临界点。毫不奇怪，42% 的组织报告称，重大事故和服务器宕机严重影响了开发人员的士气，并导致职业倦怠。
打破循环的三个策略
我们无法通过增加人手来解决这个问题。世界上没有足够的 DevOps 工程师能跟上 AI 辅助开发的周期，而且增加更多的人员可能会在团队和沟通线路之间造成更多的运营混乱。相反，运维团队需要像他们的开发同事拥抱 AI 辅助编码一样，拥抱 AI（包括 AI 代理）。
“世界上没有足够的 DevOps 工程师能跟上 AI 辅助开发的周期……增加更多的人员可能会造成更多的运营混乱……”
AI 技术可以路由问题、提供上下文、关联告警并从类似事故中提取相关的修复方案，从而让运维团队在工作量增加的情况下也能快速行动。
请考虑以下逃离“故障-修复”动态的三个步骤：
1. 从手动分选转向事件驱动抑制
继续使用手动流程的运维团队注定在每次面临新事故时都会重复同样的被动工作流。他们可以通过自动化运行手册（Runbooks）来打破这一循环，这些手册可以触发预定义脚本，从而实现更快的诊断和修复。最先进的平台则更进一步，部署能从每次交互中学习的 AI。机器学习分析历史事件和事故数据，以建议可操作的编排规则，创建事件驱动的自动化，在事故需要人工干预之前就将其阻断。事故后回顾（Post-incident reviews）通过允许 AI 自动汇总来自 Slack、系统告警和其他渠道的数据来加强这些努力，以识别可以转化为可重复工作流的模式。
2. 自动化响应以保护发布节奏
“故障-修复”循环的另一个后果是，手动运维团队会放慢发布节奏以降低风险。如果这意味着更大、更具风险的变更会导致更多事故，从而进一步降低快速部署的意愿，那么这种做法可能会适得其反。通过自动化事故响应，运维团队可以扭转这一逻辑。凭借智能告警分选和噪音消除，开发人员可以自信地部署更小、更频繁的变更。
当事故发生时，AI 代理可以自动检测、分选和诊断，以便工程师可以直接进入解决阶段。利用多代理 AI 构建这些自愈式 IT 系统改变了组织处理韧性的方式。当团队不再被事故管理压得喘不过气来时，他们就能赋予开发人员更频繁部署的能力，使事故响应变得更容易。
3. 卸下“繁杂琐事”以留住工程人才
当组织陷入“故障-修复”模式时，手动流程会导致资深工程师面临更多的中断和非工作时间待命。事实上，这些工作大部分是重复性的，本可以自动化，这给运维团队增添了一层挫败感。职业倦怠和人员流失通常是最常见的后果，从而引发连锁反应，导致组织内部知识流失，并使组织面临更多风险。
通过自动化重复性工作和部署 AI 代理，组织可以减轻压力沉重的运维团队的负担，让他们能够专注于创新而不是忙于救火。通过将“繁杂琐事”卸给 AI 代理，资深工程师可以回归到他们真正被雇佣去做的创造性、高影响力的工作中。这是一个共赢的局面。
让 AI 管理 AI 的复杂性
未能意识到“故障-修复”循环现实的组织，注定会将 AI 驱动的创新转变为运营负担。他们应该转向 AI 和专业代理来承担这一负担，使他们能够利用 AI 的力量加速代码部署，而不会让运维团队不堪重负。
从使用运行手册自动化来处理理解透彻、可重复的事故开始。逐步扩展到 AI 驱动的分选和诊断，然后加入自动化文档、持续改进建议和智能待命管理。每一层都在不取代人类判断的前提下消除了繁杂琐事。
运维团队应该考虑将“故障-修复”交给 AI，让团队成员去推动创新。端 工智能
