RCA (Root Cause Analysis) یا «تحلیل علت ریشهای» روشی ساختاریافته برای فهمیدن این است که چرا یک Incident یا Problem رخ داده و چه اقداماتی میتواند احتمال تکرار آن را کاهش دهد. هدف RCA فقط پیدا کردن «یک مقصر» نیست؛ هدف شناخت علتها و شرایطی است که وقوع مشکل را ممکن کردهاند.
RCA چه تفاوتی با رفع Incident دارد؟
در Incident Management اولویت معمولاً بازگرداندن سریع سرویس است. ممکن است با Restart، Failover یا یک Workaround سرویس دوباره در دسترس قرار گیرد، اما این به معنی حذف علت اصلی نیست. RCA بیشتر در Problem Management کاربرد دارد تا مشخص شود چرا اختلال رخ داده و چه تغییر پایداری باید انجام شود.
مراحل ساده تحلیل علت ریشهای
- مسئله را دقیق تعریف کنید: چه سرویس یا فرایندی، از چه زمانی و با چه اثری مختل شد؟
- شواهد جمع کنید: Log، Timeline، Change History، Alert، Ticket و اظهارات تیمهای درگیر.
- علتهای محتمل را بررسی کنید: به یک پاسخ سریع اکتفا نکنید؛ مشکل ممکن است چند علت فنی و سازمانی داشته باشد.
- فرضیه را با داده آزمایش کنید: بین همبستگی و علت واقعی تفاوت بگذارید.
- اقدام اصلاحی تعریف کنید: Permanent Fix، تغییر فرایند، کنترل پیشگیرانه یا Monitoring بهتر.
- نتیجه را پایش کنید: بررسی کنید آیا Incident واقعاً کمتر شده و اقدام جدید عارضه دیگری ایجاد نکرده است.
تکنیکهای رایج RCA
5 Why برای مسائل نسبتاً ساده و خطی مفید است؛ نمودار علت و معلول یا Fishbone میتواند دستههای مختلف علت را همزمان بررسی کند؛ Timeline Analysis نیز برای Incidentهای پیچیدهای که چند رویداد پشت سر هم رخ دادهاند مناسب است. در مسائل پیچیده، اصرار بر اینکه حتماً فقط «یک علت ریشهای» وجود دارد میتواند تحلیل را بیش از حد ساده کند.
مثال RCA در ITSM
فرض کنید پورتال سازمان هر دوشنبه صبح کند میشود. Restart کردن Application Server مشکل را موقتاً رفع میکند، اما Incident هفته بعد تکرار میشود. بررسی Timeline و Metrics نشان میدهد یک Job گزارشگیری همزمان با اوج ورود کاربران، Query سنگینی روی Database اجرا میکند. اقدام پایدار میتواند زمانبندی مجدد Job، بهینهسازی Query و ایجاد Alert برای زمان پاسخ Database باشد؛ نه صرفاً Restart هفتگی.
RCA، Known Error و Workaround
اگر Problem تحلیل شده ولی هنوز Permanent Fix آماده نباشد، میتوان آن را بهعنوان Known Error مدیریت کرد و Workaround مناسب را در اختیار Service Desk گذاشت. به این ترتیب تیم پشتیبانی اثر Incidentهای تکراری را سریعتر کاهش میدهد، در حالی که رفع ریشهای همچنان پیگیری میشود.
سخن پایانی
RCA زمانی ارزشمند است که از «چرا خراب شد؟» به «چه چیزی در سیستم، فرایند یا تصمیمگیری باید تغییر کند تا دوباره تکرار نشود؟» برسد. خروجی خوب RCA باید قابل اقدام، قابل اندازهگیری و قابل پیگیری باشد.
