農曆假期還沒結束XD，繼續整理筆記。
本書分成六大章節，分別為
Part 1：三步工作法 (筆記)
Part 2：從何處開始
Part 3：第一步工作法：暢流的技術實踐
Part 4：第二步工作法：回饋的技術實踐
Part 5：第三步工作法：持續學習與實驗的具體實踐
Part 6：整合資訊安全、變更管理和合規性的技術實踐
///// 以下是 Part 2 的書摘筆記 /////
Chapter 5 選擇適當的價值流作為切入點
- 軟體服務或產品常被分為「綠地」 (Green Field) 專案和「棕地」 (Brown Field) 專案
- Green field project : 代表全新的軟體專案。通常還處於規劃或實施的早期階段，有機會建構全新的應用和基礎架構，不會受到過多限制。也常用來指一些試驗性專案。ex. National Instruments 發布的 Hosted LabVIEW.
- Brown field project：指那些已經服務客戶長達幾年甚至幾十年的產品或者服務。通常背負著大量的技術債。
- 很多人認為DevOps主要是用於綠地專案，但成功應用DevOps進行轉型的棕地專案比比皆是。原因為具有最大潛在商業利益的系統(最受依賴系統、擁有大量客戶和高額利潤)常屬於棕地範疇。當認定傳統方法無法達成當前目標時，維護棕地專案的團隊會具有非常高的意願嘗試DevOps。
- DevOps成功轉型案例：
- Nordstrom百貨公司
- CSG系統國際公司
- Etsy ( 2015年成功IPO )
- 兼顧紀錄式系統和互動式系統。前者類似ERP系統，正確性至關重要，變更通常較慢。後者如電子商務系統和辦公室軟體等有所互動的系統，須對回饋快速反應。
- 從最樂意創新的團隊開始：特別是早期階段，應該把精力集中在能夠創造成功且願意承擔風險的團隊上，並以此為基礎慢慢擴大範圍。概念近似於《跨越鴻溝》一書提到的先找到創新者和早期採用者，再進行擴散。另外即使獲得高層大力支持，避免使用「大爆炸」的方式(do it everywhere)，集中火力在少數幾個嘗試性領域，確保成功，再逐步擴展。
- 若要執行上到下大爆炸式的轉型也是有可能。可參考PayPal 2012 年敏捷技術轉型，由科技副總 Kirsten Wolberg 親自主持。這種轉型需要得到最高層的支持，且必須持續不斷地追求各階段的必要成果。
- 儘早展現成果，積極發揚光大。取得初步成功後，可逐步擴大DevOps計畫的應用範圍。
- 推動革新時，如何擴大影響：此一階段執行的清單出自MIT管理學教授 Dr. Roberto Fernandez.
- 發現創新者和早期採用者：探索DevOps旅程的第一批志願者，理想上這些人受人尊重，對組織具有很大的影響力，得到他們支持更容易提高創新的可信度。
- 贏得沈默的大多數：下一階段，擴大DevOps實踐範圍，目標是建立更穩固的支持基礎。此時，謹慎避免和唱反調的人發生衝突。
- 辨識「不為所動者」：此群體為高調具有影響力，很有可能牴觸轉型計畫者。只有獲得多數人支持後才會考慮此群體。
Chapter 6 理解、可視化和運用價值流
- 接下來是充分掌握如何向客戶交付價值：需要做什麼？由誰來做？要採取哪些措施來改善流程？
“開始改善任何價值流的有效方法之一，就是和所有利害關係者一起
演練價值流程圖，幫助團隊統整出創新價值的所有必要步驟”
— Nordstorm百貨公司技術副總 Courtney Kissler
- Identity 價值流中包含的團隊成員：Product owner ( 定義系統想實現的功能)、Development、QA、Operations、Infosec、Release managers、Technology executives or Value stream managers（負責從頭到尾確保價值流所生產的價值滿足或超出客戶和組織期望）。
- 建立價值流程圖：確認成員後，下一步就是深入掌握工作如何被執行，並使用價值流程圖進行紀錄。目標不在於詳實記錄所有步驟和細節，而在於正確辨識阻礙價值流快速流動的環節，以縮短前置時間並提升可靠性。
- 應重點分析和優化需等待數週或數月的工作以及造成巨大rework的環節。
- 繪製重點
- 數小時內可繪製出最重要的那 5-15 模塊，每一塊應包含 Lead time 和 Value added time，以及由下游取用者所測量的%C/A (重工指標，下游端有多少%的時間接收到“真正可用”的工作。)
- 組織專門的轉型團隊：
- 令其獨立於負責日常運作的部門，此團隊必須負責達成明確定義的、可衡量的、系統層級的目標。ex.將「從 submit code 到 deploy 於生產環境中」此一過程的Lead time 要減少 50%。需採取措施如下
- 由轉型團隊的成員專門執行 DevOps 轉型工作
- 挑選熟悉多個領域的通才作為團隊成員
- 選擇與其他部門長期保持良好關係的人作為團隊成員
- 為團隊找一個獨立的辦公區間，盡可能促進交流，並和其他部門保持適當的距離。
- 擁有共同目標：最重要的是設定可衡量且明定執行週期的目標，通常以六個月到兩年為單位。由管理層決定目標和執行週期，並公告組織所有成員。改善目標範例如下：
- 刪減 50% 用於產品支援和計畫外工作的預算
- 確保 95% 的變更從 submit code 到版本發佈的 lead time 縮短至一周或是更短
- 維持小幅度的改善計畫：具靈活性、加快學習和迭代、更快見到有意義的成效
- 預留 20％ 改善週期來減少技術債：確保至少 20% 的時間投入到重構、自動化工作、結構優化以及非功能性需求上，如可維護性、可管理性、可擴展性、可靠性、可測試性、可部署性和安全性。
“如果組織連這「20 %的稅」都不原意支付，那麼技術債將會持續惡化，
最後消耗組織所有可用資源，導致服務脆弱不堪，無法交付功能”
— eBay產品設計資深副總 Mary Cagan
- 有趣的案例：LinkedIn 的 operation InVersion (償還技術債)
- 利用工具強化預期行為：
- 建立可共享的工作佇列，讓團隊成員清楚看見全局。避開不同工具，ex.RD 用JIRA，Operation 用 Service Now。也可使用 Slack 之類的聊天室促進團隊成員快速共享資訊、促進溝通。
Chapter 7 參考康威法則設計組織架構
- 本章節探討如何調整組織結構，實現價值流的目標。
- 康威法則 ( Conway's Law )：軟體的架構和軟體團隊的結構是一致的，更直白一點，「如果讓四個團隊開發同一個編譯器，那麼編譯器最後會有四個執行階段」。
- 案例：Etsy 開發的Sprouter技術
- 主要的組織結構分為三類：職能型(Functional)、矩陣型(Matrix)以及市場型 (Market)。此三類組織結構可做為參考 Conway's law 設計 DevOps value stream 的參考依據。
- 職能型組織：注重專業能力、優化分工或降低成本。以專業技能為中心，營運部門通常採用這種組織架構，即伺服器管理員、網管等都被劃分為獨立小組。如Google、Etsy 和 GitHub。
- 矩陣型組織：試圖結合職能型和市場型，然而組織結構通常都非常複雜。例如，一個員工可能需要向兩個或更多的經理回報。
- 市場型組織：注重迅速回應客戶需求，多為扁平化結構。成員為多職能 (如含行銷人員、工程師等），可能存在工作或人員冗餘現象。如 Amazon 和 Netfliex。
- 過度職能導向的危害：成本優化
- 執行工作者常不太理解自己工作和價值目標有什麼關聯 (因為別人要求我這樣做，我就這樣做 ) 。
- 在大規模部署等複雜活動，顯然會遞延交付週期。
- 要同時服務多個價值流 ( 多個開發團隊 ) ，需逐層溝通通報調整 priority，導致專案緩慢前進。
- 導致工作交接不善、大量重工、交付品質低落、瓶頸和延誤等問題。
- 建立以市場為導向的團隊：速度優化
- 極端情況下，要負責功能開發，測試產品，確保可用性、進行部署，支援operation。且這些跨職能團隊可以獨立運作，不需依賴其他團隊就能修復缺陷。每個團隊可以獨立地向客戶交付價值。
- 非大規模重組，反而是將工程師和其專業技能 ( operation、QA、security ) 嵌入每個服務團隊中，或者提供自助式服務平台，含配置類生產環境、執行自動化測試或部署等 。
- 如何讓職能導向有效運作？
- 雖然建議以市場為導向的團隊，但只要確保價值流中的所以人都能掌握目標，職能導向也是可以高效運轉。共同處是高度信任的文化，不同部門能有效協作，工作ㄧ
- 下圖左為「職能導向」，所有 flow 經集中式 IT 營運團隊。下圖右為「市場導向」架構，所有產品團隊能自助式在生產環境部署寬鬆耦合的元件。
 |
| source: 《精實企業》 |
- 將測試、營運和資安融入日常生活
- Ticketmaster的首席技術長 Jody Mulkey 表示：「Ops 是進攻內鋒，Dev 是負責關鍵地位四分衛或外野手。Dev 的工作是持球衝鋒， Ops 的工作則是保證 Dev 有足夠時間向前衝。」
- Facebook 曾面臨團隊始終處在永無止盡地救火狀態。最後採取能提升部署效率的措施之一就是讓所有工程師、工程經理和架構師輪流值班待命，負責各自建構的服務之 operation。這些開始對自己在價值流中的產出感同身受，對下游接手的後續團隊也產生巨大的正面影響。
- 讓團隊成員成為通才
- 在現在越來越複雜的 operation 活動中，極端情況下，職能營運組織會產生「穀倉化現象」，而導致多次交接、排隊等待進而交付時間延遲。
- 建議讓團隊成員成為通才 ( T-shaped ) 甚至更厲害的 E型人才，學習必要技能，讓他們有能力建構與運行所負責的系統，也定期讓他們在不同職位間輪換。
- 招募人才方面也著重於尋找具有好奇心、勇氣和坦承特質的人。
- 如果組織架構能夠支援小團隊獨立、安全、快速地進行開發、測試和部署，就可以提高並維持開發人員的生產力，且改善品質。 Servoce-Oriented Architecture, SOA 就具有這特徵，其由具有限界上下文 ( Bouded context ，各服務間只需透過 API 互動）的鬆耦合 ( loosely coupled ) 服務所組合。
- The "Two-Pizza Team" rule
- Amazon在轉型過程利用「兩個披薩原則」來維持小型的團隊規模－團隊所有成員人數能用兩個 Pizza 餵飽，通常為 5 - 10人。
- 這樣的限制有四個關鍵效果：
- 確保團隊對系統有清晰、相同的理解
- 限制正在開發的產品或服務的成長率
- 分散權力並實現自主性
- 帶領 “Two-Pizza team” 是讓員工獲得領導力經驗的一種方式。
- Case Study： 2015年 Target 的「API 啟用」專案
Chapter 8 將營運融入日常開發工作
- 本章主要探索實踐如何幫助開發團隊具備更強健的營運能力，創造出更多以市場為導向的業務成果，提高工作效率和生產力。
- 案例：Big Fish Games
- 原每一事業群都有專屬開發團隊，且部署新功能時需要競相爭取全組織共享的稀缺資源 —營運團隊。且使用的都是不可靠的測試和整合環境以及繁瑣的發佈流程。
- IT 營運副總 Paul Farrall 認為解決這問題的最佳方法是將營運專家嵌入開發團隊。
- 營運部門若想取得以市場為導向的成果，可以建立一套集中式的平台和工具及服務。ex.搭建類生產環境、部署管線、自動化測試工具、生產環境遙測控制台等等。開發團隊就能投注心力在建構功能，而非基礎建設上。
- 若想取得以市場為導向的成果，另一個作法是將營運工程師嵌入產品團隊，使得產品團隊能自給自足，完全負責服務的交付和支援。 ex. 迪士尼。
- 若因各種原因，組織無法為每個團隊分派營運工程師，另一種做法是“營運聯絡人”( Ops liaison)。ex. Etsy。集中式營運團隊依然管理所有環境 ( produciton and pre-production )，確保一致性。 如同嵌入營運工程師一樣，營運聯絡人也要參加團隊的stand up meeting與 retrospective meeting，且需將團隊需求納入整個營運計畫，以及需排解相關的資源競爭。
////
Part 3 -Part 6 請往這裡走 ~
Part 3：第一步工作法：暢流的技術實踐
Part 4：第二步工作法：回饋的技術實踐
Part 5：第三步工作法：持續學習與實驗的具體實踐
Part 6：整合資訊安全、變更管理和合規性的技術實踐
若有您轉貼需求，請來信討論。 轉貼時禁止修改內容及標題且保持所有連結。禁止商業使用，請註明原文標題、連結以及作者。
