多环境脚本失控,往往从复制开始
一次例行发布前,运维负责人小周收到了一项看似简单的任务:在测试、预发布和生产环境执行同一套服务检查。
共享目录里已经有三份脚本,文件名分别带着 test、uat 和 prod。但小周没有立即执行。测试脚本比生产脚本多了异常判断,生产脚本又多出一条临时诊断命令,预发布脚本里的接口地址还是旧值。
问题已经不再是“应该选哪个环境的文件”,而是没人能解释这些版本为什么不同。原本为了快速适配环境而复制的脚本,逐渐变成了三套各自演进的执行逻辑。
一次例行发布前,运维负责人小周收到了一项看似简单的任务:在测试、预发布和生产环境执行同一套服务检查。
共享目录里已经有三份脚本,文件名分别带着 test、uat 和 prod。但小周没有立即执行。测试脚本比生产脚本多了异常判断,生产脚本又多出一条临时诊断命令,预发布脚本里的接口地址还是旧值。
问题已经不再是“应该选哪个环境的文件”,而是没人能解释这些版本为什么不同。原本为了快速适配环境而复制的脚本,逐渐变成了三套各自演进的执行逻辑。
发布负责人小周是在复盘会上被问住的。
接口超时发生在发布后十几分钟。监控曲线有,错误日志也有,应用到数据库的依赖关系也能查到。所有材料看起来都在指向同一个方向:连接不稳定。
直到业务接口人问了一句:“故障发生前,连接池配置是不是刚调过?”
会议室安静了几秒。
有人翻发布记录,有人翻群消息,有人登录机器看当前文件。可当前文件只能证明“现在是什么样”,不能证明“当时是什么样”。真正卡住复盘的,不是没人看日志,而是没人能拿出配置文件在故障前后的版本和差异。
复盘最怕的不是线索少,而是线索到了配置层突然断掉。
晨会前 20 分钟,运维负责人小周被问住了。
昨天下午发布后,支付回调服务抖动了十几分钟。故障已经恢复,业务侧也确认交易补偿完成,但复盘材料迟迟拼不成一张完整图。
监控同学给了接口延迟曲线。
研发同学贴了几段带请求 ID 的错误日志。
CMDB 里能查到支付回调、缓存、数据库和下游账务服务的关系。
告警列表里也有触发、认领和恢复时间。
材料看起来很全。可复盘主持人追问了一句:
“这次到底是哪个点先异常?影响范围是一个实例、一条服务链,还是整段支付链路?”
会议室安静了几秒。
不是没人有数据,而是每个人手里都只有一块碎片。小周能解释其中任意一张截图,却很难把这些截图串成一个连续现场。
这就是很多故障复盘最难受的地方:证据都在,现场不在。
周三下午的例行发布刚结束,支付回调开始出现零星失败。业务接口人在群里追问影响范围,发布负责人把一条用户投诉里的请求 ID 发了出来,研发小周想马上进日志平台查上下文。
这时候运维还在确认一个问题:小周到底该看哪一批日志?
订单、会员、支付、履约几个服务都在同一条交易链路里,日志字段也有不少重叠。小周负责的是支付回调,但这次请求 ID 在多个系统里都会出现。如果只开放支付日志,担心线索不够;如果直接给全量检索权限,又可能把其他业务线的运行细节一起暴露出去。
群里很快有人给出最省事的建议:
先给全量检索权限,查完再收。
这句话听起来很务实。问题还没定位,大家都不想把时间耗在授权上。可小周真正进入全量入口以后,排障并没有变快。他搜同一个请求 ID,结果里同时出现支付回调、订单状态变更、会员权益校验和履约通知的日志。字段名相似,错误码相近,时间又都集中在同一分钟内。
他确实看到了更多日志,但也被更多无关日志拖住了。
更麻烦的是,其中几条会员侧日志里带着小周并不负责的业务参数。于是现场从“怎么尽快定位支付回调失败”,变成了两个问题一起压过来:权限是不是放大了,线索是不是也被放乱了。
这就是全量授权最容易被忽略的地方。它不只是“可能不合规”,也不只是“权限太大”。在真实排障里,它会同时造成数据越界和定位变慢。
月末第一天早上,运维群里最让人发紧的一句,不是“昨晚有没有告警”,而是:
“那轮夜间巡检到底谁跑了?结果现在谁能说清楚?”
主角是平台运维同学老赵。前一晚交接班前,他还在群里补过一句:夜里记得跑一轮磁盘巡检,顺手把几台业务机上的旧日志清掉,再把几个关键服务状态过一遍。话刚发完,新的告警进来;临时排障一插进来,这轮原本人人都觉得“不难、等会儿就能做”的动作,就这么一路往后顺延。
到了第二天,真正让现场翻面的,不是命令没人会写,也不是脚本完全不存在,而是大家突然发现,谁都没法把昨晚那轮动作一口气讲完整。
到底是谁真正接过去跑了? 这次巡检和清理,昨晚到底打到了哪一批机器? 跑完以后,是正常结束了,还是中间已经有节点报错?群里并不安静。有人说“这个我昨晚好像跑过”,也有人说“清理动作应该做了,只是没回结果”。可越是这种听起来都像做过一点的现场,越容易把人拖住。因为你会很快发现,大家争的已经不是“会不会做”,而是“这轮动作到底有没有被完整接住”。
很多团队第一次真正意识到服务器例行维护会失控,往往也不是在脚本写不出来的时候,而是在这种动作明明该做、结果却没人能确认的瞬间。
月末结算窗口前二十分钟,账务集群里有几台机器的磁盘占用突然往上冲。群里没有人先问脚本怎么写,而是先追着确认另一件事:这次到底只处理几台异常节点,还是会顺手打一整个执行组。
让人发紧的,不是要不要批量执行,而是没人敢保证这一键只会落在该落的地方。脚本内容、目标范围、落地路径、执行后的追溯链,只要有一处没收住,原本用于止血的动作就可能直接扩大故障面。很多生产环境里的“自动化翻车”,问题都不出在自动化本身,而是批量能力先跑了起来,边界却还没讲清楚。