AI 并没有取代 SRE，而是在让他们技能退化

原文 ↗ Hacker News 讨论 ↗

由 AI 驱动的工具正越来越多地接管 Site Reliability Engineers（SRE）的日常运维任务，从日志关联、事故分诊到自动化修复，这引发了人们对人类是否正在失去应对新颖、复杂故障所需的实战经验的担忧。很多人把这与飞行员过度依赖自动驾驶相类比：自动化提升了日常安全性和生产力，但也可能削弱在系统异常或支持 AI 的服务失效时所需的技能。另一些人反驳说，这种“技能退化”只是重心转移——从低层级的琐碎工作转向更高层级的系统设计、事故模拟以及指挥 AI agent——但他们也担心，如果没有有意识的练习和培训，未来团队可能缺乏足够的深度专业知识来安全运行关键基础设施。

SRE 中的 AI 使用与感知到的技能退化

  • 许多人明显感到技能退化：人们在事故中先去找 Claude/ChatGPT，在不同 agent 之间复制粘贴，逐渐失去“动脑子”的习惯。
  • 也有人认为这只是把技能重心转移了：从写语法转向写规范、测试，以及设计具备可观测性和弹性的系统。
  • 还有人指出这种“分层”效应：AI 处理常规的 Tier-1 和 Tier-2 事故；人类只会看到新颖的 Tier-3 故障，这可能会削弱从处理简单案例中建立起来的直觉。

对技能、学习和初级工程师的影响

  • 一些人担心长期的能力萎缩：如果从一开始就使用 AI，未来工程师可能永远学不会阅读、调试，或深入理解代码和基础设施。
  • 还有人担心，如果初级工程师大多只是提示和复核，而不是从第一性原理出发构建和调试，那么通往 Senior/Staff 的培养管道会断掉。
  • 也有人说技能是可以重新学回来的，而有意识的“练习时间”（编码、谜题、模拟事故）可以缓解技能退化。

关于 SRE/DevOps 应该是什么的争论

  • 对于 SRE/DevOps 是下面哪一种，存在激烈分歧：
    • 夸大其词的系统管理员 / 与 Kubernetes、Terraform、YAML 绑定的工具操作者，或
    • 专注于可靠性、可扩展性和成本的软件工程师。
  • 有些人坚持认为，“真正的 DevOps”意味着开发者要为自己构建的东西承担 on-call；另一些人则认为运维是一个独立且正当的专业方向。
  • 大型组织的现实：中央 SRE/基础设施团队依然存在，用于标准化平台、执行可靠性要求，并处理跨领域的复杂性。

在运维中使用 AI 的经验

  • 多位从业者报告说，前沿模型已经非常擅长：
    • 日志/指标/追踪关联、事故分诊、CI 失败分析，以及生成仪表盘/runbook。
    • 以 CLI 为主的任务（例如 AWS）以及按照检查清单完成端到端基础设施变更。
  • 也有人报告说，agent 会误解告警、追错层级、重写过多代码，或者因为它们之前的改动细微但错误，反而让调试更困难。
  • 共识是：AI 很强大，但其效果只取决于上下文、工具和人工监督；不称职的人，配上更好的工具，依然不称职。

类比与历史对照

  • 飞行被反复提及：自动驾驶能提升安全性，但需要强制的手动练习和训练；有人建议为 SRE 设置“事故模拟器”/混沌演练。
  • 反对意见：软件行业缺少航空业那样的监管和激励，所以大多数组织不会投入强制性的练习。
  • 其他类比包括：计算器与长除法、CNC 与手工加工、Docker/Terraform 已经让基础设施工作“技能退化”，以及历史上对日常技能的更广泛自动化。