SLA 簡介

關于ITIL中SLA的概念，知道的人很多，但真正洞悉其複雜與本質的人可能不多，網上也甚少看到這部份的深入資料，尤其是跟實際業務相關的就較少，多是 一些空泛的居多。一直說想寫針對ISO20000的13個流程分别寫一篇評論與思考的文章，但工程比較大，隻能象現在這樣零零碎碎的寫了，正好前段時間在 項目過程中碰到對SLA的讨論，于是想把一塊的想法記錄下來，以供内外交流，注意以下内容隻是基于個人對SLA的了解，我并不認為它是一個對SLA最好的 解釋與了解，隻是基于目前這個階段的認知而言，而是可行的也相對實際與合理。

一、        SLA的本質

1.        SLA的起源：

    ITIL的産生最重要的一個作用，是标準的作用，類似中國古代統一了語言與度量标準的做法類似，ITIL提供了一個大家可以共同交流的言語、提供了一個大 家可以标準化的指導與改進的基礎，讓全世界的IT服務業者可以真正統一、标準起來，ITIL我個人認為最核心的概念之一就是SLA的引入，服務業一直是難 以标準與度量的，一直依賴人類的感性為名額，這造成許多的交流、管理、商業、法律問題，SLA概念的清晰提出，将服務引向一個可量化、可控制、可評論、可 管理、可改進的境界，服務不再模糊、不再隻停留在非常内在的層面，服務亦可以生冷的進行管理與控制。

    事實上在傳統行業，也有類似SLA的概念，隻是沒有人獨立成一個概念，并圍繞它建立一個管理體系，比如麥當勞的60秒取餐，快遞公司的XX小時快遞等等， 亦或者一些政府機關承諾辦理手續的時間等等，這些與SLA的概念是一緻，不同的是應用與限制效用不同，同時在管理體系中扮演的重要性也不可同日而語。

2.        SLA的作用

       ITIL最具革新意義的創舉是定義了SLA，并圍繞着達成SLA設計了一整套管理體系，那麼SLA到底有什麼作用呢？SLA（Service Level Agreement）在中文中我們通常叫做服務級别協定，首先要聚集在“協定”二字上，它表示這是跟你客戶達成一緻的，具有法律限制作用，其次是“級别” 二字，這表示你的服務到什麼程度需要有量化名額出來，提到這個需要提到另一個概念“服務目錄”

       當你想承包客戶的IT服務時，首先要确定的，其實不是服務級别協定，而是服務目錄，因為你首先要搞清楚，客戶需要你做什麼服務，這就需要你梳理你的服務内 容即服務目錄，在完美的情況下，你應該是清楚你自己可以做什麼服務，才去面向市場的，即一個成熟的IT服務商，應該有自己的服務目錄（類似菜單），然後找 到客戶，由客戶點菜（選取一部份服務目錄），最後就每一項服務需要達到的級别協商達成一緻，這樣才能進行商務報價，因為服務級别與成本是成正比的。是以正 确的邏輯是首先确定做什麼，然後确定做到什麼地步。

        當SLA确定後，這份檔案具備法律意義，它清晰IT服務商與客戶的職責與服務内容，其一些免責與懲處條款，這會避免許多誤會與糾紛，因為在實際的服 務活動中，客戶經常會理所當然的認為你就應該“幹這事兒”，作為IT服務商也經常會簽訂了一個服務活動後，為了“客戶滿意度”就大包大攬的把活都幹了，在 實際的IT服務活動中，我相信大多數的運維服務公司為客戶做的許多事情，是在報價中沒有考慮到的，即我們的“服務溢出”了，最後核實成本時，又發現利潤不 高，但又無從提價，但是當服務目錄與SLA真是弄清楚後，雙方就有了一個很好的基礎去改進服務，避免了許多灰色的地帶，成本的控制（無論是客戶方還是服務

提供方）都會相當容易。

        确定了服務目錄與服務級别協定後，IT服務商将根據服務級别、成本去配置相關的資源，組成服務團隊，而SLA将是指導這些團隊作業的最有力的依據，最後一個合同周期結束時，客戶将根據合同的執行（SLA的達成）進行結算付款。

        事實上如果一個IT服務商管理相對比較成熟，業務量到達一定的規模時，還可以根據SLA與服務目錄的曆史資訊，設計一個成本計算模型，這樣在對于商務報價與日後的成本控制是非常有利的。

