讀書筆記｜DevOps Handbook: 打造世界級技術組織的實踐指南(Part 3 - Part 6 實踐篇與心得）

本書的六大章節，分別為

Part 1：三步工作法 

Part 2：從何處開始 

Part 3：第一步工作法：暢流的技術實踐

Part 4：第二步工作法：回饋的技術實踐

Part 5：第三步工作法：持續學習與實驗的具體實踐

Part 6：整合資訊安全、變更管理和合規性的技術實踐

以下是 Part 3 - Part 6  的書摘筆記。

/////  

Part 3：暢流的技術實踐

“ 奠定部署管線的基礎、 

實現快速可靠的自動化測試、 

啟動和實踐持續整合、 

自動化並降低發佈風險 

以及建置降低發佈鋒線的架構。”

— 五項暢流的技術實踐

• 為了使工作快速可靠地從開發階段流向營運階段，必須落實在價值流每階段使用 Pre-prod 環境，且要求以自動化進行佈建。

• 部署pipelines的核心目標就是讓團隊成員能透根據版本控制系統中的資訊，重複佈建整套生產環境。

• 通用的佈建機制：如開發環境、測試環境和生產環境。

• Puppet Lab 在 《2014 年 DevOps 現況報告 》中，將營運團隊使用版本控制列為 IT 效能和組織績效的五大預測因子之一。所有變更應一一被記錄在版本控制系統中，幫助查找問題以及 roll back。版本控制不僅僅只涵蓋 code 也應包含環境的可配置參數。

• 重新解釋 "完成"的定義：不只是開發完功能正確的程式碼，還包括在每一個迭代週期結束時，已經在 Pre-Prodction 環境中整合且測試了可運作和可交付的程式碼。

• 綠色交付 (Push on Green) ：Practice in Google，當developer 提交程式碼，就會自動運行測試套件，其包含了成千上萬個自動測試用例。只有當提交的程式碼通過自動化測試後，才會自動和動到主幹，得以被部署到生產環境。另外，希望「退回前一版本」的操作是很容易的。

• Continuous integration ( CI ) : 通常指將多個程式碼分枝持續整合到主幹中，且確保都通過單元測試。

• CI+：持續整合 ( CI ) 同時被要求在 pre-production 中運行，並通過整合測試和接受度測試 ( by 《 Continuous Delivery 》一書作者 Jez Humble 和 David Farley ）。 

• 「部署管線」( Deployment pipeline ) 確保所有check-in 版本系統的程式碼都是以自動化方式佈建，且在 pre-production 中進行測試。如此一來，才能讓開發人員在submit code後，得到立即的反饋，得以修復錯誤。

• 有了部署管線的基礎後，為了建立實踐 CI，還需要以下三個面向。

• 全面可靠的自動化測試套件，驗證軟體是否處於可部署狀態。

• 一種在驗證測試失敗時，可以「中止整條生產線」的文化

• 開發人員的工作模式是在主幹上以小批量提交變更，而非在生產週期很長的功能分枝上工作。 

• 依照速度快慢，自動化測試主要分為以下幾類

• 單元測試：獨立測試每一方法、類別或函數。確保程式碼按照開發人員的設計運行。

• 驗收測試：測試整個application，確保各個功能模組按照設計正常運作，且沒有破壞以前正常的功能。驗證功能能滿足使用者期待，不僅僅是程式設計師的預期。

• Smoke test：通常是只針對整個應用，執行一組成熟且完整的驗收測試。

• 整合測試：確保應用能和與生產環境中的其他應用和服務正確互動。整合測試通常是脆弱的，應減少整合測試，多進行單元和驗收測試。

• 任何通過自動化測試的佈建版本，都可以繼續用在探索性測試和其他形式的手動測試，或是效能測試等等。

• 想要確保可靠的自動化測試，最有效的一個方法是透過「測試驅動開發」( test-driven development, TDD ) 和「驗收測試驅動開法」( acceptance test-driven development，ATDD)，在日常工作中編寫自動化測試。

• 《 2015 年 DevOps 現況報告 》顯示，基於主幹的開發模式 ( trunk, or master, mainline) 能帶來更高的生產力、更好的穩定性，甚至提高工作滿意度和降低職業倦怠率。

• Case study：2012年 Bazaarvoice 的 CI 實踐。 

• 不同發布模式：

• 基於環境：藍綠部署模式 ( Blue-green deployment pattern ) 、金絲雀 ( Canary release pattern ) 發佈以及叢集免疫系統發布模式。

• 基於 application ：

• 透過功能切換開關

• 暗度發佈 ( Dark launch ) ：讓功能暫時不被看見、無法使用。2008 年 Facebook 運用 dark launch 的方式發布聊天功能

• 持續交付( continuous delivery ) 與 持續部署 ( continuous deployment )

• 持續交付 

• 所有開發人員在主幹上進行小批量工作，或者在短時間內存在的功能分之上工作，定期向主幹進行合併，且始終讓主幹維持可發佈與按需執行一鍵式發布。在引入任何 regression 錯誤時，能快速的得到回饋，而立即加以解決

• 適用於幾乎所有部署與發佈場景

• 多數於 Amazon 與 Google的團隊採用持續交付實踐

• 持續部署

• 在持續交付的基礎上，由相關人員自助式地定期向生產環境部署優質的佈建版本。甚至每當開發人員 submit code 時，就觸發一次自動化部署。 

• 更適用於交付線上的 web 服務

• 持續交付是持續部署的先決條件，如同持續整合是持續交付的先決條件。

• 架構原型：單體架構 ( Monoliths ) VS. 微服務 ( Microservices )

"沒有一個可以適用所有產品和規模的完美架構。 

任何架構都能滿足特定的一組目標，或一系列需求和條件"      

            --  from Randy Shoup

• 在產品生產週期的早期階段，單體架構通常是最佳的選擇。

• 由下表中可看出單體架構適合創業公司，而數百個開發團隊的公司較適合微服務。

• 轉型經驗：2002 年 Amazon 的演進式架構。

• 扼制模式 ( Strangler application ) : 具體內容包含以 API 封裝已有功能，按照新架構實現新的功能，僅在必要時調用舊的系統，所有服務都透過版本化 API 進行存取，也稱為版本化服務或不可變服務。可參考 2011 年 Blackboard learn 的經驗。

Part 4：回饋的技術實踐

“建立能發現並解決問題的遙測( Telemetry )系統、 

分析遙測資料以便預測故障和實現目標、

啟動回饋機制以安全地部署程式碼、 

將「假設驅動開發」和「A/B 測試」整合到日常工作、

建立評閱和協作流程，提高現有工作品質”      

—五個回饋技術的實踐

• 《 2015 年 DevOps 現況報告 》顯示高績效團隊解決生產故障的速度是平均水準的168倍，中等績效團隊的平均修復時間 ( Mean time to recovery，MTTR ) 以分鐘為單位。

• 監測框架

• 需確保對所有正在建構和營運的應用建立充分遙測資料。

• 不同層級的日誌：除錯 ( Debug )、資訊層級 ( Info )、警告層級 ( Warn )、錯誤層級 ( Error ) 以及致命層級 ( Fatal ) 

• 資訊輻射體 ( information radiator )：敏捷聯盟定義為：「術語源自豐田生產系統。圖表、圖示與其他在團隊辦公室、走廊或其他辦公室公開展示的資訊，讓所有看到的人能夠知道必要的資訊：自動化測試次數、速率、事故報告、持續整合狀態等。」

• 公開透明地以 information radiator 來溝通問題，並詳細展示正在進行的變更。

• Case study: 2011 年LinkedIn 建立自助服務指標 ( InGraphs )

• 充份而完整的遙測資料需涵蓋以下指標

• 商業層級：如交易訂單數量、營業額、使用者註冊數量、轉換率、A/B測試結果等。

• 應用程式層級：事務處理時間、使用者響應時間、應用程式故障、新使用者數、登入次數等。目標不僅要確保健康狀況，還要評估組織商業目標的實踐情形。

• 基礎架構層級：如 Web 伺服器運送量、CPU附載能力等。

• 使用者端軟體層級：含應用程式的出錯和閃退等。

• 部署管線層級：包含管線狀態、變更部署前置時間等。

• 異常檢測 ( outlier detection ) ：Netflix 團隊使用的一項統計法，用於檢測「可能導致效能顯著下降的異常運行狀況，例如管線無法正常流動等問題」。Netflix 先自動計算出「當前正常值」，然後辨識與之不符的節點，將他們從生產環境中移除。

• 分析生產環境度量指標，最簡單的一種統計法就是計算平均值/平均數和標準差。

• 建立更好的警示方式：可藉由提高訊號雜訊比、專注發現差異值或異常值。例，每天未經授權的登錄次數比平均值大了三個標準差就發出警告。當資料為高斯分佈時，約只有0.3%的資料會觸發警告。非高斯分佈的資料，可採用其他異常檢測技術，如 smoothing、快速傅立葉轉換、 KolmogorovSmirnov 檢驗。

• 需要監測哪些？ 最簡單的做法是分析在近期 ( ex. 30 天內 ) 所遭遇最嚴重的事故，並據此建立一個遙測清單，更即時、快速檢測和診斷問題，並清楚確認是否實施了有效地修復措施。 

• 開發與營運共同承擔值班工作。ex. facebook 

• 讓開發人員追蹤工作對下游的影響，含使用者體驗 。

• 軟體生命週期中營運學習往往太晚開始，導致生產軟體難以穩定運行。也會不斷發生系統管理員只待短期就紛紛離職，生產環境總是故障，部署總是十分痛苦等事件。

• Google實踐：先讓開發團隊在生產環境中管理自己開發的服務，之後才能交由集中的營運團隊接手管理。保持開發團隊的完整性，在專案後也不解散團隊，以進一步了解生產問題。

• 服務發佈規範和要求可能包含以下內容：

• 缺陷計數和嚴重性

• 警告的類型和頻率

• 監測的覆蓋率

• 架構部署

• 部署過程

• 生產環境的整潔

• Google的「服務回傳機制」( service handback mechanism )：針對生產環境中的現有服務，用於保證營運人員不會被困在無法支援的服務中。

• 當服務回到開發人員手中，營運部門就從提供生產支援的角色轉變為開發部門的顧問，幫助開發團隊再次將服務變成生產環境就緒狀態

• 對營運團隊來說像是減壓閥

• 有助於減輕技術債

• Google 實踐：

• 網站可靠性工程師 ( Site Reliability Engineer, SRE )：營運工程師的職能定位

• 開發人員能燃必須在生產環境中管理他們的服務至少六個月以上，然後產品團隊才有資格分配到 SRE 人員。

• 發佈新服務的兩個關鍵階段，兩套安全安全檢查：交接就緒審核 ( Launch readiness review, LRR ) 與上線就緒審核 ( Hand-offs readiness review, HRR )。

• 在任何服務公開給使用者前接收生產流量之前，必須進行 LRR，且簽字接收。由產品團隊自行執行並上報。

• 服務轉為營運管理狀態後 ( LRR 數月後 )，則執行 HRR。

• LRR 和 HRR 審核清單相當雷同，但 HRR 更加嚴格。

• 通過 LRR 或 HRR 流程的產品團隊都會分配到一名 SRE 人員，幫他們了解和實現需求。

• 建構一項功能之前，我們應該嚴肅的問自己：「應該建構它嗎？理由是？」接著以成本最低、速度最快的實驗，透過使用者研究來驗證設想的功能是否能產生預期的業務成果。

• A/B Testing：也被稱為線上控制實驗 (online controlled experiments) 或拆分測試 ( split test)。對網站的訪客展示兩種網頁版本的其中一種。一為控制組 ( A )，另一個則是實驗組 ( B )。根據使用者後續行為的統計分析，可以判斷兩者結果是否存在顯著差異

• 實施變更前，和傳統的外部變更批准相比，善用如GitHub 的 同儕 review 流程，可加速且有效降低風險。GitHub 建立的 Pull Request 流程也應用於「 GitHub Flow 」此一實踐上。

• 豐田生產系統的核心理念之一是「最了解問題的人，就是那些離問題最近的人」。 《 2014年 DevOps 現況報告 》的一項主要發現是，高績效組織更依賴同儕評閱而非外部變更批准。

• Giray 在Twitter 上提到：「 請工程師來審閱十行程式碼，他會找到十個問題。請他審查五百個程式碼，他會說看起來都不錯。」維持小批量規模的原則，也適用於程式碼審查。

• 2010 年 Google 的程式碼審查：

• 符合程式語言規範的程式碼可讀性（強制編碼樣式）

• 指派程式碼分支的所有權，保證一致性和正確性

• 在團隊中提倡程式碼的透明度和貢獻度

• Pair programming :由兩個軟體開發工程師同時在同一台工作站上的工作的開發方法。另一個模式是 「測試驅動開發」（ test-driven development, TDD )，一位寫程式碼，另一位同時編寫自動化測試。相關研究顯示，寫程式所需時間約多15% ，然而無錯誤的程式碼量卻由70% 增加到 85%。

Part 5：持續學習與實驗的具體實踐

“將學習融入日常生活工作、 

將局部經驗轉化為全局改善、

    為組織學習和改善活動預留時間 ”      

—三個持續學習與實驗的具體實踐

• 「韌性型組織」( resilient organization )：能夠熟練地發現問題，解決問題，並在整個組織中提供解決方案以擴大驚豔的效果。具有自我恢復的能力。

• Netflix 的「搗亂猴」( Chaos Monkey )：不斷隨機刪除生產伺服器，來模擬 AWS 環境故障。這麼做的原因在於，希望所有的工程團隊習慣在故障發生的情況下持續工作，使得服務能夠在沒有人工干預的情況下，自動恢復正常。此 Practice也讓 Netfliex 成為「2014年 Amazon EC2 伺服器大規模重啟」災害事件中，極為少數幾乎沒有遭受business impact 的企業。

• 學習型文化的先決條件之一是，當事故發生時，對待事故的反應要「公正」。以學習的角度出發，看待錯誤、報錯、失誤、過失等問題。

• 當事故和重大事件發生時，應該在問題解決後舉行「不指責的事後分析」，也就是對事不對人。Scrum 實踐上也常採用的 Retrospective。且儘可能廣泛公開事後分析會議結果，讓個案學到的經驗轉化為適用於整個組織的學習和改善。

• 重新定義失敗，鼓勵評估風險。《 2014 年 DevOps 現況報告 》證明，高效能 DevOps 組織會更頻繁地失敗和犯下錯誤，這不但是可以接受的，也更是組織需要的。

• Peter Senge：「對組織來說，唯一一種永續競爭優勢，就是比對手更快的學習能力」

• 「演練日」( Game Day ) ：特別災難恢復演練，其目標為幫助團隊模擬和演練事故，讓團隊具備實戰能力。做法為計畫一個災難性事件，例如 data center 掛掉。接著，給團隊準備時間來消除所有的單點故障，並建立必要的監控程式和故障切換程式等，並在演練日執行各種演習。透過這麼做，開始暴露系統中的「潛在缺陷」latent defects。

• 如何在組織中不斷累積學習經驗？ 可參考以下方法

• 將自動化工具整合至聊天室

• 與其將專業知識寫到 Word 文件中，倒不如將完整的各種標準和流程轉化為一種更方便執行、更容易重複使用的形式。甚至在原始程式碼中保存這些知識，讓人可搜尋使用。

• 建立全組織共享的單一原始程式碼庫，不只只有原始碼也包含其他資料文檔與工具。ex. google

• 自動化測試紀錄和交流實踐

• 為 operation 編寫非功能性的需求

• 美國零售商 Target 的「DevOps 道場 」（ DevOps Dojo ) 

