هنر ریشه‌یابی خطا (Root Cause Analysis) در تیم‌های فنی

چطور از آتش‌نشانی دائمی به سیستم پایدار برسیم؟

مقدمه: مشکل اصلی ما باگ نیست، تکرار باگ است

تقریبا همه تیم‌های نرم‌افزاری دنیا با باگ، خطا، داون شدن سیستم، مشکلات پرفورمنسی، دیتای خراب یا رفتار غیرمنتظره سرویس‌ها سروکار دارند.

خودِ خطا مشکل اصلی نیست، مسئله این است که:

• همان خطا چندبار تکرار می‌شود،

• هر بار تیم با استرس و فشار کار می‌کند،

• مدیران بالا فقط خروجی می‌خواهند،

• و تیم فنی احساس می‌کند همیشه در حالت «آتش‌نشانی» است.

در بسیاری از شرکت‌ها، واکنش معمول این است:

فقط درستش کن، وقت RCA نداریم!

اما واقعیت این است که وقتی برای RCA وقت نمی‌گذاریم، داریم هزینه تکرار مشکل را قسطی می‌پردازیم.

Root Cause Analysis (RCA) دقیقا برای این طراحی شده که:

• چرخه‌ی «خرابی => وصله => خرابی مجدد» را بشکند،

• خطا را از زاویه سیستمی نگاه کند، نه فردی،

• و راه‌حل‌هایی ایجاد کند که مانع تکرار مشکل شود، نه فقط رفع ظاهری آن.

در این مقاله به صورت عمیق و قدم‌به‌قدم توضیح می‌دهیم:

• RCA چیست و چه چیزی نیست؟

• چرا برای تیم‌های نرم‌افزاری مدرن حیاتی است؟

• تکنیک‌ها، ابزارها و ساختار یک RCA حرفه‌ای چیست؟

• چطور جلسات Postmortem را بدون سرزنش برگزار کنیم؟

• مثال‌های عملی از یک RCA واقعی در سیستم نرم‌افزاری

• و در نهایت، چطور RCA را تبدیل به بخشی از فرهنگ تیم کنیم، نه یک کار تشریفاتی بعد از بحران.

بخش اول: Root Cause Analysis دقیقا چیست و چه چیزی نیست؟

۱.۱. تعریف ساده و کاربردی Root Cause

Root Cause Analysis یعنی تلاش سیستماتیک برای پاسخ به این پرسش:

کدام علتِ عمیق، اگر برطرف شود، احتمال رخ دادن دوباره‌ی این مشکل را به‌شکل معنی‌دار کاهش می‌دهد؟

چند نکته مهم در این تعریف وجود دارد:

• علت سطحی نیست: «دیسک پر شد» ریشه‌ی مشکل نیست، نتیجه‌ی مشکل است.

• ریشه همیشه یک چیز نیست: ممکن است چند علت باهم ترکیب شده باشند «فرآیند، ابزار، آدم‌ها، معماری».

• تمرکز روی جلوگیری از تکرار است، نه سرزنش فرد

۱.۲. RCA چه چیزی نیست؟

خیلی مهم است بدانیم RCA قرار نیست چه باشد:

• RCA جلسه‌ی پیدا کردن مقصر نیست.

  اگر جلسه به «کی این کار را خراب کرد؟» تبدیل شود، همه دفاعی می‌شوند و هیچ‌کس حقیقت را نمی‌گوید.

• RCA فقط یک گزارش بعد از بحران نیست.

  اگر فقط یک سند Word بسازیم و جایی آرشیو کنیم، ولی هیچ Action Item انجام نشود، RCA تاثیر واقعی ندارد.

• RCA فقط کاری برای تیم SRE/DevOps نیست.

  فرانت‌اند، بک‌اند، دیتابیس، محصول، QA، همه باید در این فرهنگ شریک باشند.

• RCA جایگزین دیباگ لحظه‌ای نیست.

  در لحظه بحران، اول باید سیستم را بالا بیاوری، سپس با حوصله RCA انجام دهی.

بخش دوم: چرا RCA برای تیم‌های نرم‌افزاری حیاتی است؟

۲.۱. کاهش هزینه‌های مخفی (Hidden Costs)

