《DevOps實踐指南》第二部分 從何處開始

• 2019 年 12 月 19 日
• 筆記

第 5 章　選擇合適的價值流作為切入點

• 我們的第一個目標就是幫助所有團隊測量周期，使之可視化，並嘗試縮短交付周期，然後不斷迭代。」

5.1　綠地項目與棕地項目

• 綠地項目是指全新的軟體項目
• 棕地項目是指已經服務客戶長達幾年甚至幾十年的產品或服務。這種項目通常背負大量的技術債務
• 很多人認為DevOps主要面向綠地項目，但成功應用DevOps進行轉型的棕地項目比比皆是

5.2　兼顧記錄型系統和交互型系統

• 傳統記錄型系統是指類似於ERP系統，記錄型系統的變化通常較慢
• 交互型系統變化速度通常較快，需要快速響應回饋

5.3　從最樂於創新的團隊開始

• 我們的目標是找到那些相信DevOps原則和實踐，並有意願和能力對現有流程進行創新和改進的團隊
• 我們不會花費太多時間去改變保守的群體，特別是在早期階段。相反，應該把精力集中在能創造成功且願意承擔風險的團隊上，並以此為基礎慢慢擴大範圍

5.4　擴大DevOps的範圍

• 不管如何選定切入點，都要儘早展示成果，並積極宣傳
• (1) 發現創新者和早期採用者：一開始，把重點放在真正有意願改進的團隊上
• (2) 贏得沉默的大多數：在下一階段，力求將DevOps實踐擴展到更多的團隊和價值流，目標是建立更穩固的群眾基礎
• (3) 識別「釘子戶」：所謂「釘子戶」，是指那些高調的、有影響力的反對者

第 6 章　理解、可視化和運用價值流

• 根據多年的經驗總結出一個開始優化價值流的有效方法，就是和所有核心干係人一起演練價值流映射，從而幫助團隊梳理出創造價值的所有步驟

6.1　確定創造客戶價值所需的團隊

• 無論價值流的複雜程度如何，其中都沒有一個人能夠知道為客戶創造價值所要做的每一項工作，尤其是當工作由多個團隊完成時。這些團隊往往屬於不同的部門，甚至不在同一個辦公地點，考核方式也不同

6.2　針對團隊工作繪製價值流圖

• 繪製價值流圖的目標並不是記錄所有的步驟和細節，而是識別出阻礙價值流快速流動的環節，從而縮短前置時間和提高可靠性。在理想情況下，參與研討會的成員應該有權力改變各自負責的部分1
• 根據我的經驗，這樣的價值流映射演練總是讓人大開眼界。很多人通常是第一次看到，為了向客戶交付價值，到底需要完成多少工作
• 根據價值流參與團隊所提供的全部資訊，應該重點分析和優化下面兩類工作
  • 需要等待數周甚至數月的工作，例如準備類生產環境、變更審批流程或安全審查流程等
  • 引發或處理重大返工的工作

• 概念
  • 工作項的前置時間：LT
  • 處理時間（或增值時間）：VA（Value Added Time）
  • 由下游消費者測量的%C/A

6.3　組建專門的轉型團隊

• 應該組建專門的轉型團隊，並使之獨立於負責日常運作的部門（他們稱前者為「專職團隊」，稱後者為「績效引擎」）
• 最重要的是，這個團隊應該負責實現明確定義的、可度量的、系統級的目標（例如，將「從提交程式碼到部署至生產環境」這一過程的前置時間減少50%）。為了做到這一點，應該採取以下措施：
  • 轉型團隊的成員專門執行DevOps轉型工作（而不是讓他們繼續做之前的工作，但要花20%的時間來做DevOps轉型
  • 選擇熟悉多個領域的通才作為團隊成員
  • 選擇與其他部門長期保持良好關係的人作為團隊成員
  • 如果可能，為團隊找一個獨立的辦公區域，使各位成員儘可能多地相互交流，並和其他部門保持適當的距離

6.3.1　擁有共同的目標