• 「 30天挑戰」讓內部團隊在一個月內與專職 DevOps道場教練和工程師一起工作，目的是解決長期困擾他們的內部問題，且在30天內進行突破。與道場教練密切合作—規劃、工作，並在為期兩天的衝刺活動後展現成果。

• 「快閃建構」（ Flash Builds ) : 讓多團隊聚在一起，參與一次為期一到三天的活動，目標是在結束時交付 MVP 或一種功能。

• 「開放實驗室」：每兩週舉辦一次，任何人都可以來道場和道場教練交談、參加成果演示或接受培訓。

• 償還技術債：

• 舉辦為期數天或數週的「改善閃電戰」，此時不允許進行任何功能開發。改善內容可著眼於程式碼、環境、架構、工具等等任何一個問題點。

• 其他例行活動與術語「春季/秋季大掃除」 （ spring or fall cleanings)、「反轉佇列工單週」 （ticket queue inversion week)、「駭客日」 （Hack days ）、「黑客松」（ hackathons ) 和「 20%的創新時間」（20% innovation time ) 

Part 6：整合資訊安全、變更管理和合規性的技術實踐

• DevOpsSec ： 將資訊安全工作整合到軟體開發生命週期的各個階段裡的實踐和原則。

• 相關措施 

• 使安全成為每個人工作的一部分

