SLA چیست؟ راهنمای سنجش سطح خدمت و پشتیبانی ۲۴/۷

SLA چیست و چه چیزی SLA نیست؟

SLA مخفف Service Level Agreement یا موافقت‌نامه سطح خدمت است: بخشی از رابطه تجاری که خدمت، معیارها، مسئولیت دو طرف، روش سنجش و پیامد نرسیدن به سطح توافق‌شده را روشن می‌کند. NIST در چارچوب سنجه‌های خدمات ابری، توافق خدمت را پیوندی میان انتخاب، تعهد و راستی‌آزمایی می‌داند. بنابراین جمله «سامانه پایدار است» SLA نیست؛ باید معلوم شود کدام سامانه، برای چه کاربران و در چه بازه‌ای با چه داده‌ای سنجیده می‌شود. ^{[۱] [۲]}

SLA با فهرست امکانات، قرارداد پشتیبانی یا سیاست داخلی عملیات هم‌پوشانی دارد اما برابر آن‌ها نیست. فهرست امکانات می‌گوید چه چیزی عرضه می‌شود؛ دامنه پشتیبانی می‌گوید چه درخواست‌هایی پذیرفته می‌شوند؛ سیاست رخداد می‌گوید تیم چگونه واکنش می‌دهد؛ و SLA نتیجه قابل مشاهده و تعهد بیرونی را مشخص می‌کند. در خرید نرم‌افزار مالی، ممکن است دسترس‌پذیری ابر، زمان پاسخ رخداد بحرانی، بازیابی داده و پاسخ به درخواست عادی هرکدام توافق و سنجه جدا داشته باشند. ^{[۱] [۸]}

استاندارد ISO/IEC 20000-1 مدیریت خدمت را یک سیستم مدیریتی می‌بیند، نه یک عدد تزئینی در قرارداد. برنامه‌ریزی خدمت، نقش‌ها، پایش، بازبینی و بهبود باید پشت تعهد قرار گیرند. اگر فروشنده عددی می‌دهد اما نمی‌تواند مالک سنجه، گزارش دوره‌ای، فرایند رخداد یا اقدام اصلاحی را نشان دهد، خریدار با یک وعده شکننده روبه‌رو است. از سوی دیگر، سخت‌گیرانه‌ترین عدد نیز بدون هزینه، ظرفیت و مشارکت مشتری لزوماً انتخاب اقتصادی درستی نیست. ^{[۲] [۳]}

تفاوت SLI، SLO و SLA با یک مثال عملی

SLI یا شاخص سطح خدمت، اندازه‌ای از رفتار واقعی سامانه است؛ برای نمونه نسبت درخواست‌های موفق در کمتر از یک آستانه زمانی به کل درخواست‌های معتبر. SLO یا هدف سطح خدمت، مقدار هدف آن شاخص در یک پنجره زمانی است. SLA تعهد تجاری‌ای است که می‌تواند یک یا چند هدف، استثنا و جبران را در خود جای دهد. Google SRE نیز SLO را هدف قابلیت اطمینان و SLA را توافق تجاری متمایز می‌کند؛ مخلوط‌کردن این سه، گزارش را مبهم می‌سازد. ^{[۳] [۴]}

فرض کنید SLI، «دقیقه‌های سالم قابل استفاده برای کاربران مجاز» باشد و SLO مقدار هدف همان نسبت در ماه. قرارداد باید اضافه کند دقیقه سالم چگونه تشخیص داده می‌شود، اختلال جزئی چه وزنی دارد، کدام مناطق یا نقش‌ها در دامنه‌اند و اختلاف داده مشتری و ارائه‌دهنده چگونه حل می‌شود. اگر فقط پاسخ HTTP صفحه ورود سنجیده شود اما ثبت سند یا گزارش مالی از کار افتاده باشد، سنجه فنی ظاهراً سبز است و تجربه حیاتی کاربر را پنهان می‌کند. ^{[۳] [۱]}

