如何起草有效的服務水平協議(sla)

每個公制的量度應該是 SMART( 特定、 可衡量、 可達、 相關、 限時 ) 。 例如 , “ 提供者将在 15 分鐘內對 P1 事件做出反應, 并在 4 小時內解決 。 ” 避免像「 速率 」 等 的 主观 名詞 。 也明智的是定義 : 是否計算了一個历月的升級時間, 或是一個滚动的30天的視窗 ? 是否排除了維持視窗 ? [[FLT: 0] 的 Atlassian SLA 最佳做法[[FLT: 1] 提供了選擇適當的 KPI 和 測量间隔的指導 。

作用和职责

明确定义誰做甚麼。 提供者的責任可能包括维护基础设施、 补丁漏洞、 提供狀態報告、 管理安全事件。 客戶的責任通常包括提供及时存取、 界定要求、 通知提供者、 以及像數據備份( 如果未包含在服務中 ) 那樣的客戶端工作。 另外, 也為每邊指定一個單一的聯絡人( SPOC) 。 當角色模棱兩可時, 就會發生延遲。 例如, 如果客戶端不提供認證, 提供者不能达到其超時目标 — SLA 應處理這些依赖性。 包括一個通信通道的區域: 電子郵件、 票單位系統、 手機或一個入口。 說明如何處理責任的變更( 例如, 通過變更請程序) 。

监测和报告

描述如何監控性能和報告的頻率。 提供方會使用像Nagios、Datadog或SolarWinds等自動工具嗎? 報告會是月度、周度或实时的, 通過儀表板嗎? 指定格式( PDF、 CSV 或網門 ) 。 也界定誰可以存取監控資料 。 定期的報告會讓雙方都負責, 并讓它們能早日發現變化。 關鍵的服務, 考慮對違法的实时警報 — 例如, 如果上行率下降到99.5%以下, 提供方必须在15分鐘內通知客戶。 SALA 也應該說明如何解決測量爭議: 也許雙方都同意用第三方監控工具來當真相源。

發行解析度與升級

該節應概述處理事件的程序。 定義嚴重程度( 如 P1 – 危急程度, P2 – 高程度, P3 – 中度, P4 – 低程度) 和相应的反應/解析目標。 包含一個升级的路徑: 如果P1問題在目標时间内得不到解決, 它會升格到高级工程師, 然后升格到管理, 最后升格到提供者的執行团队。 提供每級的聯絡信息, 包括超時數。 明確的升级程序可以防止小問題成為危機。 也規定如何记录事件 – 票單系統必須為塞拉拉比達達達達目的而產生時間戳。 对于重犯事件, 考慮一個問題管理程序, 調查根源并执行預防行動。

处罚和补救

使 SLA 執行, 指定未達标的後果。 常见的补救办法包括服務信用( 例如, 低于升級阈值的每小時扣除的月費) 、 退款或解雇權。 但是, 避免過於懲罰的懲罰, 可能破壞關係; 目的是激励绩效而不是懲罰。 有些 SLA 也包含超标的激励, 如獎金或合同展期。 明确如何計算和要求 。 是否自动出现在发票上, 或是客戶必須要求? 法律可执行性請參考像 [ [FLT: 0] Smartshet 的 SLA 樣本 [[FLT: 1] 的樣本。

审查和修正程序

解析區不要是靜态文件。 包含一個定期審查的條款, 包括季或年 期, 以更新基于改變的企業需求或科技的度量衡。 指定如何提出、 審查和批准修改。 這保持解析區的關鍵性, 防止它變舊。 例如, 如果客戶的使用者群增加, 時空要求可能需要收緊 。 審查流程中还应包括一個解決對度量定義或量度方法的歧見的机制。 使用版本控制並保持一個有效的日期的變更紀錄 。

定義和名詞

定義部分确保所有方都一致地解釋术语。 定義中定義「 下限期 」 、 「 預定期 」 、 「 緊急期 」 、 「 意外期 」 、 「 服務信用 」 等 。 這可以減少歧視, 防止語言爭議。 例如, 有些協議將「 下限期」 定义为從客戶角度來計算的不可用服務的任何時段, 而其他協議則排除由客戶誤稱造成的失敗。 明確。

逐步起草 SLA 指南

建立自零起的 SLA 可能感到很驚人, 但遵循有條理的流程可以确保全面性。 以下是一個包括準備和執行的擴展的一步步方法。

第1步 - 评估需求和要求

開始理解客戶的企業目標和服务的重要性。 和利益關注者进行訪談 — — IT、操作、金融及终端使用者。 他們最大的关切是什么? 他們認為什么是可以接受的性能? 例如, 一個电子商务網站在高峰銷售季需要近100%的营业時間, 而內部的HR系統可能會容忍更多的停工時間。 也评估提供者的能力:他們有基础设施可以达到金層的衡量标准嗎? 記錄所有要求,包括可能要求增加時間或數據保護的监管遵守需求(例如HIPA、GDPR ) 。 這個階段應該拿出一份要求文件,作為SLA的藍圖。

第2步 - 定義明确的目的

以「确保服務需求在工作時間中99.5%的時間可以使用」為例,這比「保持良好的可用性」更清晰。 寫出符合雙方目標的目標。 如果客戶的優先權是成本节约,那么就避免不必要地提高成本的镀金量。 目標應該比照業務基准來審查 — — 例如典型的云端提供商提供99.9%的可用時間,但任務关键系統可能需要99.995%的可用性,并有相应的成本溢价。 包含可用性和性能目的(例如平均頁載量時間 < 2秒 ) 。

第3步 - 選擇可衡量量度

選擇易于衡量和直接反映服务质量的衡量。 避免看起來好但不重要的虛假衡量。 例如, 如果隱藏偶爾會有長時間的延遲, “平均反應時間 ” 可能會引人誤解 — — 考慮使用百分位數( 例如, 2 秒內的第95 百分位反應時間 ) 。 也決定量度視窗 — — 排除预定的维护視窗的停工時間, 但要确保排除的確有明确的定义。 对于複雜的服務, 考慮像“ 加权可用性” 的复合衡量, 以不同服務元件來表示。 使用 SMART 標準來驗證每個公制 。

步骤4 - 文件草稿

使用清晰、 純易的語言寫入 SLA 。 避免使用迷誤非法語的法律术语。 使用表格來表示公制和時間。 包含前面描述的所有核心元件 。 保留文件模块化 。 使用 executive 概要來簽署, 然后是公制、 程序和定義的详尽附录 。 使用版本控制和包含變更紀錄 。 考慮使用樣本來確保一致性, 但為特定服務定制。 在起草時, 既要涉及技术和法律的相關者, 也要涉及所有角度 。

第5步 -- -- 审查和商谈

向內部團隊(法律、操作、金融)和客戶發布草案。 期待就目標、懲罰和排除等進行商議。 準備用歷史資料或業務基准來為您的數據提供合理理由。 目標是平衡的協議, 既可以做到, 卻又具有挑戰性。 行動團隊應該簽署衡量尺度的現實性 — 共同的錯誤是同意提供方不能實際交付的目標。 記錄所有變更和背后的理由。 使用紅線程序來追蹤編輯。

步6 - 完成并簽署

兩方同意後,經授权的代表簽署。 确保SLA附屬於服務总協議或合同。 需要的所有人,包括支持工程師、帳戶管理者、報告團隊,都可以在寄存處中存取簽署的拷貝。 考慮數位簽章的速度。 也確認服務提供團隊自第一天起就具备了必要的監控和自动化能力,以達成商定的衡量标准。

步態7 - 實施與監控

簽署後, 啟動 SLA 。 配置監控工具以追蹤商定的公制 。 建立標準表, 顯示對每一個KPI 的实时遵守。 訓練支援隊員的升級程序和严重程度定義。 立即報告第一個月的資料對驗證至关重要。 如果實際性能不足, 在下次審查前找出根源並調整行程。 在前幾個月, 常與客戶登記, 以确保 SLA 正常工作, 并調整任何誤解。

第8步 - 定期审查和調整

以 SLA 作為活的文件。 定期的審查會議( 季或半年) , 討論性能數據、 新出现的需要和拟议的變化。 利用這些會議來慶祝成功和解決變化。 如果一公尺一直超過目標, 考慮收緊或新增公尺。 相反, 如果一個目標一直被錯過, 根因分析顯示不切实际, 請把它調整到更可達的地步。 把所有修正正式記錄下來,並重新發送 SLA 。

避免的常见陷阱

也讓許多人感到難以接受,

• 以「最終的反應」來表示「30分鐘內的反應」。
• 忽略排除: 未能列出未被遮蓋的漏洞。 列出所有的排除, 如预定的維持視窗、第三方停業, 或供應商無法控制的行為。
• 建立無法達成的公數值會削弱信任。 根據歷史資料或業務標準, 不要保證99.99%的升空率, 除非有基本設備可以提供。
• 不可計量的計量計劃 : [[FLT: 1] 。 無法計量的度量法是無用的 。 定義如何收集和驗證數據 。 例如 , “ 時間的計算使用提供商在三個地區的合成監控探測器 。 ”
• 忽略客戶的責任: 客戶的行為會影響性能。包含如及时回報、提供存取和履行客戶端依赖等义务。如果客戶不行動,提供者就不該受到懲罰。
• static SLAs: 企業需要改變。 沒有審查程序, SLA 便無關緊要。 包括一個强制性的季度審查條款 。
• 重點是, 重點是, 重點是, 重點是, 重點是, 重點是, 重點是, 重點是, 重點是, 重點是, 重點是, 重點是, 重點是, 重點是, 重點是, 重點是, 重點是, 重點是, 重點是, 重點是, 重點是, 重點是, 重點是, 重點是, 重點是, 重點是, 重點是, 重點是, 重點是, 重點是, 重點是 , 重點是 , 重點是 , 重點是 , 重點是 , 重點是 , 重點是 , 重點是 重點是 , 重點是 。
• 忘了跟隨企業优先级:[ 量子應反映對客戶端很重要的事物,而不只是容易衡量的事物。如果客戶端數值超常時速,重量解析度比可用量高 。
• 過份的文獻 : 太多的公制或過份的法律化的傳言可以混淆雙方。 盡可能簡單, 但仍要精确 。