• 將安全整合到缺陷追蹤和事後分析

• 使預防性的控制程式碼整合到共享程式碼庫中

• 將安全性整合到部署管線中

• 保證應用程式的安全性: 

• 可參考 OWASP 發佈的指導原則，ex. Cheat Sheet

• Case study: Twitter 的靜態安全測試，他們將靜態程式碼分析整合到 Twitter 的建構過程。經過數年，約將漏洞發現率降低 60%。  

• 將安全性整合到監控流程，以便快速檢測和恢復

• 整合部署活動和變更審批流程

• 降低對責任分離的依賴性

////// 一些想法 /////

• 心目中的 2 YES ＆ 2 NoNo of DevOps

• 需要觀察什麼？為什麼需要 ? for business? for system？有什麼樣的遙測 ( Telemetry )資料有所幫助？要怎麼有效的拿到這些資料？怎麼build in 進去產品/功能？拿到之後怎麼看？能不能好好的解讀？怎麼根據這些去做改善？整個feedback loop 要怎麼串接暢通？另外，每一部分的 Telemetry的成本是什麼？值得嗎？ ( 不要陷入為了有很多 data 而去建置不必要的 telemetry )

• 每一個部門/組織/團隊都有自己現有的狀態和進度，ex. 可能有的部門有CI ，還沒有CD，有的團隊全部都有。理解歷史背景，對事不對人，在有限的專案資源下，選擇團隊內以及相關 stakeholders 最有共識且最有 Value 的部分先做，一步一步的漸進改善。

