در قالب سند متن‌های آبی باید حذف و جایگزین شوند. 

مشخصات سند

• عنوان  سند: (عنوان سرویس/سیستم مورد توافق)
• نسخه سند: ( مثلاً 1.0) – تاریخ آخرین بازبینی: ( تاریخ)
• ارائه‌دهنده خدمت: ( نام شرکت/واحد ارائه‌دهنده) – نماینده/نقطه تماس: ( نام و سمت، اطلاعات تماس)
• خدمت گیرنده: (نام سازمان مشتری) – نماینده/نقطه تماس: ( نام و سمت، اطلاعات تماس)
• تاریخ شروع اعتبار: ( تاریخ موثر اجرای SLA) – تاریخ پایان: ( تاریخ پایان در صورت قرارداد مدت‌دار) - دوره‌های بازنگری: ( مثلاً هر 6 ماه)
• مشخصات قرارداد: (شماره و تاریخ قرارداد)

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

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

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

مقدمه

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

واژه‌نامه

اصطلاحات فنی یا اختصارات مورد استفاده در سراسر سند  در جدول واژه‌نامه تعریف می‌شود.

توصیف سرویس

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

تعاریف پایه

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

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

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

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

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

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

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

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

طبقه‌بندی باگ‌های نرم‌افزاری

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

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

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

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

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

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

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

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

واحد جریمه

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

سطح سرویس مطلوب

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

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

نحوه اندازی‌گیری شاخص‌ها

شاخصها‌ی سنجش کیفیت سرویس (SLI) با ابزارها و روشهای مندرج در جدول زیر اندازه‌گیری می‌شوند. 

در جدول زیر نمونه‌ای از نحوه اندازه‌گیری SLIها آورده شده است. قاعدتاً ابزارهای اندازه‌گیری باید خارج از کنترل ارائه دهنده سرویس باشند. مثلاً مشتری از لاگ WAF خود برای اندازه‌گیری زمان پاسخگویی استفاده کند یا زمان کارهای ارجاع شده را در جیرای خود ببیند. 

پشتیبانی برنامه‌ریزی شده

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

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

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

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

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

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

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

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

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

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

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

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

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