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

若是你的公司尚未走向平臺化，如今仍然能夠是很大的飛躍。您仍然能夠經過解決公司的變動管理流程來加快軟件交付。在本章中，咱們將研究咱們在公司內部所學的變動管理模式。咱們將向您展現什麼是有效的，什麼是無效的，以及如何利用DevOps原則將變動管理轉化爲有效的、使能的流程。

在過去的十年裏，咱們已經看到DevOps的實踐顛覆了軟件發佈團隊的工做方式。如下是最顯著的變化。

「問題自己並不會改變，由於改變一直在發生；問題是在變化來臨時沒法應對。」 Kent Beck《解析極限編程：擁抱變化》
即便咱們看到交付團隊成功地轉變了他們的思惟和實踐，但要在一個大型組織中改變根深蒂固的結構和流程仍然要困可貴多。變動管理就是最難改變的過程之一。
轉向一種新的作事方式須要領導支持、組織紀律和跨組織各層的大量合做和協做。可是，在大多數大型組織中發展起來的大型遺留環境並不容易被拆分和從新設計。它們一般由許多不一樣的團隊維護，每一個團隊都擁有技術堆棧的一部分。理解工做的團隊一般缺少批准本身所提變動的權限；相反，變動批准常常被分配給脫離實際工做、瞭解不夠深切的委員會。
全部這些層面的存在是由於大型遺留環境是組織的主要業務所在。所以，任何變化都會讓人以爲有風險，並且有大量的流程和官僚做風，讓人以爲是在保護企業的安全。
不幸的是，全部這些過程都阻礙了組織的發展。他們根本沒法快速發佈軟件——不管是面向外部客戶仍是內部客戶——以知足業務需求。同時，那些使他們的變動管理更有效的競爭對手可以快速而反覆地發佈，使他們排在前面。

DevOps演進和變動管理有效性

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

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

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

變動管理的方法

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

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

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

咱們的數據揭示了一些關於影響變動管理的有效性和效率：

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