• 出來跑都是要還的，雖然話說還的不一定是自己(誤)。技術債 ( Technical debt ) 最好還是定期還。在溝通技術債償還計畫時，練習思考 “償還此技術債所帶來的價值”，甚至是商業價值，將其提出來，將更有利於爭取資源。話說最近就在還技術債中...

• 浪費( Waste )：在投入resource去開發前，先和stakeholders ( Product owner, PM and so on ) 確認是否有買家要用，是否這個時間點還能解決了客戶的某個pain point，可帶來價值。

• 回到現實世界，看看手上的專案相關服務，如何讓它們更加有韌性而較不那麼脆弱？首要的事是？

• 不同組織型態都有相對應的成功案例可以參考，ex. 職能型的有 Google、Etsy 和 GitHub，市場型的有Amazon 和 Netflix。沒有唯一最好，也不需執著一定要哪一種，只有價值流中的成員知不知道目標和自己在做什麼才是重點。

• Dev 和 Ops 是該為同一個 team 還是不同 team? 前陣子和專案中的 leader們有一起簡單討論過，因為目前開發的部分很重，先由 team member 輪流值班兼顧。持續觀察狀況。

• 對於讓團隊成員成為通才這件事，Peggy抱持著正面態度，舉例來說，去年底開始安排讓部門同事們往 "solution engineer with threat knowledge" 這塊靠近。另外，根據過去經驗，想要讓專案更順利，除了培養通才外。另外，在每一個domain 或重要環節，至少要有一到兩位相對應具有精深知識和專業的工程師在那。專才搭配通才， Project 就可以跑的更順利。不過與其強調通才這一點，個人認為是否有快速學習的能力以及具有彈性願意調整此兩項更加的重要。