3.        SLA的可量化

   SLA的協定有一個很重要的關注點，即SLA的“可測量性”與“測量方法”，有一些運維服務商與客戶協商一些複雜的名額，但這些名額在合同周期内是根本 無法進行測量的，這種SLA的協定就喪失了意義，無法測量就意味着根本無法知道執行情況、無法計算執行結果，也無從改善與控制，這是一方面，另一方面，當 我們确定了一些名額後，這些名額的計算方法與測量方法也是需要注意的，這些要與客戶商定清楚，避免了有名額，但最後的測量方法雙方不一緻，導緻最終的達成 結果出現偏差而發生糾紛。

4.        在

二、        SLA的組成要素

   下面我們将開始真正了解SLA的幾個核心組成要素：

1)        服務目錄：服務目錄決定了你的SLA限制的服務範圍，即服務商到底提供哪一些服務，隻有客戶“選擇”了的服務目錄，服務商才會報價與後續的響應，在 服務目錄之外的内容，将不受SLA的限制，這也意味着報價時是未考慮這些服務内容的，最後結算也是單獨的，服務目錄要利于閱讀與了解，便于客戶、服務商自 身消化，不然在實際應用中是無法真正起到作用的，服務目錄這一塊以前寫過一些内容，就不再多作介紹了。

2)        服務月曆：服務月曆決定了你的SLA限制的時間範圍，即你為客戶提供X*X的服務響應期，是7*24還是5*8，是否扣除一個周期内的法定假期，很 多服務商有自己的公司月曆，事實上，每一個服務型的項目存在着一個服務月曆，服務月曆與公司月曆很多時候不是相同的，不同則意味着成本的增加與管理難題的 增加，這需要進行在報價結算時綜合考慮，因為它直接關系到人力的配備與排班，服務月曆跟各種監視計劃也有直接的關系，它還跟SLA的測量有關聯關系。

3)        可用性：事實上每一個項目是一組服務的集合，比如桌面運維或IDC運維，亦或者是一個應用系統的運維，這些在實際的作業中，多數是以項目的形式管理 與存在的，這同時也表示是一個服務叢集，這裡就需要定義每一個項目的可用性，說到可用性，通常的公式是：可用率=（AST-DT）/AST*100。 AST（agreed service time）是指約定的服務時間即上面提到的服務月曆，DT（Actual downtime during agreed service time）在約定服務時間内的停機時間。這個計算公式表面看起來簡單但在實際的取值中是比較複雜的，因為AST需要考慮月曆問題，需要把服務月曆的所有時

間段換算成小時甚至分鐘，如果一個故障發生在5*8之外的時間，是不會考與計算的，同時每一個故障的發生與結束時間需要測量出，還有加上其它的因素，比如 是不是這次故障是由服務商承擔的，如果是客戶非法違視操作，或者是第三方導緻的，此時把故障時間納入可用性計算顯然是不合理的。事實上考慮到一個合同周期 的長度，通常說的可用性達99%這實際是一個非常低的可用名額，如果是5*8的服務的話，99%的可用性意味着有208個小時的時間内服務是不可用的，在 實際的服務過程中，機關用小時是過粗的，因為故障的發生一般是以分鐘為機關的，有的行業甚至需要用秒為機關。加上使用者群的問題，可用性的計算還需要更複雜

才能真正發映真實的服務情況，一直以來有一個問題困擾着許多人，到底怎樣的故障算是影響了可用性呢？比如一個應用系統，如果是全國範圍内的應用而且使用者群 衆多的話，發生了局部地區的使用者無法使用部份子產品了，這需要納入可用性的計算嗎？如果納入的話，會讓可用性無端的降低很多，而實際中并非如此，你會發現全 國的服務不可用與部分地區的不可用造成的計算結果一樣了，但實際的服務情況并非如此，這表示計算的模型要複雜，這個話題放在後面再進行說明。

4)        解決時間：解決時間是指當發生各種類型的事件時的完成處理時間要求，常态而言，事件分為咨詢、請求、投訴、故障、新需求。這是事件的分類，另外事件 需要進行分級，一般可分為五級或三級，這時需要定義每一個分類、級别的事件的解決時間要求（比如一級故障要求多少分鐘解決），還需要定義哪個級别的事件影 響可用性（比如一級故障二級故障都影響可用性），有一些事件分類象投訴與咨詢可能是不會影響可用性的，常态而言新需求也是不影響可用性的（除非在商務報價 之初就納入新需求的限制考慮）。

