運維服務管理的5大難點及對策

1、運維服務管理的5大難點及對策（總6頁）本頁僅作為文檔封面，使用時可以刪除This document is for reference only-rar21year.March運維服務管理的5大難點及對策以下基于我們公司的情況討論運維服務管理，可能不是非常具有代表性，只是希望找出運 維服務管理中經(jīng)常碰到的難點，以及對應的解決方法。前段時間，一位朋友說了一個觀 點，運維服務是自動化程度最低的一個行業(yè)，很有意思，那運維服務會不會也是管理最薄 弱的一個行業(yè)呢？我接觸運維服務的時間不長，但個人總覺得我們把運維服務搞得復雜化了，沒有看透 業(yè)務本質(zhì)。在運維服務行業(yè)，真正意義上的管理者非常缺乏，我說的管理者”

2、，是用對象 的方式看待業(yè)務與流程的。有時我們過于強調(diào)行業(yè)經(jīng)驗的重要性，事實上在管理領(lǐng)域，行 業(yè)的特性對管理者提出的特殊要求沒有我們想象的多。運維服務尚未真正形成行業(yè)，多數(shù)的領(lǐng)導者不以管理見長，多是從底層或技術(shù)部門提 升而來，視野與管理理念缺乏，妨礙了運維服務管理的成熟與發(fā)展。以下我將對運維服務 管理的一些難點展開說明。項目型管理方式的挑戰(zhàn)當一個組織以項目的形式運作管理時，在管理上積淀是比較困難的。項目本身就是一 個獨立的權(quán)力結(jié)構(gòu)，公司的組織機構(gòu)是按部門、科室式劃分，管理體系也多以部門職能劃 分流程，這時權(quán)力的矛盾就會在業(yè)務運作時產(chǎn)生，發(fā)生資源的略奪行為。要么部門難以管 理，要么項目難以管理。而

3、項目是一個臨時的組織，這種人力的匯聚與釋放都比較麻煩，起用一名人力需要相 當長的磨合期。而公司的任務往往是周期性的（最小時間單位很大），這時人力釋放并不 意味可以馬上投入利用，這種痛苦沒有經(jīng)歷過很難體會到，這比你在ERP中排生產(chǎn)計劃還 要難。運維服務一般是以項目的形式管理的，項目內(nèi)的作業(yè)與部門或公司的管理往往存在偏 差。如果部門或公司處于強勢地位，項目內(nèi)的作業(yè)往往會被沖擊，或者被動敷衍配合公司 的管理。比如培訓，站在部門或公司的角度希望搞員工能力提升的培訓，這種計劃安排， 往往與項目內(nèi)希望做的培訓有非常大的出入。項目的一線主管，往往認為公司或部門不是幫助他們，而是一個麻煩制造者。一旦項 目數(shù)量

4、大時，這種情況越普遍。因為項目越多，上層對規(guī)范、標準化的愿望就越發(fā)強烈， 當一線主管花費越來越多的管理資源，配合公司的規(guī)范與標準時，對項目的控制力就會下 降。一旦發(fā)生問題，上層領(lǐng)導就會認為是缺乏規(guī)范與標準化所致，形成一個惡性循環(huán)。我經(jīng)?？吹揭环N現(xiàn)象，當某個項目發(fā)生個嚴重運維事件時，馬上會短時間把管理資源 堆積起來，對事件進行深入到可怕的分析，然后制訂出一個非常完備的制度，要求每個項 目進行落實。這種做法會起良性作用嗎？我懷疑，因為反應過度了，也有些缺乏理性。資源永遠是有限的，你把多數(shù)的資源花 在防止概率很低的問題上，而讓那些概率較高的問題沒有相應的管理資源去控制，你采用 的措施會妨礙你達到目的

5、。對運維服務而言，你讓客戶用一個最重要的詞說出他的要求，他們往往會說“穩(wěn)定”。 同樣，運維服務管理也是最需要穩(wěn)定的，救火堵漏的做法不可取。先穩(wěn)定你的管理，再去 談改善。永遠處于制度的發(fā)布與調(diào)整中，會讓運維服務管理成為最大的運維風險。我覺得此時領(lǐng)導者的作用非常重要。作為高層領(lǐng)導，由于缺乏細節(jié)信息，對自已的運 維服務管理缺乏信心，一旦發(fā)生問題，就會過度反應，這種現(xiàn)象是非?？膳碌摹Ｗ鳛檫\維 服務的管理部門，一定要想清楚自已應該做什么，你的管理邊界在什么地方。你是一個政 策制訂者，不應該越過項目的邊界去干涉項目的內(nèi)部事務。管理部門負責服務體系的維護與執(zhí)行監(jiān)督，及所有服務資源的調(diào)配，這才是最重要 的。更

