ما المقصود بتحليل السبب الجذري (RCA)؟

توضيح المشكلة

استخدم طريقة rubber duck approach‏ (rubber-duck debugging) لتوضح المشكلة ببساطة. عند توضيح أي شيء، ينبغي لك ترتيب أفكارك. Jeff Atwood، أحد مؤسسي موقع الأسئلة والأجوبة الشهير Stack Overflow، يتحدث عن عدد المرات التي يخبره مطور برمجيات حول كتابة سؤال جديد على الموقع، واكتشاف الإجابة بنفسه أثناء العملية، وعدم إرسال السؤال إلى الموقع.

استخدم الوسائل التالية لمساعدتك في التعبير عن المشكلة ببساطة:

1. اكتب سؤالاً على موقع Stack Overflow، حتى وإن لم ترسله مطلقًا.
2. قدم تقريرًا مفصلًا عن الخطأ.
3. اشرح المشكلة لأحد زملاء العمل.

اجمع بيانات السجل (وابحث فيها بشكل فعّال)

بعد ذلك، اجمع المزيد من البيانات حول المشكلة واستخرج منها الرؤى والأفكار. يساعد التسجيل والمراقبة في هذا الأمر؛ أي سجلات الأعطال وسجلات التطبيقات وسجلات الخوادم إلخ. عليك جمع الأدلة على حدوث المشكلة، لكن أيضًا عليك اكتشاف منذ متى تحدث وما معدل تكرارها.

من كل تلك البيانات، تحتاج إلى العثور سريعًا على نقاط بيانات محددة. يمكن أن تساعدك الأدوات في البحث في بيانات السجلات التي كنت تجمعها وتحليلها وتحويلها إلى رؤى وأفكار لتشخيص المشكلات وحلها بسرعة أكبر.

استخدم طريقة الأسباب الخمسة

بعد ذلك، حدد العوامل المسببة، أي السبب المباشر في المشكلة التي تواجهها. لا تقم بتحديد عامل مسبب واحد ثم تتوقف. بل يجب عليك أن تواصل البحث عن طريق تقنية الأسباب الخمسة. كرر السؤال "لماذا؟" حتى تصل إلى أصل المشكلة. على سبيل المثال، يعرض موقعك الإلكتروني الخطأ 500.

1. لماذا؟ لأن مُكون توجيه الإطار العام للشبكة مُعطل.
2. لماذا؟ لأنه يتطلب وجود مُكون آخر هو أيضًا مُعطل.
3. لماذا؟ لأن مُكون الإطار العام للشبكة هذا يتطلب امتداد intl، الذي لا يعمل.
4. لماذا؟ لأنه تم إلغاء تنشيطه بالخطأ بعد تحديث برمجيات الخادم.

ستصل بالطبع إلى المشكلة الجذرية بخطوات أقل. أو قد تحتاج إلى خطوات أكثر.

المراجعة من شخص آخر

مثل مراجعة التعليمة البرمجية، اطلب من شخص آخر غير متحيز إلقاء نظرة على التعليمة البرمجية. مع مرور الوقت، يساعدك توقع المراجعة في تحسين عمليتك. أو الأفضل من ذلك، اجعل عملية استكشاف الأخطاء وإصلاحها عمليةً ثنائيةً.