了解 ITIL 4 變更管理流程（以及自動化如何增強 IT）

 

什麼是變更管理？

ITIL 4 變更管理是指 ITIL 基金會制定的一套指導原則。這些指導原則幫助組織管理數位化產品的變更。 最小摩擦或風險.

ITIL 4 是這些指南的第四次修訂版，第一版早在 1989 年就已發布！與 ITIL 3 為組織制定了一套具體流程不同，ITIL 4 旨在提供靈活的指導。重要的是，組織可以採用 ITIL 3 中所述的具體流程，同時仍完全相容於 ITIL 4 的指南。

ITIL 4 變更管理建議主要針對 IT 維運中的關鍵概念和角色提供具體定義。這些概念具有普遍性，可以適用於任何組織，而不受公司實際結構的影響。其目的是幫助組織在 ITIL 4 變更管理框架的指導下，制定自身的流程和實踐。

將 ITIL 4 的建議與以下方面結合起來使用 變更風險預測分析 可以大幅加快發布速度，同時引導產品團隊開始進行風險較低的整體變更。利用以下方式提前規避風險： Digital.ai Intelligence.

為什麼要使用 ITIL 4 進行變更管理？

無論屬於哪個類別，變更都是日常 IT 維配的標配。幾十年前，變更僅限於偶爾發生的補丁更新或配置更新，一年甚至更少。但如今，世界上一些最受歡迎的應用程式、服務和平台每年都會收到數千次變更更新。谷歌曾在 2018 年發布過一份著名的報告，指出… 光是那一年，該公司就對其搜尋引擎演算法進行了超過3,000次更改。平均每天約 9 人。

由於變化日新月異，IT 組織需要一種結構化的方法來整合和部署變更，以最大限度地降低服務中斷的風險。同時，IT 維運負責人需要消除任何阻礙變革速度的障礙。任何不必要的延誤或阻礙都會阻礙價值鏈的運作。

這就帶來了一個悖論：我們必須在…中實施變革 safe 速度比以往任何時候都快得多。

最新更新的 ITIL 變更管理流程旨在解決這個難題。 ITIL 4 變更管理的主要目標是在有效控制營運指標和其他變更風險管理目標的同時，消除變更部署的所有障礙。基於此，ITIL 4 提出了一個變更賦能框架，而非僵化地定義一套規範化的變更管理流程。

透過採納 ITIL 4 的理念並根據當前的組織環境進行定制，IT 維運團隊可以加快變革的速度，同時最大限度地減少效率低下和破壞性威脅。

ITIL 4 旨在簡化變更管理流程。

ITIL 的最初版本——最早發佈於 20 世紀 80 年代末——嚴格地描繪了一系列流程，旨在為組織的 IT 相關活動帶來可預測性和結構性。對於那些 IT 需求不熟悉或難以預測的企業而言，這些指導至關重要。它誕生於一個新興技術尚未發達的時代，當時企業和政府機構都迫切需要這種具體的指導。

然而，2000世紀初軟體開發方法論發生了重大轉變：敏捷開發。敏捷開發摒棄了僵化的“瀑布開發流程被取消了。這使得各個開發團隊擁有更大的自主權和對最終結果的控制權，從而可以在更短的時間內完成開發。

敏捷開發推廣了一種理念，即應用程式和技術平台可以不斷發展演進——只要投入精力確保每一次新的變化都能為最終用戶增加價值。

為了因應敏捷方法論的興起（以及 DevOps 此後，ITIL被迫做出調整。 ITIL v3在現有ITIL變更流程的基礎上，發展了一種持續變更實施模型，許多組織遵循以下步驟進行實施：

1. 建立變更請求（RFC）
2. 審查 RFC
3. 由變革諮詢委員會 (CAB) 對 RFC 進行評估和評價
4. 根據 RFC 授權更改
5. 計劃更新
6. 協調實施
7. Deploy/整合新變化
8. 審核變更並關閉變更記錄

此版本的ITIL變更管理流程可靠、可重複，並且對變更提案的結果具有很強的控制力。但對某些組織而言，它仍然相當繁瑣。

持續不斷的變更諮詢委員會 (CAB) 審查會延誤變更，並可能導致嚴重的效率低下。因此，每次變更所產生的價值都會受到限制。

針對這些不足，新的 ITIL 4 框架建議將嚴格的「提案 > 批准 > 實施 > 關閉」變更模式保留給某些被視為非標準的變更。因此，儘管 ITIL 4 框架保留了以往版本中常見的「常規」變更管理流程，但它鼓勵 IT 維運負責人將盡可能多的變更遷移到另一個類別：標準變更。

利用 ITIL 標準變更模型加速變更速度

ITIL v3 中有一個名為「標準變更」的變更類別。這些變更被認為風險較低，並且在給定的 IT 環境中會頻繁發生。 提供的範例 包括密碼更改、新員工入職流程以及實體設備的搬遷。

