3.1 系统提升的一般性方法和反馈环

IT运维管理畅销书《凤凰项目：一个IT运维的传奇故事》的作者Gene Kim在调研了众多高性能IT组织后，总结了支持DevOps运作的三个原理（The Three Ways: The Principles Underpinning DevOps），如图3.1所示。

虽然这3个原理是针对DevOps提出的，但我认为它们也是系统提升的一般性原理，其核心是反馈环。

●原理一：系统思考（System Thinking）。对于开发驱动的组织，其主要责任不是制作软件，而是持续地交付客户价值。价值从业务需求开始，经过研发测试，到部署运维，依次流动，并最终以服务的形式交付到客户手中。整个价值流速并不依赖单个部门（团队或个人）的杰出工作，而是受整个价值链最薄弱环节的限制，所以局部优化通常是无效的，反而常常导致全局受损。

●原理二：强化反馈环（Amplify Feedback Loop）。过程改进常常通过加强和缩短反馈环来达成，该原理强调强化企业和客户之间、企业组织团队之间、流程上和系统内的反馈环。没有测量就没有提升，反馈要以测量和数据作为基础，通过反馈数据来优化和改进系统。

●原理三：持续试验和学习的文化（Culture of Continual Experimentation And Learning）。在企业文化层面强调勇于试错和持续试验的文化，让企业内部自发涌现出更多创新和系统提升的反馈环。

简而言之，技术研发型组织（尤其是领导层）要从全局视角审视整个IT价值流，改善瓶颈和短板，强化系统内外的反馈环，鼓励试错和试验文化，让价值在整个系统内更快、更好、更平滑地流动。

在构建闭环反馈进行系统提升方面，普遍存在如下两个组织上的问题：

●反馈环不封闭。一个常见的例子是，因为没有构建有效的数据收集、分析和监控体系，所以就没有反馈数据，决策主要依靠猜测（“拍脑袋”）来做。另外，组织部门之间如果有严重的隔阂，缺乏信任和沟通，也容易造成反馈环不封闭。

●反馈比较慢，或者说迟反馈。设想，当踩下刹车之后，车过了10s才有反应，结果会怎样？再比如，客户报告了严重的Bug，但是系统从修复到再上线需要花费几周甚至更长的时间，你觉得客户会有耐心等吗？迟反馈会让客户和股东蒙受损失，有时还是灾难性的。图3.2反映了缺陷在软件生命周期中的修复成本，越靠近上游或者源头捕获并修复，成本越低，从上游到下游，成本呈指数级上升。本质上，缺陷反馈越迟，修复成本越高。