Availability واقعی سرویس‌ها؛ چرا درصد SLA کافی نیست؟

خلاصه

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

کلمات کلیدی

Availability Management، Service Availability، SLA، ITSM، Availability  واقعی، Downtime، Uptime، مانیتورینگ سرویس، تجربه کاربر IT، Availability بر اساس کسب‌وکار، Lost User Minutes، NOC، مدیریت پایداری سرویس

مقدمه: چرا Availability این‌قدر مهم است؟

مدیریت Availability یا دردسترس‌بودن سرویس‌ها مستقیماً با اهداف کسب‌وکار و بهبود مستمر گره خورده است. وقتی سرویسی که کاربر انتظار استفاده از آن را دارد در دسترس نیست، نارضایتی اجتناب‌ناپذیر است. تهِ ماجرا ساده است:

هیچ سازمانی حاضر نیست برای سرویسی هزینه کند که در زمان نیاز، قابل استفاده نیست.

به همین دلیل Availability معمولاً به‌عنوان یکی از KPIهای اصلی در مدیریت خدمات فناوری اطلاعات (ITSM) تعریف می‌شود. اما همین‌جا اولین دام شکل می‌گیرد.

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

Availability  چگونه محاسبه می‌شود؟

ساده‌ترین تعریف Availability این است:

Availability = (AST – Downtime) / AST × 100

• AST (Agreed Service Time): زمان توافق‌شده ارائه سرویس
• Downtime: مجموع زمان‌های قطعی

اگر سرویسی باید ۱۰۰ ساعت در دسترس باشد و ۲ ساعت قطعی داشته باشد، Availability برابر 98% است. بر همین اساس، اگر یک سرویس در طول ماه 2 ساعت قطعی داشته باشد، Availability آن 99.72% خواهد بود! اما سؤال اصلی این است:

این عدد دقیقاً چه چیزی را درباره تجربه کاربر و کسب‌وکار می‌گوید؟

مشکل اصلی درصدهای Uptime

مسئله اینجاست که این عدد:

• نمی‌گوید قطعی چه زمانی رخ داده
• نمی‌گوید چند بار رخ داده
• نمی‌گوید چند نفر تحت تأثیر بوده‌اند
• و مهم‌تر از همه، نمی‌گوید کدام بخش سرویس از کار افتاده

در یک فروشگاه اینترنتی ایرانی، ۲ ساعت قطعی نیمه‌شب تقریباً هیچ اثر تجاری نداشت. اما 2 ساعت قطعی در زمان کمپین فروش، منجر به از دست رفتن هزاران سفارش شد. در گزارش ماهانه تیم فنی به مدیرعامل، هر دو «۲ ساعت Downtime» دیده شدند؛ اما اثرشان زمین تا آسمان فرق داشت.

چرا مشتری عدد نمی‌خواهد، تجربه می‌خواهد؟

از دید مشتری، Availability  فقط زمانی معنا دارد که نشان دهد آیا می‌تواند کارش را انجام دهد یا نه.

اگر کاربر نتواند ایمیل بفرستد، تراکنش ثبت کند یا عملیات اصلی‌اش را انجام دهد، گزارش «99.9% = Availability» هیچ ارزشی ندارد.

به عنوان مثال در یک بانک، اگر تمامی سرورها Up باشند اما بخشی از تراکنش‌ها ثبت نشود، کاربر نمی‌پرسید Availability چند درصد است؟! می‌پرسد «چرا کارم انجام نمی‌شود؟»

شناسایی کارکردهای حیاتی کسب‌وکار

هر سرویس IT چندین کارکرد دارد، اما ارزش همه آن‌ها یکسان نیست.

اولین قدم برای Availability معنادار این است که بدانیم کدام کارکردها حیاتی‌اند.

مثال ساده سرویس ایمیل:

