SLA، SLO و SLI چیستند و چه کاربردی در پروژه‌های نرم‌افزاری دارند؟

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

نکته‌ای که معمولاً از قلم می‌افتد این است که این سه اصطلاح جایگزین هم نیستند؛ هرکدام یک لایه متفاوت از یک تعهد را توصیف می‌کنند. یکی می‌گوید «چه چیزی را و چگونه اندازه می‌گیریم»، دیگری می‌گوید «هدف ما چقدر است» و سومی می‌گوید «اگر به هدف نرسیم چه اتفاقی می‌افتد». در ادامه این سه لایه را با مثال یک درگاه پرداخت از هم باز می‌کنیم و می‌بینیم که پروژه‌های نرم‌افزاری بدون آن‌ها در قضاوت درباره کیفیت سرگردان می‌مانند.

سه لایه تعهد به کیفیت: از عدد خام تا قرارداد

SLI؛ شاخص سطح خدمت (Service Level Indicator)

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

منبع SLI معمولاً داده‌های سیستم مانیتورینگ (Monitoring) است. همین اتصال باعث می‌شود شاخص‌ها به‌جای گزارش‌های دستی و دوره‌ای، لحظه‌ای و بی‌طرف باشند؛ عدد را سیستم تولید می‌کند، نه آدم‌هایی که انگیزه گزارش‌سازی دارند.

SLO؛ هدف سطح خدمت (Service Level Objective)

SLO مقدار هدف‌گذاری‌شده روی یک SLI در یک بازه زمانی مشخص است؛ مثلاً «در هر ماه، دست‌کم ۹۹٫۵ درصد درخواست‌ها با موفقیت پردازش شوند». این یک تعهد داخلی است و مخاطبش تیم فنی و مدیریت محصول است، نه مشتری. کارکرد اصلی SLO ساخت ابزار تصمیم‌گیری است: وقتی هدف روشن باشد، می‌توان میان توسعه قابلیت‌های تازه و صرف وقت روی پایداری، اولویت‌بندی آگاهانه کرد.

از دل SLO مفهومی به نام بودجه خطا (Error Budget) بیرون می‌آید: فاصله میان صد درصد و هدف. اگر هدف ۹۹٫۵ درصد باشد، سهم مجاز خرابی ۰٫۵ درصد است؛ در یک ماه ۳۰ روزه یعنی حدود سه ساعت و نیم. این عدد — که در اینجا یک محاسبه آموزشی فرضی است — نگاه تیم را عوض می‌کند: خرابی دیگر فاجعه مطلق نیست، سهمی است که می‌توان در آن برنامه‌ریزی کرد، به‌شرط آن‌که کنترل‌شده مصرف شود.

SLA؛ قرارداد سطح خدمت (Service Level Agreement)

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

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

مقایسه SLA، SLO و SLI در یک نگاه

جدول زیر سه مفهوم را کنار هم می‌گذارد تا مرزشان روشن شود:

مثال کاربردی: درگاه پرداخت

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

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

منافع، محدودیت‌ها و خطاهای رایج

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

خطاهای رایج

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

کاربرد عملی در پروژه‌های نرم‌افزاری

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

این سه مفهوم حتی می‌توانند در تعریف «تمام‌شده» یک قابلیت هم نقش بگیرند: انتشار نسخه‌ای که SLO سرویس را به‌طور پایدار پایین می‌آورد، منتشرشده نیست؛ عقب‌نشینی است. با چنین نگاهی، کیفیت دیگر بخشی از پروژه نیست، خودِ محصول است.

نکات کلیدی این مقاله

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

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

آیا SLA همیشه سندی حقوقی و رسمی است؟

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

چرا به‌جای صد درصد، هدفی مانند ۹۹٫۵ درصد انتخاب می‌شود؟

چون صد درصد یعنی هیچ نگهداشتی، هیچ تغییری و هیچ خطای انسانی پذیرفته نیست؛ هدفی که در عمل دست‌یافتنی نیست و رفتار گزارش‌سازی نادرست می‌سازد. هدف واقع‌بینانه مانند ۹۹٫۵ درصد فضا برای نگهداشت و خطای انسانی می‌گذارد و با بودجه خطا، مصرف این فضا را هم شفاف می‌کند. کیفیت را باید مدیریت کرد، نه شکار.

اگر SLO نقض شود اما SLA سالم بماند، چه باید کرد؟

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