【51CTO.com原創(chuàng)稿件】還記得哥上次跟大家聊到的那個云平臺項目嗎?眼看快要大功告成了，去突然最近空降了一個思路活躍VP，新的需求頓時滋生了許多，而且喜歡動輒就吹“集結號”召集項目組成員開會?？啾频牧缰荒軐⒗泵炊嗟?ldquo;力比多”繼續(xù)全情奉獻并投入到了其中，真是累成了狗!可是哥是有獨立思考和總結能力的，項目中的各種勝敗得失時常被哥綜合到理論上，并記錄在了小本兒上。

好吧，花開兩朵，各表一枝。我們還是繼續(xù)咱們的漫談主線，這次來聊聊項目與服務管理。對于運維人員來說IT服務的產生，發(fā)布和變更都是以項目的形式進行的。如何像日常運維流程那樣管理好每個項目的整個生命周期是值得每個項目參與者去認真思考和不斷試錯的。

IT項目來源于需求，普通用戶和運維人員所提出的IT需求一般較為直接也可能帶有一定的局限性，多期望于某個IT服務的功能、界面和性能等方面。比如說，只是為了滿足用戶一時之需，或是配合客戶某種互動，遷就使用了過于陳舊或是太過hi-tech的技術或服務，就如同打開了潘多拉魔盒一般，植入了一顆隱形炸彈，或是產生了連帶風險。

舉個例子吧。為了跟上潮流，企業(yè)業(yè)務部門提出迅速開同微信平臺并且提供資料下載，這個看似fashion且便捷的需求卻隱含著很多安全隱患。到時候真正出現了數據泄漏或系統(tǒng)被入侵、甚至牽扯到法律問題的時候，很少會有業(yè)務部門或者是項目組幫著IT運維部門尋根溯源甚至是引咎買單的?？梢圆豢鋸埖恼f，這都是血的教訓啊。

因此在立項時和在做分析的階段，需要對各種需求加以引導和管理，淡定，切忌冒進。一般要把握好下述三個維度：

1. 原始問題描述：對要解決問題的敘述，它是需求分析的基礎，因此需詳盡闡明需求的起源。

2. 用戶需求：使用用戶容易理解的語言和圖表描述需要提供的服務以及操作的規(guī)范。同時要做好各部分優(yōu)先級的劃分和定義。

3. 系統(tǒng)需求：開發(fā)出一個簡單界面/功能原型來映射用戶的需求。這除了可以給用戶一個直觀印象之外，還方便團隊程序考慮其如何部署到當前的IT架構中，以及與現有系統(tǒng)的數據流向和兼容性等問題。

可見，對于需求，IT部門應成立項目組，積極的做好分析，確保所制作出的需求文檔和原型能正確地反映用戶的真實意圖。其間可采用的方法包括：繪制模塊關聯(lián)圖、創(chuàng)建用戶接口原型、分析可行性、確定需求優(yōu)先級、編寫數據字典等。甚至項目組可以去主動引導用戶，將需求限定在可實現、可控制的范圍內。

有經濟學基礎的朋友都知道“機會成本”的道理，一旦我們立項的文檔和原型定好的同時就等于放棄了其他的選擇或是項目發(fā)展方向，因此項目團隊除了至上而下的接受往后的 “發(fā)展道路”外，也不要輕易產生后面將會提到的需求變更，以免產生不可以預知的蝴蝶效應，導致項目的最終失敗。

記得曾經見過這么一個段子：女神說要程序猿追求者幫其減肥。他滿口答應并稱自己是助人減肥的老司機。可是次日中午當又看到女神飯后坐在電腦前玩消消樂時，他苦口婆心的上前勸導了半天無效，突然腦洞大開，祭出狠招，去拉下了辦公室的電閘。女神盛怒，說“原來你是這樣的人!”，遂憤憤的摔門而出!望著其背景，他當時懵逼了，沒有上去追，只是默默的念叨著：“不是說好了讓我管住你的嗎?怎么一語不合就這樣?你走，我不送你;你來，無論多大的風雨，我要去給你買串兒。”

