從接觸ITIL到ISO20000實施，再到ITSM工具的規劃與實施，中間經歷了一段學習過程，也經歷一段較長的思考過程，以前更多是著眼於某個流程的內部設計，然後是各個流程之間的介面設計，漸漸的開始更多想的是一些框架性的問題了，這裡頭倒也沒有一個非常完整與成熟的想法，只是越發為ITIL或ISO20000是不是能真正解決當前IT應用的問題而感到困惑，於是便有了本文的產生，以記錄與啟迪思考。

ITIL（無論是哪一個版本）、ISO20000、COBIT、ISO27001，這些都是IT服務管理的範疇了，但這些方法論或標準都是面向服務過程的，即根本的一個事實是，當應用這些方法論時，你的服務物件（你可以理解為IT設施，或網路、資料中心、應用系統等等）已經佈署完成，這些方法論永遠面向是服務物件的後續生命週期，而此時服務物件已經很大程度上固化下來了，這種情況類似於：現在有一個非常成熟的方法論去規範管理汽車的售後服務過程，但汽車的前端過程，比如象設計、製造都沒有覆蓋到，在這種情況下，汽車的使用與服務能得到最好的保障嗎？客戶享受到更好的駕駛體驗，決定性的是後續的服務過程還是前端的設計製造過程呢？。許多情況下，當服務物件的設計與佈署的前端過程中的問題會造成後續服務過程的永遠的痛苦與掙扎，許多在服務過程中不斷碰到的問題，事實上如果在設計與佈署過程中考慮到了的話，會為後續節省更多的資源與成本，服務管理做得再好，在當前的框架內是無法滲透到前端的設計與佈署環節的，這就面臨著，當服務物件的前端過程做得不好時，服務管理能做的只是“維繫”一個現狀，甚至無法把服務過程中的知識經驗反饋到前端過程，形成一個閉環，這種知識反而是對一個服務主體是最有價值的，比那些事件、問題、變更知識庫要有用得多，當前的框架內是沒有考慮這些的。尤其當應用系統這種服務物件時，更是如此，雖然有一些小問題可以後續補丁，但有一些根源的問題往往只能忍受著、服務著。