6、細節(jié)層面，管理部門應該只扮演輔助角色。運維資源的充分利用問題有時我會想一個問題：做運維的人員，是應該忙還是閑呢這是個很矛盾的問題。如果 忙，那證明你的運維問題比較多；閑吧，證明你運維問題比較少，但你的資源可能沒有充 分利用。那有沒有一種可能，把每一個運維人員的工作安排得都不是那么忙，也不是那么 閑呢運維最大的成本是人力成本，想辦法提高工時利用率，本無可厚非。但分析下來，做 到這一點有時不現(xiàn)實，或者是很困難的。在多數(shù)運維服務中，你的運維對象不是標準化的，尤其是在軟件領(lǐng)域。這決定了你的 人員復用是困難的，因為一個人員的腦子只能裝進幾個系統(tǒng)，而每個系統(tǒng)的升級與處理故 障的知識是每隔一段時間就更新的。

7、舉這樣一個例子：A系統(tǒng)每天的問題處理需要3小時，B系統(tǒng)需要3小時，現(xiàn)在由兩 個不同的人員負責，那是不是可以由一個人負責運維這兩個系統(tǒng)呢？現(xiàn)實肯定是行不通 的。即便一個人可以掌握兩個系統(tǒng)運維的知識，兩個系統(tǒng)發(fā)生故障的時間完全有可能重 疊，還有其它臨時事務排擠在一起，造成服務問題。這種情況下，人力的閑置不可避免。雖然即便一名服務人員的資源沒有充分利用，客戶也會購買你整個的人力。但當這樣 的閑置情況很多時，作為一個商業(yè)公司，就要想辦法去提高資源利用率。這方面好像除了 提高人員的運維能力外，沒有更好的辦法對應解決。服務臺管理問題服務臺設(shè)立也是一個比較復雜的課題。怎樣的服務臺才最有效、最節(jié)省資源？如果僅

8、 僅為了滿足參觀者的感官，讓一幫戴著耳機的熱線MM坐成一片，忙碌著，用甜美的聲音 問著好，確也顯得氣派。但現(xiàn)實情況中，這樣的服務臺很可能沒起到作用，是在浪費運維 資源。項目多時，服務臺的人員恐怕聽不懂客戶在說些什么，尤其當你的運維服務不是標準 化的產(chǎn)品服務時（比如桌面）。比如，一個客戶打電話過來，說我的售車申報做不了”， 服務臺人員如果沒有深入的項目知識，估計連是哪個系統(tǒng)都搞不清楚，甚至連問題描述與 等級都不知道如何定（注意服務臺人員要在ITSM系統(tǒng)中派單）。這時，服務臺可能直接 轉(zhuǎn)電話或者草草記錄下來，其作用跟一個4萬元的語音菜單沒有區(qū)別。更有意思的是，語音菜單會在客戶電話時提示：A系統(tǒng)請按

9、1，這時電話是接入到服 務臺，還是接入到這個系統(tǒng)的一線工程師呢？如果服務臺可以處理這個電話，事實上服務 臺就是一線。多數(shù)情況下，服務臺人員無法處理這類電話，除非你把所有一線工程師納入 服務臺。在運維服務中，當你的服務臺無法做一線支持時，不設(shè)立專門的熱線MM會合適些， 或者把你一線支持人員全部納入服務臺中，把服務臺做成一個虛擬或混合型的。我們的情 況跟上述有些類似，服務臺人員不了解具體的項目知識，需要把電話轉(zhuǎn)到一線人員處；或 者告訴一線人員，由一線人員跟客戶聯(lián)系，最后客戶都不打電話到服務臺了。我個人傾向于把一線人員納入服務臺，取消單純接電話性質(zhì)的服務臺人員，這會節(jié)約 運維資源，但這也會產(chǎn)生一些問

