بين عالم الطيران وهندسة البرمجيات - مخطط PIOSEE لإتخاذ القرارات في الأوقات الحرجه

المقدمه

السلام عليكم ورحمة الله وبركاته, مرحبًا بك مُجددًا عزيزي القارئ الجميل في مقالٍ آخر جديد, وفي هذا المقال سنتطرق إلى موضوع جدًا مهم ومُثير للإهتمام, ألا وهو كما رأيت بالعنوان عن إحدى مخططات إتخاذ القرار “Decision Making Model” ويدعى “PIOSEE” وسوف أشرح عن ما معناه؟ ولماذا نحتاج لتوظيف مخطط مثله في عملنا كمهندسي برمجيات وDevOps وسيناريوهات حوادث تقنيه يُمكن إستخدمه فيها, بسم الله نبدأ.

مخططات إتخاذ القرار وفاعليتها في حالات الطوارئ

هل تساءلت يومًا كيف يتصرف الطيار حين يُحدق فيه خطرٌ مفاجئ على ارتفاع ثلاثين ألف قدم, وتحته بحرٌ لا يرحم أو جبالٌ شامخه؟ لا يتصرف بعشوائية, ولا يتجمّد من الخوف, بل يُطبق في لحظاتٍ معدودة مخططًا محددًا يأخذ بيده خطوةً بخطوه نحو القرار الصحيح.

هذا بالضبط ما تُقدمه مخططات إتخاذ القرار, فهي ليست مجرد نظرية أكاديمية تُحفظ وتُنسى, بل هي أدواتٌ عملية تُدرَب عليها الكوادر في القطاعات الأكثر حساسيه كالطيران والطب العسكري والاستجابة للكوارث. الفكرة الجوهريه هي بسيطه: حين يتصاعد الضغط ويضيق الوقت, يُصبح العقل البشري عرضةً للأخطاء المعرفيه والتحيزات, ومخططٌ واضح الخطوات يكون بمثابة حارسٍ يُبقيك على المسار الصحيح.

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

مامعنى PIOSEE وكيف يمكننا توظيفه في هندسة البرمجيات؟

مخطط PIOSEE هو اختصارٌ لستة مراحل متسلسله تشكل معًا منهجيةً متكامله لإتخاذ القرار في الأوقات الحرجه, وُلدت في عالم الطيران ثم ثبت أن روحها تنطبق على كل ميدانٍ يتطلب تفكيرًا سريعًا تحت الضغط. إليك المراحل الست وكيف تبدو:

• المشكلة (P - Problem): حدد المشكله بوضوح تام قبل أي شيءٍ آخر.

• المعلومات (I - Information): اجمع كل البيانات المتاحة, سجلات الـlogs, مقاييس الـmonitoring, آخر عملية نشر deployment, أي تغيير طرأ على البنية التحتيه. لا تفترض شيئًا قبل أن تجمع البيانات وتحللها.

• الخيارات (O - Options): ضع أمامك كل الحلول الممكنه دون إقصاءٍ مبكر, هل نُعيد آخر نشر؟ هل نُوسع الـinstances؟ هل نُفعل خطة الـrollback؟ هل نُحول الحمل لبيئةٍ بديله؟

• الاختيار (S - Select): الآن فقط قيم كل خيار بناءً على الوقت والمخاطر والتأثير على المستخدمين, واختر الأنسب. حيث ان الحل الأسرع ليس دائمًا الأفضل تذكر ذلك.

• التنفيذ (E - Execute): نفذ القرار بتنسيقٍ واضح مع فريقك, من يفعل ماذا؟ من يُبلغ العملاء؟ من يُراقب التأثير؟ لا مجال للارتجال هنا.

• التقييم (E - Evaluate): بعد التنفيذ لا تُغلق ملف المشكله, راقب النتائج, هل حُلت المشكلة فعلًا؟ هل ظهرت آثارٌ جانبيه؟ وهل تحتاج للتدخل مُجددًا؟

أمثله على سيناريوهات يمكن فيها إستخدام مخطط PIOSEE

دعنا نُجسد الأمر بأمثلةٍ حقيقيه تمسُ يومياتنا كمهندسي برمجيات وDevOps, وسنُطبق المخطط خطوةً بخطوة حتى ترى كيف يتحول من مجرد نظريه إلى أداةٍ عمليه تُنقذك في أحلك اللحظات.

السيناريو الأول - انهيار قاعدة البيانات في بيئة الإنتاج

منتصف الليل, وفجأةً تتدفق عليك تنبيهات المراقبة ويتوقف التطبيق عن الاستجابة. هذا من أكثر السيناريوهات رعبًا لأي مهندس, لكن مع PIOSEE:

• المشكلة: لا تقل “في مشكله بالـDB”, بل كن دقيقًا: “قاعدة البيانات الرئيسية تجاوزت الحد الأقصى للاتصالات المتزامنه وأصبحت ترفض الطلبات الجديده منذ 8 دقائق, مما أوقف 3 خدمات رئيسية”.

• المعلومات: افتح لوحة المُراقبه, راجع عدد الاتصالات الفعلية مقارنةً بالحد الأقصى, تحقق من آخر عملية deployment هل تزامنت مع بداية الأزمه, افحص الـslow queries log لمعرفة هل هناك استعلامٌ يحجز الاتصالات, وتواصل مع زملائك: هل غير أحدهم شيئًا في آخر ساعة؟

