线上操作到底该「手动敲命令」还是「写成自动化」？聊聊我们反复纠结的边界

先交代坐标：3 年运维，团队 12 个微服务，跑在 3 节点自建 K8s 1.28。今天想抛一个我每次都要跟研发吵、且吵不出标准答案的问题：一条线上操作，到底该让我手动敲命令，还是该写成脚本 / 平台按钮？

【背景 · 一个真实撕裂】 上个月一次发布，一个服务要手动改 3 个环境变量再滚动重启。当时的流程是：我登跳板机 → kubectl set env ×3 → kubectl rollout restart → 盯 rollout status。全程 4 条命令、6 分钟，没人犯错，看起来挺爽。 但上个月另一回，凌晨一次故障恢复，让一个入职 2 个月的同学走同一套操作，他漏了第 2 个变量，重启后服务起了一半、流量打过来直接 5xx，又多烧了 11 分钟。事后复盘，结论是「这 4 条命令早该固化成一个脚本」。

于是我们开始「自动化改造」。结果两个季度后我回头一看：写了 7 个脚本，其中 3 个因为参数变了没人跟进，已经悄悄坏了（跑起来是旧逻辑，没人知道）；另外 2 个功能高度重复，是两个人各写了一版。自动化没消灭风险，只是把风险从「敲错命令」换成了「跑错版本」。

【常见分歧 / 几种做法】

• 激进派：能自动化的全自动化，人只点按钮，杜绝手抖。代价是前期投入大、脚本本身成了新的维护负担和故障源。
• 保守派：低频、高风险、场景多变的操作，宁可手动 + 双人复核，因为「写脚本的成本比它一年跑两次的风险还高」。
• 中间派：高频且参数固定的 → 自动化；低频且多变的 → 手动 + checklist；介于两者之间最纠结。

【我的倾向与理由】 我倾向用两个数字做判断线，而不是拍脑袋：

1. 一年跑几次？ 我的经验阈值是——月均 ≥4 次 的操作，值得自动化（摊薄成本）；一年 <6 次 的，先别写脚本，写一份带「每一步预期输出」的 checklist 更划算。
2. 参数是不是每次都变？ 参数固定 → 一键化；参数每次都不同（比如订正哪张表、改哪个字段）→ 自动化容易烂尾，不如做「参数化 + 强校验」的半自动，把「判断」留给人，把「执行」交给脚本。

核心理念一句话：自动化该消灭的是「重复执行中的人为失误」，不是「每次都要重新判断」的场景。判断型操作硬自动化，就等于把「手抖」换成了「跑错版本」，风险没消，只是换了形态。

【想听大家怎么选】 特别想收集几个真实场景的做法，好对照我的判断线：

• 你们团队「手动 vs 自动化」有没有一条明确的数量 / 频率标准？还是纯靠老运维经验拍？
• 自动化脚本本身，你们怎么防它「悄悄烂尾」？（版本校验？跑前 dry-run？定期演练？）
• 有没有过「自动化做得越多，出事故反而越多」的经历？当时怎么收手的？

欢迎贴你们的判断标准和踩过的坑，数字越具体越好，我好攒一份「边界判断清单」。