這裡要特别需要強調一下可用性與解決時間的關系，這是一個互相鉗制關聯的，比如可用性定義了一年之中隻能當機20個小時，但是客戶不會充許你在同一個時間 裡把20小時用完，解決時間裡定義了當機是一級故障，一級故障的解決時間是1小時，這樣會強制把20個小時分散到全年之中，以減少對業務的沖擊。當可用性 與解決時間這兩個核心名額定義了後，象按時解決率等等這些事實是用于服務管理的，基于服務商自身的管理而言的，站在客戶方的立場而言有了這兩個名額就足夠 限制服務商了。

三、        SLA的測量

SLA經過設定後，就需要進行監控與測量，事實上對SLA的測量等于對事件的測量過程，不會涉及到其它的流程了。就可用性這個名額而言，隻會與故障這一種事件分類關聯，而解決時間這一名額是橫跨所有事件的。

每一個事件從發生到解決的時長會與解決時間這一名額比對，如果屬于故障，再根據事件的等級與可用性的關系來比對以确定每一個故障是否影響了可用性，而且要 判斷影響了多少。這樣需要涉及到的資訊與計算量是比較巨大的，沒有軟體工具的支援很難實作，有了軟體工具并考慮了上述的要素，是可以随時計算有多少事件的 解決時間違規的，也可以随時計算出目前的可用性是多少。在服務人員處理事件時，當建立的那一刻開始倒計時以限制加快處理程序，服務人員的接單需要考慮事件 等級與解決時間剩餘。

在計算過程中還需要考慮許多例外因素，比如要剔除因客戶或第三方造成的等待時間，當服務商承諾，電腦出了問題8小時可以維修完成，但由于客戶的原因一直聯 系不到對方無法拿到電腦，造成解決時間違規，最後要對服務商進行金錢懲罰顯然不合理。還要剔除責任歸屬是客戶或第三方的事件，以合理公正的計算。

SLA的測量是一個實時的行為，時間的要求非常高，這事實上會要求服務商的服務人員有一個非常明确的操作規程，不然SLA的計算與提取很容易失真，這些數 據事後是很難補上再計算的，尤其是有軟體支援的情況下。SLA應該是一面鏡子，讓客戶可以照清楚服務商，而服務商也可以确切的知道自已目前的服務能力，個 人覺得目前國内許多服務商的SLA的設定與結果其實經不起嚴格推敲的，這的确需要服務商有比較成熟的認識與管理水準。當每一個商務周期結束後，可以提取出 服務的績效結果，一是供結算考評，二是分析以确定明年的服務績效。

四、        SLA的實施過程

在一個沒有導入ITIL的組織中，要實施SLM是一件比較難的事情，因為這需要客戶方與服務商共同接受這種理念，同時這對服務商而言是一種壓力，在大家沒 有真正的理清這些内在的道理之前，服務商與客戶方反而可能保持一種天然的生态融洽，不管這對客戶還是服務商是否有利，起碼以前客戶不會意識到原來服務是如 何低下，服務商雖然有時會被客戶的無理要求所打擊，但絕大多數情況下，還是可以赢得下一個商務合同的，當這一切的混沌被打破時，就使得大家置于一個相對生 冷的環境，以目前國内的服務合同而言，關系往往是占據很重要的位置的，可能客戶也暫時沒有意識到需要如此嚴格透明的管理服務商，這時服務商去實施SLM

時，有時會有一種找抽的感覺。但SLM又是ITSM真正走向成熟的一個很重要的基礎，這時需要組織的高層上司的強力支援才有可能走向現實，客戶方與服務商 需要有很好的學習與溝通，甚至要做好有短期混亂的準備。

     實施SLM，從服務商的角度而言，最開始需要梳理的服務目錄，然後才開始針對目前的每一個服務項目進行分析，與客戶（業務方）讨論确定一個服務範圍 （服務目錄），再确定服務時間範圍（服務月曆），然後要根據業務的現實情況來一同确定可用性與解決時間，這個過程是一個相當痛苦的過程，尤其是在第一次實 施讨論時，在第一次時，建議與客戶訂一個粗的SLA，比如解決時間可以相對一刀切，這裡特别需要注意的是要把關鍵業務活動找出來，以便于事件的定級，不然 後續的一切計算與統計全部會失真，服務人員也不知道如何将每一個事件定級而造成作業混亂。把這些商定清楚時，雙方可以寫入合同一同确認并生效。SLA生效

