每年一到十月底，我就开始犯恶心。为因为我们那个季度财报前的预算审批，总是卡在“11.2”这个点上——不是什么高大上的技术升级，而是把那些陈年烂谷子的技术债拿出来晒太阳，问你为啥没解决，但又不会给你批钱去解决。
这帮领导永远是那几个问题：为什么我们XXX系统还在跑三年前的架构？为什么存储占用量比去年多了40%？为什么夜间批处理失败率总是蹭蹭往上涨？每年都要解释，每年都一样，跟复读机似的。今年我彻底烦了，我决定不解释了，我直接把答案提前做成文档，一脚踢过去，让他们自己看。
实践开始：动手把痛点数据扒出来
我这个人，你让我动嘴皮子不如让我动键盘。既然他们想知道“11.2的常见疑问”是那我就把这些疑问的根源，也就是那些血淋淋的数据，全部捞出来。
我干的第一件事就是抓日志。我直接跑了脚本，把过去九十天内，所有标记为“高风险”或“需人工干预”的系统告警日志全部导出，然后开始分类。之前这些日志都扔在不同的ELK集群里，没人管，堆得跟小山一样。
- 第一周，我就是个挖煤工。我先是手动筛选了前一百条最频繁的告警，发现其中六成指向同一个遗留系统。这系统谁都不敢动，但它天天在报错，就是没人愿意认领。
- 第二周，我开始对比。我把运维组那边扒过来的资源利用率图表，跟我自己从代码层面跑出来的调用栈数据进行交叉比对。这一比不要紧，发现某几个核心服务虽然代码没动，但随着业务量涨了，它占用的计算资源直接翻了倍。这玩意儿在年初预测的时候根本没人发现。
我把这些实际运行中的异常数据，全部翻译成大白话，去掉了所有专业术语。比如，不说“内存页错误”，我说“跑着跑着就死机了”。这样，就算隔壁卖咖啡的也看得懂我们在瞎忙活
构建“11.2问答清单”的逻辑
光有数据没用，得把数据和管理层关心的问题对上号。管理层最关心钱和风险。所以我的文档结构，直接奔着这两个核心点去。
我把所有常见疑问都归了三类，然后针对每一类，我不是给出解决方案，而是给出“为什么现在是这个鸟样”的实践记录：
第一类：成本疑问（为什么花这么多钱？）
我直接亮出那几个资源消耗大户。不是说新业务多花钱，而是那几个老祖宗系统，它们吃得多，干得少。我甚至把它们每天多烧的电费和云服务费用都估算出来了。我发现，光是那个遗留数据库集群，每年浪费的存储预算就能请一个全职高级架构师。我把这个数字狠狠地写在了文档的第一页。
第二类：风险疑问（会不会突然崩了？）
我把那堆“高风险告警”清单直接扔过去。这块内容，我特别强调了“单点依赖”。我把那个谁都不敢动的遗留系统，用红框圈出来，明确指出，一旦它在11.2之后任何一个时间点嗝屁，会连带拖垮哪三个关键业务。这比任何复杂的风险评估报告都管用，因为这是我亲手从生产环境里抓出来、验证过的。
第三类：资源疑问（为什么总说人不够？）
针对人员配置，我展示了一个时间线。我没有抱怨人少，而是把团队花在处理各种突发问题（就是我第一周抓出来的那些告警）上的工时，拉出来做了个饼图。结果很清楚，我们40%的时间都在给那个遗留系统“擦屁股”。我直接粗暴地得出我们不是缺人手去开发新东西，而是现有的人手被困在旧系统里，没法解放出来。
结果与个人反思
到了11.2那天，会议室里，领导果然又开始问那些熟悉的不能再熟悉的问题。我没等他们问完，直接把那份我花了两周时间捣鼓出来的“11.2常见疑问及实测数据报告”发了过去。
场面瞬间就安静了。他们盯着那些表格和红色高亮的风险点，没人再追着问“为什么”。他们看得很明白，我不是在抱怨，而是在呈现一个已经发生的事实。他们要的不是我的解释，而是能够帮他们规避责任、向上汇报的证据。而我这份东西，就是最硬的证据，因为这是从实践中抠出来的。
为啥我非要这么干？这事儿把我多年前的一段经历给治愈了。
那时候我在上一个公司，也是年底，一个系统突然崩了，客户损失巨大。我明明之前就口头报告过系统有隐患，但当时大家都在忙着赶进度，没人听我的。出了事，所有人都把锅甩给了我，说我没有“正式书面”记录风险。那次我差点被搞得灰头土脸，工资也被扣了半截。
从那以后我就明白了：你嘴上说一万遍不如你动手抓一次数据。所有的问题，只要你亲手去实践、去记录、去验证，它就不是一个问题，而是一个板上钉钉的事实。而这份11.2清单，就是我给自己和团队设置的一道防火墙。实践证明，自己把数据准备比等别人来问高效一万倍。
