تاریخچه تغییرات

تاریخچه تغییرات سند SLA در جدول زیر قابل مشاهده است. این سند در فواصل زمانی مشخص مورد بازبینی قرار می‌گیرد.

تایید‌کنندگان

در جدول زیر نام تمامی ذی‌نفعان اصلی (Primary Stakeholders) قرارداد و نقش‌ ایشان آمده است. سند حاضر به امضا و تایید این ذی‌نفعان رسیده است.

تاریخ آخرین بازبینی:

تاریخ تعیین‌شده برای بازبینی بعدی:

مقدمه

این سند، یک توافق‌نامه سطح سرویس بین [سرویس‌دهنده] و [سرویس‌گیرنده] به منظور توافق دوطرفه بر روی سطح خدمات مورد نیاز جهت پشتیبانی، نگه‌داری و پایداری سرویس [نام سرویس] است.

توصیف سرویس

در این بخش، به صورت خلاصه سرویس مورد نظر توصیف می‌شود و به طور کلی به کارکردها، مخاطبان، اهداف و خروجی‌های سرویس اشاره می‌گردد. 

طبقه‌بندی کارکردهای سیستم

در این بخش، کارکردهای سیستم برای کنشگران مختلف از جهت اهمیت در سرویس‌دهی طبقه‌بندی می‌شوند. این طبقه‌بندی مبنای تعیین سطح حساسیت سرویس و تعیین جرائم خواهد بود.

به عنوان مثال در یک سامانه «فروشگاه آنلاین» می‌توانیم کارکردهای سیستم را از جهت اهمیت در سرویس‌دهی به شکل زیر طبقه‌بندی کنیم.

بازه‌های زمانی

در این بخش، روزها و ساعت‌های روز در چند بازه زمانی تعریف می‌شوند. روزهای خاصی از سال (مثل ایام نوروز) یا روزهای خاصی از هفته به دلیل حساسیت متفاوت در دسته جداگانه‌ای قرار می‌گیرند. به همین ترتیب، ساعت‌های مختلف ایام مختلف سال از جهت حساسیت قابل تفکیک هستند. در جدول زیر بازه‌های زمانی تعریف شده تا در بخش‌های دیگر مورد ارجاع قرار گیرند. در جدول زیر، تایم‌زون ایران و تقویم هجری شمسی ملاک است.

به عنوان مثال، در یک سامانه «فروشگاه آنلاین» می‌توانیم زمان‌های فعالیت سیستم را از جهت اهمیت در سرویس‌دهی به شکل زیر طبقه‌بندی کنیم. 

طبقه‌بندی Issueها

به دلیل وجود ایراد در عملکرد سیستم یا وجود حفره‌های امنیتی یا کندی و امثال آن‌ها، کارهایی به سرویس‌دهنده ارجاع داده می‌شود. کارهای ارجاعی از جهت اهمیت در چند دسته طبقه‌بندی می‌شوند.

طبقه‌بندی باگ‌ها

باگ به معنی اختلال در کارکرد سیستم است. در این بخش، باگ‌های سامانه از جهت میزان تاثیرگذاری بر کارکرد طبقه‌بندی می‌گردد.

در جدول زیر نمونه‌ای از این طبقه‌بندی قابل رویت است.

طبقه‌بندی آسیب‌های امنیتی

به طرق مختلف ممکن است آسیب‌پذیری‌هایی از جهت امنیت در سیستم کشف شود. درجه اهمیت و ضریب اثر این آسیب‌پذیری‌ها متفاوت است. در جدول زیر، آسیب‌پذیری‌های امنیتی طبقه‌بندی شده‌اند. این طبقه‌بندی طبق استاندارد ... صورت گرفته است.

در جدول زیر نمونه‌ای از این طبقه‌بندی قابل رویت است. 

طبقه‌بندی خرابی‌ها

سیستم باید دائما در دسترس کاربران و کنشگران مختلف باشد. در عین حال ممکن است خرابی‌هایی در اجزای سخت‌افزاری یا اجزای نرم‌افزاری موجب مختل شدن سرویس‌دهی به صورت کلی یا جزئی شوند. در جدول زیر این خرابی‌ها طبقه‌بندی شده‌اند.

در جدول زیر نمونه‌ای از این طبقه‌بندی قابل رویت است. 

واحد جریمه

در صورت نقض تعهد توسط سرویس‌دهنده جرایمی به وی تعلق می‌گیرد. این جریمه بسته به میزان نقض تعهد و تبعات آن متفاوت خواهد بود. جریمه در بخش‌های مختلف به صورت ضریبی از «واحد جریمه» بیان می‌گردد. یک «واحد جریمه» برابر هزینه پشتیبانی یک روز (کل هزینه پشتیبانی تقسیم بر تعداد روز دوره پشتیبانی) ضرب در یک است. 

شاخص‌های سنجش سرویس

کیفیت سرویس بر اساس شاخص‌های (Service Level Indicator) زیر سنجیده می‌شود:

پنجره‌های پشتیبانی

مسئولین سرویس می‌توانند با اطلاع‌رسانی قبلی و پس از دریافت تایید از نماینده سرویس‌گیرنده در چارچوب جدول زیر، برای انجام امور پشتیبانی، اختلالاتی را در سرویس‌دهی ایجاد نمایند. این زمان‌ها اصطلاحا پنجره پشتیبانی (Maintenance Window) نامیده می‌شوند.

جدول زیر نمونه‌ای از برنامه‌ریزی پنجره‌های پشتیبانی را نمایش می‌دهد.

