...
در جدول زیر نام تمامی ذی‌نفعان اصلی (Primary Stakeholders) قراراداد و قرارداد و نقش ایشان آمده است. سند حاضر به امضا و تایید این ذی‌نفعان رسیده است.
...
این سند، یک توافق‌نامه سطح سرویس بین [سرویس‌دهنده] و [سرویس‌گیرنده] به منظور توافق دوطرفه بر روی سطح خدمات مورد نیاز جهت پشتیبانی، نگهداری و پایداری سرویس [نام سرویس] است.
توصیف سرویس
در این بخش بخش، به صورت خلاصه سرویس مورد نظر توصیف می‌شود و به طور کلی به کارکردها، مخاطبان، اهداف و خروجی‌های سرویس اشاره می‌گردد.
طبقه‌بندی کارکردهای سیستم
در این بخش بخش، کارکردهای سیستم برای کنشگران مختلف از جهت اهمیت در سرویس‌دهی طبقه‌بندی می‌شوند. این طبقه‌بندی مبنای تعیین سطح حساسیت سرویس و تعیین جرائم خواهد بود.
...
| عنوان طبقه‌بندی کارکرد سیستم | توضیح |
|---|---|
| اولویت یک |
|
| اولویت دو |
|
| اولویت سه |
|
| اولویت چهار |
|
بازه‌های زمانی
در این بخش بخش، روزها و ساعت‌های روز در چند بازه زمانی تعریف می‌شوند. روزهای خاصی از سال (مثل ایام نوروز) یا روزهای خاصی از هفته به دلیل حساسیت متفاوت در دسته جداگانه‌ای قرار می‌گیرند. به همین ترتیب ترتیب، ساعت‌های مختلف ایام مختلف سال از جهت حساسیت قابل تفکیک هستند. در این بخش جدول زیر بازه‌های زمانی تعریف شده تا در بخشهای بخشهای دیگر مورد ارجاع قرار گیردگیرند. در جدول زیر زیر، تایم‌زون ایران و تقویم هجری شمسی ملاک می‌باشداست.
به عنوان مثال مثال، در یک سامانه «فروشگاه آنلاین» می‌توانیم زمان‌های فعالیت سیستم را از جهت اهمیت در سرویس‌دهی به شکل زیر طبقه‌بندی کنیم.
| عنوان پنجره زمانی | توضیح |
|---|---|
| روز | از ساعت ۲۴ یک روز تا ساعت ۲۴ روز بعد |
| هفته | از ساعت ۰۰:۰۰ روز شنبه تا قبل از ساعت ۰۰:۰۰ شنبه بعد طبق |
| ماه | از ساعت ۰۰:۰۰۰ روز اول ماه تا قبل از ساعت ۰۰:۰۰ روز اول ماه بعد |
| همه زمانها | کل ساعات همه روزهای سال |
| ساعت‌های اداری | ساعت ۸ تا ۱۶ روزهای شنبه تا چهارشنبه |
| زمان اصلی فروش | ساعت ۸ تا ۲۳ همه روزهای سال |
| ساعت‌های پیک | ساعت ۱۶ تا ۲۲ همه روزهای سال ساعت ۸ تا ۲۴ نیمه اسفند ماه تا تحویل سال جدید |
| ساعت‌های کم‌باری | ساعت ۱ تا ۵ هر روز |
...
به دلیل وجود ایراد در عملکرد سیستم یا وجود حفره‌های امنیتی یا کندی و امثال آنها آنها، کارهایی به سرویس‌دهنده ارجاع داده می‌شود. کارهایی کارهای ارجاعی از جهت اهمیت در چند دسته طبقه‌بندی می‌شوند.
| نام | توضیح |
|---|---|
| حیاتی | باید بلافاصله و خارج از برنامه انجام شوند. |
| فوری | باید با قید فوریت در برنامه قرار گیرند. |
| متوسط | انجام آنها آنها لازم است ولی فوریت ندارد. |
| کم‌اهمیت | امکان به تعویق انداختن آنها آنها و حتی انجام ندادن آنها آنها وجود دارد. |
طبقه‌بندی باگ‌ها
...
در جدول زیر نمونه‌ای از این طبقه‌بندی قابل رویت است.
| عنوان طبقه‌بندی باگ | توضیح | طبقه‌بندی Issue |
|---|
| مربوطه | |
|---|---|
| متوقف‌کننده | یک یا چند کارکرد سیستم به طور کامل خراب شده و راه جایگزینی برای انجام آنها وجود ندارد |
راحتی استفاده از سیستم را تحت تاثیر قرار می‌دهد.
مثلا یک کلید کوتاه (short key) از کار افتاده است ولی با ماوس می‌توان روی دکمه کلیک کرد. یا موقع تایپ کردن بخشی از یک کلمه ادامه آن پیشنهاد داده نمی‌شود. چنانچه میانگین زمان پاسخگویی به یک سرویس |
بیش از ۶۰ ثانیه باشد، باگی در این سطح محسوب می‌شود. | باگ‌های این دسته اگر مربوط به «کارکردهای اولویت یک» باشند 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 مرکز داده کارفرما می‌باشداست. |
محدوده مسئولیت‌ها
در این بخش، محدوده مسئولیت‌های ارائه‌کننده و دریافت‌کننده سرویس با ذکر محدودیت‌ها، پیش‌نیازها و استثناء‌ها تببین می‌گردد.
...
سلب مسئولیت از سرویس‌دهنده
- در صورتی که پیش‌نیازهای پایداری یک سرویس نقض گردد و سرویس‌دهنده قبلا پیش‌نیازها را به صورت شفاف اعلام کرده باشد، مسئولیت قطع سرویس به عهده وی نمی‌باشد.
- در صورتی که باری بیش از مقیاس اعلام شده اعلام‌شده توسط سرویس‌دهنده به سیستم تحمیل شود، مسئولیت کیفیت سرویس به عهده سرویس‌دهنده نمی‌باشد.
- سرویس‌دهنده نسبت به تجهیزات شبکه، سرورها و تجهیزات سخت‌افزاری، سیستم‌عامل، سیستم‌عامل و زیرساخت ابری مسئولیتی ندارد.
- سرویس‌دهنده نسبت به نگهداری بکاپ‌ها تعهدی ندارد و صرفا موظف است فایل‌های بکاپ را در فضای ذخیره‌سازی مشخص‌شده از سوی کارفرما سرویس‌گیرنده قرار دهد.
- سرویس‌گیرنده سرویس‌دهنده نسبت به قطع شدن سرویس‌های بالادستی که پیش‌نیاز کارکرد صحیح سیستم هستند (مثل سرویس‌های پیامک و ایمیل) مسئولیتی ندارد.
...