هر Incident (داون شدن، باگ بحرانی، خرابی داده) این هزینه‌ها را دارد:

• زمان مهندسان برای تشخیص و رفع مشکل

• استرس و فرسودگی تیم

• نارضایتی کاربران، ریزش مشتری، کاهش اعتماد

• تلفن‌ها، جلسه‌ها، هماهنگی‌های اضطراری

• فشار روی تیم فنی برای «هرچه سریع‌تر درستش کنید»

اگر این خطاها تکرار شوند، هزینه‌ها به‌صورت تصاعدی بالا می‌روند.

RCA کمک می‌کند:

• با چند اقدام ریشه‌ای، ده‌ها Incident مشابه در آینده رخ ندهد.

• به‌جای اینکه چندبار همان مشکل را حل کنیم، یک بار «علت اصلی» را اصلاح کنیم.

۲.۲. تبدیل فرهنگ سرزنش به فرهنگ یادگیری

بدون RCA:

• خطا = آبرو ریزی

• مهندس‌ها سعی می‌کنند مشکل را پنهان کنند یا کم‌اهمیت نشان دهند.

• مدیران به دنبال مقصر هستند.

با RCA درست:

• خطا = فرصت یادگیری سیستم

• تیم می‌پرسد «چطور سیستم را طوری طراحی کنیم که این اشتباه به پروداکشن نرسد؟»

• کسی از گفتن حقیقت نمی‌ترسد، چون قرار نیست تنبیه شود، هدف، بهبود سیستم است.

۲.۳. بلوغ معماری و فرآیندها در طول زمان

هر RCA خوب معمولا به این نوع اقدامات ختم می‌شود:

• افزودن تست‌های خودکار

• بهبود مانیتورینگ و هشدارها

• اصلاح فرآیند ریلیس (Release)

• استانداردهای کدنویسی

• بهبود Runbookها (مستندات رفع مشکل)

این اعمال کوچک در طول زمان باعث می‌شوند سیستم شما:

• قابل‌اعتمادتر،

• قابل‌تشخیص‌تر (Better Observable)،

• و کمتر وابسته به قهرمان‌بازی افراد خاص باشد.

بخش سوم: مراحل عملی اجرای یک RCA حرفه‌ای

برای اینکه RCA فقط یک شعار نباشد، باید آن را مانند یک فرآیند تکرارپذیر طراحی کنیم.

در ادامه یک فریم‌ورک چندمرحله‌ای معرفی می‌شود که می‌توانید در تیم خود پیاده کنید.

۳.۱. مرحله صفر: قبل از RCA – محیط را پایدار کن

وقتی Incident رخ می‌دهد، ترتیب منطقی کار این است:

1. Stabilize – سیستم را به وضعیت پایدار برگردان (Rollback، Hotfix، Failover و …).

2. Communicate – به ذینفعان (مدیران، محصول، پشتیبانی) بگو چه شده و چه کار می‌کنی.

3. Record – هر چیزی که الان می‌بینی (لاگ، اسکرین، رفتار عجیب) را ثبت کن، بعداً به درد می‌خورد.

4. Schedule RCA – حداکثر ظرف ۲۴–۷۲ ساعت بعد، یک جلسه رسمی RCA برنامه‌ریزی کن.

۳.۲. مرحله اول: توصیف Incident

یک Incident بدون توصیف شفاف، مبنای RCA خوبی نمی‌شود. در توصیف Incident به این موارد پاسخ دهید:

• چه اتفاقی افتاد؟ (در یک یا دو جمله واضح)

• چه زمانی شروع شد و چه زمانی پایان یافت؟

• Scope مشکل چه بود؟ (کدام سرویس‌ها، کدام کاربران)

• تأثیر روی کاربران چه بود؟ (مثلاً ۳۰٪ درخواست‌ها ۵۰۰ شدند، تراکنش‌ها Fail شدند و …)

• چگونه متوجه مشکل شدید؟ (Monitoring Alert، گزارش مشتری، تیم پشتیبانی و …)

مثال:

در تاریخ X، بین ساعت ۱۰:۱۲ تا ۱۰:۵۵، سرویس پرداخت در ۶۰٪ درخواست‌ها خطای ۵۰۰ برگرداند.

