35 岁做底层技术：把一次架构判断讲清楚，比讲英雄故事更有用

35岁继续做底层，我更在意能否把一次判断讲清楚，而不是能否把经历讲得惊险。女性技术人的可信度也不需要靠“在所有人都束手无策时接过终端”来建立。没有可公开证据的救火细节，写得再像现场，也只是故事。

原理示意，非真实系统截图或性能测量。

一道不需要虚构事故的评审题

假设团队正在考虑给分析查询增加CPU线程。供应商材料说新平台带宽更高，基准更快。架构评审需要先把问题收窄：我们当前慢在算术、内存带宽、磁盘，还是排队？若主要时间耗在对象存储，增加计算线程可能只是更快地等。

10月21日ClickHouse发表Vera CPU实验，在早期访问机器上使用Memory表研究过滤、聚合与JOIN的线程扩展。它把数据放在内存中的条件写得很清楚。对我们关心的磁盘恢复时间，这份实验没有直接给答案。

我会把评审记录写成这样：

这不是礼貌性地给结论加一句“视情况而定”，而是把下一步测量的对象写出来。

技术表达也要允许反证

如果验证后发现增加线程没有收益，记录仍有价值：它排除了一个方向。若只把成功结果写进材料，团队很快就会忘记哪些路已经走不通，下一位同事又来交一次学费。

10月13日的ClickHouse尾延迟复盘把协议完成点、拥塞窗口和空闲连接分开排查。对我而言，可学的不是“高手一眼看穿”，而是每个假设如何变成可观察条件。专业判断应该允许别人沿着证据走到同一处，也允许别人指出哪里还没证实。

年龄不替代贡献，性别也不替代证据

长期做存储确实会积累耐心，但年资不是一次判断正确的证明。年轻同事发现一个反例，值得认真处理；资深同事也应能说“这段我没测过”。

这篇没有新增性能实验，没有真实生产事故可供复盘。上面的评审场景明确是假设，公开实验属于原作者。我的立场只是：把目标、限制、反证与回滚路径写进决策记录，比给自己加一个救火标签更经得起时间。

技术人的尊严可以很具体：一次评审少说半句没有依据的话，下一个接手的人就少猜一件事。