• 任何改進計劃的首要內容都是為未來6個月到2年設定可度量的目標。為了實現目標，團隊需要付出相當大的努力，而且目標的實現應該能為整個組織和客戶創造出顯著的價值
• 一旦明確了整體目標，團隊就應該制訂改進工作的詳細計劃與節奏。像產品開發工作一樣，轉型工作也應該以迭代、增量的方式進行。一般每次迭代在2～4周內完成。對於每次迭代，團隊應該制訂出一組能夠產生價值的小目標，並朝著長期目標靠近。在每次迭代結束時，團隊應該檢查進度，並為下一次迭代設定新的目標

6.3.2　保持小跨度的改進計劃

• 具備重新計劃和更改優先順序的能力和靈活性
• 減少工作從實施到生效的延遲時間 ，從而加強回饋迴路 ，這將更有可能強化期望的行為——初步成功有利於加大投入
• 從迭代中更快地獲得經驗 ，並將其用於下一次迭代
• 能夠更省力地獲得改進
• 在日常工作中更快地實現有意義的差異化改進
• 降低項目還沒有取得成果就被終止的風險

6.3.3　為非功能性需求預留20%的開發時間，減少技術債務

• 為了積極地管理技術債務，要確保至少把20%的開發和運維時間投入到重構、自動化工作、架構優化以及非功能性需求（有時也稱為「品質屬性」）上，例如可維護性、可管理性、可擴展性、可靠性、可測試性、可部署性和安全性等（見下圖）

• 產品負責人和工程師之間的協作是這樣的：產品負責人需要考慮把團隊20%的資源分配給與工程相關的活動，用於重寫或重構程式碼庫中有問題的部分，如果情況已經非常糟糕了，那就可能需要投入30%甚至更多的資源
• 如果組織不願意支付這「20%的稅」，那麼技術債務將會最終惡化到耗盡所有可用資源的程度。終有一天，服務會變得不堪一擊，特性交付將停滯不前，所有工程師都在解決可靠性問題或者尋求臨時方案

案例研究 * LinkedIn的「反轉行動」（2011年）

LinkedIn的「反轉行動」（Operation InVersion）是一個有趣的案例，它證明了為什麼要把償還技術債務作為日常工作的一部分。2011年，LinkedIn成功進行了IPO。但半年過去了，公司依然在部署問題上苦苦掙扎。於是，他們啟動了「反轉行動」，在兩個月內，停止所有特性開發，並對計算環境、部署和架構進行全面的優化 截至2010年，大多數新開發的特性都以新的服務部署，已經有近百個服務獨立於Leo運行。但Leo本身還是只能每兩周部署一次 現在，LinkedIn的工程師每天將網站進行3次重要升級 2010年，我們已經有超過150個獨立的服務。今天，我們的服務超過750個

6.3.4　提高工作的可視化程度

• 組織中的每個人都有必要了解當前的工作狀態。將狀態進行可視化的方法有很多，最重要的是有效展示最新狀態，而且要不斷修訂，以確保團隊了解最新進展

6.4　用工具強化預期行為

• 共享隊列的另一個好處是統一了任務列表，每個人都能從全局的角度思考優先順序最高的事情，選擇對組織最有價值的工作，或能最大限度地償還技術債務的工作。在發現技術債務時，如果不能立即解決，可以將它添加到任務列表中。對於待解決的問題，可以使用為非功能性需求預留的20%的時間進行修復

第 7 章　參考康威定律設計組織結構

• 康威定律：「系統設計受限於組織自身的溝通結構。組織的規模越大，靈活性就越差，這種現象也就越明顯。」
• 康威定律：「軟體的架構和軟體團隊的結構是一致的，說白了就是『如果讓4個團隊開發同一個編譯器，那麼編譯器最後會有4個執行階段』。」
• 軟體開發團隊的結構對軟體產品的架構和成果有著巨大的影響

7.1　組織原型

• 主要有3種組織結構類型
  • 職能型組織結構：注重提高專業技能、優化分工或降低成本
  • 矩陣型組織結構：試圖結合職能型和市場型。然而，正如許多管理矩陣型組織或身處其中的人所看到的那樣，這種組織結構通常都非常複雜
  • 市場型組織結構：注重快速響應客戶需求。這種組織往往有著扁平化的結構，由多個跨職能的部門組成（例如市場營銷部門和工程技術部門等），整個組織可能往往存在冗餘現象。很多實施DevOps的傑出組織採用了這種結構

