每當我們談到傳統(tǒng)的IT運維或IT服務管理，第一時間會讓大家想到的是要遵循IT服務管理最佳實踐ITIL的流程去指導日常運維。我們的IT服務管理就是通過ITIL的流程管控來實現(xiàn)標準的運維操作。ITIL作為由英國政府商務辦公室（OGC）所主導的IT服務管理最佳實踐，目前已經(jīng)成為很多國家和企業(yè)用來指導IT運維的方法論。在過去的20年里，包括國有五大銀行、中國移動和中國電信等國內(nèi)IT服務管理做得比較好的公司，無疑不是ITIL流程落地的忠實粉絲。

   我們且看ITIL的流程落地給使用ITIL的企業(yè)或組織帶來什么樣的好處？ITIL強調(diào)通過服務臺實現(xiàn)事件單和服務請求單的統(tǒng)一接入和轉(zhuǎn)派，并設置合理的工單優(yōu)先級，以急業(yè)務之所急的方式通過服務臺工作人員對每個工單的全鏈路跟蹤和督辦,最終實現(xiàn)工單處理流程的閉環(huán)。另外，我們都知道業(yè)務應用和IT基礎設施的日常運維都擔心會不時的引入可能的風險，風險有可能是由于不善的變更和發(fā)布導致，或由于新代碼的缺陷引入的風險等。所以ITIL強調(diào)嚴格的變更和發(fā)布審批，并設置變更咨詢委員會（CAB）的職能通過CAB會議來履行該職責。通過設置變更/發(fā)布窗口的固定時間段來盡可能降低或規(guī)避不必要的風險。規(guī)范的變更和發(fā)布管理是在企業(yè)內(nèi)部做好IT服務配置管理的前提，最根本和直接的做法是對生產(chǎn)環(huán)境的相關(guān)配置項（如服務器或存儲設備）進行變更后，需要做到及時的對配置管理數(shù)據(jù)庫也就是我們經(jīng)常提及的CMDB中的內(nèi)容進行同步更新。如果做不到這一點，久而久之CMDB的內(nèi)容和生產(chǎn)環(huán)境就不一致。再久而久之，CMDB就失去了在日常運維過程中判斷異常事件的影響級別、系統(tǒng)監(jiān)控和業(yè)務影響分析的輔助能力。所以，看一個企業(yè)的運維管理成熟度如何，我們基本可以通過配置管理的成熟度就可以做出初步判斷。配置管理是很多運維管理流程和實踐的基礎，比如很多公司的統(tǒng)一監(jiān)控平臺就是建立在配置管理之上的。利用統(tǒng)一的監(jiān)控大屏(ECC)來實現(xiàn)業(yè)務應用和IT基礎設施的全鏈路的指標監(jiān)控和故障定位。通過數(shù)量龐大的IT技術(shù)運維團隊提供7x24小時的故障處理和業(yè)務保證。定期執(zhí)行全網(wǎng)的安全掃描和跨數(shù)據(jù)中心級的容災切換，確保IT治理能力的最終實現(xiàn)。以上所有流程實踐都會有相應的指標，比如銀行在主數(shù)據(jù)中心出現(xiàn)整體不可用的情況，要確保在8個小時內(nèi)把所有的業(yè)務應用在其災備中心啟用，實現(xiàn)業(yè)務級的災備。這個8小時的時間承諾就是我們常說的目標回滾時間（RTO，Recovery Time Objective）。RTO是一個典型的服務級別指標，通常會被納入服務級別協(xié)議（SLA）中去監(jiān)督和管理，確保其能有效達成。

  通過以上的IT運維流程的綜合布局，最終實現(xiàn)了以ITIL理論為指導的IT服務管理體系。那么在云時代下，相對于傳統(tǒng)的以流程管控為抓手的運維會有哪些變化呢？我們且從如下幾點來區(qū)分其不同。

   1、監(jiān)控系統(tǒng)的實現(xiàn)機理不同

   傳統(tǒng)的監(jiān)控系統(tǒng)是以獨立的第三方商業(yè)軟件作為輸出的。比如IBM的Tivoli Monitor或HP的OpenView。監(jiān)控系統(tǒng)是以外掛的方式來采集被監(jiān)控的軟件產(chǎn)品的日志并做到集中的ECC大屏呈現(xiàn)。在云計算的世界里，每個云產(chǎn)品，比如ECS云服務器，其作為可以獨立輸出的產(chǎn)品服務單元，云產(chǎn)品自身已經(jīng)帶有完備的監(jiān)控功能。換句話說：云產(chǎn)品的配置管理已經(jīng)落到了每個云產(chǎn)品的內(nèi)部，云產(chǎn)品的監(jiān)控能力與產(chǎn)品的配置項是緊耦合的關(guān)系。云廠商需要做的是設置一個統(tǒng)一的監(jiān)控平臺界面（Uni-Manager），把各個云產(chǎn)品的監(jiān)控能力加以封裝，以客戶比較熟悉的ECC的形式輸出。

   2、風險的控制機理不同

  傳統(tǒng)運維的風險預防主要集中在執(zhí)行嚴格的變更和發(fā)布管控和審批流程，以及針對風險的治理能力。風險的發(fā)現(xiàn)主要來自監(jiān)控的指標體系的設置，以及事件的定級和指標觸發(fā)的應急響應。故障恢復也有賴于頻繁的應急演練，這里包括特定故障的應急演練和整個數(shù)據(jù)中心級的切換演練。

   有別于傳統(tǒng)運維嚴把變更和發(fā)布審批，云計算的運維更加強調(diào)通過白屏化的操作和腳本化的驅(qū)動來降低和規(guī)避風險?；緦崿F(xiàn)全局故障1分鐘發(fā)現(xiàn)，5分鐘定位和10分鐘解決。云環(huán)境下的風險管理也會包括諸如風險預防、風險發(fā)現(xiàn)、故障定位、故障恢復和故障復盤的全流程，只是云環(huán)境更加強調(diào)自動化腳本或平臺的作用，把變更或發(fā)布腳本在云計算的產(chǎn)研側(cè)寫完，這樣就可以做到可重復執(zhí)行和受故障影響的業(yè)務自動恢復。通過平臺的管控和腳本的觸發(fā)實現(xiàn)變更或發(fā)布的可灰度、可監(jiān)控（白屏化）和可回滾?？苫叶燃磳狣evOps提到的金絲雀發(fā)布，可回滾即對應DevOps的藍綠部署。故而云環(huán)境的風險控制是依賴DevOps全自動化的部署流水線來實現(xiàn)的。

   3、自動化成熟度不同

   云計算的資源虛擬化和資源池化的特性本身為自動化運維提供了很好的技術(shù)保障。在云環(huán)境下遇到網(wǎng)絡DDOS（拒絕服務）安全攻擊或重大故障時，自動化的業(yè)務限流或業(yè)務流量的自主切換變得非常容易實現(xiàn)。甚至為了確保業(yè)務全鏈路的安全，可以采取部分業(yè)務功能自動降級的處理，比如某券商軟件可以把已引入故障的查客戶積分的功能暫時跳過，確保主業(yè)務鏈路的證券產(chǎn)品買賣服務功能的可用。除此之外，云環(huán)境還可以如DevOps所提倡的不時人為注入故障(Chaos Monkey)的操作,驗證在重大故障來臨可以以自動化方式恢復業(yè)務的能力，充分體現(xiàn)云環(huán)境的產(chǎn)品魯棒性。

總之，云環(huán)境下的運維更加強調(diào)白屏化和腳本驅(qū)動，以DevOps部署流水線的方式來規(guī)避或降低變更或發(fā)布的風險。ITIL 4的部署管理實踐可以通過DevOps部署流水線的方式來落地，故而企業(yè)的IT服務管理在未來的指導原則是不斷打造基于云計算的產(chǎn)品能力來實現(xiàn)業(yè)務的持續(xù)交付和自動化運維的能力。