توافقنامه سطح خدمات ابر نبریکس
این سند سطح خدمت قابل انتظار برای خدمات ابری ارائهشده توسط نبریکس را تعریف میکند. این خدمات شامل IaaS، KaaS و سرویسهای مدیریتی وابسته به پلتفرم ابری است.
هدف سند
هدف این SLA تعیین شفاف مسئولیتهای ارائهدهنده و مشتری، نحوه محاسبه دسترسپذیری، سطح پشتیبانی، زمان پاسخگویی، استثناها و جبران خدمت در صورت عدم تحقق سطح خدمت است.
دامنه خدمات
این SLA شامل سرویسهای زیر است: IaaS - Infrastructure as a Service: شامل ماشین مجازی، دیسک، شبکه مجازی، Floating IP، Security Group، Image، Volume و سرویسهای مدیریتی وابسته. KaaS - Kubernetes as a Service: شامل ایجاد و مدیریت کلاستر Kubernetes اختصاصی برای هر مشتری، شامل Control Plane، Worker Nodeها، اتصال به شبکه، Volume Integration و Add-onهای پایه. Cloud Management Services: شامل پرتال ابری، Ticketing پایه و API، Identity/IAM، Billing، Monitoring. این SLA شامل نرمافزارها، اپلیکیشنها، دیتابیسها، کانتینرها، workloadها، imageها، پیکربندی سیستمعامل، تنظیمات داخل کلاستر توسط مشتری و سرویسهای خارج از کنترل مستقیم ارائهدهنده نمیشود؛ مگر آنکه در قرارداد جداگانه ذکر شده باشد.
تعاریف
Monthly Uptime Percentage / دسترسپذیری ماهانه: نسبت دقایقی از ماه که سرویس در دسترس بوده است به کل دقایق همان ماه. فرمول محاسبه: Monthly Uptime % = ((Total Minutes - Downtime Minutes) / Total Minutes) × 100 Downtime: مدت زمانی که سرویس تحت کنترل ارائهدهنده بهصورت کامل یا موثر غیرقابل استفاده باشد. Downtime زمانی محاسبه میشود که اختلال بیش از ۵ دقیقه پیوسته ادامه داشته باشد و توسط سیستم مانیتورینگ ارائهدهنده یا تیکت معتبر مشتری تأیید شود. Planned Maintenance: عملیات برنامهریزیشده نگهداری، ارتقا، patch یا تغییر زیرساخت یا بهبود امنیتی که از قبل به مشتری اطلاعرسانی شده باشد. Emergency Maintenance: عملیات فوری برای حفظ امنیت، پایداری یا جلوگیری از اختلال گسترده که ممکن است بدون اطلاعرسانی قبلی یا با اطلاعرسانی کوتاه انجام شود. Service Credit: اعتبار مالی یا تخفیف قابل اعمال روی فاکتور آینده مشتری، در صورتی که سطح خدمت توافقشده محقق نشود.
سطح دسترسپذیری سرویسها
جدول زیر سطح SLA ماهانه پیشنهادی برای سرویسهای اصلی پلتفرم ابری نبریکس را نشان میدهد.
| ردیف | سرویس | SLA ماهانه پیشنهادی | توضیح |
|---|---|---|---|
| 1 | Cloud Portal | 99.90% | دسترسی به پرتال مدیریت ابر |
| 2 | Cloud API / IAM | 99.90% | APIهای اصلی، احراز هویت و مدیریت پروژهها |
| 3 | IaaS Compute API | 99.90% | ایجاد، حذف، روشن/خاموش و مدیریت VM |
| 4 | Single VM Connectivity | 99.50% | اتصال شبکه به یک ماشین مجازی منفرد |
| 5 | HA VM Group | 99.90% | حداقل دو VM در دو Fault Domain متفاوت |
| 6 | Enterprise HA VM Group | 99.95% | فقط در صورت وجود طراحی HA تأییدشده توسط ارائهدهنده |
| 7 | Block Storage / Volume | 99.90% | دسترسی به Volumeهای متصلشده به VM |
| 8 | Virtual Network / Router / Floating IP | 99.90% | ارتباطات شبکه داخلی و خروجی تحت کنترل پلتفرم |
| 9 | Image Service | 99.90% | دسترسی به Imageهای عمومی و تأییدشده |
| 10 | KaaS Dedicated Control Plane Production | 99.90% | کلاستر اختصاصی با حداقل ۳ Control Plane |
| 11 | KaaS Single Control Plane / Dev Test | 99.50% | کلاسترهای توسعه، تست یا تکمسیر |
| 12 | KaaS Worker Nodes | مطابق IaaS | Workerها بهعنوان VM محاسبه میشوند |
| 13 | KaaS Managed Add-ons پایه | 99.90% | CoreDNS، CSI، CNI و اجزای پایه در صورت مدیریت توسط ارائهدهنده |
SLA سرویس IaaS
ارائهدهنده متعهد است سرویسهای IaaS را مطابق سطح دسترسپذیری تعریفشده در این سند ارائه کند.
ماشین مجازی
SLA ماشین مجازی شامل موارد زیر است: دسترسی شبکه به ماشین مجازی دسترسی به دیسک متصلشده امکان مدیریت VM از طریق API یا پرتال سلامت زیرساخت محاسباتی تحت کنترل ارائهدهنده موارد زیر تحت SLA ماشین مجازی نیست: خرابی سیستمعامل داخل VM مصرف کامل CPU، RAM، Disk یا Network توسط مشتری حذف یا تغییر اشتباه توسط مشتری پیکربندی اشتباه Floating IP، Firewall، Route یا Security Group توسط مشتری مشکل نرمافزار یا سرویس داخل VM حمله، نفوذ یا سوءاستفاده ناشی از credentialهای مشتری VMهایی که توسط مشتری خاموش، suspend یا حذف شدهاند
دیسک و Volume
SLA ذخیرهسازی شامل دسترسی به Volumeهای سالم و attachشده است. این SLA تضمین backup یا بازیابی داده نیست، مگر آنکه سرویس Backup/Snapshot جداگانه خریداری و فعال شده باشد. مشتری مسئول تهیه backup از دادههای حیاتی خود است، مگر آنکه در قرارداد managed backup خلاف آن ذکر شده باشد.
شبکه
SLA شبکه شامل اجزای تحت کنترل پلتفرم است؛ از جمله شبکه داخلی، Floating IP، Router و Security Group. اینترنت عمومی، DNS مخابراتی خارج از دیتاسنتر، CDN خارجی و سرویسهای Third-party خارج از دامنه این SLA هستند.
SLA سرویس KaaS
بخشهای زیر سطح خدمت KaaS و زمانهای provisioning را تعریف میکنند.
مدل ارائه KaaS
در سرویس KaaS، برای هر مشتری یک کلاستر Kubernetes اختصاصی ایجاد میشود. Control Plane و Worker Nodeها بهصورت ماشین مجازی در پروژه اختصاصی مشتری روی زیرساخت IaaS ارائهدهنده اجرا میشوند. کلاسترهای KaaS بهصورت namespace-based اشتراکی ارائه نمیشوند، مگر آنکه در سفارش مشتری صراحتاً ذکر شده باشد.
دامنه SLA کلاستر Kubernetes
SLA کلاستر Kubernetes شامل موارد زیر است:
- دسترسپذیری Kubernetes API Server
- سلامت Control Planeهای مدیریتشده توسط ارائهدهنده
- اتصال کلاستر به شبکه و Storage تحت کنترل ارائهدهنده
- Add-onهای پایه مدیریتشده توسط ارائهدهنده
- جایگزینی Worker Nodeهای معیوب در Managed Node Pool
موارد زیر تحت SLA KaaS نیست:
- Availability اپلیکیشنها و Podهای مشتری
- خطای manifest، image، container یا Helm chart مشتری
- کمبود resource ناشی از درخواست اشتباه CPU/RAM
- حذف workload، namespace، secret، PVC یا resource توسط مشتری
- تغییرات مستقیم مشتری روی اجزای سیستمی کلاستر
- نصب Operatorها یا Add-onهای ناسازگار توسط مشتری
- اختلال ناشی از admission webhook، policy، network policy، ingress یا service mesh مشتری
- استفاده از نسخههای Kubernetes خارج از چرخه پشتیبانی
- عدم رعایت حداقل replica، readiness probe، liveness probe یا PodDisruptionBudget توسط مشتری
Provisioning کلاستر
زمان هدف برای ایجاد کلاستر استاندارد KaaS:
| نوع درخواست | زمان هدف |
|---|---|
| ایجاد کلاستر KaaS استاندارد | حداکثر ۶۰ دقیقه |
| افزودن Worker Node به Node Pool موجود | حداکثر ۳۰ دقیقه |
| حذف Worker Node | حداکثر ۳۰ دقیقه |
| ارتقای Minor Version Kubernetes | طبق زمانبندی و پنجره نگهداری |
| ارتقای Patch Version | طبق پنجره نگهداری یا درخواست مشتری |
زمان Provisioning به موجودی ظرفیت، flavor، image، quota و سلامت زیرساخت وابسته است. تأخیر ناشی از عدم وجود quota یا شبکه محسوب نمیشود. Downtime اطلاعات ناقص سفارش مشتری محسوب نمیشود.
نگهداری و ارتقا
ارائهدهنده مجاز است برای حفظ امنیت، پایداری و کیفیت سرویس، عملیات نگهداری انجام دهد.
نگهداری برنامهریزیشده
اطلاعرسانی حداقل ۷۲ ساعت قبل از عملیات ترجیحاً در ساعات کممصرف حداکثر ۴ ساعت در ماه برای هر سرویس، مگر در موارد خاص زمان نگهداری اعلامشده محسوب نمیشود Downtime، مگر آنکه از پنجره اعلامشده فراتر رود
نگهداری اضطراری
در صورت وجود ریسک امنیتی، ناپایداری جدی یا احتمال اختلال گسترده، ارائهدهنده میتواند Emergency Maintenance انجام دهد. در این حالت، اطلاعرسانی در سریعترین زمان ممکن انجام میشود.
پشتیبانی و زمان پاسخگویی
جدول زیر زمان پاسخ اولیه و بهروزرسانی وضعیت را بر اساس سطح حادثه نشان میدهد. پشتیبانی P1 برای سرویسهای Production بهصورت 7×24 ارائه میشود. پشتیبانی سایر سطوح طبق ساعات کاری رسمی نبریکس انجام میشود، مگر آنکه قرارداد پشتیبانی Enterprise فعال باشد.
| سطح حادثه | تعریف | زمان پاسخ اولیه | بهروزرسانی وضعیت |
|---|---|---|---|
| P1 - Critical | قطعی کامل سرویس تولیدی یا عدم دسترسی گسترده | ۱۵ دقیقه | هر ۳۰ دقیقه |
| P2 - High | اختلال جدی، کاهش شدید کیفیت یا تأثیر روی چند مشتری | ۱ ساعت | هر ۴ ساعت |
| P3 - Medium | مشکل محدود، workaround موجود، بدون قطعی گسترده | ۴ ساعت کاری | روزانه |
| P4 - Low | درخواست عادی، سوال، تغییرات غیراضطراری | ۱ روز کاری | طبق نیاز |
مسئولیتهای مشتری
مشتری مسئول موارد زیر است:
- طراحی صحیح High Availability برای اپلیکیشن خود
- تهیه backup از دادههای حیاتی
- مدیریت امن credentialها، SSH keyها، tokenها و kubeconfigها
- پیکربندی صحیح DNS، firewall، security group و route
- رعایت quota و ظرفیت خریداریشده
- استفاده از imageها و نسخههای پشتیبانیشده
- مانیتورینگ اپلیکیشن و workloadهای خود
- بهروزرسانی نرمافزارهای داخل VM، مگر در سرویس managed OS
- رعایت سیاستهای امنیتی و Acceptable Use Policy
- عدم انجام تغییرات مخرب روی اجزای سیستمی کلاستر Kubernetes
استثناهای SLA
موارد زیر از محاسبه SLA خارج هستند:
- Planned Maintenance اعلامشده
- Emergency Maintenance برای امنیت یا پایداری
- خطا یا پیکربندی اشتباه مشتری
- خرابی نرمافزار، اپلیکیشن، دیتابیس یا workload مشتری
- حملات DDoS یا حملات امنیتی خارج از سطح محافظت خریداریشده
- قطعی اینترنت، DNS یا سرویسهای Third-party خارج از کنترل ارائهدهنده
- عدم پرداخت، تعلیق سرویس یا اتمام اعتبار حساب
- مصرف بیش از quota یا ظرفیت خریداریشده
- حذف، خاموشکردن یا تغییر منابع توسط مشتری
- Force Majeure شامل بلایای طبیعی، جنگ، آشوب، تحریم، قطعی گسترده برق یا مخابرات خارج از کنترل ارائهدهنده
- استفاده از flavorها، imageها یا add-onهای پشتیباننشده
- اختلال ناشی از migration یا تغییراتی که به درخواست مشتری انجام شده است
- سرویسهای Beta، Preview یا SLA آزمایشی
Service Credit
در صورتی که دسترسپذیری ماهانه یک سرویس کمتر از SLA تعریفشده باشد، مشتری میتواند درخواست Service Credit ثبت کند. Service Credit فقط روی مبلغ همان سرویس آسیبدیده در همان ماه محاسبه میشود و شامل کل فاکتور مشتری، سرویسهای دیگر، خسارت غیرمستقیم، از دست رفتن سود، از دست رفتن داده یا هزینههای جانبی نمیشود.
| دسترسپذیری ماهانه واقعی | Service Credit پیشنهادی |
|---|---|
| کمتر از SLA تعهدشده تا %99.00 | ۱۰٪ از مبلغ سرویس آسیبدیده |
| کمتر از %99.00 تا %95.00 | ۲۵٪ از مبلغ سرویس آسیبدیده |
| کمتر از %95.00 | ۵۰٪ از مبلغ سرویس آسیبدیده |
حداکثر Service Credit در هر ماه برابر با ۵۰٪ مبلغ همان سرویس آسیبدیده در همان ماه است، مگر آنکه در قرارداد Enterprise سقف دیگری توافق شده باشد.
فرآیند درخواست Service Credit
برای دریافت Service Credit، مشتری باید حداکثر تا ۳۰ روز پس از پایان ماهی که اختلال در آن رخ داده است، درخواست رسمی ثبت کند.
درخواست باید شامل موارد زیر باشد:
- نام سرویس آسیبدیده
- زمان شروع و پایان اختلال
- شرح اثر اختلال
- شماره تیکتهای مرتبط
- لاگ، مانیتورینگ یا شواهد فنی در صورت وجود
ارائهدهنده پس از بررسی لاگها، مانیتورینگ داخلی و اطلاعات مشتری، نتیجه را اعلام میکند. در صورت تأیید، اعتبار مالی روی فاکتور آینده مشتری اعمال میشود.
Backup و بازیابی
SLA حاضر بهتنهایی شامل backup دادههای مشتری نیست. Backup، Snapshot و Replication باید بهصورت سرویس جداگانه فعال و در قرارداد مربوطه تعریف شود. برای KaaS، ارائهدهنده میتواند backup اجزای مدیریتی کلاستر را طبق سیاست داخلی انجام دهد. این backup جایگزین backup اپلیکیشن، دیتابیس، PVC یا objectهای مشتری نیست. جدول زیر اهداف بازیابی پیشنهادی برای سرویسهای Production را نشان میدهد:
| سرویس | هدف RTO | هدف RPO |
|---|---|---|
| Cloud Management Plane | ۴ ساعت | ۲۴ ساعت |
| KaaS Control Plane | ۴ ساعت | ۲۴ ساعت |
| Enterprise KaaS | ۲ ساعت | ۶ ساعت |
| Managed Volume Backup | طبق پلن خریداریشده | طبق پلن خریداریشده |
RTO و RPO فقط زمانی تعهد مالی محسوب میشوند که در قرارداد سرویس backup یا disaster recovery بهصورت جداگانه ذکر شده باشند.
امنیت
ارائهدهنده مسئول امنیت لایه زیرساخت، سختافزار، hypervisor، سرویسهای پایه، شبکه مدیریتی و کنترلهای امنیتی پلتفرم است. مشتری مسئول امنیت سیستمعامل، اپلیکیشن، داده، کلیدها، credentialها، policyها، container imageها و دسترسی کاربران خود است. در KaaS، مشتری مسئول مدیریت RBAC داخل namespaceها، secretها، image registryها، policyها و workloadهای خود است، مگر آنکه سرویس Managed Security جداگانه خریداری شده باشد.
تغییرات SLA
ارائهدهنده میتواند SLA را با اطلاعرسانی قبلی بهروزرسانی کند. تغییرات SLA برای قراردادهای فعال، طبق مفاد قرارداد اصلی اعمال میشود. کاهش سطح SLA برای مشتریان فعال بدون اطلاعرسانی و توافق قراردادی اعمال نخواهد شد.
محدودیت مسئولیت
جبران عدم تحقق SLA محدود به Service Credit تعریفشده در این سند است. SLA تنها راهکار جبرانی مشتری بابت عدم تحقق سطح خدمت است. Service Credit تعهد مالی بیشتری محسوب نمیشود، مگر آنکه در قرارداد اصلی خلاف آن ذکر شده باشد.
اولویت اسناد
در صورت تعارض میان این SLA، قرارداد اصلی مشتری و ضمیمه اختصاصی برای سرویس خاص، مفاد قرارداد اصلی اولویت دارد. در صورت وجود ضمیمه اختصاصی برای سرویس خاص، ضمیمه اختصاصی همان سرویس نسبت به مفاد عمومی این سند اولویت خواهد داشت.
جمعبندی سطح سرویس پیشنهادی
این SLA برای ارائه خدمات Public Cloud با مدل پایدار و قابل توسعه طراحی شده است. سطح پایه پیشنهادی برای اکثر سرویسهای Production برابر با %99.90 است. SLA بالاتر مانند %99.95 فقط برای سرویسهایی توصیه میشود که طراحی HA، automation، مانیتورینگ، ظرفیت کافی و عملیات backup برای آنها فعال باشد.