探索那些亟待優化的變革管理實踐

變革已成為現代數位產品創建和管理中最重要的組成部分。這些變革通常涉及添加新功能，但也受到客戶需求和利害關係人優先事項的驅動。目標是 DevOps 團隊不僅要優先考慮快速變革，還要優先考慮那些能帶來持久、可衡量價值的變革。 

可惜的是，持續整合/持續交付（CI/CD）的概念並非總是能體現在組織的實際運作中。首先，缺乏測試或回饋會阻礙變更管理。此外，繁瑣的遺留流程仍然存在，這往往會限制團隊或組織創造新價值的速度。 

但 DevOps 團隊可以審視多個關鍵領域，尋找改善機會。這些改進旨在優化變更管理，使其更快、更敏捷，並更有可能透過持續整合/持續交付 (CI/CD) 實現頻繁的價值創造。基於這些標準，我們建議的改進措施如下： 

• 透過策略性變更建模來限制人工變更審批。
• 產生、收集和利用持續回饋 
• 繪製流程圖，尋找可以刪除或修改的步驟

透過標準變更模型加快變更審批速度

DevOps 敏捷開發重視高度自主的團隊快速迭代式的變更。團隊通常擁有自主決策權，可以根據需要靈活調整策略，並基於當時的資訊不斷演進。這種敏捷團隊結構消除了傳統「瀑布式」開發方法的瓶頸。在傳統的瀑布式開發中，編碼團隊依賴上級下達的指令。很多時候，這些指令反映的是持續數月的項目，而且在最終產品完全交付之前，指令都不會改變。 

即使是敏捷思維也未能消除那些固守傳統瀑布式開發方法的人。其中最頑固的頑固分子之一就是人工變更諮詢委員會（CAB）審查。 

雖然需要對下一版本部署中提出的變更進行審核和批准，但這些批准並非總是需要手動完成。至少， DevOps 團隊應盡量減少需要最高層級變更諮詢委員會 (CAB) 團隊參與的審查次數。限制需要 CAB 審查的變更數量和頻率，有助於簡化流程並最大限度地減少中斷。如何才能做到這一點？ DevOps 如何減少對公民諮詢委員會審查的依賴？可以先從模擬變更入手，使其適應標準組和非標準組。

A 變更是指任何與以往類似變更相關的常規變更，或代表產品改進的重複策略。通常有大量數據表明，標準變更造成的中斷、缺陷或變更失敗風險極低。因此，標準變更在部署前經過自動化審核和測試後即可自動獲得批准。

分析技術可以透過以下方式提供有關特定變更（無論是標準變更或非標準變更）風險的見解： 表達變化風險關鍵績效指標.

對於不符合標準模型的變更，開發團隊可以將部署拆分為標準元件和非標準元件。這樣，需要審查的組件就可以被隔離出來，從而減少變更諮詢委員會 (CAB) 團隊的工作範圍和所需時間。

即使需要人工審核，也可以限制審核範圍。根據一個受歡迎的IT服務管理（ITSM）資源網站的說法，這種審查概念是… 當變更不完全符合標準時，可以採取「授權委託」的方式。 這種模式遵循標準模型，但僅限於特定部門或地點。其運作原理是確保具有局部風險的變更由本地負責人（例如 IT 經理或業務部門主管）審核和批准。這種做法可以避免召集整個變更諮詢委員會 (CAB) 來審核和批准變更。

使持續整合和資料庫管理更加敏捷

自動化整體上可以減少人為幹預的環節。但自動化不應淪為低效率流程的電腦控製版本。 

DevOps 團隊需要確保透過在內部建立文件功能來最大限度地發揮自動化的效用。 DevOps 流水線。任何時候，只要變更影響到配置項目 (CI) 之間的關係，開發工具就應該儘早使用自動化文件記錄這種互動。這樣，任何想要審核 CI 變更的人員都可以快速找到影響特定 CI 的具體變更。

CI交互作用尤其容易導致資料庫變更核准速度變慢。如果未謹慎考慮變更可能帶來的影響，資料庫變更可能會導致CI出現效能缺陷。

