DevOps的基礎知識-Part 2

主要原則與概念

13 min readApr 12, 2024

在本文中，我們將討論 DevOps 的關鍵原則和概念。我們將會檢視CALMS 的含義，並了解其重要性是支撐 DevOps 的關鍵支柱和概念。另外，我們還將討論三步工作法(流程、回饋與持續實驗)的重要性以及Full-Stack DevOps的範圍。

本文最後會讓我們理解 DevOps 的基本概念、原則和範圍，包括支援 DevOps 運動演進和出現的三步工作法和加速器，例如精實和敏捷，並總結文化、 IT 在嘗試以正確的"品質、速度和成本"提供服務時所面臨的架構和技術障礙。以及為什麼在現代企業中實施 DevOps 時會面臨挑戰。

C.A.L.M.S 是一組縮寫，最初由 John Willis 和 Damon Edwards 於 2010 年提出。隨後Juz Humble 對它進行了改進，以便更好地理解支撐 DevOps 的主要支柱和概念，即"文化、自動化、精實、測量和共享"。 C.A.L.M.S 對於 DevOps 實行至關重要且非常核心。

文化(Culture)是指對當今定義組織和 IT 的價值觀、信念和心態需要轉變以支持 DevOps 舉措的理解。
自動化(Automation)相信幾乎任何事情都可以自動化，手動可重複流程應盡可能自動化。
精實(Lean)強調精實價值體系和方法論中的原則，以降低流程複雜性、消除浪費並簡化工作流程。
測量(Measurement)重點在於測量一切和建立可見且透明的流程的重要性。
共享(Sharing)包含了開發和維運之間協作和溝通的主要概念，使他們能夠有效地整合他們的作業努力以實現共同的目標。

而DevOps的六種原則為:

以客戶為中心的行動：勇於行動、創新。
以終為始的思維：產品和服務思維、工程思維、協作。
端到端的責任：實踐我們的責任與理念，提供績效支持。
跨職能自治團隊：T 形人才，技能互補。
持續改進：如果有問題，就多做，快速失敗。
盡可能實現一切自動化：提高品質、最大化流量。

三步工作法

第一種方法:流程(Flow)

第一種方法的目標是確定各個部分如何組合在一起，了解哪些東西正在從一個團隊移動到另一個團隊，為什麼它們會移動，以及將產品交付給客戶的整體流程中將會有哪些步驟。

第一種方法著重於理解作業流程，作業如何從開發轉移到維運，然後從業務的職能領域轉移到客戶 — 從左至右，從一個團隊到另一個團隊。

流程是關於識別前面討論的限制。了解整體作業流程瓶頸在哪裡以及生產力最慢的地方，以便我們可以優先考慮改進以產生最大的影響。

當我們理解工作流程時，我們可以清楚地識別導致混亂之牆的障礙並消除它們。隨著時間的推移，流程可能會變得緩慢、低效且不必要地變複雜。當這種情況發生時，這會帶來額外的挑戰，並因為出現瓶頸而進一步減慢速度。

高德拉特博士在 1984 年的商業小說《目標》中介紹了約束理論(如下圖)。該理論指出，沒有任何複雜的系統或流程能夠比其最有限制的瓶頸或約束更有效或更強大。

換句話說，任何工作流程都不能比最慢的步驟更快。該理論幫助組織識別並專注於最慢且效率最低的一個領域，因為該領域限制了整個系統。當組織應用該理論並解決問題時，他們會提高整個企業體系的進度。

流程作為 DevOps 的第一種方式。理想的流程意味著作業從一個人轉移到另一個人，從一個團隊轉移到另一個團隊，不受限制地高速流動。 精實價值觀和精實流程聚焦於約束和流程概念。

作業如何從頭到尾跨越穀倉和團隊，以及如何精簡到讓每個人以相同的速度作業。精實(Lean)中可用的主要工具之一是價值流圖(value stream mapping)。這意味著我們需要不斷衡量績效，利用數據關注特定問題領域或確定浪費發生的位置及其原因。

然後，領導者可以對工作流程進行適當的改進。重點是各種文化變革、新流程或實踐，以及旨在增加流程流量的技術和自動化方法。我們需要進一步檢視以了解一些增加流量的做法，這可以用提高作業的透明度和可見度來進行。

在 IT 領域，作業通常是無形的，因為與製造業不同，庫存和生產不涉及實體商品。作業很容易堆積或阻礙流程，而沒有人意識到或看到其影響。而視覺化的管理這一類的 DevOps 實踐使我們能夠專注於這些領域，讓不可見的變得可見，並對正在進行的作業設定限制。

IT作業是非常動態的，由於持續的資源投入和多個利害關係人同時要求不同優先順序的產出。 IT 專業人員經常同時處理多項任務，注意力分散，有時甚至不知所措。

