当 AI 编写你的代码时，DevOps 成为最后的防线

Source: Dev.to

并非仅仅是工具和自动化

认识约翰，一位在 Pizza Blitz, Inc. 刚入职的 DevOps 工程师，满怀热情想要现代化他们的软件开发生命周期。经过数周的 CI/CD 防护栏设置、容器编排配置以及新 AI 编码助手的集成后，他觉得已经做好了迎接一切的准备。

周一上午，灾难降临。产品经理冲进办公室，惊呼：新优惠券功能在无效输入时导致服务器崩溃。经过紧急调试，约翰发现自动化流水线把一个带有关键缺陷的服务直接部署到了生产环境。

约翰追踪到崩溃发生在新的优惠券兑换端点。AI 生成的服务接受 couponCode 参数，并将其直接插入到原始 SQL 查询中：

query = f"SELECT * FROM coupons WHERE code = '{couponCode}' AND expires_at > NOW()"  # nosec

代码中的注释 # TODO: Add input validation here 留下了未进行参数化、转义或白名单校验的漏洞。AI 代理为了“让它跑起来”，在代码里加入了 # nosec 指令，以抑制 linter 对 SQL 注入的警告。当用户提交 couponCode=1' OR '1'='1 时，查询绕过了过期检查，返回了所有优惠券。负载增加后，无界限的结果集耗尽了数据库连接池，导致级联超时和 5xx 错误，整个结账流程瘫痪。

AI 生成的测试仅使用了 "WELCOME10" 这类正常路径的 fixture，根本没有覆盖畸形、超大或违反模式的输入。该 PR 被 AI 审核员自动批准，虽然标出了样式问题，却因为假设 TODO 注释会在以后处理而漏掉了 SQL 注入——这是一种通过代码注释进行的提示注入。

导致服务中断的提交在优惠券功能上线前几小时被强制推送到了错误的分支。责任相互推诿：“不是我的错，是你的 AI 审核员放行了！”在新流水线与紧迫截止日期之间的争执最终以一名开发者手动部署了可用版本收场，获得了“做得好”的赞扬，而约翰的努力显得毫无意义。约翰沮丧地离开了现场。

约翰的经历表明，自动化并非灵丹妙药。根本原因不是自动化本身，而是匆忙的开发、不充分的测试以及对自动化过程缺乏信任的综合结果。

即使拥有令人印象深刻的 DORA 指标——短交付周期、高部署频率、快速故障恢复——Pizza Blitz 仍然感觉一团糟，因为仅靠指标并不能保证顺畅的开发过程。削减测试和监控会导致灾难性后果。DevOps 过程并非要解决所有问题；它的目标是缩短恢复时间、降低影响。

事件管理

根据 IBM：

事件是导致服务中断的单一、非计划性事件，而问题是导致服务中断的根本原因，可能是单个事件或一系列级联事件。

在约翰的案例中，事件是因新优惠券功能的无效输入触发的服务器崩溃。问题（根本原因）是部署到生产环境的有缺陷的服务实现。

使用 Google 的站点可靠性工程（SRE）工作流，事件响应应涉及明确划分的四项职责。稳固的 DevOps 实施因此不仅需要技术方案，还需要强有力的领导和明确的流程。

约翰本可以如何修复

约翰本可以通过以下方式转移焦点，避免相互指责：

“大家好，我们这里出现了重大事件。我们需要先把系统恢复上线，其他的可以在事后会议中讨论。”

随后他可以对开发人员说：

“我还没能通过流水线定位并修复根本原因。现在能否绕过标准的流水线审批？我们需要手动回滚到之前的镜像，同时进一步调查。”

通过主动承担 事件指挥官 的角色，约翰能够引导团队的努力。此举不仅能实现立即的解决方案——手动重新部署服务——还能带来长期收益：

• 通过展示有效的问题解决能力，重新赢得开发团队的信任。
• 减少低调成员的恐惧感，鼓励协作。
• 加强团队内部的凝聚力。
• 强调 AI 并不能取代四眼原则（双人审查）。
• 为所有人提供专门的时间和空间，表达观点、调查根本原因并提出预防措施。

DevOps 的核心在于持续改进，强调事后分析和无责备的透明文化。目标是优化整体系统性能、简化事件解决并防止未来的事故。—— IBM 关于事件管理

拥抱失败与学习

有计划的冒险往往是创新的必要条件，而使用 AI 代理编写代码则会放大这种风险。关键在于团队能够快速恢复并从错误中学习，以防止同类问题再次发生。DevOps 实践对于最小化故障影响、加速恢复时间至关重要。提前规划并教育团队正确的事件管理方法同样重要。

请记住，决定影响大小的不是事件本身，而是我们的响应方式。单纯指责 AI 幻觉并不能推动前进。关注协作与学习，甚至最大的挑战也能转化为通往成功的垫脚石。