稳定性治理日志（二）：复盘会上

本故事纯属虚构，如有雷同，纯属巧合。

那天的复盘会，是在一个下雨的周二下午召开的，雨点敲打窗台的节奏，像极了系统报警时的Bot提示音——短促、密集、令人心烦。

14:03，会议开始。

黄工一如既往地坐在会议桌靠窗的位置，背后是微微泛潮的墙壁。他没有制作PPT，只是打开了事故处理系统的历史记录，光标在屏幕上方闪烁，如同事故现场残留的焦灼余温。

“上周的稳定性事故大家应该都还记得吧，我简单讲一下。”他用一贯平静的语调，复述了那次凌晨的雪崩：慢SQL如瘫痪神经蔓延全库，CPU拉满，监控红线齐鸣，最后靠着业务低谷期的自然回落，侥幸逃过了全面崩溃的命运。

“这次我们还是动作慢了点，侥幸不是实力。有没有什么改进建议？”黄工扫视全场。

空气沉默。

我端着泡冷的速溶咖啡，终于开口：“事故发生的第一时间，我们做了什么？是否有按预案执行？”

黄工点了点头，接话：“我当时在群里丢了一个慢SQL，只有林工回了我，其他人都没反应。是不是群通知都关了？”

我没在群里，那时候我正蹲在 Grafana 里一行一行地扒着日志，期望能发现问题的来源。

“这说明我们的应急预案本身就不够具体，团队协作机制也没建立清楚。”我说。

“对，还有应对策略也太单一了。”黄工叹气，“靠杀慢SQL治标不治本，我们是不是该把OLTP和OLAP彻底剥离了？”

我点头：“这个方向在两个月前的故障复盘就已经被提到过了。”

“是，但还没推进。”他苦笑了一下，“大家还有别的建议吗？”

14:17，会议室门被推开，宋总进来了，手里还拎着刚拿到的星巴克咖啡，热气未散。这个名义上的技术总监在整个系统架构上的参与并不多，但凡是“资源”和“预算”相关，他总会准时现身。

“我听说这次事故是数据库压力太大？现在我们打算怎么处理？”他直接发问，语气里没有责备，但也毫无温度。

黄工顿了顿，回答：“先考虑对所有的订单库都构建一个备库，构建读写分离，至少能缓解压力峰值，支撑更久。我们一共有四个订单库…”

“订单库不是去年就规划过备库方案吗？为何现在又冒出来？撤了建，建了撤？”宋总的语气中透着不解，仿佛他记忆中的撤库事件理所当然地存在。然而，这种印象与现实完全不符——事实上，我们根本从未搭建过备库。

房间内的气氛骤然紧张，信息在层级传递中彻底断裂。我看向黄工，他的神色中满是困惑与无奈，仿佛在努力追问：为何上层的某些认知会与实际操作相悖？正是这种沟通不畅和决策失真的结果，使得一些虚幻的“事实”在高层中生根发芽，而实际工作中却毫无对应。

我们都清楚，真正的决策并非在透明的Pull Request中经过充分讨论，而是在上层会议室里，由一句模糊不清、未经验证的指令随意“定论”。这种脱离实际的指令不仅掩盖了真实的问题，更让信息在传递过程中不断失真、扭曲。

14:22，杨工也发话了。他是云资源采购的负责人，一提“四个订单库的备库”，他眉头就皱了：“这个成本要多少？之前几个实例扩容都还没审批下来，你这备库又得上多少台？CPU？IOPS？带宽？这些都是钱。”

他说的没错。但问题是，这种情况下，“省钱”与“活下来”总不能兼得。

我瞥见黄工低头翻着笔记本上的草稿，那是他自己写的备库部署方案，现在还没机会展开。他没有再争辩，只说：“我没什么要补充的了。”

会议陷入冷场。没人再说话。

“那……今天就这样吧，大家散会。”宋总端着咖啡离开了会议室。

14:31，复盘会结束，雨还在下。我们走出会议室，仿佛从一场技术与权力的棋局中抽身，没人赢，但每个人都输了点什么。

那一刻我终于明白，所谓的“工程问题”，从来不是冷冰冰的技术拼图。它是一场多方博弈的持久战，是在有限资源、分散权责、模糊边界中寻求平衡的艺术。

数据库不是挂掉了，而是倒在了权力与成本的跷跷板上。

真正的解决方案，不仅在代码里，更在会议室的语气中，在组织结构的缝隙间，在那道没人回答的提问之后：