SLA، SLO و SLI چیست و چه تفاوتی دارند؟

وقتی یک سازمان سرویس دیجیتال ارائه می‌دهد، عباراتی مانند «سرویس باید همیشه در دسترس باشد»، «سرعت سامانه باید مناسب باشد» یا «قطعی نباید زیاد شود» به‌تنهایی قابل اندازه‌گیری نیستند. تیم فناوری اطلاعات برای مدیریت واقعی کیفیت سرویس به معیارهایی نیاز دارد که بتوان آن‌ها را اندازه‌گیری، هدف‌گذاری و در نهایت به تعهد تبدیل کرد.سه مفهوم SLI، SLO و SLA دقیقاً برای همین منظور استفاده می‌شوند. به زبان بسیار ساده، SLI به ما می‌گوید وضعیت فعلی سرویس چگونه است، SLO مشخص می‌کند وضعیت مطلوب سرویس چه باید باشد و SLA تعیین می‌کند چه سطحی از خدمات به مشتری یا دریافت‌کننده سرویس تعهد داده شده است.شناخت تفاوت این سه مفهوم برای مدیران فناوری اطلاعات، تیم‌های عملیات، دواپس و مدیران کسب‌وکار اهمیت زیادی دارد؛ زیرا بدون شاخص‌های قابل اندازه‌گیری، حتی بهترین زیرساخت نیز به‌سختی قابل مدیریت خواهد بود.

SLI چیست؟

SLI مخفف Service Level Indicator و به معنای «شاخص سطح سرویس» است.SLI یک اندازه‌گیری واقعی از عملکرد سرویس است. به عبارت دیگر، وضعیت فعلی سرویس را با عدد نشان می‌دهد.فرض کنید یک فروشگاه اینترنتی در ماه گذشته ۹۹٫۹۵ درصد مواقع در دسترس بوده است. عدد ۹۹٫۹۵ درصد می‌تواند یک SLI برای Availability آن سرویس باشد.

SLI فقط به دسترس‌پذیری محدود نمی‌شود. بسته به نوع سیستم، شاخص‌های متفاوتی را می‌توان اندازه‌گیری کرد؛ از جمله:

• درصد درخواست‌های موفق
• زمان پاسخ سرویس
• نرخ خطا
• میزان تأخیر
• توان عملیاتی
• درصد موفقیت تراکنش‌ها
• مدت زمان در دسترس بودن سرویس

نکته مهم این است که SLI باید چیزی باشد که واقعاً قابل اندازه‌گیری باشد.

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

SLO چیست؟

SLO مخفف Service Level Objective و به معنای «هدف سطح سرویس» است.

اگر SLI نشان دهد وضعیت واقعی چگونه است، SLO مشخص می‌کند می‌خواهیم وضعیت سرویس چگونه باشد.

برای مثال:

SLI: دسترس‌پذیری واقعی سامانه در ماه گذشته ۹۹٫۹۳ درصد بوده است.

SLO: هدف سازمان این است که دسترس‌پذیری سامانه حداقل ۹۹٫۹ درصد باشد.

در این مثال مشخص می‌شود عملکرد واقعی سیستم از هدف تعیین‌شده بهتر بوده است.

SLO باید واقع‌بینانه باشد. تعیین هدف ۱۰۰ درصد برای تمام سرویس‌ها ممکن است از نظر فنی یا اقتصادی منطقی نباشد. هرچه سطح دسترس‌پذیری مورد انتظار افزایش پیدا کند، معمولاً هزینه طراحی، افزونگی، نگهداری و عملیات نیز افزایش خواهد یافت.

SLA چیست؟

SLA مخفف Service Level Agreement و به معنای «توافق‌نامه سطح خدمات» است.SLA برخلاف SLI و SLO بیشتر جنبه توافق میان ارائه‌دهنده و دریافت‌کننده سرویس دارد.در SLA مشخص می‌شود ارائه‌دهنده چه سطحی از کیفیت را متعهد می‌شود و در صورت رعایت نشدن آن چه اتفاقی خواهد افتاد.

برای مثال ممکن است یک شرکت ارائه‌دهنده سرویس در قرارداد خود متعهد شود که:

دسترس‌پذیری ماهانه سرویس حداقل ۹۹٫۹ درصد باشد.

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

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

تفاوت SLA، SLO و SLI چیست؟

برای درک سریع تفاوت این سه مفهوم، جدول زیر کاربردی است:

مفهوم	سؤال اصلی	کاربرد
SLI	الان عملکرد سرویس چگونه است؟	اندازه‌گیری عملکرد واقعی
SLO	عملکرد سرویس باید چقدر خوب باشد؟	تعیین هدف داخلی
SLA	چه سطحی از سرویس را تعهد داده‌ایم؟	توافق با مشتری یا دریافت‌کننده سرویس

می‌توان ارتباط آن‌ها را خیلی ساده این‌گونه بیان کرد:

SLI = اندازه‌گیری

SLO = هدف

SLA = تعهد

همین سه عبارت بخش زیادی از تفاوت این مفاهیم را توضیح می‌دهند.

