پیاده سازی قراردادهای سطح سرویس (SLA)
چهارشنبه
4 دی 1398
اگر مشغول خواندن این مقاله هستید، پس احتمالاً تصمیم گرفتهاید یا از شما درخواست شده که یک SLA را پیاده سازی کنید. ابتدا اين پرسشها به ذهن شما خطور میکند: "این جنجالها برای چیست؟"، "چگونه SLA به شرکت، کارمندان و تیم ما کمک میکند؟" و "جنبههای منفی SLA واقعاً چه هستند و چگونه میتوان از آنها پرهیز کرد؟"
بسیار خوب، باید بگویم شما خوش شانس هستید. چرا؟ چون این مقاله تمام اطلاعاتی را که لازم است راجع به SLA بدانید، در اختیارتان میگذارد. شما به محض به پایان رساندن مطالعه این مقاله، قادر خواهید بود با موفقیت مراحل طراحی، پیاده سازی، تهیه گزارش و بهبود SLA خود را به انجام رسانید، و از مزایای مرتبط با آن بهره مند شوید.
نخست نکات مهم - قرارداد سطح سرویس (SLA) چیست؟
تعریف "رسمی" برای SLA چنین است: قرارداد سطح سرویس (SLA) یک سند رسمی برای طرح ریزی تعهد سرویسی است که توسط تامین کننده سرويسهای IT به یک یا چند مشتری ارائه میشود. بر اساس مفاد ®ITIL، پذیرفته شدهترین رویکرد مدیریت سرويسهای IT در جهان، مدیریت سطح سرویس (SLM) بیانیهای تبلیغی برای "برنامه ریزی، هماهنگی، مذاکره، تهیه گزارش و مدیریت کیفیت سرويسهای IT با هزینههای قابل قبول" است. علاوه بر این، SLA باید شامل یک عنصر بهبود نیز باشند تا بتوانید از طریق یک برنامه بهبود خدمات مستمر (CSIP) سرويسهای IT را فعالانه مدیریت کنید.
SLA بر پايه قراردادهای قانونی که چارچوبی را برای سرويسهای IT تنظیم میکنند، بنا میشوند و انعطاف پذیری عملیاتی بیشتری را بین طرفین قرارداد فراهم میکنند. این امر اجازه میدهد تا SLA بر اساس شرایط شرکت شما و نحوه توسعه روابط در داخل سازمانتان به روز شده یا تغییر داده شوند. SLA كه معمولاً با زبانی مربوط به جنبههای روزانه ارائه سرويسها نوشته میشوند، باید برای کارمندانتان شفاف باشند، زیرا آنها بانكداران شما هستند.
فرآیند سنتی SLA چیزی شبیه به نمودار زیر است:
توجه: تیمهای IT میتوانند SLA متعددی بر اساس ضوابط سرويسهای مختلف و نیازها و توقعات گوناگون مشتریان داشته باشند، اما هدف به حداقل رساندن تعداد SLA و قطعاً جلوگیری از ارائه یک SLA برای هر تغيير اساسی در ضوابط سرويسها و مشتریان است.
تمرکز این مقاله اصولاً بر SLA است، اما دو مفهوم دیگر در همین خانواده وجود دارند که ممکن است بخواهید از آنها آگاه شوید:
قرارداد سطح عملیاتی (OLA) - توافقی بین تامین کننده سرويسهای IT و دپارتمان دیگری از همان سازمان که ارائه سرويسهای زیرساخت را کنترل میکند.
قرارداد پشتیبانی و تایید (UC) - یک قرارداد رسمی بین تامین کننده سرويسهای IT و تامین کننده خارجی سرويسهای IT یا زیرساخت.
چرا باید یک SLA را پیاده سازی کنم؟
اهداف يك SLA پیاده سازی چارچوبی است كه با تغییر اولویتهای شرکت و سطوح سرويس سازگار میشود، اهداف روشنی را برای شکل دادن به سرويسهای ارائه شده توسط تامین کننده تعریف میکند و از مغایرتهای اين سو و آن سوی سطح سرويس جلوگیری میکند. به هر حال بدون SLA، تنها راه حل قانونی ادعای "نقض قرارداد" است که اغلب مستلزم تلاشی سخت و طولانی است.
مزایای SLA شامل ارتباط باز و توانایی مدیریت توقعات مشتریان است. سازمانهای IT نیز از مزایایی همچون تصویر شفافتری از آنچه کاربران نیاز دارند، توانایی تراز و تطبيق منابع خود برای پاسخگویی به توقعات مشتريان، همچنین شرح دقيق و واضح هزینههای مربوط به هر سطح مفروض از سرویس بهرهمند میشوند.
اگر میخواهید تصویر شركت و دپارتمان خود را بهبود بخشید، IT میتواند از این فرصت برای تنظیم توقعات واقع بینانه کاربر که منجر به رضایت بیشتر کاربر و روحیه بالای تیم IT خواهد شد، استفاده کند.
در داخل شرکت نیز SLA آنچه را که برای مشتریان و تیم IT شما مهم است، دیکته میکنند و شاخصهای روشنی را برای تکنسینها در مورد نحوه گذراندن وقت خود و نحوه قضاوت عملکردشان ارائه میدهند. معیارهای عملکرد شفاف همراه با مشوقهای مناسب برای تیمهای IT انگیزه دستیابی به سطوح بالای سرويس را ایجاد میکند. به عبارت ساده - اهداف و انگیزههای روشن منجر به عملكرد بهتر میشود.
برای یک تامین کننده IT خارجی که سرویسهایی را به مشتریان متعدد ارائه میدهد، SLA مزایای دیگری نیز دارد آنها سرويسهای ارائه شده را نمايش میدهند و سپس به عنوان مدرک سرويسهای با کیفیت بالا عمل میکنند. تامین کنندگان سرويسهای IT همچنین میتوانند از تاریخچه SLA خود به عنوان ابزارهای بازاریابی برای مقایسه سرویسهای مشابه با رقبای خود به منظور جذب مشتریان جدید استفاده کنند. مشتریان جدید به معنای درآمد بیشتر و پاداشهای عملکرد بالقوه بالاتر است.
یک SLA جامع این پرسشهای کلیدی را مورد توجه قرار میدهد:
وعده تامین کننده چيست؟
چگونه تامین کننده وعدههای خود را ارائه خواهد داد؟
چه کسی و چگونه نحوه ارائه سرویس را ارزیابی میکند؟
اگر تامین کننده موفق به ارائه وعده خود نشود، چه اتفاقی میافتد؟
چگونه SLA در طول زمان تغییر خواهد کرد؟
هنگام طراحی SLA خود این نکات کلیدی را به یاد داشته باشید!
اگر مشخص نکنید که از چه کسی پشتیبانی میکنید، آنگاه پشتیبان همه خواهيد بود.
اگر مشخص نکنید که از چه چیز پشتیبانی میکنید، آنگاه پشتیبان همه چیز خواهيد بود.
اگر مشخص نکنید که چه زمانی پشتیبانی میکنید، آنگاه پشتیبان 24 ساعته خواهيد بود.
اگر مشخص نکنید که کجا پشتیبانی میکنید، آنگاه پشتیبان هر مکانی خواهيد بود.
ساعت SLA زمانی آغاز به كار میكند که سرویس متوقف میشود، نه زمانی که یک درخواست ثبت میشود یا مشتری آن را اولین بار گزارش میدهد!
چگونه یک SLA ایجاد کنم؟
یک SLA با نگارش خوب مسئولیتهای طرفین قرارداد را به وضوح بیان میکند - شما میخواهید نام همه در قراداد قيد شود و هركس مسئوليت خود را به عهده بگيرد. بلوکهای تشکیل دهنده ساختار SLA عبارتند از:
1. ارزیابی وضعیت فعلی و سطوح سرويس
وضعیت فعلی را بررسی کنید. تا كنون به چه چیز دست یافتید، و مهم تر از آن اینکه آيا جايگاه فعلی همان جایگاهی است كه شرکت فردا میخواهد باشد؟ طرح واقع بینانهای تهیه کنید که به وضوح شرح میدهد چه سطحی از سرويس باید بر مبنای بازخورد حیاتی از واحدهای شرکت، مشتریان و تامین کننده سرویس ارائه شود.
2. سطح سرويس را تعریف کنید
مطمئن شوید که اين تعريف تمام اطلاعات مربوطه از جمله هدف، دامنه (آنچه كه بايد اضافه و حذف شود)، فرآیندهای تجاری وابسته و تاثیر فقدان سرویس را شامل میشود.
3. شرايط توافق نامه را ثبت کنید
وظايف و مسئولیتهای مشتری و تامین کننده سرویس به همراه تعریف شرايط توافق نامه مانند مدت قرارداد، مکانها و زمانهای سرویس را طرح ریزی کنید. برای مثال:
وظایف تامین کننده سرویس
وظایف مشتری
مسئولیتهای کاربران سرویس (برای مثال در رابطه با امنیت IT)
جنبههای امنیتی IT که باید رعايت شود (در صورت عملی بودن، ارجاع به سیاستهای امنیتی IT مربوطه)
فراموش نکنید که موارد استثنا برای زمانهای سرویس نظیر تعطیلات آخر هفته و تعطیلات عمومی و مدت از کار افتادگی به خاطر تعمیر و نگهداری عادی را نیز تعریف کنید.
4. سطوح عملكرد راشناسایی کنید
سطوح حداقل و مورد انتظار عملكرد سرویس و همچنین شرایطی که تحت آن سرویس غیر قابل دسترس یا محدود در نظر گرفته میشود را كران يابی کنید.
برای مثال، سطوح مورد انتظار و حداقل سرویس میتواند طبق برنامه 95% و 85% باشد. نکته کلیدی این است که "سطح مورد انتظار" سطحی است که مشتری واقعاً برای آن هزینه میکند و "سطح حداقل" سطحی است که آن را ضعیف میداند و آن را مرز سرویس غیرقابل قبول میخواند.
مساله دسترس پذیری میتواند با ارقام «9» بررسی شود:
9/99% معادل 8 ساعت
99/99% معادل 53 ساعت
999/99% معادل 5 دقیقه
5. شيوههای اسکالاسیون را طرح ریزی کنید
برای زمانی که سطوح سرويس استانداردهای مورد انتظار و مورد توافق را برآورده نمیکنند گامهایی که باید برداشته شوند را تعریف کنید. این کار ممکن است مستلزم تعیین خطای اقدامات ناموفق، تهیه گزارش و حل مشکل در مدت زمان مشخص باشد. همچنین، هنگامی که مشکل در مدت زمان مشخص حل و فصل نمیشود، مدیر ارشد از هر دو طرف یعنی مشتری و تامین کننده سرویس باید مداخله کنند.
6. معیارها راتعریف کنید
معیارهای سرویس را تعریف کنید و مطمئن شوید که آنها را در طول زمان پیگیری میکنید. این معیارها باید شامل اقلامی همچون شرایطی که سرویس غیر قابل دسترس/ محدود در نظر گرفته میشود، اهداف دسترس پذیری، اهداف قابلیت اطمینان، زمان بازگرداندن سرویس و زمان از کار افتادگی به جهت تعمیر و نگهداری باشد.
معیارهای مورد استفاده رایج عبارتند از:
MTBF : زمان متوسط بین خرابیها
MTBSI : زمان متوسط بین رویدادهای سرویس
MTRS : زمان متوسط برای بازگرداندن سرویس
TAT : زمان برگشت (زمان فعالیت)
Uptime
7. دستمزدها و شرایط را تعيين كنيد
برای تامین کنندگان سرويسهای IT خارجی، هر گونه دستمزدهای اضافی که ممکن است اعمال شوند و شرایط دقیقی که تحت آن این دستمزدها اعمال میشوند، را با جزئيات بنويسيد. هر چه شرایط واضحتر بیان شوند، احتمال اختلاف نظر کمتر خواهد شد. نتیجه این کار رضایت بیشتر مشتری و پرداخت سریعتر خواهد بود.
8. هزینه ها و جریمه ها را شرح دهيد
هزینههای تامين سرویس و قوانین جریمهها را با جزئيات بنويسيد. برای مثال:
اعتبارات مالی/ تحلیل علت ریشهای/ طرح اقدام اصلاحی
به طور معمول جریمهها درصدی از دستمزدهای ماهانه است که مقدار آن با شدت ناكامیها افزایش مییابد
سقف جریمهها اغلب با 50 تا 100٪ از دستمزدهای ماهانه تعيين میشود
جریمهها ممکن است در تمام SLA تصاعدی باشند
فسخ قرارداد ممکن است یک گزینه معین برای مسائل تكرار شده یا بسیار شدید باشد - به عنوان مثال X ماه متوالی یا Y ماه در Z ماه متوالی
فسخ قرارداد همچنین ممکن است به علت ناتوانی بیش از حد يك شخص باشد
استثناهای SLA
شما باید لیستی از استثناها تهیه کرده و به تفصیل شرح دهید که در چه زمانی معاف از سنجش کلی SLA است. استثناهای رایج تعمیر و نگهداری برنامه ریزی شده و اضطراری است که ممکن است هر چیزی از ارتقاء تجهیزات گرفته تا عمليات راه اندازی و تهیه نسخه پشتیبان را شامل شود. برخی استثناها ممکن است قيود SLA را به دلیل عدم موفقیت شخص ثالث مستثنی کند که تامین کننده سرویس مستقیماً آنها را کنترل نمیکند. همچنین استثنا ممکن است عليه فروشندگان نرم افزار برای خطاهای برنامه استفاده شود، که بايد خودشان آنها را رفع کنند.
"تعمیر و نگهداری اضطراری" - باید پوشش داده شود
"وضع اضطراری" - اگر تعریف نشده باید میان فروشندگان و تولید کنندگان یکپارچه باشد
"تلاشهای منطقی" - وقتی که تلاشهای فروشنده کافی نیست، بار مسئولیت را بر دوش مشتری میگذارد.
"تعمیر و نگهداری برنامه ریزی شده" - باید به وضوح تعریف شود.
چه زمانی سیستم از كار می افتد؟
تعریف کلیدی: هر مشکلی که به طور موثر سرويسهای غیر قابل استفاده به مشتری ارائه دهد. مثالهایی در این رابطه عبارتند از:
"آشکار": سرور پاسخ نمیدهد.
عملکردهای مهم کار نمیکنند (برای مثال، خطاهای مهم)
تعداد قابل توجهی از کاربران نمیتوانند وارد سیستم شوند.
تاخیر بیش از حد - برای مثال، سرعت برای استفاده موثر خیلی پایین است.
لیست کنترلی SLA
آیا قرارداد موارد زیر را پوشش میدهد؟
اهداف سرویس
افراد نامبرده در قرارداد
افراد مسئول قرارداد
دوره پوشش
تعریف شرايط
روالهای به روز رسانی/ تغییر/ اصلاح قرارداد
آیا قرارداد عوامل سرویس زیر را شامل میشود؟
تعریف سرویس (سرویسها)
ساعات و تاریخهای سرویس
استثناهای سرویس
آیا قرارداد با جزئیات عوامل مشتری/ تامین کننده سرویس را شرح میدهد؟
روالهایی برای افزودن یا تغییر سرویسها
ترتیبات برای وقفه سرویس
روالهای اسکالاسیون
مسئولیتهای مشتری/ تامین کننده سرویس
آیا قرارداد کانالهای ارتباطی را پوشش میدهد؟
نقاط تماس برای مشتریان و تامین کننده سرویس كه در قرارداد گنجانده شده
کانالها و روشهای ارتباطی
آیا قرارداد معين میکند که چه نظارت بر عملکردی و چگونه روی خواهد داد؟
اهداف سرویس با هر دو سطح مورد انتظار و حداقل
چگونگی نظارت بر عملکرد و تهیه گزارش
تعداد دفعات تهیه گزارش
بازرسی گزارشها و نحوه نظارت
اقدامات تضمین کیفیت
مدیریت شکایات
آیا قرارداد هزینه های سرویس و جریمه عملکردهای زیر استاندارد و بی كيفيت را با جزئيات شرح میدهد؟
هزینه سرویس و جریمههای مالی
نتیجه گيري
يك SLA با نگارش خوب به سازمان شما کمک میکند تا وعده ارائه موارد ممكن را بدهيد و آنچه را که وعده دادهايد ارائه كنيد. با استفاده از این راهنمای عملی اکنون آمادهاید تا اولین قرارداد سطح سرویس (SLA) خود را ایجاد کنید و اگرچه نگارش آن میتواند یک کار دلهره آور باشد، فراموش نكنيد که معرفی SLA تعهدی برای ارائه غیر ممکنها نيست.
SLA میتواند به همان اندازه هدف عملکرد غیررسمی باشد یا به دشواری زمان تعهد شده برای برگرداندن سیستمها از طريق اعمال جریمهها باشد. در هر صورت SLA به عنوان مبنایی برای ایجاد یک درک مشترک از رابطه سرویس به کار میرود. اگر SLAها به درستی تهیه شوند، یک موقعیت برد- برد را هم برای تامین کننده سرویس و هم مشتری فراهم میکنند.
منبع خبر:
danapardaz.net