一、收集反馈与衡量重要的指标
DevOps 不只是工具——它是流动、反馈和持续改进。本单元聚焦「第二方式：反馈」：理解为什么缩短交付周期（lead time）是更快获得用户反馈的关键，掌握衡量流程是否真正改进的四大关键 DevOps 指标。
DevOps 四大关键指标
DevOps 三种方式：① 流动（Flow，创新从开发到用户）② 反馈（Feedback，检查变化是否有正确影响）③ 持续改进（Continuous Improvement，每天让流程更好）。
为什么交付周期重要：长交付周期 = 用户等数周反馈才被听取、开发者在项目间上下文切换、双方沮丧；短交付周期 = 小批量频繁发布、用户对真实软件给反馈、开发者保持心流。
四大关键指标：
- 部署频率——多久部署到生产一次？精英：每天多次；低：每月一次或更少。频繁的小部署比不频繁的大部署更安全。
- 变更交付周期——代码提交到生产运行多久？精英：不到一小时；低：数月。越短 = 越快反馈 = 越快学习。
- 平均恢复时间（MTTR）——生产故障恢复多久？精英：不到一小时；低：数天。故障总会发生，恢复速度才重要。
- 变更失败率——多大比例的部署导致生产故障？精英：0-15%；低：45%+。不是防止所有故障，而是让故障罕见且易恢复。
这四大指标告诉你 DevOps 实践是否真正有效——测量它们、跟踪它们、改进它们。
二、构建持续改进的文化
从指标转向心态。工具和流程只有在文化支持时才有用。对比固定型和成长型思维、引入科学思维作为改进引擎、学习 Improvement Kata——系统性、日常改进的四步模式。
成长型思维与改进 Kata
固定型 vs 成长型思维：固定型（「我不擅长这个」回避挑战、轻易放弃、视努力为无意义、忽视反馈、受他人成功威胁）；成长型（「我能学会」拥抱挑战、挫折中坚持、视努力为精通之路、从反馈学习、受他人成功启发）。DevOps 需要成长型思维——持续改进要求相信改进是可能的。
科学思维——改进的引擎：不猜、不假设、实验（形成假设 → 小规模测试 → 测量结果 → 从结果学习 → 形成新假设）。
Improvement Kata——每天实践的四步：① 理解方向（愿景：我们要去哪）② 把握当前状态（我们现在在哪）③ 确立下一个目标状态（下周想到哪）④ PDCA（计划-执行-检查-行动：下一个小的实验是什么）。这不是季度练习，而是日常实践——每天的小改进在数月数年内复利成转型。
三、韧性、包开发与测试
覆盖 DevOps 成熟的三大支柱：通过无指责的事后复盘和快速失败构建韧性、用解锁包迁移到模块化包开发模型、把全面测试构建进 CI/CD 流水线以在问题到达用户前捕获。
韧性、模块化架构与质量
无指责的事后复盘——从失败中学习而不指责：出错时问题不是「谁的错」，而是「我们系统中什么允许了它发生？如何防止再次发生？」聚焦流程改进而非个人惩罚；没有无指责文化，失败会被隐藏——它们会再次发生，只是没人知道。
模块化包架构：单体 org（元数据依赖的纠缠网，改一处无法预测什么会破）；解锁包（把元数据组织成独立模块，每包有清晰边界、显式依赖、独立版本、可单独部署）；康威定律（系统架构镜像团队沟通结构，把团队对齐到包）；从紧耦合 → 松耦合；好处：更快部署、独立测试、团队并行开发、更安全发布。
把测试构建进流水线：单元测试（测单个方法/类，快，每次提交跑）；集成测试（测组件协同，每次合并到主干跑）；UI 测试（端到端体验，生产部署前跑）；org 监控（捕获测试漏掉的问题）。把质量构建进来，而非事后测出来——开发后测试是找 bug，开发中测试是防 bug。
Scratch Org 上的持续集成：每次提交起一个全新 scratch org、部署全部元数据、跑全部测试、报告结果；测试失败则阻止部署；scratch org 是一次性的（创建、测试、销毁），无配置漂移、无「我机器上能跑」问题。