7.2　過度職能導向的危害（「成本優化」）

• 傳統IT運維組織往往採用職能型結構，資料庫管理員被歸在一組，網路管理員歸在另一組……這種方式顯然會延長交付周期，特別是在大規模部署這樣複雜的活動中，不得不向多個團隊發出一堆工單並且對工作的交接情況進行協調，導致每一個步驟都面臨長時間等待

7.3　組建以市場為導向的團隊（「速度優化」）

• 將工程師及其專業技能（如運維、QA和資訊安全）嵌入每個服務團隊，或者得團隊提供自助服務平台，其功能包括配置類生產環境、執行自動化測試或進行部署

7.4　使職能導向有效

• 左側為職能導向：所有工作流經集中式IT運維團隊
• 右側為市場導向：所有產品團隊能以自助的方式向生產環境部署松耦合的組件

7.5　將測試、運維和資訊安全融入日常工作

• 共同的痛點可以強化團隊的共同目標。一個經典的案例是Facebook。2009年，Facebook正經歷著飛速的增長，同時在程式碼部署方面也遇到了重大問題。雖然並非所有問題都會直接影響到客戶，但團隊始終處於沒完沒了的救火狀態中
• 為了提升部署效率，Facebook採取的最有效的一個措施就是讓所有工程師、工程經理和架構師輪流值班，負責他們自己構建的服務的運維工作。通過這樣做，所有構建服務的人都對自己在上游所負責的架構和程式碼有了親身的感受，這對下游的工作產生了巨大的積極影響

7.6　使團隊成員都成為通才

• 部門過於專業化時，就會產生筒倉
• 任何複雜的運維活動都需要在基礎設施的不同部分之間多次交接和排隊，這導致交付時間推遲（例如，每次網路變更都必須由網路部門的某個人實施）
• 一種對策是讓每一位團隊成員都成為通才（見表）

• E型人才是指在經驗、專業、探索能力和執行能力4個方面都表現突出的人

7.7　投資於服務和產品，而非項目

7.8　根據康威定律設定團隊邊界

• 不合理的團隊組織方式可能產生不良後果，這就是康威定律的副作用。這些不當的方式包括按職能劃分團隊（例如將開發人員和測試人員安置在不同的辦公地點，或者完全外包測試人員），以及按架構層次拆分團隊（如應用層、資料庫層等）
• 不當的組織方式需要各個團隊進行大量的溝通和協調，但仍然可能導致大量返工、對需求定義有分歧、工作交接低效，以及由於等待上遊人員完工而造成的人員閑置等

7.9　創建松耦合架構，提高生產力和安全性

• 如果架構能夠支援小團隊獨立、安全、快速地進行開發、測試和部署，就可以提高和維持開發人員的生產力，並改善部署品質。面向服務架構（Service-Oriented Architecture，SOA）就具有這種特徵
• 它是一種支援獨立測試和部署服務的架構方式，其典型特徵是由具有限界上下文的松耦合服務組成
• 限界上下文（bounded context）是Eric Evans在《領域驅動設計》9一書中提出的概念。其思路是開發人員應該能夠理解和更新服務的程式碼，而不必知道其對等服務的內部邏輯

保持小規模（「兩個比薩原則」）

• 2002年，亞馬遜在試圖脫離單一程式碼庫的轉型過程中利用「兩個比薩原則」保持團隊規模小型化——兩個比薩夠團隊的所有成員吃，這樣的團隊通常有5～10人
• 這種規模限制有4個重要作用
  • (1) 它確保團隊成員對系統有清晰、相同的理解。當團隊規模變大時，如果要讓所有人都了解系統狀況，需要溝通的資訊量就會成倍增加
  • (2) 它限制正在開發的產品或服務的增長率。通過限制團隊的規模，系統的發展速度也受到限制，這也有助於保證團隊成員對系統有相同的理解
  • (3) 它分散權力並實現自主。每個「雙比薩」團隊都儘可能地自主工作。團隊負責人直接向管理層彙報，由他決定團隊負責的關鍵業務指標（又稱適應度函數），並將其作為團隊實踐的總體評估標準
  • (4) 領導「雙比薩」團隊是讓員工獲得領導經驗的一種方式。在這樣的環境中，即使失敗了也不會有災難性後果。亞馬遜的策略有一個關鍵要素，即「雙比薩」團隊的組織結構與面向服務架構之間的聯繫
