IT運維支援如何轉化為服務

 

說明： 運維體系可以從組織、流程、工具三塊進行擴充套件，前面幾期的文章對運維組織中的專業化 進行了分析，並將專業化涉及的線底保障能力、可用性保障能力、運維分析能力（ITOA）、IT運營能力單獨作了分解，接下來還將進一步對專業化能力剩下的服務能力、運維開發能力、服務檯、集中操作四塊進行分解，本篇是服務能力。

   

關於IT服務能力的介紹，本期標題中主動式、可量化、構建IT運營服務三個關鍵詞概括了我對IT服務能力的理解，其中IT運營服務在上一篇《IT運營轉型中的ITOM》作了一些分析，本篇從ITIL、ISO20000、ITSS方法論對服務做補充。另外，IT服務能力主要以ITSM方式提供IT服務，關於ITSM的實現方式在之前關於servicenow的文件中也作了介紹，本篇不介紹在ITSM上的服務具體實現，而是從主動式、可量化兩個角度進行擴充套件。

一、ITIL、ISO20000、ITSS中的服務

老規矩，第一章先來對全文命題的名詞做分析調研，本篇的名詞是IT運營服務，其中IT運營在上一篇文章作了分析：即以業務為本，以穩健運維、風險可控為底線，從組織、流程、工具三個維度構建一套標準化、可擴充套件性的運營管理體系，持續提升服務水平，提高企業效能、降低成本。以“控底線、優服務、提效能、降成本”作為實施的業務指導思路，它要為組織架構調整、流程標準化、執行保障、效率提升、服務交付、成本最佳化提供技術支撐。

至於服務，在運維領域中成熟的方法論有個：ITIL、ISO20000、ITSS資料中心運維服務能力成熟度。三者雖然同為指導方法論，也有一些區別，三者的邊界大致為：從定位看，ITIL是一套IT服務管理最佳實踐框架，ISO20000與ITSS資料中心運維服務能力成熟度是一種標準；從內容看，ITIL針對管理流程或服務的最佳實踐做了定義，即告訴我們IT服務應該要做成什麼樣，ISO20000是在ITIL基礎上設計的標準，告訴企業要如何獲得標準化的IT服務管理能力，ITSS從人員、流程、技術、資源四個方面，以PDCA為指導思想對服務成熟度制定了四個持續最佳化的可測量的級別；從物件與認證看，ITIL針對個體，ISO20000、ITSS針對組織的認證。

1）ITIL

ITIL最早來自英國，經歷了V1到V3的升級，其中V3的最大進步是在V2的基礎上引入了服務生命週期的理念，這5個生命週期包含在服務戰略、服務設計、服務轉換、服務運營、持續性服務改進（分別對應ITIL的5本核心書籍），包括了IT服務從企業業務需求到服務支援、交付，再到持續最佳化的內容。5個生命週期大概的意思分別是：

• 服務戰略：制定IT運維或運營組織的定位，角色，需要提供服務範圍，是針對IT服務的戰略性決策。

• 服務設計：根據服務戰略對服務的規劃，對服務進行設計，以滿足企業對IT服務的要求。

• 服務轉換：是將設計的IT服務替代己有管理手段的過程，這個過程要兼顧己有的IT能力有序與新設計服務的可用。

• 服務運營：是將服務真正開始推廣使用在服務支撐過程階段，需要適應企業對IT服務能力的需求。

• 持續性服務改進：是對服務的實施過程中存在的問題進行持續的最佳化。

總的來說，這5個生命週期的設計能看到PDCA的思路，能夠適應業務變化來不斷提高IT服務質量。ITIL可以讓IT運營組織從原來技術驅動的角度轉化為業務驅動，提高IT與業務的一致性，將IT內部管控、可用性、安全性、容量、連續性等管理標準化，提高IT服務質量，可以促進被動到主動，從非透明的管理到可量化、數字可視的管理精細化轉變。

在ITIL的實踐過程中，通常是ITSM的方式進行落地，事實上ITSM也主要以ITIL作為理論基礎進行設計，雖然ITIL提出了差不多30種服務，但使用者在應用ITIL時可以自行決定落地哪些流程或服務，也可以對IT服務進行擴充套件超過ITIL的定義，通常在國內主要應用在事件、變更、問題等內部控制類的流程服務。從我的認識來看，IT服務的思想應該落地在整個生命週期，運維組織中的每一個小團隊，每一個人都應該以主動服務供給作為工作導向，才能發揮ITIL更大的價值。

2）ISO20000

ISO20000是基於ITIL最佳實踐進行構建，是一套透過管理和規範服務流程確保IT服務質量的國際標準。ISO20000的認證適合IT服務的提供者，可以是甲方內部的IT組織，也可以是提供IT服務的乙方，通常來說，獲得ISO20000在一定程度上說明這個組織對管理流程進行了標準化，具備較好的管控能力。ISO20000由規範與實施指南兩部份組成。因為具備標準的認證作用，規範介紹了企業要實施ISO20000的服務管理需要完成的工作，列出一份強制的流程控制清單，認證的企業需要達標。實施指南則描述了一些最佳實踐，是對第一部份規範中的標準進行補充，是希望認證的企業去做這些實踐。

