人工智能驱动的代码激增，正以前所未有的速度改变着生产环境，其变化之快已经超出了运维工程师重建心理模型的速度。人工智能模型可以在这一过程中提供帮助。

　　根据《Cursor开发者习惯报告》，前1%的AI活跃开发者每天生成的AI辅助代码量，是普通活跃用户中位数的46倍。瓶颈已不再是编写软件本身，而在于理解软件上线之后会发生什么。

　　每一个新增的服务、依赖项、功能开关、生成的抽象以及部署路径，都会增加生产系统潜在故障的方式。人工智能极大地压缩了制造这种复杂性所需的时间，却并没有压缩理解它所需要的时间。

　　结果是，生产环境的变化速度比工程师重建其心智模型的速度更快。在这种情况下，人工智能可以发挥作用——因为大多数现有的调试实践，都是为节奏较慢的世界设计的。

　　昨天和今天调试

　　几十年来，调试在很大程度上是一个“局部问题”。服务A中的故障属于拥有服务A的团队。他们了解部署历史、运行时的特殊行为、有用的日志查询，以及那些从未写入手册的诡异现象。事件响应也延续了这一假设：团队拥有服务，运维手册限定在这些服务范围内，值班轮岗也按组织边界划分。

　　当故障保持在局部范围内时，这种模式仍然有效。如果某次部署引入了内存泄漏，或因配置不当导致服务崩溃，症状和原因通常都位于同一处，拥有团队可以自行调查、定位问题并恢复服务。然而，这类事件在生产故障中所占的比例正越来越小。

　　人工智能生成的代码本质上并不比人工编写的代码更可靠，真正的变化在于数量和速度。团队如今能够在更短时间内引入更多代码，一次性触及更多系统，并以前所未有的速度演进架构。随着系统间相互依赖加深，故障越来越多地出现在其原始触发点之外。

　　单跳事件是局部性的：发生故障的服务同时也是导致故障的服务，调查始终停留在一个团队的边界内。

　　而多跳事件则完全不同。例如，结账API开始超时，但结账服务自身看起来一切正常——延迟正常、错误率很低。实际根因是一个队列消费者在静默丢弃消息，因为两天前的一次架构更改仅实现了部分向后兼容。队列团队看到的吞吐量一切健康，数据平台团队从未收到告警，因为其服务没有任何指标违反阈值。每个团队对自己负责的系统而言都是正确的，但没有人能解释为什么客户最终无法完成购买。

　　问题并不在于缺乏证据——现代生产系统产生的遥测数据远远超过任何人在事件中能消化的量。真正的挑战在于，知道哪些证据是关键的，哪些信号只是巧合，以及这些零散线索如何串联成完整的因果链条。

　　人工智能在生产运营中的作用

　　这改变了人工智能在运维中应扮演的角色。人工智能不应被视作一个“魔法随叫随到工程师”——前沿模型并不了解你的特定架构，不会主动记住以往的事件，也不知道哪些仪表板其实不靠谱、哪些服务通常一起挂掉、上周发生了什么变化，或者哪条依赖链最关键。仅凭自身，它只能在一片真空中进行推理。

　　人工智能在生产中有用的版本更为具体。它可以辅助组织上下文、测试假设、追踪依赖关系、将当前事件与历史事件进行比对，并排除那些不符合时间线或影响范围的解释。它能够胜任目前事件响应前20分钟里最耗时的工作：搜集证据、检查近期变更、映射依赖关系、缩小排查范围。

　　而做出需要判断的决策仍然属于人类工程师：证据是否足以支持行动？回滚是否值得冒险？是否需要叫醒另一个团队？最稳妥的选择是尽快恢复，还是继续深入排查？但他们不应花费一半的时间去重建组织已经历过无数次的生产系统认知。

　　这正是更大的生产力转变所在。

　　如果人工智能能够承担更多的故障排查负担，工程师就能把精力集中在真正能产生复利效应的工作上：简化脆弱的架构，改进那些反复出问题区域的监控指标，设计更安全的降级路径、更精准的告警、更可靠的回滚模式，以及在用户察觉之前就能捕捉到语义错误的评估机制。他们还可以将生产环境中的经验反馈到开发环节，让代码助手和代码评审流程了解哪些服务存在风险、哪些模式曾导致服务中断、哪些依赖项值得格外关注。

　　这些工作是工程师们通常没有足够时间去做的事，因为他们一次又一次地处理着同一类事件。

　　让工程师做工程师该做的事

　　目标不是把工程师从生产中剔除出去，而是停止浪费他们的判断力——这些判断力本该用在系统本身需要做的工作上。人工智能应该缩短事件持续时间，但这仅仅是第一层收益。更大的好处是，让资深工程师有更多时间去预防未来事故，而不是被拉进每一次混乱的突发事件中。

　　随着人工智能加速软件开发，生产运维也亟需在另一端获得同样的加速——这不只是要更快地调试，更是要更好地分配人类注意力。

　　人工智能代码激增的挑战，不能靠要求工程师以机器的速度不停排障来解决。它必须通过让生产系统更清晰、更具弹性，并减少对任何一位清醒专家的过度依赖来加以管理。

来源：https://www.infoworld.com/article/4197480/how-ai-can-improve-site-reliability-engineering.html