跳到主要内容

6 篇博文 含有标签「BK Lite」

查看所有标签

多环境脚本失控,往往从复制开始

· 阅读需 6 分钟

一次例行发布前,运维负责人小周收到了一项看似简单的任务:在测试、预发布和生产环境执行同一套服务检查。

共享目录里已经有三份脚本,文件名分别带着 testuatprod。但小周没有立即执行。测试脚本比生产脚本多了异常判断,生产脚本又多出一条临时诊断命令,预发布脚本里的接口地址还是旧值。

问题已经不再是“应该选哪个环境的文件”,而是没人能解释这些版本为什么不同。原本为了快速适配环境而复制的脚本,逐渐变成了三套各自演进的执行逻辑。

配置文件被改过没人知道,故障复盘就少了一段关键证据

· 阅读需 8 分钟

发布负责人小周是在复盘会上被问住的。

接口超时发生在发布后十几分钟。监控曲线有,错误日志也有,应用到数据库的依赖关系也能查到。所有材料看起来都在指向同一个方向:连接不稳定。

直到业务接口人问了一句:“故障发生前,连接池配置是不是刚调过?”

会议室安静了几秒。

有人翻发布记录,有人翻群消息,有人登录机器看当前文件。可当前文件只能证明“现在是什么样”,不能证明“当时是什么样”。真正卡住复盘的,不是没人看日志,而是没人能拿出配置文件在故障前后的版本和差异。

复盘最怕的不是线索少,而是线索到了配置层突然断掉。

故障复盘为什么总拼不出现场

· 阅读需 11 分钟

开场:晨会前那张拼不完整的图

晨会前 20 分钟,运维负责人小周被问住了。

昨天下午发布后,支付回调服务抖动了十几分钟。故障已经恢复,业务侧也确认交易补偿完成,但复盘材料迟迟拼不成一张完整图。

监控同学给了接口延迟曲线。

研发同学贴了几段带请求 ID 的错误日志。

CMDB 里能查到支付回调、缓存、数据库和下游账务服务的关系。

告警列表里也有触发、认领和恢复时间。

材料看起来很全。可复盘主持人追问了一句:

“这次到底是哪个点先异常?影响范围是一个实例、一条服务链,还是整段支付链路?”

会议室安静了几秒。

不是没人有数据,而是每个人手里都只有一块碎片。小周能解释其中任意一张截图,却很难把这些截图串成一个连续现场。

这就是很多故障复盘最难受的地方:证据都在,现场不在。

日志权限全量放开,排障更慢也更危险

· 阅读需 9 分钟

发布后十分钟,日志权限先被要走

周三下午的例行发布刚结束,支付回调开始出现零星失败。业务接口人在群里追问影响范围,发布负责人把一条用户投诉里的请求 ID 发了出来,研发小周想马上进日志平台查上下文。

这时候运维还在确认一个问题:小周到底该看哪一批日志?

订单、会员、支付、履约几个服务都在同一条交易链路里,日志字段也有不少重叠。小周负责的是支付回调,但这次请求 ID 在多个系统里都会出现。如果只开放支付日志,担心线索不够;如果直接给全量检索权限,又可能把其他业务线的运行细节一起暴露出去。

群里很快有人给出最省事的建议:

先给全量检索权限,查完再收。

这句话听起来很务实。问题还没定位,大家都不想把时间耗在授权上。可小周真正进入全量入口以后,排障并没有变快。他搜同一个请求 ID,结果里同时出现支付回调、订单状态变更、会员权益校验和履约通知的日志。字段名相似,错误码相近,时间又都集中在同一分钟内。

他确实看到了更多日志,但也被更多无关日志拖住了。

更麻烦的是,其中几条会员侧日志里带着小周并不负责的业务参数。于是现场从“怎么尽快定位支付回调失败”,变成了两个问题一起压过来:权限是不是放大了,线索是不是也被放乱了。

这就是全量授权最容易被忽略的地方。它不只是“可能不合规”,也不只是“权限太大”。在真实排障里,它会同时造成数据越界和定位变慢。

夜里该跑的巡检和清理,怎么总在交接班后断档?

· 阅读需 9 分钟

月末第一天早上,运维群里最让人发紧的一句,不是“昨晚有没有告警”,而是:

“那轮夜间巡检到底谁跑了?结果现在谁能说清楚?”

主角是平台运维同学老赵。前一晚交接班前,他还在群里补过一句:夜里记得跑一轮磁盘巡检,顺手把几台业务机上的旧日志清掉,再把几个关键服务状态过一遍。话刚发完,新的告警进来;临时排障一插进来,这轮原本人人都觉得“不难、等会儿就能做”的动作,就这么一路往后顺延。

到了第二天,真正让现场翻面的,不是命令没人会写,也不是脚本完全不存在,而是大家突然发现,谁都没法把昨晚那轮动作一口气讲完整。

到底是谁真正接过去跑了? 这次巡检和清理,昨晚到底打到了哪一批机器? 跑完以后,是正常结束了,还是中间已经有节点报错?

群里并不安静。有人说“这个我昨晚好像跑过”,也有人说“清理动作应该做了,只是没回结果”。可越是这种听起来都像做过一点的现场,越容易把人拖住。因为你会很快发现,大家争的已经不是“会不会做”,而是“这轮动作到底有没有被完整接住”

很多团队第一次真正意识到服务器例行维护会失控,往往也不是在脚本写不出来的时候,而是在这种动作明明该做、结果却没人能确认的瞬间。

生产环境批量跑脚本,风险往往不在脚本里

· 阅读需 9 分钟

月末结算窗口前二十分钟,账务集群里有几台机器的磁盘占用突然往上冲。群里没有人先问脚本怎么写,而是先追着确认另一件事:这次到底只处理几台异常节点,还是会顺手打一整个执行组。

让人发紧的,不是要不要批量执行,而是没人敢保证这一键只会落在该落的地方。脚本内容、目标范围、落地路径、执行后的追溯链,只要有一处没收住,原本用于止血的动作就可能直接扩大故障面。很多生产环境里的“自动化翻车”,问题都不出在自动化本身,而是批量能力先跑了起来,边界却还没讲清楚。