CMMI等方法論，是面向軟體類的服務物件的前端過程的，但是CMMI與ITIL或ISO20000等上面無法是理論結構還是著眼點亦或者是流程假設都是沒有考慮過相融的，變成CMMI只考慮開發過程中的問題，ITIL與ISO20000只考慮服務過程中的問題，服務物件的兩個核心的生命階段的管理可以說是斷層與脫節的，也沒有一理論框架來解釋指導這一個完整的生命過程。而且CMMI只面向軟體類服務物件，事實上當前的服務物件範圍要更廣，ITIL3.0開始有比較清楚的服務生命週期的概念，但我認為這是不夠的，生命週期的概念不應該是面向服務的，而應該是物件導向的。當前世界需要的是一個面向服務物件的規劃、設計、佈署、服務的完整生命過程的框架與方法論，這個框架需要完成融入ISO27001這一標準，這個框架應該是完全“物件導向”的，它會提出明確的要求來規範在任何過程的服務物件，不管是軟體還是網路亦還是IDC，它會要求在每一個過程如何考慮資訊保安，這樣才不會導致標準的分裂與無法統一作業的現象，實施過CMMI與ISO27001與ISO20000的人會發現，這幾個標準作用於同一個組織時，你會無以適從，非常難以調和。這個大的“IT管理”標準，是可以分層級與結構化的，只有一個成熟而全面的服務商才可能完全實施並得到這個完整的認證，而象一些僅僅面向服務過程的只需要實施並得到關於服務管理部份的認證，重點在於一個完整的標準會真正統一規範IT業，讓全世界的IT組織與人員有一個全面的平臺作業。當然這個標準的整合力度與難度也可想而知，但我個人相信隨著服務管理方法論的成熟與發展，在一個不久的週期後，人們會發現這一服務管理標準的侷限性，最後一定會碰到“天花板”，因為很簡單一個邏輯在於：我們需要是IT應用的效益最大化，服務管理過程並不能從根本上改變現狀，甚至不能從根本上決定服務的質量（因為服務的質量很大程度是由前端過程決定了），加上其它的緯度的標準要求，造成框架性的割裂，統一標準的面向整個服務物件生命週期的方法論出現是必然的選擇。
上面談的問題，基本不是一個IT組織或個人可以完成的事情，除非你有IBM與HP這樣的資源與理論力量。那麼很現實的問題是，在沒有一個這樣大而全的框架支援的情況下，我們如何做，才能更好的發揮IT應用的效益呢。我們可以從一個IT提供與服務商的角度來看看，看看我們如何可以建立一個小體制來對應框架的缺失，為了避免服務物件的寬泛而無法聚焦說明，我們就以應用軟體類的服務物件為例說明
1)在規劃設計時考慮運維問題
當在規劃設計一個應用系統時，在目前絕大多數的軟體型專案中（非套裝產品），在軟體設計時甚少考慮軟體日後的可維護性，也很少會在軟體功能設計時為維護提供便利性。事實上合理的情況是，首先要著眼於客戶的業務分析，同時要結合日後軟體佈署、維護、升級、調整。有許多系統設計時連上線佈署都未考慮，這樣面臨的局面是，可能是一個很好的產品，但實施上線非常困難，又或者剛開始上線使用時，功能符合業務的需求，但一旦發生變化，升級變更非常困難，後續的維護工作也異常被動。所以當前僅僅是根據客戶需求一方面的資訊來規劃與設計軟體是不夠的，需要同時基於後續的服務過程需要來一同規劃設計，目前大多資料軟體開發型專案，光是前者就很少做得足夠好的，國內真正意義上的優秀軟體規劃與分析人員太少了，同時優秀的合格軟體實施顧問亦少，一款功能不是很強大的軟體，如果實施顧問足夠優秀，事實上可以很大程度上彌補軟體不足，因為可以將客戶的業務流程與制度做相應的重組與融合，反之亦然。我想這一塊領域還有相當長遠的路要走。
2)在規劃設計時考慮服務目錄
在規劃設計一個應用系統時，到底在軟體實施上線後，可以做哪一些服務，哪一些功能、與介面是需要維護中重點關注的，要用怎樣的頻度去做日常的檢查與維護，多久做一次資料最佳化，這些目前也是很少被考慮的，某種程度上可以說，這是軟體開發商的短視，從利潤榨取或商業利益而言，軟體的規劃設計開發過程的純利潤是不高的，同時是非常短期的，但日後漫長的服務過程，可以為軟體開發商提供持久不斷的收益。從軟體開發商的角度而言，從純商業的角度而言，除了滿足客戶的業務需求外，如何在規劃設計軟體時，設計好後續的服務目錄（服務內容），這是非常重要的，如果一款軟體完成上線後，軟體開發商無法在專案的後續過程中挖掘商業利益，這某種程度是一種商業失敗，開發過程相當於種下一個種子，軟體開發商在規劃設計過程中對服務目錄的設計，就取定這顆種子日後到底結出怎樣的果實出來，事實上這裡面有大量的文章可做的，這同時也十分有利於軟體穩定。以當前大多數軟體開發商的做法，都是把軟體折騰出來後，把款項回收完成，然後根本不太重視後續的服務過程，基本上是客戶報障時或有新需求時，才響應做一些服務，而這些服務基本上是沒多少收益的，一定要在軟體規劃與設計時埋好服務的伏筆，在合理的情況下，當軟體完成規劃設計後，基本日後的服務目錄，與服務體制，以及日常的維護手冊都是可以出來的，因為在規劃之初，設計者是清楚哪一些地方是需要進行經常檢查與維護的，服務受體到底有多少人，需要配備多少以及怎樣的服務人員，基本上此時就可以大概知道日後的服務收益是多少，做多少服務合同的報價。在現實中經常看到這樣的情形，在軟體開發合同一般開發商會承諾有一年的免費維護，當軟體實施上線後，開發商也可能是不重視服務也可能是為了控制成本，就留下極少的資源對應這個免費的維護週期，這樣當免費週期結束後，由於之前的維護過程只投入了很少的資源，客戶只給了很低的服務價格，這樣就掉入一個迴圈過程中，事實上對客戶與服務商雙方都是不利的。
3)在規劃設計時考慮資訊保安
在軟體的規劃設計時，資訊保安同樣是一個需要被考慮的因素，一些高保密性的系統除了需要技術手段外（比如CA認證），還需要考慮管理手段，比如象核心賬戶的管制，敏感資料的備份、讀取、操作。都可以建立起制度出來，目前多數系統都是在系統上線時甚至是維護時，才開始設計配套制度，這是有些晚的，因為資訊最充足的情況是在客戶處進行業務調研的時候，既軟體的規劃與設計者們才是資訊集中者，他們最清楚系統要做成什麼樣子，需要一套怎樣的管理機制配合，這也某種程度上決定了軟體規劃設計者同時是一個需要理解“管理”本身的人，而不是現在技術專家們。
4)在規劃設計時考慮配置管理
在專案初期，軟體規劃設計時，基本已確定了核心的配置資訊，要佈署多少怎樣的裝置，要用到哪一些元件，要同哪一些系統做介面，相互傳遞什麼資訊，要用到哪一段網路，整個系統的拓撲圖是怎樣的，哪一些裝置是熱點，需要備機。這些都會相應的完成，即此時CMDB要進入多少個CI是明確的，而且這些CI之間的相互關係是如何的也是明確的。同時從CMDB的角度而言，在規劃設計時要儘量避免關係過多，以避免一個故障造成大範圍服務中斷，儘量形成可插拔式的，故障只形成單點。當這一個過程中完成後，事實我們這個時間非常清楚日後的服務受體（到底是哪一些組織的哪一些使用者使用系統），我們也非常清楚日後的服務物件（上述的CI），我們也非常清楚自已的服務主體（我們配備怎樣的服務團隊），我們還清楚了服務目錄（日後需要從事哪一些日常的主動維護活動），這時服務管理就非常容易展開。
5)運維如何促進規劃設計
在漫長的運維過程中，我們會發現許多問題，分析下來我們也會知道許多問題是在軟體規劃與設計時可以避免的，同時運維過程中也會積累大量的業務知識，這些對一個軟體的規劃設計是非常有幫助的，也對一個軟體開發商的開發能力提升意義重大，我們說公司的能力如何如何，事實就是依靠這些知識匯聚而成。這方面是一個比較難的課題，因為當一個軟體開發商初具規模後，服務團隊與研發團隊肯定是不同的部門，要讓這兩個不同團隊的知識可以平滑傳遞，不然研發能力無以提升，一定需要把運維過程中的經驗知識轉化為下一次研發活動的輸入，這樣才能形成閉環，不斷提升，服務質量才能更好。

一直以來，國內的公司都忽視了運維的重要性，這裡說的重要性是指對業務影響的重要性、管理的重要性、商業的重要性。長久以來運維成了低技術含量，沒有多少商業價值的業務。雖然近幾年慢慢得以好轉，我們也開始慢慢跟著ITIL們的後面小跑了，但真正如何做好運維，怎樣做才更具商業價值，還是在跌打滾爬中。這裡也有一個全世界大的趨勢所在，前面的數十年中，國家與商業組織都在大量的投資IT建設，所以以前建設是焦點，問題是如何做好建設，慢慢的大部份的建設工作完成後，資訊化也覆蓋到了組織的方方面面了，現在面臨的如何管理好這些IT設施，讓以前的投資更好的發揮效益以及持續穩定的服務於業務，所以未來運維將成為熱點，這裡不得不佩服郭士納在九幾年就帶著IBM向服務轉型的遠見，我在這裡想說的僅僅是：為了服務質量的真正受控，我們可能需要滲透到整個服務物件的全部生命週期進行管理，最好是有一個統一的方法與標準指導，運維工作不應該只在接手服務物件時就開始考慮，而是在服務物件設計時開始考慮，即：運維從設計開始！[@more@]

運維從設計開始-轉載

相關文章