在製品限制(Work in progress limits)透過將作業量能( 使用小批量工作)的概念導入 IT 來解決這個問題。採用敏捷實踐的更具迭代性的開發方法（例如 Scrum）允許團隊在作業早期發現缺陷和錯誤，並減少重工和浪費。

減少作業傳遞次數 — 每當作業從一個人傳遞到另一個人，或從一個團隊傳遞到另一個團隊時，都會涉及大量的溝通。這些作業傳遞之間的等待時間會成為一種限制並減緩作業流程。在這些傳遞過程中，知識也不可避免地會損失一些。 DevOps 致力於減少傳遞次數，其結構和團隊方法增強了責任感和自我管理。

識別約束或瓶頸並確定其優先順序 — 系統的速度通常取決於其最慢的節點。 DevOps 提供的工具(一種槓桿)可協助識別約束並確定其優先等級，以產生最大的影響。

盡可能消除浪費 — DevOps 建立在精實和敏捷的基礎上，消除浪費是其核心焦點。 DevOps 不斷努力改進，以便盡可能消除浪費。

第二種方法:回饋(Feedback)

第一種方式說明了實現從左到右快速作業流程的原則，而第二種方式說明了實現互惠的原則，即在價值流的所有階段從右到左快速且持續的回饋。第二種方式強調溝通和協作，這是改進產品所必需的。第二種方法是加強和自動化回饋循環，拉近開發與維運以促進溝通的一致性和規律性，並確保回饋帶來有意義的行動和變革。

反饋循環(Feedback Loop)需要快速且準確。反饋循環需要與開發和維運以及所有利害關係人建立聯繫。第二種方法有助於建立"安全、有韌性"的作業體系，因為它提供了更多偵測和糾正錯誤的機會。

DevOps 鼓勵文化轉變、新流程和實踐以及新的技術和自動化方法，以支持反饋循環並提高品質和韌性。

在問題發生時及時發現 — Scrum 和視覺化管理等 DevOps 實踐提供了提供快速回饋的機會。 DevOps 測量方法還可以確保在問題發生時就會偵測到，而不是在作業流程的後期才進行偵測。

停下整個產線來解決問題並取得新知識 — 在作業流程中，偵測問題並不能解決問題。團隊也必須對它們做出回應。此步驟涉及能夠快速協作、集群相關專家以及利用解決問題的機會作為學習機會來取得新知識並確保解決方案盡可能廣泛地傳播。

讓品質更接近源頭 — DevOps 架構和團隊旨在增強責任感並減少作業傳遞，以確保品質更接近作業執行地點。進行的檢查越多，作業必須經過的人員或團隊越多，知識損失的可能性就越大，並且每次交接時發生錯誤的可能性就越大。

全局最佳化與局部最佳化 — DevOps 鼓勵系統性思考，綜觀全局使我們能夠對我們的作業在全局範圍內的適應情況負責。我們可能會發現一個局部改進，這只會對我們自己本身有幫助。我們需要應用系統思考，我們就會考量在全局範圍內實施的局部改進是否會使整個組織受益。

正如前面所討論的，DevOps 鼓勵文化轉變、新流程和實踐以及新的技術和自動化方法，以支持建立實驗和持續學習的文化。

營造安全的學習文化 — 在組織文化中，IT 人員通常會感到自己會因提出問題而受到異樣眼光，如果提出建議或因失敗而受到指責，則會受到指責。組織甚至可以不是解決問題，而是解決提出問題的人。安全的學習文化將失敗視為取得知識的機會，並且在問題發生時不責怪任何人，因為是體系的錯誤導致的。

將持續的日常改善制度化 — 當日常作業和「保持正常運作」成為首要任務時，就沒有時間進行持續改進或創新。 DevOps 文化確保持續改善是日常優先事項，而流程和實踐以及對自動化的聚焦是為了創造時間來做到這一點。

將局部知識轉變為全局改進 — 局部最佳化沒有不好，在存在局部知識的情況下，DevOps 鼓勵團隊和個人分享該知識，以造福組織中的每個人。

在日常作業中實行韌性模式 — DevOps 鼓勵實行韌性模式，即預測問題並確保在問題出現時做好準備並準備好處理問題的方法。

轉變領導方式以鼓勵學習 — 變革型領導是文化變革的關鍵驅動力。 DevOps 專注於確保組織內的領導者支持鼓勵學習的文化。

第三種方法:持續實驗(continuous experimentation)

第三個方法專注於創造一種持續實驗和學習的文化 — 使個人、團隊和整個組織能夠不斷創造知識。這個方法涉及打破穀倉文化。穀倉文化常常成為一種恐懼和低度信任的文化。持續實驗和學習幫助 IT 將失敗視為一種學習經歷，並將失敗視為創新的必要條件。

持續交付(continuous delivery)

