本文授權轉載自公眾號 AgileRunner，作者姚冬，樂於分享讀書，跑步，生活，敏捷，精益，DevOps，產品研發的點滴思考。
源於一月份讀了《鳳凰項目:一個IT運維的傳奇故事》一書（感謝徐磊同學的推薦），這本小說體一氣呵成的書，閱讀感受非常好，提筆想做讀書筆記卻有些犯難，小說貌似只有寫讀後感的；恰好隨後給同事做過兩次DevOps的介紹，乘機整理了一下思路，將自己對DevOps方方面面的理解，最終呈現為這篇文檔，作為階段性的總結。
什麼是DevOps？
DevOps不只是開發與運維的問題
從大處著眼
從小處下手
通過加大部署/發佈頻度來撬動整個交付過程
自動化、標準化、配置化
DevOps實踐
DevOps與雲
DevOps與精益、敏捷
三步工作法
1. 以下問題有沒有解？
“快速將產品推向市場” 與 “提供穩定、安全並可靠的IT服務” 是否可以兼得？
用更少的資源完成更多的業績，既要保持競爭力，又要削減成本？
如何解決任務交接出現的問題，例如業務與開發，開發與運維之間？
運維人員能否和其他人一樣，正常上下班，而不用在夜裡或者週末加班？
2. 什麼是DevOps？眾說紛紜
Wikipedia上說："DevOps是軟件開發、運維和質量保證三個部門之間的溝通、協作和集成所採用的流程、方法和體系的一個集合。它是人們為了及時生產軟件產品或服務，以滿足某個業務目標，對開發與運維之間相互依存關係的一種新的理解。“
百度百科說：“DevOps（英文Development和Operations的組合）是一組過程、方法與系統的統稱，用於促進開發（應用程序/軟件工程）、技術運營 和質量保障（QA）部門之間的溝通、協作與整合。它的出現是由於軟件行業日益清晰地認識到：為了按時交付軟件產品和服務，開發和運營工作必須緊密合作。”
IBM這樣說：“DevOps是企業必備的持續交付能力，通過軟件驅動的創新，保證組織抓住市場機會，同時減少反饋到客戶的時間。”
3. DevOps不只是開發與運維的問題
一般而言，開發與運維有著不同的文化；開發部門的驅動力通常是“頻繁交付新特性”，而運維部門則更關注IT服務的可靠性和IT成本投入的效率，降低風險。兩者目標的不匹配，在開發與運維部門之間造成了鴻溝，從而減慢了IT交付業務價值的速度。運維從維穩出發，自然希望生產系統部署上線次數越少越好，而上線頻度降低，對開發人員是一個負激勵：反正我發佈的版本也不會上線，反正我再積極也不能實時地體現出來，團隊積極性和人員士氣都會受到打擊。
與此同時，業務部門則希望業務需求儘快地推向市場，而維穩的要求導致價值交付用戶的速度被延緩，價值無法迅速得到反饋驗證。
當發佈列車變成3個月一趟車次時，業務人員習慣於自己的需求無法快速得到滿足，能想出的方法就是把所有的業務需求都設置成最高優先級，去搶佔發佈窗口。所有人都這樣想這樣做，擁堵就此產生，真正高價值的需求無法得到快速交付。（試想，如果每天有十次發佈，大家還會拼得頭破血流去搶一個發佈窗口麼？）
上線頻度低的另一個副作用是，單次上線中包含的變更規模變大，風險也隨之增加。事實上，減少上線次數不僅不會降低風險，反而讓每一次上線都變得像一個火藥桶，危機四伏。
4. 從大處著眼
究其根本，DevOps目的是提升業務交付能力：如何快速地交付想法；如何讓客戶進行嘗試（從而獲取反饋）；如何快速響應客戶反饋；
DevOps不應該只是IT內部的幾個部門玩的遊戲。必須跳出IT的角度，端到端（業務端到客戶端）分析，才能弄清公司需要依靠IT的哪些工作來支撐業務目標，支撐企業戰略 ，從而實現更完整、真正的DevOps。
需要將IT變成一種能力，融入公司的日常運作中，融入業務活動中。在快魚吃慢魚的時代，需要快速試錯，不斷整合來自市場的反饋。
所以最終，DevOps是一個端到端的問題，是產品管理部、開發部、測試部、IT運維部、信息安全部協同工作，共同支持。
DevOps嘗試建立一個業務價值交付管道，業務規劃、需求梳理、計劃、開發、構建、測試、部署、運維、監控 ，在此交付過程中涉及到的部門/團隊、過程、系統、方法都歸屬於DevOps關心的內容。
5. 從小處下手
理解了DevOps是一個端到端的過程，整個交付鏈條涉及太多的領域，問題也層出不窮，無從下嘴。實際操作中，需要有一個切入點。
DevOps的思想以精益與敏捷為核心，通過暴露問題，解決問題，從而實現持續改進。從精益的角度看，在代碼投產之前，實際上未產生任何價值，都只是半成品。要限制半成品，即在製品（WIP）數量，讓其儘快流過生產線，讓投入產生交付價值。
DevOps是一個複雜問題，我們卻希望可以把一個複雜的問題簡單化：正如裝修時通過加壓檢查管道是否洩露，是否有阻塞，我們也通過加壓的方式來暴露軟件交付管道的問題。
如何加壓？以終為始，我們選擇業務價值交付的那個點，也就是部署與發佈來對整個交付管道進行加壓。
可以簡單地問自己一個問題：“能不能一天部署10次？”如果沒有辦法？那麼原因何在？流程不規範？自動化不夠？溝通導致效率低下？過程無法複用？環境差異導致迴歸出錯？逐一的暴露問題，解決問題，交付能力自然提升。
需要注意的是，根據《鳳凰項目》中提到的TOC約束理論（Theory of Constraints），在瓶頸之外的任何地方做出的改進都是假象，在瓶頸之後做的任何改進都是徒勞的，因為只能乾等著瓶頸把工作傳送過來，而在瓶頸之前做的任何改進則只會導致瓶頸處堆積更多的庫存。所以如何識別真正的瓶頸變得尤為重要，在發現問題之後多問幾個為什麼，力求找到根源原因。
DevOps的由來
Flickr公司的約翰·阿爾斯帕瓦和保羅·哈蒙德在2009年Velocity技術大會關於開發速率的一場演講，“一天十次部署”，是2009年前後興起的DevOps運動的一部分，提倡開發和IT運維通力協作，在完成高頻率部署的同時，提高生產環境的可靠性、穩定性、靈敏性和安全性。2009年一天十次部署就算很快了，但現在只能算平均水平，2012年亞馬遜公司宣佈，他們平均每天能開展23000個部署。
Wikipedia上說，有以下幾方面因素可能促使一個組織引入DevOps：
-使用敏捷或其他軟件開發過程與方法
-業務負責人要求加快產品交付的速率 （新興技術趨勢，例如雲計算、移動應用、大數據和社交媒體）
-虛擬化和雲計算基礎設施（可能來自內部或外部供應商）日益普遍
-數據中心自動化技術和配置管理工具的普及
-傳統的管理方式導致“煙囪式自動化”，從而造成開發與運維之間的鴻溝
6. 通過加大部署發佈頻率來撬動整個交付過程
以應用部署自動化作為切入點，由部署自動化，往前倒逼測試自動化、構建自動化。進一步往前，配置管理、變更管理是基礎要求。再往前，業務需求與敏捷計劃同步關聯，通過短週期迭代交付與反饋，加強業務與開發的協作溝通。
同樣地，往後端與運維銜接，更小、更頻繁的變更，需要讓開發人員更多地控制生產環境，更多地以應用程序為中心來理解基礎設施。需要定義簡潔明瞭的流程，儘可能地自動化，從而在完成高頻率部署的同時，提高生產環境的可適應性，與此同時，可靠性、穩定性、彈性和安全性也同時提升。
由此也促成了開發與運維的協作，通過不斷縮減批量規模，實現快速工作流，確保了部署環境時刻準備就緒，按需投產。頻繁的發佈、意味著每次發佈包含的變化更少，每次部署不會對生產系統造成巨大影響，應用程序會以平滑的速率逐漸生長。逐步協調和彌合開發與運維之間的技能鴻溝和溝通鴻溝。
7. DevOps要實現自動化、標準化、配置化
自動化：全面自動化，構建、部署、測試、升級、擴展、維護、數據衛生、監測、安全和策略管理。通過自動化，倒逼團隊高效溝通，倒逼流程規範；自動化手段確保部署任務的可重複性、減少部署出錯的可能性。
標準化：（流程，環境，配置） 基礎環境標準化，運行環境標準化，應用環境標準化/多樣化。
配置化：通過配置，儘量避免代碼，通過功能開關或者參數設置，來支持A/B testing、灰度發佈。
8. DevOps實踐
不做什麼比做什麼更重要：相比起向系統中投入更多的工作，將無用的工作剔出系統更為重要；無用的工作，無用的項目，無用的產品；排優先級，哪些是重要的工作。
運維參與研發評審：常見的現象是，運維人員很少被邀請參與架構決策或代碼評審，開發代碼是否會影響運維環境前期無人知曉，需要讓運維人員參與架構評審，從運維角度提出對系統的要求。
非功能性需求同樣重要：償還技術上的債務。每個人都像重視功能性要求一樣重視非功能性要求QoS（質量，穩定性，可維護性，持續性，可擴展性，可管理性，安全性，可操作性），非功能性需求對於實現業務目標同等重要。要把非功能性需求設計到產品當中。
整體協作：產品所有者，開發部，QA，IT運維部以及信息安全部通力協作，幫助彼此乃至整個企業取得勝利。
質量為先：上游團隊不再給下游團隊造成麻煩，開發部將20%的時間用於幫助確保工作順利地通過整個價值流，加快自動化測試，改進部署基礎架構，並確保所有應用程序建立有用的產品遙測。
基礎架構即代碼（Infrastructure as a Code）：把創建和部署流程自動化，把基礎架構當成代碼一樣對待；各套環境之間，代碼版本、運行時、環境配置需要匹配；需要將基礎環境配置化、版本化管理。
運維服務化：DevOps會讓開發部門承擔更多的代碼部署和維持服務水平的責任。要求把許多IT運維任務轉變為自助服務。
版本化一切（Versionlize Everything）：應該把所有東西都進行版本控制，不只是代碼，而是創建環境所需的每一樣東西。
ITIL：為了適應DevOps更短的交付週期和更高的部署頻率，ITIL流程的很多方面都需要自動化，特別是變更、配置和發佈流程等。
雲計算：有效地利用雲技術，可以為開發和測試人員動態設置基礎架構資源，快速獲得測試環境。
針對類生產系統進行開發和測試 （環境的標準化），利用可重複的可靠流程進行部署，監控並驗證運維質量。
放大反饋迴路：快速反饋迴路，防止問題代碼進入生產環節，並且讓代碼能夠迅速部署投產，從而迅速發現並修復任何產品問題。（編寫代碼時，單元測試、集成測試、驗收測試一直在類生產環境運行，不斷確認，代碼和環境獎會按照預先設定的運行，並且總是處於可部署狀態）
9. DevOps與雲
DevOps要支持雲，虛擬化與雲技術可以帶來DevOps要求的標準化以及自動化。
環境標準化，無論是基礎設施還是運行時環境，並把這些環境投入開發、QA和IT運維的日常使用，就能消除大部分在部署流程中因為差異而導致的問題。不僅應該拿出可部署的代碼，還應該擁有部署這些代碼的確切環境，並在版本控制中一併控制與檢查。
混合雲下的DevOps訴求：在雲的場景下，如何利用虛擬化、容器等加速環境的創建以及標準化，如何通過自動化的方式加快環境搭建；如何在On-Prem、私有云、公有云，不同廠商不同類型的雲的混合模式下，統一流程，統一DevOps的用戶感受。
同時，由應用層的自動化部署，同樣可以發現Infrastructure層, Runtime層的問題，虛擬化與雲的技術也與DevOps相輔相成，相得益彰。
10. DevOps與精髓、敏捷
DevOps是基於敏捷與精益原則的方法。DevOps是軟件開發生命週期（SDLC）從瀑布式到敏捷再到精益的發展。
DevOps超越了敏捷，它的關注點是從SDLC中移除浪費。通常情況下，發現浪費或者瓶頸的形式包括：不一致的環境，人工的構建和部署流程，差的質量，IT部門之間缺少溝通和理解，頻繁的中斷和等待，部分完成的工作，額外的功能，任務切換等。
DevOps強調流水線，交付管道，與傳統生產與製造業有著千絲萬縷的聯繫；而《鳳凰項目》一書中直接用生產工廠來點化故事的主人公，與IT開發運維直接類比。
DevOps實施中，可以借鑑精益理論中的很多思想，例如：降低批量規模、減少半成品、縮短並增強反饋迴路、價值流圖分析、時間線分析、消除浪費，以及敏捷中持續集成、持續測試、持續交付、持續監控、A/B測試、灰度發佈、滾動更新等。
11. 三步工作法
《鳳凰項目:一個IT運維的傳奇故事》中建議的三步工作法以實現DevOps：
第一工作法：（幫助理解在工作從開發移向IT運維時該如何建立快速工作流）從開發到IT運維再到客戶的整個自左向右的工作流。為了使流量最大化，需要小的批量規模和工作間隔，絕不讓缺陷流向下游工作重心，並且不斷為了整體目標（相對於開發功能完成度、測試發現/修復比率或運維有效性等局部目標）進行優化。必要的做法：看板、持續構建、集成以及部署，按需創建環境，嚴控半成品，以及構建起能夠順利變更的安全系統和組織。
第二工作法：（如何縮短以及放大反饋環路，從而在源頭解決質量問題）價值流各階段自右向左的快速持續反饋流，放大其效益以確保防治問題再次發生，或者更快地發現和修復問題。這樣我們就能在所需支出獲取或潛入知識，從源頭上保證質量。必要的做法：在部署管道中的構建和測試失敗時“停止生產線”；日復一日地持續改進日常工作；創建快速的自動化測試套裝軟件，以確保代碼總是處於可部署的狀態；在開發和IT運維之間建立共同的目標和共同解決問題的機制；建立普遍的產品遙測技術，讓每個人都知道，代碼和環境是否在按照設定運行，以及是否達到了客戶的目標。
第三工作法：（如何建立文化，既能鼓勵探索，從失敗中吸取教訓，又能理解反覆的時間是精通工作的先決條件）創造公司文化，帶動兩種風氣的形成：不斷創世，這需要承擔風險並從成功和失敗中吸取經驗教訓；理解重複和練習是熟練掌握的前提。不斷加壓，從而強化習慣並加以改進。（系統裡要經常出些故障，長此以往，再遇到困難就沒原來那麼痛苦了）必要的做法：營造一種勇於創新、敢於保險以及高信任度的文化，把至少20%的開發和IT運維週期規劃給非功能性需求，並不斷鼓勵進行改進。
12. KPI與度量
為了促進DevOps戰略，調整績效考核和激勵機制是必要的，原本按各自為政的KPI考核只會造成部門之間的隔閡，依然只根據敲出代碼的生產力來獎勵開發人員，或者根據基礎設施的可靠性來獎勵運維人員，什麼都無法改變；圍繞業務系統而不是職責來組織工作，這就是DevOps打破IT分組壁壘的寓意。團隊一起協作，共同為他們的應用和系統負責。
部分度量參考：
-開發應用所花費的最高時間（開發速率）
-失敗部署的百分比（部署成功率）
-客戶產生了多少問題（客戶接受度）
-故障恢復的平均時間（團隊解決故障的能力）
-用戶數（用戶歡迎度）
1.《鳳凰項目》
DevOps圖書推薦：
豆瓣評分9.0分
引發全球IT從業者強烈共鳴的小說
《鳳凰項目（修訂版）》
Gene Kim，Kevin Behr等 著
成小留 譯
三位DevOps專家用節奏明快、生動有趣的風格撰寫了一個所有IT從業人員都會產生共鳴的故事。讀者可以從中學會如何對自己的IT組織進行優化，而且會用一種全新的視角來看待IT工作。全書講述了一名IT經理Bill臨危受命，在未來董事的幫助和自己The Three Ways理念的支撐下，挽救工期和預算都大大超期的鳳凰項目，最終挽救一傢俱有悠久歷史的汽車配件製造商的故事。
IT運維名著《鳳凰項目》姊妹篇
助力現代企業數字化轉型
《DevOps實踐指南》
Gene Kim 等 著
劉徵 , 王磊等 譯
IT組織效能專家Gene Kim，持續交付先鋒Jez Humble，DevOps之父Patrick Debios，DevOps佈道師John Willis聯合執筆。全書涵蓋40餘個DevOps案例，以谷歌、亞馬遜、Facebook等全球知名企業和組織的實際調查結果為依據，展示如何通過現代化的運維管理提升管理效率，進而為企業贏得更大市場、創造更多利潤。
閱讀更多 人民郵電出版社 的文章
