---
title: "چارچوب SLA لایه‑بندی‌شده برای قراردادهای SaaS چند ابری"
---

# چارچوب SLA لایه‑بندی‌شده برای قراردادهای SaaS چند ابری

یک **توافق‌نامه سطح خدمات (SLA) لایه‑بندی‌شده** رویکردی ساختارمند است که انتظارات عملکردی متغیر گروه‌های مختلف کاربری را با توانمندی‌های محیط چند‑ابری هم‌تراز می‌کند. همان‌طور که سازمان‌ها به‌طور فزاینده‌ای بارهای کاری خود را بین چندین ارائه‌دهنده ابری توزیع می‌کنند، یک SLA یک‑سان برای همه دیگر عملیاتی نیست. SLAهای لایه‑بندی‌شده به مدیران قرارداد امکان می‌دهند ریسک، هزینه و مسئولیت‌های عملیاتی را به‌دقت بیشتری تخصیص دهند، در حالی که برای مشتریان انتظارات شفافی برای هر لایهٔ سرویس فراهم می‌آورند.

## چرا SLAهای لایه‑بندی‌شده در محیط چند ابری مهم هستند

معماری‌های چند ابری ترکیبی از قدرت‌های ابرهای عمومی، ابرهای خصوصی و نقاط لبه (Edge) هستند. هر پلتفرم پروفایل‌های تأخیر، ضمانت‌های در دسترس بودن و محدودیت‌های محل دادهٔ متفاوتی دارد. یک SLA لایه‑بندی‌شده این تفاوت‌ها را با تعریف **نوارهای عملکرد** جداگانه—به عنوان مثال «طلا»، «نقره» و «برنز»—بازتاب می‌دهد. این رویکرد:

* تأمین‌کنندگان را ترغیب می‌کند منابع را متناسب با مهم‌ترین بارهای کاری تنظیم کنند.  
* به سازمان‌ها امکان می‌دهد خدمات را بر اساس ارزشی که ارائه می‌شود قیمت‌گذاری کنند و یک سلسله مراتب هزینه‑فایدهٔ طبیعی ایجاد نمایند.  
* مسیر ارجاع واضحی را هنگام افت معیارها زیر آستانه‌های توافقی فراهم می‌کند و باعث کاهش مناقشات می‌شود.

## عناصر اصلی یک SLA لایه‑بندی‌شده

### تعریف لایهٔ سرویس

یک لایه گروه‌بندی منطقی ویژگی‌های سرویس مانند افزونگی جغرافیایی، زمان پاسخ و توان عبوری است. هنگام تدوین یک لایه، موارد زیر را بگنجانید:

* **دامنه جغرافیایی** – مناطق یا زون‌های تحت پوشش را مشخص می‌کند.  
* **مدل افزونگی** – پیکربندی‌های فعال‑فعال یا فعال‑انتظاری را توصیف می‌کند.  
* **ارائه‌دهندگان ابر پشتیبانی‌شده** – فهرست ابری‌هایی (مثلاً AWS، Azure، GCP) که لایه را میزبانی می‌کنند.  

### معیارهای عملکرد

معیارها باید قابل‌کمیت و قابل‌حسابرسی باشند. **شاخص‌های کلیدی عملکرد** (KPI) رایج برای SaaS شامل:

* **در دسترس بودن** – به صورت درصد زمان کارکرد در طول یک ماه محاسبه می‌شود.  
* **تأخیر** – زمان متوسط رفت‑و‑آمد برای فراخوانی‌های API.  
* **توان عبوری** – تعداد تراکنش‌ها در هر ثانیه.  
* **نرخ خطا** – نسبت درخواست‌های ناموفق به کل درخواست‌ها.

### ساختار جبران خسارت

جبران‌ها باید متناسب با اهمیت لایه باشد. جبران‌های معمول شامل اعتبار سرویس، پشتیبانی تسریع‌شده و حق فسخ بدون جریمه است. جدول جبران اغلب به‌صورت تابعی از کسری معیار بیان می‌شود. برای مثال، کاهش ۰٫۵ % در در دسترس بودن برای لایهٔ «طلا» ممکن است منجر به اعتبار سرویس ۵ % شود، در حالی که همان کاهش برای «برنز» ممکن است تنها ۲ % اعتبار بدهد.

