第 12 章 综合案例:OOS 订单系统全生命周期实战本章把前 11 章的方法串到同一个项目的时间线上,展示每个阶段做什么、产出什么、常见坑是什么。它是全系列的总装配车间:前 11 章的零件在这里装配成整车。学习目标将需求、设计、编码、测试、配置、管理、质量、DevOps 方法落到同一项目时间线体验阶段间的工件衔接与追溯识别各阶段的典型失败模式及其对策建立从提交代码到用户看到功能的完整心智模型0. 项目背景(回顾)OOS(Order System):零售企业订单管理系统。业务:商品目录、购物车、下单(库存校验 支付)、订单状态流转、退货售后;约束:Web 移动端,日均 10 万单,与 ERP/支付网关集成,SLA 99.9%;团队:PO ×1、架构 ×1、开发 ×5、测试 ×2、SRE ×1、PM ×1(共 11 人,拆两个小队);过程:Scrum 双周迭代 Trunk-Based CI/CD 季度路线图。时间线总览W0-2 启动与规划(风险地图、估算、过程定义) W2-6 迭代 1-2:需求工程(SRS v1.0、状态机、追溯矩阵) W4-8 迭代 2-3:架构与详细设计(ADR、契约、评审) W6-16 迭代 3-6:编码 单元测试(TDD 核心模块) W12-20 迭代 5-8:集成与系统测试(契约、性能、安全) W16 发布 1(蓝绿)→ 金丝雀转型 W20 运营期(SLO、混沌、DORA 看板) Y2 维护与演进(技术债、绞杀者、跨境微服务)1. 启动与规划(第 0–2 周)活动产出方法来源业务目标对齐业务需求 BR 列表(3 条核心)第 3 章干系人分析干系人矩阵(业务/仓库/财务/支付方/安全)第 3 章过程选型过程定义文档(迭代节奏、门禁、角色)第 2 章初步估算发布 1:14 人月期望 / 18 人月承诺(三点法)第 8 章风险登记册 v1R1 联调延迟、R2 容量、R3 关键人、R4 范围蔓延第 8 章团队组建两小队(订单组/支付与集成组),康威对齐第 8 章三条 BR(示例):BR-01:支撑双 11,峰值 1000 单/秒,下单成功率 ≥99.9%;BR-02:人工对账成本降低 50%(系统自动对账);BR-03:退货售后全流程线上化,客服工单减半。坑:跳过干系人分析直接开工 → 财务对账需求到测试阶段才提出,返工 2 人周。对策:干系人清单是需求启动的门禁,缺财务 不放行。估算推演(8.2 方法):类比历史项目 12 人月 → 三点 O10/M14/P20 → 期望 14 → 承诺 18(25% 缓冲,缓冲放在承诺层)。实际发布 1 消耗 17.5 人月,偏差 -3%——校准数据入库,供发布 2 参考。2. 需求工程(迭代 1–2)获取:运营访谈 仓库影子跟随 支付网关文档分析 JAD 工作坊(解决改价与留痕冲突);分析:订单状态机建模(第 4 章图)、核心用例提交订单含 6 条异常流;规格:SRS v1.0,功能需求 42 条(编号 FR-*)、NFR 12 条(全部量化,如下单 P95 300ms 10 万单/日)、约束 5 条;验证:需求评审(发现 17 条问题,3 条不可测被量化重写) 高保真原型演示;管理:双向追溯矩阵建立;变更走 CR 流程(本迭代 2 条 CR,1 条批准 1 条拒绝)。冲突消解实例(3.3 方法):运营随时改价 vs 财务留痕不可篡改 → 调和为改价审批流 不可变审计日志,产出 FR-PRICE-003 与 NFR-AUDIT-001。坑:预售定金CR 被 PO 坚持 → 影响分析显示触及状态机 支付协议,CCB 判定本版本拒绝,列入下季度。拒绝也是变更控制的产出。需求阶段度量:评审发现 17 条(非零,健康);CR 前置时间 4 天;追溯完整度 100%(CI 检查上线)。3. 设计(迭代 2–3,与需求部分并行)架构:单体分层(表现/业务/数据) 事件总线(订单状态广播);微服务拆分列入 v2 评估(康威:团队未分,先不拆);ADR 记录:ADR-001 选单体而非微服务(团队规模 运维能力);ADR-007 库存最终一致(本地事务 预扣 对账补偿),拒绝 2PC;ADR-012 支付异步化 熔断降级(NFR 驱动);详细设计:核心领域模型类图、下单序列图、订单状态机(需求/设计/测试三方共享);设计评审:1 次,发现库存预扣与超时释放的竞态→ 补充幂等与分布式锁方案。设计完成判据自查(4.1):NFR→战术映射 ✓ / 接口契约(含错误码、幂等)✓ / 状态机 ✓ / ADR ×3 ✓ / 评审闭环 ✓——五项齐备,放行编码。坑:设计评审只走过场(0 缺陷)→ 竞态问题拖到集成测试才暴露,修复成本 ×5。对策:评审缺陷发现率纳入过程度量,连续两期为 0 触发审计。4. 编码与单元测试(迭代 3–6)规范:ESLint 类型检查 SonarQube 进 CI,分支覆盖门禁 ≥80%;TDD:核心计价与库存模块先行(红-绿-重构),接口设计被测试倒逼优化;BDD:关键业务规则(退款)用 Gherkin 描述,PO 可读可评审;重构纪律:重构与行为修改分 commit;双 11 前冻结重构窗口。代码评审:单次 ≤400 行,24 小时响应,发现率 3.2 条/PR(非零,健康)。度量:单测 1200 用例,分支覆盖 84%;静态分析 S1/S2 问题 0 开放。TDD 收益实例:库存预扣的幂等语义,在写第一个红测试时暴露了接口设计缺陷(reserve(sku, qty)无法表达同一订单重复调用)→ 接口改为reserve(orderId, sku, qty)以 orderId 作幂等键。测试在编码前救了一个集成期缺陷。5. 集成与系统测试(迭代 5–8)集成:订单↔库存↔支付 契约测试(防接口漂移);自顶向下,外部依赖用 Stub/Mock;系统功能:核心 E2E(下单→支付→发货→完成,含 5 条异常路径)自动化;性能:JMeter 基准(10 万单/日模型),P95 240ms 达标;压测发现库存表行锁竞争→ 优化分桶;安全:渗透测试 1 次(发现 2 个越权,修复) 依赖扫描持续;回归:每日全量 每次合入增量;flaky 治理:3 个不稳定用例隔离修复,1 个删除。集成高频缺陷命中(6.4 清单):金额单位(元/分)1 起、错误码吞并 2 起、重试不幂等 1 起——全部被契约测试在合入阶段拦截,未进系统测试。缺陷统计:共 214 个,按阶段发现比例——需求 17、设计 9、单元 82、集成 45、系统 51、UAT 10。集成占比 21%(目标 25%,达成)。逃逸 3 个(全 S3)。6. 配置与发布(迭代 8 起)Trunk-Based 特性开关;主干保护 PR 评审 CI 门禁;构建不可变:同一 commit 必出同一镜像,制品进 Registry;发布:v1.0 用蓝绿(资源允许);v1.1 转金丝雀(5%→25%→100%);回滚预案:每版本明确触发信号 目标版本 数据兼容说明;实际:发布 6 次,金丝雀回滚 1 次(支付渠道配置错误,10 分钟内切回)。不可变构建审计(7.5):某次紧急修复有人提议在生产重新构建→ 被流程拦下:修复走正常 PR,新制品走金丝雀。事件本身成为团队培训案例。开关审计(7.4):月度执行,峰值期开关 9 个,6 个带退役日期;1 个无主开关 48 小时内被认领或下线。7. 质量管理(全程)DoD(每迭代):单测 ≥80%、无 S1/S2 开放、E2E 核心流通过、文档同步;度量看板:速度、逃逸率、变更失败率、MTTR;改进试点:发现支付联调缺陷集中 → 试点接口评审 契约测试前置 → 下季度集成缺陷占比 21% → 16%;审计:半年度内部过程审计,对照标准过程库,3 项差距整改。改进项目书(9.3 模板):基线 45%(项目初期)→ 试点(订单-支付接口,契约变更强制评审)→ 两季度后 21% → 推广 → 再两季度 16%。全程一个改进项、一个 Owner、有退出标准——一次 1–2 个纪律的完整兑现。缺陷-过程漏洞回溯(9.2):3 个逃逸 S3 缺陷回溯,2 个源于UAT 场景未覆盖退款部分退款,1 个源于压测模型未含批量查询→ 补 UAT 场景与压测模型,均关闭。8. DevOps 与运营(上线后)SLO:下单成功率 99.9%(30 天),错误预算月度回顾;可观测性:结构化日志 traceId 全链路 Prometheus 指标 Jaeger 追踪;告警基于症状:用户侧下单错误率 0.5% 才告警(避免 CPU 噪音);混沌工程:大促前演练支付网关超时 30s→ 验证熔断 补偿 人工核对队列;DORA(上线 6 个月):部署频率 3 次/周、前置时间 4h、变更失败率 4%、MTTR 35min。第一次 P1 事故(复盘素材):某发布后下单错误率升至 2.1%(18 分钟)。时间线: 10:02 金丝雀 5% 错误率越限告警 → 10:04 自动切回 10:06 全量恢复 → 10:40 定位(新索引导致慢查询)→ 11:10 修复版本走完整流程上线 复盘结论: 止血机制(金丝雀自动回滚)有效,MTTR 8 分钟; 根因(系统层): 预发数据量 1:10,索引问题在预发不可复现; 改进项: 预发数据扩至 1:3 慢查询压测进发布检查单(Owner: SRE, 2 周)体现 11.8 纪律:止血优先、根因到系统层、改进项 ≤5 且有 Owner。9. 维护与演进(上线 1 年后)维护构成(12 个月):完善 52% / 适应 24% / 纠错 16% / 预防 8%;技术债登记册:12 项,偿还 5 项(大促后窗口),利息最高的 2 项优先;退化信号:订单模块圈复杂度上升、文档滞后 → 安排预防性重构 1 个迭代;现代化:业务提出跨境订单独立合规需求 → 绞杀者模式启动:新微服务承接跨境子集,旧系统 6 个月后退役订单模块;知识管理:关键模块双人制,轮岗 2 轮,ADR 库 18 篇。技术债偿还实例(10.2 公式):TD-07 计价 if-else 链,利息 2 人天/次 × 促销季 4 次变更 × 资金风险 ×2 高优先级 → 大促后窗口 3 人天偿还(提取 PricingStrategy 族),偿还后当季促销需求工时 -30%。绞杀者执行(10.5):跨境订单切流,每次切流前过检查单(行为回放对比 双写对账差异0 回滚演练 72h SLI 观察);旧订单模块设退役倒计时(切流日即倒计时起点),6 个月后无功能留存,正式下线。10. 全生命周期工件地图(汇总)启动 : BR 列表、干系人矩阵、过程定义、估算、风险登记册 需求 : SRS(编号)、用例模型、状态机、追溯矩阵、CR 记录 设计 : 架构文档、ADR 库、类图/序列图、接口契约 编码 : 源代码、单元测试、BDD 场景、静态分析报告 测试 : 测试计划、用例集(分层)、缺陷库、性能/安全报告 配置 : 仓库、基线、制品、发布检查单、回滚预案 管理 : 迭代计划、燃尽图、风险月报、DORA 看板 质量 : DoD、度量看板、评审记录、审计报告、改进项目 运维 : SLO/错误预算、监控告警、混沌实验记录、事故复盘 维护 : 技术债登记册、影响分析、现代化路线(绞杀者)工件间的接力关系(读图方法):每条工件都是下一阶段的输入——SRS 的 NFR 喂给架构战术,状态机喂给测试生成,接口契约喂给契约测试,SLI 定义喂给告警与发布门禁。任何一环工件缺失,下游就是盲飞。11. 跨阶段失败模式速查阶段典型失败根因对策需求上线后这不是我想要的干系人缺失/验证不足干系人门禁 原型演示设计改一处崩三处高耦合、无架构决策记录内聚/解耦 ADR编码重构不敢动无测试安全网TDD 覆盖门禁集成接口在我这没问题无契约、无联合评审契约测试 接口评审测试flaky 测试狼来了隔离差、数据耦合治理:修或删,不挂起发布上了测不了的近似版本构建可变不可变制品 制品库上线故障 2 小时才定位无链路追踪可观测性三支柱维护越改越难改技术债复利登记册 偿还窗口使用方式:团队复盘时,先在本表定位我们是哪种失败,再回到对应章节找根因与对策——本表是索引,不是答案。OOS 全年失败事件统计(复盘输入)事件阶段归类(上表)改进落地财务需求测试期才提出需求干系人缺失干系人门禁库存竞态集成期暴露设计评审走过场发现率审计支付渠道配置回滚发布构建/配置配置即代码索引慢查询 P1上线环境差异预发数据扩容计价 if-else 改不动维护技术债复利偿还窗口12. 复盘:OOS 做对的三件事与做错的两件事做对的:风险前置:支付 spike 第 2 周做完(螺旋),把最大外部风险消灭在编码前;工件接力:状态机/契约/追溯矩阵成为三方法共享的单一事实来源,需求-设计-测试零口径打架;度量闭环:每个改进项有基线-目标-退出,一年 4 个改进项全部兑现并推广。做错的:第一次设计评审走过场:付出集成期修竞态 ×5 成本的学费,此后用发现率为零触发重审机制修复;预发数据 1:10 太久:环境差异导致 P1,教训固化进发布检查单(慢查询压测 数据 1:3)。这两条做错的价值大于三条做对:它们证明了体系的自我修复能力——失败被捕获、归因、转化为门禁。这是过程成熟度最真实的标志(第 9 章 CMMI 5 级特征)。13. 如何把本章用于你自己的项目抄工件地图(第 10 节):作为新项目启动 checklist,逐行裁剪做不做/谁负责;抄检查单类工件:发布检查单(7.7)、绞杀者切流单(10.5)、复盘模板(11.8)、改进项目书(9.3)——直接可用;替换 OOS 数值:用你项目的真实数据替换(单量、P95、缺陷数),案例才活;每季度对照失败速查表复盘一次:定位归类 → 回章节找对策 → 定改进项;带新人读本章:2 小时能建立全生命周期心智模型,比逐章快得多。14. 本章 FAQQ1:OOS 11 人团队,这些过程会不会太重?对照裁剪原则(第 2 章):OOS 保留了全部工件接力工件,但把过程动作压到最小(一页纸策略、半页周报、单 PR 评审)。“重的感觉通常来自执行痕迹缺失后的临时补课”,而非工件本身。Q2:双周迭代里怎么塞下这么多活动?活动是叠加在迭代内的,不是串行:需求分析在设计迭代、测试设计在编码迭代、度量在迭代回顾。Scrum 的事件(计划/站会/评审/回顾)只是骨架,第 3–11 章的活动填在事件之间。Q3:如果我的项目只有 3 个月,砍掉哪些?按风险砍:无外部集成 → 砍 spike 与契约测试(保留接口评审);无合规 → 砍正式 SRS(保留故事 NFR 表);无大促 → 砍冻结窗口管理。永远不砍:干系人分析、测试(至少黄金路径)、版本管理、变更记录、事故复盘。15. 小结软件过程是工件驱动的:每个阶段的产出是下一阶段的输入,追溯性贯穿始终;方法不是孤立工具,而是风险结构的映射:哪里风险高,那里过程重;度量(缺陷分布、DORA、维护构成)是过程的体检仪,趋势比单点重要;失败模式大多可预防,且预防成本远低于修复成本;OOS 案例证明:中等规模团队用敏捷外壳 工程纪律 闭环反馈可以兼顾速度与稳定;体系成熟度的标志不是从不失败,而是失败被捕获、归因、转化为门禁。思考题(综合)画出 OOS 从提交代码到用户看到新功能的完整链路,标注每一环的自动化与人工点。若 OOS 团队从 11 人扩到 33 人,第 2 章的过程选型应如何调整?康威定律起什么作用?用缺陷成本放大律复盘:OOS 中库存竞态若在设计评审被抓住 vs 集成测试才暴露,成本差多少?过程上如何避免?设计 OOS v2(微服务化)的绞杀者路线:切分边界、双写方案、一致性验证、退役判据。为你的项目画一张工件接力图:列出 5 个关键工件,标明各自的上游输入与下游消费者,指出你当前最薄弱的一环。对照第 11 节失败速查表,给你团队最近 6 个月的 3 个失败事件归类,并各写一条门禁化改进。OOS 的做错的两件事都转化成了门禁——你的组织最近一次失败,转化成了什么?如果没有,为什么?假设你是 OOS 第二年的新 PM,接手时 DORA 四项指标全面恶化,写出你的 30 天诊断计划(看哪些数据、查哪些环节、找谁)。 
长河君 · 2026/10/13 3:11:44 · 阅读 1.2k 12-综合案例-软件过程实战演练
第 12 章 综合案例:OOS 订单系统全生命周期实战本章把前 11 章的方法串到同一个项目的时间线上,展示每个阶段做什么、产出什么、常见坑是什么。它是全系列的总装配车间:前 11 章的零件在这里装配成整车。学习目标将需求、设计、编码、测试、配置、管理、质量、DevOps 方法落到同一项目时间线体验阶段间的工件衔接与追溯识别各阶段的典型失败模式及其对策建立从提交代码到用户看到功能的完整心智模型0. 项目背景(回顾)OOS(Order System):零售企业订单管理系统。业务:商品目录、购物车、下单(库存校验 支付)、订单状态流转、退货售后;约束:Web 移动端,日均 10 万单,与 ERP/支付网关集成,SLA 99.9%;团队:PO ×1、架构 ×1、开发 ×5、测试 ×2、SRE ×1、PM ×1(共 11 人,拆两个小队);过程:Scrum 双周迭代 Trunk-Based CI/CD 季度路线图。时间线总览W0-2 启动与规划(风险地图、估算、过程定义) W2-6 迭代 1-2:需求工程(SRS v1.0、状态机、追溯矩阵) W4-8 迭代 2-3:架构与详细设计(ADR、契约、评审) W6-16 迭代 3-6:编码 单元测试(TDD 核心模块) W12-20 迭代 5-8:集成与系统测试(契约、性能、安全) W16 发布 1(蓝绿)→ 金丝雀转型 W20 运营期(SLO、混沌、DORA 看板) Y2 维护与演进(技术债、绞杀者、跨境微服务)1. 启动与规划(第 0–2 周)活动产出方法来源业务目标对齐业务需求 BR 列表(3 条核心)第 3 章干系人分析干系人矩阵(业务/仓库/财务/支付方/安全)第 3 章过程选型过程定义文档(迭代节奏、门禁、角色)第 2 章初步估算发布 1:14 人月期望 / 18 人月承诺(三点法)第 8 章风险登记册 v1R1 联调延迟、R2 容量、R3 关键人、R4 范围蔓延第 8 章团队组建两小队(订单组/支付与集成组),康威对齐第 8 章三条 BR(示例):BR-01:支撑双 11,峰值 1000 单/秒,下单成功率 ≥99.9%;BR-02:人工对账成本降低 50%(系统自动对账);BR-03:退货售后全流程线上化,客服工单减半。坑:跳过干系人分析直接开工 → 财务对账需求到测试阶段才提出,返工 2 人周。对策:干系人清单是需求启动的门禁,缺财务 不放行。估算推演(8.2 方法):类比历史项目 12 人月 → 三点 O10/M14/P20 → 期望 14 → 承诺 18(25% 缓冲,缓冲放在承诺层)。实际发布 1 消耗 17.5 人月,偏差 -3%——校准数据入库,供发布 2 参考。2. 需求工程(迭代 1–2)获取:运营访谈 仓库影子跟随 支付网关文档分析 JAD 工作坊(解决改价与留痕冲突);分析:订单状态机建模(第 4 章图)、核心用例提交订单含 6 条异常流;规格:SRS v1.0,功能需求 42 条(编号 FR-*)、NFR 12 条(全部量化,如下单 P95 300ms 10 万单/日)、约束 5 条;验证:需求评审(发现 17 条问题,3 条不可测被量化重写) 高保真原型演示;管理:双向追溯矩阵建立;变更走 CR 流程(本迭代 2 条 CR,1 条批准 1 条拒绝)。冲突消解实例(3.3 方法):运营随时改价 vs 财务留痕不可篡改 → 调和为改价审批流 不可变审计日志,产出 FR-PRICE-003 与 NFR-AUDIT-001。坑:预售定金CR 被 PO 坚持 → 影响分析显示触及状态机 支付协议,CCB 判定本版本拒绝,列入下季度。拒绝也是变更控制的产出。需求阶段度量:评审发现 17 条(非零,健康);CR 前置时间 4 天;追溯完整度 100%(CI 检查上线)。3. 设计(迭代 2–3,与需求部分并行)架构:单体分层(表现/业务/数据) 事件总线(订单状态广播);微服务拆分列入 v2 评估(康威:团队未分,先不拆);ADR 记录:ADR-001 选单体而非微服务(团队规模 运维能力);ADR-007 库存最终一致(本地事务 预扣 对账补偿),拒绝 2PC;ADR-012 支付异步化 熔断降级(NFR 驱动);详细设计:核心领域模型类图、下单序列图、订单状态机(需求/设计/测试三方共享);设计评审:1 次,发现库存预扣与超时释放的竞态→ 补充幂等与分布式锁方案。设计完成判据自查(4.1):NFR→战术映射 ✓ / 接口契约(含错误码、幂等)✓ / 状态机 ✓ / ADR ×3 ✓ / 评审闭环 ✓——五项齐备,放行编码。坑:设计评审只走过场(0 缺陷)→ 竞态问题拖到集成测试才暴露,修复成本 ×5。对策:评审缺陷发现率纳入过程度量,连续两期为 0 触发审计。4. 编码与单元测试(迭代 3–6)规范:ESLint 类型检查 SonarQube 进 CI,分支覆盖门禁 ≥80%;TDD:核心计价与库存模块先行(红-绿-重构),接口设计被测试倒逼优化;BDD:关键业务规则(退款)用 Gherkin 描述,PO 可读可评审;重构纪律:重构与行为修改分 commit;双 11 前冻结重构窗口。代码评审:单次 ≤400 行,24 小时响应,发现率 3.2 条/PR(非零,健康)。度量:单测 1200 用例,分支覆盖 84%;静态分析 S1/S2 问题 0 开放。TDD 收益实例:库存预扣的幂等语义,在写第一个红测试时暴露了接口设计缺陷(reserve(sku, qty)无法表达同一订单重复调用)→ 接口改为reserve(orderId, sku, qty)以 orderId 作幂等键。测试在编码前救了一个集成期缺陷。5. 集成与系统测试(迭代 5–8)集成:订单↔库存↔支付 契约测试(防接口漂移);自顶向下,外部依赖用 Stub/Mock;系统功能:核心 E2E(下单→支付→发货→完成,含 5 条异常路径)自动化;性能:JMeter 基准(10 万单/日模型),P95 240ms 达标;压测发现库存表行锁竞争→ 优化分桶;安全:渗透测试 1 次(发现 2 个越权,修复) 依赖扫描持续;回归:每日全量 每次合入增量;flaky 治理:3 个不稳定用例隔离修复,1 个删除。集成高频缺陷命中(6.4 清单):金额单位(元/分)1 起、错误码吞并 2 起、重试不幂等 1 起——全部被契约测试在合入阶段拦截,未进系统测试。缺陷统计:共 214 个,按阶段发现比例——需求 17、设计 9、单元 82、集成 45、系统 51、UAT 10。集成占比 21%(目标 25%,达成)。逃逸 3 个(全 S3)。6. 配置与发布(迭代 8 起)Trunk-Based 特性开关;主干保护 PR 评审 CI 门禁;构建不可变:同一 commit 必出同一镜像,制品进 Registry;发布:v1.0 用蓝绿(资源允许);v1.1 转金丝雀(5%→25%→100%);回滚预案:每版本明确触发信号 目标版本 数据兼容说明;实际:发布 6 次,金丝雀回滚 1 次(支付渠道配置错误,10 分钟内切回)。不可变构建审计(7.5):某次紧急修复有人提议在生产重新构建→ 被流程拦下:修复走正常 PR,新制品走金丝雀。事件本身成为团队培训案例。开关审计(7.4):月度执行,峰值期开关 9 个,6 个带退役日期;1 个无主开关 48 小时内被认领或下线。7. 质量管理(全程)DoD(每迭代):单测 ≥80%、无 S1/S2 开放、E2E 核心流通过、文档同步;度量看板:速度、逃逸率、变更失败率、MTTR;改进试点:发现支付联调缺陷集中 → 试点接口评审 契约测试前置 → 下季度集成缺陷占比 21% → 16%;审计:半年度内部过程审计,对照标准过程库,3 项差距整改。改进项目书(9.3 模板):基线 45%(项目初期)→ 试点(订单-支付接口,契约变更强制评审)→ 两季度后 21% → 推广 → 再两季度 16%。全程一个改进项、一个 Owner、有退出标准——一次 1–2 个纪律的完整兑现。缺陷-过程漏洞回溯(9.2):3 个逃逸 S3 缺陷回溯,2 个源于UAT 场景未覆盖退款部分退款,1 个源于压测模型未含批量查询→ 补 UAT 场景与压测模型,均关闭。8. DevOps 与运营(上线后)SLO:下单成功率 99.9%(30 天),错误预算月度回顾;可观测性:结构化日志 traceId 全链路 Prometheus 指标 Jaeger 追踪;告警基于症状:用户侧下单错误率 0.5% 才告警(避免 CPU 噪音);混沌工程:大促前演练支付网关超时 30s→ 验证熔断 补偿 人工核对队列;DORA(上线 6 个月):部署频率 3 次/周、前置时间 4h、变更失败率 4%、MTTR 35min。第一次 P1 事故(复盘素材):某发布后下单错误率升至 2.1%(18 分钟)。时间线: 10:02 金丝雀 5% 错误率越限告警 → 10:04 自动切回 10:06 全量恢复 → 10:40 定位(新索引导致慢查询)→ 11:10 修复版本走完整流程上线 复盘结论: 止血机制(金丝雀自动回滚)有效,MTTR 8 分钟; 根因(系统层): 预发数据量 1:10,索引问题在预发不可复现; 改进项: 预发数据扩至 1:3 慢查询压测进发布检查单(Owner: SRE, 2 周)体现 11.8 纪律:止血优先、根因到系统层、改进项 ≤5 且有 Owner。9. 维护与演进(上线 1 年后)维护构成(12 个月):完善 52% / 适应 24% / 纠错 16% / 预防 8%;技术债登记册:12 项,偿还 5 项(大促后窗口),利息最高的 2 项优先;退化信号:订单模块圈复杂度上升、文档滞后 → 安排预防性重构 1 个迭代;现代化:业务提出跨境订单独立合规需求 → 绞杀者模式启动:新微服务承接跨境子集,旧系统 6 个月后退役订单模块;知识管理:关键模块双人制,轮岗 2 轮,ADR 库 18 篇。技术债偿还实例(10.2 公式):TD-07 计价 if-else 链,利息 2 人天/次 × 促销季 4 次变更 × 资金风险 ×2 高优先级 → 大促后窗口 3 人天偿还(提取 PricingStrategy 族),偿还后当季促销需求工时 -30%。绞杀者执行(10.5):跨境订单切流,每次切流前过检查单(行为回放对比 双写对账差异0 回滚演练 72h SLI 观察);旧订单模块设退役倒计时(切流日即倒计时起点),6 个月后无功能留存,正式下线。10. 全生命周期工件地图(汇总)启动 : BR 列表、干系人矩阵、过程定义、估算、风险登记册 需求 : SRS(编号)、用例模型、状态机、追溯矩阵、CR 记录 设计 : 架构文档、ADR 库、类图/序列图、接口契约 编码 : 源代码、单元测试、BDD 场景、静态分析报告 测试 : 测试计划、用例集(分层)、缺陷库、性能/安全报告 配置 : 仓库、基线、制品、发布检查单、回滚预案 管理 : 迭代计划、燃尽图、风险月报、DORA 看板 质量 : DoD、度量看板、评审记录、审计报告、改进项目 运维 : SLO/错误预算、监控告警、混沌实验记录、事故复盘 维护 : 技术债登记册、影响分析、现代化路线(绞杀者)工件间的接力关系(读图方法):每条工件都是下一阶段的输入——SRS 的 NFR 喂给架构战术,状态机喂给测试生成,接口契约喂给契约测试,SLI 定义喂给告警与发布门禁。任何一环工件缺失,下游就是盲飞。11. 跨阶段失败模式速查阶段典型失败根因对策需求上线后这不是我想要的干系人缺失/验证不足干系人门禁 原型演示设计改一处崩三处高耦合、无架构决策记录内聚/解耦 ADR编码重构不敢动无测试安全网TDD 覆盖门禁集成接口在我这没问题无契约、无联合评审契约测试 接口评审测试flaky 测试狼来了隔离差、数据耦合治理:修或删,不挂起发布上了测不了的近似版本构建可变不可变制品 制品库上线故障 2 小时才定位无链路追踪可观测性三支柱维护越改越难改技术债复利登记册 偿还窗口使用方式:团队复盘时,先在本表定位我们是哪种失败,再回到对应章节找根因与对策——本表是索引,不是答案。OOS 全年失败事件统计(复盘输入)事件阶段归类(上表)改进落地财务需求测试期才提出需求干系人缺失干系人门禁库存竞态集成期暴露设计评审走过场发现率审计支付渠道配置回滚发布构建/配置配置即代码索引慢查询 P1上线环境差异预发数据扩容计价 if-else 改不动维护技术债复利偿还窗口12. 复盘:OOS 做对的三件事与做错的两件事做对的:风险前置:支付 spike 第 2 周做完(螺旋),把最大外部风险消灭在编码前;工件接力:状态机/契约/追溯矩阵成为三方法共享的单一事实来源,需求-设计-测试零口径打架;度量闭环:每个改进项有基线-目标-退出,一年 4 个改进项全部兑现并推广。做错的:第一次设计评审走过场:付出集成期修竞态 ×5 成本的学费,此后用发现率为零触发重审机制修复;预发数据 1:10 太久:环境差异导致 P1,教训固化进发布检查单(慢查询压测 数据 1:3)。这两条做错的价值大于三条做对:它们证明了体系的自我修复能力——失败被捕获、归因、转化为门禁。这是过程成熟度最真实的标志(第 9 章 CMMI 5 级特征)。13. 如何把本章用于你自己的项目抄工件地图(第 10 节):作为新项目启动 checklist,逐行裁剪做不做/谁负责;抄检查单类工件:发布检查单(7.7)、绞杀者切流单(10.5)、复盘模板(11.8)、改进项目书(9.3)——直接可用;替换 OOS 数值:用你项目的真实数据替换(单量、P95、缺陷数),案例才活;每季度对照失败速查表复盘一次:定位归类 → 回章节找对策 → 定改进项;带新人读本章:2 小时能建立全生命周期心智模型,比逐章快得多。14. 本章 FAQQ1:OOS 11 人团队,这些过程会不会太重?对照裁剪原则(第 2 章):OOS 保留了全部工件接力工件,但把过程动作压到最小(一页纸策略、半页周报、单 PR 评审)。“重的感觉通常来自执行痕迹缺失后的临时补课”,而非工件本身。Q2:双周迭代里怎么塞下这么多活动?活动是叠加在迭代内的,不是串行:需求分析在设计迭代、测试设计在编码迭代、度量在迭代回顾。Scrum 的事件(计划/站会/评审/回顾)只是骨架,第 3–11 章的活动填在事件之间。Q3:如果我的项目只有 3 个月,砍掉哪些?按风险砍:无外部集成 → 砍 spike 与契约测试(保留接口评审);无合规 → 砍正式 SRS(保留故事 NFR 表);无大促 → 砍冻结窗口管理。永远不砍:干系人分析、测试(至少黄金路径)、版本管理、变更记录、事故复盘。15. 小结软件过程是工件驱动的:每个阶段的产出是下一阶段的输入,追溯性贯穿始终;方法不是孤立工具,而是风险结构的映射:哪里风险高,那里过程重;度量(缺陷分布、DORA、维护构成)是过程的体检仪,趋势比单点重要;失败模式大多可预防,且预防成本远低于修复成本;OOS 案例证明:中等规模团队用敏捷外壳 工程纪律 闭环反馈可以兼顾速度与稳定;体系成熟度的标志不是从不失败,而是失败被捕获、归因、转化为门禁。思考题(综合)画出 OOS 从提交代码到用户看到新功能的完整链路,标注每一环的自动化与人工点。若 OOS 团队从 11 人扩到 33 人,第 2 章的过程选型应如何调整?康威定律起什么作用?用缺陷成本放大律复盘:OOS 中库存竞态若在设计评审被抓住 vs 集成测试才暴露,成本差多少?过程上如何避免?设计 OOS v2(微服务化)的绞杀者路线:切分边界、双写方案、一致性验证、退役判据。为你的项目画一张工件接力图:列出 5 个关键工件,标明各自的上游输入与下游消费者,指出你当前最薄弱的一环。对照第 11 节失败速查表,给你团队最近 6 个月的 3 个失败事件归类,并各写一条门禁化改进。OOS 的做错的两件事都转化成了门禁——你的组织最近一次失败,转化成了什么?如果没有,为什么?假设你是 OOS 第二年的新 PM,接手时 DORA 四项指标全面恶化,写出你的 30 天诊断计划(看哪些数据、查哪些环节、找谁)。