تحلیل علل ریشهای (RCA)
تحلیل علل ریشهای (RCA) تحلیل علل ریشهای (RCA) چیست؟ تحلیل علل ریشهای (RCA) یک رویکرد سیستماتیک است که برای شناسایی علت اصلی یک حادثه به عمق مسئله میرود، با پرسیدن سوالهای مکرر «چرا» تا زمانی که دیگر پاسخهای تشخیصی قابل ارائه نباشد. این تحلیل معمولاً بلافاصله پس از وقوع حادثه انجام میشود. یک منبع اضافی، سند وضعیت حادثه، بهعنوان یک رکورد مکتوب از آنچه که قبل و حین حادثه رخ داده، عمل میکند و به سوالات لازم برای انجام تحلیل علل ریشهای پاسخ میدهد.
سند وضعیت حادثه که بهعنوان گزارش حادثه نیز شناخته میشود، بهترین نقطه شروع برای تحلیل علل ریشهای است. با این حال، مهم است که فراتر از آنچه که فرم بیان میکند، عمیقتر کاوش کنیم. در Zoho، ما از طریق ابزار ITSM خود، یک رکورد مشکل از بلیط حادثه ایجاد میکنیم تا RCA کاملی انجام دهیم.
چرا تحلیل علل ریشهای انجام دهیم؟ در Zoho، ما هیچگاه بحران خوب را هدر نمیدهیم. ما یک رویداد ناخوشایند را بهعنوان فرصتی برای یادگیری از اشتباهاتمان، شناسایی نقاط ضعف در فرآیندها یا سیستمها، و آمادهتر شدن برای مقابله با حوادث مشابه در آینده میبینیم.
اصول RCA RCA برای تعیین عواملی که منجر به حادثه شدهاند و انجام اقدامات اصلاحی بهجای درمان فقط علائم انجام میشود. یک RCA موفق بهطور سیستماتیک انجام میشود و نتایج آن با شواهد واقعی پشتیبانی میشود. اغلب، بیش از یک علت ریشهای برای یک حادثه وجود دارد. «اگر اشتباه نمیکنید، پس هیچ کاری نمیکنید.» در Zoho، ما به یادگیری از اشتباهاتمان اعتقاد داریم. داشتن یک فرآیند RCA «بدون سرزنش» به کارکنان و تیمها این امکان را میدهد تا جزئیات دقیق رویکرد خود، مانند اقداماتی که انجام دادهاند و فرضیاتی که در هنگام مدیریت حادثه داشتهاند، بیان کنند.
فرآیند RCA اقدامات اصلاحی و پیشگیرانه (CAPA) رویکرد ساختاریافته ما برای بررسی، شناسایی علت ریشهای، انجام اقدام اصلاحی و جلوگیری از تکرار علتهای ریشهای است.
فرآیند RCA در اینجا اقداماتی که مدیر حادثه در طول RCA انجام میدهد آورده شده است:
ایجاد: از بلیط حادثه یک رکورد مشکل ایجاد میکند تا RCA انجام دهد.
بررسی: اطلاعات موجود در سند وضعیت حادثه بهعنوان پایهای برای انجام RCA استفاده میشود. مدیر حادثه بخشها و فرآیندهای مرتبط با CAPA را شناسایی کرده و یک بررسی کامل انجام میدهد. در طول فرآیند RCA، ما دروس میآموزیم و فرصتهایی برای بهبود پیدا میکنیم. سوالات زیر را برای رسیدن به نتیجه میپرسیم.
مرحله سوالات مورد استفاده خلاصه حادثه
مرحله | سوالات | مورد استفاده | خلاصه حادثه |
---|---|---|---|
خلاصه حادثه | حادثه در چه زمانی شناسایی شد؟ (تاریخ و زمان حادثه) | این حادثه در تاریخ ۲۲ ژانویه ۲۰۱۹ ساعت ۱۵:۳۱ به وقت IST رخ داد و در ساعت ۱۵:۵۲ همان روز خاتمه یافت. | این مشکل بر سرویسهای Zoho CRM و Zoho Mail تاثیر گذاشت. علت اصلی این بود که سرورهای Zoho Accounts فعال بودند اما نمیتوانستند درخواستها را پردازش کنند که باعث مشکلات دسترسی شد. |
حادثه در کجا رخ داده است؟ (محل حادثه، شبکه، سرور، محصول و دیگر موارد) | سرورهای Zoho Accounts تحت تاثیر قرار گرفتند که بر سرویسهای Zoho CRM و Zoho Mail تاثیر گذاشت. | ||
نوع حادثه چیست؟ (خطا/مشکل گزارششده) | این حادثه به دلیل مشکلات دسترسی در Zoho CRM و Zoho Mail بود. | ||
مشکل واقعی چیست و چه اتفاقی در حال رخ دادن است؟ (مشاهدات تیمهای درگیر) | تیمها مشاهده کردند که سرورهای Zoho Accounts فعال بودند اما نمیتوانستند درخواستها را پردازش کنند. | ||
طرفهای متاثر (سهامداران، مشتریان یا هر دو) | مشتریان استفادهکننده از Zoho CRM و Zoho Mail تحت تاثیر قرار گرفتند. | ||
بیانیه علت اصلی | بیانیه علت اصلی: سرورهای Zoho Accounts فعال بودند اما نمیتوانستند درخواستها را پردازش کنند که باعث مشکلات دسترسی در Zoho CRM و Zoho Mail شد. | ||
تاثیر | مدت زمان تاثیر چقدر بود و چگونه رفع شد؟ | مدت زمان خرابی ۲۱ دقیقه بود. مشکل با حذف ورودی سرویس باعثکننده مشکل رفع شد. | |
مشتریان چه چیزی مشاهده کردند؟ | مشتریان نتواستند به سرویسهای Zoho CRM و Zoho Mail دسترسی پیدا کنند. | ||
چند نفر درگیر یا متاثر شدند؟ (مثلاً مشتریان یک مجموعه یا محصول) | مشتریان Zoho CRM و Zoho Mail تحت تاثیر قرار گرفتند. | ||
چند تیکت پشتیبانی ثبت شد؟ | ۲۰ تیکت پشتیبانی از طریق تماس تلفنی، ایمیل و چت ثبت شد. | ||
پاسخ | چه کسی پاسخ داد و چه زمانی؟ | مشتریان حادثه را شناسایی کردند و تیمهای هماهنگی حادثه Zoho CRM و Zoho Mail پاسخ دادند. | |
زمان پاسخ چقدر بود؟ | زمان پاسخگویی ۱۵ دقیقه بود و یک راهحل موقت ارائه شد. | ||
بازیابی | چگونه سرویس بازگردانی شد؟ | مشکل با حذف ورودی سرویس باعثکننده مشکل در عرض ۱۵ دقیقه پس از بروز حادثه رفع شد. | |
چه شگفتیهایی تیمهای حلکننده با آن مواجه شدند؟ | مکانیزم مرتبسازی سرویسها مشکلساز شد. | ||
چه شرایطی پیشبینی نشده بود؟ | مکانیزم مرتبسازی سرویسها دیگر نیازی نداشت و در بهروزرسانی حذف شد. | ||
آیا راهحلها یا راهبرگهای مفیدی در زمان بحران پیدا شد؟ | راهحلهای موقت بلافاصله اعمال شدند تا دسترسی به سرویسها بازیابی شود. | ||
جدول زمانی | جدول زمانی دقیق حادثه به ترتیب زمانی، با ذکر زمانمنطقه | ||
۲۲ ژانویه ۲۰۱۹ ساعت ۱۵:۲۷ IST: ورودی سرویس جدید به حسابها اضافه شد. | |||
۲۲ ژانویه ۲۰۱۹ ساعت ۱۵:۳۰ IST: پیکربندیهای Zoho Accounts برای بازتاب ورودی جدید پاک شدند. | |||
۲۲ ژانویه ۲۰۱۹ ساعت ۱۵:۳۱ IST: سرورهای Zoho Accounts خراب شدند و دسترسی به سرویسها امکانپذیر نبود. | |||
۲۲ ژانویه ۲۰۱۹ ساعت ۱۵:۵۱ IST: راهحل موقت در ۲۰ دقیقه اعمال شد. | |||
۲۲ ژانویه ۲۰۱۹ ساعت ۱۵:۵۲ IST: Zoho Accounts به حالت پایدار برگشت و سرویسها قابل دسترسی شدند. | |||
درسهای آموختهشده | چه کاری میتوان انجام داد تا این نوع حادثه مجدداً رخ ندهد؟ | الگوریتم مرتبسازی سرویسها حذف شد تا از بروز مشکلات مشابه در آینده جلوگیری شود. | |
اگر قرار بود دوباره این کار را انجام دهیم، چه کاری را متفاوت انجام میدادیم؟ | عملکردهای غیرضروری از کد پایه حذف شد تا از بروز توقفهای مشابه جلوگیری شود. |
تحلیل علت ریشهای (RCA)
مدیر حادثه از تکنیک "۵ چرا" برای تعیین علت ریشهای حوادث استفاده میکند که شامل پرسیدن مکرر سوال "چرا؟" تا زمانی که علت ریشهای شناسایی شود. هدف این است که به جای سرزنش، دلیل وقوع حادثه در ابتدا کشف شود.
تحلیل علت ریشهای
نکته: گاهی اوقات ممکن است با سه سوال "چرا؟" علت ریشهای شناسایی شود؛ در اغلب مواقع به سوالات بیشتری نیاز است. هنر پرسیدن سوالات نیاز به زمان دارد، اما هنگامی که سوالات صحیح پرسیده شوند، علت ریشهای به سرعت شناسایی میشود. در این مورد، علت ریشهای با سه سوال شناسایی شد.
اقدامات اصلاحی و پیشگیرانه (CAPA)
به طور ساده، اقدامات اصلاحی بر اساس یک رویداد منفی که در گذشته رخ داده است، و اقدامات پیشگیرانه بر اساس جلوگیری از وقوع یک رویداد منفی در آینده است. اقدامات اصلاحی و پیشگیرانه (CAPA) بخشهای ضروری از فرآیند بهبود مستمر ما هستند.
موفقیت RCA نیاز به مدیریت دقیق برنامه اقدام دارد. بنابراین مرحله بعدی فرآیند RCA، تدوین یک برنامه اقدام پیشنهادی است که لیست اقدامات اصلاحی و پیشگیرانه را تعریف میکند. برنامه اقدام باید چارچوب زمانی برای تکمیل اقدامات و مسئول هر کار را مشخص کند.
چکلیست ما برای اطمینان از یک برنامه اقدام سیستماتیک:
- آیا اقدامات اصلاحی که در تحلیل پشتیبانی نمیشوند، وجود دارند؟
- آیا اقدامات اصلاحی واضح و مناسب برای علت هستند؟ آیا اقدامات اصلاحی بر اساس اولویت در لیست قرار دارند؟
- اگر شخص ثالثی درگیر است، آیا اقلام اقدام در چارچوب زمانی مشخص تحویل خواهند شد؟
- آیا اقدامات اصلاحی ممکن است منجر به عواقب ناخواسته شوند؟
- آیا اقدامات اصلاحی تحت کنترل مدیریت هستند؟ آیا اقدامات اصلاحی احتمال تکرار را کاهش میدهند؟
- آیا صاحب بخش/عملیات موافقت کرده است که اقدام اصلاحی را انجام دهد؟
- آیا هر اقدام اصلاحی صاحب واضح و تاریخ انجام دارد؟
فرآیند اقدامات پیشگیرانه شامل ساختن حفاظتها و تغییرات فرآیند برای جلوگیری از ناهماهنگی است. به عنوان یک اقدام پیشگیرانه، ما:
- فرآیندها و خدمات را برای شناسایی روندهای منفی که میتواند منجر به حادثه شود، تحلیل میکنیم.
- تحلیل ریسک برای شناسایی خطرات نهفته انجام میدهیم.
- برنامههای آموزشی برای تقویت مهارتهای کارکنان و آمادهسازی بهتر آنها در هنگام حادثه برگزار میکنیم.
- برنامههای بازیابی بحران، امنیت و موارد اضطراری را برای موقعیتهای بحران غیرقابل پیشبینی معرفی میکنیم.
- نگهداری پیشگیرانه را برای اطمینان از اینکه خدمات ما همیشه ایمن، در دسترس و بهینه عمل میکنند، راهاندازی میکنیم.
- ممیزیها را برای کمک به سادهسازی فرآیندها و ارائه خدمات با کیفیت انجام میدهیم.
بررسی
در نهایت، RCA برای تأیید تغییرات و جلوگیری از مشکلات تکراری به مدیریت ارجاع میشود. مدیر حادثه پیگیریهای دقیقی با گروههای حلکننده ترتیب میدهد تا اطمینان حاصل شود که گامهای اصلاحی مؤثر هستند و از تکرار جلوگیری شده است.
چکلیست زیر میتواند توسط تمام تیمهای IT برای ارزیابی کیفیت کلی برنامه پاسخ به حادثه استفاده شود:
- آیا برنامه پاسخ به حادثه به حل حادثه کمک کرد یا سازمان به فعالیتهای "خارج از برنامه" تکیه کرد؟
- آیا یک سند خلاصه واضح برای درک سریع حادثه وجود دارد؟
- آیا تحلیل کل حادثه بر اساس واقعیت است؟
- آیا معماری IT به اندازه کافی قوی بود تا تأثیر بین سیستمهای داخلی را محدود کند؟
- چطور تیمهای مرتبط مانند HR، حقوقی، محصول و غیره در ارزیابی و ارتباطات مشارکت کردند؟
- آیا سیاست و روشهای حفاظت از دادهها برای شناسایی و اولویتبندی دادههای حیاتی کافی بودند؟
- آیا برنامه ارتباطی مؤثر بود؟
- آیا ما به اندازه کافی "چرا" پرسیدیم تا علت ریشهای را تعیین کنیم؟
- آیا ارتباط واضحی بین واقعیتها، علل و اقدامات اصلاحی وجود دارد؟
- آیا تحلیل مشخص کرد که حادثه قبلاً رخ داده است؟
- آیا حلکنندگان زودتر برای مدیریت این نوع حادثه شناسایی شدند یا بعداً بر اساس دانششان جذب شدند؟
- آیا ریسکهای سازمان ارزیابی و مدیریت شدند؟
- آیا RCA از مکانیسم تأیید عبور کرده است؟
جلسات RCA
ما جلسات RCA برگزار میکنیم تا به عمق موضوع پی ببریم، اقدامات اصلاحی لازم را برای رفع دائمی مشکل انجام دهیم و اقدامات پیشگیرانه اتخاذ کنیم. مهمترین راهنمایی برای جلسات RCA ما این است که یاد بگیریم و به طور مستمر بهبود پیدا کنیم، نه اینکه سرزنش کنیم یا خالی کنیم.
نکات برای برگزاری یک جلسه RCA مؤثر:
- تاریخ و زمانی را انتخاب کنید که برای تمام شرکتکنندگان جلسه مناسب باشد، با توجه به تیمهایی که شیفتی کار میکنند و تیمهای توزیعشده.
- یک دستور جلسه تنظیم کنید و به آن پایبند باشید که از دو ساعت بیشتر نشود.
- یک اتاق کنفرانس/جلسه با صندلی کافی برای تمام گروههای حلکننده، ذینفعان و مدیریت ارشد رزرو کنید.
- یک یا دو روز قبل از جلسه RCA، شرکتکنندگان را از طریق تقویم Zoho دعوت کنید، اهمیت جلسه را تأکید کنید و دستور جلسه را شامل کنید.
- یک رکورد کتبی از مدت زمان جلسه داشته باشید.
فرآیندهای مدیریت حادثه به منظور محافظت از سازمانها در برابر رویدادهای منفی طراحی شدهاند. این امر به ویژه برای سازمانهایی مانند Zoho که به شدت به اینترنت و شبکههای کامپیوتری وابسته هستند و با حجم زیادی از دادههای شخصی سر و کار دارند، صادق است.
یک سیاست مؤثر پاسخ به حادثه بر چهار جنبه کلیدی تمرکز دارد: مدیریت ریسک، ممیزیهای منظم، اقدامات پیشگیرانه و مهمتر از همه، آموزش کارکنان. در Zoho، ما افراد، فرآیندها و ابزارهای لازم را برای پیشی گرفتن از حملات سایبری آینده داریم.
اکنون که دیدید Zoho چگونه با حوادث برخورد میکند، امیدواریم سازمان شما بتواند یک استراتژی مشابه با توجه به عملیات کسب و کار، نیروی کار و فرهنگ سازمانی خود طراحی و پیگیری کند.