前言
我是食品公司开发本部技术部 SRE 团队的一员。自 2018 年起我便加入了食品公司。
本文将为大家介绍一个系统改善案例：针对持续 10 余年的手动 cron 运维工作，我们通过运用生成式 AI，仅用 4 天开发就实现了 “作业时间归零” 的目标。
其中包括与 AI 对话的设计流程、开发效率的提升，并客服遗留系统改善的心理障碍。希望我们的实践经验能为面临类似问题的各位提供帮助。
SRE 团队的 “cron 注册工作” 是什么
我所在的 SRE 团队负责公司的中间流程及编排管理、CI/CD 运维、监控等工作。公司由多个系统构成，而 SRE 团队几乎要对所有系统进行跨域管理。
长期以来公司运行着大量新增的批处理任务，其中一部分通过在 VM 中设置的 cron 来执行。SRE 团队负责 cron 的注册与管理，接收开发团队的设置变更请求并统一处理。具体工作流程如下：
- 配置文件管理：基于 IaC（基础设施即代码）理念，cron 的配置内容以文件形式在 GitHub 上进行管理。
- 部署：向各 VM 反映配置时，使用的是 10 多年前编写的 “祖传” 部署脚本。
- 手动操作：执行部署作业时，操作人员需向脚本多次输入 sudo 密码。
这项运维工作每年约发生 100 次，每次作业耗时约 10 分钟。由于单次作业看似轻微，基于 “改善成本与效果不匹配” 的判断，这种运维方式得以长期延续。
然而，仅为这项工作就需要随时准备好 sudo 密码。此外，运维过程中还需要掌握诸多知识，例如部署使用哪台服务器、在服务器上执行何种命令等。
放任这类遗留的重复性工作存在，会阻碍工程师专注于本应投身的创造性业务。因此，我们决定迈出改善 cron 运维的第一步。
启动改善的契机
尽管长期以来都意识到这是个问题，却始终未能着手解决。此次下定决心推进改善，源于一个个人契机 —— 我休完育儿假重返工作岗位。
由于长期离开工作环境，即便对于以往习以为常的 cron 注册工作，我也不得不以头脑 “重置” 后的全新状态去面对。实际操作时，我才重新注意到许多以往因习惯而忽略的繁琐之处，比如 “为什么要多次输入密码？”“这个步骤每次不看文档就心里没底……”。
这段经历深刻揭示了 “习惯” 如何掩盖了工作的低效性。
同时，这也成为我重新审视以往 “成本不匹配” 判断的契机 —— 那就是生成式 AI 的应用。生成式 AI 不仅能提供设计方案，还能生成几乎全部实现的代码。相比从零开始自主思考，运用 AI 能以更低成本实现改善。
系统设计与技术架构
详细系统架构图
基于 Argo CD 与 Kubernetes 的 cron 注册系统
本次构建的新型 cron 管理系统整体架构如图所示。我们以 GitOps 理念为基础，采用 Kubernetes 和 Argo CD 作为核心技术。
当开发者将 cron 配置文件推送到 GitHub 的 master 分支后，Argo CD 会自动检测到该变更，并将其同步为 Kubernetes 集群上的 ConfigMap。随后，以 ConfigMap 的更新为触发条件，执行 Kubernetes Job，最终实现目标 VM 上 cron 的更新。
该架构的特别之处在于，完全未改动目标 VM 的配置。对长期稳定运行的 VM 环境进行修改，存在引发意外故障的风险。因此，所有更新 cron 的处理均在 Kubernetes 集群侧执行，仅通过 SSH 向 VM 发送更新命令。
通过这一设计，在将对现有环境的影响降至最低的同时，实现了以 Git 推送为起点的现代化声明式工作流。
技术栈选型理由
构建本次系统时，我们重视的是即使是对该领域知识为零的工程师，也能安全且无困惑地执行 cron 注册工作”。为实现这一目标，我们采用了 GitOps 方法。
在推进 GitOps 的过程中，我们选择 Argo CD 作为核心工具，原因在于其已在我们公司现有的 Kubernetes 基础设施上稳定运行并积累了实践经验。正如过往文章所提及的，我们已有多个系统在本地 Kubernetes 上运行，且已通过 Argo CD 实现 GitHub 代码变更检测的实践。
无需为引入新工具付出学习成本与验证成本，借助熟悉的环境和技术栈，我们得以快速推进开发。
本次技术选型的背后，是朝着 “任何人都能零负担作业” 的运维目标迈进。为此，我们在最大限度利用现有技术资产以控制改善成本的同时，融入了 GitOps 思想。
安全考虑事项
本次系统改善也极大提升了安全性。
在以往的运维模式中，执行 cron 部署的操作人员必须掌握特权用户的 sudo 密码。从密码管理角度来看，这本身就潜藏着安全风险。
在新系统中，我们通过 Bitnami Sealed Secrets 对该密码进行加密，并改为在 Kubernetes 集群内进行安全管理。由此，操作人员无需 SSH 登录部署服务器，也无需知晓特权密码。
此前，负责 cron 部署的人员需时刻谨慎管理密码并执行部署工作。而通过本次改善，这类心理负担也得以消除。我们既减轻了操作人员的负担，又实现了系统整体更安全的状态。
基于 GitOps 的发布流程
提到 “任何人都能零负担作业”，或许有人会联想到管理混乱的 “法外之地”。但事实并非如此。在本次新流程中，我们确保其符合公司标准开发流程。
所有 cron 配置变更均通过 GitHub 的 Pull Request（PR）进行。且该 PR 必须经过团队负责人审核批准后，才能合并至 master 分支。这一机制确保了变更内容的意图与合理性能由第三方进行核查。
以往的 cron 注册流程中，PR 合并后还需登录部署服务器执行脚本等操作。这些步骤也是发布工作的一部分，需要形成文档并接受审核。而本次系统变更，也减少了文档撰写与审核等步骤。
此外，部署的执行状态与结果可通过 Argo CD 的 GUI 实时查看。即便出现问题，也能通过同步状态及执行日志快速追踪原因。如此一来，我们在消除作业对特定人员的依赖的同时，实现了具备可靠可追溯性与管控力的发布流程。
公司系统规模特有的考虑事项
公司系统运行着数量极多的服务器。本次改善中我们尤其关注的是，需注册 cron 的 VM 数量庞大。在对大量 VM 同时执行 SSH 连接与命令执行的过程中，必须考虑到因网络瞬时中断等导致连接错误的可能性。同时，还需避免因配置错误导致向大量 VM 重复发起非预期 SSH 连接，造成连接请求集中的情况。
为规避此类风险，确保系统在大规模环境下稳定运行，我们在设计时考虑了以下几点：
- 确保故障耐受性：在 cron 部署过程中，即便对某一台 VM 的部署失败，也不会影响其他 VM，对正常 VM 的部署仍会继续进行。
- 便捷重试机制：由于通过 Argo CD 进行管理，可在 GUI 上轻松触发同步（重新执行）操作。
- 安全执行时机：仅在必要时才与 VM 建立 SSH 连接，仅当需要变更时才启动 Job。
通过这些设计，我们实现了即便在大规模环境下，也能安全且稳定地应用变更的机制。
实施流程与生成式 AI 应用详情
本次项目的一大特点是，从设计、开发到调试的全过程，都以生成式 AI 为伙伴进行了全面应用。下文将介绍具体流程以及与 AI 协作过程中的发现。
通过与生成式 AI 对话实现设计与开发
在设计初期阶段，我们将生成式 AI 用作 “头脑风暴对象”。起初并未打算正式着手改善，只是在偶然打开的 Cursor 上，以和工程师同事闲聊的轻松心态与 AI 对话，这便是一切的开端。
我：“现有 cron 运维存在这样的问题，有没有什么好办法？现在实在太麻烦了。”
针对这个模糊的问题，AI 首先给出了几个通用的最佳实践。
AI：“可以考虑使用 AWS Lambda、Kubernetes CronWorkflow、GitHub Actions 等工具。”
对此，我们向 AI 说明了公司特有的约束条件以及已可使用的技术资产。
我：“哦，我们的前提是本地环境。不过现有的 Kubernetes 集群可以用。”
AI：“明白了。那么，使用 ConfigMap 或通过 CronWorkflow 进行变更检测如何？”
我：“不错！我们有使用 configMapGenerator 的经验。如果用已经引入的 Argo CD，变更检测应该会更简单！”
就这样，通过与 AI 反复交流探讨，我们逐步将方案从纸上谈兵转化为切实可行、效果显著的具体设计。
加速开发与调试
当确信 “这样真的可行” 后，我们便进入了开发阶段。此时 AI 依然是强大的支持者。Kubernetes 的清单文件、容器中执行的 Shell 脚本等开发所需的大部分代码，均由 AI 生成。
当然，生成的代码并非总能直接运行。但只要告知 AI 出现的错误，它就能立即提供调试支持。
此外，为提高开发与调试效率，我们还委托 AI 搭建了基于 Docker Compose 的本地运行验证环境。仅需告知 AI“由于不止我一人使用，要注重易懂性和可维护性” 等设计理念，AI 便会针对 Secret 及环境变量的处理方式，提出并实现最优方案。
借助检查脚本实现安全发布
我们还运用 AI 确保发布安全。为将持续 10 余年的运维工作转换为新系统，必须确认新系统能够正常启动运行。例如，cron 文件是否能与以往一样正常部署、是否产生了非预期变更等。我们委托 AI 编写了从这些角度进行检查的脚本，并对所有运行 cron 的服务器执行了检查，从而降低了人为错误的风险。
生成式 AI 的局限性与人类专业知识的重要性
然而，生成式 AI 并非万能。在本次项目中，最终决策仍离不开工程师的专业知识。
例如，AI 最初提出的方案是通过 Deployment 或 CronJob 管理更新流程：利用 configMapGenerator 生成并管理 cron 文件的 ConfigMap，在 Deployment 中仅配置一个启动时执行 cron 部署流程的 Pod，将 ConfigMap 挂载到该 Pod 上，这样更新 cron 文件后会重新生成 Pod，进而完成 cron 部署。这一设计乍看之下似乎合理。我们请 SRE 团队的技术专家进行设计评审，他给出了精准建议：“这看起来简单易行，但针对本次的使用场景，使用执行一次性处理的 Job 资源会更简洁、无冗余。” 这种基于对系统特性深刻理解的判断，正是人类专家独有的价值。
此外，AI 还曾提出使用已废弃的旧版 kustomize 功能（通过 configMapGenerator 用通配符指定目录里的内容）。起初我们按照建议开发并进行运行验证，但多次执行 kustomize build 均失败。询问 AI 时，它仅指出写法有误，而我们自行调查后才发现该功能已被废弃。这让我们再次认识到，AI 的知识未必是最新、准确的，因此绝不能盲目相信其建议，必须通过官方文档等进行事实核查。
从实践中获得的故障排查经验
在开发的最终阶段，我们也积累了实际的故障排查经验。起初，我们设置为自动清理已完成处理的 Job 资源，却发现 Job 的执行日志也会随之删除，导致故障发生时无法追踪原因。虽然通常推荐在 Kubernetes 节点层面进行日志记录，但公司采用Sidecar模式收集应用日志。
我们向 AI 咨询后，它自然推荐了节点层面的日志记录方案。但当我们重新说明当前的约束条件后，AI 提出了使用 Argo CD Notifications、添加日志收集容器等方案，并生成了所需的清单模板。我们立即尝试了 Argo CD Notifications，却发现它无法实现通知容器日志内容的功能。意识到这一点后再次询问 AI，得到的回复是 “确实可能不适合本次的需求”。我们也考虑了其他方案，但在首次发布阶段，暂且采用了 “不自动删除 Job” 这一简单方法。同时我们判断，由于执行日志本身仅输出 “已向 xxx 服务器分发完成” 等简单内容，平时查看日志的需求应该较少。
由此可见，生成式 AI 并非总能给出完美答案。但它能提供多种选择，大幅降低试错门槛，从而拓展我们解决问题的能力。毫无疑问，它是一位 “优秀的助手”。
成果与效果验证
通过本次努力，我们在开发流程与日常运维两方面都取得了显著成果。
开发工时大幅削减：从 10 天降至 4 天
首先值得一提的是，借助生成式 AI，开发工时大幅减少。
若本次完全不使用生成式 AI，从零开始设计开发，预计需耗费约 10天。而实际仅用 4 天便完成了开发。
这主要得益于：在设计初期，AI 提供了多种选择；在开发阶段，快速生成了代码模板。以往需要花费大量时间进行调研和试错的环节，通过与 AI 对话得以高效推进，且过程令人信服。
突破遗留系统改善的心理障碍
将持续 10 余年的运维工作转换为新机制，不仅存在技术难题，还伴随着 “真的能安全迁移吗” 的心理压力。
在这一点上，生成式 AI 也提供了很大帮助。我们委托 AI 编写检查脚本，用于确认新旧 cron 配置是否存在差异、是否添加了非预期变更。这客观保障了迁移工作的安全性，让我们能够满怀信心地推进发布。
可以说，AI 消除了遗留系统改善中常见的 “不知从何下手”“害怕失败” 等心理障碍。
彻底优化 cron 注册工作
当然，作为核心目标的 cron 注册运维也得到了突破性改善。
新旧 cron 注册操作流程对比
如图所示，以往的流程需要执行部署脚本、准备密码等多项手动操作。而在新流程中，开发者只需将配置文件推送到 GitHub，后续流程便会全自动执行。
由此带来了以下效果：
- 定量改善效果：单次约 10 分钟的作业耗时，实际降至 0 分钟。
- 定性改善效果：无需提前准备密码、无需对照手册操作等，任何人都能毫无顾虑地进行 cron 注册与变更。
向横向拓展延伸
这款新型 cron 注册系统不仅在 SRE 团队内部受到认可，其他团队的工程师也纷纷表示 “想使用”。已有部分团队表达了兴趣，这一成果有望在未来提升全公司的生产效率。
未来展望
通过本次成功实践，我们确信：“借助生成式 AI，即便对于以往因成本效益不匹配而搁置的遗留重复性工作，也能以较少工时完成改善。”
SRE 团队仍面临其他类似课题。今后，我们将运用本次项目积累的经验与 momentum（势头），积极推进这些问题的改善。
我们将与生成式 AI 这一强大伙伴携手，持续为提升公司的服务可靠性及工程师生产效率贡献力量。