银河系统维护该怎么办？一个普通运维人员的深夜实录

凌晨两点十七分，手机屏幕突然亮起来的那一刻，我的第一反应是——完了，银河又挂了。

这已经是本月第三次系统报警了，我摸黑戴上眼镜，看着监控界面上一片刺眼的红色告警，叹了口气，如果你也管过类似的系统，大概能体会这种滋味，银河系统，听名字挺浪漫,实际维护起来可真没那么多诗意。

先说说银河系统到底是什么，很多人可能觉得这是个科幻概念，其实在不少企业和机构里，银河是一套分布式数据处理平台的代号，负责调度成千上万台服务器的算力，跑着各种数据分析任务，名字取"银河"，大概是因为节点多得像星星，彼此之间又有复杂的引力关系，问题是，星星不会半夜崩掉,但这套系统会。

第一步：别慌，先判断是什么类型的故障

我见过太多人一看到报警就手忙脚乱，上去就重启服务器，结果把小问题搞成大事故，维护银河这种大型分布式系统，第一件事永远是定位故障层级。

具体怎么做呢？我通常先看三个东西：

• 调度中心是否存活——如果调度节点宕了，下游全乱套，这时候什么都别动,先切备用调度节点。
• 存储层有没有响应——银河底层通常是分布式文件系统，存储挂了日志会疯狂报错，特征是大量任务同时失败，失败信息里带"connection refused"或"timeout"。
• 计算节点负载是否异常——有时候不是挂了，是某个大任务把资源吃光了,其他任务排队排到超时。

拿前天那次事故举例吧，报警信息显示上百个任务同时报错，表面看像是调度层崩了，但我翻了两分钟日志之后发现，调度器本身运行正常，问题出在底层的元数据服务——它响应速度从正常的几毫秒飙升到三十多秒，导致所有依赖元数据的操作全部超时，这种时候你要是去重启调度器，等于白费功夫还把正在跑的任务全杀了，所以我说，定位比行动重要，这不是废话,是真金白银的经验。

第二步：执行你的应急预案，同时保持沟通

定位到问题之后就进入实际处理阶段了，这里我想强调一个容易被忽视的点：边修边记。

什么意思？就是你在敲命令的同时，把每一步操作和输出结果都记录下来，我知道这听着挺麻烦的，尤其是大半夜脑子还不太清醒，但你不记，等两小时后领导打电话问你"现在什么情况"，你很可能已经忘了自己十分钟前改过哪个参数，我的习惯是开一个共享文档，实时更新状态，这样团队其他人不用反复问我,也能看到进展。

处理不同类型的故障，套路也不一样，我列了一个简表,算是自己总结的速查手册：

故障类型	典型症状	优先操作
元数据服务过载	大量任务排队，日志频繁出现锁等待	限流非核心任务，扩容元数据节点
计算节点宕机	任务失败后自动重试，部分队列积压	隔离故障节点，让调度器重新分配
网络分区	部分节点失联，数据副本出现不一致	确认分区范围，强制下线孤岛节点后恢复
磁盘写满	写入操作全部失败，日志疯狂刷屏	紧急清理临时文件，调整数据保留策略

到了凌晨三点四十左右，我把那个出问题的元数据服务切到了备用集群上，同时给主节点加了内存限制参数，防止它再次被某个超大规模查询打爆，看着监控曲线慢慢从红色变回绿色,紧绷的神经才稍微松了松。

第三步：事后复盘，别让这次故障白发生了

系统恢复了，很多人就觉得完事儿了，洗洗睡了，但说真的，不把根因挖出来，下次它还会换个花样来折腾你。

第二天上午，我们团队坐下来把整个过程理了一遍，为什么元数据服务会突然过载？翻了三天的访问日志之后发现，有个业务方前一天上线了一个新任务，这个任务会对元数据做全表扫描——而且他们没意识到这套操作在分布式环境下有多昂贵，调度器也没有对这种"危险操作"做任何拦截,直接就放行了。

所以最后我们做了三件事：

• 在调度层面加了SQL拦截规则,对不带分区条件的全表扫描直接拒绝并告警。
• 给元数据服务设置了自动扩容策略，负载超过阈值时自动增加节点,不用等人手动介入。
• 和业务方拉了个群，把常见的高风险操作列了个清单发过去，让写代码的人知道底层系统不是无限容量的。

你可能会问，银河这种级别的系统难道上线前没有压测过吗？当然有，但真实世界的流量永远比测试环境复杂，再完善的测试也模拟不出所有极端情况，这也是为什么维护工作不存在一劳永逸,每一次故障都是系统在告诉你哪儿还需要加固。

平时能做些什么来减少凌晨被叫醒的次数

写到这里我突然想起一个挺有意思的细节，刚接手银河系统的时候，我的手机一个月能响七八次，现在呢，差不多降到了每月一两次，不是系统变稳定了——实话讲，底层架构两年没大动过——而是我们花了很多功夫在那些不起眼的预防措施上。

比如说，监控不是光看CPU和内存就够了，我们给银河加了一套任务级别的健康度评分，系统会分析每个任务的历史运行模式，发现今天某个任务的耗时比平时长了三倍，就算它还没失败，也会提前发预警，这种"软告警"帮我们拦截过好几次即将扩大的事故。

再比如，我们定期做故障演练，选一个业务低峰时段，真的去拔掉某个节点的网线，看系统能不能自动恢复，第一次做的时候出了好多意外状况，调度器切换花了四十几秒，远超过预期的十秒，后来查出来是心跳检测的间隔设置得太保守了，改短之后一切就正常了，这种事你不真刀真枪试一下,永远发现不了。

还有一点可能容易被忽略——文档，我知道写文档是个苦差事，没人爱干，但你想，凌晨三点被叫起来的时候，脑子本来就不转，如果还要从头推导排查逻辑，太容易出错，我们维护了一份不断更新的"常见故障处理手册"，每次处理完一个新类型的故障就往里加一条，现在已经有四十多个条目了，新来的同事上手也快,不用事事都要老人带着。

工具脚本也很重要

顺手提一句，我们攒了不少自动化脚本，比如一个能快速分析银河调度日志的小工具，输入任务ID就能自动画出它从提交到执行的完整时间线，标出每个等待节点的耗时，这东西写起来不复杂，但省出来的时间累积起来相当可观，很多时候，维护工作的体验好坏,就取决于你有没有趁手的工具。

说回那个凌晨，四点半的时候，所有指标终于稳定了，我合上电脑，靠在椅子上发了会儿呆，窗外的天还是黑的，但隐约能看到远处高架桥上稀稀落落的车灯，银河系统还在安安静静地跑着，像一个巨大的星系在深空中无声转动，做运维大概就是这样吧——平时没人注意到你，只有出事的时候你才突然变得重要，不过换个角度想，最好的维护就是让系统安静到没人觉得需要维护,这大概算一种挺奇妙的成就感。

下次如果你也遇到类似的问题，不妨试试上面这些思路，不是标准答案，但都是实打实踩过的坑，银河也好，别的什么系统也好，说到底维护的本质就那么回事——在混乱里保持冷静，在稳定时储备方案，然后等待下一次出其不意的考验。