一次系统崩溃,让团队立下铁规:写代码前先问5个“为什么”

周一早会刚结束，年轻程序员小杨就盯着监控面板皱起了眉，核心接口又崩了，这是本周的第三次。他熟练地打开配置文件，准备再加一层缓存，手却被一只带着咖啡渍的鼠标轻轻按住了。

“先别急着加缓存。”架构师老陈的声音很稳，“我们用5why法问几个为什么。”

问：“为什么接口会崩？”
答：“请求量冲垮了数据库连接池。”
问：“为什么连接池会耗尽？”
答：“用户行为分析的关联查询太慢，连接占着不放。”
问：“为什么要做这么复杂的关联查询？”
答：“产品要实时报表，客户要最新数据。”
问：“客户为什么需要实时报表？”

最后一问让小杨卡壳了。他拨通客户对接人的电话，半小时后得到答案：所谓“实时”，只是客户希望在每周一的早会前5分钟拿到数据。

那天下午，团队在白板上做了一场“归零练习”，把需求文档里所有的“必须”都划掉，换成“真的吗？”。原来，80%的复杂逻辑，都是为了满足一个被误读的需求。

重构方案简单得惊人：用定时任务在每周一早会前生成快照报表，替换掉实时关联查询；加一层轻量缓存应对早会高峰。代码量砍了三分之二，性能反而提升了十倍。

上线前夜，小杨仍有些忐忑：“这么简单，会不会太草率？”

老陈递过一杯热美式：“架构的本质不是炫技，是恰如其分。就像你不会用挖掘机去拧螺丝。”他顿了顿，“我刚入行时，为了优化一个报表，把系统改得像瑞士手表，后来才发现，客户只需要每月看一次数据。”

后来，团队里多了一个不成文的规矩：写代码前，先问五个“为什么”。小杨把这句话贴在了显示器边框上，他终于明白，架构师不是画PPT的人，而是帮大家把问题挖深的人。

在这个追求“微服务”、“云原生”的技术圈里，我们总忙着用新框架、新名词武装系统，却忘了停下来问问：我们到底在解决什么问题？

每一次系统崩溃，都是在提醒我们：别只顾着给破桶钉木板，要先看看，我们是不是真的需要这只桶。毕竟，最好的架构，从来不是最复杂的那个，而是最懂需求的那个。