و سپس «افزودن به صفحه اصلی» ضربه بزنید
و سپس «افزودن به صفحه اصلی» ضربه بزنید
مدیریت خدمات فناوری اطلاعات (ITSM) تنها زمانی موفق تلقی می‌شود که سطح خدمت ارائه شده با انتظارات مشتری یا سازمان هم‌تراز باشد. در ITIL، ابزار اصلی برای تعریف و کنترل این سطح خدمت، دو مفهوم کلیدی SLA و OLA هستند.
این دو مفهوم اگر درست پیاده‌سازی و مانیتور شوند، باعث:
- هماهنگی بین تیم‌ها
- جلوگیری از ابهام در وظایف
- کاهش شکایات کاربران
- افزایش رضایت و کیفیت خدمت
می‌شوند.
اما در بسیاری از سازمان‌ها SLA فقط روی کاغذ است و نه قابل اندازه‌گیری، نه قابل پایش، و نه اجرایی.
در این مقاله از لاندا، یک راهنمای کامل، اجرایی و واقعی برای:
- تعریف اس‌ال‌ای سازمانی
- پیمان داخلی OLA بین تیم‌ها
- طراحی KPI عملی
- مانیتورینگ ۲۴/۷
ارائه می‌کنیم.
SLA چیست؟
توافق رسمی بین ارائه‌دهنده خدمت SLA (Service Level Agreement) (مثلاً واحد IT یا شرکت پیمانکار) و مشتری / واحدهای کسب‌وکار است که در آن مشخص می‌شود:
| مورد | توضیح |
|---|---|
| خدمت چیست؟ | (مثلاً سرویس ERP، شبکه، دیتابیس SQL، پشتیبانی Helpdesk) |
| سطح کیفیت مورد انتظار چیست؟ | (Availability 99.5%, Response Time زیر ۳۰ دقیقه و …) |
| ساعات ارائه خدمت چیست؟ | ۲۴/۷ یا کاری ۸-۱۷ |
| جریمه یا امتیاز رعایت/نقض چیست؟ | Credit/Penalty Model |
اس‌ال‌ای از دید سازمان: “ما چه سطح خدماتی را ضمانت می‌کنیم.”
OLA چیست؟
توافق بین تیم‌های داخلی IT OLA (Operational Level Agreement) برای انجام تعهدات SLA است.
مثال:
- اگر اس‌ال‌ای می‌گوید: «زمان رفع Incident: حداکثر ۴ ساعت»
- OLA تعیین می‌کند:
- تیم شبکه ۳۰ دقیقه برای تشخیص Root Cause فرصت دارد.
- تیم امنیت ۱۵ دقیقه برای بررسی لاگ‌ها
- تیم DBA باید Recovery Plan را در ۶۰ دقیقه اجرا کند.
OLA از دید سازمان: “هر تیم برای رسیدن به SLA دقیقاً چه کار می‌کند و در چه زمانی.”
تفاوت SLA و OLA
| ویژگی | SLA | OLA |
|---|---|---|
| طرف قرارداد | سازمان ↔ مشتری | تیم‌های داخلی ↔ تیم IT |
| هدف | تضمین خدمت به مشتری | تضمین تحقق SLA |
| زبان | تجاری / قابل فهم برای مدیریت | فنی و عملیاتی |
| مسئولیت‌ها | سطح کلان | سطح جزئی و تخصصی |
چرا بیشتر SLAها شکست می‌خورند؟
اس‌ال‌ای تعریف می‌شود ولی قابل اندازه‌گیری نیست.
اس‌ال‌ای مبهم است (به‌جای “رفع”، می‌نویسند “رسیدگی”)
هیچ مانیتورینگ Real-Time وجود ندارد.
OLA تعریف نشده → هر تیم تقصیر را گردن دیگری می‌اندازد.
مدیریت اس‌ال‌ای در Excel دستی انجام می‌شود.
نتیجه: SLA تبدیل به یک PDF تزئینی می‌شود.
چارچوب طراحی SLA در سازمان (استاندارد لاندا)
۱. تعریف Service Catalog سازمان
لیست سرویس‌ها باید شفاف باشد:
- شبکه
- ایمیل
- دیتابیس SQL
- ERP
- پشتیبانی Helpdesk
- سرویس‌های ابری
بدون Service Catalog → SLA معنی ندارد.
۲. تعریف KPIهای قابل اندازه‌گیری
نمونه KPIهای استاندارد:
| KPI | توضیح | روش اندازه‌گیری |
|---|---|---|
| Availability (Uptime) | درصد در دسترس بودن سرویس | مانیتورینگ Uptime |
| Response Time | زمان پاسخ‌گویی به درخواست | Helpdesk Ticketing |
| MTTR | میانگین زمان رفع مشکل | Incident Log |
| MTBF | میانگین فاصله بین خرابی‌ها | Historical Reports |
۳. تقسیم نقش‌ها در قالب OLA
نمونه OLA تیمی:
| تیم | وظیفه | زمان مجاز (SLA Support) |
|---|---|---|
| Helpdesk | ثبت و طبقه‌بندی Incident | ≤ ۱۰ دقیقه |
| Network | Ping / Traceroute / Routing Fix | ≤ ۴۵ دقیقه |
| DBA | بررسی Query / Failover / Recovery | ≤ ۱ ساعت |
| امنیت | بررسی تهدید / فایروال / WAF | ≤ ۳۰ دقیقه |
۴. مانیتورینگ SLA و OLA به‌صورت Real-Time
پیشنهاد:
- Zabbix یا Prometheus برای سرویس‌های شبکه/سرور
- Elastic + SIEM برای امنیت
- Grafana / Power BI برای داشبورد مدیریتی
- و تیکتینگ: OTRS / Freshdesk / SysAid / Jira Service Desk
قالب SLA پیشنهادی (قابل استفاده فوری)
Service Name: Microsoft SQL Server
Availability: 99.5%
Support Level: 24/7
Incident Response Time: ≤ ۳۰ دقیقه
Incident Resolution (P1): ≤ ۴ ساعت
Planned Maintenance: فقط ۲۳:۰۰ تا ۰۵:۰۰
Penalty: 5% Credit از حق‌الزحمه ماهانه به‌ازای هر ۱% کاهش در Uptime
قالب OLA پیشنهادی
DBA Team:
- Failover بررسی: ≤ ۱۰ دقیقه
- Restore / Recovery Plan: ≤ ۶۰ دقیقه
- مانیتورینگ TempDB / IO / Blocking: Real-Time Dashboard
Network Team:
- بررسی دسترسی به Node ها: ≤ ۱۰ دقیقه
- اصلاحات Routing / DNS / Firewall: ≤ ۴۵ دقیقه
مانیتورینگ SLA و OLA در عمل
داشبورد مدیریت (Executive View):
- رنگ‌ها ساده (سبز/زرد/قرمز)
- KPIهای واضح
- نمودارهای Availability و Incident Trend
- قابل نمایش در موبایل
داشبورد فنی (Technical View):
- Performance Metrics
- Log Analytics
- Alerting Rules و Escalation Policy
لاندا برای اینکار از ساختار:
- Grafana + Zabbix
- Elastic + Watchers
- Power BI برای گزارش مدیریتی
استفاده می‌کند.
بهترین الگوهای موفقیت (Best Practices 2025)
| توصیه | توضیح |
|---|---|
| SLA باید قابل اندازه‌گیری باشد | قابل سنجش = قابل اجرا |
| هر SLA باید OLA مرتبط داشته باشد | بدون OLA SLA اجرا نمی‌شود |
| Eskalation Policy ضروری است | چه کسی، چه زمان، در چه شرایطی تماس می‌گیرد |
| گزارش‌دهی باید خودکار باشد | نه Excel دستی، نه گزارش آخر ماه |
| دسترسی Dashboard برای مدیران ضروری است | شفافیت = اعتماد |
نتیجه‌گیری
SLA و OLA فقط قرارداد نیستند؛ ستون فقرات مدیریت خدمات IT هستند.
اگر درست طراحی و مانیتور شوند، سازمان از حالت واکنشی به پیشگیرانه و کنترل شده می‌رسد.
اگر فرایندها استاندارد و شفاف شوند، مشکلات:
- کمتر،
- سریع‌تر حل،
- و با هزینه پایین‌تر
مدیریت می‌شوند.
سوالات متداول (FAQ)
۱. آیا SLA فقط برای شرکت‌های بزرگ ضروری است؟
خیر، حتی تیم‌های ۳ نفره IT هم باید اس‌ال‌ای داشته باشند.
۲. SLA بدون OLA قابل اجراست؟
تقریباً همیشه نتیجه شکست است.
۳. SLA باید سالانه بازبینی شود؟
بله، تغییر اندازه سازمان → تغییر سطح خدمت.
تماس و مشاوره ITIL توسط لاندا
اگر نیاز دارید SLA و OLA واقعی و قابل مانیتور در سازمان پیاده‌سازی کنید:
تیم لاندا با:
- طراحی فرآیند ITSM
- مستندسازی
- و ساخت داشبورد مانیتورینگ مدیریتی
این کار را برای سازمان شما اجرا می‌کند.
نظری داده نشده