DevOps實踐指南

二零一九年讀完的第九十八本書，很大一部分是在飛機上讀完的，鑑於之前對DevOps體系有一定的瞭解，所以讀起來還是挺順利的，暫時還沒有遇到不可理解的點，至於在實踐中能否全部用上那就得看環境的配合了，道理我都懂只是條件不成熟的時候只能選擇走次優的路。看完這套書以後有計劃去考一個DevOps認證的證書來玩玩，看看自己是不是真的懂了。😄

Devops指南讀書筆記 價值流：一個組織基於客戶的需求所執行的一系列有序的交付活動； 流動原則 第一步，流動原則：通過持續加強工作內容的可視化，減少每批次大小和等待時間，內建質量以防止缺陷向下遊傳遞，從而增強流動性。通過加速技術價值流的流動，可以縮短滿足內部客戶和外部客戶的需求的前置時間，進一步提高工作質量。具體的目標：縮短代碼從變更到生產環境的。 提升價值流的流動性的手段： 1）限制在製品數：準確評估團隊的任務承載量，同時嚴格限制同時並行的任務； 2）減小批量大小：縮短前置時間和提高交付物質量，應該持續不斷追求小批量模式；最小的批量定義爲單件流，每次操作只執行1個單位產品的處理； 3）減少交接次數：一項工作在團隊之間交接時，需要大量的溝通——請求、委派、通知、協調，而且經常需要排優先級、調度、消除衝突、測試和驗證，實現自動化。 4）持續識別和改進約束點：環境搭建、代碼部署、測試的準備和執行、緊密耦合的架構。 5）消除日常中的困境：半成品、額外工序、額外功能、任務切換、等待、移動、缺陷、非標準或手動操作、填坑俠。 反饋原則 通過在整個價值流和組織中建立快速、頻繁、高質量的信息流，包括反饋和前饋迴路，可以讓系統更安全。這樣，就可以在規模較小、修復成本較低的情況下發現並修復問題，在災難發生前消除問題，並創造出組織性學習氛圍。同時，我們應該把失敗和事故的發生視爲寶貴的學習機會，而不是懲罰和責備的理由。 及時發現問題： 在安全的工作系統中，我們要不斷地對設計和假設進行驗證。目標是更早、更快、以儘可能低的成本、從儘可能多的維度增加系統的信息流，並儘可能清晰地確定問題的前因後果。能排除的假設越多，定位和解決問題的速度就越快，從而提高我們的順應力、敏捷性以及學習和創新能力。 在源頭保障質量： 做決策的地方一般遠離執行工作的地方，這導致審批流程的有效性有所下降。這樣做不僅降低了決策質量，而且還增加了決策週期，進而減弱了因果關係之間反饋的強度，降低了在成功和失敗中學習的能力。 在技術價值流中，我們通過爲運維而設計來爲下游工作中心做優化，包括運維的非功能性需求（如架構、性能、穩定性、可測試性、可配置性和安全性）與用戶功能同樣重要。 持續學習與實驗原則 技術價值流的核心是建立高度信任的文化。它強調每個人都是持續學習者，必須在日常工作中承擔風險；通過科學的方式改進流程和開發產品，從成功和失敗中積累經驗教訓，從而識別有價值的想法，摒棄無用的想法。另外，所有局部的經驗都會快速轉化爲全局性的改進，從而幫助整個組織嘗試和實踐新技術。 1）建立學習型組織和安全文化：組織包括病態型、官僚型、生機型； 2）將日常工作的改進制度化：通過明確預留時間來改善日常工作，包括預留時間來償還技術債、修復缺陷、重構和優化代碼和環境。可以在每個開發週期的間歇中預留一段時間，或者安排改善閃電戰（kaizen blitze）時段，讓工程師通過自組團隊的方式來解決他們感興趣的問題。 3）把局部發現優化改爲全局優化（推廣）：一旦在局部範圍內取得了成果，就應當把它分享給組織裏的其他人，讓更多的人從中獲益。換句話說，當單個團隊或個人獲得了獨有的專業知識或經驗時，我們的目標是把這些隱性知識（即很難通過文檔或溝通的方式傳遞的知識）轉換爲顯性知識，從而幫助其他人吸取這些專業知識並在實踐中應用。 4）在日常工作中注入彈性模式：通過加入一定程度的隨機變量不斷試驗，提高產能，進而達到抗脆弱性 5）領導層強化學習文化：爲團隊創造條件，讓團隊能在日常工作中感受到這種卓越，共同的努力，每個人都相互依存，缺一不可。這些目標條件構成了科學實驗的框架：清晰地描述出要解決的問題，對解決方案所做的假設，驗證假設的方法，對結果的解釋，以及如何利用經驗進行下一個迭代。領導者可以使用下列問題來幫助和輔導實驗者。 雖然培養持續學習與實驗的文化是第三步原則，但是它與第一步和第二步的工作方法密不可分。換句話說，要實現工作的快速流動和快速且持續的反饋，需要使用迭代和實驗的方法，包括設立目標條件，說明設想的解決方案，設計和進行實驗，以及評估結果。 第二部分：選擇合適的價值流作爲切入點：想清楚贏的邏輯 1）軟件項目分爲綠地項目與棕地項目：綠地項目是指在未開發的土地上建設的項目，而棕地項目則是指在以前用於工業生產的土地上建設的項目，這樣的土地可能受到有毒物質或污染物的侵蝕。在城市的發展過程中，許多因素使得綠地項目比棕地項目更容易實施——前者既不需要拆除建築，也不需要清除有毒物質。 2） 兼顧記錄型系統和交互型系統 記錄型系統：交易和數據的正確性比較突出，變化速度比較慢，需要做的正確 交互型系統：面向員工和客戶的可交互系統，變化速度比較快，需要快速響應。 3）從最樂於創新的團隊開始 4）從擴大Devops的範圍 階段一：發現創新者和早期採用者； 階段二：贏的沉默的大多數； 階段三：識別釘子戶。 理解、可視化和運用價值流 1）確定創造客戶價值所需的團隊：包括產品負責人、開發團隊、QA團隊、運維團隊、安全團隊、發佈經理、價值流經理 2）針對團隊工作繪製價值流圖：目標不是記錄所有的步驟和細節，識別阻礙價值流快速流動的環節，縮短前置時間與提高穩定性，注意A需要等待時間較長的工作；引發和處理重大返工的工作。 3）組建轉型團隊： A.擁有共同的目標：確定產生價值的小目標，以迭代，增量開發； B.保持小跨度的改進計劃：在短期內獲得可以度量的改進結果或者可用數據； C.20%的開發和運維時間投入到重構、自動化工作、架構優化以及非功能性需求：清理技術債務 D.提高工作的可視化程度 工具強化預期行爲：開發人員和運維人員不僅有着共同的目標，而且還有同一份任務列表。共享隊列的另一個好處是統一了任務列表，每個人都能從全局的角度思考優先級最高的事情，選擇對組織最有價值的工作，或能最大限度地償還技術債務的工作 參考康威定律設計組織結構 康威定律：軟件的架構和軟件團隊的結構是一致的，說白了就是‘如果讓4個團隊開發同一個編譯器，那麼編譯器最後會有4個執行階段’。 組織的原型：職能型、矩陣型、市場型 組建市場型的的團隊： 理想情況下，軟件的架構應該保證小團隊能夠獨立運作，彼此充分解耦，從而避免過多不必要的溝通和協調。 這種規模限制有以下4個重要作用。 （1）它確保團隊成員對系統有清晰、相同的理解。當團隊規模變大時，如果要讓所有人都瞭解系統狀況，需要溝通的信息量就會成倍增加。 （2）它限制正在開發的產品或服務的增長率。通過限制團隊的規模，系統的發展速度也受到限制，這也有助於保證團隊成員對系統有相同的理解。 （3）它分散權力並實現自主。每個“雙比薩”團隊都儘可能地自主工作。團隊負責人直接向管理層彙報，由他決定團隊負責的關鍵業務指標（又稱適應度函數），並將其作爲團隊實踐的總體評估標準。然後，團隊能夠自主採取行動來最大限度地提升該指標。 （4）領導“雙比薩”團隊是讓員工獲得領導經驗的一種方式。在這樣的環境中，即使失敗了也不會有災難性後果。亞馬遜的策略有一個關鍵要素，即“雙比薩”團隊的組織結構與面向服務架構之間的聯繫。 第8章，講運維融入日常開發 創建共享服務，提高開發生產力：創建一套集中式的平臺和工具集服務，讓所有開發團隊都能夠通過使用這套平臺和服務來提高生產力，例如搭建類生產環境、部署流水線、自動化測試工具、生產環境遙測控制檯等。 將運維工程師融入服務團隊：他們將參加開發團隊的相關討論，如計劃會議、每日站會以及新特性的演示，並幫助決定可以交付哪些特性。隨着開發團隊對運維知識和能力的需求逐漸降低，運維工程師就可以轉移到其他的項目或者工作中，接着按照以上模式進入下一個團隊以及相應產品的生命週期。 爲每個團隊分配運維聯絡人：給每個產品團隊指定一位運維聯絡人，職責：新產品的功能、如何工作、可擴展性和監控能力、怎麼監控和收集指標、是否對基礎設施有額外的要求，特性的發佈計劃。 邀請運維工程師參加開發團隊會議：包括每日站會、回顧會議、使用看板工作法。 第三部分：技術實踐 第一步流動的技術實踐 第9章： 1）按需搭建開發環境、測試環境、生產環境： 複製虛擬化環境（如VMware虛擬機鏡像、執行Vagrant腳本，以及啓動Amazon EC2虛擬機鏡像文件）； ❏ 構建“裸金屬物理機”的自動化環境搭建流程（例如，使用PXE方式通過基線鏡像進行安裝）； ❏ 使用“基礎設施即代碼”的配置管理工具（例如Puppet、Chef、Ansible、SaltStack、CFEngine等）； ❏ 使用操作系統自動化配置工具（例如Solaris Jumpstart、Red Hat Kickstart和Debian preseed）； ❏ 使用一組虛擬鏡像或容器（例如Vagrant和Docker）搭建環境； ❏ 在公有云（例如Amazon Web Services、Google App Engine和Microsoft Azure）、私有云或其他PaaS（平臺即服務，如OpenShift和Cloud Foundry等）中創建新環境。 2）應用統一的代碼倉庫： ❏ 應用的所有代碼和依賴項（例如庫、靜態內容等）； ❏ 任何用於創建數據庫模式的腳本、應用的參考數據等； ❏ 上一節描述的所有用於搭建環境的工具和工件（例如VMware或AMI虛擬機模板、Puppet或Chef配置模塊等）； ❏ 任何構建容器所使用的文件（例如Docker或Rocket的定義文件和compose文件等）； ❏ 所有支持自動化測試和手動測試的腳本； ❏ 任何支持代碼打包、部署、數據庫遷移和環境置備的腳本； ❏ 所有項目工件（例如需求文檔、部署過程、發佈說明等）； ❏ 所有云平臺配置文件（例如AWS CloudFormation模板、Microsoft Azure Stack DSC文件，以及OpenStack HEAT模板文件）； ❏ 創建支持多種基礎設施服務（例如企業服務總線、數據庫管理系統、DNS區域文件、防火牆配置規則和其他網絡設備）所需的任何其他腳本或配置信息。 3）使基礎設施的重建更容易：一旦出現問題，便可以快速進行構建，而不必花時間修復。變更爲了杜絕不受控制的配置差異，可以禁止遠程登錄生產服務器，或定期刪除和替換生產環境中的實例，從而確保移除手動變更。這會促使所有人都通過版本控制系統用正確的方式進行變更。這些措施能系統地減少基礎設施偏離已知良好狀態的可能性 4）運行在類生產環境裏纔算“完成”：最好在預生產環境中使用與生產環境相同的工具，如監控工具、日誌記錄工具和部署工具等。這樣做能讓我們積累經驗，熟悉如何在生產環境中順利部署和運行代碼，以及診斷和解決問題。通過讓開發團隊和運維團隊共同掌握代碼和環境互動的方式，並儘早頻繁地實施代碼部署，生產環境的部署風險得以顯著降低。這也避免了在項目的最後時刻才發現架構問題，並完全消除了這一類安全隱患。 第10章：實現快速可靠的自動化測試 1）對代碼和環境做持續構建、集成、測試：開發過程中的持續集成（continuous integration, CI）通常是指將多個代碼分支持續集成到主幹中，並確保它們都會通過單元測試。然而，在持續交付和DevOps中，持續集成還要求在類生產環境中運行應用，並且通過集成測試和驗收測試。 部署流水線的第一個環節是提交階段，這個階段完成代碼構建和打包，運行自動化單元測試，並執行其他各種驗證，如靜態代碼分析、測試覆蓋率分析、重複代碼檢查以及代碼風格檢查等。如果成功，就會進入驗收階段，自動地把在提交階段創建的包部署到類生產環境中，再執行自動化驗收測試。 當版本控制系統檢測到代碼變更後，將一次性生成軟件包。接下來，軟件包將在整個部署流水線中使用。這種方式保證了集成測試環境、類生產環境，以及生產環境的代碼一致性，可以有效減少難定位的下游錯誤（例如，所使用的編譯器、編譯器標誌參數、庫版本或配置不一致）。 因此，對於開發流程來說，部署流水線基礎設施和版本控制系統同等重要。部署流水線還存儲了每一份代碼的構建歷史，包括某次構建執行過哪些測試，測試結果如何，以及部署到了什麼環境中。結合版本控制系統中的歷史信息，可以快速地找到導致部署流水線失敗的原因和可能的修復方法。 這些信息還有助於審計和合規歷史數據（證據在日常工作中自動生成）。 有了部署流水線基礎設施之後，還必須有持續集成實踐，這需要以下3個方面的配合： ❏ 全面且可靠的自動化測試套件，用於驗證可部署狀態； ❏ 一種在驗證測試失敗時，可以“停掉整條生產線”的文化； ❏ 開發人員在主幹上工作，並小批量提交變更，而不是在生命週期很長的特性分支上工作。 單元測試：通常獨立測試每個方法、類或函數。它的目的是確保代碼按照開發人員的設計運行。由於諸多原因（如需要進行快速和無狀態的測試），通常會使用打樁（stub out）的方式，隔離數據庫和其他外部依賴（例如，把函數修改爲返回靜態的預定義值，而不是調用數據庫）。 ❏ 驗收測試：通常整體測試應用，確保各個功能模塊按照設計正常工作（例如符合用戶故事的業務驗收標準，API能正確調用），而且沒有引入迴歸錯誤（即沒有破壞以前正常的功能）。Jez Humble和David Farley認爲單元測試和驗收測試的區別在於：“單元測試的目的是證明應用的某一部分符合程序員的預期……驗收測試的目的則是證明應用能滿足客戶的願望，而不僅僅是符合程序員的預期。”在構建的版本通過單元測試後，部署流水線就對其執行驗收測試。任何通過驗收測試的構建版本通常都可用於手動測試（例如探索性測試、用戶界面測試等）和集成測試。 ❏ 集成測試：保證應用能與生產環境中的其他應用和服務正確地交互，而不再調用打樁的接口。Jez Humble和David Farley寫道：“大部分系統集成測試工作都是在部署應用的新版本，並使它們能正常協作。在這種情況下，冒煙測試通常是指針對整個應用進行的一組成熟的驗收測試。”只有通過了單元測試和驗收測試的構建版本才能執行集成測試。因爲集成測試通常是脆弱的，所以應該儘量減少集成測試的次數，並且要在單元測試和驗收測試期間，儘可能多地找出缺陷。 第11章：應用和實踐持續集成 1）小批量開發與大批量合併 2）應用基於主幹的開發實踐 這些代碼通過一鍵式流程在主幹上創建，並已通過自動化測試。 第12章：自動化和低風險發佈 1）自動化部署流程： 部署流水線：用相同的方式處理所有環境的部署：對所有的環境進行相同的部署機制，提高生產部署的成功率。 對部署執行冒煙測試：在部署過程中，測試所有的依賴系統是否能正常訪問 維持環境的一致性：保持開發環境、測試環境、生產環境共同的搭建機制，保證搭建的方式是一致的。 構建：部署流水線必須基於版本控制系統構建可部署到任何環境（包括生產環境）的軟件包。 測試：任何人都應該能夠在他們的工作站上或測試系統中運行任何一個自動化測試套件。 部署：任何人都應該能夠將這些軟件包部署到具有訪問權限的任何環境，通過執行（已提交到版本控制系統中的）腳本來完成部署。 如果代碼部署過程是自動化的，就能將其變成部署流水線的一部分。 第13章：將部署與發佈解耦 基於環境的發佈模式 1）藍綠部署：藍綠部署是3種模式中最簡單的一種。在這種模式下，我們有兩個生產環境：藍環境和綠環境。 在發佈新版本的服務時，先把它部署到非在線環境，以便在不影響用戶體驗的情況下執行測試。在確信一切都正常以後，再把客戶流量切換到藍環境，用這種方式來交付新版本。之後，藍環境就變成了生產環境，綠環境則變爲預生產環境。通過把客戶流量再重定向回綠環境，還可以實現回滾。 2）金絲雀發佈： 在金絲雀發佈模式下，我們會監控軟件在每個環境中的運行情況。一旦出現問題，就回滾；否則就在下一個環境中進行部署。 基於應用的發佈： 1）特性升級 基於應用的發佈模式主要是通過特性開關來實現的。特性開關機制使我們能在不進行生產環境代碼部署的情況下，選擇性地啓用和禁用特性。通過特性開關，可以將應用的特性向某些特定用戶（例如內部員工和某些客戶羣）開放。 特性開關的實現機制通常是用條件語句封裝應用邏輯或用戶界面元素，並根據保存在某處的配置信息啓用或禁用某個特性。可以使用簡單的應用配置文件（例如JSON或XML格式的配置文件）存儲配置信息，也可以通過服務目錄來配置，甚至可以專門設計用於管理特性開關的Web服務。 輕鬆地回滾：只需更改特性開關的設置，就可以在生產環境中，快速安全地禁用出了問題或造成服務中斷的特性。在非頻繁部署的情況下，它的價值更大——關掉某一個特性通常要比回滾整個版本容易得多。 緩解性能壓力：當服務遭遇極高的負載時，通常需要擴容系統；更糟糕的是，可能導致生產環境中的服務中斷。不過，可以使用特性開關來緩解系統的性能壓力。換句話說，可以通過減少可用的特性，來支持更多的用戶（例如，減少使用某特性的客戶數量，禁用推薦等CPU密集型特性，等等）。 採用面向服務架構提高恢復能力：即便某個特性依賴於還沒有上線的服務，仍然可以將這個特性部署到生產環境中，然後用特性開關把它先隱藏起來。當它所依賴的服務上線後，就可以啓用這個特性。同樣，當所依賴的服務中斷時，也可以關閉該特性，這樣做不但可以和下游的故障服務隔離，同時還可以保持應用的其餘部分正常運行。 2）黑啓動 特性開關實現的效果是，將特性部署到生產環境中，但暫時使其不可用。它使黑啓動技術成爲可能——先把所有特性都部署到生產環境中，然後對客戶不可見的特性執行測試。對於大規模或高風險的變更來說，黑啓動過程往往持續數週，從而保證在正式發佈之前使用類生產負載安全地進行測試。 13章：降低發佈風險的架構 1、能提高生產力、可測試性和安全性的架構 緊耦合架構不僅會降低生產力，還會影響安全變更的能力。接口定義清晰的松耦合架構則與之相反，它優化了模塊間的依賴關係，提高了生產力和安全性，讓小型且高產的“雙比薩”團隊可以執行小的變更，並能安全和獨立地進行部署。因爲每個服務都有一個定義明確的API，所以更容易測試，團隊之間的服務等級協議條款也更容易確定。 2、架構原型：單體架構與微服務 大多數DevOps組織都曾深深地被緊耦合的單體架構困擾。雖然單體架構非常成功地幫助這些組織實現了產品與市場的高度契合，但是當組織規模擴大後，這樣的架構卻成了很大的隱患（例如，eBay在2001年的單體C++應用、亞馬遜在2001年的單體Obidos應用、Twitter在2009年的單體Rails前端，以及LinkedIn在2011年的單體Leo應用）。 第14章 建立能發現並解決問題的遙測系統 1、建設集中式監控架構 在業務邏輯、應用程序和環境層收集數據 負責存儲和轉發事件和指標的事件路由器 2、建立生產環境的應用程序日誌遙測 調試級別：此級別的信息是相關應用程序中發生的所有事件，最常用於調試的時候。通常，調試日誌在生產中是禁用的，但在故障診斷期間要暫時啓用。 信息級別：此級別的信息包括用戶觸發的或系統特定的操作（例如“開始信用卡交易”）。 警告級別：此級別的信息告訴我們可能的出錯情況（例如，調用數據庫花費的時間超過某個特定時長）。可能會因此而觸發報警和故障診斷過程，而其他日誌消息會有助於更好地理解事件的原因。 錯誤級別：此級別的信息側重於錯誤狀況（例如，API調用失敗，內部出錯）。 致命級別：此級別的信息告訴我們何時發生了中斷情況（例如，網絡守護進程無法綁定網絡套接字） 3、使用遙測指導問題的解決 4、將建立生產遙測融入日常工作 5、建立自助訪問的遙測和信息輻射器 通過使監控信息可以快速、方便地獲取到，並且把數據完全集中化處理，價值流中的所有人都可以對現狀有所瞭解。這通常意味着將生產度量指標顯示到一個由中央服務器（比如Graphite）或上一節中提到的任何其他技術實時生成的網頁上。 我們希望生產監控指標具有高度的可見性，這意味着要將其放置在開發和運維人員工作區域的中心，從而使所有感興趣的人都能看到服務的現狀。這至少要包括價值流中的每一個人，比如開發、運維、產品管理和信息安全。 6、發現和填補遙測的盲區 業務級別：示例包括交易訂單的數量、產生的營業額、用戶註冊數、流失率、A/B測試的結果等。 應用程序級別：示例包括事務處理時間、用戶響應時間、應用程序故障等。 基礎架構級別（如數據庫、操作系統、網絡、存儲）：示例包括Web服務器吞吐量、CPU負載、磁盤使用率等。 客戶端軟件級別（如客戶端瀏覽器上的JavaScript、移動應用程序）：示例包括應用程序的出錯和崩潰、用戶端的事務處理時間等。 部署流水線級別：示例包括構建流水線狀態（例如：各種自動化測試套件的紅色或綠色狀態）、變更部署前置時間、部署頻率、測試環境上線狀態和環境狀態。 第15章 分析遙測數據以更好地預測故障和實現目 用均值和標準差識別潛在問題 異常狀態的處理和告警 非高斯分佈遙測數據的問題 第16章 應用反饋實現安全部署 1、通過遙測使部署更安全 2、開發和運維共同承擔值班工作 3、讓開發人員跟蹤工作對下游的影響 4、讓開發人員自行管理生產服務 第17章 將假設驅動的開發和A/B測試融入日常工作 1、在功能測試中集成A/B測試 2、在發佈中集成A/B測試 3、在功能規劃中集成A/B測試 第18章 建立評審和協作流程以提升當前工作的質量 1、變更審批流程的危險 2、“過度控制變更”的潛在危險 3、變更的協調和排程 4、變更的同行評審 5、人工測試和變更凍結的潛在危害 6、利用結對編程改進代碼變更 第19章 將學習融入日常工作 1、建立公正和學習的文化 2、舉行不指責的事後分析會議 3、舉行不指責的事後分析會議 4、降低事故容忍度，尋找更弱的故障信號 5、重新定義失敗，鼓勵評估風險 6、在生產環境注入故障來恢復和學習 7、創建故障演練日 第20章 將局部經驗轉化爲全局改 1、使用聊天室和聊天機器人自動積累組織知識 2、軟件中便於重用的自動化、標準化流程 3、創建全組織共享的單一源代碼庫 4、運用自動化測試記錄和交流實踐來傳播知識 5、通過確定非功能性需求來設計運維 6、把可重用的運維用戶故事納入開發 7、確保技術選型有助於實現組織目標 第21章 預留組織學習和改進的時間 1、償還技術債務的制度化慣例 2、讓所有人教學相長 3、在DevOps會議中分享經驗 4、傳播實踐的內部顧問和教練

