首先宣告自己不是ITIL方面的專家，特別是具體的規范細節，后面論述如有不當，請指正，但我為什么會提起它？主要是因為它和運維（IT服務管理）相關性太大了，早起的運維完全就是以ITIL來藍本構建的，在當時公司中還有ITIL學習小組/實踐活動、ITIL的外部顧問培訓等等，后來在YY的時候，當時實踐CMDB、事件管理的時候，也是參照了其具體的規范和要求，我建議大家在講ITIL的時候，一定要把ITSMF授權荷蘭人Jan Van Bon寫的兩本書都看一下，可以迅速掃盲，避免對ITIL的耍流氓式理解， 

一、什么是ITIL

如何實作服務對接？在ITIL中，設計了一些相應的IT服務流程來保證，我們經常接觸到的ITIL應該有兩個版本，ITIL V2和ITIL V3，早期的V2版本中包含了一個服務臺和10大核心流程，在后期ITIL V3版本中吸收了ITIL V2的精華，同時對IT服務提出“生命周期”的概念呢，在ITIL V3中就有了服務設計、服務轉換和服務運營的周期性概念，在生命周期的不同階段，有不同的服務職責和服務流程參照，具體如下：

簡要了解之后，我們再來了解下和其他規范的關系，2001年，英國標準協會（BSI）以ITIL為核心發布了國家的標準BSI15000，隨后2005年左右，國際標準化組織ISO以英國的標準化和ITIL為基礎，又發布了一個IT服務管理規范ISO20000，確保IT服務管理的理念在全球推廣，在ISO20000的IT服務管理規范中，同時吸收了ISO9000（質量管理規范）一些質量管理思想的要求，

COBIT是IT治理的框架和體系，我理解IT治理應該是一個全域的IT資訊系統戰略規劃和指引，是一個統領性規范，如果企業完成其IT治理的目標，企業應該參照實施多個規范完善相應的治理，比如說IT服務質量標準化ISO20000、專案管理規范、安全管理規范、軟體管理規范CMMI、安全管理規范、質量管理規范等等， 

二、ITIL的價值

不得不說，IT服務管理是IT部門的福音，在此之前，IT部門可能都不知道自己要干什么，是不是我就負責做資訊系統建設就可以了（以前電信的經歷就是如此），通過ITIL，IT服務部門找到自己部門的業務價值描述，但是單憑一己之力，貌似很難實施起來，都怪體系太龐大，因此市場上出現了一堆的IT服務管理（ITSM）產品，基于這些產品和概念，又出現了一堆的IT服務咨詢公司和顧問，可以說目前ITIL的行業和生態還是不錯的，

ITIL最大的價值是提供了一套最佳實踐的標準和規范，的確對于很多企業來說，特別是一個大型的企業或者組織來說，都可以通過這套實踐標準把方向和職責梳理清楚，比如說CMDB、容量管理、事件、連續性管理、成本管理，此時也改變了IT部門的傳統定位，你除了寫代碼開發系統之外，你還有其他方面的作業要做，

既然ITIL是一套參照的最佳實踐和描述，它也只是提出了一個業界通行的標準，因此在結合每個企業實際的程序中，由于每個企業的矛盾點和問題點必有不同，實踐的路徑和方法論也有不同，特別是傳統企業，此時匯入ITIL就需要相應的產品支持和咨詢支持，而互聯網則壓根兒就沒有完全照搬這套，貌似運行得也還行，

剛剛說互聯網企業很少把ITIL體系搬過來，那是為什么呢？我理解是一種【外力】和【內力】的不同導致，這種內外力到底是什么？“外力”是指“面向用戶”的程度不同，傳統企業（銀行、電信或者其他）很多服務的設計和交付還是基于自己的能力來設計的，而非真正的面向用戶，因此產生的內部IT服務流也是一種緩慢的流，而互聯網的產品從開始設計就考慮用戶的參與，后期的用戶需求的快速變化和用戶價值及時回應產生的內部IT服務流必然是快速而敏捷的，流程性規范顯然應對乏力，且服務內涵已經大發生了大大的變化，而“內力”可以轉換成“結構決定功能”的描述，技術架構本身也決定了上層IT服務組織的設計，IT服務組織最終影響到IT服務能力的輸出，在過去的一份金融作業經歷中，采用的是SAN存盤+刀片技術結構，這種技術架構帶來的就是自身“甲方”化，其次會影響企業自身的IT能力，最后剩下的就是做各種ITIL流程來保證“SAN存盤+刀片”高可靠運行，而互聯網企業本身就是基于一個不可靠的基礎設施來設計自己的IT技術架構和IT運維組織，由此產生的功能輸出是不一樣的，

接下來我會重點闡述我在互聯網企業中所經歷的轉變，這種轉變是一種逐步“去ITIL”的程序，如下圖：

三、運維的關注點轉變

之前說了互聯網企業為什么會逐步“去ITIL化”，粗略講了內外的合力催生下的轉變，接下來我具體談談這種轉變的細節，