大家看到了吧，人都是有惰性和抵觸情緒的，很多事情光有口頭的約定是不行的，沒有形成文字的東西是沒有人會承認的，當然對有某些任性的女人來說，形成文字又如何?Anyway，我們下面來聊聊服務與運能級別管理。

1 白紙黑字

IT部門在企業(yè)內服務的對象是end users，他們對于咱們來說是“詩和遠方以及甲方”。要實現企業(yè)的投資回報率，IT運維團隊需要在服務質量需求、客戶滿意和服務成本之間實現平衡，也就必須在任何IT服務的立項階段著手制定服務級別約定(SLA)，即：IT服務提供者(IT部門)與用戶之間的約定。其內容包括：IT服務的描述，約定服務次數與時間，響應時間，故障恢復耗時(Recovery Time Objective)，故障恢復程度(Recovery Point Objective)，用戶和提供者的各自責任，關鍵業(yè)務周期，異常處理與升級渠道，以及最終報告等。

多說一句：常在河邊走，哪有不失鞋的。在出現IT事故時，運維人員應及時運用郵件/電話/短信等方式告知公司全員，讓大家感受到IT的“關懷”和運作。讓其在碰到問題的時候有了思想準備，不會因為“記幾控幾不住記幾”而大發(fā)雷霆，同時也能樹立了IT的積極、主動和盡力形象。

2 因人而異

應當注意的是：對于同一種IT服務，由于總部和分支辦公室的地域差別以及不同部門用戶的角色差異，服務級別約定有時候需要進行定制，以滿足其要求的差異性。此外，IT部門除了有基于服務類型的“總體約定”，還應制定：“特殊區(qū)域/部門詳細約定”，例如：對總部寬帶線路的品質保證和特別為財務部數據安全的保證;以及“特殊用戶群詳細約定”，例如：對部門經理級別用戶提供移動通信服務的支持力度。因此服務基本約定有利于用戶對IT部門所提供的服務達成共識，避免過高的期望和誤解的產生。IT部門也能籍此作為服務成本核算(下期將提到)的基礎。

3 合縱連橫

IT部門與企業(yè)其他部門之間可以就IT服務進行約定，從而產生那些運營級別約定(OLA - Operational Level Agreement)。這種約定旨在保證該業(yè)務部門的日常運作，例如：保證市場部在外開研討會時所使用IT設備的齊備和可用。這種約定可以避免內部部門對部門“打群架”式的扯皮情況的發(fā)生。此外IT服務上線之前一定要有相應的基礎合同(UC)的支撐，如上網線路保證、硬件備機、軟件技術支持等。此類合同一般不為最終用戶所感知到而且是由IT管理層與供應商簽訂。另外，不得不說的是簽訂的UC是對IT部門的一種合理的風險轉嫁到方式。這種“上帝的歸上帝，凱撒的歸凱撒”式的明確責任的處理方式可以使得IT團隊中事故發(fā)生時有條不紊的進行響應和恢復。當然這也會增加IT部門的日常成本支出，因此要周期性的重審并對條款進行改動，至于簽到什么程度是要根據預算而定的。這一點，我們留到以后的成本核算章節(jié)再做討論。

至此，三種約定之間的關系可由下圖所體現：

重申一點：由于內外部環(huán)境的變化，以及技術的發(fā)展，服務等級管理應該是一個不斷循環(huán)的過程，IT管理層應定期對各種服務/運營等級約定和基礎合同進行評估、更新和修訂。 

屈指算來，這已是我們漫談的第十四期了，回首十多期下來，這些分享既是對自己的思路和知識的一種梳理，又是和小伙伴們互動相長的過程，還結識了一些素未謀面的“朋友圈的朋友”。很有“ 有兩岸猿聲啼不住，輕舟已過萬重山” 的即視感。聚沙成塔，匯溪成河，讓我們在日常運維的技能與管控理論上不斷提高自己的廣度和深度，盡快成為企業(yè)里的“T型人才”吧。

【51CTO原創(chuàng)稿件，合作站點轉載請注明原文作者和出處為51CTO.com】