面向?qū)ο蟮南到y(tǒng)分析與面向服務的設計

申請免費試用、咨詢電話：400-8352-114

不管是ITSM理論還是實際IT服務中，都一直存在一個問題，就是如何設計運維，一個開發(fā)項目如何順利的交接到運維團隊的手中，這也是一個比較讓人頭痛的課題，在ITIL V2、ISO20000一開始就談怎么樣運維，好象業(yè)務就一直就是存在的一樣，尤其是ITIL V2中這種問題更加明顯，它的假設是我們已經(jīng)完成了運維設計或者說服務設計，只需要考慮怎么做服務就可以了，但大家一直以來就無法跳到那個場地上，因為大家不知道怎樣才能到達或建設一個這樣的場地，這從根本上讓許多人與公司只對服務支持有一些認識，而無視服務交付的部份，事實上我們從市面的一些ITSM的書上也可以有意思的發(fā)現(xiàn)，介紹ITIL，一般是從服務臺、事件管理這些服務支持端開始的，反而是服務交付是放在后面講解，這給大家一個錯覺，服務支持為先，服務交付為后，但事實并非如此，只要把理論置入實際的業(yè)務場景，假設一個客戶丟一個IDC運維合同給你，讓你去幫他運維，對照ITIL的方法論，你會發(fā)現(xiàn)你難以下手，連先做什么先操作哪一個流程都不知道，如果沒有服務交付的部份，服務支持的流程是難以聚焦的，或者說缺乏戰(zhàn)略的，因為服務交付在前，服務支持在后。ITIL V3在大的視角上，在一定程度上解決了這一個問題，獨立了服務設計這一過程，但是它又制造了一些其它的問題出來，而且它的解決更多只是哲學概念的，它過于玄思了，缺乏實操指引意義，難以有業(yè)務案例進行推演，事實上到現(xiàn)在，我覺得ITIL的流程框架設計問題挺多，它的概念與邏輯并不清晰，而且相互交互重疊過多，流程的概念在實際業(yè)務過程中缺乏嚴謹，主體的框架更是缺乏美感，可能負責開發(fā)ITIL的團隊，既缺乏業(yè)務的經(jīng)驗，又缺乏哲學家的思維，這里的批評暫切放下，日后有機會單獨寫一篇這方面的文章。

言歸正傳，目前的ITIL的理論與業(yè)務之間，還存在一個斷層，就是明確的指導如何進行服務設計，這就是我試圖說明的內(nèi)容，運維設計這個課題斷斷續(xù)續(xù)也前后思考過兩年了，一直也沒有多少突破，運維設計的結果有了比較確切的定義與約束，也納入體系之中了，但生成這個運維設計的過程的方法與步驟是沒有的。正好前段時間公司在做一個比較大的項目的運維設計，在作業(yè)過程中，對這一塊的想法有了一些突破，但可惜無法驗證整個方法與模版細節(jié)是否可行，因為時間來不及，只能暫且寫下來了。

以前，我們只知道當一個項目轉運維時，我們知道要監(jiān)控要搞備份，于是整理出這一塊的計劃出來，但是缺乏嚴謹?shù)耐评硌堇[過程，我們只知道去做監(jiān)控與備份，而不知道為什么要做，或者怎樣做才是最佳的方式，每一個主機要監(jiān)控什么，它的閥值是怎樣定義的，為什么備份是一天一次，為什么是凌晨的時刻進行，最終我們成為完全依靠常態(tài)的經(jīng)驗去決定一個系統(tǒng)怎樣運維，我們最終一直只知道做，而從來不會去分析與設計，于是我們經(jīng)常會發(fā)現(xiàn)一些很荒唐的情況，與業(yè)務不直接關聯(lián)的對象我們沒有監(jiān)控或備份，不管是處理器密集型還是內(nèi)存密集型又或者是輸入/輸出密集型的服務器，我們一視同仁的設定閥值。最后這種沒有個性化與針對性的監(jiān)控導致異常過多，運維人員最終淹沒在其中，不再對監(jiān)控信息敏感，等到狼來了時，我們重新開始一個輪回。所以到今天，我相信大多數(shù)公司的IT運維是沒有分析與設計的，幾乎所有的系統(tǒng)在規(guī)劃設計時是不考慮運維方案的。我們也是只知道運維設計最終要產(chǎn)出一些什么，但并不確切知道那個產(chǎn)出的生產(chǎn)過程是怎樣的，我想許多公司的許多系統(tǒng)在開始運維之初，是并沒有方案的，而是在故障與問題的鍛煉下漸漸成型。去漸漸的理解運維設計或者說服務設計的作業(yè)過程，這就是我想探討的

首先要破斥的第一個觀念是，一個開發(fā)項目并不等于一個運維項目，經(jīng)常會一些大型項目，會包括若干個系統(tǒng)，由一個團隊負責，最后完成后，交給運維團隊時，運維團隊也通常把它等同于個運維項目，我非常不認同這種做法，不管是實際作業(yè)過程，還是ISO20000的理論，我們都非常清楚的知道我們的管理單位，什么才是一個管理單位，為什么要定義成一個管理單位，到今天我們?nèi)匀徊焕斫馐裁础胺铡?，我們需要明確服務，一個開發(fā)型項目交付給我們時，可能包括多個服務，從過去的經(jīng)驗看，應用系統(tǒng)獨立做為服務運營時最容易控制質(zhì)量與保障資源的，所以運維需要根據(jù)自已的管理需求，重新打包項目，有可能一個開發(fā)項目等于多個運維項目，也有可能一個開發(fā)項目根本不算一個運維項目，比如我們經(jīng)常會去把一些重大的新功能增加或擴容做為開發(fā)項目操作，最后這種項目結束后，我們只會把原有的運維項目做變更，而不產(chǎn)生一個新的運維項目。所以在運維設計時，第一步也就是最重要的是明確定義服務，將服務獨立看成一個運維項目去管理運營。