2024.No85： 24年第40本技術書。DevOps是一個很大的概念，是文化也是理念，是實踐也是工具，是原則也是規範。DevOps乃集大成者，包含敏捷開發、MVP實現、看板、站會、Sprint等。目前國內的IT公司，不管大小，都或多或少認可DevOps。至少在引入GitLab(GitHub)+Jenkins+SonarQube+JIRA(禪道)+Confluence+Docker+K8S等CI/CD等工具鏈等方面還是有目共睹的。但是開發流程、部門組織、團隊架構、公司文化等層面則不見得多麼實踐DevOps。

書中除了理論研究也附帶了很多實踐案例，可以作爲工具書，時不時拿來翻翻，慢慢領悟其中內涵，將來會受益匪淺。

個人認爲這是對devops體系介紹比較詳細的書了，更多的還是通過一些企業的生產案例來介紹devops方法論，不錯，值得閱讀

最近公司在嚴抓代碼質量+需要學習自動化集成與測試。 感覺Devops是一種趨勢，相信隨着歷史的推進，一個越來越講究質量的時代即將到來。而且精益理念不僅僅應用在IT行業，人生成長也應該敏捷、快速迭代。 一、Devops的三原則。 內容：回顧DevOps的發展史，探討了DevOps組織轉型的三步工作法：流動原則、反饋原則和持續學習與實驗原則。 1. 流動： 使工作可見、限制數量、減少批量大小，減少交接次數，持續識別改善約束點，消除價值流中的困境和浪費。 2. 反饋原則 建立快速的反饋機制，對於實現技術價值流中高質量、可靠性和安全性至關重要，要在問題發生時識別問題、羣策羣力解決問題並構建新的知識，在源頭控制質量，並且不斷爲工作重心做優化。 3. 持續學習與實現 接收系統中會發生故障的實時，並鼓勵討論任何問題，以建立一個安全的工作系統，還要求將日常工作的改進制度化，把局部成果轉化爲可供組織全局使用和學習的惡知識以及不斷向日常工作注入張力。 二、Devops實踐: 內容：DevOps轉型的多個方面，包括選擇切入點，理解架構與組織的關係，以及組建轉型團隊，還探討了如何將運維工作融入開發團隊的日常工作。 1. 選擇合適的切入點 謹慎得選擇切入點，選擇不會對組織造成巨大影響的團隊，選擇有開拓精神的團隊選擇有多領域知識的人，選擇和各部門有良好關係的人。 2. 通過繪製價值流圖瞭解到了向客戶交付價值所要做的工作。 3. 運用康威定理設計組織架構 4. 將運維融入日常開發工作 三、流動技術實踐: 內容：實現了使工作從開發到運維快速流動的架構和技術實踐，從而快速、安全地向客戶交付價值。 1. 構建從開發到運維的快速工作流，需要確保任何人都能按需獲得類生產環境。通過讓開發人員在軟件項目的最初階段就使用類生產環境，可以顯著降低生產環境出現問題的風險。爲實現全面自動化測試奠定了基礎 2. 創建了一組全面的自動化測試，用來確保構建始終處於綠色的可部署狀態。我們在部署流水線中組織好了測試套件和測試活動，還建立了規範，要求無論誰的代碼變更導致自動化測試失敗，大家都要竭盡全力地將系統恢復到綠色狀態。 3. Puppet Labs的《2015年DevOps現狀報告》表明，基於主幹的開發方式能帶來更高的生產力、更好的穩定性，甚至更高的工作滿意度和更低的職業倦怠率。 4. 將發佈和部署融入日常工作，能夠把部署時間從幾個月縮短到幾分鐘，使組織能夠快速地向客戶交付價值，同時避免意外事故和服務中斷。此外，開發人員和運維人員的緊密合作，能使運維工作變得人性化。 5. 使工作從開發到運維快速流動的架構和技術實踐，從而快速、安全地向客戶交付價值。 四、反饋技術實踐: 內容：通過實施反饋迴路，可以讓每個人都爲實現共同的目標而協作，當發生問題時及時發現問題，並通過快速檢測和恢復的機制，保障所有功能不僅能按照設計在生產環境中運行，而且還實現了組織目標和組織學習。我們還研究瞭如何讓開發和運維共享目標，從而提高整個價值流的健康程度。 1. 在問題發生時就能發現問題是多麼地重要，這樣才能及時地找出原因，並迅速補救。 2. 本章探討了幾種用於分析生產環境遙測數據的統計技術，通過它們能更早地發現和解決問題，並且能在問題較小的時間予以解決，從而避免造成災難性後果。這些技術使我們能識別出那些微弱的故障信號，並及時採取行動，從而建立一個更安全的工作系統，同時提高實現目標的能力。 3. 反饋機制，它使得我們可以在日常工作的每個階段改進服務，不管是將變更部署到生產環境，在出現問題時請求工程師修復代碼，讓開發人員跟蹤下游工作，建立非功能性需求來幫助開發團隊編寫更優的生產就緒代碼，還是將有問題的服務交回給開發團隊自己管理。 4. 成功不但需要快速地部署和發佈軟件，還要在實驗方面超越競爭對手。採用假設驅動的開發、定義和度量客戶獲取渠道，以及A/B測試等技術，能夠安全、輕鬆地進行用戶實驗，從而讓員工發揮出創造力和創新能力，並進行組織性學習。 5. 本章討論了一些要整合到日常工作中的技術實踐，它們能夠提高變更的質量，降低部署出錯的風險，減少對審批流程的依賴。GitHub和塔吉特的案例研究表明，這些實踐不僅改善了工作成果，而且還極大地縮短了前置時間，並提高了開發人員的生產力。這些工作需要高度信任的文化。 五、打造持續學習性組織技術: 內容：探討了在組織中創造學習和實驗文化的實踐。當我們在複雜系統中工作時，從事故中學習，創建共享代碼庫和共享知識是必不可少的，這有助於工作文化更公正，系統更安全、更具彈性。 1. 不指責的事後分析會議和在生產環境中注入故障都強化了這樣一種文化：每個人都應該坦然面對失敗，承擔責任，並從失敗中學習。事實上，當事故數量大幅降低時，容忍度同時也下降了，從而讓我們能夠繼續學習。正如Peter Senge所說：“組織唯一的可持續競爭優勢就是比對手更快的學習能力。” 2. 通過主動和廣泛地傳播新知識來實現這個目標，例如採用聊天室、架構即代碼、共享源代碼庫、技術標準化等方法。這樣做不僅能提升開發和運維團隊，更能提升整個組織，因此組織中的每個工作者都在爲積累集體經驗添磚加瓦。 3. 本章描述瞭如何建立一系列慣例，來幫助強化終身學習以及重視在日常工作中改進日常工作的文化。具體實現方法是：預留償還技術債務的時間；創建論壇，使大家能夠在組織內部和外部互相學習和指導；通過輔導、諮詢，或者僅僅設置一段面談時間，讓專家能夠爲內部團隊提供幫助。 六、集成信息安全、變更管理、和合規性的技術實踐： 內容：探討了如何將DevOps原則應用於信息安全，幫助我們實現目標，並確保安全是所有人日常工作的一部分。更好的安全性確保了我們能防護數據、理智地對待數據，能在安全問題釀成災難以前恢復。最重要的是，我們可以讓系統和數據的安全性變得比以往更好。 1. 通過將安全控制集成到已經創建的機制中，確保所有按需環境都處於加固的低風險狀態，以及通過將安全測試集成到部署流水線中，確保在預生產和生產環境中創建安全遙測系統。這樣，我們可以在提高開發和運維效率的同時，提高整體安全性。 2. 讓每個人都承擔信息安全責任的實踐，將所有的信息安全目標都納入價值流中每個人的日常工作。這樣顯著提高了控制的有效性，能更好地預防安全漏洞，更快地檢測到安全漏洞並從中恢復。此外，還大大減少了準備和通過合規審計的工作時間。

