從接觸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向服務轉型的遠見，我在這里想說的僅僅是：為了服務質量的真正受控，我們可能需要滲透到整個服務對象的全部生命周期進行管理，最好是有一個統一的方法與標準指導，運維工作不應該只在接手服務對象時就開始考慮，而是在服務對象設計時開始考慮，即：運維從設計開始！