後，需要宣達到與此服務項目所有相關的作業人員，最好以會議的形式公布宣達。後續就進入正常的服務過程了，在每一個商務周期内，把SLA可以進一步分析與 細化，這樣一個周期一個周期的改進循環，最後走向成熟。

五、        SLA的局限

   SLA有一個比較沖突的地方，即可用性的定義，你如何了解與設定你的可用性，這是一個很困難的地方，小的說一台電腦，好象從表面而言，這台電腦用不了當 然會影響可用性，但實際情況上，電腦關非隻處于0和1的狀态，可能隻是電腦的OFFICE中的EXCLE用不了，那這時客戶報障到底算不算影響可用性呢？ 如果算，那麼AST（約定的服務時間）要如何取值呢。這還是從一個裝置而言，如果是一分布式的應用系統，遍布全國的使用者，這時這個問題就更複雜了，這裡面 我發現應該是存在一個規律與道理的，即如果局部的服務受影響也會納入可用性的計算時，那麼AST一定需要把服務受點納入考慮，比如上述的電腦，如果隻是一

個EXCLE無法使用時也納入可用性的計算，那麼需要把這種EXCLE類型的服務也納入AST的計算中，這樣分子越大時，分母也應該随之增加，如此才能更 接近真實的情況。比如如果一個分布式的系統，服務月曆是7*24。在全家有100個應用網點，當10個應用網點無法正常運作1個時，如果這種情況需要納入 可用性計算，那麼每一個應用網點都應該被考慮進AST中，即AST是7*24*100。其實核心的問題是到底哪一些算影響可用性，我們往往的答案時隻要影 響了關鍵業務就算影響了可用性，但真正深入分析，這個回答往往不是很堅實的，因為現實中業務往往是互為一體的，系統的功能也是相輔相成的，說關鍵業務，事

實也是由許多一個個小的服務或功能點支撐的，常常會使我們面臨一個問題就是，造成故障發生時，要麼可用性的落點很多，要麼根本沒有落點，最終可用性不是很 低就是很高，沒有真正的反映出實際的情況。這個問題從2006年的時候我就想求一個最終解，但現在隻是變相找到一個解決方法，即把事件的等級與可用性影響 關聯，這樣便于制定名額與測量，但事實上仍然沒有找到一個非常合理的模型出來，也有可能是“可用性”這一概念本身就是不合适的，需要用另外一種更合理更易 于分解的概念來代替才行。

   另外一個事實是，SLA最終的結果其實不是事實結果，因為當一個故障發生時,如果這故障是成規模性的影響的，還是以上面的分布式應用系統為例，此時如果 你的可用性設定得非常詳細與具體（即把每一個網點都納入AST考慮7*24*100），你很難知道到底在故障期間到底有多少網點受了影響，你的事件建立可 能隻是一條，這時你的可用性事實上無形中拔高了。如果你的可用性設定得比較粗（7*24），這時不管你是否把這次故障時間納入計算，你的可用性計算都會是 錯的。

SLA的内容暫時寫這些了，實施SLM難度很大的根本原因在于，在這一個流程中集中了許多曆來已久的問題，比如象服務目錄的梳理與設計，這本身就是一個獨 立的課題了，而SLM并不是一個服務商内部的流程，它需要與客戶方做許多溝通與理念共識，它又關系于商業利益，在國内的客戶基本上還成熟到有一個清晰的 SLA來限制服務商時，服務商反而超前一步了，這某種程度是一種好的趨勢，我相信IT服務一片混沌的情況會在未來成為曆史，它應該更具體透明、更量化、更 易于控制的，未來你将不能再丢一個粗粗合同把客戶數百萬的預算吃下去了，起碼客戶需要知道到底你做了些什麼，做到什麼水準，作為服務商你可不太可未來一直

把合同拿到就算完，做好做壞都得到按合同金額了，客戶将會有更多的方法來控制合同的執行情況，服務将不再是一個黑盒子了。