• الخيارات: لديك عدة مسارات: (1) إعادة تشغيل الـconnection pool في التطبيق, (2) التحويل الفوري إلى الـread replica لتخفيف الحمل, (3) تعطيل الميزات غير الحيوية مؤقتًا لتقليل عدد الاتصالات, (4) رفع الحد الأقصى للاتصالات في إعدادات الـDB إن كانت الموارد تسمح, (5) تفعيل وضع الصيانة للتطبيق ريثما تُعالج المشكله.

• الاختيار: التحويل للـreplica هو الأسرع في تخفيف الضغط الفوري دون مخاطر, مقترنًا بتعطيل الميزات غير الحيوية. أما رفع حد الاتصالات دون معرفة السبب الجذري فقد يُعالج العَرَض لا المرض.

• التنفيذ: قسم المهام بوضوح: مهندسٌ يُحول حركة القراءه للـreplica, آخر يُعطل الميزات المحددة, ثالثٌ يُبلغ فريق المنتج والعملاء بالوضع. لا أحد يتصرف منفردًا دون تنسيق.

• التقييم: بعد التحويل, راقب معدل الأخطاء هل بدأ بالانخفاض؟ هل عادت الخدمات للاستجابه؟ ثم بعد استقرار الوضع, ابدأ تحقيقًا أعمق لإيجاد السبب الجذري وتوثيقه في post-mortem.

السيناريو الثاني - ارتفاع مفاجئ وحاد في حركة المرور

أطلق فريق التسويق حملةً على منصةٍ كبيره وأرسلوا رابط الموقع لمئات الآلاف, في هذه الحاله الحمل ارتفع بمقدار 20 ضعفًا في دقائق:

• المشكلة: “خوادم التطبيق تعمل بطاقةٍ تتجاوز 95% من الـCPU والذاكره, زمن الاستجابه تجاوز 8 ثوانٍ, وبدأت بعض الطلبات تُقابَل بخطأ 503”.

• المعلومات: من أين يأتي الحمل بالضبط؟ هل هو موزع على الخدمات أم مركز على endpoint معين؟ هل الـCDN يعمل ويُخزن الـstatic assets؟ هل قاعدة البيانات متأثرةٌ أيضًا؟ هل الـauto-scaling مُفعَل؟

• الخيارات: (1) رفع عدد الـinstances يدويًا إن كان الـauto-scaling بطيئًا, (2) تفعيل aggressive caching للصفحات الأكثر زياره, (3) تفعيل Rate Limiting لمنع الطلبات المفرطه من مصدرٍ واحد, (4) تعطيل الميزات الثقيله حسابيًا مؤقتًا كالتقارير والـexports.

• الاختيار: الجمع بين رفع الـinstances فورًا وتفعيل الـRate Limiting وتعطيل الميزات الثقيله هو الثلاثي الذهبي الذي يُعطي نتائج سريعه دون إيقاف الخدمه كليًا.

• التنفيذ: وزع المهام: مهندس البنية التحتيه يرفع الـinstances, مهندس الـbackend يُفعل الـRate Limiting ويُعطل الميزات المحددة, مهندس الـfrontend يتأكد من أن الـCDN يخدم الـstatic assets بكفاءه (كمهندس برمجيات تعمل على مشروع خاص بك غالبًا ستهتم بهذه الأمور كلها كونك one man army والأمر مُضحكٌ نوعًا ما).

• التقييم: راقب زمن الاستجابه ومعدلات الخطأ كل دقيقتين, تأكد من عودة التجربه لمستواها الطبيعي. ثم بعد انتهاء الضغط, وثّق الحادثه وخطط لـload testing منتظم حتى لا تُفاجئك الحملات القادمه.

السيناريو الثالث - خطأٌ كارثي بعد عملية نشر جديده

نشرتَ إصدارًا جديدًا وبعد دقائق بدأت تتوالى تقارير المستخدمين: “زر الدفع لا يعمل”, “لا أستطيع تسجيل الدخول”, والتنبيهات تُشير لارتفاعٍ حاد في معدل أخطاء الـ500 (أخطاء متعلقه بالسيرفر):

• المشكلة: “معدل خطأ الـ500 ارتفع من 0.1% إلى 23% بعد نشر الإصدار “v2.4.1” قبل 6 دقائق, المتأثر الرئيسي هو مسار الـcheckout والمصادقة”.

• المعلومات: افحص الـerror logs فورًا, هل الأخطاء تشير لكود جديد أم لتغييرٍ في قاعدة البيانات؟ هل أُجريت migrations جديده؟ هل المشكلة في كل المناطق الجغرافيه أم في منطقةٍ واحده؟

• الخيارات: (1) Rollback فوري للإصدار السابق, (2) Hotfix سريع إن كانت المشكلة سطرًا واحدًا أو اثنين, (3) Feature flag لتعطيل الجزء المعيب فقط دون rollback كامل.

• الاختيار: الـRollback هو الخيار الأأمن عمومًا كلما كانت المشكلة تمس مسارات حيويه كالدفع, إلا إن كان الإصلاح حرفيًا سطرًا واحدًا واضحًا ويمكن اختباره في أقل من دقيقتين.

• التنفيذ: نفذ الـrollback, أبلغ فريق الدعم حتى يُهدئوا المستخدمين المتأثرين, وأغلق قناة الـdeployment للإصدار المعطوب حتى يُحقق الفريق في المشكله.

• التقييم: تأكد من عودة المعدلات لطبيعتها بعد الـrollback, ثم حلل المشكله في بيئة التطوير بهدوء, وأضف اختبار integration يغطي هذا السيناريو حتى لا يتكرر.

مخططات أُخرى مشابهه مع إختلاف الفلسفه

الخاتمه

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