کارکرد از کار افتاده	افت ارزش سرویس
ارسال ایمیل	100%
دریافت ایمیل	100%
خواندن پوشه‌ها	50%
ویرایش پوشه‌ها	10%
دسترسی به تقویم	30%

واضح است: اگر ارسال و دریافت ایمیل کار نکند، سرویس (صرفنظر از رقم SLA) عملاً بی‌ارزش است.

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

مدت و تکرار قطعی؛ دو عامل فراموش‌شده

دو ساعت Downtime می‌تواند:

• یک قطعی ۲ ساعته باشد
• یا ۲۰ قطعی ۶ دقیقه‌ای

اثر این دو کاملاً متفاوت است.

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

به همین دلیل، به‌جای درصد کلی، می‌توان آستانه‌های قابل قبول تعریف کرد:

مدت قطعی	حداکثر مجاز
زیر ۲ دقیقه	چند بار در روز
۲ تا ۳۰ دقیقه	چند بار در ماه
بیش از ۱ ساعت	حداکثر سالی یک‌بار

این مدل برای مدیران قابل لمس‌تر از یک عدد انتزاعی است.

Availability  بر اساس اثر واقعی روی بهره‌وری

یکی از دقیق‌ترین روش‌ها برای سنجش اثر قطعی، محاسبه دقایق کاری از دست‌رفته کاربران است.

روش ساده:

• Potential User Minutes = تعداد کاربران × زمان کاری
• Lost User Minutes = کاربران متاثر × مدت قطعی

به عنوان مثال، در یک شرکت ۵۰ نفره، اگر ۲۰ نفر به مدت ۱۵ دقیقه نتوانند کار کنند:

Lost User Minutes = 300

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

همین روش را می‌توان برای:

• مرکز تماس (Agent Phone Minutes)
• سامانه‌های تراکنشی
• خطوط تولید

به‌کار برد.

جمع‌آوری داده  Availability؛ هیچ راه جادویی وجود ندارد

روش‌های مختلفی وجود دارد:

• داده‌های Service Desk (ارزان اما بحث‌برانگیز)
• مانیتورینگ زیرساخت و اپلیکیشن
• تراکنش‌های مصنوعی (Synthetic Monitoring)
• Instrumentation  داخل اپلیکیشن

مثلا ممکن است در یک سازمان، اختلال ایمیل به دلیل DHCP رخ دهد اما چون سرور ایمیل سالم است، در گزارش Availability دیده نمی‌شود. در چنین حالتی است که تنها مانیتورینگ End-to-End مشکل را آشکار خواهد کرد.

Downtime برنامه‌ریزی‌شده

اگر Downtime برنامه‌ریزی‌شده شفاف و دقیق تعریف نشود:

• گزارش نادقیق می‌شود
• اعتماد از بین می‌رود

باید مشخص باشد:

• چه Downtimeهایی محاسبه می‌شوند
• چه Downtimeهایی خارج از SLA هستند

و این موارد دقیقاً در SLA ثبت شوند

بازی خطرناک با بازه گزارش‌دهی

یک قطعی ۸ ساعته می‌تواند:

• گزارش هفتگی را نابود کند
• گزارش فصلی را «موفق» نشان دهد

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

به عنوان مثال، در یک قرارداد NOCممکن است گزارش فصلی SLA همیشه Pass باشد و در عین حال کاربران نیز هر ماه ناراضی باشند. با تغییر بازه گزارش‌دهی، زمینه بروز واقعیت مهیا می‌شود.

جمع‌بندی نهایی

تقریباً همه سازمان‌ها Availability را اندازه می‌گیرند، اما سازمان‌های بالغ:

• به عدد قانع نمی‌شوند.
• با مشتری گفت‌وگو می‌کنند
• اثر واقعی روی کسب‌وکار را می‌سنجند
• و به‌جای بازی با SLA، تجربه واقعی را بهبود می‌دهند

Availability واقعی یعنی تعهد به قابل استفاده بودن سرویس، نه فقط روشن بودن آن.