### اندازه‌گیری و گزارش‌گیری

یک چارچوب شفاف اندازه‌گیری ضروری است. بندهای قرارداد باید اجباری کنند:

* استفاده از ابزارهای مانیتورینگ مستقل یا حسابرسان سوم.  
* دورهٔ گزارش‌گیری (مثلاً داشبوردهای لحظه‌ای، خلاصه‌های ماهانه).  
* دوره نگهداری داده‌های لاگ حسابرسی، که معمولاً با سیاست‌های [RPO](https://azure.microsoft.com/en-us/support/legal/sla/) و [RTO](https://www.ibm.com/cloud/learn/multi-cloud) هم‌راستاست.

## ساختن بند SLA لایه‑بندی‌شده

در زیر یک الگوی بند مدولار آورده شده که می‌تواند برای هر قرارداد SaaS چند‑ابری تنظیم شود. مقادیر داخل براکت‌ها را با مقادیر مخصوص قرارداد جایگزین کنید.

```
1. Service Tiers. The Provider shall deliver the Services in three tiers: “Gold,” “Silver,” and “Bronze.” Each tier is defined by the Service Tier Matrix attached as Exhibit A.
2. Performance Metrics. For each tier, the Provider shall meet the performance metrics listed in Exhibit B. Metrics are measured on a monthly basis using the Monitoring System described in Exhibit C.
3. Remedies. If the Provider fails to meet any metric for a given tier, the Customer shall be entitled to the remedies set forth in Exhibit D, proportional to the severity of the breach.
4. Measurement and Reporting. The Provider shall deliver performance reports to the Customer within five business days after the end of each calendar month. The reports shall include raw measurement data, aggregated statistics, and any incident logs required for verification.
5. Audit Rights. The Customer may, upon reasonable notice, engage an independent auditor to verify the Provider’s compliance with this SLA. Audit costs shall be borne by the party requesting the audit unless a material breach is discovered, in which case the Provider shall reimburse the Customer.
```

## تخصیص ریسک بین لایه‌ها

تخصیص ریسک باید معادل تأثیر تجاری هر لایه باشد. لایه‌های با ارزش بالاتر مسئولیت بیشتری بر عهدهٔ تأمین‌کننده می‌گذارند، در حالی که لایه‌های پایین‌تر ریسک عملیاتی بیشتری به مشتری منتقل می‌شود. تکنیک‌های متعادل‌سازی ریسک زیر را در نظر بگیرید:

* **افزونگی مشترک** – برای لایهٔ «نقره»، مشتری می‌تواند نمونه‌های آماده‑پشتیبان بیشتری در یک ابر دوم provision کند و بدین‌صورت مسئولیت انحصاری تأمین‌کننده برای در دسترس بودن را کاهش دهد.  
* **تریگرهای ارتقاء** – آستانه‌های واضحی تعریف کنید که به‌صورت خودکار یک مشکل را از سطح «برنز» به «نقره» ارتقا دهند و پاسخ به‌موقع را بدون نقض قرارداد تضمین کنند.  
* **استثناهای فورس ماژور** – مسئولیت تأمین‌کننده را برای رویدادهای خارج از کنترل او محدود کنید، اما بندی اضافه کنید که تأمین‌کننده را ملزم به بازیابی سرویس در حداکثر دورهٔ **Mean Time Between Failures** ([MTBF](https://www.iso.org/standard/54573.html)) می‌کند.

## سازوکارهای اجرایی

اجرای مؤثر به‌معنای داشتن **تریگرهای جبران** و **نگه‌داشتن پرداخت‌ها** واضح است. الگوی رایج این است که درصدی از فاکتور ماهانه تا زمان تأیید توافق‌نامه SLA توسط تأمین‌کننده، نگه‌داری