1. پنجره‌های پشتیبانی باید قبل از شروع به تایید نماینده سرویس‌گیرنده رسیده باشند. 
2. در «پنجره‌های پشتیبانی» هیچ یک از شاخص‌های کیفیت سرویس (SLI‌ها) غیر از «نرخ بالا بودن سیستم» اندازه‌گیری نمی‌شود.
3. در صورتی که بودجه خطای (Error Budget) شاخص‌های مرتبط با عملیات (Operation) همچون «سرعت پاسخگویی» و «نرخ پاسخ صحیح» و «نرخ بالا بودن سیستم»‌ تمام شده باشد،‌ باید پنجره‌های پشتیبانی به بازه‌های زمانی بعدی موکول گردد، مگر آنکه انجام آن‌ها ضروری تشخیص داده شود. 
4. در صورتی که عملیات پشتیبانی کارکردهای متنوعی را متاثر کند، اولویت بالاتر ملاک برنامه‌ریزی خواهد بود.

نحوه اندازی‌گیری سطح سرویس

نحوه اندازی‌گیری زمان اختلالات سرویس و رعایت تعهد با روش‌های زیر سنجیده می‌شود.

در جدول زیر نمونه‌ای از نحوه اندازه‌گیری زمان اختلالات آورده شده است.

محدوده مسئولیت‌ها

در این بخش، محدوده مسئولیت‌های ارائه‌کننده و دریافت‌کننده سرویس با ذکر محدودیت‌ها، پیش‌نیازها و استثناء‌ها تببین می‌گردد. 

مسئولیت‌های سرویس‌دهنده

• سرویس‌دهنده موظف است تغییراتی که ممکن است اختلالی در سرویس‌دهی ایجاد کنند را بدون اطلاع و اجازه سرویس‌گیرنده اعمال نکند.
• سرویس‌دهنده موظف است نیازهای سخت‌افزاری خود را با توضیح مکفی و ذکر فوریت، حداقل یک ماه قبل از بحرانی شدن وضعیت به اطلاع سرویس‌گیرنده برساند.
• سرویس‌دهنده موظف است مقیاس قابل تحمل با سخت‌افزارهای موجود را به اطلاع سرویس‌گیرنده برساند.
• سرویس‌دهنده موظف است از همه داده‌های سرویس بکاپ تهیه نموده و در تجهیزات ذخیره‌سازی مربوط به بکاپ قرار دهد.
• سرویس‌دهنده موظف است پیش‌نیازهای پایداری هر یک از اجزای سیستم و همچنین تبعات خرابی آن را در قالب یک مستند شفاف نماید تا سرویس‌گیرنده در صورت صلاحدید اقدام به درخواست پایداری بیشتر و تامین منابع و پیش‌نیازهای آن نماید.
  • مثال: سرویس پایگاه‌داده elasticsearch، شرط پایداری: حداقل دو سرور از سه نود کلاستر سالم باشد،‌ تبعات خرابی: خریداران امکان جستجو روی محصولات را نخواهند داشت. ممکن است بخشی از داده از دست برود و در این صورت باید مجددا reindex شود.
    
• سرویس‌دهنده موظف است چیدمان اجزای نرم‌افزاری را روی تجهیزات سخت‌افزاری به گونه‌ای مدیریت کند که خراب شدن هیچ سرور واحدی کارکردهای اصلی سیستم را متوقف نکند. در صورت توقف سرویس با خراب شدن یک سرور با وجود تامین منابع، مسئولیت به عهده سرویس‌دهنده است.
• در صورت نیاز، سرویس‌دهنده باید سرویس را حداکثر ظرف سه روز کاری از صفر به طور کامل روی یک مرکز داده جدید نصب نماید. بدیهی است چنانچه نصب مجدد ریشه در خرابی‌های ناشی از نقض تعهدات سرویس‌دهنده نداشته باشد، خدمات وی مشمول هزینه مجزا خواهد بود.

سلب مسئولیت از سرویس‌دهنده

• در صورتی که پیش‌نیازهای پایداری یک سرویس نقض گردد و سرویس‌دهنده قبلا پیش‌نیازها را به صورت شفاف اعلام کرده باشد، مسئولیت قطع سرویس به عهده وی نمی‌باشد.
• در صورتی که باری بیش از مقیاس اعلام‌شده توسط سرویس‌دهنده به سیستم تحمیل شود، مسئولیت کیفیت سرویس به عهده سرویس‌دهنده نمی‌باشد.
• سرویس‌دهنده نسبت به تجهیزات شبکه، سرورها و تجهیزات سخت‌افزاری، سیستم‌عامل و زیرساخت ابری مسئولیتی ندارد.
• سرویس‌دهنده نسبت به نگهداری بکاپ‌ها تعهدی ندارد و صرفا موظف است فایل‌های بکاپ را در فضای ذخیره‌سازی مشخص‌شده از سوی سرویس‌گیرنده قرار دهد.
• سرویس‌دهنده نسبت به قطع شدن سرویس‌های بالادستی که پیش‌نیاز کارکرد صحیح سیستم هستند (مثل سرویس‌های پیامک و ایمیل) مسئولیتی ندارد.

مسئولیت‌های سرویس‌گیرنده

• سرویس‌گیرنده موظف است تجهیزات و پیش‌نیازهای سرویس‌دهی را تامین نماید.

سلب مسئولیت از سرویس‌گیرنده

• سرویس‌گیرنده نسبت به ارتقای منابع سرورها تعهدی ندارد مگر آنکه حداقل از یک ماه به وی اطلاع داده شده باشد.