為了在加速CI相關變革的同時降低缺陷風險， OpenSource.com專家推薦 由於“資料庫變更往往會使持續整合變得複雜”， DevOps 團隊可以簡化流程。 「透過使用包含資料庫管理員的敏捷跨職能團隊，實現資料庫持續整合 (DBCI)。」這位專家還建議更多地依賴「資料庫即程式碼”，以及「使用物件導向 (OO) 原則重構資料庫」。

依靠持續的數據回饋來改善變革管理

利用數據分析可以在價值流的各個環節提供重要的回饋，使開發和營運能夠協同工作，從而提高變更的可靠性。 

As 持續交付專家馬修·斯凱爾頓評論“日誌記錄和指標對於構建現代軟體系統的團隊來說至關重要，就像雷達和視頻模式識別系統幫助自動駕駛車輛行駛一樣。” safe在高速公路上高速行駛。 

這些活動產生的回饋有助於調整團隊的現有工作方向，引導他們進行能夠創造更高價值且缺陷風險最小的變更。但需要注意的是，正確的指標對於促進快速有效的回饋至關重要。例如，某個團隊的變更導致較高的缺陷逃逸率，可能表示該團隊的發布版本需要增加測試覆蓋率，或需要對其依賴的編碼實踐進行調整。

傳統上，監控系統效能並利用回饋進行改進被視為維運團隊的職責。雖然維運團隊確實負責生產環境中的最終部署和效能，但開發團隊也必須能夠存取相同的監控工具，以便追蹤關鍵的變更效能指標並發現潛在問題。讓開發團隊存取這些數據，可以幫助他們發現並修復缺陷，甚至有可能改變編碼實踐，從而創建更穩定的變更。允許他們自行監控和糾正此類問題，而無需上級指示，可顯著提高開發效率。 積極主動的自主性，以及可能更高的工作滿意度.

然而，需要注意的是，開發團隊可能需要一些時間來適應承擔審查並可能回應維運回饋的責任。這通常超出了採用新流程或技術本身的工作範疇，它需要文化變革和明確的策略，以確保組織內部對敏捷持續整合/持續交付（CI/CD）的認可。 

實施流程圖繪製，以了解價值創造或受到負面影響的環節。

為了找出價值生產瓶頸， DevOps 領導者可以創造工作的每個階段的概念圖。 DevOps 以及所有相關團隊。根據此分析產生的文件稱為「價值流圖」。它不僅可以用於追蹤工作流向，還可以用於追蹤流程每個階段的實際價值流向。

為每個階段創建和追蹤指標 這對於發現缺陷和提升敏捷性非常有用。例如，追蹤工作到達特定階段到離開的總時間等指標，可以提供有關效率的寶貴資訊。它還可以突出顯示特定工作區域中持續存在的問題。

追蹤每個階段的過程可以 DevOps 團隊不應僅關注孤立的部分。這種流程圖繪製方式有助於視覺化價值如何貫穿整個流程，以及每個步驟如何影響價值。例如，減少建置/測試和部署之間的步驟將為整個流程增值。 

As Conflux 的 Matthew Skelton 觀察到“冗長緩慢的部署流程會阻礙從部署過程中獲得快速反饋。相反，應該使用簡短而全面的部署流程，讓團隊和產品經理能夠根據每次具體變更的性質靈活地決定運行哪些測試。”

將這些建議作為基礎，以實現更好、更敏捷的變革管理。

雖然很容易提出優化 CI/CD 流程的可能方向，但事實上，每個組織在 CI/CD 流程方面都是獨一無二的。 DevOps 部署。因此，流程圖繪製至關重要，它可以精準定位組織中存在的改進機會。 

數據回饋對於指導決策策略、提升敏捷性至關重要。此外，自動化資料收集能夠促進開發團隊內部形成自主改善的文化，進而增強IT部門乃至整個組織的持續整合/持續交付（CI/CD）文化。 

最後，進階機器學習建模甚至可以利用數據來創建 對變革風險等事物更深入的理解這不僅能讓您和您的團隊查看數據，還能讓他們精準地根據數據採取行動。讓變革賦能團隊能夠使用諸如表達性風險建模之類的工具，可以促進快速理解、快速工作和快速決策的文化——所有這些都使得… DevOps 在不產生意外風險的前提下，更頻繁地創造更多價值。

了解人工智慧驅動的分析（例如變更風險預測）如何彌補差距。 ITIL與ITIL之間的差距 DevOps 本次網路直播.