如何以項目的運作方式進行運維管理
嘉賓介紹：
陳貽泰，凡客誠品系統運維部高級經理。目前在凡客做運維工作，負責IDC機房和網站業務的技術運營，以及企業內部IT的系統及網絡運維。
從事IT基礎設施方面的工作十多年。曾在武漢微軟技術中心專門為給各種不同行業、大中小企業做IT規劃和建設，后來加入了凡客誠品，全程深度參與了公司的系統及網絡基礎設施的建設。
引言
作為企業IT的主要技術負責人，在逐步建立起支撐全國上萬員工的企業IT系統的過程中，對互聯網運維和企業IT運維、外網與內網、甲方和乙方之間在IT技術運用和管理實踐上有深刻的感悟。
以下我談一下本人在運維管理或者稱為企業IT管理上的粗淺想法及具體應用。
曾經的我是怎么看待運維工作的?
之前聽騰訊劉棲銅同學講到運維是技術運營，我覺得挺好，很高大上，意境很令人向往!我之前有時候會粗鄙的認為運維干的就是照看一堆網絡設備、服務器、各種操作系統和應用軟件……讓他們有效率和安全穩定的運行好。
對于運維來說，汗流浹背扛著服務器上架是常有的事情，他這一說，我就聯想到網站運營、企業運營、運營某某大項目……反正感覺“運營”這個詞就比較大氣，這讓一直以來苦逼的運維汗水一下抖落，似乎神氣了。
我對運維工作的簡單分類
再重復單調的工作也需要有一種超脫的心態去面對，跳出自身才能更好的做好本職工作。運維就是一項比較單調的工作，根據技術分類，運維有做機房管理的，有做網絡管理的，有做系統管理的，有做數據庫管理的，有做各類應用系統管理的。
從管理這個層面來看，無論是哪種技術類型，根據處理事情的特性，比如周期長短、量大事小、日常重復、緊急等等，我都把運維分為兩大類。一類是日常(類)運維，一類是項目(類)運維。
我這樣分類源于五六年前在PMP培訓過程中的感悟，PMPBOOK書中有一段這樣的話：“項目源于人類有組織的活動。隨著人類社會的發展，人類有組織的活動逐步分化為兩大類型：一類是連續不斷，周而復始的活動，人們稱之為’作業’或’運作(operations)’，如企業流水線生產大批產品的活動;另一類是臨時性、一次性的活動，人們稱之為’項目’(project)”。
日常運維就是屬于***類的活動，稍大的角度來看，我們的整個運維工作可能都談不上是項目。但如何使得本來是做周而復始的工作變成一次性的工作呢?還記得在上學的時候說到微分的概念吧!如何求導?這兩個問題好像奇妙的產生了火花，通過微分的方式我們可以把一個曲線函數看做是一段段的直線，從而可以求導。
項目運維是什么?
在實際的工作中，一個持續性的工作是否可以通過微分的方式將連續有波動的工作做成項目?
我想是可以的。通過將不同階段的任務或周期性的任務進行切割和統籌安排，一個周期性的運維是可以劃分成若干個微小項目的。通過對微小項目的管理建立起整個運維工作的體系。
微小項目的管理方式，也稱任務式管理。這種任務式的管理方式可以有助于我們緩解長期易疲勞的運維工作。而且還可以形成快速迭代體系，讓方法變得更靈活，注重交付結果的同時也關注過程。
下面我們根據幾個例子來說明。在幾十人的運維團隊，我們實際上也是根據會議溝通和日常工作來實現了對分類的認識：
對運維分類的進一步解釋
日常運維，就是咱們運維人員日常經常處理的工作內容。比如：
- 系統運維人員處理一臺服務器某個目錄磁盤空間不足的問題;
- 添加或者修改一個DNS域名A記錄
- 機房人員更換一塊有故障的硬盤
- 網絡人員對某個出口線路帶寬有異常的流量檢查
- 桌面支持人員給同事安裝一個Office
- ……
對這類事情處理，講究的是 “短平快”。
項目運維，就是非日常運維的內容了。大到包括一個IDC機房或者辦公樓的系統網絡建設，小到比如升級系統內核，因為涉及重要和關鍵的業務，或因技術上升級過程比較繁瑣，需要考慮的方面比較多，也會放到非日常運維這塊。
要重點說明的是，團隊在日常運維中遇到一些故障，在快速解決后，會在統計中發現經常出現類似現象，也總會拿出來作為問題來解決。不管是理論意義上真正的項目，還是問題類項目，或者其他具有項目特征的事情，只要不能在日常運維類別中快速了結，都會考慮以項目的方式來進行處理。
這里指的是具有項目特征，要處理的事情有很多事情的集合，涉及面比較廣泛，成功完結后有從無到有的深遠影響，也像項目一樣是計劃內的，周期也相對比較長，涉及的資源和人員也可能比較多。
具體其他特征可以參考下項目管理方面的書，但是可不能硬套。所以這類事情個人認為按照項目管理的方式去落實和推進非常合適，這也是為什么稱為項目類運維。
總之，通過綜合處理各類運維事情的共性，做了一個二分法，日常運維和項目運維。非此即彼，也好劃分。
如何立項?
在實際操作中，由于沒有太明確的定義，一般同事也不好掌握。但既然是項目，還是有立項門檻的，***能不能立項，還是需要幾個人討論后才能說了算的。但這幾個人怎么確定?
答案是，當然不是終身制的所謂立項委員會，原則上根據這件事的利害關系及簡單好操作來確定。
在實際工作中，團隊的例行會議中就可以了，畢竟負責各個技術方向的主管人員都是技術出身的，能夠把握好方向。舉個例子：
我們發現日常運維中某個路由器CPU始終很高，連續很多次觸發報警，日常運維中通過分流可以緩解。但是，實際報警時候流量負載并沒有到達設備的設計上限。初步推斷就知道需要進行更深入的排查。這時候由誰來發起立項呢?
- 通常網絡管理員會在周期工作報告中匯報這個問題，希望提升成為項目，以查找問題根源。
- 當然這種情況也可能是他的主管領導，在查看日常運維處理報表中發現這個事情經常出現，而希望提升為項目。
- 另外還可能是服務器系統管理員，發現最近某些服務器或者應用網絡延遲很大，進而發現這個問題比較嚴重，于是在運維部門較高的例行會議上立項。
無論哪種，在內部技術類的周期例會上，或運維管理層會議上，都會分析這些情況，大致評估對業務的影響程度和主要解決這個問題的技術類型，決定立項和負責人、大致的項目目標和起止時間。
項目工作如何流轉?
假設這個問題是在網絡組內部會議討論要立項的，那么項目就在網絡組內部自行組織人員解決。后續處理過程中，如果發現需要涉及線上業務的正常運行，可能需要機房組和系統組人員協助。甚至問題根源可能就在系統組負責的某個服務器上，那么項目會升級到較大團隊級別。
但升級就升級，一般習慣是不會變更之前既定的項目負責人的，除非特殊，否則不會臨陣換將。
過程中管理層可以多出些力來協助項目負責人，尤其是負責人的直接主管領導。我想這對培養團隊人員個人技術綜合素質和提升整個團隊的協作能力是非常有益的。
如何落實運維工作?
既然運維工作分為日常運維和項目運維，就可以分別來落實了。基本原則是思想上要認識清楚每項工作的意義，制度上要落實到位。落實到位***的辦法就是將思想和制度技術化。
“技術化”通俗的講就是通過各種軟件系統來管理運維工作。打個很形象的比喻：
我們日常開車，要對安全有很高的認識(思想層面上)，當然還需要制定交通法規(制度上)來指導我們開車，路上也會設置各種行車線。
比如實線和虛線，路中間的實線就是不能碾壓和跨越的，高速上的實線處還設立了很高和厚實的水泥防護欄，這個水泥防護欄就是思想和制度技術化的極端體現。實線攔不住不守規矩的車，但是水泥防護欄能!
所以思想需要形成文檔來固化，當文檔***要通過技術化的實體軟件系統來固化以協助我們更正確的工作。
有了體現思想的制度和軟件系統，最關鍵的是：要用，天天用。還有，不是所有的文化思想都能固化的，還要培訓和溝通，這些無形的和有形的都需要講，換著方法的講，日日講。
當然思想文化、文檔制度、系統軟件不是一天能完善的，也不是完善了就能高枕無憂的，需要集眾人智慧，與時俱進，不停的進化下去。因為開放、向上、探索本身應該是一個良好運維團隊的文化核心之一。
如何做好日常運維?
對于日常運維，這類事情是運維的主體工作，雖然瑣碎、技術含量一般不高，但是非常影響客戶(外部用戶和公司同事)的用戶體驗，影響運維團隊提供的服務質量。ITIL中的事件管理系統可幫助我們管理日常運維工作。
我們就基于ITIL的IT服務管理思想，結合自身業務情況，公司自己開發了一套事件管理系統。個人認為這套系統最有意義的地方有兩處：
1.使各個團隊或者部門的服務接口化了。
用戶可以根據自己選擇的事情類別由系統分配給最適合的團隊來處理。原理是各個團隊將自己的工作職責提前進行了菜單化，用戶根據自己的需求“點菜”即可。
比如上海辦公室的用戶outlook有問題了，就可以在事件管理系統中輸入outlook，找到outlook相關的服務項，選中提交即可，系統會根據用戶賬戶里面的屬性分配給上海的IT桌面支持團隊處理。
系統也有分配錯誤的時候，被分配者可以重新替用戶轉給認為正確的團隊處理……我甚至認為應該將這個系統推送給公司所有部門使用，而不是僅僅局限于技術中心。
2.服務質量的把控技術化了。
用戶的問題根據重要情況是分級別的，不同的級別有不同的初始響應時間，響應不及時以及后續處理不及時會升級。
不是原本不重要的事情變成重要，而是無論哪種事情，響應不及時都會逐級報給事件處理人的領導，甚至領導的領導。
當然，還有相關的統計報表，來統計個人和團隊的事件處理數量和質量。所以無論是個人還是團體部門，都像有一根鞭子在背后飛舞。
如何做好項目運維?
對于項目運維，這類事情一般涉及比較廣泛和深遠，更是重中之重了。項目運維類的事情在實際中我一般用來監控比較長期的事情，比如部署某某系統，或者作為問題管理。
基本上是運維部門內部的事情，或者是已經轉化為內部的事情了。因為用戶少，只面向運維部門，所以我們直接拿開源的Redmine作為管理軟件。
Redmine很靈活，需要先理解它是基于任務(issue)的，至于具體怎么用，就需要結合標簽來做，具體就不細談了，感興趣的各位可以慢慢摸索。
通過這個軟件系統，可以彌補事件管理系統的不足。那么事件管理哪里不足呢?
最主要的不足是事件管理最(只)適合對單個零散的、短平快的事情管理。而項目類的事情需要拆分成N個子任務，任務之間也有前后依賴關系等等。另外項目類的運維周期有時候還很長。
這么長的時間沒有處理完，要是在事件管理系統中記錄，那你的KPI就完蛋了。-_-|||
通過項目管理軟件我們實現了扁平化的管理，可以查看到所有正在進行的任務情況，可以細致到下面的一個個子任務。這樣向領導匯報的時候不至于抓瞎，和團隊成員溝通也便于就事論事。
一般情況，子任務都是項目負責人和任務被指派者相互溝通協商確定的，最終干活的人有很大的自主權。
***實踐
在不影響上級任務目標的情況下，給予子任務實施人較大的自主權，比如自己定制細節的任務目標，有助于調動當事人的主觀積極性，因為他在完成自己的目標。
運維都用數據說話
因為運維工作被分成了日常運維和項目運維，并分別有事件管理系統和項目管理系統來監管，有了很好的運維管理平臺，現在基本上可以說整個運維團隊的工作大體上都實現了數據化了。
同時作為一般運維人員來講，這二者也是一個非常好的知識和溝通平臺，工作的好與不好不是領導說了算，是自己平常在日常運維和項目運維中的表現說了算。這樣作為運維管理人員來講同樣就有了管理的利器，團隊的表現也是用數據說話。
寫在***的話
以上看法和做法都是我個人的一家之言，純粹為了交流，每個人都有自己的管理心得，個人覺得只要符合自身企業的實際情況，運行起來圓融無礙，就是很好的方式方法了。
好的方式方法里總是有普世的智慧之光，希望能為大家提供一些借鑒的價值。
