2020DevOps狀態報告——變更管理

如果你的公司還沒有走向平臺化，現在仍然可以是很大的飛躍。您仍然可以透過解決公司的變更管理流程來加快軟體交付。在本章中，我們將研究我們在公司內部所學的變更管理模式。我們將向您展示什麼是有效的，什麼是無效的，以及如何利用DevOps原則將變更管理轉化為有效的、使能的流程。

在過去的十年裡，我們已經看到DevOps的實踐顛覆了軟體釋出團隊的工作方式。以下是最顯著的變化。

“問題本身並不會改變，因為改變一直在發生；問題是在變化來臨時無法應對。” Kent Beck《解析極限程式設計：擁抱變化》

即使我們看到交付團隊成功地轉變了他們的思維和實踐，但要在一個大型組織中改變根深蒂固的結構和流程仍然要困難得多。變更管理就是最難改變的過程之一。

轉向一種新的做事方式需要領導支援、組織紀律和跨組織各層的大量合作和協作。但是，在大多數大型組織中發展起來的大型遺留環境並不容易被拆分和重新設計。它們通常由許多不同的團隊維護，每個團隊都擁有技術堆疊的一部分。理解工作的團隊通常缺乏批准自己所提變更的許可權；相反，變更批准經常被分配給脫離實際工作、瞭解不夠深切的委員會。

所有這些層面的存在是因為大型遺留環境是組織的主要業務所在。因此，任何變化都會讓人覺得有風險，而且有大量的流程和官僚作風，讓人覺得是在保護企業的安全。

不幸的是，所有這些過程都阻礙了組織的發展。他們根本無法快速釋出軟體——無論是面向外部客戶還是內部客戶——以滿足業務需求。同時，那些使他們的變更管理更有效的競爭對手能夠快速而反覆地釋出，使他們排在前面。

DevOps演進和變更管理有效性

我們想看看變更管理的有效性是否與DevOps的發展相關。為了衡量變革管理的有效性，我們從以下三個維度觀察：

實施成功率。我們觀察了變更失敗率和部署頻率。理想情況下，企業應該能夠更頻繁地進行變革，從失敗中迅速恢復，並從中吸取教訓。
效率水平。我們想知道改變的效率有多高管理過程基於以下內容：
•不到兩週的強制等待期
•更改只需一次批准
•更改被正確實現，不需要撤銷
•由具備適當技能的人批准，從而做出正確評估
•記錄更改所需的時間很少
績效情緒。作為對每個受訪者所在組織的客觀評估的代理，我們制定了該指標。我們詢問受訪者他們公司的變更管理程式是否：
•降低風險
•減少與服務事件相關的停機時間
•提供對組織有用的資訊
•確保與適當的利益相關者共享知識和資訊
•加快業務需求的變化速度
•根據評估的變更風險等級，提供適當級別的審查和批准

這三個維度——實施成功率，效率水平和績效情緒——構成我們的變更管理有效性的度量。

我們發現隨著組織發展他們的DevOps實踐，變更管理的有效性增加了。雖然差異不是很大，但在統計上的表現是顯著的。

變更管理的方法

為了調查變革管理，我們向受訪者詢問了他們在工作場所的一些不同做法。這些可以分為兩個部分：變更審批流程和變更實現的自動化程度。可分為四種群體：
運維成熟。高水平的過程和自動化。
工程驅動。高度重視自動化。
以治理為中心。高度重視人工審批，而不重視自動化。
臨時型。不重視過程和自動化。

是什麼驅動著變革管理的有效性？

當從總體上看變革管理的有效性時，會發現工程驅動的公司具有最高水平的變更管理有效性，臨時型公司因缺乏流程而成功率居於第二，剩下的兩組嚴重依賴正統的認可，在有效性上得分不高。

我們的資料揭示了一些關於影響變更管理的有效性和效率：

正統的批准會降低效率；
自動化使團隊對變更管理充滿信心；
授予許可權會帶來更高的效率。