• 康威定律運用得好，團隊就能夠安全、獨立地開發、測試和向客戶交付價值；而運用得不好，就會產生不良的後果，導致安全性和敏捷性遭到破壞

第 8 章　將運維融入日常開發工作

• 集中式運維團隊如何取得以市場為導向的成果
• 3個通用的策略：
  • 構建自服務能力，幫助開發人員提高生產力
  • 將運維工程師融入服務團隊
  • 如果運維工程師人數緊張，則可以採用運維聯絡人模式

8.1　創建共享服務，提高開發生產力

• 運維部門若想取得以市場為導向的成果，一種做法是創建一套集中式的平台和工具集服務，讓所有開發團隊都能夠通過使用這套平台和服務來提高生產力，例如搭建類生產環境、部署流水線、自動化測試工具、生產環境遙測控制台等

8.2　將運維工程師融入服務團隊

• 通過融入運維工程師使產品團隊能自給自足，從而降低對集中式運維的依賴程度。這些產品團隊可以完全負責服務的交付和支援
• 產品團隊通常有專用的預算僱用這些運維工程師，不過面試和聘用決策可能還是由集中式運維團隊來完成，以確保一致性和員工的素質
• 這種範式有一個重要優勢：開發團隊和運維工程師的緊密配合和協作是一種極其有效的方式，能將運維知識通過交叉培訓的方式融入服務團隊，還可以將運維知識逐漸轉換為自動化的程式碼，使之更可靠和更廣泛地重用

8.3　為每個服務團隊分派運維聯絡人

• 由於各種原因（如成本或者資源不足），可能無法給每個產品團隊都分派運維工程師，但可以給每個產品團隊指定一位運維聯絡人，通過這種方式同樣也能得到類似的好處

8.4　邀請運維工程師參加開發團隊的會議

• 可以邀請他們參與開發團隊的各種會議。我們的目標是幫助運維工程師和其他非開發人員更好地了解目前開發團隊的文化，並主動地參與規劃工作和日常工作，從而使運維團隊可以更好地為產品團隊植入運維能力，並在產品上線以前就落實相關工作

8.4.1　邀請運維工程師參加每日站會

• 有些資訊在開發團隊內部是分散的，這是一個常見的問題。通過參加會議的運維工程師，運維部門可以充分理解開發團隊的活動，從而更好地進行規劃和準備

8.4.2　邀請運維工程師參加回顧會議

• 參加回顧會議的運維工程師也可以從中學習和受益。而且，當回顧的時間段里正好有部署或發布時，運維工程師應該向大家彙報結果，並給產品團隊提供回饋。這樣做可以改進未來工作的計劃和執行方式，提高工作的品質
• 我們必須提醒所有人，改進日常工作其實比日常工作本身更重要，所有團隊都必須為此預留時間（例如，每個周期都分配20%的時間用於改進工作，安排每周一天或每月一周，等等）。如果不這樣做，在償還技術債務的巨大壓力之下，團隊的生產力肯定會遭到破壞

8.4.3　使用看板圖展示運維工作

• 使用看板圖展示相關的運維工作非常少見。然而，若想使應用成功運行於生產環境（真正產生客戶價值的地方），這些運維工作是必需的
• 因為運維工作是價值流的一部分，所以應該將它和與產品交付相關的其他工作一起呈現在看板圖上

第二部分總結

• 我們思考並探討了DevOps轉型的多個方面，包括選擇切入點，理解架構與組織的關係，以及組建轉型團隊，還探討了如何將運維工作融入開發團隊的日常工作