بخش عمده تراکنش‌های کاربران جدید Fail شد.

Incident ابتدا توسط هشدار نرخ خطای سرویس در گرافانا شناسایی شد.

۳.۳. مرحله دوم: ساختن Timeline دقیق

تایم لاین قلب یک RCA خوب است. باید قدم‌به‌قدم وقایع را ثبت کنید:

• چه اتفاقی در سیستم افتاد؟ (دپلویمنت، تغییر کانفیگ، افزایش ترافیک، مشکل شبکه)

• چه کسی چه کاری انجام داد؟ (آقای X فلان تغییر را دپلوی کرد، خانم Y رول‌بک کرد، و …)

• چه آلرت‌هایی آمدند و چه زمانی؟

• چه تصمیم‌هایی در جریان incident گرفته شد؟

چند نکته:

• زمان‌ها را با دقت ثبت کنید (ترجیحاً با تایم زون یکسان).

• از لاگ‌ها، تاریخچه گیت، هشدارها و ابزار مانیتورینگ برای بازسازی تایم لاین کمک بگیرید.

• تایم لاین باید آبجکتیو باشد، نه احساسی. «احساس کردیم همه‌چیز خراب شد» جمله‌ی خوبی نیست!

۳.۴. مرحله سوم: کشف علت‌ها – از «چه شد؟» به «چرا شد؟»

اینجا جایی است که ابزارهای RCA وارد بازی می‌شوند.

تکنیک ۵ چرا (5 Whys)

این روش ساده اما قوی است:

1. مشکل را بیان کن.

2. بپرس چرا؟

3. پاسخ را بنویس.

4. روی هر پاسخ دوباره چرا؟ بپرس.

5. این کار را تا ۵ بار (یا تا زمانی که به علت سیستمی و عمیق برسی) تکرار کن.

مثال کوتاه:

• مشکل: درگاه پرداخت از کار افتاد.

• چرا؟ چون پردازش درخواست‌ها Timeout می‌شد.

• چرا؟ چون یک کوئری روی جدول تراکنش‌ها بسیار کند بود.

• چرا؟ چون ایندکس مناسب نداشت.

• چرا؟ چون هنگام طراحی فیچر جدید، بررسی پرفورمنس دیتابیس انجام نشده بود.

• چرا؟ چون فرآیند تعریف فیچر الزام پرفورمنس ریویو ندارد.

اینجا ریشه مشکل «کمبود Index» نیست، بلکه نبود فرآیند پرفورمنس ریویو در چرخه توسعه است.

تکنیک Ishikawa (نمودار استخوان ماهی)

برای مسائل پیچیده‌تر، که چندین عامل دارند، نمودار Ishikawa کمک می‌کند از ابعاد مختلف فکر کنیم:

• People (آدم‌ها): آموزش ناکافی؟ خستگی؟ تجربه کم؟

• Process (فرآیند): نبود کد ریویو؟ تست نبود؟ معیار پذیرش تعریف نشده؟

• Technology (تکنولوژی): باگ در لایبرری؟ محدودیت دیتابیس؟ اسکیل نامناسب؟

• Tools (ابزارها): مانیتورینگ ناکافی؟ CI/CD ناقص؟

• Environment (محیط): افزایش ناگهانی ترافیک؟ وابستگی به سرویس بیرونی؟ مشکل دیتاسنتر؟

برای هر دسته سؤال بپرسید: «آیا در این دسته عاملی وجود دارد که به Incident کمک کرده باشد؟»

نکته مهم: ریشه معمولاً «یک نفر حواسش نبود» نیست

اگر در 5 Whys به جواب زیر رسیدید:

چون فلانی حواسش نبود / درست چک نکرد

یک «چرا» دیگر اضافه کنید:

• چرا فرآیند طوری طراحی شده که اگر یک نفر حواسش نباشد، سیستم به شدت Fail می‌شود؟

• چرا تست‌ها این را نگرفتند؟

• چرا کد ریویو این مشکل را ندید؟

• چرا مانیتورینگ زودتر خبر نداد؟

این «چرا»ها شما را از سرزنش فرد به سمت اصلاح سیستم می‌برد.

