تاریخچه تغییرات
تاریخچه تغییرات سند SLA در جدول زیر قابل مشاهده است. این سند در فواصل زمانی مشخص مورد بازبینی قرار می‌گیرد.
| نسخه | تاریخ | ویرایش‌کننده | تغییرات این نسخه |
|---|---|---|---|
تایید‌کنندگان
در جدول زیر نام تمامی ذی‌نفعان اصلی (Primary Stakeholders) قرارداد و نقش ایشان آمده است. سند حاضر به امضا و تایید این ذی‌نفعان رسیده است.
| نام | سمت | امضا | تاریخ |
|---|---|---|---|
تاریخ آخرین بازبینی:
تاریخ تعیین‌شده برای بازبینی بعدی:
مقدمه
این سند، یک توافق‌نامه سطح سرویس بین [سرویس‌دهنده] و [سرویس‌گیرنده] به منظور توافق دوطرفه بر روی سطح خدمات مورد نیاز جهت پشتیبانی، نگهداری و پایداری سرویس [نام سرویس] است.
توصیف سرویس
در این بخش، به صورت خلاصه سرویس مورد نظر توصیف می‌شود و به طور کلی به کارکردها، مخاطبان، اهداف و خروجی‌های سرویس اشاره می‌گردد.
طبقه‌بندی کارکردهای سیستم
در این بخش، کارکردهای سیستم برای کنشگران مختلف از جهت اهمیت در سرویس‌دهی طبقه‌بندی می‌شوند. این طبقه‌بندی مبنای تعیین سطح حساسیت سرویس و تعیین جرائم خواهد بود.
به عنوان مثال در یک سامانه «فروشگاه آنلاین» می‌توانیم کارکردهای سیستم را از جهت اهمیت در سرویس‌دهی به شکل زیر طبقه‌بندی کنیم.
| عنوان طبقه‌بندی کارکرد سیستم | توضیح |
|---|---|
| اولویت یک |
|
| اولویت دو |
|
| اولویت سه |
|
| اولویت چهار |
|
بازه‌های زمانی
در این بخش، روزها و ساعت‌های روز در چند بازه زمانی تعریف می‌شوند. روزهای خاصی از سال (مثل ایام نوروز) یا روزهای خاصی از هفته به دلیل حساسیت متفاوت در دسته جداگانه‌ای قرار می‌گیرند. به همین ترتیب، ساعت‌های مختلف ایام مختلف سال از جهت حساسیت قابل تفکیک هستند. در جدول زیر بازه‌های زمانی تعریف شده تا در بخش‌های دیگر مورد ارجاع قرار گیرند. در جدول زیر، تایم‌زون ایران و تقویم هجری شمسی ملاک است.
به عنوان مثال، در یک سامانه «فروشگاه آنلاین» می‌توانیم زمان‌های فعالیت سیستم را از جهت اهمیت در سرویس‌دهی به شکل زیر طبقه‌بندی کنیم.
| عنوان پنجره زمانی | توضیح |
|---|---|
| روز | از ساعت ۲۴ یک روز تا ساعت ۲۴ روز بعد |
| هفته | از ساعت ۰۰:۰۰ روز شنبه تا قبل از ساعت ۰۰:۰۰ شنبه بعد |
| ماه | از ساعت ۰۰:۰۰۰ روز اول ماه تا قبل از ساعت ۰۰:۰۰ روز اول ماه بعد |
| همه زمان‌ها | کل ساعات همه روزهای سال |
| ساعت‌های اداری | ساعت ۸ تا ۱۶ روزهای شنبه تا چهارشنبه |
| زمان اصلی فروش | ساعت ۸ تا ۲۳ همه روزهای سال |
| ساعت‌های پیک | ساعت ۱۶ تا ۲۲ همه روزهای سال ساعت ۸ تا ۲۴ نیمه اسفند ماه تا تحویل سال جدید |
| ساعت‌های کم‌باری | ساعت ۱ تا ۵ هر روز |
طبقه‌بندی Issueها
به دلیل وجود ایراد در عملکرد سیستم یا وجود حفره‌های امنیتی یا کندی و امثال آن‌ها، کارهایی به سرویس‌دهنده ارجاع داده می‌شود. کارهای ارجاعی از جهت اهمیت در چند دسته طبقه‌بندی می‌شوند.
| نام | توضیح |
|---|---|
| حیاتی | باید بلافاصله و خارج از برنامه انجام شوند. |
| فوری | باید با قید فوریت در برنامه قرار گیرند. |
| متوسط | انجام آن‌ها لازم است ولی فوریت ندارد. |
| کم‌اهمیت | امکان به تعویق انداختن آن‌ها و حتی انجام ندادن آن‌ها وجود دارد. |
طبقه‌بندی باگ‌ها
باگ به معنی اختلال در کارکرد سیستم است. در این بخش، باگ‌های سامانه از جهت میزان تاثیرگذاری بر کارکرد طبقه‌بندی می‌گردد.
در جدول زیر نمونه‌ای از این طبقه‌بندی قابل رویت است.
| عنوان طبقه‌بندی باگ | توضیح | طبقه‌بندی Issue مربوطه |
|---|---|---|
| متوقف‌کننده | یک یا چند کارکرد سیستم به طور کامل خراب شده و راه جایگزینی برای انجام آن‌ها وجود ندارد. چنانچه میانگین زمان پاسخگویی به یک سرویس بیش از ۶۰ ثانیه باشد، باگی در این سطح محسوب می‌شود. | باگ‌های این دسته اگر مربوط به «کارکردهای اولویت یک» باشند issue ای «حیاتی» و در غیر این صورت «مهم» محسوب می‌شوند. |
| آزار‌دهنده | استفاده از یک یا چند کارکرد سیستم را مختل می‌کند ولی راه‌های دیگری برای استفاده از آن کارکردها وجود دارد. مثلا امکان ایجاد کاربران جدید با فرم خراب شده ولی امکان ایمپورت اطلاعات کاربران از فایل اکسل کار می‌کند. چنانچه میانگین زمان پاسخگویی به یک سرویس بین ۳۰ تا ۶۰ ثانیه باشد، باگی در این سطح محسوب می‌شود. | باگ‌های این دسته اگر مربوط به «کارکردهای اولویت یک» باشند issue ای «مهم» و در غیر اینصورت «متوسط» محسوب می‌شوند. |
| ناراحت‌کننده | راحتی استفاده از سیستم را تحت تاثیر قرار می‌دهد. مثلا یک کلید کوتاه (short key) از کار افتاده است ولی با ماوس می‌توان روی دکمه کلیک کرد. یا موقع تایپ کردن بخشی از یک کلمه ادامه آن پیشنهاد داده نمی‌شود. چنانچه میانگین زمان پاسخگویی به یک سرویس بین ۵ تا ۳۰ ثانیه باشد، باگی در این سطح محسوب می‌شود. | باگ‌های این دسته اگر مربوط به «کارکردهای اولویت یک» باشند issue ای «متوسط» و در غیر این صورت «کم‌اهمیت» محسوب می‌شوند. |
طبقه‌بندی آسیب‌های امنیتی
به طرق مختلف ممکن است آسیب‌پذیری‌هایی از جهت امنیت در سیستم کشف شود. درجه اهمیت و ضریب اثر این آسیب‌پذیری‌ها متفاوت است. در جدول زیر، آسیب‌پذیری‌های امنیتی طبقه‌بندی شده‌اند. این طبقه‌بندی طبق استاندارد ... صورت گرفته است.
در جدول زیر نمونه‌ای از این طبقه‌بندی قابل رویت است.
| اهمیت آسیب‌پذیری | طبقه‌بندی Issue مربوطه |
|---|---|
| خیلی بالا | آسیب‌پذیری‌های این رده «حیاتی» محسوب می‌شوند. |
| بالا | آسیب‌پذیری‌های این رده «مهم» محسوب می‌شوند. |
| متوسط | آسیب‌پذیری‌های این رده «متوسط» محسوب می‌شوند. |
| پایین | آسیب‌پذیری‌های این رده «کم‌اهمیت» محسوب می‌شوند. |
طبقه‌بندی خرابی‌ها
سیستم باید دائما در دسترس کاربران و کنشگران مختلف باشد. در عین حال ممکن است خرابی‌هایی در اجزای سخت‌افزاری یا اجزای نرم‌افزاری موجب مختل شدن سرویس‌دهی به صورت کلی یا جزئی شوند. در جدول زیر این خرابی‌ها طبقه‌بندی شده‌اند.
در جدول زیر نمونه‌ای از این طبقه‌بندی قابل رویت است.
| عنوان اختلال دسترس‌پذیری | توضیح | طبقه‌بندی Issue مربوطه |
|---|---|---|
| توقف سرویس اصلی | سرویس‌دهی به طور کلی یا جزيی قطع می‌شود و کاربران امکان استفاده از آن را ندارند. | خرابی‌های این رده، اگر مربوط به «کارکردهای اولویت یک و دو» باشند، issue ای «حیاتی» و در غیر این صورت «مهم» محسوب می‌شوند. |
| خرابی افزونگی‌ها | سرویس‌دهی ادامه دارد ولی به دلیل خرابی افزونگی‌ها (مثلا یک نود از یک کلاستر سه نودی)، احتمال اختلال در سرویس‌دهی بالا رفته است. | خرابی‌های این رده، issue ای «مهم» محسوب می‌شوند. |
| خرابی سرویس‌های پشتیبان | خرابی در اجزای اصلی که در سرویس‌دهی به کاربران نقش مستقیم دارند اتفاق نیفتاده است بلکه در اجزایی مانند سرویس مانیتورینگ یا امکانات مدیریتی سرورها رخ داده است. | خرابی‌های این رده، issue ای «مهم» محسوب می‌شوند. |
واحد جریمه
در صورت نقض تعهد توسط سرویس‌دهنده جرایمی به وی تعلق می‌گیرد. این جریمه بسته به میزان نقض تعهد و تبعات آن متفاوت خواهد بود. جریمه در بخش‌های مختلف به صورت ضریبی از «واحد جریمه» بیان می‌گردد. یک «واحد جریمه» برابر هزینه پشتیبانی یک روز (کل هزینه پشتیبانی تقسیم بر تعداد روز دوره پشتیبانی) ضرب در یک است.
شاخص‌های سنجش سرویس
کیفیت سرویس بر اساس شاخص‌های (Service Level Indicator) زیر سنجیده می‌شود:
| شاخص | توضیح | هدف (SLO) | جریمه |
|---|---|---|---|
| صدک ۹۹ «زمان پاسخگویی» به کارکردهای با اولویت یک و دو (percentile 99 یا p99) | ۹۹ درصد از درخواست‌ها در زمانی کمتر از مقدار این شاخص پاسخ داده شده‌اند. | در یک روز بیش از یک ثانیه نباشد. | به ازای هر ثانیه بیشتر، یک واحد جریمه تعلق می‌گیرد. |
| «نرخ پاسخ صحیح» به کارکردهای اولویت یک و دو | نسبت درخواست‌هایی که کد وضعیت پاسخ به آن‌ها از سری ۵۰۰ یا تایم‌اوت نیست به کل درخواست‌ها | در یک روز کمتر از ۹۹.۵ درصد نباشد. | به ازای هر ۵ درصد انحراف از هدف در هر روز یک واحد جریمه تعلق می‌گیرد. |
| صدک ۹۹ «زمان پاسخگویی» به کارکردهای با اولویت سه و چهار (percentile 99 یا p99) | ۹۹ درصد از درخواست‌ها در زمانی کمتر از مقدار این شاخص پاسخ داده شده‌اند. | در یک روز بیش از دو ثانیه نباشد. | به ازای هر ۵ درصد انحراف از هدف در هر هفته یک واحد جریمه تعلق می‌گیرد. |
| «نرخ پاسخ صحیح» به کارکردهای اولویت سه و چهار | نسبت درخواست‌هایی که کد وضعیت پاسخ به آن‌ها از سری ۵۰۰ یا تایم‌اوت نیست به کل درخواست‌ها | در یک هفته کمتر از ۹۹ درصد نباشد. | به ازای هر ۵ درصد انحراف از هدف در هر هفته یک واحد جریمه تعلق می‌گیرد. |
| زمان انجام issueهای حیاتی | زمان انجام از ۲ روز کاری تجاوز نکند. | به ازای هر روز کاری تاخیر در انجام هر issue پنج واحد جریمه تعلق می‌گیرد. | |
| زمان انجام issueهای فوری | زمان انجام از ۵ روز کاری تجاوز نکند. | به ازای هر روز کاری تاخیر در انجام هر issue سه واحد جریمه تعلق می‌گیرد. | |
| زمان انجام issueهای متوسط | زمان انجام از موعد مورد توافق تجاوز نکند. زمان مورد توافق باید کمتر از ۲۰ روز کاری باشد مگر با رضایت کارفرما. | به ازای هر روز کاری تاخیر در انجام هر issue یک واحد جریمه تعلق می‌گیرد. | |
| زمان انجام issueهای کم‌اهمیت | زمان انجام از موعد مورد توافق تجاوز نکند. زمان مورد توافق باید کمتر از ۳۰ روز کاری باشد مگر با رضایت کارفرما. | به ازای هر روز کاری تاخیر در انجام هر issue یک واحد جریمه تعلق می‌گیرد. | |
| نرخ بالا بودن سیستم | درصد زمانی که همه مولفه‌های مرتبط با سرویس‌دهی مستقیم به کنشگران سلامت هستند و توان سرویس‌دهی دارند. سالم بودن افزونه‌ها ضرورت ندارد. | در یک ماه کمتر از ۹۹ درصد نباشد. | به ازای هر درصد انحراف از هدف، یک واحد جریمه تعلق می‌گیرد. |
پنجره‌های پشتیبانی
مسئولین سرویس می‌توانند با اطلاع‌رسانی قبلی و پس از دریافت تایید از نماینده سرویس‌گیرنده در چارچوب جدول زیر، برای انجام امور پشتیبانی، اختلالاتی را در سرویس‌دهی ایجاد نمایند. این زمان‌ها اصطلاحا پنجره پشتیبانی (Maintenance Window) نامیده می‌شوند.
جدول زیر نمونه‌ای از برنامه‌ریزی پنجره‌های پشتیبانی را نمایش می‌دهد.
| طبقه‌بندی کارکرد متاثر از عملیات پشتیبانی | بودجه | پنجره زمانی قابل برنامه‌ریزی |
|---|---|---|
| اولویت یک | حداکثر ۲ ساعت در روز حداکثر ۶ ساعت در ماه | ساعت‌های کم‌باری |
| اولویت دو | حداکثر ۴ ساعت در روز حداکثر ۱۰ ساعت در ماه | غیر از «ساعت‌های پیک» |
| اولویت ۳ و ۴ | حداکثر ۶۰ ساعت در ماه | همه زمان‌ها |
- پنجره‌های پشتیبانی باید قبل از شروع به تایید نماینده سرویس‌گیرنده رسیده باشند.
- در «پنجره‌های پشتیبانی» هیچ یک از شاخص‌های کیفیت سرویس (SLIها) غیر از «نرخ بالا بودن سیستم» اندازه‌گیری نمی‌شود.
- در صورتی که بودجه خطای (Error Budget) شاخص‌های مرتبط با عملیات (Operation) همچون «سرعت پاسخگویی» و «نرخ پاسخ صحیح» و «نرخ بالا بودن سیستم» تمام شده باشد، باید پنجره‌های پشتیبانی به بازه‌های زمانی بعدی موکول گردد، مگر آنکه انجام آن‌ها ضروری تشخیص داده شود.
- در صورتی که عملیات پشتیبانی کارکردهای متنوعی را متاثر کند، اولویت بالاتر ملاک برنامه‌ریزی خواهد بود.
نحوه اندازی‌گیری سطح سرویس
نحوه اندازی‌گیری زمان اختلالات سرویس و رعایت تعهد با روش‌های زیر سنجیده می‌شود.
در جدول زیر نمونه‌ای از نحوه اندازه‌گیری زمان اختلالات آورده شده است.
| نوع شاخص | ملاک اندازه‌گیری |
|---|---|
| زمان انجام issue | زمان ثبت در جیرای پروژه. زمان‌هایی که کار معطل سرویس‌دهنده نیست در نظر گرفته نمی‌شود. |
| زمان پاسخگویی | زمان پاسخگویی طبق لاگ WAF که در ELK پروژه نگهداری می‌شود. |
| نرخ پاسخ صحیح | مقدار http status ثبت‌شده در لاگ WAF ملاک است. آمار از لاگ‌های ذخیره‌شده در ELK پروژه استخراج می‌گردد. |
| زمان خرابی | زمان خرابی اجزای نرم‌افزاری از زمان ارسال اولین هشدار توسط Zabbix مرکز داده کارفرما به مسئول سرویس محاسبه می‌گردد. |
| بالا بودن سیستم یا اجزای آن | ملاک، وضعیت سلامت سرویس یا اجزای سیستم در Zabbix مرکز داده کارفرما است. |
محدوده مسئولیت‌ها
در این بخش، محدوده مسئولیت‌های ارائه‌کننده و دریافت‌کننده سرویس با ذکر محدودیت‌ها، پیش‌نیازها و استثناء‌ها تببین می‌گردد.
مسئولیت‌های سرویس‌دهنده
- سرویس‌دهنده موظف است تغییراتی که ممکن است اختلالی در سرویس‌دهی ایجاد کنند را بدون اطلاع و اجازه سرویس‌گیرنده اعمال نکند.
- سرویس‌دهنده موظف است نیازهای سخت‌افزاری خود را با توضیح مکفی و ذکر فوریت، حداقل یک ماه قبل از بحرانی شدن وضعیت به اطلاع سرویس‌گیرنده برساند.
- سرویس‌دهنده موظف است مقیاس قابل تحمل با سخت‌افزارهای موجود را به اطلاع سرویس‌گیرنده برساند.
- سرویس‌دهنده موظف است از همه داده‌های سرویس بکاپ تهیه نموده و در تجهیزات ذخیره‌سازی مربوط به بکاپ قرار دهد.
- سرویس‌دهنده موظف است پیش‌نیازهای پایداری هر یک از اجزای سیستم و همچنین تبعات خرابی آن را در قالب یک مستند شفاف نماید تا سرویس‌گیرنده در صورت صلاحدید اقدام به درخواست پایداری بیشتر و تامین منابع و پیش‌نیازهای آن نماید.
- مثال: سرویس پایگاه‌داده elasticsearch، شرط پایداری: حداقل دو سرور از سه نود کلاستر سالم باشد، تبعات خرابی: خریداران امکان جستجو روی محصولات را نخواهند داشت. ممکن است بخشی از داده از دست برود و در این صورت باید مجددا reindex شود.
- مثال: سرویس پایگاه‌داده elasticsearch، شرط پایداری: حداقل دو سرور از سه نود کلاستر سالم باشد، تبعات خرابی: خریداران امکان جستجو روی محصولات را نخواهند داشت. ممکن است بخشی از داده از دست برود و در این صورت باید مجددا reindex شود.
- سرویس‌دهنده موظف است چیدمان اجزای نرم‌افزاری را روی تجهیزات سخت‌افزاری به گونه‌ای مدیریت کند که خراب شدن هیچ سرور واحدی کارکردهای اصلی سیستم را متوقف نکند. در صورت توقف سرویس با خراب شدن یک سرور با وجود تامین منابع، مسئولیت به عهده سرویس‌دهنده است.
- در صورت نیاز، سرویس‌دهنده باید سرویس را حداکثر ظرف سه روز کاری از صفر به طور کامل روی یک مرکز داده جدید نصب نماید. بدیهی است چنانچه نصب مجدد ریشه در خرابی‌های ناشی از نقض تعهدات سرویس‌دهنده نداشته باشد، خدمات وی مشمول هزینه مجزا خواهد بود.
سلب مسئولیت از سرویس‌دهنده
- در صورتی که پیش‌نیازهای پایداری یک سرویس نقض گردد و سرویس‌دهنده قبلا پیش‌نیازها را به صورت شفاف اعلام کرده باشد، مسئولیت قطع سرویس به عهده وی نمی‌باشد.
- در صورتی که باری بیش از مقیاس اعلام‌شده توسط سرویس‌دهنده به سیستم تحمیل شود، مسئولیت کیفیت سرویس به عهده سرویس‌دهنده نمی‌باشد.
- سرویس‌دهنده نسبت به تجهیزات شبکه، سرورها و تجهیزات سخت‌افزاری، سیستم‌عامل و زیرساخت ابری مسئولیتی ندارد.
- سرویس‌دهنده نسبت به نگهداری بکاپ‌ها تعهدی ندارد و صرفا موظف است فایل‌های بکاپ را در فضای ذخیره‌سازی مشخص‌شده از سوی سرویس‌گیرنده قرار دهد.
- سرویس‌دهنده نسبت به قطع شدن سرویس‌های بالادستی که پیش‌نیاز کارکرد صحیح سیستم هستند (مثل سرویس‌های پیامک و ایمیل) مسئولیتی ندارد.
مسئولیت‌های سرویس‌گیرنده
- سرویس‌گیرنده موظف است تجهیزات و پیش‌نیازهای سرویس‌دهی را تامین نماید.
سلب مسئولیت از سرویس‌گیرنده
- سرویس‌گیرنده نسبت به ارتقای منابع سرورها تعهدی ندارد مگر آنکه حداقل از یک ماه به وی اطلاع داده شده باشد.