从“群里 @ 运维”到自助执行：20+ 运维操作平台化的 6 层架构与 4 个落地阶段
概述 周五下午四点半，业务群开始刷屏： “@运维 帮我重启一下订单服务” “@运维 线上这个接口报错了，帮我捞下日志” “@运维 机器是不是又满了？帮我清下磁盘” 三个请求，三个 @，运维同学放下手里正在写的巡检脚本，SSH 登录、敲命令、回群里贴截图、再被追问一句“好了吗”。一个下午就这么碎了。这不是个例，是大多数团队运维工作的常态——高频、低难度、高度依赖人肉。 我在自研运维平台项目里做过一次统计：把 20 多个运维操作（服务重启、缓存清理、配置下发、证书续期、日志捞取、磁盘扩容……）从“群里 @ 人”搬进自助平台之后，单次操作的平均耗时从 15 分钟降到 90 秒左右，运维团队花在“响应请求”上的人力降了约 40%。这两个数字后面没有魔法，就是一件事：把操作变成平台上的标准动作。 这篇文章把我做这件事的完整思路摊开讲：为什么要平台化（不是“提效”这种空话，而是四个具体的结构性问题）、6 层架构怎么设计、操作目录怎么标准化、审批流怎么做才不会被绕过，以及四个真实踩过的坑。代码和配置都是可以直接抄走的。 先说清楚一点：运维操作平台化不是“写个 Web 界面跑脚本”。如果你只是在 Web 页面上开了个终端让开发自己敲命令，那不叫平台化，叫换个地方人肉。平台化的核心是：操作本身被定义成结构化的资产——有参数、有权限、有审批、有回滚、有审计。Web 界面只是这个体系的门面。 手工运维的四个结构性问题 在讲架构之前，先把问题说透。很多团队知道手工运维“慢”，但慢只是表象。真正让运维团队疲于奔命的是四个结构性问题： 问题一：请求链路太长，人的时间被切碎 一次“帮我重启服务”的完整链路是这样的： 业务在群里 @ 运维（等待响应：5 分钟） → 运维确认影响范围（翻 CMDB / 问业务：5 分钟） → 运维 SSH 登录执行（1 分钟） → 运维回群确认 + 贴执行结果（2 分钟） → 业务追问验证（3 分钟） 单次 15 分钟，其中真正“执行操作”只有 1 分钟，剩下 14 分钟都是沟通成本。Red Hat 在一篇 AIOps 实践文章里给过一个真实数据：一家英国金融公司用 Ansible Automation Platform 每周跑 600 多个任务（装机、补丁、合规扫描、配置漂移修复），每周产生约 40 张失败工单——如果没有平台，这 40 张工单每一张都是一次“群里 @ 人”。任务量到这个级别，人肉响应模式必然崩掉。...