رفتن به محتوای اصلی
MedaNet
شرکت مدانت مجری تخصصی پیاده‌سازی، آموزش و پشتیبانی راهکارهای فناوری اطلاعات
راهنمای ServiceDesk Plus | دانش و تجربه اجرایی

RCA در ServiceDesk Plus؛ چگونه Root Cause Analysis را از Incident تکراری به Problem واقعی تبدیل کنیم؟

شرکت مدانت

فرض کنید سرویس مالی هر دوشنبه صبح کند می‌شود. تیم پشتیبانی هر بار Service را Restart می‌کند، Incident بسته می‌شود و SLA هم ظاهراً حفظ شده است. اما هفته بعد همان اتفاق تکرار می‌شود. اینجا مسئله دیگر «حل Incident» نیست؛ باید RCA یا Root Cause Analysis انجام شود.

در ServiceDesk Plus، Problem Management برای همین نقطه طراحی شده است: جداکردن رفع موقت اختلال از شناسایی علت ریشه‌ای و جلوگیری از تکرار.

RCA چیست؟

Root Cause Analysis روشی برای پیدا کردن علت بنیادی یک Problem است؛ علتی که اگر اصلاح شود احتمال تکرار مجموعه‌ای از Incidentهای مشابه کاهش می‌یابد. RCA نباید با اولین علت قابل مشاهده متوقف شود.

مثلاً «Database CPU بالا بود» Root Cause نیست؛ باید پرسید چرا CPU بالا رفت، چه Query یا Change باعث آن شد، چرا Monitor هشدار مؤثر نداد و چرا ظرفیت یا Change Control مانع آن نشد.

Incident و Problem چه تفاوتی دارند؟

موضوع Incident Problem
هدف بازگرداندن سرویس کشف و حذف علت
فشار زمانی بالا تحلیلی‌تر
خروجی Resolution/Workaround Root Cause/Known Error/Permanent Fix
KPI مهم MTTR و SLA کاهش تکرار و اثر Problem

چه زمانی Incident باید به Problem تبدیل شود؟

  • Incident مشابه چند بار تکرار شده است.
  • یک Major Incident رخ داده و علت روشن نیست.
  • Workaround وجود دارد اما Fix دائمی ندارید.
  • Trend گزارش‌ها افزایش یک نوع اختلال را نشان می‌دهد.
  • یک CI یا Service به‌طور غیرعادی Incident تولید می‌کند.

RCA را از داده شروع کنید، نه از حدس

قبل از جلسه RCA، Incidentهای مرتبط، Work Log، Change History، Alarm، Log، CI و Timeline را جمع کنید. اگر داده ناقص باشد، جلسه RCA خیلی زود به «حدس فنی» تبدیل می‌شود.

اتصال Incident به CIهای صحیح در CMDB کیفیت تحلیل را بالا می‌برد. مقاله CMDB Health در ServiceDesk Plus درباره کیفیت CI و Relationship توضیح بیشتری می‌دهد.

روش 5 Whys چگونه استفاده شود؟

روش Five Whys یعنی چند بار پی‌درپی «چرا؟» بپرسید تا از Symptom به علت برسید. عدد پنج قانون ثابت نیست؛ مهم زنجیره علت و معلول است.

مرحله نمونه
مشکل سامانه مالی کند است.
چرا ۱ Database Queryها کند شده‌اند.
چرا ۲ یک Query Full Scan دارد.
چرا ۳ Index حذف شده است.
چرا ۴ Change شب گذشته Schema را تغییر داده است.
چرا ۵ Checklist تغییر شامل Performance Validation نبوده است.

در این مثال، Root Cause صرفاً «Index حذف‌شده» نیست؛ ضعف Change Control نیز یک علت سیستمی است که باید اصلاح شود.

Fishbone چه زمانی بهتر است؟

برای Problemهای پیچیده که چند عامل هم‌زمان محتمل‌اند، نمودار Ishikawa یا Fishbone می‌تواند علت‌ها را در دسته‌هایی مثل People، Process، Technology، Vendor، Environment و Data تفکیک کند.

Known Error و Workaround را ثبت کنید

اگر Root Cause شناسایی شده اما Fix دائمی زمان می‌برد، Known Error و Workaround ارزش زیادی دارند. Service Desk می‌تواند Incidentهای بعدی را سریع‌تر پاسخ دهد تا Change نهایی اجرا شود.

RCA بدون Change Management ناقص است

بخش زیادی از Fixهای دائمی نیاز به Change دارند. بنابراین Problem Record باید به Change مرتبط شود، Risk ارزیابی گردد، Rollback Plan وجود داشته باشد و بعد از اجرا اثربخشی Fix بررسی شود.

راهنمای Risk Scoring در ServiceDesk Plus برای بخش ارزیابی Change مکمل این سناریو است.

اشتباه‌های رایج در RCA

  • مقصرسازی فرد به‌جای اصلاح سیستم؛
  • توقف روی اولین علت فنی؛
  • نداشتن Timeline دقیق؛
  • ثبت نکردن Evidence؛
  • بستن Problem بلافاصله بعد از Change؛
  • اندازه‌گیری نکردن تکرار Incident پس از Fix.

KPI مناسب برای Problem Management

KPI معنا
Recurring Incident Rate آیا Incident تکراری کم شده است؟
Time to Root Cause شناسایی علت چقدر زمان می‌برد؟
Known Error Coverage برای Problemهای شناخته‌شده Workaround داریم؟
Permanent Fix Effectiveness Fix واقعاً تکرار را متوقف کرده است؟

سناریوی اجرایی در ServiceDesk Plus

  1. Incidentهای مشابه را Link کنید.
  2. Problem Record بسازید.
  3. Owner و Priority تعیین کنید.
  4. Timeline و Evidence جمع‌آوری کنید.
  5. RCA را با 5 Whys یا روش مناسب ثبت کنید.
  6. Workaround/Known Error تعریف کنید.
  7. در صورت نیاز Change بسازید.
  8. بعد از Fix، Monitoring Period تعریف کنید.
  9. Problem را فقط بعد از تأیید عدم تکرار ببندید.

اگر هنوز در مرحله طراحی معماری سامانه هستید، مقاله مقایسه تیکتینگ Cloud و On-Premises در ServiceDesk Plus به انتخاب مدل استقرار کمک می‌کند.

منابع

سخن پایانی

RCA زمانی ارزش دارد که نتیجه آن فقط یک توضیح فنی نباشد؛ باید به اقدام اصلاحی، Change و کاهش واقعی Incidentهای تکراری منجر شود. ServiceDesk Plus این زنجیره را از Incident تا Problem، Known Error و Change قابل رهگیری می‌کند.

مدانت خدمات طراحی Problem Management، پیاده‌سازی ServiceDesk Plus، Workflow، Integration، آموزش و پشتیبانی ارائه می‌کند. برای بررسی مسیر اجرا به ServiceDesk Plus در مدانت مراجعه کنید.

33