DevOps的基礎知識-Part 4
流程與實踐
我們在本系列文章中提到了到 ITIL 的最佳實踐（精實和敏捷）已成為我們現在所說的 DevOps 的建構區塊(Building block)。關於建構區塊得的概念請參閱本部落格TOGAF系列文章。
在本文中，我們將進一步了討論DevOps 實踐的演變如何從 ITIL、精實和敏捷最佳實踐中產生。它們現在被列為 DevOps 的 15 項基本實踐。最後我們能夠總結支援 DevOps 的關鍵文化價值和服務管理、專案管理以及軟體開發流程和技術。
我們將會討論 DevOps 如何實踐轉型流程，利用精實、敏捷和 ITSM 加速器來解決 IT 面臨的流程設計問題。討論 15 種與文化、流程和自動化相關的非常具體的實踐，這些實踐是有效交付 DevOps 的必備條件。
關於ITSM實踐
服務管理(Service Management)是一組專門的組織能力，以服務的形式為顧客提供價值。它是將正確的資源與正確的技能結合起來，以提供客戶想要和需要的東西的能力。
服務管理是當今許多企業的重要面向，也是金融、旅遊、公用事業和零售等產業的基礎。它是一種服務，也是交付顧客價值的基礎。 因此，IT 內部某種形式的服務管理是絕對必要的。 IT 服務管理（ITSM）就是服務管理在資訊科技管理的應用之一。
DevOps 建構在現有 ITSM 框架和品質系統之上。在實施 DevOps 時，合理的假設是採用和調整現有實踐總是比從頭開始建立或發明參考更容易、更快捷。因此，DevOps 利用現有記錄框架（包括 ITIL 和敏捷）中的實踐，可以充當關鍵加速器，並提供一組定義的功能作為有效性的參考模型。
此外，DevOps 結合了精實實踐，進一步關注不斷發展和保持相關性以滿足當前和未來需求的需要。人們在採用任何新方法時犯的最大錯誤就是忘記過去的教訓。最佳實踐的建立是為了擺脫技術債和不良部署的惡性循環，它呈現的是那些忘記了過去的教訓的人可能會重蹈覆轍。
在我們快節奏的商業競爭世界中，更快地犯下不必要的錯誤可能會讓任何企業陷入失敗的漩渦。ITIL、精實和敏捷實踐代表了 DevOps 運動建立和持續發展的基礎。
為了確保持續的相關性，ITIL經歷了四個版本的迭代。 ITIL 並不是萬能的解決方案。相反，它必須根據其支援的服務和底層 IT 技術進行調整。
採用 ITIL 意味著致力於在組織範圍內轉變以服務為導向、以客戶為中心的文化，而採用 ITIL 意味著了解最佳實踐、為什麼推薦它們，然後根據組織的需求、目的和目標仔細考量它們。
在上一圖中ITIL 第三版的服務生命週期有五個階段。它們是： 服務策略(Service Strategy)，支援其他生命週期階段，並且處於中心位置。 服務設計、服務轉換、服務營運和持續服務改進，這在其他生命週期階段創造了持續改進的氛圍。
然後到了2019年，ITIL 4就發布了，而ITIL 4的核心是建立在服務價值體系上的。這意味著一切，所提供的所有服務都必須創造價值。
它可以透過服務價值體系來完成，因此我們可以了解組織和其他系統的複雜結構。所以，我們所做的每一項活動都必須專注於一個價值。
更多的ITIL介紹請參閱本部落格ITIL的系列文章。
關於精實概念
精實的概念已被應用於製造業和 IT 領域，並證明是有效的。精實思維的五個關鍵原則。
- 定義價值
- 映射價值流
- 建立流程
- 運用Pull方法
- 追求完美
定義價值是精實思維的首要原則，它解決了我們之前討論過的整個價值流和參與階段的系統性思考。定義價值意味著了解最終業務客戶價值。
映射價值流是評估價值流中是從客戶端到收到的價值的不同流程以及每個流程中的活動的原則，以評估它們是否增加了業務價值並識別任何浪費領域。 創建流程是精實的原則，它獲取價值流程圖的產出，用它來識別浪費和約束，應用Just-in-time方法，並減少高峰和低谷。
啟動”pull applies ways”來觸發流程鏈(process chain)的方法。精實使用
- WIP(work in progress)
- 限制或約束(limits)
- 視覺化管理
等流程以上來啟動pull。精實的最後一個原則是追求完美，包括系統性地、持續地消除品質差的根本原因。 精實稱之為 — 改善(Kaizen)。 與 DevOps 一樣，回饋，尤其是客戶回饋也是精實的重要組成部分。
當人們聽到精實這個詞時，他們通常會將消除浪費部分理解為縮小規模、裁員或削減預算。這不是精實的意義。 精實意味著working smarter，而不是worker harder。它是用更少的錢做更多的事，而不是用更少的錢做更多的事。
例如，亨利·福特並沒有發明汽車，但他發明了一種生產價格實惠、可靠、性能穩定的汽車的方法，徹底改變了世界，普通中產階級也能擁有這種汽車。他實現這一目標並不是透過降低汽車本身的價值，而是透過降低生產汽車的成本，簡化生產線並減少勞動力密集度。亨利福特當時並不知道他正在考慮其實精實原則。
如今，精實的核心是增加客戶價值、消除浪費、透過促進管理而不是透過命令和控制進行管理、讓所有員工參與並確保持續改進。
當我們了解變革型領導時，我們本質上是在回顧精實領導風格，而精實的許多焦點也是《DevOps 三種方式》的焦點。
關於敏捷的概念
敏捷是一系列框架和實踐的集合，它們都屬於一組特定的價值和原則。我們經常看到的＂Learn、Scrum 和 XP ＂實際上早於術語「敏捷」。
自 1990 年代中期以來，它們已在各種組織中開發和使用，但缺乏一套連貫的指導原則來整合它們及其想法。2001 年，由17 名軟體開發人員組成的小組在猶他州的一個度假勝地開會討論各種方法，其結果是《敏捷宣言》，這是一份重要文件，闡述了明確的原則和價值觀，並將他們討論的所有想法都連結起來。 敏捷宣言指定了四個核心價值：
- 個體和互動＂優先於＂流程與工具
- 作業軟體＂優先於＂全面性的文件
- 客戶協作＂優先於＂合約協商
- 回應變化＂優先於＂按照計畫
DevOps 擁有相同的價值觀並受到相同的價值觀影響。
DevOps的15個實踐
DevOps 利用精實思維和實踐，以及敏捷專案管理和 Scrum 等開發工具，進一步解決阻礙 IT 交付價值的最終約束和瓶頸 — — 混亂之牆，開發和營運之間的障礙，阻礙他們以相同的速度和相同的方向移動。
DevOps 可以加快速度。DevOps 的 15 個基本實踐對於三種方式和 CALMS 至關重要，它們支援持續交付和持續部署。這 15 個基本實踐是 DevOps 實踐流程轉型以及利用精實、敏捷和 ITSM 加速器來解決 IT 面臨的流程設計問題的方式。
1.顧客的聲音
要了解客戶的聲音，首先要了解與 ITSM 相關的效用(Utility)和保固(Warranty)概念。 品質和價值可以是許多元素的組合，但在 ITSM 中，它被描述為效用性和保固，這兩個元素都是創造價值所必需的。
效用代表功能性需求(Functional requirement)。它描述了服務的所有需求，這些需求符合目的(Fit Purpose) — — 服務是否做了它應該做的事情（What the service does)?服務的效能是否得到支援？ 是否存在限制其運作的限制？ 效用性是服務滿足特定需求的功能。
保固代表非功能性要求。 它描述了適合使用（Fit for use）的服務的要求 — 該服務實際上是否已交付？ 保固意味著服務在客戶需要時可用，並以適當的容量持續、安全地運作。 ITSM 框架，尤其是 ITIL領域中，是需要非常聚焦於確保良好的保固。缺乏良好的保固被認為是 IT 內＂技術債和脆弱性＂的主要原因。
隨著精實、敏捷和 DevOps 等更快的開發方法的發展，如果不遵循平衡的方法來提供效用性和保固，就會存在巨大的風險。現在我們已經知道了業務價值、最終客戶並從他們的角度理解價值，而這就是顧客的聲音與精實的關係。它涉及了解端到端客戶體驗並認識到最終客戶是定義價值的人。
精實概念建議組織需要考慮兩種類型的客戶。
- 那些實際使用他們的產品或服務的人
- 那些在價值流中處於下一個位置的人
收集客戶聲音可以透過多種方式完成，企業直接使用問卷或可以依靠外部研究，但在精實中定義價值時，考慮以下這四個完整問題非常重要。
- 誰是客戶？
- 客戶想要的是甚麼？
- 什麼為客戶增加價值？
- 客戶願意支付什麼費用？
定義客戶的聲音應該是我們理解業務價值的核心。我們必須了解客戶偏好 — “Must haves、Nice to haves與驚艷時刻(WoW)”。 精實將我們的注意力集中在必須must haves的項目上，並且它們對品質至關重要。 對品質至關重要意味著這些要求是客戶的絕對需要，而不是想要。
對品質至關重要的要求實際上是價值，而不是增加價值。 根據精實原則，組織應優先考慮並專注於對品質價值至關重要的專案。 如果我們沒有提供對品質至關重要的價值項目，那麼我們就沒有真正提供價值。
2.業務關係管理
業務關係管理旨在建立並維護 IT 與內部業務利害關係人之間的關係。業務關係管理識別業務價值並確保 IT 部門理解並能夠交付它。 然而，業務關係經理可能會創建一個額外的穀倉，因為他們的存在可能會阻止業務和 IT 部門相互溝通。
相較之下，如果業務關係管理實施得當，它可以減少充當中間人的角色，而更多地扮演促進者的角色，介紹人員並確保雙方了解彼此的目的和目標，從而實現協作。
3. 精實流程優化
與任何品質系統相關的三個關鍵宣告是：
- 未定義的內容無法控制
- 不受控制的事物是無法測量的
- 無法量測的事物就無法改進
價值流程圖能讓我們進行定義、控制並最終進行量測。它確保採取必要的步驟，以便我們可以開始改進，這就是流程優化的起點。精實將所有作業活動分為三種不同的類型。
- 增值(Value-Add)作業增加了顧客眼中的價值。 增值工作不包括促進該作業的必要流程。這是客戶真正體驗到並認為有價值的唯一作業。 增值作業是客戶願意付費的活動。增值作業是需要被優化的。
- 必要的非增值(Necessary Non-Value-Add)作業在顧客眼中不會增加價值，但卻是必須要做的工作。例如，客戶不會將負責招募和培訓人員的HR部門或伺服器上的 IT 作業視為對他們直接有價值的部門。 但這項作業對於增值項目發揮作用並存在。 我們應盡量最小化必要的非增值作業，例如機房建置可以外包給雲端業者。
- 非增值（Non-Value-Add）作業不會為客戶或企業增加價值，所以應該要移除。
精實將浪費稱為Muda — 需要檢查並消除價值損失，因為它浪費時間、精力、精神和資源。Muda 指的是流程中妨礙（或約束）且不必要的面向。 下圖呈現了精實所識別的七種浪費。
- 團隊之間的轉移或交接（戰略層面）
- 庫存－任何部分完成的工作積壓（戰略層面）
- 移動－流程中的任務切換、中斷與干擾 （戰術層面）
- 等待 — — 主要是等待批准或決策（戰略層面）
- 過度處理－重新學習被遺忘的知識（戰術層面）
- 過度生產－創造超出需求的功能（戰略層面）
- 缺陷/重工 — — 過程中的品質問題（戰術層面）
精實也確認了另外兩類價值損失 — — Mura 和 Muri。
Mura 的意思是不平均，而不是平均和不規則，Mura 是七種浪費(除了未利用的人才)中任何一種存在的原因。換句話說，Mura會驅動並導致Muda。
例如，在生產線中，產品在組裝過程中需要經過多個工作站。 當一個站點的量能大於其他站點時，我們會看到以生產過剩或等待這一些形式出現的浪費堆積。
精實生產系統的目標是平衡工作量，從而避免不均勻或浪費堆積
透過Just-In-Time Kanban system和其他限制生產過剩和庫存過剩的pull based strategies可以避免 Mura。Just-In-Time system的關鍵概念是在正確的時間以正確的數量交付和生產正確的零件。
Muri(無理)的意思是超出自己能力範圍的負擔、過度、不可能的不合理的事。
Muri 可能是由 Mura 引起的，在某些情況下，是在流程中過多去除 Muda（浪費）引起的。
當機器或員工使用超過 100% 的能力來完成一項作業時，Muri 也會存在。或以不可持續的方式，Muri 在一段時間內可能會導致員工缺勤、生病和機器故障。 標準化作業可以透過設計工作流程來平均分配工作量，並且不會給任何特定員工或設備帶來過多負擔，從而有助於避免Muri現象。
4.價值流程圖(Value Stream Mapping)
了解價值流以及我們在價值流中的位置對於有效領導、企業治理和管理效率至關重要。如果我們檢視一下流程就會知道，所有流程都有輸入和輸出。價值流用於查看此特定情況。
與流程(Process)相比，價值流程圖無法複製。所謂流程是指在實現特定目標的一組結構化活動。 流程採用一個或多個已定義的輸入並將其轉換為已定義的輸出。而精實為我們提供了另一個與流程價值流相關的術語。
價值流程圖提供了端到端業務價值交付的整體視圖。價值流程圖對於精實和 DevOps 至關重要。 在對流程進行價值流程圖分析之前，我們將無法視覺化工作流程並識別限制和浪費。
完成價值流程圖繪製後，我們就可以開始檢視已確定的衡量標準和問題領域，以確定是否存在可以消除的浪費或需要解決的限制。
專用於活動的input在發布output之前遵循多個步驟。 整體週期時間是流程中實際作業從開始到結束的總體時間，由我們和客戶定義。 流程時間是實際建立產品或服務所花費的總時間，這就是增值活動。
等待時間是等待下一步開始所花費的時間。此等待時間可能涉及檢視或關鍵資源不可用。 時間是一種非增值活動（Wait Time = Non Value Add Activity），等待被認為是一種浪費。總體週期時間包括處理時間和等待時間，在處理時間期間對單元進行操作以使其更朝向output，在等待時間期間工作單元等待採取下一個操作。
價值流映射最常用的術語和討論是前置時間（lead time），它是從初始觸發(Initial Trigger)到實際收到價值的輸入和輸出之間的時間。價值流程圖提供基於清晰測量的有價值的資料，我們可以使用這些資料來優化工作流程。
更多的價值流程圖說明可參閱本部落格"ITIL4 — 發展價值服務體系"、"ITIL4 評估與規劃"及其系列文章。
5.知識管理
在 DevOps 環境中，知識管理實踐最重要的考量因素不是特定知識管理系統的具體結構，而是共享，這是 C.A.L.M.S 縮寫中的單字之一，也是 DevOps 的關鍵原則和概念與三種方法和協作連結在一起。 DevOps 的知識管理就是利用實踐來打破穀倉。所以知識管理的目的有三:
- 分享觀點、想法、經驗和資訊。
- 確保在正確的地點和時間提供觀點、想法、經驗和訊息，以做出明智的決策。
- 透過減少重新探索知識的需要來提高效率。
知識管理側重於為什麼知識在組織內不共享的人類面向，而不是將其視為流程問題或技術問題。
要理解缺乏共享知識作為人類問題與流程或技術問題之間的區別，我們要使用 DIKW 模型，它幫助我們理解缺乏"資料或資訊與缺乏知識或智慧"之間的區別。
資料只是客觀事實或觀察結果，或者只是沒有意義且在應用整體脈絡之前無法使用的符號。在人類利用資料做某件事之前，資料是毫無用處的。例如，考慮文件管理系統中的文件清單或不附加其他資訊的客戶清單。
資訊與資料的區別在於它是有用的。它是被賦予整體脈絡或目的的有組織或結構化的資料。再次檢視客戶清單的例子，但現在想像一下，不僅是客戶姓名，還添加了電話號碼或地址，並且它們排列在清單中。現在資料變得相關，因此它是資訊。
使資料和資訊易於存取並將它們合併到系統中是很容易的。我們只需概述一種以某種有組織的方式向人們提供資訊的方法，並確保它根據需要進行更新。 我們每天都會遇到對資訊進行編碼的系統 — 只需想想 Google 搜尋或智慧型手機中的聯絡人清單即可。
資訊回答了Who、What、When或Where的問題。知識(Knowledge)更難定義，知識是資訊，但由個人經驗、各種洞察力或直覺構成。知識不僅是嵌入系統中的內容，而且還涉及人們的綜合和處理以確定如何(How)使用它。
再次回到客戶清單的例子。知識是我們對客戶清單中電話號碼的人的理解。 此外，它還涉及我們知道可以利用該資訊做些什麼。當您我們擇客戶清單中的任何人時，我們可以在發送簡訊和通話之間進行選擇，並使用我們必須「知道」的資訊，這有助於我們確定如何處理這些資訊。
知識(Knowledge)涉及經驗、技能和專業知識。智慧是層次中的最終成就，也被稱為啟蒙(enlightenment)。
它不僅是對「How」的理解，也是對「Why」的理解。 智慧需要更高層次的背景和關係思考。它不僅來自於實務經驗，或許也來自於倫理考量或價值判斷或美感價值。
再次回到客戶清單範例。 在打電話給某客戶之前，我們可能會想現在是否是打電話的最佳時機。 想想這種思維與將客戶清單視為沒有其他背景脈絡的資料的簡單行為有多大的差距。
接下來，從組織與IT單位角度考慮DIKW模型(資料、資訊、知識、智慧)。有資料或資訊儲存和存取的地方就足夠了嗎？
我們如何從資料和資訊共享的環境轉變為真正知道知識和智慧被每個需要它們的人共享和理解？在考量 DevOps 的知識管理時，我們需要考量這些問題。一些知識管理系統可以在 DevOps 環境中使用，它們支持共享文化並將知識嵌入最需要的地方。
知識管理系統、協作軟體技術（例如 Slack 或內部 wiki）的一些例子是 DevOps 運動所採用的一些協作工具。知識資料庫是儲存資料和資訊的地方，例如文件管理系統或文件共用工具。它們仍然被認為是有用和必要的。
指導是確保人與人之間知識和智慧轉移的重要系統。跨職能團隊是 DevOps 結構的關鍵面向。早些時候，我們理解到 DevOps 鼓勵在跨職能團隊中嵌入不同的技能組合，以便輕鬆傳遞知識和學習機會。 知識研討會等資訊蒐集有助於分享知識。 知識管理的另一種形式是使用視覺化管理工具，例如看板(Kanban)。
6.視覺化管理
視覺化管理旨在讓組織的"控制和管理"盡可能簡單。這種做法涉及在顯而易見的情況下使用視覺控件，而不是基於文字的控件，因為視覺控件更容易解釋、記住並牢記在心。 看板和其他視覺化工具就是這種實踐的例子。
看板出現於 20 世紀 40 年代，是豐田精實製造最初發展的一部分。 裝配線工人將展示顏色編碼的看板（即卡片），以通知下游合作夥伴對零件或其他工作的需求。這種方法增加了透明度和溝通，並使流程標準化。
到 2000 年代中期，看板已應用於知識工作 — 服務和 IT。 其核心目的源自於製造業 — 流程的可視化與最佳化。事實上，看板對於 IT 來說更為重要，因為與製造業不同，IT 所做的大部分工作都是抽象的，否則可能是看不見的。
透過使不可見的變得可見，看板提供了一種收集持續改進所需指標的寶貴方法。看板提供了一定的自由度，可以以最適合企業的方式組織指標，它們的樣態將取決於我們的價值流和工作流程。
基本的看板將有多個通道，標有其繪製的流程中的步驟。 例如，To Do、Doing、Plan和Done。
更複雜的價值流或看板(如下圖)可能包含額外的水平通道作為來源指示器，以顯示多個團隊沿著相同價值流工作等資訊。 然後，卡片被放置在看板上，代表沿著價值流從左到右、從開始到結束移動的項目。 這些卡片通常採用顏色編碼，顏色代表不同的事物，例如項目類型、緊急程度等，但每個人都應該清楚地理解它們。
卡片可能會表明誰在做工作、時間長度和其他相關詳細資訊，並根據其當前狀態將它們放置在適當的通道中。
進行中的工作限制也將顯示在看板上的特定列中，最有可能透過卡片量能來呈現(也就是每個垂直通道中可以置放的卡片數量)，以便每個人都可以清楚地看到瓶頸在哪裡以及何時無法將項目添加到通道中。
也就是說看板允許每個人查看WIP(Work In Progress)並對其設定限制，以便工作量永遠不會超過系統完成它的能力。 看板確保可視化的每一列只能容納一定數量的任務或工作項目。 這種方法可以清楚地了解作業積壓或限制發生的位置。
推式(Push)系統與拉式(Pull)系統
在拉式系統中，產品或服務是根據客戶需求拉動整個流程的。 例如一家咖啡店，咖啡師在開始輪班時不會先煮二十杯咖啡，而是等待顧客到來。想當然耳地，咖啡必須使用拉式系統來製作。
每一杯咖啡都是由顧客的訂單觸發的。拉式系統與推式系統相反，推式系統根據預測的需求推動產品或服務通過流程。
如果咖啡師煮了 20 杯咖啡，這是否是他們時間最有效利用的方式？ 按訂單製作咖啡可以節省時間。如果咖啡師只接受 15 個訂單，他們就會浪費更少的時間再製作五杯咖啡。
只有當我們設定需求(Demand)而不是回應需求時，預測(Forecasts)才會如此準確。它還增加了靈活性。這意味著，如果咖啡師急於喝茶或卡布奇諾，他們不會突然手邊有錯誤的物品，也沒有任何需要的東西。 拉式系統減少流程中的浪費。
拉式的概念對 IT 來說也很有意義，因為客戶價值出現在發布後部署流水線的末端。如果我們花時間或精力致力於最終沒有交付給客戶的任何事情，或者最終客戶實際上並不需要的事情，那麼我們就沒有交付價值。 根據精實概念，這是非增值的， 是浪費。
看板體現了拉式概念。 如果我們要推送並提交代碼，它將觸發自動建置。推式的好處是不會浪費時間等待。然而，可能還有另一個構建(built)正在跑，這種盲目的Push將導致兩個構建都失敗。
如果我們是要拉取，一旦可以進行更多工作，自動化的正當程序將定期檢查新的提交。 等待執行此任務會浪費時間，但根據檢查頻率，可以將其最小化。
下一階段真正需要做的時候就可以取得下一個作業，從而最大限度地減少或消除風險。 對於 100% 在現場作業的團隊來說，實體白板可能非常有效，而且對於某些人來說，這可能是一種觸覺偏好。 然而，對於遠距工作的團隊或覆蓋多個部門或區域的董事會來說，虛擬看板可能是必要的。
虛擬看板(例如Trello或Leankit)還可以提供其他優勢，例如與其他工具整合或產生報告或量測的能力。 看板應該以相同的方式發揮作用，無論它們是虛擬的還是實體的。 看板的設定方式並不重要，重要的是它的使用方式。 它需要有效地讓每個使用它的人快速了解任何問題或疑慮並採取行動糾正它們。 不管我們怎麼設定。 對於所有利害關係人來說，一致性和易於理解至關重要。 應該對誰使用它以及誰維護和更新它有明確的責任。
7.Agile Scrum
要理解敏捷專案管理，首先需要回顧傳統的瀑布式專案管理。傳統上，IT 使用瀑布技術進行專案管理(PMP這一類屬於瀑布式)。它們之所以被稱為瀑布，是因為它們向前流動，在任何時候都不會向後移動。瀑布式方法假設專案的規格(或規範)從一開始就是正確的。 範圍是在專案開始時定義的，然後一切都從那裡開始「進行」。
敏捷是一種適應性(adaptive)的專案管理方法。敏捷會宣告專案一開始的需求預計會隨著專案的進展而變動和發展。 敏捷專案管理使用持續迭代(iterations)來適應和合併這些變化。
與瀑布方法不同，敏捷專案管理在每次迭代完成後重新定義範圍。 Scrum 將這些迭代稱為衝刺(Sprints)。 敏捷專案管理支援第二種方式，即內建回饋( feedback built in)。
每次迭代後重新定義範圍，我們可以確保客戶在每次迭代後感到滿意。而且完全有可能在這個序列中的第三次或第四次迭代中，客戶就會對產品感到滿意，並且甚至不再需要進展到最終版本。
人們有時不知道自己真正想要什麼，直到他們看到它為止，這符合人性，因此盡快給他們一些東西可以看到比逐步實現最終結果所產生的浪費更少。
敏捷專案管理也支持三種方法(流程、回饋與持續實驗)，因為它促進實驗。它支援一種結構，在這種結構中，如果嘗試，就能夠快速失敗並快速適應改變方向。
此外，敏捷透過迭代和適應性來擁抱變化。在沒有設計回饋的情況下建立過多的內容既危險又浪費。創建正式且簡短的回饋循環可以提高參與度並支持 DevOps。
雖然對許多人來說，敏捷和 Scrum 現在是同義詞，但 Scrum 自 20 世紀 90 年代初以來就被用來管理複雜的產品開發。Scrum 是一個適應性強的流程框架，可以在其中應用各種流程、工具和技術。它以迭代方式促進產品開發，從而實現頻繁發布並獲得最高品質的結果。
Scrum 建立在三個基本支柱（如上圖）之上，而且是關於透明度的。這意味著讓負責結果的人員盡可能了解整個過程，並讓每個人都就完成的標準定義達成一致。
Scrum 是關於學習，而不是預測（predicting）。
Scrum 是關於調查的（inspection）。 在 Scrum 中，在整個專案中頻繁且一致地執行進度和工件的檢查，並收集回饋以確保一切仍處於正軌。
Scrum 是關於適應的(adaptation)。 進行調查時，如果流程的任何面向會導致缺陷、錯誤或品質下降，則會立即進行調整。Scrum 中有一些正式的活動來確保適應。
下圖中我們可以看到 Scrum 的所有角色(Roles)、事件(Events)和工件(Artifacts)。
Scrum 中有三種角色：
- 產品負責人(Product Owner)：
這個角色負責產品價值的最大化。這是透過建立和維護產品積壓(backlog)、與客戶、最終用戶和開發人員的持續溝通來完成的。 - Scrum Master：
這個角色確保完全正確地遵循 Scrum 框架，這需要指導、訓練和解決問題。 - 開發團隊：它是一組開發解決方案的技術、自組織和跨職能專家。
Scrum 事件 —
規定的事件用於使用 Scrum 來建立規律性，並最大限度地減少 Scrum 中未定義的會議的需要。 所有事件都是有時間限制的事件，因此每個事件都有最長持續時間。衝刺一旦開始，其持續時間就固定，無法縮短或延長。
每當活動的目的達到時，剩餘的活動就可以結束，確保花費適當的時間，而不會在過程中浪費時間。除了衝刺本身（它是所有其他事件的容器）之外，Scrum 中的每個事件都是檢查和調整某些內容的正式機會。這些活動是專門為實現關鍵的透明度和調查而設計的。
未能將這些事件之一納入其中會導致透明度降低，並失去檢查和調整的機會。工件有助於規劃、監控和控制項目，同時保持一切透明和可見。
工件：
- 產品積壓（product backlog)是最終產品中可能需要的所有內容的有序清單。
- Sprint backlog：從產品 backlog 中選擇要在衝刺中交付的項目。 增量（Increment）是專案中迄今為止完成的所有產品積壓項目的集合，直到某個衝刺結束。
理解這一點非常重要。這裡完成(Done)的定義是什麼? 完成的定義是對一項作業被視為完成意味著什麼的共同理解。以下我們可以看到產品積壓的範例。 以及使用者故事如何進入產品待辦事項清單。與客戶和關鍵利害關係人一起的產品負責人將確定工作的優先順序，並且首先完成價值較高的專案。下圖右邊，我們可以看到如何將使用者故事分解為任務。
除了 timeboxed events之外，還有一個持續的快速使用 Scrum 項目，稱為產品待辦事項梳理或產品待辦事項精煉（ product backlog grooming or product backlog refinement）。這是檢視和修改產品積壓項目的行為，通常涉及向其添加詳細資訊、估計和順序。
產品負責人負責對項目排序，開發團隊負責估算。 此活動與 Scrum 五個事件之間的主要區別在於，Scrum 事件都是有時間限制的，但精煉是在整個衝刺期間發生的持續活動。估算活動不應佔用開發團隊超過 10% 的時間。
這裡需要注意的是，在敏捷中，開發人員是指為最終解決方案的產生做出貢獻的任何人。它可以指分析師、解決方案設計師、UI設計師、程式設計師、測試人員等。
Scrum 的核心是衝刺，一個月或更短的時間框，在此期間創建「完成」、可用且可能可發布的產品增量。 在整個開發工作中，衝刺最好有一致的持續時間。 新的 Sprint 在上一個 Sprint 結束後立即開始。
每個衝刺都可以被視為一個期限不超過一個月的產品。 與專案一樣，衝刺也用於完成某些事情。 每個衝刺都有要建造的內容的定義、指導構建、工作和最終產品的設計和靈活計劃。 Sprint 僅限於一個日曆月。 當衝刺的範圍太長時，正在建構的內容的定義可能會改變，複雜性可能會增加，風險也可能會增加。 衝刺透過確保至少每個日曆月針對衝刺目標檢查和調整流程來實現可預測性。
Sprint 也將風險限制在一個日曆月的成本範圍內。每個 Scrum 專案都是一組衝刺 (sprint)。 衝刺是其他四個事件、開發工作和產品積壓維護的容器。
Sprint Planning是 Sprint 中的第一個事件。 Spring 團隊計劃他們將在衝刺中交付的項目以及交付方式。
每日Scrum看板（如上圖） — 衝刺計畫一完成，開發團隊就開始致力於衝刺的目標。在衝刺期間，開發團隊每天召開一次會議。可能需要15分鐘來協調接下來24小時的工作。該會議稱為每日例會。 在衝刺結束之前，開發團隊向客戶展示衝刺的結果並接收回饋。這個會議稱為 Sprint Review。
在 Sprint 評審之後和 Sprint 結束之前，開發團隊會召開內部會議來評審 Sprint，並用它來改善下一個 Sprint 的流程。這些活動旨在實現關鍵的透明度、檢查、規律性和適應性。
我們應該使用這些具有固定目標和最長持續時間的預定義會議，而不是通常會浪費我們時間的臨時會議。基於同樣的原因，Scrum 使用精實原則的視覺化管理原則。 在 Scrum 中，視覺化管理工件被稱為資訊輻射器（information radiators），它們支援許多 Scrum 工件和事件。衝刺待辦事項清單板使衝刺目標可見(如上圖)，並追蹤正在進行或已完成的工作項目。
燃盡圖非常簡單且功能強大，它們一目了然地傳達了許多訊息。儘管它們可能有其他格式，但它們應該始終傳達相同的細節。線的向下斜率稱為速度，該行顯示團隊在一次衝刺中可以完成的工作量。
此衝刺燃盡圖用於隨後的衝刺規劃會議，以了解開發團隊的進度並將正確的工作量帶入衝刺，以及規劃整個專案。發布燃盡圖顯示了專案開始時的專案以及每個衝刺完成的專案的進度。
產品待辦事項清單看板使專案目標可見，並追蹤移至頂部的工作項目和已完成的工作項目。 讓產品待辦事項清單清晰可見是許多 Scrum 環境所忽略的，但這是一個常見的錯誤。在持續時間較長的專案或一系列衝刺中，視覺化管理可確保開發團隊不會感到與大局或正在取得的進展脫節。
8.左移（Shift Left ）
DevOps 提倡回饋的力量，即第二種方法。
與傳統的在開發流程中間進行品質保證測試不同，左移思維鼓勵在開發早期並在整個週期中持續進行測試和回饋的移動。這種方法使組織能夠更好地適應和回應客戶的需求和變化，並有助於及早發現和糾正錯誤。
我們可以透過強調單元測試（unit testing ）和整合測試（integration testing）來向左移動。 持續測試是 DevOps 實施的一種左移策略，此策略確保在開發過程的早期就建立品質。
我們還應該能夠看到品質第一方法和敏捷專案管理如何透過在較短的迭代後允許回饋而不是在測試開始之前要求完成產品來轉移測試。
到目前為止所討論到的一切，我們應該能理解 DevOps 將品質放在第一位。 它是為了確保我們發布的產品不僅能夠快速或廉價地發布，而且還具有內在的品質並提供價值。 傳統上，這種方法是發布具有潛在缺陷和錯誤的產品，隨著時間的推移，這些產品可以變得更好。
如上圖呈現，很明顯，組織一開始就有許多不同的功能和特性，但整體品質較低。 傳統觀念認為這種方法是時間和發布日期與品質之間不可避免的權衡。
傳統思維計劃早期版本都需要修復，假設更高的品質需要時間，並且隨著時間的推移，功能和品質都會提高。品質第一的模式不採用傳統方法。它指出最高品質是絕對要求。然後，權衡(trad-off)就變成一組有限的初始特徵。
這種方法主張限制範圍和功能，但提供高品質的產品。這是滿足非功能性需求的主張，然後隨著時間的推移引入更多特性和功能。在這種情況下，敏捷實踐非常重要。我們可以在衝刺中新增功能。 透過將新功能新增為衝刺，我們還可以透過更早測試並在每次迭代中獲取回饋來將測試和回饋轉移到左側，而不是僅在最終版本上進行測試和取得回饋。
透過遵循品質第一的方法，我們還可以更靈活地對開發階段進行排序，並按照客戶偏好的進行排序的提供新功能。這種方法是承諾和超額交付，而不是相反。
品質保持不變。 然而，每增加一個新功能，功能就會變得更好。
測試驅動開發（test driven development）的好處如下。
- 程式設計師確切地知道其他人對他們的期望，並且可以更有效率地工作。
- 鼓勵程式設計師創建盡可能簡單的程式以通過測試。
- 這種方法在敏捷環境中是可取的，因為我們不想浪費時間創造完美的東西，因為我們需要的只是一個足夠好的功能解決方案。
9.變更管理
如果變更管理做法不正確，那麼在採用敏捷和 DevOps 時，業務單位和 IT單位都可能將變更管理視為為一種官僚做法，並且可以繞過它。
然而，繞過變更管理將是一個導致技術債的錯誤。 由於其價值，變更管理是最早採用來支援 DevOps 的領域之一。組織應利用 ITIL 提供的標準變更模型和簡化的正常變更模型。
ITIL 對幾種特定類型的變更進行分類，並提供特定的變更模型來應對組織中的變更。 三種變更類型是
- 標準變更
- 緊急變更
- 一般變更
標準變更風險低且是通用。標準變更有一個特定的相關程序或作業指示，在先前的實行中已被證明是有效的。標準變更是預先授權的，例如一般正常的OS的補丁。
為回應重大事件或緊急需求而需要立即實施的變更是緊急變更，例如資安類的緊急修復。
一般變更是指非標準或緊急變更的變更，它們指的是必須遵循完整變更管理流程的變更。一般變更需要全面的變更管理檢討，它們以變更請求或 RFC(Request for Change) 形式提出，由變更諮詢委員會 (CAB) 審核，並由變更經理批准或拒絕。
在下圖中，我們可以看到傳統的ITIL變更管理審核流程，對於一般變更來說非常緩慢。接下來，對於與 DevOps 相關的一般變更，我們需要了解如何適應 ITIL 的變更管理模型。使用標準 ITIL 變更管理模型是最好的方法，因為更傳統的變更管理模型通常無法像敏捷和 DevOps 要求的那樣快速運行。
我們是否需要 CAB 或變更流程來評估與 DevOps 中正常變更相關的 RFC？答案是不用。而是由產品負責人和開發團隊負責批准下一個衝刺的產品積壓專案， 所以衝刺規劃(Sprint Planning)就會形成了討論變更的基本 CAB。
產品負責人應建立適當的 RFC 並提交。我們也不需要授權和監控測試建置階段，因為不需要監控 Sprint 進度。Scrum 教練和開發團隊是自我管理的，授權和監控部署也不需要 CAB 或變更流程。產品所有者、客戶、其他利害關係人和開發團隊審核並接受已完成的作業增量。
Sprint Review 形成了用於討論變更的基本 CAB。 產品負責人應該更新相應的 RFC，或者變更經理可能會在審核期間在場。 要執行傳統變革管理流程的所有任務，我們需要按步驟一路進行。 由於涉及的任務，這可能看起來是一個漫長的流程。 但這並不意味著不應該有任何變更管理流程。 變更管理流程是必要的，因為它可以最大限度地降低風險。
這就是 DevOps 困境的本質 — 變更的實施使我們重新專注於混亂之牆。
維運單位被告知要發布一些內容，但維運部門的測試表明，該變更尚未準備好投入生產環境。開發和營運並未就解決方案進行協作。
ITIL變更管理與核可流程:
- 變更請求（次要、重要、主要 RFC）
- 變革經理決定優先順序和緊急程度
- 標準變更的預先核准的變更清單（次要 RFC）
- 變更經理向 CAB 報告。
- CAB 一般變更授權（重要和主要 RFC）
- 更改排程
10. 組態管理(Configuration Management)
在 ITIL 中，組態管理的範圍首先考慮技術配置、單一組件設定的配置（例如軟體程式設定）、伺服器如何設定作業系統、驅動程式、硬碟分割區等。
ITIL 將它們稱為配置項CI(Configuration Item)。 這種組態管理對於 DevOps 至關重要，因為隨著技術的進步，虛擬化也在進步，一切都變成了代碼。 DevOps 依賴每次都以相同方式自動設定組件的腳本，並減少人為錯誤。 因此，組態管理這一ITIL 流程對於 DevOps 至關重要。
組態管理對於自動化至關重要，它涉及維護基礎設施中每個組件當前狀態的知識。DevOps 也使組態管理更進一步，並擴大了範圍，包括開發和測試以及生產過程中存在的整個環境的配置。
基礎設施即程式碼(IaC)是基於一些實踐，這是使用定義檔案並確保所有設定都在可執行定義檔（例如 shell 腳本）中定義。由於所有一切都是代碼並留存於原始碼控制中，以便記錄每個配置和變更以供審核。
在 DevOps 環境中，組態管理包含自動化基礎架構交付和操作的實務和工具。工具用於執行以下操作：
- 基礎設施模型
- 持續執行所需的配置
- 修復主要和輔助基礎設施配置之間隨時間的意外變化或「配置漂移(Configuration drift)」差異
使用 DevOps 的組織最常使用各種可用工具來自動化其基礎設施。 一些最受歡迎的工具是 Ansible 、Puppet、 Chef。 這些工具用於將配置政策應用於雲端資源、應用程式、系統或直接應用於硬體
DevOps強調小變更而不是大批量變更，這使得更容易發現錯誤並在需要時恢復。實施能自我記錄的系統和流程，而不是SOP文件中的指令讓員工執行。持續測試系統和流程，使我們能夠快速發現基礎架構配置中的錯誤。 並保持服務持續可用。
透過將基礎架構視為代碼，可以在 DevOps 中實現以Ansible、Puppet和 Chef 等工具以及自動化設定管理的轉變，可以使用開發人員使用的常規工具和流程進行管理。 他們使用版本控制、代碼審查、自動化測試、小型部署等。 IaC有時也稱為「programmable infrastructure」。
利用IaC能力的自動化組態管理是 DevOps 的基礎，因為它可以提高速度，同時也使變更更安全，並允許以更低的風險升級應用程式和系統。 根據 Martin Fowler（2016）的說法，IaC是基於以下一些實踐。
- Using Definition Files
- Versioning Everything
- Emphasizing Small Changes Rather Than Big Batches
- Implementing Self Documenting Systems and Processes
- Testing Systems and Processes Continuously
- Keeping Services Available Continuously
11.發布與部署管理
軟體開發和 IT 維運中的發布管理是一個用於管理整個軟體交付生命週期（從計劃、部署、測試到部署）的系統。
對於 ITIL 和 DevOps 來說，這是一般流程。 然而，DevOps 鼓勵在整個交付過程中進行更多的協作和可見性。
- 縮短回饋循環並鼓勵更簡單、更快的發布管理。
- 自動化配置管理和IaC支援自動化發布管理並實現更頻繁的部署。
只有透過成熟的組態管理和IaC的自動化，才能實現持續交付和持續部署。 在DevOps中，發布管理還包括”規劃、調度和控制”軟體開發和交付流程。
但在 DevOps 中，開發人員和 IT 維運人員從流程的開始到結束都在進行協作 — 允許更少、更短的回饋循環和更快的發布。DevOps 團隊對他們在代碼上提供的服務承擔責任，並承擔On-Call的責任。
由於軟體開發人員和 IT 維運人員參與整個交付生命週期和待命狀態，因此無論是在發布過程中還是發布後，都可以更快地偵測和解決相關事件。
當我們討論 DevOps 的發布和部署管理時，我們主要談論開發流水線、持續交付和持續部署。 DevOps 部署流水線是一組自動化流程和工具，可讓開發人員和維運專業人員緊密合作，建置代碼並將其部署到生產環境。
雖然 DevOps 流水線可能因組織而異，但它通常包括建立自動化/持續整合、自動化測試、驗證和報告。它還可能包括一個或多個手動點，需要人為干預才能允許代碼繼續進行。
持續交付是持續整合的擴展，因為它在建置階段後自動將所有代碼變更部署到測試和(或)產品環境。這意味著除了自動化測試之外，我們還擁有自動化的發布流程，並且可以隨時透過點擊按鈕部署應用程式。
理論上，透過持續交付，我們可以決定每天、每週、每兩週或任何適合我們業務需求的方式發布。但是，如果我們確實想獲得持續交付的效益，則應該儘早部署到生產環境中，以確保發布小批量，以便在出現問題時易於排除故障。
持續部署比持續交付更進一步。 這種做法會透過生產流程所有階段的每個變更都會發布給我們的客戶。沒有人為干預，只有失敗的測試才會阻止新的變更部署到生產中。
持續部署是加速與客戶的回饋循環並減輕團隊壓力（因為不再有發布日）的絕佳方法。 開發人員可以專注於建立軟體，他們在完成工作幾分鐘後就會看到自己的作業上線。
而這些實踐如何相互關聯呢?簡而言之，持續整合是持續交付和持續部署的一部分。持續部署就像持續交付，只不過發布是自動發生的。
即使有了成熟的發布和部署管理流程，DevOps 也提供了實現發布管理的新技術和方法，可以幫助減少長期困擾 IT 的壓力、高機率的錯誤以及發布頻率低的問題，它還應該提高速度和可靠性。
我們可以使用一些技術：
- IaC實現組態管理自動化。 自動化並利用IaC的組態管理支援我們的發佈管理流程，並透過自動化安裝和設定軟體的流程來幫助提高可靠性並減少錯誤。它使發布過程更具可重複性，因我們可以在測試和生產環境中重複執行腳本。腳本幫助組織了解伺服器的配置方式，版本控制意味著他們還可以追蹤一段時間內的變更。 定期重建伺服器。
- DevOps 也鼓勵利用VM定期重建伺服器。 能夠輕鬆刪除和重新建立伺服器可以減少配置偏差(Configuration drift)的影響，並迫使組織確保其基礎設施代碼包含有關如何配置伺服器的準確詳細資訊。這種方法還可以減輕災難復原的壓力。
- 實施零停機部署 — DevOps 鼓勵零停機部署。 實施零停機部署意味著找到在不影響最終使用者的情況下發佈軟體的方法。當組織定期重建伺服器時，這種方法至關重要，因為否則所需的停機時間將是不可接受的。
組織可以將變更部署到他們不使用的伺服器。 他們可以根據需要重建伺服器，如果出現問題，任何人都不會受到影響。這種方法意味著組織不再局限於在正常時間之外進行部署，以盡量減少停機的影響，也不必擔心更改對最終使用者的影響。
然後，當他們確定環境按要求作業時，他們會將使用者流量重新導向到新的伺服器集群。 這些伺服器成為新的環境，然後它們可以使用先前的運作環境作為待命環境來再次開始這個過程。請記住，DevOps 鼓勵自動化部署，但發布應始終由手動決定。
藍綠部署(Blue Green Deployment)是區分部署和發布的另一種方法，並確保一個部署可以自動化，即使另一個部署無法自動化。
12.事故管理
上圖是一個傳統的事件管理模型。該模型運作良好，可以輕鬆適應 DevOps，但需要事故處理程序時要讓開發團隊參與進來，讓他們對環境中引入的任何錯誤或不良代碼負責。當出現問題時，開發團隊需要承擔更多責任。
責任的增加也強化了開發團隊確保這種情況不再發生的可能性。DevOps 事故管理減少了穀倉心態並鼓勵協作，它也鼓勵實驗和學習，這是第三個方式的核心。
請務必注意 ITIL 分類為事故(Incident)與問題(Problem)之間的差異。根據 ITIL事故是:
- 事故是指服務的意外中斷
- 尚未影響服務的服務組件的故障
ITIL的問題則是:
- 問題是一個或多個事故的根本原因
- 建立問題記錄時通常不知道原因，問題管理流程負責進一步調查，這需要在RCA(根本原因分析)流程中發現根本原因。
13.問題管理與改善(Kaizen)
上圖為傳統的ITIL問題管理流程。我們也可以看到，所有問題都在變更管理的幫助下解決。與經過調整的事故管理流程一樣，在 DevOps 環境中，開發團隊應該更參與問題的分類和優先排序。
Kaizen是一種結構化的方法，以一種態度或心態逐步解決問題並改善流程，鼓勵組織各個層級的每個人尋找改善想法，如果可能的話，可以輕鬆快速地實施這些想法。Kaizen旨在成為組織日常文化和消除浪費的日常流程的一部分，同時也鼓勵實驗和生成性 DevOps 安全文化。
DMAIC 模式可以在組織致力於 Kaizen 和持續改善時提供指導和釐清。它代表定義、量測、分析、改進和控制。
- 定義是讓所有相關人員都了解問題。
- 量測數據並收集事實。
- 分析是分析數據，建立影響因素，找出根本原因，定義假設。
- 改進候選解決方案
- 控制實施，確保改進過程的可持續性和穩定性
14.持續服務優化
DevOps 是圍繞著"持續一切"的概念而建構的。我們甚至在許多名稱中使用它 — 持續交付、持續測試、持續整合 — 想要改進軟體交付系統和流程中形成瓶頸的地方是一個值得追求的目標。這種實踐基於ITIL的持續服務改善生命週期，也基於精實原則：追求完美。
這項原則將幫助我們理解標準化對於 DevOps 的重要性。標準化作業為每個利害關係人的每個流程建立了最佳且最適合目標的方法和順序。 作業標準必須不斷發展和改變，它是穩定的基礎。作業標準消除了主觀性。 如果沒有標準，就不可能了解變更是否是改進。
ITIL 服務生命週期的最後階段是持續的服務改善。到目前為止，我們應該已經在這一個系列文章中反覆回顧過這一點，正如在 DevOps 和三種方法的各種實踐和流程中所討論的那樣，之前我們談到了業務和 IT 價值交付問題。
作為解決問題的解決方案，持續改進至關重要 — — 作為跟上業務需求價值、競爭正在興起和世界不斷變化的步伐的一種方式。
ITIL 持續服務改善利用稱為 CSI Register 的工具來為持續改善工作提供結構和可見性。它用於按時間範圍、努力程度、緊迫性、影響和優先記錄和分類來改進機會。
敏捷 Scrum 產品待辦事項清單還可用於提供結構，並可與 CSI 的概念整成，然後規劃迭代持續改進衝刺。
ITIL 提供了持續服務改進的工具，這些工具對於實現 DevOps 非常有價值，並且體現了 CALMS 和三種方法(文化、實踐與自動化)的關鍵原則。 它要求我們不僅要不斷改進，還要對改進進行衡量，並以策略性的方式進行改進，並將注意力集中在那些限制和影響最大的領域。
當與精實和敏捷的流程和實踐以及持續交付整合並以支援 DevOps 的方式實施時，ITIL 服務生命週期以及 IT 服務管理的流程和實踐將非常有價值。
更多的服務持續優化可參考本部落格"ITIL4 持續改進"一文，及其相關系列文章。
15.反脆弱(AntiFragility)
反脆弱的原則實際上是基於由於壓力、失敗和其他影響而導致能力、韌性或穩健性的增加。
韌性指的是組織從"事故和中斷"事件中恢復的能力。反脆弱性的不同之處在於，它將事故和破壞視為學習的機會，它不僅涉及恢復，還涉及災後的蓬勃發展。 因為破壞而變得更強大。
混沌工程(Chaos engineering)是在分散式系統上進行實驗的學科，目的是建立對系統承受生產環境中動盪條件的能力的信心。
Netflix 與Chaos Monkey 及其Simian Army 的合作使該公司開創了混沌工程的概念，這是一門專注於實現反脆弱性並確保即使在面對緊急情況或意外事件和中斷時也能保持穩定性的學科。
該軟體演變為雲端測試工具的集合，用於模擬公司在生產環境中可能面臨的其他潛在故障。他們將這組工具稱為“Simian army”，其中包括 Conformity Monkey 等，它會探索不遵守最佳實踐的實例並在生產環境中關閉它們。
Janitor Monkey，在雲端環境中搜尋未使用的資源並進行處理。 還有 Chaos Gorilla，它模擬整個AWS AZ的中斷。2016 年，Netflix 發起了 Chaos Kong，這是一種模擬的分散式阻斷服務或 DDoS 攻擊，對 Netflix 的反脆弱性進行了終極考驗。