想要學習瞭解DevOps，可以從這本書開始。DevOps是一種管理實踐的大融合，包括精益、敏捷、持續集成與交付等，並且能夠與ITIL和信息安全結合，所以我們現在稱爲DevSecOps。 :) DevOps的三步工作法： 第一、正向的流動原則(Flow)：利用Could和Docker/K8S等技術簡化基礎設施搭建，使用自動化代碼檢查、自動化測試、持續集成和持續部署/發佈來加快能力的交付。 第二、反向的反饋原則：利用日誌和監測技術監控系統健康，再結合統計分析能力預測問題，以及利用A/B測試快速試錯與創新。 第三、持續學習與實驗原則：建立學習的文化和制度，推動組織內的信息共享，預留日常工作改進的時間。 而信息安全，則要結合進已經建立的各種流程和工具中，而不是在上線前才整改。

移的實踐——在需求和設計階段就開始做威脅建模，而不是等到上線前才慌慌張張做安全實踐。

這本書是應試用的。 鳳凰項目是基礎。我只看了三個工作法，這部分兩本書基本內容是一樣的。 說實話這不是我現在需要的書……

裏面涉及到的知識點蠻多的，有些理念講的挺好，值得借鑑，但是在國內場景下落地複雜度還是蠻高，對日誌、監控、安全以及平臺化建設方面的內容略少，大部分的着重點是圍繞CICD和生成穩定來開展的，學習到了不少，感謝