1、關注“流程”轉變為關注“工具”

這是最基本的轉變視角，我們一定要把流程藏匿在工具之后，這個工具可以繼續上升成一個平臺，流程是一種靠人來推動，而工具是靠計算機來推動的，兩者在效率和一致性上面完全不同，基于工具自動化的要求，會反向對組織設計提出更敏捷的要求，所有阻礙事務優化的藩籬都需要消除掉，用DevOps最直接的一個價值觀要求來說就是“杜絕浪費”，不是么？流程帶來的是太多的浪費，為什么服務器申請需要發起流程，而不是“所見己即所得”，我們是資源提供者不就是最大化滿足業務需求么？那無規則的使用如何約束呢，這個就是需要技術層面上要解決的，比如是IAAS云服務、彈性應用架構，甚至引入反向的成本機制來約束，如此一來便會不斷促使在技術層面上全域的思考，而不會把很多問題交給流程， 

再者對于x86大規模的互聯網運維基礎設施來說，一則流程根本就無濟于事，流程是把人的能力過度放大；其次不引入“自動化”和“智能化”的工具，則最侄訓讓運維成為能力瓶頸，個人一直是運維自動化的熱衷者，自動化代表著運維的出路和未來，一個關注流程而忽視工具的運維才是真正感到危機的運維， 

2、關注“規范”轉變為關注“效率”

流程型規范帶來的就是約束，約束本身是為了確保大家的行為不要偏離方向，看似是一種優勢，實則不是，ITIL對變更管理的描述，書里面給了一個復雜的參考流程圖，目的就是為了確保變更不出問題，可事實是這樣么？我們依然還見到很多發布變更走了流程之后還在出問題，此時我們倒不如轉換一個思路，既然引入這么多規則，只會讓事情越來越復雜（人和介面多了），倒不如關注效率，如何讓效率變得越來越高，基于效率之下，去檢視IT團隊之間如何更好的合作和發揮自身的能力優勢？比如剛剛說的發布問題，效率之下，一定會考慮持續集成、持續的自動化測驗、持續部署平臺、立體化監控、技術架構優化等多種工具手段，而不是把問題拋給流程及流程之中的人， 

3、關注“分工”轉變為關注“合作”

ITIL是D/O分離的代名詞，強調了彼此的分工，而非合作，D/O分離也是造成運維成就感不強的核心原因，在互聯網企業中，必須杜絕，基于這種分離或者分工的模式，會造成組織間的彼此資訊不透明，不透明之下就進一步失去對周邊團隊的未來方向性了解，彼此也就沒法向對方提出更高的要求，變成一種簡單的結果性要求，所以很多時候對方說我希望是什么樣的，而不是考慮【我】還可以做什么，才能達到【我們】希望的樣子，我把這種合作推向更本質化的要求上，叫“共享責任”，責任隔離只有【我】存在，責任共享才是【我們】，前幾天有個騰訊的運維朋友告訴我，他們現在研發會主動把研發人力投入到和運維相關的研發作業中，我聽了之后都有點小感動， 

4、關注“服務”轉變為關注“價值”

ITIL是把IT看成一個個的服務，運維是IT服務的最直接的提供者，可以說大部分流程服務都和運維相關，“服務”是看我能為你做什么，而“價值”則是看運維和研發一起用戶能做什么，運維此時就需要把自己的服務者角色上升到價值者的角色，站在用戶的角度去思考問題，“如何讓用戶使用我們產品更爽”（技術運營）+“如何讓用戶一直使用我們的產品”（產品運營）都會落到如何為用戶提供價值的服務上來，技術運營尋找自己的技術價值點，產品運營是尋找自己的產品價值點，服務者角色，認為產品和功能交付，IT的作業則結束，而面向用戶的互聯網產品下的技術與產品運營則需要考慮迭代和倍訓， 

5、關注“業務”轉變為關注“用戶”

ITIL的整體框架上可以看到，ITIL解決的是IT部門和業務部門如何銜接的問題，面向的是業務需求，ITIL的很多流程都是為部門間的協作設計的，比如說事件流程、問題流程等等，非常重要的ITIL業務連續性管理，是和業務關系非常緊密的一個流程，在我所經歷的互聯網業務中，都沒有為這個流程做過單獨的設計，而是用戶角度的產品必然性要求，當真正的故障產生的時候，一個敏捷回應的團隊更加重要，對于一個時刻變化的IT架構來說，業務連續性管理很難跟上，最后這個問題就交給技術架構本身來解決，減少對人和檔案的依賴，

站在“業務”角度和“用戶”角度看IT服務也是完全不同的，“業務”角度是關注的這個業務功能交付程序怎么樣？多少用戶使用？等等，而站在用戶的角度，運維還需要回答“用戶”使用這個功能感覺怎么樣？需要細化到一些技術指標上去更好的度量， 

6、關注“事務”轉變為關注“優化”

