چطور به رخدادها پاسخ می‌دیم — شفاف و بدون ابهام

ما هیچ عدد uptime یا SLA رو بدون شرایط و دامنه‌ی مشخص تبلیغ نمی‌کنیم. این صفحه چارچوبی رو توضیح می‌ده که برای تعریف سطح پاسخ‌گویی هر مشتری استفاده می‌کنیم.

چهار مفهومی که باید از هم جدا بشن

Response Time چقدر طول می‌کشه یک مهندس واقعی رخداد شما رو ببینه و شروع به بررسی کنه.

Acknowledgement Time چقدر طول می‌کشه رسماً تایید کنیم که رخداد رو دریافت کردیم و در حال بررسیشیم.

Resolution Time چقدر طول می‌کشه رخداد کاملاً برطرف بشه — این عدد به‌شدت به پیچیدگی مشکل بستگی داره.

Availability Target هدف uptime سیستم در یک بازه‌ی زمانی مشخص، معمولاً به‌صورت درصد ماهانه یا سالانه.

پاسخ‌گویی بر اساس Severity، نه یک عدد ثابت برای همه

زمان پاسخ واقعی برای هر مشتری در قرارداد سرویس تعریف می‌شه و به severity رخداد بستگی داره — یک باگ جزئی UI با یک قطعی کامل production فرق داره.

Critical (Sev-1) قطعی کامل سرویس یا از دست رفتن داده — بالاترین اولویت پاسخ‌گویی.

High (Sev-2) افت شدید عملکرد یا از کار افتادن یک قابلیت اصلی.

Medium (Sev-3) مشکل محدود که کارکرد اصلی سیستم رو مختل نمی‌کنه.

Low (Sev-4) درخواست‌ها و مشکلات جزئی که در چرخه‌ی عادی کاری رسیدگی می‌شن.

چیزی که تضمین نمی‌کنیم

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

می‌خواید سطح پاسخ‌گویی دقیق برای زیرساخت خودتون رو بدونید؟

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