۳.۵. مرحله چهارم: دسته‌بندی علت‌ها

یک راه خوب برای سازمان‌دهی نتیجه RCA این است که علت‌ها را در ۳ دسته قرار دهید:

1. Technical Root Causes (علل فنی)

   • باگ در کد

   • مشکل معماری

   • ضعف در دیتابیس، کانفیگ، هندلینگ Error و …

2. Process Root Causes (علل فرآیندی)

   • نبود تست

   • نبود کد ریویو

   • ضعف در فرآیند ریلیس

   • نبود Checkpoint برای Performance/Scalability

3. Organizational / People Root Causes (علل سازمانی/انسانی)

   • حجم کار غیرواقعی

   • عدم هماهنگی بین تیم‌ها

   • اهداف غیرواقع‌بینانه (فشار زیاد ددلاین‌ها)

   • آموزش ناکافی

این دسته‌بندی کمک می‌کند که از یک Incident، فقط یک «باگ فنی» برداشت نکنید، بلکه پشت صحنه آن را هم ببینید.

۳.۶. مرحله پنجم: طراحی و اولویت‌بندی اقدامات (Action Items)

اگر RCA بدون Action Item تمام شود، عملاً هدر رفته است.

برای هر ریشه (Root Cause)، حداقل یک اقدام مشخص تعریف کنید:

• آیا باید تست E2E جدید اضافه شود؟

• آیا باید در CI/CD چک جدیدی اضافه شود؟

• آیا نیاز به تغییر معماری یا ریفکتور جدی وجود دارد؟

• آیا یک Runbook برای Incident مشابه لازم است؟

• آیا باید آموزش داخلی برگزار شود؟

هر Action Item باید:

• Owner داشته باشد (چه کسی مسئول اجرای آن است؟)

• ددلاین داشته باشد (تا کی انجام می‌شود؟)

• نوع آن مشخص باشد (کوتاه‌مدت، میان‌مدت، بلندمدت)

مثال Action Item:

• افزودن تست Integration روی مسیر تراکنش با حجم دیتای بالا – Owner: علی – ددلاین: ۱۰ روز

• اضافه کردن بخش «پرفورمنس ریویو» در Definition of Done فیچرهای مالی – Owner: سارا – ددلاین: دو هفته

• افزودن داشبورد مانیتورینگ خاص برای Latency کوئری‌های حیاتی – Owner: تیم DevOps – ددلاین: یک هفته

۳.۷. مرحله ششم: مستندسازی و اشتراک‌گذاری

گزارش RCA خوب:

• کوتاه و شفاف باشد؛

• اصطلاحات فنی لازم را داشته باشد اما قابل فهم برای محصول/مدیر هم باشد؛

• روی «حقایق و داده‌ها» استوار باشد، نه حدس و گمان.

ساختار پیشنهادی ریپورت:

1. خلاصه Incident

2. تأثیر (Impact)

3. تایم لاین

4. Root Causes (فنی/فرآیندی/سازمانی)

5. اقدامات کوتاه‌مدت (Hotfix/Mitigation)

6. اقدامات بلندمدت (Prevention)

7. درس‌های آموخته‌شده (Lessons Learned)

این گزارش را می‌توانید:

• در Wiki داخلی (کانفلوئنس، نوش، ویکی گیت لب و …) منتشر کنید،

• لینک آن را در کانال عمومی تیم به اشتراک بگذارید،

• در جلسه کوتاه برای بقیه تیم توضیح دهید.

بخش چهارم: چگونه جلسه Postmortem را «بدون سرزنش» اداره کنیم؟

اگر جلسه RCA به «محاکمه» تبدیل شود، کل مفهوم را از بین می‌برد.

چند اصل مهم:

۴.۱. قانون طلایی: Blameless Postmortem

در ابتدای جلسه صریح بگویید:

هدف این جلسه پیدا کردن مقصر نیست، هدف این است که سیستم را طوری بهتر طراحی کنیم که چنین مشکل‌هایی تکرار نشود.

و واقعاً هم به آن پایبند باشید. اگر مدیر وسط جلسه بپرسد:

خب اینجا دقیقا کی خراب کرده؟

همه از راست‌گویی می‌ترسند.

به جای این سؤال بپرسید:

