3.1 系統提升的一般性方法和反饋環

IT運維管理暢銷書《鳳凰項目：一個IT運維的傳奇故事》的作者Gene Kim在調研了眾多高性能IT組織后，總結了支持DevOps運作的三個原理（The Three Ways: The Principles Underpinning DevOps），如圖3.1所示。

圖3.1

雖然這3個原理是針對DevOps提出的，但我認為它們也是系統提升的一般性原理，其核心是反饋環。

●原理一：系統思考（System Thinking）。對于開發驅動的組織，其主要責任不是制作軟件，而是持續地交付客戶價值。價值從業務需求開始，經過研發測試，到部署運維，依次流動，并最終以服務的形式交付到客戶手中。整個價值流速并不依賴單個部門（團隊或個人）的杰出工作，而是受整個價值鏈最薄弱環節的限制，所以局部優化通常是無效的，反而常常導致全局受損。

●原理二：強化反饋環（Amplify Feedback Loop）。過程改進常常通過加強和縮短反饋環來達成，該原理強調強化企業和客戶之間、企業組織團隊之間、流程上和系統內的反饋環。沒有測量就沒有提升，反饋要以測量和數據作為基礎，通過反饋數據來優化和改進系統。

●原理三：持續試驗和學習的文化（Culture of Continual Experimentation And Learning）。在企業文化層面強調勇于試錯和持續試驗的文化，讓企業內部自發涌現出更多創新和系統提升的反饋環。

簡而言之，技術研發型組織（尤其是領導層）要從全局視角審視整個IT價值流，改善瓶頸和短板，強化系統內外的反饋環，鼓勵試錯和試驗文化，讓價值在整個系統內更快、更好、更平滑地流動。

在構建閉環反饋進行系統提升方面，普遍存在如下兩個組織上的問題：

●反饋環不封閉。一個常見的例子是，因為沒有構建有效的數據收集、分析和監控體系，所以就沒有反饋數據，決策主要依靠猜測（“拍腦袋”）來做。另外，組織部門之間如果有嚴重的隔閡，缺乏信任和溝通，也容易造成反饋環不封閉。

●反饋比較慢，或者說遲反饋。設想，當踩下剎車之后，車過了10s才有反應，結果會怎樣？再比如，客戶報告了嚴重的Bug，但是系統從修復到再上線需要花費幾周甚至更長的時間，你覺得客戶會有耐心等嗎？遲反饋會讓客戶和股東蒙受損失，有時還是災難性的。圖3.2反映了缺陷在軟件生命周期中的修復成本，越靠近上游或者源頭捕獲并修復，成本越低，從上游到下游，成本呈指數級上升。本質上，缺陷反饋越遲，修復成本越高。

圖3.2