هدف صددرصدی معمولاً نه واقع‌بینانه است و نه رایگان. رویکرد بودجه خطا، فاصله میان هدف و صددرصد را به ظرفیت کنترل‌شده برای تغییر و رخداد تبدیل می‌کند. سیاست مکتوب باید بگوید با مصرف سریع یا کامل بودجه چه می‌شود: توقف انتشار پرریسک، اولویت‌دادن به اصلاح قابلیت اطمینان یا بازبینی هدف. بودجه خطا مجوز بی‌کیفیتی نیست؛ راهی است تا تصمیم میان سرعت توسعه و ثبات بر داده و اثر مشتری تکیه کند. ^{[۵] [۳]}

درصد دسترس‌پذیری را چگونه درست بخوانیم؟

عدد uptime بدون فرمول ناقص است. از فروشنده بپرسید مخرج محاسبه کل دقیقه‌های تقویمی است یا فقط ساعات کاری؛ اختلال سراسری، کندی شدید و خرابی یک قابلیت اصلی چگونه وزن می‌گیرند؛ و پنجره ماهانه، فصلی یا شناور است. همچنین منبع حقیقت باید معلوم باشد: پایش ارائه‌دهنده، مشاهده بیرونی، لاگ تراکنش کاربر یا ترکیبی از آن‌ها. NIST تأکید می‌کند سنجه باید نماینده، دقیق و قابل بازتولید باشد تا انتخاب و راستی‌آزمایی خدمت ممکن شود. ^[۱]

قلمرو مهم‌تر از رقم است. آیا API، اپ موبایل، ورود پیامکی، گزارش‌گیری، ارسال صورتحساب و پردازش پس‌زمینه داخل همان تعهد‌اند؟ آیا افت کارایی که ثبت سند را چند دقیقه طول می‌دهد «در دسترس» حساب می‌شود؟ یک SLA مالی بهتر است سفرهای حیاتی مانند ورود، ثبت سند، مشاهده مانده و خروجی را تعریف کند. هدف latency نیز می‌تواند درصدی باشد؛ میانگین ساده، تجربه بد بخش کوچکی از کاربران را پنهان می‌کند. ^{[۴] [۳]}

استثناها باید محدود و قابل ممیزی باشند. نگهداری برنامه‌ریزی‌شده به پنجره اعلام، سقف مدت و کانال اطلاع‌رسانی نیاز دارد. فورس‌ماژور، اینترنت مشتری، تنظیم نادرست، سرویس ثالث و حمله نیز نباید به عبارت‌های بی‌مرز تبدیل شوند. برای هر وابستگی بنویسید چه کسی آن را پایش می‌کند و افت آن چگونه در گزارش می‌آید. اگر تمام زنجیره‌های محتمل استثنا شوند، عدد سطح خدمت در زمان نیاز واقعی کاربردی نخواهد داشت. ^{[۱] [۲]}

پشتیبانی ۲۴/۷ دقیقاً به چه معناست؟

چهار مفهوم را جدا کنید: امکان ثبت درخواست در تمام ساعات، پایش خودکار شبانه‌روزی، حضور کارشناس آماده‌به‌کار و کار پیوسته تا مهار یا رفع. یک پورتال می‌تواند همیشه درخواست بگیرد ولی صف انسانی فقط در ساعات کاری بررسی شود. حتی در خدمات بزرگ، سطح شدت و طرح خریداری‌شده زمان پاسخ را تغییر می‌دهد. اسناد AWS و Microsoft نمونه روشنی‌اند که زمان پاسخ نخست را بر اساس اثر کسب‌وکار و سطح خدمت طبقه‌بندی می‌کنند. ^{[۶] [۷]}

