作者：北京老李：DevOps布道師、IT管理咨詢師。擁有EXIN Agile、EXIN Lean IT、首批EXIN DevOps Master講師、首批ITIL Expert講師、PMP、Prince2專家級、EXIN云安全管理、注冊信息安全講師(CISI)、ISO20000 LA、ISO27001 LA等多項認證。先后在北京、上海、廣州等地主導軟件開發、系統集成、咨詢服務等工作，主要研究方向云安全管理、DevOps落地實施。

本文的擬寫自來與Martin劉老師的討論，也感謝Martin劉老師找到了下面這個鏈接的圖片，Martin劉老師說，看個文章還看到了北京老李和上海孫老師當年的模樣:(~

當前的討論，很是久遠的歷史，但值得回憶：）

北京老李說:得感謝互聯網，哈哈。來看看孫老師現在的模樣。看看北京老李和Martin劉老師現在的樣子：9~~歲月在Martin劉老師的臉上，也在北京老李的臉上：（

Martin劉老師、上海孫老師現在的模樣，當你老了，化妝也沒

也讓北京老李這個首批ITIL Expert回憶起當年從事IT管理的初期的討論與研究，也正是在不斷地項目實踐中，進一步進印證了，IT管理的重要性，雖然時光荏苒，但我們在新的IT管理體系下也在進行相同的事情。歷史的回憶從ITIL的變更到DevOps的變更應用。下圖為歷史的回憶

十年過去了，但不變的不僅僅是情懷還有管理思想，ITIL在當今流行的DevOps中還在發揮著效果，那么看下，什么是變更？在ITIL原文中變更是指一切對服務以及CI配置項的改變，包括增加、刪除、修改。那么在DevOps下是否適用呢？

正確的理解是適用！因為DevOps中的變更雖然進行了自動化，但也需要引入ITIL中的變更，因為DevOps沒有必要自己再造一個已經有國際標準ISO/IEC20000，已經有最佳實踐ITIL成熟多年的體系，那么就是引用。

在ITIL中變更管理將變更分為三大類，分別是標準變更（Standard change）、緊急變更（Emergency change）、正常變更（Normal change）

標準變更（Standard change）：是指那些經過預授權的變更，主要針對那些低風險、經常發生，并且是有預先定義好的處理步驟的的變更。一般情況下包括每月固定更新的稅表或網站樣式變更等內容。

其特點在于不需要再次經過領導審計，因為在變更部署前已經提前完成了審批。并且變更部署活動可以完全是自動進行的，但需要注意的是需要留下審計及跟蹤的記錄。在DevOps中也一樣遵從ISO20000及ITIL的標準，只不就是進行了自動，智能化目前看標準變更也在逐步實現。

緊急變更（Emergency change）：是指那些要盡可能快地去實施的變更，比如解決一個重大故障，或打一個緊急的安全補丁。在緊急情況下，變更必須立即投入生產環境。一般情況下安全緊急安全補丁或緊急恢復服務。其特點是必須盡快解決的潛在高風險變更。這些變更通常需要盡快得到高級管理層的批準，在執行完成技術活動后，應立即進行記錄歸檔工作。DevOps的踐的關鍵目標是簡化常規變更流程，使其也能適用于緊急變更。

所以在DevOps中緊急變更想要應對緊急，并不是大家認為的只是緊急的變更來了就可以應對，這就需要提前進行緊急變更的預防管理。

這里需要應急管理、連續性管理（BCM）、IT災備管理（ITSCM）、安全事件響應（ISMS）等多個流程的提前定義才能做好緊急變更的處理工作，這個工作在ITIL高級課程 RCV中進行了很好的說明與描述。有空來聽北京老李講ITIL高級課成為ITIL專家：）

北京老李：首批ITIL Expert講師

正常變更（Normal change）：是指那些除了標準變更和緊急變更之外的所有其它服務變更。其特點是需要更高的領導進行評審或者在既定的審批組織CAB和ECAB進行批準。其中CAB是指變更顧問委員會，ECAB是指緊急變更顧問委員會。

在最新的敏捷的道路上，很多組織的變更都是由于領導出差、評估不能及時完成，所以造成了評估的時間上的延誤。

我們在2012年在IT管理項目中就注意到了這一點，我們是通過移動辦公平臺，IOS、安卓等新應用的開發解決這一問題。能夠實現立即審批，隨手審批、一鍵審批，并且隨著應用了BMC? BladeLogic等自動化的產品，加快IT的交付頻率。

那么對于變更我們是如何解決專業化的快速評估的呢？我們在銀行率先實現了變更的標準化評審工作，隨著自動化產品BMC? BladeLogic的應用，一起同步推進管理與技術的問題。

在新的DevOps體系下，需要從管理與技術層面解決變更的效率，這個問題在大規模代碼部署的情況下尤其突出。

一般情況下我們都認為只有技術加快才能解決軟件交付的問題，其實這是一個偽命題，因為技術動作的不標準化，還來的快速交付的后果就是上線死的快，上線BUG多。

今天很多單位都已經進行了云了，傳統企業也從豎井式管理上升到云管理，這種情況下更是需要管理的標準化與技術的標準化。

曾經有人說過沒有寫過代碼的工程師就不是好司機，在此老李想說，沒有管理支撐的技術實現就不是好DevOps。

在越大的組織下，需是需要IT管理，IT管理成為他們的管理抓手，你可以想像一下，大規模部署可能包含成百上千（甚至數百萬）行代碼，由數百個開發人員在幾個月內需要快速地進行交付，那么這更需要各技術專業的協合配合。

變更管理在DevOps下仍然發揮著他在云下管理的控制權及組織權，只要CABle建設得當，這依然是一個建設高效組織的必經之路。因為無論是在云下，還是傳統IT管理，都不能離開組織的“閘門”。

在云下，現在更多的強調的是自動化，智能化。但隨著AIOps的流行，你會發現，前提依然是需要一個標準化的規則與策略。

每個組織都希望“一口吃個胖子”。但管理的成熟度告訴我們這根本就是不可能的。

企業管理的AI成功之路，就是標準化=》模板化=》自動化=》策略化=》智能化，但在此的前提是服務化。

所以變更管理在新的DevOps需要有一個更加清晰的變更請求單（RFC）的定義，因為它里面定義了執行RFC的決策所需要信息，它是智能化的基礎。

很高興在回顧這個內容，也讓我們朝著智能化之路在前進，我們已經在策略化的路上，但前方的路還有很多困難，需要不斷地規避風險和引入安全管理、云安全管理。下附老李在《云安全管理》課程講到的內容，并會在本次云博會公開，先提前爆個光：）

北京老李，云安全管理框架

當年寫下的“般若是體,方便是般若所起的作用，般若側重體證,方便為適宜方法.知此先后,則進道已.”.今天寫下“知行合一，道法相合，術器相應，才能鯤鵬直上”。----共勉? ? ? ? 北京老李? 手打版