|
| 1 | +--- |
| 2 | +layout: post |
| 3 | +title: "稳定性治理日志(二):复盘会上" |
| 4 | +date: 2025-4-9T00:00:00 |
| 5 | +category: 稳定性 |
| 6 | +tags: ['稳定性'] |
| 7 | +--- |
| 8 | + |
| 9 | +# 稳定性治理日志(二):复盘会上 |
| 10 | + |
| 11 | +> 本故事纯属虚构,如有雷同,纯属巧合。 |
| 12 | +
|
| 13 | +那天的复盘会,是在一个下雨的周二下午召开的,雨点敲打窗台的节奏,像极了系统报警时的Bot提示音——短促、密集、令人心烦。 |
| 14 | + |
| 15 | +14:03,会议开始。 |
| 16 | + |
| 17 | +黄工一如既往地坐在会议桌靠窗的位置,背后是微微泛潮的墙壁。他没有制作PPT,只是打开了事故处理系统的历史记录,光标在屏幕上方闪烁,如同事故现场残留的焦灼余温。 |
| 18 | + |
| 19 | +“上周的稳定性事故大家应该都还记得吧,我简单讲一下。”他用一贯平静的语调,复述了那次凌晨的雪崩:慢SQL如瘫痪神经蔓延全库,CPU拉满,监控红线齐鸣,最后靠着业务低谷期的自然回落,侥幸逃过了全面崩溃的命运。 |
| 20 | + |
| 21 | +“这次我们还是动作慢了点,侥幸不是实力。有没有什么改进建议?”黄工扫视全场。 |
| 22 | + |
| 23 | +空气沉默。 |
| 24 | + |
| 25 | +我端着泡冷的速溶咖啡,终于开口:“事故发生的第一时间,我们做了什么?是否有按预案执行?” |
| 26 | + |
| 27 | +黄工点了点头,接话:“我当时在群里丢了一个慢SQL,只有林工回了我,其他人都没反应。是不是群通知都关了?” |
| 28 | + |
| 29 | +我没在群里,那时候我正蹲在 Grafana 里一行一行地扒着日志,期望能发现问题的来源。 |
| 30 | + |
| 31 | +“这说明我们的应急预案本身就不够具体,团队协作机制也没建立清楚。”我说。 |
| 32 | + |
| 33 | +“对,还有应对策略也太单一了。”黄工叹气,“靠杀慢SQL治标不治本,我们是不是该把OLTP和OLAP彻底剥离了?” |
| 34 | + |
| 35 | +我点头:“这个方向在两个月前的故障复盘就已经被提到过了。” |
| 36 | + |
| 37 | +“是,但还没推进。”他苦笑了一下,“大家还有别的建议吗?” |
| 38 | + |
| 39 | +14:17,会议室门被推开,宋总进来了,手里还拎着刚拿到的星巴克咖啡,热气未散。这个名义上的技术总监在整个系统架构上的参与并不多,但凡是“资源”和“预算”相关,他总会准时现身。 |
| 40 | + |
| 41 | +“我听说这次事故是数据库压力太大?现在我们打算怎么处理?”他直接发问,语气里没有责备,但也毫无温度。 |
| 42 | + |
| 43 | +黄工顿了顿,回答:“先考虑对所有的订单库都构建一个备库,构建读写分离,至少能缓解压力峰值,支撑更久。我们一共有四个订单库...” |
| 44 | + |
| 45 | +“订单库不是去年就规划过备库方案吗?为何现在又冒出来?撤了建,建了撤?”宋总的语气中透着不解,仿佛他记忆中的撤库事件理所当然地存在。然而,这种印象与现实完全不符——事实上,我们根本从未搭建过备库。 |
| 46 | + |
| 47 | +房间内的气氛骤然紧张,信息在层级传递中彻底断裂。我看向黄工,他的神色中满是困惑与无奈,仿佛在努力追问:为何上层的某些认知会与实际操作相悖?正是这种沟通不畅和决策失真的结果,使得一些虚幻的“事实”在高层中生根发芽,而实际工作中却毫无对应。 |
| 48 | + |
| 49 | +我们都清楚,真正的决策并非在透明的Pull Request中经过充分讨论,而是在上层会议室里,由一句模糊不清、未经验证的指令随意“定论”。这种脱离实际的指令不仅掩盖了真实的问题,更让信息在传递过程中不断失真、扭曲。 |
| 50 | + |
| 51 | +14:22,杨工也发话了。他是云资源采购的负责人,一提“四个订单库的备库”,他眉头就皱了:“这个成本要多少?之前几个实例扩容都还没审批下来,你这备库又得上多少台?CPU?IOPS?带宽?这些都是钱。” |
| 52 | + |
| 53 | +他说的没错。但问题是,这种情况下,“省钱”与“活下来”总不能兼得。 |
| 54 | + |
| 55 | +我瞥见黄工低头翻着笔记本上的草稿,那是他自己写的备库部署方案,现在还没机会展开。他没有再争辩,只说:“我没什么要补充的了。” |
| 56 | + |
| 57 | +会议陷入冷场。没人再说话。 |
| 58 | + |
| 59 | +“那……今天就这样吧,大家散会。”宋总端着咖啡离开了会议室。 |
| 60 | + |
| 61 | +14:31,复盘会结束,雨还在下。我们走出会议室,仿佛从一场技术与权力的棋局中抽身,没人赢,但每个人都输了点什么。 |
| 62 | + |
| 63 | +那一刻我终于明白,所谓的“工程问题”,从来不是冷冰冰的技术拼图。它是一场多方博弈的持久战,是在有限资源、分散权责、模糊边界中寻求平衡的艺术。 |
| 64 | + |
| 65 | +数据库不是挂掉了,而是倒在了权力与成本的跷跷板上。 |
| 66 | + |
| 67 | +真正的解决方案,不仅在代码里,更在会议室的语气中,在组织结构的缝隙间,在那道没人回答的提问之后: |
| 68 | + |
| 69 | +“我们准备好为稳定性付出多少代价?” |
0 commit comments