زمان پاسخ نخست با زمان رفع یکی نیست. پاسخ نخست یعنی فرد یا تیم مسئول درخواست را پذیرفته و کار را آغاز کرده است؛ مهار، کاهش اثر فوری است؛ راه‌حل موقت امکان ادامه محدود را می‌دهد؛ رفع، علت یا خرابی را برطرف می‌کند؛ و تحلیل ریشه‌ای بعدتر می‌تواند علت و اقدام پیشگیرانه را مستند کند. قراردادی که فقط «پاسخ یک‌ساعته» دارد ممکن است هیچ تعهدی برای به‌روزرسانی، مهار یا بازگشت خدمت نداشته باشد. ^{[۶] [۸]}

پشتیبانی پیوسته یک تعهد دوطرفه نیز هست. مشتری باید مخاطب مجاز، شماره در دسترس، داده بی‌خطر تشخیصی، زمان وقوع، اثر، گام‌های تکرار و تغییرات اخیر را ارائه کند. Microsoft در رخدادهای شدت بالا، همراهی پیوسته مشتری را شرط ادامه کار ۲۴/۷ می‌داند و AWS بر انتخاب شدت درست و ارائه دامنه اثر، زمان، شناسه منابع و اقدامات انجام‌شده تأکید دارد. بدون نماینده تصمیم‌گیر مشتری، کار شبانه‌روزی می‌تواند در انتظار مجوز متوقف شود. ^{[۷] [۶]}

ماتریس شدت و زمان را چگونه طراحی کنیم؟

شدت باید بر اثر قابل مشاهده بنا شود، نه اضطراب درخواست‌کننده. شدت بحرانی می‌تواند توقف فرایند اصلی برای بیشتر کاربران، خطر از دست‌رفتن داده یا نبود راه‌حل موقت باشد؛ شدت بالا، افت مهم با راه‌حل محدود؛ متوسط، اختلال برای بخشی از کاربران؛ و عادی، سؤال یا درخواست تغییر. تعداد کاربران، نزدیک‌بودن موعد قانونی و اثر مالی می‌توانند معیار کمکی باشند. تعریف باید مثال‌های متعلق به کسب‌وکار مشتری داشته باشد تا دو طرف یک رخداد را متفاوت طبقه‌بندی نکنند. ^{[۶] [۷]}

برای هر شدت، ساعت پوشش، کانال مجاز، زمان تأیید، زمان آغاز بررسی، فاصله به‌روزرسانی، هدف مهار و مسیر تصعید بنویسید. هدف رفع قطعی را فقط جایی عددی کنید که نوع خرابی واقعاً قابل پیش‌بینی است؛ گاهی تعهد به کار مستمر و به‌روزرسانی منظم صادقانه‌تر است. ساعت از لحظه ثبت کامل آغاز می‌شود یا تشخیص خودکار؟ توقف ساعت هنگام انتظار پاسخ مشتری چگونه ثبت می‌شود؟ این جزئیات از اختلاف پس از رخداد جلوگیری می‌کنند. ^{[۲] [۶]}

فرایند ارتقا و تنزل شدت نیز لازم است. اگر اثر گسترش یافت، مشتری باید کانال تصعید و مسئول آن را بداند؛ اگر راه‌حل موقت برقرار شد، تنزل شدت باید با ثبت دلیل انجام شود. فروشنده نباید صرفاً برای بهبود آمار، پرونده را ببندد و مشتری نیز نباید همه پرسش‌ها را بحرانی اعلام کند. گزارش دوره‌ای بهتر است حجم، سن، زمان پاسخ، زمان مهار، پرونده بازگشایی‌شده و علل پرتکرار را کنار رضایت و اثر واقعی نشان دهد. ^{[۶] [۲]}

رخداد، ارتباطات و جبران خدمت در قرارداد

طرح رخداد باید نقش فرمانده، مالک فنی، ارتباط با مشتری و تصمیم بازیابی را تعیین کند. برای رخداد مهم، کانال وضعیت، زمان نخستین اطلاع، فاصله به‌روزرسانی و معیار پایان تعریف شود. NIST SP 800-61 Rev. 3 بر آمادگی، هماهنگی با ذی‌نفعان و تأمین‌کنندگان و ارتباط پیشرفت بازیابی تأکید دارد. پیام خوب واقعیت معلوم، اثر، اقدام جاری و زمان به‌روزرسانی بعدی را می‌گوید و از حدس درباره علت پیش از بررسی خودداری می‌کند. ^[۸]

