去年冬天，技术我蹲在机房冰冷的总结字范地板上，盯着一台刚烧毁的技术电源模块，手里的总结字范万用表还停留在蜂鸣档。那是技术我第三次在同一块板子上栽跟头——前两次是虚焊，这次是总结字范电容耐压选低了。旁边运维老张递过来一杯速溶咖啡，技术说了句：“你这毛病，总结字范跟三年前刚入行时一模一样。技术”这句话比烧掉的总结字范模块更让我难受。

技术这行，技术犯错不可怕，总结字范可怕的技术是同一个坑反复踩。我后来专门建了个文档，总结字范取名“踩坑记”，技术每次故障处理完就记一笔：时间、现象、根因、解决动作、后续预防。半年下来，文档里攒了四十七个条目。翻回去看，至少八条是同类问题换了张皮。比如“配置文件漏改”出现了三次，分别发生在Nginx、Redis和Kafka上。表面看是三个不同组件，实际都是部署流程缺少自动化校验环节。于是我在发布脚本里硬塞了一段diff检查，谁跳过谁背锅。这事之后，同类故障归零。

很多人把技术总结写成流水账，或者堆砌术语显得专业。我见过一份运维报告，三页纸里出现了二十三次“高可用架构”和十七次“弹性伸缩”，但具体到那次数据库主从切换失败，只写了“经排查为网络抖动”。网络抖动？是交换机端口CRC错误，还是TCP重传超时？是物理链路问题，还是内核参数没调？不写清楚，下次换个人值班，照样抓瞎。我的习惯是：故障报告里必须出现至少一个具体数字——丢包率、延迟毫秒数、错误日志行号。没有数字的总结，等于没写。

写技术文档和写代码有个共同点：读者优先。你写给三个月后的自己看，还是写给刚入职的新人看，措辞完全不同。我负责过一个内部工单系统重构，第一版接口文档写得像天书，每个字段都解释，但没写调用顺序。结果联调时，前端同事把查询接口放在鉴权接口之前调用，返回全是403。后来我加了一张时序图，用文字描述清楚“先拿token，再带token查数据”，联调时间从两天缩到两小时。文档不是炫技的地方，是降低沟通成本的地方。

说到成本，技术决策里最容易被忽略的就是维护成本。去年团队选消息队列，两个候选：一个社区活跃、文档齐全，但资源占用高；另一个性能彪悍、内存省一半，但issue区里一堆“生产环境丢消息”的抱怨。我们选了前者。三个月后，隔壁组选了后者，半夜被报警叫醒三次。性能参数是纸面的，半夜爬起来修bug的痛苦是真实的。技术总结里如果只写“选用XX组件，吞吐量提升30%”，不写“为此多付了20%服务器成本和每周两小时运维精力”，那就是耍流氓。

还有个事挺有意思。我观察过身边技术强的人，他们写总结有个共同习惯：必写“如果重来一次，我会怎么做”。这句话逼着你跳出当时的局限，用上帝视角复盘。比如那次电源模块烧毁，如果重来，我会在选型阶段就加一道降额设计检查，而不是等到烧了才翻 datasheet。这种假设性反思，比单纯记录“更换了耐压更高的电容”有价值得多。前者是方法论，后者只是操作记录。

最后说个反直觉的：技术总结不一定要长。我见过最有用的一份总结，是某次线上故障后，负责人只写了五行字——故障现象、影响范围、根因、修复动作、后续动作。每行不超过二十个字。但每个字都砸在点上。后来这份总结被贴在了团队白板上，整整一个月没人再犯类似错误。反倒是那些动辄三五千字的“深度复盘”，发在群里连个水花都没有。写清楚，比写多重要。你写的是给人看的，不是给考核系统看的。

(责任编辑：百科)