一、拆东墙补西墙的日子
大促结束，技术部松了口气，但问题开始冒头：
- 支付模块为了赶工，跳过了测试，结果大促当天线上出了 3 次故障；
- 库存模块有个"临时方案"——写死的库存阈值，现在每次调价都要改代码；
- 阿杰离职了，他负责的会员模块没人看得懂，新来的同事小周接手，第一周就哭了。
小陈把这些现象说给老周听："师傅，咱们好像……在还债？"
"不是'好像'。"老周说，"是欠了一屁股技术债。这一章，我们把'债'这件事彻底讲清楚。它分两块：风险（怎么防出事） 和 度量（怎么知道好不好）。"
二、第九层：风险管理——先算算你欠了多少债
2.1 技术债：欠的，迟早要还（带利息）
"技术债（Technical Debt），是 1992 年一个叫沃德·坎宁安的程序员提出的概念。"老周说，"它的核心比喻：写代码图快、图省事、跳过规矩，就像借钱花——当下爽，但债务会累积，还带利息。"
技术债的四种形态：
1. 明知故犯债：赶工期，跳过测试/评审（利息：线上事故）
2. 设计债：架构没想好就开写，后来推倒重来（利息：改不动）
3. 文档债：代码没人看得懂，维护全靠"当事人"（利息：巴士因子=1）
4. 依赖债：用了没人维护的老库、过期版本（利息：安全漏洞）
利息的表现：
- 加一个新功能，要改的地方越来越多
- 每次改代码都怕炸，速度越来越慢
- 新人上手越来越难
"注意：技术债不全是坏事。"老周强调，"为了抢上线窗口，借一点债是合理的商业决策——就像开店周转资金。关键是要'记账'：知道借了多少、什么时候还。最怕的是'借了不记，利滚利，最后破产'。"
云间书店 · 技术债清单（示例）：
[ ] 支付模块缺集成测试 —— 借债日期：6/1，应还日期：7/1（逾期！）
[ ] 库存阈值硬编码 —— 借债日期：5/20，计划重构：8/15
[ ] 会员模块无文档 —— 借债日期：3/1，小周接手后优先补
[ ] 依赖库 requests 版本过旧 —— 安全漏洞 CVE-2026-xxxx，本周还
"技术债清单要纳入排期——每个 Sprint 留出 20% 时间还债，就像每月固定还信用卡。不还债的团队，会越走越慢，直到走不动。"
2.2 依赖管理：你的系统，建立在别人的代码上
"还有一个风险源：依赖（Dependencies）。"老周说，"咱们系统用了 137 个第三方库。每一个都是别人写的代码，都可能有 bug、有漏洞、有版本冲突。"
依赖管理的三条铁律：
1. 锁定版本：requirements.txt / lock 文件，保证所有人装同一版本
2. 定期更新：安全更新要及时，别用"没人维护的老版本"
3. 少而精：能不用第三方库就不用，每加一个库=多一份风险
工具：Dependabot（自动检测依赖更新）、npm audit / pip-audit（安全扫描）
2.3 安全与应急预案：出事前的准备
"还有两件事，平时看不见，出事才要命：安全 和 应急预案。"
安全基本盘（小团队也要做）：
- 密钥不写进代码（用环境变量/密钥管理）
- 数据库、后台加权限控制
- 依赖安全扫描（上面说的）
- 数据定期备份 + 演练恢复
应急预案（Runbook）：
- 线上挂了 → 第一步干什么？（先回滚，别边查边改）
- 数据库满了 → 怎么处理？
- 被攻击了 → 找谁？关哪个服务？
- 预案要写成文档，演练过，别出事才现想
三、第十层：度量与改进——用数据说话
3.1 周会上的灵魂拷问
某次技术部周会，老周问了一个让全场安静的问题：
"咱们团队，现在到底快不快？质量到底好不好？"
有人说"感觉还行"，有人说"最近挺忙的"，有人说"bug 好像少了"。
"感觉？好像？"老周说，"没有数据的'感觉'，是团队最大的错觉。 从今天起，我们每周看 4 个数字。这就是著名的 DORA 指标——Google 研究了上千个团队总结出的'软件交付四金指标'。"
3.2 DORA 四指标：衡量团队的"血压"
DORA 四指标（软件交付性能）：
① 部署频率（Deployment Frequency）
多久部署一次线上？ → 快团队：按需/每天；慢团队：每月/每季度
② 变更前置时间（Lead Time for Changes）
从代码提交到上线，要多久？ → 快团队：< 1 天；慢团队：1 周到 1 月
③ 变更失败率（Change Failure Rate）
上线的变更里，多少比例导致故障？ → 好团队：< 15%
④ 故障恢复时间（Time to Restore）
线上出故障后，多久恢复？ → 快团队：< 1 小时；慢团队：1 天以上
"这 4 个数字回答两个问题：快不快（①②）、稳不稳（③④）。注意——快和稳是统一的：能每天部署且很少出错的团队，才是真正快的团队。一个月部署一次还总出错的团队，是'假装稳定'。"
云间书店技术部 · 第一份 DORA 数据：
部署频率：每周一次（目标：每天）
变更前置时间：3.5 天（目标：< 1 天）
变更失败率：22%（目标：< 15%）← 偏高，要查
故障恢复时间：6 小时（目标：< 1 小时）
"看到没？数据不会骗人：我们以为挺好的，其实四项全不达标。 这就是度量的意义——先承认现实，才能改进。"
3.3 复盘（Postmortem）：出事后，最重要的是学习
"DORA 指标里'变更失败率 22%'，意味着我们经常出事。出事不可怕，可怕的是出完事就完了，下次照犯。"老周说，"所以每次事故都要做复盘（Postmortem）。"
复盘五问（对事不对人）：
1. 发生了什么？（时间线：什么时候开始、什么时候发现、什么时候恢复）
2. 根因是什么？（追问 5 个"为什么"，挖到系统层面，别停在"人操作失误"）
3. 为什么没有被提前发现？（监控？测试？评审？哪道防线漏了）
4. 怎么防止再发生？（改流程/加监控/补测试）
5. 谁来跟进？什么时候完成？
铁律：
- 复盘不是追责会，不惩罚人（惩罚只会让人隐瞒问题）
- 每个复盘必须有"改进项 + 负责人 + 截止日"
"记住：优秀团队的标志不是'从不犯错'，而是'同样的错不犯第二次'。 复盘，就是把这句口号变成流程。"
3.4 回顾会：定期的小复盘
"除了事故复盘，还要有定期回顾（Retrospective）——不等人出事，主动找改进点。"老周说，"Scrum 里每个 Sprint 结束都开回顾会，三句话："
回顾会三栏（20 分钟）：
做得好（继续做） | 有问题（改进） | 新想法（试试）
站会开得高效 | 测试太慢 | 试试结对编程
需求评审变少了 | 发布总在周五 | 留 20% 时间还技术债
"然后挑 1-2 个最痛的问题，下一个 Sprint 专门解决。改进要小步、要落地——一次改一件事，别列十件事然后一件都不做。"
四、章末：老周的第九、十层总结
第九层：风险管理
├── 技术债 → 借钱要记账，定期还（清单 + 20% 时间）
├── 依赖管理 → 锁版本、定期更新、少而精
├── 安全 → 密钥管理、备份演练、权限控制
└── 应急预案 → Runbook：出事先回滚，预案要演练
第十层：度量与改进
├── DORA 四指标 → 部署频率/前置时间/失败率/恢复时间
├── 复盘 → 对事不对人，挖根因，改进落地
└── 回顾会 → 定期小复盘，一次改一件事
"小陈，记住这一章最核心的一句话：没有度量就没有改进，没有复盘就没有成长。 团队的进步，不是靠'感觉'，是靠数据和反思堆出来的。"
"师傅，技术债、度量都讲了……但我觉得还有个更大的问题。"小陈犹豫着说，"咱们的代码，现在……好像越来越难改了。加一个功能，要动十几个文件，改完这个崩那个。这算什么问题？"
老周的眼睛亮了："你问到最深的那个问题了。这不是 bug，是架构问题。 下一章，也是管理家族树里最'技术'的一层——架构与治理。当代码变成一个大泥球，再好的流程也救不了。"