决策日志是什么
决策日志记录重要决策的上下文与理由：日期、主题、决策内容、背景、备选方案、依据、影响范围与当前状态。它回答的是“当时为什么这样选”，减少后人反复推翻与重复讨论，也让新成员能快速理解决策背后的约束。
怎么维护才不流于形式
只记录重大决策（涉及架构、供应商、组织与预算方向），普通决策按需记录，否则日志会因数量失控而无人填写。条目写成当时的事实与权衡，不做事后美化；集中存放在可检索的位置，并定期回顾假设是否仍成立，不成立的决策要显式标注失效原因。
基本信息
| 必备字段 | 日期、主题、决策、背景、备选、依据、影响、状态 |
|---|---|
| 记录范围 | 重大决策必须留痕，普通决策按需 |
| 存放要求 | 集中、可检索、便于新人阅读 |
| 复盘机制 | 定期回顾假设是否仍成立，标注失效原因 |
典型使用场景
- 技术选型：记录备选方案与选择理由
- 架构演进：说明当时的技术约束与取舍
- 供应商决策：记录评估过程与合同关键条款
- 组织调整：记录变更背景与预期效果
- 安全策略：记录风险接受与补偿措施
- 项目终止：保留结论，避免同类项目重复立项
条目示例
条目示例
主题：消息队列选型
决策：采用 Kafka（2026-05，决议人：架构组）
背景：峰值 20 万 TPS，需要消息回放能力
备选：Pulsar / RocketMQ（对比见附件）
依据：吞吐与生态成熟度；团队已有运维经验
状态：生效中，计划 2026-12 复盘字段与作用
| 字段 | 内容 | 作用 |
|---|---|---|
| 背景 | 当时的业务与技术约束 | 理解取舍前提 |
| 备选 | 考虑过哪些方案 | 避免重复调研 |
| 依据 | 选择的关键理由 | 争议时可回溯 |
| 状态 | 生效、已变更或已失效 | 防止旧决策被误用 |
决策日志要记录当时的认知边界：写清“当时不知道什么”，后来者才不会用事后信息指责当时的判断。