持續交付流水線是持續範例的一種體現，其中自動化"建置、測試和部署"被編排為一個發佈作業流程。更簡單地說，CD 流水線是代碼變更進入生產環境所需經歷的一組步驟。 CD 流水線根據業務需求，以自動化方式頻繁且可預測地提供從test到Stage再到Production的高品質產品。

持續整合

持續整合是一種將多個開發人然的代碼變更自動整合到單一軟體專案中的實踐。這是主要的 DevOps 最佳實踐，允許開發人員經常將代碼變更合併到中央儲存庫中，然後在其中執行建置和測試。

自動化工具用於在整合之前診斷並確認新代碼的正確性。原始碼版控系統是 CI 流程的關鍵。版控系統還輔以其他檢查，例如自動化代碼品質測試、語法風格(syntax style)檢視工具等。

持續測試

DevOps 中的持續測試(Continuous testing)是一種軟體測試，涉及開發生命週期的每個階段的測試。持續測試的目標是透過儘早且經常進行測試來評估作為持續交付過程一部分的軟體品質。

持續佈署

持續部署是持續整合的延續。一旦測試在開發環境中得到驗證，就必須投入生產環境。因此，持續部署包括自動執行先前手動執行的部署操作。以下列出功能性測試與非功能性的差異，功能測試驗證軟體應用程式的每個功能是否按照需求規格運行。。

功能性測試 — 測試產品運作所需的功能

Unit Tests
Integration
API
System Testing

非功能性測試: 系統運行測試

Performance
Compliance
Security
Capacity

非功能性測試主要涉及黑盒測試(black box testing)，它不關心應用程式的原始代碼。它測試產品運作所需能力。非功能性測試被定義為一種軟體測試，用於檢查非功能方面或測試系統操作。

以下比較表，我們可以檢視持續交付的效益。部署流水線的組件和實踐產生持續交付，解決 IT 價值交付問題，並協助 IT 交付業務價值。

跨部署流水線的持續交付意味著…

有效的測試資料管理 →更少的重工
全面、快速、可靠的測試和部署自動化 →降低部署痛苦
基於主幹(trunk)的開發和持續整合 → 更高水準的 IT 效能（更高的吞吐量和穩定性）
應用程式代碼、應用程式和系統配置全部在版控中 →降低變更的失敗率
將安全（安全團隊）納入交付流程 →對組織有更強的辨識度

Full Stack DevOps

我們按照Full stack的思路檢視一下 DevOps 的範圍。IT 中的價值交付問題在於，不僅需要對某一領域進行變革。例如，僅針對文化、流程或技術。

但涉及整個堆疊(Full stack)的各個面向。 IT 當今面臨的挑戰要求企業運用我們設面討論的三步工作法並在整個部署流水線中實現持續交付。這種方法需要文化轉變、一套新的實踐以及圍繞工具和自動化達到高度成熟度的能力。

DevOps 建立在 ITIL、精實和敏捷的現有實踐之上。然而，這些框架或方法在過去都沒有發揮作用，因為它們片面的並且不是在 DevOps 範圍內實現的。DevOps 使用Full Stack方法來改變人員和文化、流程和實踐、技術和自動化。

Full Stack包含一個解決與人員和文化相關的挑戰的階層問題。它重點聚焦於 IT 領域當前存在的障礙，以打破穀倉和混亂之牆，從而鼓勵溝通、協作和實驗的文化。

文化轉變的最大障礙之一是領導力

DevOps 滿足了變革型領導的需求，並倡導 IT 內部架構和團隊的新方法，從而消除了穀倉心態並促進必要的文化轉型。 Full stack的第二層(實踐)解決了與流程和實踐相關的挑戰。

以下為DevOps 的 15 種實踐，我們將在Part 3中介紹這些實踐。在實踐層確保在適當的文化到位的情況下，流程基本上會變得簡單和精簡。它建立在精實原則的基礎上，重點在於問題解決和利用改善(Kaizen )流程優化和視覺化管理等工具。

客戶的聲音
業務關係管理
精實流程優化
價值流程圖
知識管理
視覺化管理
敏捷專案管理與 Scrum
左移測試
變更管理
配置管理
發布和部署管理
事故管理
問題管理和改善
持續改善服務
反脆弱性

DevOps 建立在敏捷開發和產品管理思維的基礎上，結合了 Scrum 實踐、規模化敏捷框架和敏捷 XP。它結合了 IT 服務管理和 ITIL 的各個面向。DevOps 採用所有這些現有的實踐和概念，並使用它們來實現三步工作法並實現持續交付。

Full Stack的第三層(自動化)解決了與技術、如何採用正確的流程和實踐並透過整合和自動化加速它們相關的挑戰。

這種方法涉及整合的工具鏈，了解要使用哪些工具以及如何跨團隊整合它們以實現各種流程的自動化。DevOps 涉及開發與開發流水線自動化相關的高複雜度和成熟度等級。

最後，它涉及了解如何利用雲端技術和虛擬化來進一步加快速度並提高協作和效率。