یک مثال واقعی برای درک بهتر SLA، SLO و SLI

فرض کنید یک بانک سامانه بانکداری اینترنتی دارد.

تیم فناوری اطلاعات با استفاده از ابزارهای پایش متوجه می‌شود سامانه در یک ماه ۹۹٫۹۷ درصد در دسترس بوده است.

این عدد SLI است.

تیم فنی قبلاً هدف داخلی خود را دسترس‌پذیری ۹۹٫۹۵ درصد تعیین کرده است.

این عدد SLO محسوب می‌شود.

اما بانک در توافق خدمات خود سطح دسترس‌پذیری ۹۹٫۹ درصد را تعهد کرده است.

این عدد بخشی از SLA است.

بنابراین:

شاخص	مقدار مثال	معنی
SLI	۹۹٫۹۷٪	عملکرد واقعی
SLO	۹۹٫۹۵٪	هدف تیم
SLA	۹۹٫۹۰٪	سطح تعهدشده

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

چرا SLO بهتر است از SLA سخت‌گیرانه‌تر باشد؟

یکی از نکات کاربردی در طراحی مدیریت سرویس همین موضوع است.

فرض کنید SLA برابر با ۹۹٫۹ درصد باشد و تیم فناوری اطلاعات نیز دقیقاً SLO را ۹۹٫۹ درصد تعیین کند.

در این حالت کوچک‌ترین عبور از هدف داخلی می‌تواند مستقیماً به نقض تعهد خارجی تبدیل شود.

اما اگر SLA برابر ۹۹٫۹ درصد و SLO داخلی مثلاً ۹۹٫۹۵ درصد باشد، تیم عملیات قبل از رسیدن وضعیت سرویس به محدوده خطر متوجه افت عملکرد خواهد شد.

بنابراین می‌توان SLO را مانند یک خط هشدار قبل از خط قرمز SLA در نظر گرفت.

Error Budget چیست و چه ارتباطی با SLO دارد؟

یکی از مفاهیم ارزشمند مرتبط با SLO، «بودجه خطا» است.

فرض کنید SLO یک سرویس ۹۹٫۹ درصد Availability تعیین شده است. این یعنی مقدار محدودی از عدم دسترس‌پذیری در بازه اندازه‌گیری پذیرفته شده است.

این ظرفیت باقی‌مانده همان چیزی است که در رویکردهای مهندسی قابلیت اطمینان به‌عنوان Error Budget شناخته می‌شود.

بودجه خطا به تیم کمک می‌کند بین دو نیاز تعادل برقرار کند:

پایداری سرویس و سرعت تغییر و توسعه.

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

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

چگونه SLI مناسب انتخاب کنیم؟

یکی از اشتباهات سازمان‌ها این است که هر چیزی را که ابزار مانیتورینگ اندازه‌گیری می‌کند به‌عنوان SLI در نظر می‌گیرند.

اما یک SLI خوب باید با تجربه واقعی کاربر ارتباط داشته باشد.

برای مثال CPU Usage یک سرور اطلاعات فنی مهمی است، اما الزاماً SLI مناسبی برای سرویس فروش آنلاین نیست.

ممکن است CPU سرور ۹۰ درصد باشد ولی کاربران هیچ مشکلی احساس نکنند.

برای سرویس فروش آنلاین، معیارهایی مانند موارد زیر ارزش بیشتری دارند:

• درصد درخواست‌های موفق کاربران
• زمان پاسخ صفحات مهم
• موفقیت فرایند پرداخت
• دسترس‌پذیری API
• زمان تکمیل تراکنش

بنابراین هنگام تعریف SLI بهتر است سؤال کنیم:

«کاربر از کجا متوجه می‌شود سرویس ما درست کار می‌کند؟»

پاسخ این سؤال معمولاً ما را به شاخص مناسب نزدیک‌تر می‌کند.

اشتباهات رایج در تعریف SLA و SLO

تعیین هدف ۱۰۰ درصدی بدون تحلیل هزینه

رسیدن از ۹۹٫۹ درصد به ۹۹٫۹۹ درصد فقط اضافه کردن یک رقم نیست. این تغییر ممکن است نیازمند معماری افزونه، مراکز داده متعدد، مکانیزم‌های Failover و سرمایه‌گذاری بیشتر باشد.

انتخاب شاخص‌هایی که کاربر احساس نمی‌کند

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

تعریف SLO بدون داده تاریخی

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

تعریف SLA بدون توان عملیاتی کافی

تیم فروش یا مدیریت نباید سطحی از سرویس را تعهد کند که زیرساخت فناوری اطلاعات توان ارائه پایدار آن را ندارد.

یکسان گرفتن همه سرویس‌ها

سامانه پرداخت، سیستم حضور و غیاب و یک سامانه آرشیوی الزاماً نباید SLO یکسان داشته باشند. اهمیت کسب‌وکاری هر سرویس باید در تعیین هدف دخالت داده شود.

چگونه برای یک سرویس SLI، SLO و SLA تعریف کنیم؟

بهترین نقطه شروع، خود فناوری نیست؛ ابتدا باید اهمیت سرویس برای کسب‌وکار مشخص شود.