當我們定義好服務后，需要找出跟這個服務相關的所有組件，即服務對象。到底什么是我們的服務對象，要依據(jù)公司的配置管理顆粒度來，如果有CMDB則更簡單了，看CI的分類體系，CI的分類決定了配置管理的廣度與深度，有一些屬于公用的服務對象，需要考慮好歸屬問題，比如一個服務器上有兩個業(yè)務系統(tǒng)的數(shù)據(jù)庫實例，再比如一些公共的存儲設備，要么放置在一個相對重要的服務中，要么歸屬于公共的服務之中（如公共存儲服務或機器托管服務、安全服務等等），這樣可以首先保障對象不能遺漏，這非常重要。

在確定好每一個服務的所有服務對象后，形成一張服務對象清單與統(tǒng)計表，然后基于每一個對象做組件分析，要知道與記錄每一個服務對象的：

可用性：該服務對象存在哪一些可用性的風險

持續(xù)性：當這些風險發(fā)生時，需要多久時間修復

能     力：服務對象的子能力有哪一些項次，對服務人員有哪一些能力要求

安     全：服務對象的安全缺陷有哪一些

文     檔：服務對象的專屬文檔有哪一些

以上這些可以用一張表格集中記錄下來，每一行是一個服務對象，做完這個過程后，對整個服務的服務對象就比較清楚了，同時還會理出兩個層面的事務出來，首先是清楚了服務人員要做哪一些培訓，比如學習業(yè)務系統(tǒng)的業(yè)務功能及操作配置，或者一個全新的操作系統(tǒng)，其次清楚了要開發(fā)移轉的所有文檔，這兩個方面的事情是運維團隊永遠的痛，開發(fā)團隊從來不會正規(guī)的對運維團隊進行培訓講解，也不會完整而正確的交付出開發(fā)文檔，把這兩個事務理清楚后，可以做為專頂進行管理，這樣即便我們不清楚什么服務設計，把文檔整正確了，人員抓起來了，一個系統(tǒng)的運維就有了扎實的基礎。

在分析完所有的服務對象后，我們就知道了現(xiàn)狀。下一步提出的觀念是面向服務的運維設計，我們需要定義這個服務的客戶是誰，即服務主體，它到底是哪一些公司的哪一些部門的哪一些人員。其次是我們需要定義這個服務有哪一些內(nèi)容，即服務目錄，到底哪一些是我們做的，哪一些不是我們做的，這對理清統(tǒng)一用戶的心理預期與我們的認知有非常重要的意義，然后需要定義這個服務做到什么的水平，即服務級別，最后才是定義這個服務在什么時間才提供，即服務日歷。我認為目前絕大多數(shù)的IT服務的客戶們，是難以清楚表達他們的服務要求的，你不能要求一個Iphone的用戶說清楚要有怎樣的話務服務，你不能要求一個KFC的客戶說清楚要有怎樣的餐飲服務，蘋果公司與KFC應比用戶更加理解什么是服務，所以IT部門不能因為IT服務的用戶或客戶們沒有提出更全面而細致的要求，就認為沒有要求，這是組織的自我限定與封閉。當我們知道了服務主體、服務目錄、服務級別、服務日歷，也就意味著我們知道了目標，前面的系統(tǒng)分析讓我們知道了現(xiàn)狀，這兩者的差距，就形成我們要做的，也就是我們運維時到底要做什么。

我們根據(jù)可用性與持續(xù)性的現(xiàn)狀，結合客戶的服務級別要求，可以知道我們?yōu)榱酥揽捎眯缘那闆r，需要做監(jiān)控以掌握可用性信息，在一旦發(fā)生不可用時，要設計怎樣的持續(xù)性計劃，而持續(xù)性計劃需要一系列的物資與數(shù)據(jù)準備，事實上數(shù)據(jù)備份的主要目的是為了支撐持續(xù)性計劃，這兩者有高度的關聯(lián)性。當我們知道了安全方面的缺陷，我們需要設計加固或控制措施，這些措施或改進也就是信息安全作業(yè)計劃，它會在一個相當長的時間內(nèi)指導我們的安全工作。能力方面，我們知道了有哪一些資源子能力，就需要進行閥值定義，并監(jiān)控它，我們同樣需要知道客戶未來的業(yè)務能力，以了解資源能力與業(yè)務能力之間的函數(shù)關系，同樣的我們的服務能力需要做怎樣的提升與保障，。所以的這些最終都形成作業(yè)計劃，這是既定的要做的，這些要盡可能有手冊編制，所以運維的作業(yè)之中在部份是既定的，它需要完全有計劃進行管理，有手冊進行指導，當服務日歷開啟時，還會有不既定的，如事件、變更之類的觸發(fā)性事務，這些事務的數(shù)量是可以預測的，每一個對象可能的事件、變更的數(shù)量也是需要估算的，這個數(shù)字與服務主體的數(shù)量也是成正比，這些事務清楚后，我們要考慮需要怎樣專業(yè)的人員去完成它，用怎樣的體制去管理這些人員，這就是服務體制，此時我們就可以測算出服務成本，最后需要考慮最終用怎樣的方式去記錄或分析整個服務的狀況，也就是服務報告的設計。

至此，整個服務設計工作才真正結束，剩下的就是跟客戶推銷你的服務設計方案，通過后就是發(fā)布執(zhí)行它，然后在服務周期結束時，根據(jù)服務方案進行服務審計，看當初的設計是否得到執(zhí)行落實，進行總結分析后，可以在第二個服務周期開始前，對服務設計方案進行調(diào)整，再評審發(fā)布出去。