一個事務性團隊在流程中能找到最好的歸宿，見過有些運維團隊把日常的事務要求作為考核要求，比如說某種服務要支持多少單，失敗率多少等等，這種要求不能產生任何輸出，只會讓一些團隊為了流程而流程，這也是一些團隊不愿意放棄ITIL的原因，而優化型團隊則更多的從用戶的角度去尋找優化點，不斷的去思考，除了流程，我們還能做什么？甚至去顛覆流程帶給自己的束縛，

優化型團隊是帶著強烈的資料化運維思維的團隊，其表現出來的驅動力會更強，在資料中能找到很多優化的方向，在一開始就要抱著“采集一切”和“分析一切”的訴求去對待資料，當早期我所在的騰訊部門把海量服務間的介面呼叫資料都收集起來，我對“采集一切”和“資料價值”就有了深刻的理解，基于這份資料可以去做真實的業務告警、故障定位，可以做服務容量預測，甚至是自動化變更等等， 

7、關注“推動”轉變為關注“拉動”

推動和拉動是兩種不同的做事方式，帶來的組織行為也差別很大，“推動”是靜態的，被動改變的，而“拉動”是動態的，自適應的，ITIL的流程觀反復天生造就了其中的部門或者人在流程中的分工和責任制衡似的，帶來的優化力實在很小，當流程形成之后，團隊容易進入慣性，接受一種自然狀態，不愿意做出改變，改變就意味著承擔更多的責任，而“拉動”是自適應的，用戶驅動的，工具驅動的，你能看到很多互聯網運維團隊都處于一個自我演變的狀態，時刻讓自己的狀態變得更好， 

四、幾個實體

1、故障報告

大家可以仔細留意一下自己的故障報告，看看解決措施是怎么寫的，能看到運維個人或者團隊的一些思維和理念，針對故障，很多報告中寫到讓運維人如何更快的發現故障，如何更快的處理故障甚至如何更快的解決故障等等，然后還寫一些流程保證的措施，殊不知人就是最不可靠的哈，因此通常一個線上故障產生的時候，事后的故障回顧首先需要想到的是技術解決方案是什么？而不是靠運維人，

前幾天線上服務出現一個故障，行程Tl狀態，監控已經探測到服務例外，而這個時候運維的一個忽略，問題持續了一個晚上（告警太多，狼來了的故事上演了），而這個問題處理特別簡單，dump出行程狀態資訊以及服務重啟一下就解決了，最后我們給出故障的解決措施：1）本地服務增加一個通用守護的功能，探測服務例外后，直接服務例外干預；2）其次把帶來服務組件更換成另外一個，使之具備對服務的七層檢測能力，便于更好的服務容錯，以上解決措施就大大減少對人的要求，其實我們都知道，誰會愿意大半夜的起來處理個小故障呢，人是做不到7*24的，如果運維變成7*8，是不是覺得自己不苦逼了？ 

2、應用變更流程

這是騰訊早期部門的發布流程圖（有點和ITIL變更流程類似），我記得當時還有一個流程系統，里面有以下很多角色，很多角色和這個發布事務都沒有關聯關系的，在流程只是點擊一個按鈕而已，

當后續的發布平臺建設起來之后，這個流程就沒用了，所有的發布都在線上完成，并且運維已經從發布流程中徹底退出，再往后，為了解決發布后的服務檢查而不依賴運維，實時的發出發布變更報告，供研發、測驗和運維查看發布狀態，把發布程序倍訓起來， 

3、設備維修流程

早期的設備維修流程都是機器負責人（應用運維）發起流程，然后提交服務臺，服務臺統一派單給設備管理員處理，而云端IAAS服務的出現，則顛覆了這一模式，但服務器出現故障的時候（和應用運維無關），直接把服務器放到故障池中，不需及時維修，因為云平臺對硬體的故障的容忍度更高，此時維修人員根據系統設定的派單規則對設備進行批量的維修或者更換，大大減少成本，可以說云技術的出現，無狀態技術架構大大降低對人的依賴和對設定流程的依賴， 

五、總結

“去ITIL化”更多的是去ITIL流程化和對其的照搬，其實ITIL中的很多服務思想依然值得借鑒和學習，比如說CMDB、能力管理，但最怕是被ITIL框住，不結合自己的實際直接匯入一些ITIL流程，如成本管理、業務連續性管理等等，費力不討好，而更多需要結合實際考慮建設那些為用戶帶來價值的服務和平臺建設，我們一定要“去ITIL”帶來的靜態流程觀，我們需要DevOps動態工具觀去提升運維能力，

綜上所述，我的觀點是把ITIL的部分服務思想和DevOps結合起來，而運維是“去ITIL”的首要角色，如此才能構建真正的面向用戶的IT服務能力（不限于ITIL），其實不是它或者我變了，而是我們服務的用戶變了，

標籤：其他

上一篇：記MacOS抹盤后--使用U盤安裝MacOS實錄

下一篇：一文解讀CQRS (轉)