• «چه چیزی در سیستم/فرآیند باید تغییر می‌کرد که این خطا رخ ندهد؟»

۴.۲. فضا را امن کنید

• کسی را وسط جلسه تحقیر نکنید.

• شوخی‌های تمسخرآمیز ممنوع.

• اگر کسی اشتباهش را می‌پذیرد، او را تشویق کنید؛ این شجاعت است.

۴.۳. جلسه را با ساختار پیش ببرید

یک Facilitator (تسهیل‌گر) داشته باشید که جلسه را به ترتیب زیر جلو ببرد:

1. توصیف Incident

2. مرور تایم لاین

3. بحث روی علت‌ها

4. تعریف Action Itemها

5. جمع‌بندی

اگر بحث‌ها شخصی شد، Facilitator باید بحث را به سمت سیستم برگرداند.

۴.۴. از داده به جای احساس استفاده کنید

به‌جای «فکر کنم ترافیک خیلی بالا بود»، بگویید:

• CPU روی ۹۵٪ رفت

• QPS از میانگین ۳۰۰ به ۸۰۰ رسید

• Latency متوسط از ۲۰۰ میلی ثانیه به ۱۵۰۰ میلی ثانیه رسید

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

بخش پنجم: مثال عملی از یک RCA در سیستم نرم‌افزاری

بیایید یک مثال نسبتاً واقعی را گام‌به‌گام طی کنیم.

۵.۱. شرح Incident

• سیستم: پلتفرم سفارش آنلاین غذا

• مشکل: در ساعت ۲۰ تا ۲۱ شب، بخش زیادی از سفارش‌ها در مرحله پرداخت Fail شدند.

• تأثیر: تقریبا ۴۵٪ سفارش‌ها در این بازه زمانی موفق نبودند.

• آشکار شدن مشکل: تیم پشتیبانی از افزایش ناگهانی تماس‌های کاربران شکایت داشت، و هم‌زمان داشبورد خطای سرویس پرداخت در گرافانا هشدار داد.

۵.۲. Timeline خلاصه‌شده

• ۱۹:۵۵ – شروع پیک ترافیک (شام)

• ۲۰:۰۵ – اولین افزایش غیرعادی در Error Rate پرداخت

• ۲۰:۱۰ – آلارم در گرافانا فعال شد

• ۲۰:۱۵ – مهندس On-Call وارد سیستم شد، لاگ‌ها را بررسی کرد

• ۲۰:۲۰ – متوجه شد همه خطاها از یک نوع هستند: Timeout در سرویس Payment Gateway

• ۲۰:۲۵ – تصمیم به Rollback به نسخه قبلی سرویس Payment Adapter

• ۲۰:۳۵ – Rollback کامل شد، Error Rate به حالت نرمال برگشت

• ۲۰:۴۵ – Incident خاتمه یافت

۵.۳. اجرای 5 Whys

• چرا سفارش‌ها Fail شدند؟

  چون سرویس Payment Adapter در بسیاری از درخواست‌ها Timeout شد.

• چرا Timeout شد؟

  چون اتصال به Payment Gateway در برخی درخواست‌ها بسیار کند بود و پاسخ به موقع نمی‌رسید.

• چرا سیستم ما نتوانست این کندی را مدیریت کند؟

  چون Retry Logic و Circuit Breaker به‌درستی تنظیم نشده بود، و برای هر درخواست، تا آخرین لحظه صبر می‌کرد.

• چرا Retry و Circuit Breaker درست تنظیم نشده بودند؟

  چون این سرویس جدید بود و برای پرداخت با این Gateway خاص، تست Load واقعی انجام نشده بود.

• چرا تست Load واقعی انجام نشده بود؟

  چون در فرآیند ریلیس فیچرهای جدید پرداخت، تست Performance/Load به‌عنوان الزام تعریف نشده بود و فقط تست‌های Functional انجام شده بود.

Root Cause: نبود الزام تست پرفورمنس در ریلیس فیچرهای مربوط به پرداخت، به‌عنوان بخشی از فرآیند توسعه.

۵.۴. Action Itemهای ممکن

• اضافه کردن تست پرفورمنس اجباری برای فیچرهای پرداخت.

