SLA دیتاسنتر یا توافق‌نامه سطح خدمت، مشخص می‌کند ارائه‌دهنده چه خدمتی را با چه معیار و در چه بازه‌ای متعهد می‌شود، عملکرد چگونه سنجیده خواهد شد و در صورت نقض تعهد چه فرایندی اجرا می‌شود. عددی مانند ۹۹٫۹۹ درصد بدون تعریف نقطه تحویل، زمان توقف، استثناها و روش جبران، برای مقایسه دو پیشنهاد کافی نیست.
برای مدیر فنی، این سند باید به داده‌های مانیتورینگ و فرایند رسیدگی به رخداد متصل باشد؛ برای مدیر حقوقی، تعهد باید روشن، مستند و قابل پیگیری باشد. این راهنمای مرجع، روش ارزیابی SLA دیتاسنتر در خدمات کولوکیشن را از هر دو زاویه توضیح می‌دهد. تمام اعداد نمونه در این مقاله آموزشی هستند و بیانگر تعهد قراردادی آوابرید یا استاندارد الزامی همه دیتاسنترها نیستند.
SLA دیتاسنتر چیست و چه چیزی را تضمین می‌کند؟
SLA مخفف Service Level Agreement است. در کولوکیشن، مشتری تجهیزات خود را در مرکز داده مستقر می‌کند و خدماتی مانند فضا، برق، شرایط محیطی و اتصال شبکه را دریافت می‌کند. دامنه تعهد به سرویس خریداری‌شده بستگی دارد؛ مدیریت سیستم‌عامل، برنامه کاربردی یا بکاپ لزوماً بخشی از قرارداد میزبانی فیزیکی نیست.
یک SLA دیتاسنتر قابل ارزیابی برای هر خدمت، شناسه تجهیز یا مدار، نقطه تحویل، شاخص، هدف، دوره سنجش و مسئول رسیدگی را تعیین می‌کند. برای نمونه، «دسترس‌پذیری برق در خروجی مشخص‌شده رک» با «دردسترس‌بودن وب‌سایت مشتری» دو تعهد متفاوت‌اند. خرابی نرم‌افزار ممکن است سایت را متوقف کند، در حالی که برق و اتصال تحویلی مرکز داده برقرار است.
همچنین تعهد ۱۰۰ درصدی به معنی ناممکن بودن خرابی نیست؛ معنی قراردادی آن، هدف خدمت و پیامد نقض تحت شرایط سند است. کیفیت واقعی را باید از ترکیب طراحی، بهره‌برداری، سوابق رخداد و شفافیت گزارش‌ها سنجید. برای شناخت دامنه سرویس، راهنمای خدمات کولوکیشن دیتاسنتر را نیز ببینید.
تفاوت SLA با SLI، SLO و گواهی Tier
| اصطلاح | معنی کاربردی | نمونه آموزشی |
|---|---|---|
| SLI؛ شاخص سطح خدمت | آنچه واقعاً اندازه‌گیری می‌شود | نسبت دقیقه‌های دسترس‌پذیر اتصال تحویلی |
| SLO؛ هدف سطح خدمت | سطح هدف برای یک شاخص و دوره معین | هدف دسترس‌پذیری ۹۹٫۹۵ درصد در ماه |
| SLA؛ توافق‌نامه سطح خدمت | تعهد مورد توافق همراه با شرایط و پیامد نقض | هدف مشخص، روش سنجش و اعتبار خدمت مشروط |
| Tier؛ رده‌بندی زیرساخت | معیارهای توپولوژی و قابلیت‌های زیرساخت | قابلیت نگهداری هم‌زمان یا تحمل خطا طبق رده و دامنه گواهی |
در چارچوب Google SRE، شاخص، هدف و توافق‌نامه سه مفهوم متمایزند؛ وجود عدد هدف به‌تنهایی تمام اجزای یک توافق‌نامه را فراهم نمی‌کند. منبع: Service Level Objectives.
گواهی Tier نیز جایگزین SLA دیتاسنتر نیست. Uptime Institute تصریح کرده است که استاندارد فعلی توپولوژی، برای رده‌های Tier درصد پیش‌بینی‌شده دسترس‌پذیری تعیین نمی‌کند. بنابراین از عنوان Tier III یا Tier IV نباید خودکار یک درصد آپ‌تایم یا حق جبران استخراج کرد. نوع گواهی، سایت مشمول و دامنه آن را جداگانه بررسی کنید. منبع: توضیح رسمی رده‌بندی Tier.
شاخص‌های مهم در SLA دیتاسنتر
بهتر است SLA دیتاسنتر برای برق، شبکه، شرایط محیطی و پشتیبانی شاخص‌های جدا داشته باشد. یک میانگین کلی می‌تواند اختلال شدید در یک رک را پشت عملکرد مطلوب سایر بخش‌ها پنهان کند. هدف و گزارش باید تا حد امکان به سرویس واقعی مشتری مربوط باشند.
| حوزه | آنچه باید قابل سنجش باشد | پرسش تعیین‌کننده |
|---|---|---|
| برق | وجود تغذیه قابل استفاده در نقطه تحویل و شرایط A/B | قطع یک مسیر نقض است یا قطع هم‌زمان هر دو؟ |
| شبکه | دسترس‌پذیری پورت یا اتصال، افت بسته و تأخیر در محدوده مشخص | اندازه‌گیری تا کدام نقطه و از کدام مسیر انجام می‌شود؟ |
| شرایط محیطی | دامنه توافق‌شده دما و رطوبت و مدت خروج از آن | حسگر کجاست و میانگین یا بیشینه ملاک است؟ |
| پشتیبانی | زمان پذیرش، شروع اقدام و اطلاع‌رسانی رخداد | پاسخ خودکار تیکت، پاسخ مؤثر محسوب می‌شود؟ |
| دسترسی فیزیکی | زمان و روال ورود مجاز و اجرای درخواست عملیاتی | خدمت شبانه‌روزی است یا تابع ساعات کاری؟ |
| گزارش‌دهی | موعد گزارش ماهانه و تحلیل علت ریشه‌ای | چه داده‌ای و با چه جزئیاتی تحویل می‌شود؟ |
دو کابل برق الزاماً دو مسیر مستقل نیستند. اتصال تجهیزات به تغذیه‌های مقرر، رعایت ظرفیت و پیکربندی منابع تغذیه ممکن است شرط برخورداری از تعهد برق افزونه باشد. در نمونه عمومی SLA کولوکیشن Verizon نیز شرایط برق و نحوه اتصال مشتری در تعریف خدمت اهمیت دارند؛ این نمونه، قرارداد آوابرید نیست. نمونه سند کولوکیشن.
محاسبه Uptime و زمان توقف در SLA دیتاسنتر
برای یک شاخص مبتنی بر زمان و با تعریف مشخص دسترس‌پذیری، رابطه پایه به شکل زیر است:
دسترس‌پذیری (%) = ۱۰۰ × (زمان مبنای سنجش − توقف مشمول) ÷ زمان مبنای سنجش
حد توقف متناظر با هدف = زمان مبنا × (۱ − درصد هدف ÷ ۱۰۰)
زمان مبنا می‌تواند ماه تقویمی، دوره صورتحساب یا زمان فعال بودن سرویس باشد. اگر قرارداد دوره‌هایی را از مخرج حذف می‌کند، باید همان تعریف اعمال شود. برخی اسناد فقط توقف‌های مستثنا را از صورت کسر کنار می‌گذارند و مخرج را ثابت نگه می‌دارند؛ این دو روش یک نتیجه ندارند. فرمول درج‌شده در SLA دیتاسنتر را پیش از محاسبه تثبیت کنید.
| هدف دسترس‌پذیری | توقف متناظر در ماه ۳۰روزه | توقف متناظر در سال ۳۶۵روزه |
|---|---|---|
| ۹۹٪ | ۷ ساعت و ۱۲ دقیقه | ۳ روز و ۱۵ ساعت و ۳۶ دقیقه |
| ۹۹٫۹٪ | ۴۳ دقیقه و ۱۲ ثانیه | ۸ ساعت و ۴۵ دقیقه و ۳۶ ثانیه |
| ۹۹٫۹۵٪ | ۲۱ دقیقه و ۳۶ ثانیه | ۴ ساعت و ۲۲ دقیقه و ۴۸ ثانیه |
| ۹۹٫۹۹٪ | ۴ دقیقه و ۱۹٫۲ ثانیه | ۵۲ دقیقه و ۳۳٫۶ ثانیه |
| ۹۹٫۹۹۹٪ | ۲۵٫۹۲ ثانیه | ۵ دقیقه و ۱۵٫۳۶ ثانیه |
جدول بالا صرفاً تبدیل ریاضی درصد به زمان است؛ فرض آن خدمت پیوسته و نبود زمان مستثناست. هدف ماهانه را نمی‌توان با میانگین سالانه جایگزین کرد. همچنین این زمان‌ها مجوز توقف برنامه‌ریزی‌شده نیستند و نقض یک شاخص دیگر ممکن است مستقل از درصد دسترس‌پذیری رخ دهد.
مثال: در ماه ۳۰روزه، زمان کل ۴۳٬۲۰۰ دقیقه است. اگر ۱۸ دقیقه توقف مشمول ثبت شود، دسترس‌پذیری برابر با ۹۹٫۹۵۸۳ درصد خواهد بود. این مقدار از هدف فرضی ۹۹٫۹۵ درصد بیشتر و از هدف ۹۹٫۹۹ درصد کمتر است. برای مقایسه، عدد را زودهنگام گرد نکنید و قواعد گردکردن قرارداد را رعایت کنید.
چگونه اندازه‌گیری قابل استناد انجام دهیم؟
سنجش SLA دیتاسنتر زمانی قابل دفاع است که طرفین پیش از رخداد درباره شواهد توافق کرده باشند. داشبورد سبز ارائه‌دهنده یا یک هشدار منفرد مشتری، به‌تنهایی تمام واقعیت را نشان نمی‌دهد. پایش نقطه تحویل و پایش تجربه برنامه کاربردی را جدا نگه دارید و سپس خط زمانی آن‌ها را تطبیق دهید.
- دامنه را ثبت کنید: شناسه رک، مدار، پورت، آدرس آزمون و محدوده مسئولیت هر طرف مشخص باشد.
- تعریف خرابی را بنویسید: تعداد شکست متوالی، آستانه افت بسته، مدت تداوم و معیار بازگشت خدمت روشن شود.
- زمان‌ها را همگام کنید: منطقه زمانی، دقت ساعت و شیوه ثبت شروع و پایان یکسان باشد.
- منابع شواهد را تعیین کنید: لاگ تجهیزات، سامانه برق، حسگر محیطی، پایش شبکه و تیکت‌ها با شناسه رخداد مرتبط شوند.
- داده خام را نگه دارید: مدت نگهداری، دسترسی طرفین و روش رسیدگی به اختلاف داده از قبل مشخص شود.
- گزارش را بازتولیدپذیر کنید: هر زمان حذف‌شده باید علت و ارجاع به بند مرتبط داشته باشد.
فاصله نمونه‌برداری بر دقت تشخیص اثر دارد. پایش پنج‌دقیقه‌ای ممکن است اختلال کوتاه را نبیند؛ از طرف دیگر، یک Ping ناموفق الزاماً قطع خدمت نیست. برای شاخص شبکه از آزمون مناسب و نقاط مستقل استفاده کنید، بدون آنکه خرابی اینترنت محل پایش را به اشتباه خرابی دیتاسنتر حساب کنید.
در توقف‌های هم‌پوشان، برای یک شاخص زمانی واحد، بازه مشترک را دوبار جمع نکنید. اگر برق و شبکه جداگانه تعهد دارند، هرکدام گزارش مستقل می‌خواهد؛ قواعد جمع شدن اعتبارهای جبرانی نیز باید در سند روشن باشد. نبود داده مانیتورینگ را هم خودکار معادل سلامت یا خرابی نگیرید؛ روش رسیدگی به داده مفقود را تعریف کنید.
استثناها و نگهداری برنامه‌ریزی‌شده
استثناها می‌توانند نتیجه SLA دیتاسنتر را تغییر دهند. نگهداری برنامه‌ریزی‌شده، اقدامات مشتری، مصرف خارج از ظرفیت توافق‌شده یا رویدادهای خارج از دامنه مسئولیت، فقط طبق متن قرارداد ارزیابی می‌شوند. نباید فرض کرد هر تعمیرات یا هر قطعی بیرونی خودبه‌خود مستثناست.
برای نگهداری، مهلت اطلاع قبلی، کانال اعلام، بازه مجاز، سقف مدت، اثر بر مسیر جایگزین و شرایط کار اضطراری را بنویسید. مشخص کنید اگر عملیات از زمان اعلام‌شده طولانی‌تر شود، بخش اضافه چگونه محاسبه خواهد شد. عنوان کلی «نگهداری» نباید جای ثبت علت و زمان واقعی را بگیرد.
مدیر فنی باید پیامد عملی استثنا را بررسی کند و مدیر حقوقی دامنه و نحوه اثبات آن را روشن سازد. درباره فورس‌ماژور، محدودیت مسئولیت و حقوق ناشی از نقض قرارداد، نتیجه نهایی تابع متن توافق و قانون حاکم است؛ بررسی نسخه نهایی با مشاور حقوقی انجام شود.
زمان پاسخ، بازیابی و رفع ریشه‌ای مشکل
در SLA دیتاسنتر، «پاسخ در ۱۵ دقیقه» با «بازیابی در ۱۵ دقیقه» یکسان نیست. زمان پاسخ، آغاز ارتباط یا اقدام تعریف‌شده است؛ زمان بازیابی، بازگشت خدمت به سطح مورد توافق؛ و رفع ریشه‌ای، حذف علت اصلی برای جلوگیری از تکرار است. بازگشت موقت خدمت می‌تواند پیش از تعویض قطعه معیوب رخ دهد.
برای هر شدت رخداد، زمان شروع شمارش، ساعات پوشش، مسئول اعلام شدت و دوره به‌روزرسانی را مشخص کنید. اگر زمان‌سنج هنگام انتظار برای پاسخ مشتری متوقف می‌شود، شرط توقف و شواهد آن باید دقیق باشد. عبارت «در اسرع وقت» جای هدف زمانی قابل سنجش را نمی‌گیرد.
میانگین زمان تعمیر یا بازیابی نیز تضمین حداکثر زمان یک رخداد نیست. علاوه بر میانگین، طولانی‌ترین رخداد و توزیع زمان‌ها را ببینید. RTO هدف زمان بازیابی و RPO هدف میزان قابل‌تحمل از دست رفتن داده در برنامه تداوم خدمت‌اند؛ قرارداد برق و شبکه به‌تنهایی این اهداف برنامه کاربردی را تضمین نمی‌کند.
جبران خدمت و بندهای قراردادی SLA دیتاسنتر
اعتبار خدمت یا Service Credit معمولاً کاهش هزینه یا اعتبار صورتحساب طبق جدول قرارداد است و نباید آن را خودکار معادل جبران تمام خسارت تجاری دانست. در بررسی SLA دیتاسنتر، مبنای مبلغ، پله‌های جبران، سقف دوره و روش ثبت درخواست را بخوانید.
| بند قراردادی | موضوعی که باید روشن شود |
|---|---|
| مبنای اعتبار | کل صورتحساب یا فقط هزینه خدمت آسیب‌دیده؟ |
| مهلت درخواست | تا چه زمانی و از چه کانالی باید درخواست ثبت شود؟ |
| مدارک | شناسه سرویس، خط زمانی، تیکت و لاگ مورد قبول کدام‌اند؟ |
| سقف و تجمیع | اعتبار برق و شبکه قابل جمع است یا محدودیت مشترک دارد؟ |
| رسیدگی و اعتراض | مهلت پاسخ ارائه‌دهنده و مسیر حل اختلاف چیست؟ |
| نقض تکرارشونده | برنامه اصلاحی، بازبینی سرویس یا حق خاتمه چگونه تعریف شده است؟ |
| تقدم اسناد | در تعارض سفارش، قرارداد اصلی و پیوست SLA کدام ملاک است؟ |
نمونه فرضی: اگر مبنای محاسبه، هزینه ماهانه خدمت آسیب‌دیده به مبلغ ۲۰ میلیون تومان و نرخ اعتبارِ پله مربوط ۱۰ درصد باشد، اعتبار ۲ میلیون تومان می‌شود؛ البته فقط در صورت احراز شرایط همان مثال. این مبلغ برآورد خسارت کسب‌وکار نیست و جدول جبران واقعی باید از ارائه‌دهنده دریافت شود.
نمونه ارزیابی یک رخداد
فرض کنید قرارداد، قطعی هم‌زمان تغذیه‌های A و B در نقطه تحویل را ملاک برق قرار داده و هدف شبکه نیز جداگانه تعریف شده است. در یک رخداد، مسیر A به مدت ۱۲ دقیقه قطع می‌شود اما مسیر B کل بار را نگه می‌دارد. این اتفاق باید ثبت و بررسی شود، ولی طبق همین تعریف فرضی، لزوماً توقف مشمول شاخص برق نیست. اگر هدف جداگانه‌ای برای هر مسیر وجود داشته باشد، نتیجه فرق می‌کند.
در همان ماه، اتصال شبکه تحویلی ۱۸ دقیقه قطع شده است. اگر کل این بازه مشمول باشد و زمان مبنا ۴۳٬۲۰۰ دقیقه باقی بماند، نتیجه همان ۹۹٫۹۵۸۳ درصد است. تیم فنی ابتدا شواهد نقطه تحویل و زمان بازگشت را تأیید می‌کند؛ سپس تیم قراردادی هدف، استثنا و پله جبران را تطبیق می‌دهد.
اکنون اگر برنامه مشتری پس از بازگشت شبکه پنج دقیقه دیگر برای راه‌اندازی زمان بخواهد، این پنج دقیقه نباید بدون بررسی دامنه به توقف شبکه اضافه شود. در عوض، در گزارش اثر کسب‌وکاری ثبت می‌شود. جدا کردن این دو گزارش مانع پنهان شدن تجربه واقعی مشتری یا نسبت دادن مسئولیت نادرست خواهد شد.
چک‌لیست بررسی SLA دیتاسنتر پیش از قرارداد
- خدمات مشمول و خارج از دامنه را برای همان سفارش فهرست کنید.
- شناسه نقطه تحویل برق و شبکه را با نقشه استقرار تطبیق دهید.
- هدف هر شاخص، دوره سنجش و فرمول را مکتوب دریافت کنید.
- شرایط استفاده از دو مسیر و ظرفیت مجاز هر مسیر را تأیید کنید.
- شروع و پایان توقف، حداقل مدت و دقت سنجش را مشخص کنید.
- استثناها و قواعد نگهداری برنامه‌ریزی‌شده را بررسی کنید.
- شدت رخداد، زمان پاسخ و برنامه اطلاع‌رسانی را تعیین کنید.
- نمونه گزارش ماهانه و گزارش علت ریشه‌ای درخواست کنید.
- مهلت، مدارک، سقف و روش مطالبه اعتبار خدمت را ثبت کنید.
- تقدم اسناد، تغییر شرایط و مسیر حل اختلاف را بازبینی کنید.
برای ارزیابی SLA دیتاسنتر، از دو ارائه‌دهنده بخواهید یک سناریوی یکسان را محاسبه کنند. تفاوت در نقطه تحویل، مخرج فرمول یا استثناها معمولاً از تفاوت ظاهری درصدها مهم‌تر است. تصمیم نهایی باید با معماری افزونه و هزینه توقف سازمان هماهنگ باشد.
پرسش‌های متداول
آیا آپ‌تایم ۹۹٫۹۹ درصد برای تمام خدمات کافی است؟
خیر. کفایت هدف به حساسیت خدمت، مدت هر رخداد، ساعت وقوع و امکان بازیابی بستگی دارد. حتی توقف کوتاه در زمان حساس می‌تواند اثر زیادی داشته باشد. ابتدا نیاز کسب‌وکار و نقطه اندازه‌گیری را مشخص کنید.
آیا SLA دیتاسنتر شامل خرابی سرور مشتری هم می‌شود؟
فقط اگر مدیریت یا پشتیبانی آن تجهیز صریحاً در دامنه سرویس باشد. در کولوکیشن، تعهد زیرساخت فیزیکی را نباید خودکار به سخت‌افزار، سیستم‌عامل و برنامه مشتری تعمیم داد.
آیا تعمیرات برنامه‌ریزی‌شده از Uptime حذف می‌شود؟
به متن سند بستگی دارد. شرط اطلاع، سقف مدت و روش اثرگذاری بر صورت و مخرج محاسبه باید مشخص باشد. زمان خارج از شرایط مجاز را نمی‌توان صرفاً با نام تعمیرات حذف کرد.
برای اثبات قطعی چه مدارکی لازم است؟
شناسه سرویس، زمان شروع و پایان، شماره تیکت، لاگ و نتایج پایش در نقطه مورد توافق معمولاً مبنای بررسی‌اند. فهرست الزام‌آور مدارک و مهلت ارسال را SLA دیتاسنتر و قرارداد اصلی تعیین می‌کنند.
آیا درصد بالاتر، جای بکاپ و بازیابی بحران را می‌گیرد؟
خیر. دسترس‌پذیری زیرساخت با حفاظت داده و بازیابی بحران متفاوت است. نسخه پشتیبان مستقل، آزمون بازیابی و طراحی تداوم خدمت باید متناسب با نیاز سازمان انجام شوند.
جمع‌بندی
SLA دیتاسنتر زمانی اعتماد ایجاد می‌کند که هدف عددی به دامنه مشخص، شواهد قابل بازبینی و فرایند اجرایی متصل باشد. مدیر فنی باید بتواند محاسبه را از روی داده‌ها بازتولید کند و مدیر حقوقی باید بتواند تعهد، استثنا و پیامد نقض را بدون ابهام تشخیص دهد.
برای بررسی پیشنهاد کولوکیشن آوابرید، مشخصات تجهیزات، نیاز برق و شبکه، حساسیت سرویس و الزامات دسترسی خود را آماده کنید و نسخه SLA مربوط به همان پیشنهاد را بخواهید. درصد دسترس‌پذیری، جدول جبران و شرایط پشتیبانی باید از سند رسمی همان سرویس استخراج شوند؛ مبنای تصمیم، تعهد مکتوب و متناسب با نیاز سازمان است.