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

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

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

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

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

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

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

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

可用性：該服務(wù)對象存在哪一些可用性的風(fēng)險

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

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

安     全：服務(wù)對象的安全缺陷有哪一些

文     檔：服務(wù)對象的專屬文檔有哪一些

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

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

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

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