• تنظیم مناسب Timeout، Retry، Circuit Breaker در Payment Adapter.

• ایجاد داشبورد اختصاصی برای Latency تعامل با Payment Gateway.

• مستندسازی بهترین تنظیمات برای Gatewayهای مختلف.

• اضافه کردن Chaos Testing در محیط استیج برای بررسی رفتار در کندی/عدم پاسخ‌دهی Gateway.

این‌ها اقداماتی هستند که احتمال رخ دادن Incident مشابه را در آینده به‌شدت کاهش می‌دهند.

بخش ششم: چالش‌های واقعی در پیاده‌سازی RCA و راه‌حل‌ها

پیاده‌سازی RCA در یک شرکت واقعی، همیشه مثل کتاب‌ها تمیز و ساده نیست. چند چالش معمول:

۶.۱. وقت نداریم RCA کنیم

مدیران می‌گویند:

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

راه‌حل:

• نشان بدهید که چند Incident اخیر، چقدر زمان تیم را گرفته‌اند.

• مقایسه کنید: ۲ ساعت RCA در برابر ۲۰ ساعت آتش‌نشانی تکراری در ماه‌های بعد.

• RCA را برای Incidentهای مهم (با Impact بالا) الزامی کنید، نه برای هر باگ کوچک.

۶.۲. مقاومت در برابر شفافیت

برخی تیم‌ها یا افراد می‌ترسند واقعیت را بگویند:

اگر بگم من این تغییر را بدون تست دپلوی کردم، ممکنه مواخذه بشم.

راه‌حل:

• فرهنگ Blameless را از بالا حمایت کنید (CTO/مدیر باید این را جدی بگوید و عمل کند).

• اگر کسی اشتباه خود را شفاف گفت، او را تشویق کنید؛ نه تنبیه.

• به مرور زمان، اعتماد ساخته می‌شود.

۶.۳. تبدیل RCA به فرمالیته (صرفاً گزارش پر کردن)

بعضی شرکت‌ها به اجبار، فرم RCA پر می‌کنند، اما:

• Action واقعی انجام نمی‌دهند؛

• یا کسی پیگیر Action Itemها نیست.

راه‌حل:

• تعداد Actionها را کم اما با کیفیت انتخاب کنید.

• برای هر Action، Owner و Deadline واقعی بگذارید.

• در جلسه‌های بعدی، حتماً وضعیت انجام Actionها را چک کنید.

۶.۴. تقابل کوتاه‌مدت و بلندمدت

همیشه یک کشمکش بین:

• «سریع Fix کن تا امروز راحت شویم»

• «سیستمی Fix کن تا فردا راحت باشیم»

وجود دارد.

راه‌حل:

هر Incident را به دو بخش تقسیم کنید:

• Mitigation/Hack کوتاه‌مدت برای برگرداندن سرویس

• Prevention بلندمدت برای جلوگیری از تکرار

در گزارش RCA، این دو را واضح جدا کنید.

بخش هفتم: ابزارها و تکنیک‌های کمکی در RCA برای تیم‌های فنی

بدون ابزارهای مناسب، RCA می‌تواند تبدیل به حدس و گمان شود.

۷.۱. مانیتورینگ و متریک‌ها

ابزارهایی مانند:

• Prometheus + Grafana

• Datadog

• New Relic

• CloudWatch و …

به شما کمک می‌کنند:

• CPU, Memory, Latency, Error Rate و … را ببینید،

• Threshold و Alert تعریف کنید،

• روند تغییرات را قبل و بعد Incident بررسی کنید.

۷.۲. Logging متمرکز

ابزارهایی مثل:

• ELK Stack (Elasticsearch, Logstash, Kibana)

• Graylog

• Loki

• Splunk

امکان می‌دهند:

• لاگ‌ها را در سطح سیستم جمع کنید؛

• براساس Request ID یا Trace ID، یک جریان کامل درخواست را دنبال کنید؛

• Queryهای پیچیده روی لاگ‌ها اجرا کنید.

۷.۳. Tracing توزیع‌شده (Distributed Tracing)

در معماری میکروسرویس، بدون Tracing، RCA بسیار سخت می‌شود.

ابزارهایی مثل:

