حقيقة مهندس شبكة (مع الشعرية و ... الملح؟)في الآونة الأخيرة ، أثناء مناقشة الحوادث المختلفة مع المهندسين ، لاحظت وجود نمط مثير للاهتمام.
في هذه المناقشات ، تنشأ مسألة "السبب الجذري" دائمًا. ربما يعرف القراء المؤمنين أن لدي
بعض الأفكار حول
هذا الموضوع . في العديد من المنظمات ، يعتمد تحليل الحوادث كليًا على هذا المفهوم. يستخدمون تقنيات مختلفة لتحديد العلاقات بين السبب والنتيجة ، مثل
Five Why . تشير هذه الأساليب إلى ما يسمى "الخطية للأحداث" كعقيدة لا يمكن إنكارها.
عندما تسأل هذه الفكرة وتوضح أن الخطية في الأنظمة المعقدة تكون خادعة بشكل مطمئن ، يولد نقاش رائع. يصر المتحاورون بشغف على أن معرفة "السبب الجذري" فقط تسمح لنا بفهم ما يحدث.
لقد لاحظت وجود نمط مثير للاهتمام: يتفاعل المطورون و devs بشكل مختلف مع هذه الفكرة. في تجربتي ، كثيرًا ما يجادل المطورون بأن السبب الجذري مهم وأن السببية يمكن أن تنشأ دائمًا في الأحداث. من ناحية أخرى ، يتفق المسلمون في كثير من الأحيان على أن العالم المعقد لا يخضع دائمًا للخطي.
كنت دائما أتساءل لماذا؟ ما الذي
يجعل المبرمجين ينتقدون فكرة "السبب الجذري - الأسطورة"؟ مثل الجهاز المناعي الذي يتعرف على وكيل أجنبي. لماذا يتفاعلون بهذه الطريقة بينما
من المرجح أن يفكر المطربون
في هذه الفكرة؟
لست متأكدًا تمامًا ، ولكن هناك اعتبار في هذا الصدد. يرتبط بسياقات مختلفة يقوم فيها هؤلاء المحترفون بعمل يومي.
المطورين غالبا ما تعمل مع أدوات حتمية. بطبيعة الحال ، فإن المجمعين ، والروابط ، وأنظمة التشغيل جميعها أنظمة معقدة ، لكننا معتادون على إعطاء نتيجة حتمية ، ونقدمها على أنها حتمية: إذا قدمنا نفس بيانات الإدخال ، فإننا نتوقع عادةً نفس الناتج من هذه الأنظمة . وإذا كانت هناك مشكلة ("الأخطاء") ، فإن المطورين يحلونها عن طريق تحليل بيانات الإدخال (إما من المستخدم أو من مجموعة من الأدوات في عملية التطوير). يبحثون عن "خطأ" ثم يقومون بتعديل الإدخال. هذا إصلاح الخلل.
الافتراض الرئيسي لتطوير البرمجيات: نفس بيانات المدخلات بشكل موثوق وحاسم يعطي نفس الناتجفي الواقع ، تعتبر النتيجة غير القطعية في حد ذاتها خطأ: إذا لم يتم إعادة إنتاج نتيجة غير متوقعة أو خاطئة ، فإن المطورين يسعون إلى توسيع الدراسة لتشمل أجزاء أخرى من الحزمة (نظام التشغيل ، الشبكة ، إلخ.) التي تتصرف أيضًا بشكل أو بآخر بشكل حاسم ، مع إعطاء نفس الشيء تنتج مع نفس المدخلات ...
وإذا لم يكن كذلك ، فإنه لا يزال يعتبر خطأ. إنها مجرد خطأ في نظام التشغيل أو الشبكة.
في أي حال ، الحتمية هي افتراض أساسي ، يؤخذ على أنه من المسلم به معظم الأعمال التي يقوم بها المبرمجون.
ولكن بالنسبة لأي devopa الذي قضى اليوم في جمع الحديد في الرفوف أو فرز API السحابية ، فإن فكرة عالم حتمية تمامًا (طالما هناك فرصة لعرض جميع بيانات الإدخال!) هي ، في أحسن الأحوال ، مفهوم سريع. حتى
يرمي جانبا
BOHF النكات حول بقع الشمس ، ورأى المهندسين ذوي الخبرة أغرب الأشياء في هذا العالم. إنهم يعرفون أنه
حتى الصراخ البشري يمكن أن يبطئ الخادم ، ناهيك عن ملايين العوامل البيئية الأخرى.
لذا فمن الأسهل بالنسبة للمهندسين ذوي الخبرة أن يشكوا في أن جميع الحوادث لها سبب وجيه واحد ، وأن تقنيات مثل "Five Why" بشكل صحيح (وقابل للتكرار!) تؤدي إلى هذا السبب الجذري. في الواقع ، فإن هذا يتناقض مع تجربتهم الخاصة ، عندما لا تضيف قطع الألغاز في الممارسة بشكل واضح. لذلك ، فإنهم يدركون هذه الفكرة بسهولة أكبر.
بالطبع ، أنا لا أقول أن المطورين ساذجون ، أو أغبياء ، أو غير قادرين على فهم كيف يمكن للخطية أن تخدع.
ربما رأى المبرمجون المتمرسون أيضًا الكثير من عدم الحتمية في حياتهم.لكن يبدو لي أن رد الفعل المعتاد من المطورين في هذه النزاعات يرتبط غالبًا بحقيقة أن مفهوم الحتمية
ككل يخدمهم جيدًا في العمل اليومي. لا يواجهون عدم الحتمية بقدر ما يضطر المهندسون للقبض على قطط شرودنجر على بنيتهم التحتية.
ربما هذا لا يفسر بشكل كامل ردود الفعل الملحوظة للمطورين ، ولكن هذا تذكير قوي بأن ردود الفعل لدينا هي مزيج معقد من العديد من العوامل.
من المهم أن تضع هذا التعقيد في الاعتبار ، سواء كنا نحقق في حادثة واحدة أو نعمل معًا على خط أنابيب لتسليم البرامج ، أو نحاول فهم العالم الأوسع.