10、題，比如誰來監(jiān)督事件的服務質(zhì)量。運維服務分析問題運維服務中，我們一直強調(diào)改善，改善就意味著一要清楚你的現(xiàn)狀，二要清楚你的目 標。這兩點是要基于大量數(shù)據(jù)分析的，我們說的改善不是針對項目這么微觀的層面，而是 基于整體的層面，這意味著你的數(shù)據(jù)有一個度量標準。這個標準適于不同類型的項目，不 然你根本無從知道你的整體狀況。這里ITIL中的SLM有一個指引作用，但這還不夠，我認為要做到深入的運維分析，需 要以下幾個要素：需要有一個精確的CMDB： CMDB提供信息讓你方便把每一次事件定位，以便知道 什么地方什么組件出了多少問題，在項目層面可以提供精確的數(shù)據(jù)做改進（哪一個模塊是 問題最多的）；在管理層面，C

11、MDB的附帶信息會告訴你，哪一類設(shè)備是我們運維的薄弱 環(huán)節(jié)（如果硬盤的故障比重較大，我們可能換供應商，或者提升運維人員的硬盤維修能 力）。需要有一個橫向業(yè)務分類基準：要基于組織層面，規(guī)劃出一個分類數(shù)據(jù)，以供每一 個項目統(tǒng)一調(diào)用。比如事件的類型，我們可以分為：故障、請求、咨詢、新需求、投訴， 這樣可以跨項目統(tǒng)計，每個周期內(nèi)每一個事件類型有多少。比如事件的分類：我們可以分 為軟件、硬件、網(wǎng)絡、數(shù)據(jù)庫、接口、業(yè)務。需要時間資源的記錄：這一部份的數(shù)據(jù)采集最為困難，也最有價值。它與上面的信 息交互分析，可以知道哪一類設(shè)備花去我們最多的時間資源（CMDB），可以知道我們硬件 故障的平均處理時長是多少（事件

12、分類），還可以知道新需求會花去我們多少時間資源（事件類型）。除此之外，基于員工的績效分析以及運維結(jié)算的數(shù)據(jù)統(tǒng)計都需要基于此部 份信息。運維服務分析，個人的意見是：沒有ITSM軟件，是難以展開的。軟件化管理問題運維服務作業(yè)采用ITSM軟件管理，這本沒有什么值得爭議，說來我也在設(shè)計與推行 這種工具，但應用時的確兩難。有人問我，用ITSM系統(tǒng)對一線工程師到底有什么好處？ 換位思考，如果我是一名一線工程師，我是不愿意使用這種工具的，我快速把事件搞定， 不去填任何信息，來得多快。說什么知識庫與CMDB，我沒有這些時，故障一樣可以處 理。我不是否認我設(shè)計的東西，只是它真正的價值在于平臺與運維服務管理，而不

13、在于具 體的業(yè)務支持。ITSM系統(tǒng)的上線，會降低運維服務成本嗎會提高運維服務的效率嗎我的回 答是不會，起碼短期不會。同樣是修一臺電腦，怎么可能會因為上一個ITSM工具，以前 需要30分鐘，現(xiàn)在就只要20分鐘呢人們一直沒有理解管理軟件的真正價值。管理軟件首先要滿足管理的需求，而不是具體業(yè)務操作的需求。你想提高桌面的運維效率么？SMS 是解決這一方面問題的。上ITSM工具，是為了固化你的體制與流程，讓你的服務體制更 規(guī)范、標準化，形成一面鏡子，把你真實的運維現(xiàn)狀反映出來，讓你的運維服務管理起 來。如果說某段時間增加了你的成本，那么這個成本是你必須付的，這是你以前欠下的 債。用一個不恰當?shù)睦?，學內(nèi)

14、功不能讓你很快打倒一個人，學一個招式可以。但學十年 的內(nèi)功跟學十年的招式相比，前者更具成效，而且當你學了招式一兩年后，你會發(fā)現(xiàn)你無 法進步，因為缺乏根基。要想清楚你上ITSM工具是為什么，你要解決什么問題，如果你不是為了解決管理上 的問題，而是為了提高工程師效率，那么不是你的目的錯了就是選擇錯了。只有當你的運 維服務管理穩(wěn)定成熟后，才能為你后續(xù)一切提升提供源源不斷的動力、方向、決策支持數(shù) 據(jù)，而軟件就是幫助你前行的有力工具。ITSM工具，由于SLA的計算，對事件處理信息錄入有較苛刻的要求，這對需要在廠區(qū) 跑來跑去的工程師來講是比較麻煩的。比如象桌面項目的服務工程師，他們不可能隨身帶 著電腦，外面服務時，都是電話派單過去。事件單關(guān)閉不及時，會引起SLA的計算失真問 題。這都是些負面影響，在軟件功能上很難有什