首先申明下，今天的主題雖然叫“建構閉環回報架構”，但主要是面向技術管理的主題，可能會讓一些技術和業務視角的同學有一點點失望。
本分享總結軟體研發型組織在産品、組織、流程和架構方面經常需要關注的一些回報環(feedback loop)，以及強化這些回報環需要哪些支撐性的技術和架構手段，希望對組織在這些方面改進提升有一定的指導價值。另外，本分享希望對研發工程師和架構師建立閉環回報和devops意識有一定的指導意義。
本分享主要基于之前工作總結和近期的學習思考，分享目的一方面是梳理自己思路并做些沉澱；另一方面是抛磚引玉，激發大家的進一步思考，如有了解不當偏頗之處，還請各位不吝指教。本分享假設針對提供saas服務的軟體研發型組織，其它類型涉及it系統的組織也可從中獲得借鑒。
it運維管理暢銷書<b>《鳳凰項目》</b>的作者<b>gene kim</b>在調研了衆多高性能it組織後總結了支援devops運作的三個原理(the three ways: the principles underpinning devops)，見下圖
雖然這三個原理是針對devops提出的，但我認為它們也是系統提升的一般性原理，其核心是回報環：
<b>原理一</b>：系統思考(systems thinking)，開發驅動的組織，其能力不是制作軟體，而是持續的傳遞客戶價值。價值從業務需求開始，經過研發測試，到部署運維，依次流動，并最終以服務形式傳遞到客戶手中。整個價值流速并不依賴單個部門（團隊或個人）的傑出工作，而是受整個價值鍊最薄弱環節的限制，是以局部優化通常是無效的，反而常常導緻全局受損。
<b>原理二</b>：強化回報環(amplify feedback loops)，過程改進常常通過加強和縮短回報環來達成，原理二強調強化企業和客戶之間，企業組織團隊間，流程上和系統内的回報環。沒有測量就沒有提升，回報要以測量和資料作為基礎，通過回報資料來優化和改進系統。
<b>原理三</b>：持續試驗和學習的文化(culture of continual experimentation and learning)，在企業文化層面強調勇于試錯和持續試驗的文化，讓企業内部自發湧現更多創新和系統提升的回報環。
簡言之，技術研發型組織（尤其是上司層）要從全局視角審視整個it價值流，改善瓶頸和短闆，強化系統内外的回報環，鼓勵試錯試驗文化，讓價值在整個系統内更快、更好和更平滑的流動。
在建構閉環回報進行系統提升方面，組織普遍存在的兩個問題是：
<b>1．回報環不封閉。</b>一個常見的例子是，因為沒有建構有效的資料收集、分析和監控體系，也就沒有回報資料，決策主要依靠猜測（拍腦袋）。另外，組織部門之間如果隔閡嚴重，缺乏信任和溝通，也容易造成回報環不封閉；
<b>2. 回報比較慢，或者說遲回報。</b>設想一個場景，你踩下刹車之後，你的車要過10秒後才有反應，結果會怎樣？再如你的客戶報告了嚴重的bug，但是你的系統修複再上線需要花上幾周甚至更長的時間，你覺得客戶會有耐心等嗎？遲回報會讓客戶和股東蒙受損失，有時還是災難性的。
上圖反映缺陷在軟體生命周期過程中的修複成本，越靠近上遊或者源頭捕獲并修複，成本越低，越到下遊，成本呈指數級上升。本質上是說，缺陷回報越遲，修複成本越高。
netflix雲架構師adrian cockcroft在2014年的一次演講中分享了netflix持續規模化産品創新的概念模型—基于ooda環的持續傳遞，如下圖所示，
<b>1. 觀察（observe）</b>：表示觀察現狀以發現潛在的創新點。netflix鼓勵員工勇于創新，任何人發現機會都可發起項目進行創新。比如，上圖提到“客戶痛點”，如果員工發現很多客戶在網站上操作到某一步的時候都放棄了注冊流程，那麼他/她就可以調查其中原因，主動發起項目修複這個問題。
<b>2. 判斷（orient）</b>: 表示通過分析測量資料，來了解之前觀察到的現象的背後原因。通常這涉及分析大量的資料（例如日志檔案分析），通常也稱為大資料分析。
<b>3. 決策（decide）</b>: 指的是開發和執行一個項目計劃。公司文化在決策一塊是很重要的因素，在netflix，公司鼓勵自由和責任文化，員工将計劃公開分享(share plans)，不需要層層管理審批，就能主動發起變更項目。上圖的jfdi表示just f*cking do it[偷笑]，強調推進力和執行力。
<b>4. 行動（act）</b>: 指的是測試解決方案并将其部署到生産環境。netflix采用基于雲的微服務架構(microservices architecture)，員工将包含增量功能的微服務釋出到雲環境，并開啟a/b測試和之前版本做比對，基于資料判斷新版本是否解決老版本的問題。
netflix采用微服務架構體系，團隊獨立開發和維護各自負責的微服務，互相不幹擾，一個微服務團隊用1~2周的時間就可以完成一次ooda循環，可以說在業界是非常高的水準。
基于資料的閉環回報是ooda環的核心，cockcroft是這樣說的：如果你的每一步都是基于充分的測量資料做出的行動，而你的競争對手主要靠需要好幾個月才能驗證的猜測，那麼你想不赢都難("it's hard not to win")。
在技術層面，netflix通過大資料、微服務、雲計算、自動化部署和a/b測試等手段，支援快速的創新和閉環回報。
大部分的研發型組織，主要基于專業分工和成本使用率考量，會采用如下圖所示的嚴格職能型組織架構。
一個标準的軟體研發流程，從産品經理先和使用者體驗/開發團隊讨論新功能想法開始。開發團隊再将想法實作為代碼，之後代碼被移交給測試團隊和資料庫管理團隊，這中間涉及溝通和協調。最後産品上線又涉及和運維團隊(系統、網絡和存儲等)的溝通和協調。
嚴格職能型組織很容易産生孤島(silo)效應，或者說豎井效應，每個職能團隊都想成為舞台中央的明星團隊，各團隊易各自為政和局部優化，是以嚴格職能組織有溝通開銷大、研發流程緩慢和回報效率低下問題。
有一些公司會更進一步，組建所謂基于産品線的跨職能團隊負責整個端到端的研發活動，見下圖：
跨職能團隊有助于提升效率和強化回報環，這個也是目前國内外主流網際網路公司采用的組織模型。但隻要團隊基于單塊(monolithic)應用的開發和傳遞模式，就難免産生跨團隊間的移交、溝通和協調活動，整體效率仍然受限。
下面是netflix所采用的基于微服務和paas平台的devops組織模型：
跨職能的産品團隊基于可獨立開發、測試和部署的微服務而組建，支援端到端的研發活動；平台團隊則在aws雲的基礎上提供paas基礎服務平台，将微服務基礎設施，釋出和監控等基礎能力封裝在平台内，支援開發團隊進行微服務的自助式(self-service)部署。
這個組織模型減少了組織間的孤島，強化了團隊内的回報閉環，最大化了研發和傳遞的效率。當然，這個組織模型對技術能力和基礎設施的要求更高，需要微服務架構體系、自動化部署和paas平台等技術手段的支撐。
上十年，靈活(agile)研發方法學得到長足進步和大範圍推廣，幾乎每家技術型組織都在講靈活。
考慮到大部分同學已經對靈活方法學耳熟能詳，是以我這裡不打算再多費口舌，隻想強調一點：靈活，不管是項目管理方面流行的scrum方法學，還是編碼和品質方面的單元測試、持續內建等最佳實踐，本質上是關于回報的，不管采用哪種方法和實踐，其核心是強化回報閉環。
下圖反映不同靈活實踐的回報周期。
近期，随着溝通協作工具的興起，比如知名的slack，出現了所謂chatops等新的devops實踐，其核心是建構dev和ops之間的溝通回報閉環，如下圖所示：
上圖中，整個軟體傳遞生命周期過程中的重要事件，如代碼送出，建構的成功和失敗，建構包的上傳/部署，生産系統的告警等，都被push到slack工具的不同管道(channel)中，不同職責的devops成員通過關注不同的管道來實時掌握和溝通研發程序和生産系統的健康狀況。
該實踐通過事件可視化和溝通回報閉環讓dev和ops更密切地協作，進一步提升研發效率。
系統架構層面的閉環主要展現在系統監控方面，系統監控主要分為三個層次：
1. 系統層監控，監控底層硬體如cpu、網絡和存儲等的性能狀況；
2. 應用層監控，監控應用性能如頁面/服務調用計數，調用延遲，錯誤計數等；
3. 業務層監控，監控重要的業務名額如pv/uv，使用者登入數和訂單量等。
上圖是一個假想的電商網站的分層架構圖，
1. 底層第0層是運維基礎設施層，可以基于私有雲或者公有雲，右邊對應系統層次的監控回報閉環；
2. 第1層是技術基礎平台（中間件+架構）層，通常稱為技術paas(platform as a service)；
3. 第2層是應用服務平台(soa)層，通常也稱為業務paas，第1和2層右邊對應業務/應用/服務監控和大資料分析閉環回報。
4. 第3層是使用者體驗和管道，右邊對應端使用者體驗監控和網站分析閉環回報。
通過在每一層次建構監控和大資料分析等閉環回報機制，整個系統可以在回報資料的基礎上不斷地優化和改進。
網際網路時代，企業在瞬息萬變的市場赢得和保持競争優勢的核心在于持續創新。netflix的成功實踐告訴我們，一方面企業戰略，文化，組織/團隊，流程，架構對持續創新至關重要；另一方面像微服務，雲計算和paas等技術手段，對持續創新和快速閉環起到基礎性的支撐作用。
上圖是典型的傳統開發模式，其中硬體資源的審批、采購和安裝配置，花上幾周甚至幾個月都是非常普遍的，造成研發效率低下，回報速度緩慢。
上面兩個圖分别是基于iaas的開發模式，和在iaas開發模式下的團隊協作模式，iaas雲支援硬體資源的快速自助式提供，可以将研發和回報效率提升一個量級。但是，在中間件的安裝配置、測試、釋出和監控運維等環節仍然需要很多協調、移交和手工的重複性工作，研發和回報的效率仍然受限。
上面兩個圖分别是基于paas的開發模式，和對應的團隊協作模式，該模式将中間件、持續內建、釋出和監控運維等基礎能力自動化并封裝在paas雲平台中，可以支援研發人員的快速自助式部署，理想情況下研發人員可以做到想發就發，即達成快速的産品創新閉環。
在netflix的微服務架構模式下，微服務是一個獨立的開發，測試，釋出和擴容機關，不同的團隊可以互不幹擾，獨立的演化各自的微服務，這是一種自适應的和支援持續業務創新的架構風格。
微服務架構需要基礎paas平台的支撐：将微服務管理(服務發現，配置，路由，容錯和負載均衡)，持續內建和釋出，監控和自動化運維等基礎核心能力抽象、下沉并封裝在平台内，讓研發人員可以專注于微服務業務邏輯的實作，支援微服務的獨立自助式部署，達成快速疊代和閉環回報。
上圖中，gartner把這個基礎平台稱為<b>外架構(outer architecture)</b>，把居住在這個平台内的微服務架構稱為<b>内架構(inner architecture)</b>。
1. 網際網路以快制勝(speed wins in the marketplace)，企業的成功很大程度上取決于企業對客戶需求的快速響應，換句話說，就是企業和客戶之間能否形成良性正向和快速的閉環回報，這個最大的回報環又由衆多子回報環組成，包括産品創新、組織、流程和架構等各個環節，每一個子回報環最終會直接或者間接的影響到企業和客戶之間的閉環回報。
2. 對閉環回報的關注和投入，可以作為衡量一個優秀軟體研發型公司的重要名額。同樣，是否具備充分的閉環回報意識，也是衡量一個優秀架構師的重要名額。
3. lord kelvin曾指出：如果你無法度量，你就無法提升，見下圖：
在《架構即未來》一書中，作者馬丁l.羅伯特也強調：管理意味着度量，失敗的度量意味着失敗的管理。同樣，回報必須基于測量資料，有回報資料才能學習，有學習才能有提升。
4. 微服務，雲計算和paas是支援持續業務創新和快速閉環回報的支撐性技術架構手段。devops和持續傳遞是提升企業内外回報機制的最佳實踐，我常用下圖來展示devops：
最後，所有的模型都是錯誤的，但是有一些是有用的。閉環回報模型和意識非常重要和強大，但是在實踐過程中要根據企業實際上下文(業務模式，規模，發展階段，人才密度等等)靈活應用。
下面是本次分享引用的一些參考資料：
1. 鳳凰項目：一個it運維的傳奇故事
2. the three ways: the principles underpinning devops
<a target="_blank" href="http://itrevolution.com/the-three-ways-principles-underpinning-devops/">http://itrevolution.com/the-three-ways-principles-underpinning-devops/</a>
3. 精益企業：高效能組織如何規模化創新
4. adopting microservices at netflix: lessons for team and process design
<a target="_blank" href="https://www.nginx.com/blog/adopting-microservices-at-netflix-lessons-for-team-and-process-design/">https://www.nginx.com/blog/adopting-microservices-at-netflix-lessons-for-team-and-process-design/</a>
5，adopting microservices at netflix: lessons for team and process design
6，microservices: building services with guts on the outside
<a target="_blank" href="http://blogs.gartner.com/gary-olliffe/2015/01/30/microservices-guts-on-the-outside/">http://blogs.gartner.com/gary-olliffe/2015/01/30/microservices-guts-on-the-outside/</a>
7，agile metrics in action: measuring and enhancing the performance of agile teams
<a target="_blank" href="https://www.amazon.com/agile-metrics-action-measuring-performance/dp/1617292486/ref=pd_bxgy_14_img_2?ie=utf8&psc=1&amp;refrid=zsed7d48j9jz2wpscc4b">https://www.amazon.com/agile-metrics-action-measuring-performance/dp/1617292486/ref=pd_bxgy_14_img_2?ie=utf8&psc=1&amp;refrid=zsed7d48j9jz2wpscc4b</a>
8，架構即未來：現代企業可擴充的web架構、流程群組織（原書第2版）
<a target="_blank" href="https://www.amazon.cn/%e6%9e%b6%e6%9e%84%e5%8d%b3%e6%9c%aa%e6%9d%a5-%e7%8e%b0%e4%bb%a3%e4%bc%81%e4%b8%9a%e5%8f%af%e6%89%a9%e5%b1%95%e7%9a%84web%e6%9e%b6%e6%9e%84-%e6%b5%81%e7%a8%8b%e5%92%8c%e7%bb%84%e7%bb%87-%e9%a9%ac%e4%b8%81l-%e9%98%bf%e4%bc%af%e7%89%b9/dp/b01dxw29im">https://www.amazon.cn/%e6%9e%b6%e6%9e%84%e5%8d%b3%e6%9c%aa%e6%9d%a5-%e7%8e%b0%e4%bb%a3%e4%bc%81%e4%b8%9a%e5%8f%af%e6%89%a9%e5%b1%95%e7%9a%84web%e6%9e%b6%e6%9e%84-%e6%b5%81%e7%a8%8b%e5%92%8c%e7%bb%84%e7%bb%87-%e9%a9%ac%e4%b8%81l-%e9%98%bf%e4%bc%af%e7%89%b9/dp/b01dxw29im</a>
q1：如何衡量平台能力好不好？
a1：這個問題很大啊，涉及方面太多了，簡單講衡量方式就是業務創新或者說疊代的速度，規模化創新的能力，這些都需要強力平台+人才密度的支撐。阿裡的平台，支撐淘寶，天貓，阿裡雲，螞蟻金服這麼大體量的業務領域，這個平台非常強大，一般公司的平台能力是支撐不了的，這個是它的核心競争力。
q2：有一些架構圖很漂亮，一回到應付新業務的接入能力就歇菜，楊老師有沒有這方面的資料？
a2：你這個問題應該是平台建設和業務發展平衡的問題吧，這個問題也很大不好回答，涉及方面太多，沒有線性答案的，我簡單說是要技術上司層的眼光、戰略和平衡能力。
q3：靈活強調不要提前做big design，甚至有咨詢師把架構動作等同于某個使用者故事，楊老師咋看？
a3：it depends，還是要看上下文，我個人主張靈活，盡快involve客戶回報，疊代演化産品，但是，平台和技術體系的建設還是需要高屋建瓴的長期規劃的，大處着眼，小處着手，疊代演化是我的架構和設計原則。
<b>分享者簡介</b>
<b>楊波</b>，前ebay中國研發中心自身研發工程師,攜程架構研發總監，有超過十年的網際網路分布式系統架構設計經驗，曾是ebay soa和開放平台的核心開發者，攜程微服務架構體系核心架構師，開源愛好者，目前是拍拍貸基礎架構研發總監，專注于微服務架構體系，雲計算paas，ci/cd/devops實踐等技術領域。
本文來自中生代技術群的分享
<b>微信公衆号 freshmantechnology</b>