• Jaeger

• Zipkin

• OpenTelemetry

کمک می‌کنند:

• ببینید یک ریکوئست از کدام سرویس‌ها عبور کرده،

• کجا بیشترین زمان صرف شده،

• کجا Errors رخ داده است.

۷.۴. Chaos Engineering (برای تیم‌های بالغ‌تر)

تست عمدی خطا در سیستم (قطع کردن سرویس، بالا بردن Latency، قطع دیتابیس و …) برای:

• بررسی رفتار سیستم در شرایط واقعی

• کشف نقاط ضعف قبل از پروداکشن

اگرچه این سطح برای همه تیم‌ها مناسب نیست، اما در بلندمدت، فهم شما از سیستم را بسیار بالا می‌برد و کیفیت RCA را بهتر می‌کند.

بخش هشتم: تبدیل RCA به بخشی از DNA سازمان

RCA باید از «یک کار اضافی» به «بخشی از کار عادی تیم» تبدیل شود. برای این کار:

۸.۱. سیاست رسمی تعریف کنید

مثلاً:

• برای هر Incident با Impact بالا، ظرف ۷۲ ساعت باید یک RCA انجام و مستند شود.

• نتیجه RCA باید در یک کانال مشخص (اسلک/تلگرام/مترموست) به اشتراک گذاشته شود.

• Action Itemها باید در Backlog تیم وارد شوند و وضعیت آن‌ها قابل ردیابی باشد.

۸.۲. موفقیت‌ها را جشن بگیرید

وقتی:

• یک Incident مشابه به خاطر Action RCA قبلی رخ نداد،

• یا تیم در RCA یک نقطه ضعف مهم را کشف کرد و اصلاح کرد،

این را در تیم مطرح کنید.

به این شکل، RCA از دید تیم تبدیل می‌شود به:

کاری که واقعاً فرق ایجاد می‌کند.

۸.۳. آموزش و انتقال دانش

• برای اعضای جدید، یک یا دو نمونه RCA خوب را در Onboarding بگنجانید.

• گاهی یک جلسه داخلی برای مرور چند RCA قدیمی و درس‌های آموخته‌شده برگزار کنید.

• تشویق کنید اعضای تیم خودشان RCA بنویسند و ارائه کنند.

جمع‌بندی: از واکنش به طراحی

Root Cause Analysis یعنی حرکت از مدل:

وقتی خراب شد، درستش می‌کنیم.

به مدل:

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

در این مقاله دیدیم که:

• RCA فقط یک تکنیک نیست؛ یک طرز فکر سیستمی است.

• هدف اصلی، جلوگیری از تکرار خطاست، نه پیدا کردن مقصر.

• با ابزارهایی مانند 5 Whys، Ishikawa، مانیتورینگ، لاگ‌گذاری و Tracing می‌توان RCA را عملی و علمی کرد.

• جلسات Postmortem اگر Blameless باشند، هم سیستم را بهتر می‌کنند، هم تیم را.

• وقتی RCA تبدیل به بخشی از فرهنگ سازمان شود، کیفیت، سرعت توسعه و آرامش تیم هم‌زمان افزایش پیدا می‌کند.

اگر در تیم شما هر چند هفته یک‌بار Incident تکراری دارید، شاید وقتش است به جای یک چسب‌زخم دیگر، یک RCA جدی انجام دهید.

برای شروع می‌توانید جدولی با ستون‌های زیر در اکسل، کانفلوئنس، نوشن یا ... ایجاد کنید و ریشه‌یابی مشکلات را شروع کنید:

• ماژول: این مشکل در کدام ماژول یا سرویس رخ داده

• تاریخ: تاریخ ثبت مشکل را بنویسید

• ریزالور: کسی که مشکل را برطرف کرده و راه حل ارائه داده

• ایشو: مشکل چیست؟

• تصویر: در صورت نیاز تصویری از مشکل یا ارور قرار دهید (در کانفلوئنس تصویر تامبنیل می‌تواند قرار گیرد یا لینک تصویر آپلود شده در بعضی نرم افزارها مثل اکسل)

• راه حل: راه حل رفع مشکل را به صورت گام به گام نوشته

• علت: علت وقوع مشکل چیست؟