對於我們金融企業來說，透過ISO20000認證的過程中也是一種標準化梳理與落地的過程，這個過程能讓企業的IT運維組織的工作可量化，為數字化工作提供了資料基礎。

3）ITSS.1

ITSS的資料中心服務能力成熟度模型是以資料中心作為研究物件，以人員、流程、技術、資源四個維度的服務能力水平作為分析評估切入點，是由國內提出的標準規範。ITSS提供的這個能力成熟度以PDCA的持續最佳化的思路，將成熟度分為4級，並將能力細分為30幾個能力項，不同級別下的能力項要求有所不同，是一個不斷提升的過程。我對ITSS這個模型的認識是去年做所在團隊能力水平調研時進行了解，從有限的資料學習看，ITSS涉及的面比ITIL或ISO20000更廣，而且更接地氣，從戰略發展、運營保障、組織治理等多個方面進行細分，是企業細化IT整體服務能力，量化能力成熟度的一個比較好的模型。

4）其它

關於運維/IT運營方法論，業內分享更熱的是以devOps、AIOps這類思想，有不少新興的2B廠商或業內大牛會認為ITIL的流程管控過重，認為ITIL己不能適應現在運維管理的發展需要，應該採用更敏捷的方式構建運維管理體系。現階段，我對這種觀點幾點想法，第一，devOps、AIOps是一種更為先進的理念，也有不少組織獲得了成功，但現在更多的聲音是認為devOps這類是一種思想，標準化程度與及周邊的工具支撐還遠不如ITIL、ISO20000、ITSS成熟；第二，很多認為ITIL是落後思想的觀點可能是出自未真正落地ITIL的組織，或將ITIL理解為框住自動化流程的審批類思想，或是因為很多ITSM的廠商在推動業務時主要以內部流程管控為主等等原因，其實如果真正以ITIL的服務全生命週期的思想去構建ITSM，ITSM的構建不僅能提高IT管控、服務水平能力，同樣也能提高組織的工作效率，就像servicenow官網中提到的ITSM產品特點：提升效率與交付能力，轉變IT影響力；第三，在金融行業內，以務實的角度看，ITIL、ISO20000、ITSS能為企業帶來更快、更經濟的成效，適合在整個組織中落地，devOps則可以作為區域性環節的關聯補充。

2、從被動到主動

被動一詞很好的體現了運維人員的工作狀態，很多運維團隊以事件驅動的被動操作為主，這種工作方式會導致運維人員的工作無法連續性，服務交付碎片化，IT資源缺乏統籌協調，不利於服務質量的持續提升。我歸納了幾點關於主動服務的思路：

精細化分工：要打破被動式運維的工作狀態，最重要的是要有一個IT服務可持續最佳化的機制，透過不斷的分析當前組織存在的效率、質量、安全等問題，並標準化流程，構建工具來持續最佳化問題。精細化分工可以從兩個層次改善持續最佳化的問題，首先，針對以往操作性的工作進行歸納，有助於提高這類工作的熟練程度與服務質量，也有利於集中資源對這類集中式的操作性工作進行分析最佳化，類似於ECC的事件集中管理、服務檯、集中資料維護、辦工支援等；其次，從整個組織看，流程的標準化、工具的引入也需要有獨立的人員去受理痛點需求，主動分析流程管控不足、自動化程度不夠、效率不高等現狀，精細化分工有助於從原來被動的人力資源中釋放一部份獨立的人員進行這類計劃性工作。同時，有些崗位分工需要進行調優，比如以往維護經理的一些職能可以考慮獨立出服務經理的角色，這類角色也可以考慮是一個橫向兼職的角色。

客戶管理意識：客戶管理是區別於使用者管理，即需要IT運營組織內的每個角色都要有主動提供IT服務的意識。一方面，組織內的成員需要理解企業、IT運營組織在企業的核心價值是以業務為本，為業務更好的運營提供IT支撐。同時，要讓IT運營組織裡不同的團隊清楚所在崗位的具體職責，理解哪些重要的IT服務能力，哪些是工作底線，針對底線的服務能力需要標準化，並透過數字量化到KPI，建立服務能力的及格線。同時，要在底線的基礎之上，不斷的最佳化服務能力，由圍繞執行保障的能力基礎上豐富到其它IT服務能力上。另一方面，要理解服務消費方。團隊成員要理解服務的消費方是誰，消費方有什麼訴求，比如業務運營的團隊的主要消費方是業務人員，業務的訴求是業務的連續性，更高效IT資源支援；DBA的主要消費方是業務運營團隊，業務運營團隊的訴求是資料庫的高可用、高效能，出問題時快速的資料庫問題定位所需的工具支援；運營工具開發團隊的消費方是業務、系統、硬體、網路的縱向運營團隊，他們的訴求是需要更快的擁有IT工具支援。

