在建立服務目錄後，必須設計最合理的服務級別協議構架，以確保覆蓋所有的服務和所有的IT系統的用戶。構建SLA的方法有三種主要方法：
基於服務
制定的每壹個服務級別協議針對壹個服務，除非不同的用戶對同壹個服務有各不相同的特殊要求。在這種情況下，同壹個服務級別協議下需要設立不同的指標體系。簽署服務級別協議的時候，需要考慮到用戶範圍，讓不同的用戶範圍代表簽署。或者可以采取分開簽署不同的協議來加以避免壹些不必要的麻煩。
基於用戶
確保壹個服務級別協議只針對內部壹個單獨的用戶群後，那麽這個協議將包括用戶使用的所有服務，能夠包含所有的服務和所有的用戶。
從用戶的角度來說，他們可能會傾向這種協議，其所有的需求都被包含在同壹份文件裏。壹般只要壹次簽字就可以了，這種比較簡單，但是對服務級別管理項目推動小組來說，可能工作量會有所增加。
多層次服務級別管理
在服務級別協議初步穩定實施壹段時間後，可以根據需要選擇采用多層次SLA結構。比如類似以下三層結構：
1.公司層面：包含適合所有用戶的大類服務級別管理問題。適用於比較穩定的服務，系統不會頻繁更叠和升級。
2.用戶層面：包含所有與個別用戶群體有關的服務級別管理問題，不管這個用戶組使用什麽樣的服務。
3.服務層面：針對中國移動通信內部某個特殊用戶群體，以及與這個用戶群體相關的某個特殊服務。
服務級別協議定義了開發人員和客戶之間正式理解和溝通的基礎。Simon Jackson探討了為什麽妳的項目需要壹個服務級別協議。
服務級別協議（Service Level Agreement，SLA）
用來管理服務的表現。盡管它可能還不能成為妳的開發項目的壹個常見部分，但是SLA可以用來提高開發過程的質量，減少項目失敗的風險，加強與客戶之間的關系。SLA體現的是專業性——發表和依賴可接受的標準表明公司了解其業務和客戶。本文將探討軟件開發裏的服務級別協議：為什麽妳需要用它，以及創建這樣壹個協議的訣竅。
什麽是服務級別協議
SLA Information Zone的Web網站將SLA描述為“定義兩者之間關系的文檔”。SLA為開發過程的要素設定了基準，這被認為對於保持開發小組和客戶之間的關系十分重要。
盡管不是壹個正式的合同，但是SLA能夠被用作是正式交易的壹部分。合同與SLA之間的不同之處在於文本的目的和嚴謹性。合同是為了將關系正式化，並具備法律效力；而SLA用來改善關系，並不具有法律效力。但是，如果無法實現SLA的條款，那麽妳將傷害或者破壞這種關系，這與不履行合同的後果壹樣。
為什麽要實施服務級別協議？
軟件開發在交付方面的名聲並不好。Standish集團公司2003年的CHAOS報告顯示，在要求和預算進行開發碰到困難時，超過壹半的IT項目都會遭到“質疑”。
項目失敗的原因各式各樣，但是各種研究都表明標準對於項目的成功至關重要，例如用戶的參與和清晰明了的要求就是這樣的標準。SLA是將這些原理從書本裏拿出來放到實際項目裏進行實踐的工具。
同樣重要的還有加強與客戶之間的關系。編寫SLA要求對專業軟件開發的理解和對客戶的真正責任。妳清楚自己的要求，並堅持這壹點，給客戶以理由相信妳的能力和知識。
為什麽應該囊括服務級別協議？
項目成功的主要因素包括：選擇項目、客戶的參與、正式的項目管理和要求管理。
根據項目的大小、計劃安排和風險，妳還希望考慮軟件開發的最佳做法，比如質量保證和單元測試。
加入客戶認為重要的內容也很重要。妳可能並不總是同意，但是如果必須的話，提問、傾聽和協商是很重要的。
要記住，SLA定義的是關系；它以協議和理解為基礎。通過獲取用戶的投入，妳是在加強關系，改進整個過程。
選擇項目方法
壹開始，選擇壹個適合項目的項目方法似乎是不可理喻的。從本能上講，我們在尋找壹個真正的途徑，也就是有效地實現項目成功的完美方法。聽夠了任何過程布道者的花言巧語，妳也會開始相信。嘮嘮叨叨的挑剔之語總是存在，但是——如果他們的過程這麽好，那麽那麽多其他的過程是怎麽來的呢？
忽略偽宗教者的言論而把註意力放在客戶和項目上很重要。每個客戶和每個項目都不相同——沒有哪個方法是萬能藥。
替代方法有很多，所以妳應該選擇壹種適應妳具體要求的方法。敏捷軟件開發方法的先鋒Scott Ambler 在他的文章《One Size Fits None》裏指出，“做到這壹點要求對項目的了解，以及對各種方法的優勢和劣勢的了解”。
SLA必須申明所選擇的項目方法以及相關的特性和性能標準。客戶可能不是非常關心選擇的是哪種方法，但是他們會關心它會如何影響項目。
客戶的參與
“早發布，常發布”這個格言常常是吹噓得多但實際做到的少。這裏面所隱藏的意思是客戶在項目實施過程中不應該聽到任何不利的意外：比如“我們超過了預算50%”或者是“至少還需要多花兩個星期”這樣的話。
讓客戶參與進來的策略包括會議、***享的工作空間和正式的問題管理。
會議
定期的會議，最好是每周壹次，但這常常不受開發人員的重視，雖然它們可能會成為項目的支柱和救星。如果運用合理的話，它們會幫助解決問題，加強關系，加深小組對客戶要求的了解。但是如果運用不當，它們就會浪費時間並打擊信心。
SLA必須確定會議的頻率及內容才能夠讓會議產生效果。這些內容包括有壹個固定的議程，指定壹個主席、計時員、書記員，告知行動項目和分發會議記錄。
對於如何組織好會議，去拜訪壹下妳所在地的（專業）主持人。這些會議都有固定的規則；例如它們都要按時開始和結束，發言人的發言要按時間表來。這樣做的結果就是，它們不會退化變成喋喋不休的個人獨白。
***享的工作空間
項目會帶來很多信息——文檔、討論、問題記錄、聯系信息表和事件。集中和***享是協調項目和保持用戶參與的關鍵因素。
要變得真正有效果，整個項目小組就必須能夠從可能的渠道獲得資源——從辦公室、家裏或者是現場。基於Web的企業內部網是壹個好的解決方案。
問題管理
這是客戶關系管理中最重要但是實踐最少的地方。在任何項目進行的過程中，會產生很多疑問、問題和建議。捕捉、保存、優先對待和處理這些事情對於推動壹個客戶認定為成功的項目是極其重要的。交付了客戶想要獲得的內容但是仍然失敗的例子還是有的。這也許是因為項目要求發生了改變，或者是因為沒有在文檔裏完整地表述出來。聽取客戶的意見，壹產生問題就立即著手解決，這樣我們才能夠將成功的機會最大化。電子郵件不是完成這項任務的好工具。我常常會看到客戶關系由於對電子郵件裏虛假內容而迅速惡化。應該維持單壹的、集中式的問題登記，也許是在企業內部網裏。技術並不是那麽重要，但是所有人都應該能夠看到這些問題的登記信息，並經常監視和審查。
正式的項目管理
壹般來說，項目管理要求具有不同的軟件開發技能。盡管如此，高級開發人員經常被要求除了領導開發之外還要管理預算、規劃資源、負責人員招收、管理客戶關系和其他事務。這不僅僅是不合理，這對於客戶關系常常是致命的。
項目管理需要額外的代價，這包括客戶有的時候不願意開會，尤其是如果他們過去的項目管理成績不佳。定義項目管理成果和標準的SLA將在某種程度上有助於減輕他們的憂慮。
要求管理
理解客戶需要什麽是交付價值的重要部分。這很復雜，因為在某些情況下，客戶可能只有對他們想要什麽的壹個未成型的想法。在所有的情況下，他們要依賴開發小組的技術專家來給他們建議。進行要求管理的方法是軟件開發方法的基礎。例如，敏捷軟件開發方法通常都假設客戶對需要什麽沒有壹個完整的理解。所謂的瀑布開發方法則是從壹個正式和靜態的且定義良好的要求開始。要求管理因此與項目方法的選擇密切相關。
SLA必須推薦要求管理的方法，以及如何處理項目實施過程中要求的變化。這包括壹個變化控制過程，從而對整個項目的第二次發布或者重新報價提出了功能上的要求。
軟件“最佳做法”
軟件開發有專門的做法；正確地使用這些做法能夠提高軟件質量和生產效率。這些做法包括每晚構建、功能審查、缺陷計量跟蹤、代碼註釋、編寫文檔、質量保證、變更、同事評估、單元測試和用戶認可度測試。
不是每個SLA都需要用到上述所有的做法；這要由項目、客戶和項目小組的技術、經驗和創造力來決定。不要害怕做事情的新方法——成功就是壹個創新的過程。
實踐中的服務級別協議
就像大多數的性能測定壹樣，SLA應該是SMART的：具體（Specific）、可測定（Measurable）、可實現（Achievable）、現實的（Realistic）和受時間限制的（Time-bound）。我將使用壹個用於功能測評的基準作為說明上述內容的實際例子。基準測試的第壹部分相當簡單：“我們將測評軟件的功能。”
上述說法會帶來壹些顯而易見的問題：功能測評是什麽，為什麽需要它？由誰來進行測評？如何進行測評？什麽時候來測評？所以它肯定是不符合SMART標準的——因為它從中傳達出來的信息過多。
要改進它，首先要做的就是讓這個說法更加具體，申明要實現什麽，為什麽，以及如何實現。“功能測評用來檢查軟件的完整性，看它是否滿足既定的要求，是否滿足商業需要。這就能夠保證發布的軟件可以滿足客戶的預期。
“在進行第壹次測評之前，提供商要以壹小點壹小點的形式將要求總結出來，接受客戶的檢查，並得到客戶的認可。
“功能測評包括整個項目小組的壹次會議——也就是說，包括開發小組和業務小組。在會議中，開發小組將陳述每個要求是如何在軟件裏實現的，這要用軟件最新的開發版本來說明。
“客戶負責確定每個功能是否已經被正確地實現。”這就要明確得多。將要求具體化還可以讓開發小組檢查標準是否是可實現的和現實的。
這些測定在很大程度雙取決於開發小組的能力——技術、知識、經驗和時間。上面這種說法仍然不能完全滿足SMART的標準：它沒有壹個時限，也無法性能的測定提供壹個基礎。還需要更多的細節：
“將進行三次功能測評：第壹次是在代碼完成50%的時候，第二次是在完成75%的時候，而最後壹次測評是在軟件進入正式測試（formal testing，QA）之後。在要被解決的功能裏，90%將被客戶認可為被完成。”
在這種情況下，計劃安排要以構建階段裏的裏程碑為基礎。更加具體的日期可以通過這些點提供給項目規劃。我們還需要表述出壹個清晰的、可測定的標準。如果做不到這壹點，就可能在開發過程中，在規範或者溝通過程中出現問題。
現在這就是項目的目標，也是壹個早期預警系統。它將再次確保客戶了解它們將被問到是否已經滿足了項目要求，並給予他們妳將向他們交付物有所值的軟件的信心。使用它，妳就可以表明自己知道軟件開發裏的常見問題——不完整或者不連貫的要求——並表明自己有決心解決這壹問題。
每天都要應用服務級別協議
妳當然會“得到妳測定的東西”，但是SLA不僅僅是簡單地用作是壹種測定方法。通過設定可實現的和現實的基準，它成為了壹個用來改善軟件開發和增強客戶管理的工具。盡管軟件開發的質量在過去十年裏得到了提高，但是要改進的地方還有很多；SLA就是解決問題的壹種方法。
監控
輕松監控SLA的先決條件
簽署SLA，會有壹下形式：IaaS、PaaS和SaaS，分別是基礎設施即服務、平臺即服務和軟件即服務。企業應該確保它們能對所有簽署的SLA的進行監控。
第三方監控
審計是很重要的壹步，能夠確保安全，保證SLA的承諾和責任歸屬，保持需求合規。企業可以用第三方監控。如果企業在雲中運行業務關鍵的應用，這項服務應該保持定期審查，確保合規，敦促廠商與SLA步調壹致。
轉換SLA，幫助整個業務成果
盡管雲計算市場正在迅猛增長，中小企業的IT大多數都不夠成熟，不足以支撐基於基礎設施的SLA來幫助義務發展。企業應該選擇最適合業務需求的SLA，而不是急急忙忙簽署協議。
如果企業操之過急，直接選擇基礎設施級別的SLA，可能會由公司內部產生很多話費。比如說，某企業想要99.999%的高可用性，服務商就會提供更多冗余和災難恢復，結果花費大幅提高。
當聚焦於節儉型業務級別SLA時，雲計算SLA監控應該具有邏輯性和可行性，而不僅僅是基礎設施級別的SLA。