• 建立信任且願意說真話的文化。這邊也想來個感謝。團隊內有好幾位優秀的 members 在發現有問題或擔心有問題的時候，願意提出來討論，且同時也會提出possible solutions。 (雙手合十)

• VSM 實作的部分本書著墨不是那麼多，看完內心還是有些疑問....之後再找時間去多瞭解。

///

 有興趣的朋友可參考Peggy之前整理的兩篇讀書筆記

• Part 1：三步工作法 (筆記)
• Part 2：從何處開始 (筆記）

原創文章，若有您轉貼需求，請來信討論。 轉貼時禁止修改內容及標題且保持所有連結。禁止商業使用，請註明原文標題、連結以及作者。

讀書筆記｜DevOps Handbook: 打造世界級技術組織的實踐指南(Part 2: 從何處開始）

農曆假期還沒結束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：整合資訊安全、變更管理和合規性的技術實踐

若有您轉貼需求，請來信討論。 轉貼時禁止修改內容及標題且保持所有連結。禁止商業使用，請註明原文標題、連結以及作者。

讀書筆記｜DevOps Handbook: 打造世界級技術組織的實踐指南(三步工作法)

趁著農曆假期，再次把這本前陣子就拜讀完的經典書悠閒地翻閱一次 。將感興趣的部分整理成筆記，也打算拿來以後提醒自己以及定期反思用。

本書書名是“DevOps Handbook”，可看出很適合遇到卡住的點時，拿來翻閱參考用。

另外書厚度約350頁，沒時間看的朋友也可以加減參考。

本書分成六大章節，分別為

Part 1：三步工作法

Part 2：從何處開始

Part 3：第一步工作法：暢流的技術實踐

Part 4：第二步工作法：回饋的技術實踐

Part 5：第三步工作法：持續學習與實驗的具體實踐

Part 6：整合資訊安全、變更管理和合規性的技術實踐

///// 以下是 Part 1 的書摘筆記 /////

• Value Stream Mapping (價值流程圖) 

• 起源為製造業，為豐田精益製造(lean manufacturing) 生產系統框架下的一種用來描述物流和信息流的形象化工具。    
• 目的是辨識和減少生產過程中的浪費。Reduce "Work in process, WIP" & rework 



Source: https://wiki.mbalib.com/zh-tw/%E4%BB%B7%E5%80%BC%E6%B5%81%E7%A8%8B%E5%9B%BE

• 對照到科技產業：

“ The process required to convert a business hypothesis into a technology enabled service that delivers value to the customer. ” 

              “以科技轉化商業構想，向客戶交付價值所需的流程。從需求提出到開發、測試、部署、發布、營運整個的過程” 

• Value stream 始於工程師（含開發、QA、IT營運和資安人員）向版本控制系統提交一個變更，結束於這個變更在Production環境中成功運行，為客戶帶來價值，並產生有效回饋和監控資訊。

• Deployment Lead time (部署前置時間）

• 本書重點之一，A subset of whole value stream。

• Lead time(前置時間)：從需求提出到需求被滿足的整個週期，也通常是客戶真正體驗到的時間。

• Process time: 從開始工作到工作結束。不包含in queue waiting time

• 重點擺在縮短前置時間。

• 在複雜組織中常見的、耗時數個月的科技價值流（下圖）。(好複雜XD)

• DevOps目標：部署前置時間只需要數分鐘。
• 達成目標的關鍵行為：小批量程式碼變更、自動化測試、探索測試、模組化、高內聚、低耦合架構...

• 三個關鍵指標：Lead time 、Process Time以及重工指標( %C/A)

• %C/A：下游端有多少%的時間接收到“真正可用”的工作。

• The Three Ways(三步工作法)

• 第一步：The Principle of Flow (暢流原則)

• 第一步是讓工作具有可視化，可透過大家耳熟能詳的看板(Kanban) 或者Sprint計畫板，讓目前的task位處於哪個狀態一目了然。

• 限制再製品數量(WIP, work in process)可幫助辨識阻礙快速流動的問題，另外同時處理多任務會造成更漫長的處理時間。

• 每一次工程師的code Check in 盡量維持小規模，更快的檢測出錯誤，減少重工。

• 盡量透過減少交接次數、自動執行作業以及調整組織結構，讓團隊不需依賴他人就可以獨立為客戶提供價值。

• 辨識系統中的constraint：根據經驗，通常依序要改善以下約束點。
• 環境佈建
• 程式碼部署
• 測試準備和執行
• 過度耦合的組織架構
• 開發部門或產品經理有可能是以上問題解決完後接下來的約束點（要盡可能提升個人和團隊的生產力）

• 浪費和困境的類型：半成品、多餘加工、不被需要的功能、任務切換、等待、motion(如工作交接、資訊需要過多轉移溝通和釐清)、瑕疵、家常便飯的救火、非標準化或手動作業。

• 第二步：The Principle of Feedback (回饋原則)

• 在問題發生時立即察覺：目標包含建立自動化機制建構、整合與測試流程，同時搭配遙測技術，以監控每一個組件在 production environment 的運行狀態。

• 聚集並解決問題，建構新知識：建立等同“豐田安燈索(Toyota Andon Cord)”和相對應的蜂擁式對策(Swarming)，同時建立讓人可以在出現差錯時勇於拉動 Andon Cord 的組織文化。一但拉動Andon Cord，所有人必須蜂擁而上共同解決問題。

                         Source: Andon system from https://medium.com/serious-scrum/andon-processes-can-help-your-team-value-fire-prevention-over-fire-fighting-23fdeee504f5

• 將品質意識推進至源流：利用Peer reivew來確認變更可以按照設計方式運行。盡量將過去由只有QA霍伊安部門才可執行的Test自動化，Developer可隨時依需求執行這些測試，確保品質。

• 為下游工作中心提供改善活動：精實法則認為最重要的消費者是接續我們下一階段的人。藉由設計完整的作業流程來優化下游工作中心。注重Quality at the source。

• 第三步：The Principle of Continual Learning and Experimentation 持續學習與實驗原則

• 激發學習與安全的組織文化：問題發生時採行一種“不怪罪任何人的事後驗證(blameless post-mortems)”，快速釐清原因，在改善系統方面取得最佳對策與共識，防止問題再度發生，加快檢測和復原速度，此做法可以建立《第五項修煉》中的學習型組織。下圖由左到右分別為病態型組織、官僚型組織以及賦生型組織，以賦生型組織型態為最佳．

• 將日常工作的改善制度化：比日常工作更重要的就是“改善”日常工作( Lean IT, Mike Orzen)。刻意排定時間解決技術債、修復瑕疵，重新建構與改善程式碼和開發生產環境，將修復問題視為日常生活的一部分。

• 將局部發現轉化為全域改善：建立“不怪罪任何人的事後驗證”報告、組織共享的open source，讓這些改善局部系統而產生的新知識可被在全組織內流通以及被查詢。

• 在日常工作中注入韌性模式：

• 低效能製造業組織運用大量囤貨、增加緩衝區、購買更多資本設備和生產人員等方式緩解生產中斷。而高效能組織則透過持續改善日常作業流程，不斷引入緊張局勢來提升績效，同時強化組織韌性。

• 在科技價值流中，可嘗試縮短部署前置時間、增加測試覆蓋範圍、縮短測試執行時間。可舉辦Game day演練大規模故障應變或 Netflix 著名的“搗亂猴”在生產環境中隨機殺死程序和運算server。

• 由領導者強化學習文化：

• 領導者必須深刻認知學習和有效解決問題的珍貴價值。比照科學實驗方法，明確指出欲解決的問題、解決對策的假設、測試假設的方法、對於結果的詮釋，以及下次iteration如何運用。

• 領導者在指導組員時，可提出引導式的問題。
• 你的最後一步是什麼？發生了什麼？
• 學到了什麼？
• 現在的狀況是？
• 下一個目標條件是什麼？
• 你目前正克服什麼障礙呢？
• 下一步打算怎麼做？
• 預期結果是什麼呢？
• 何時可以檢驗成果呢？

(好的開始是成功的一半，下一篇來看看要怎麼開始DevOps....）

////// Reference //////

• https://wiki.mbalib.com/zh-tw/%E4%BB%B7%E5%80%BC%E6%B5%81%E7%A8%8B%E5%9B%BE
• Andon system: https://medium.com/serious-scrum/andon-processes-can-help-your-team-value-fire-prevention-over-fire-fighting-23fdeee504f5

若有您轉貼需求，請來信討論。 轉貼時禁止修改內容及標題且保持所有連結。禁止商業使用，請註明原文標題、連結以及作者。