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

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

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

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

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

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

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

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

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

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

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

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

1 白紙黑字

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

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

2 因人而異

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

3 合縱連橫

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

至此，三種約定之間的關(guān)系可由下圖所體現(xiàn)：

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

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

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