جبران خدمت می‌تواند اعتبار دوره بعد، بازپرداخت بخشی از هزینه یا حق فسخ در نقض تکراری باشد. فرمول باید پلکانی، سقف‌دار و متناسب با خدمت آسیب‌دیده باشد و روش مطالبه و مهلت آن را بگوید. اعتبار مالی جای زیان کسب‌وکار را لزوماً نمی‌گیرد؛ نقش آن ایجاد پاسخ‌گویی قراردادی است. برای فرایند بسیار حساس، معماری جایگزین، خروجی داده، برنامه تداوم و امکان مهاجرت مهم‌تر از امید به جبران پس از توقف‌اند. ^{[۱] [۲]}

گزارش پسارخداد را از سرزنش فردی جدا کنید. دامنه اثر، خط زمانی، تشخیص، مهار، بازیابی، عوامل مؤثر و اقدام‌های دارای مالک و موعد باید ثبت شوند. همه رخدادها تحلیل مفصل نمی‌خواهند؛ آستانه بر اساس شدت، تکرار و مصرف بودجه خطا تعیین شود. سیاست Google نمونه‌ای ارائه می‌کند که رخداد مصرف‌کننده بخش بزرگی از بودجه را به بازبینی و اقدام اجباری وصل می‌کند. مشتری نیز باید نتیجه اقدام اصلاحی را در بازبینی خدمت دنبال کند. ^{[۵] [۸]}

چک‌لیست خرید و مرز وعده عمومی ژرف‌بان

پیش از امضا، یک پیوست یک‌صفحه‌ای بسازید: نام و نسخه خدمت، کاربران و قابلیت‌های داخل دامنه، ساعات پوشش، منطقه زمانی و تعطیلات، SLI و فرمول، هدف و پنجره، منبع داده، نگهداری، وابستگی و استثنا، شدت‌ها، زمان‌های پاسخ و به‌روزرسانی، کانال تصعید، مسئولیت مشتری، گزارش، جبران، تغییر SLA و خروج داده. سپس دو سناریوی واقعی—توقف ثبت مالی در پایان ماه و کندی گزارش—را با همین متن محاسبه کنید. ^{[۱] [۲]}

در ارزیابی فروشنده، نمونه گزارش ماهانه و یک رخداد گذشته با اطلاعات بی‌نام بخواهید. بررسی کنید درصد اعلامی از همان فرمول قرارداد آمده باشد، پرونده‌های وابسته و نگهداری حذف‌شده قابل ردیابی باشند و اقدام اصلاحی بسته شده باشد. همچنین RPO و RTO را با SLA دسترس‌پذیری یکی نگیرید: RPO مقدار قابل تحمل عقب‌افتادگی داده و RTO هدف زمان بازگرداندن خدمت است. هر دو برای همان معماری، پشتیبان و سناریوی خرابی باید آزمایش و قراردادی شوند. ^{[۱] [۸]}

ژرف‌بان در صفحات عمومی فعلی عدد uptime، SLA، RPO یا RTO و نیز دسترسی انسانی ۲۴/۷ منتشر نکرده است. وعده عمومی قابل استناد کنونی، پاسخ واتساپ در ساعات کاری و ایمیل حداکثر تا یک روز کاری است. اگر سطح دیگری برای استقرار شما لازم است، دامنه، عدد، ساعت و قیمت آن باید در پیشنهاد و قرارداد همان پروژه نوشته شود. در دمو قابلیت فعال را اجرا کنید و از تیم بخواهید ماتریس مسئولیت و سطح خدمت پیشنهادی را جدا تحویل دهد. ^{[۱] [۲] [۸]}

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