برای مثال:

مرحله اول: سرویس حیاتی را مشخص کنید.

سامانه پرداخت، وب‌سایت، API، پایگاه داده یا سرویس داخلی؟

مرحله دوم: تجربه مهم کاربر را پیدا کنید.

کاربر از سرویس چه انتظاری دارد؟ سرعت؟ دسترس‌پذیری؟ تکمیل موفق تراکنش؟

مرحله سوم: SLI تعریف کنید.

معیاری انتخاب کنید که بتواند این تجربه را به عدد تبدیل کند.

مرحله چهارم: داده واقعی جمع‌آوری کنید.

عملکرد فعلی را برای یک بازه مناسب اندازه‌گیری کنید.

مرحله پنجم: SLO تعیین کنید.

هدف باید هم برای کسب‌وکار مناسب و هم از نظر فنی دست‌یافتنی باشد.

مرحله ششم: SLA را با توجه به توان واقعی تعیین کنید.

تعهد خارجی نباید صرفاً براساس خواسته تجاری و بدون بررسی توان فنی ایجاد شود.

در سازمان‌های بزرگ، کیفیت این فرایند مستقیماً به معماری و بلوغ زیرساخت فناوری اطلاعات وابسته است؛ زیرا بدون پایش، افزونگی و مدیریت صحیح منابع، تضمین سطح مشخصی از سرویس دشوار خواهد بود.

SLA فقط Availability نیست

یکی دیگر از برداشت‌های اشتباه این است که SLA را معادل Uptime بدانیم.

Availability یکی از متداول‌ترین شاخص‌هاست، اما توافق سطح خدمات می‌تواند ابعاد دیگری نیز داشته باشد؛ مانند:

• زمان پاسخ پشتیبانی
• زمان بازیابی سرویس
• زمان پاسخ برنامه
• نرخ موفقیت تراکنش
• کیفیت سرویس
• ساعات پشتیبانی
• نحوه Escalation
• دوره گزارش‌دهی

بنابراین SLA خوب باید براساس ماهیت سرویس طراحی شود، نه اینکه یک الگوی ثابت برای تمام خدمات سازمان باشد.

جمع‌بندی

SLI، SLO و SLA سه مفهوم جدا اما به‌شدت مرتبط در مدیریت قابلیت اطمینان و کیفیت سرویس هستند.

SLI وضعیت واقعی سرویس را اندازه‌گیری می‌کند.

SLO هدفی را مشخص می‌کند که تیم فنی باید برای رسیدن به آن تلاش کند.

SLA سطح خدماتی را مشخص می‌کند که ارائه‌دهنده در برابر دریافت‌کننده سرویس متعهد شده است.

اما ارزش واقعی این مفاهیم زمانی مشخص می‌شود که از حالت اعداد تزئینی در گزارش‌های مدیریتی خارج شوند.یک سازمان بالغ ابتدا مشخص می‌کند کدام تجربه کاربران اهمیت دارد، سپس برای آن SLI قابل اندازه‌گیری تعریف می‌کند، براساس داده‌های واقعی SLO مناسبی تعیین می‌کند و در نهایت SLA را به شکلی تنظیم می‌کند که هم نیاز کسب‌وکار را پاسخ دهد و هم از نظر عملیاتی قابل تحقق باشد.

به همین دلیل می‌توان رابطه این سه مفهوم را در یک جمله خلاصه کرد:

آنچه اتفاق افتاده را با SLI می‌سنجیم، آنچه می‌خواهیم اتفاق بیفتد را با SLO مشخص می‌کنیم و آنچه متعهد شده‌ایم اتفاق بیفتد را در SLA تعریف می‌کنیم.

سوالات متداول

تفاوت اصلی SLA و SLO چیست؟

SLO هدف داخلی عملکرد سرویس است، در حالی که SLA یک توافق درباره سطح خدمات میان ارائه‌دهنده و دریافت‌کننده سرویس محسوب می‌شود و می‌تواند پیامدهای مشخصی برای عدم تحقق تعهد داشته باشد.

تفاوت SLI و SLO چیست؟

SLI مقدار واقعی اندازه‌گیری‌شده را نشان می‌دهد، اما SLO مقدار هدف را مشخص می‌کند. برای مثال Availability واقعی ۹۹٫۹۶ درصد یک SLI و هدف ۹۹٫۹۵ درصد یک SLO است.

آیا SLO باید از SLA بالاتر باشد؟

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

Error Budget چیست؟

Error Budget میزان عدم تحقق SLO است که در یک بازه زمانی قابل پذیرش در نظر گرفته می‌شود و به تیم کمک می‌کند میان سرعت توسعه و قابلیت اطمینان سرویس تعادل ایجاد کند.

آیا SLA فقط برای سرویس‌های ابری استفاده می‌شود؟

خیر. SLA را می‌توان برای دیتاسنتر، شبکه، نرم‌افزار سازمانی، خدمات پشتیبانی، سرویس ابری و بسیاری از خدمات فناوری اطلاعات تعریف کرد.