ITIL 4 使 ITSM 領導者認識到，組織可以努力使標準變更成為常態，而不是「正常變更」的特殊例外。它提出，透過對變更類別或特定變更類型進行建模，在許多情況下不再需要正式的把關和變更諮詢委員會 (CAB) 的批准。

因此，弄清楚哪些變更實際上是「正常」（即「低風險」）的，可以消除阻礙敏捷性的大部分瓶頸。當高風險變更被引入正式的 RFC 流程時，IT 維運負責人也可以開始著手接受、緩解或拒絕這些風險。

現在，實施常規變更的過程可以在很大程度上實現自動化，這意味著一旦開發部門提出變更（通常是根據 IT 維運部門的數據回饋），就可以在生產環境中進行測試、整合和部署，然後幾乎不需要人工幹預即可完成變更。

因此，雖然標準變更確實反映了正常的變更流程，但 RFC 是透過低延遲流程進行審查和授權，而不是透過正式的 CAB 審查。

調整 ITIL 變更管理流程，以加速變更並同時管控風險

在不犧牲速度或彈性的前提下，可以基本保留原 ITIL 3 變更管理流程的每個步驟。

更新後的 ITIL 4 框架所提出的建議 調整組織變革管理流程包括：

• 為重複性變更建立變更模型
• 將標準變更的變更審批分散化
• 將較大的變革分解成風險較小的部分。
• 利用自動化檢查、測試和部署

以下是針對更正式的 ITIL 變更管理流程的每個步驟可能進行的調整：

變更請求

首先應將個別提出的「常規」變更方案參考標準變更模型進行評估，以確定該變更是否真的可以避免審批流程。對於「低風險」且包含一些預設變更模型特徵的變更，可以將其拆分，僅對新增提案進行正式審議，而對標準組件進行預先授權。

在條件允許的情況下，可以根據 IT 維運資料回饋，針對已提出的變更需求自動產生 RFC。自動產生的 RFC 可以納入建議的變更/功能組合中。自動化的 RFC 減少了緊急變更的需求，因為它們能夠主動識別風險，並力求解決這些風險，最好是盡可能遵循預先建模的標準變更。

變更評估
根據 ITIL 4，變更諮詢委員會 (CAB) 會議應在特殊情況下召開，而不是按預設的週期或作為標準變更流程的一部分。當變更經理的判斷補充時，通常只需一位變更經理即可評估特定變更的風險或影響。 人工智慧驅動的分析標準變更可以透過自動化流程進行大部分或全部評估，從而避免積壓的審批事項，並大幅降低延遲。需要正式批准的常規變更可以成為新標準變更模型的基礎，也可以用於更新現有標準變更模型，使其適應更廣泛的範圍。

變更授權
ITIL 4 以敏捷性為中心的變更賦能架構的主要目標是盡可能減少變更授權的數量。在大多數情況下，透過對變更進行建模，可以實現即時授權，並利用分析來… 評估變更風險 可以讓人工引導的正常變更授權流程更簡單、研究更深入。

計劃變更
透過使用變更分析，變更調度和建立授權流程可以顯著簡化，甚至接近完全自動化。應盡可能減少手動調度和變更建置計劃。此外，透過對變更進行建模，可以將需要特別關注的變更與可以快速規劃並建置到未來版本部署中的變更區分開來，從而消除不確定性。

Deploy/整合新變化
感謝 Release 管理工具對於許多企業而言，變更部署和整合已基本自動化。 「正常」的低風險變更應優先處理，這意味著大多數變更無需手動部署或整合。需要關注的變更可在部署後進行監控，從而減少對少數高風險變更的直接人工監督需求。

審核變更並關閉變更記錄
全面變更收尾的重要性不容忽視。實務證明，全面變更收尾能夠有效減少意外問題和中斷。然而，這並不意味著IT組織需要引入繁瑣的人工審核流程，以確保每次變更都穩定可靠，並準確反映在所需的文件中。

即使在規模較小的組織中，變更收尾也是變更管理流程中最適合自動化的步驟之一。 自動化測試和審查 自動化組態管理資料庫 (CMDB) 更新和其他變更收尾任務可發揮「品質保證」作用，同時減少手動變更收尾的需求。這些做法可確保記錄更加完整，並降低組織失誤影響 CMDB 資料和其他主要記錄系統完整性的風險。

在流程的每個步驟中利用 IT 分析加速變革部署。

人類富有創造力，也擅長解決問題，但我們並不像電腦那樣能夠快速審查成千上萬行程式碼或數百萬筆資料記錄。分析技術能夠提供此功能，它不僅能顯著提升 IT 效率，還能增強變更審查和部署流程的敏捷性。
添加 AI 和 ML 模型可以自動發現人眼可能無法看到的資料模式，從而進一步增強 IT 能力，例如變化風險因素或給定變化對效能產生破壞性影響的可能性。

這些功能體現了科技在幫助我們管理日常創建和修改的技術方面所發揮的關鍵作用。雖然變更自動化並非現代變更管理實踐的必要條件，但ITIL指南將其視為最佳實踐，在以毫秒而非月來衡量速度的時代，它至關重要。