主動服務的工作氛圍需要標準化支撐，精細化的分工，團隊文化、持續的最佳化需要標準化的管理流程與工具、專業的人員進行管控才能有序的落地。同時，IT服務標準化可以避免無原則性的服務供給。比方說，業務或研發團隊肯定希望變更交付越快越好，但IT運營團隊需守住業務可用性保障的底線，有些計劃性的流程還是必須要有，我們在實施上要多考慮計劃性，比方說CAB的計劃評審機制就需要在多個層面讓業務、研發、測試提前知道相關規則，讓他們能提供做好計劃來適應這個規則，可以考慮在公司內提前修改應用變更管理辦法，每一年、每個月根據實際情況提供更細化的CAB計劃。

3、從盡最大努力到可量化與視覺化

運維組織裡的管理考核通常以服務檯諮詢響應率，工單處理及時率，應用可用性等指標，故障處理的時效性等，這些考核指標有底線思維的特點，這種特點容易造成運維組織只有及格與不及格的評價，組織內對員工的要求更多的是盡最大努力做好基本保障，這種工作特點不利於IT運營服務水平的持續提升。造成這個問題的主要原因是團隊缺乏量化IT服務能力，沒有量化能力就無法給組織整理一條服務能力的基線，自然無法動態的評價IT服務能力做得好不好，所以IT服務能力要持續提升需要有量化IT服務能力的運營資料支撐，運營資料包括監控（事件、效能KPI）、日誌、CMDB、業務指標、流程或運營運算元據，具體介紹參見ITOA的文章。

有了量化IT服務能力的運營資料，還需要有良好的視覺化。一直以來，不少人覺得視覺化只是一個面子工程，是一個錦上添花的環節，我的觀點是對視覺化的一個誤解與低估，視覺化是工具建設中極為重要的一環，良好的視覺化可以促進工具的落地效率，事實上很多工具專案失敗的原因就是因為不重視視覺化的建設。另外，視覺化其實是將人頭腦中形成的最佳實踐以計算機的方式呈現出來，它體現出我們對運維工作的理解達到什麼程度。同時，我們將運維資料公開、透明，實現資料共享，並透過視覺化讓資料的理解得到一致化，將實現對IT資源與服務能力全域性掌控，進而發揮資料驅動運維。引用一位朋友對視覺化的描述：視覺化是將複雜世界簡單化，讓人能更好的理解。

視覺化的實施不僅僅是單個工具，還需要從工具體系角度進行全域性性的視覺化設計，建立視覺化標準化，比如主色彩的配置，字型，風格，操作互動方式等，同時，建立場景驅動的視覺化也是一個方向，場景驅動的視覺化區別於傳統意義上的門戶，通常來講門戶主要是資訊、呼叫鏈的整合，場景驅動是以日常工作的最佳實踐為基礎進行資料、操作、流程等多環節的視覺化，關於場景驅動的視覺化後續再專門寫文章總結。

其它：

最近，有朋友提近來寫的文章碼字太多，資訊量太大。為減少枯燥程度，本篇在收尾部份增加一個最近設計的IT服務入口的工具場景來收尾（僅思路，暫未落地）。

1）背景：IT運營工具體系涉及很多工具，且大部份工具是以IT的術語進行設計，對於工具的客戶準確找到工具或服務並不容易，所以需要設計一個IT服務統一入口輔助各類工具更好的服務交付，需支援工具、服務、文件、視覺化看板等服務支撐。

2）參考思路：

參考了servicenow與百度的設計

3）設計說明：

圖一是初始檢視，主要包括服務檢索區域與常用工具區域。圖二是檢索後的檢視，主要包括檢索後的檢視：

- 初始檢視：

在檢索檢視方面，考慮到了IT服務涉及面向IT組織內部的服務與面向企業內IT部門以外的服務，兩者區別主要是後者更關注服務的結果，他們對技術語言的理解能力層次多樣化，往往是採用自然語言的方式獲取IT服務，像一個新入職的業務人員想要IT運營組織為他辦理入職所需要的IT環境的服務全部清單，而不希望瞭解服務目標中細化的辦工機器申請、電話申請、終端IP服務、網際網路許可權、OA許可權、文件協作許可權等零散服務入口，為了更好的最佳化服務，檢索需要為非IT人員提供面向自然語言的IT服務檢索入口，檢索後將提供服務清單。

-檢索後的檢視：

檢索後的檢視主要按不同的內容進行分類，從IT運營服務的特點進行了以下分類：工具、服務、文件、看板，其中工具是指工具入口，由工具工廠支援，服務主要由ITSM支援，文件由運維文件管理工具支援，看板主要是為了支援己有的grafana視覺化工具的定製化檢視