故障处置20年：技术讨论应回归客观本位

　　去年2月那场数据库崩溃，我到现在想起来还后槽牙发酸——凌晨三点接到电话，机房空调坏了，温度飙到四十度，硬盘阵列跟烧开水壶似的嗡嗡响。运维小王蹲在机柜前，手里攥着根温度计，汗珠子砸在防静电地板上“啪嗒”响。我原以为按预案走就行，结果发现应急文档里写的“优先恢复核心业务”是句屁话——谁也没说清“核心”到底指哪几个表，开发说订单表，产品说用户画像，财务非扯着结算流水表不放。最后小王一拍桌子：“都别吵了，我按表大小排序恢复！”结果最先起来的是日志表，业务反而卡了半小时。

　　最扯的是事后复盘会。CTO拍着桌子喊“要建立技术共识”，结果讨论到第三句就歪楼——有人翻出三年前的架构图，说现在用的分库分表方案早该淘汰；有人揪着监控告警规则不放，说阈值调得太高；最绝的是测试组那姑娘，举着手机说“你们看，我昨晚发的朋友圈，机房温度报警短信比你们早到二十分钟”。我盯着会议室投影仪的光斑，突然想起二十年前刚入行时，师傅叼着烟跟我说：“故障处置就俩字——快、准。别整那些虚头巴脑的共识，能解决问题的方案就是好方案。”

　　现在倒好，技术讨论越来越像学术研讨会。上周参加个线上故障复盘会，一个新人花了十分钟解释“为什么用分布式锁比本地锁更符合微服务架构原则”，我实在忍不住插嘴：“兄弟，当时服务都挂了，你跟我说架构原则？先让业务能访问再说啊！”他愣了两秒，低头翻笔记本：“可...可这是行业标准啊...”我差点把咖啡喷在键盘上——行业标准能当饭吃？去年双十一，某电商平台的支付系统崩了，就是因为非要按“行业标准”用某个新中间件，结果那玩意儿连高并发场景都没测过。

文章配图，仅供参考

　　上周五又出幺蛾子。监控系统报“数据库连接池耗尽”，开发组非说是应用层代码漏关连接，运维组咬死是连接池配置太小。两边吵了两个小时，我实在听不下去，直接登录服务器查日志——结果发现是第三方服务接口超时，应用层重试机制把连接池撑爆了。我把日志截图甩群里，开发主管回了个“哦”，运维组长发了个“尴尬”的表情包。我关掉电脑时，窗外正飘着雪，突然想起二十年前第一次处理故障，师傅蹲在机房地上，边焊电路板边跟我说：“别信那些‘最佳实践’，故障现场没有标准答案，能解决问题的就是好答案。”

　　现在有些讨论太形式化了。上个月参加个技术沙龙，主持人让用“SWOT分析法”讨论故障处置，我差点当场走人——故障来了，你还有时间画SWOT矩阵？最搞笑的是有人提议“建立故障处置知识图谱”，说要把所有故障场景和解决方案结构化。我原以为他是开玩笑，结果上周真的收到份需求文档，要求把“数据库连接池耗尽”这种场景拆解成“原因-影响-解决方案”三部分，每部分还要配流程图。我回复：“要不直接写个‘重启服务器’得了？”对方回：“这样不够专业。”

　　其实故障处置的“优胜劣汰”特别简单——能快速定位问题、能果断采取措施、能承担决策后果的方案，就是好方案。去年2月那次崩溃，小王按表大小恢复虽然被骂，但业务确实最先恢复；我直接查日志定位第三方接口问题，虽然显得“不够专业”，但解决了根本原因。反倒是那些追求“技术共识”“行业标准”的方案，往往在故障现场抓瞎——因为现实永远比预案复杂，变量永远比理论多。

　　今天下班前，又收到份“故障处置流程优化建议”，里面写着“建议增加故障分级响应机制，根据影响范围和严重程度启动不同级别的应急流程”。我盯着屏幕看了三秒，直接删掉——去年双十一，某平台就是按“分级响应”流程走，结果因为判断失误，把小故障拖成了大事故。要我说，故障处置就该像打仗——指挥官在现场，看准时机，拍板，执行，别整那些花里胡哨的。至于技术讨论？等业务稳了，爱怎么讨论怎么讨论，但别在故障现场扯这些。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!