حقيقة مهندس الشبكات (بالشعرية و... الملح؟)
في الآونة الأخيرة، أثناء مناقشة حوادث مختلفة مع المهندسين، لاحظت وجود نمط مثير للاهتمام.
في هذه المناقشات، يُطرح دائمًا سؤال "السبب الجذري". ربما يعرف القراء المخلصون أنني فعلت ذلك في . في العديد من المنظمات، يعتمد تحليل الحوادث بالكامل على هذا المفهوم. ويستخدمون تقنيات مختلفة لتحديد العلاقات بين السبب والنتيجة، مثل: . تفترض هذه الأساليب ما يسمى بـ "خطية الأحداث" كعقيدة لا جدال فيها.
عندما تتحدى هذه الفكرة وتشير إلى أن الخطية خادعة بشكل مطمئن في الأنظمة المعقدة، تنشأ مناقشة رائعة. يصر المتنازعون بشدة على أن معرفة "السبب الجذري" فقط هي التي تسمح لنا بفهم ما يحدث.
لقد لاحظت نمطًا مثيرًا للاهتمام: يتفاعل المطورون والمطورون بشكل مختلف مع هذه الفكرة. في تجربتي، من المرجح أن يجادل المطورون بأن السبب الجذري مهم وأن علاقات السبب والنتيجة يمكن دائمًا تأسيسها في الأحداث. من ناحية أخرى، يتفق DevOps في كثير من الأحيان على أن العالم المعقد لا يطيع دائمًا الخطية.
كنت أتساءل دائما لماذا هذا؟ ماذا يجعل هل ينتقد المبرمجون فكرة "السبب الجذري هو أسطورة" بهذه الطريقة؟ مثل جهاز المناعة الذي يتعرف على العامل الأجنبي. لماذا يتفاعلون بهذه الطريقة بينما المطورين يميل إلى حد ما النظر في هذه الفكرة؟
لست متأكدا تماما، ولكن لدي بعض الأفكار حول هذا الموضوع. يتعلق الأمر بالسياقات المختلفة التي يقوم فيها هؤلاء المهنيون بعملهم اليومي.
غالبًا ما يعمل المطورون باستخدام الأدوات الحتمية. بالطبع، المترجمات والروابط وأنظمة التشغيل كلها أنظمة معقدة، لكننا اعتدنا على أنها تعطي نتيجة حتمية، ونتخيلها على أنها حتمية: إذا قدمنا نفس بيانات الإدخال، فإننا عادة نتوقع نفس المخرجات من هذه الأنظمة . وإذا كانت هناك مشكلة في الإخراج (“خلل”)، يقوم المطورون بحلها من خلال تحليل البيانات المدخلة (إما من المستخدم أو من مجموعة الأدوات أثناء عملية التطوير). يبحثون عن "خطأ" ثم يقومون بتغيير بيانات الإدخال. يؤدي هذا إلى إصلاح "الخلل".
الافتراض الأساسي لتطوير البرمجيات: نفس بيانات المدخلات بشكل موثوق وحتمي تنتج نفس المخرجات.
في الواقع، تعتبر النتيجة غير الحتمية في حد ذاتها خطأً: إذا لم يتم إعادة إنتاج المخرجات غير المتوقعة أو الخاطئة، فإن المطورين يميلون إلى توسيع التحقيق ليشمل أجزاء أخرى من المكدس (نظام التشغيل، الشبكة، وما إلى ذلك) والتي تتصرف أيضًا بشكل أفضل. أو بشكل أقل حتمية، إنتاج نفس النتيجة مع نفس البيانات المدخلة... و إذا لم يكن كذلك، فهذا لا يزال يعتبر خطأ. إنه الآن مجرد خلل في نظام التشغيل أو الشبكة.
على أية حال، الحتمية هي افتراض أساسي، ويكاد يكون مسلمًا به بالنسبة لكثير من العمل الذي يقوم به المبرمجون.
ولكن بالنسبة لأي شخص من المطورين الذي قضى يومه في تجميع الأجهزة أو اكتشاف واجهة برمجة التطبيقات السحابية، فإن فكرة العالم الحتمي تمامًا (طالما أنه من الممكن حتى تعيين جميع المدخلات!) هي مفهوم عابر في أحسن الأحوال. حتى لو وضعته جانبا لقد شاهد المهندسون ذوو الخبرة أغرب الأشياء في هذا العالم. وهم يعرفون ذلك ناهيك عن ملايين العوامل الأخرى في البيئة.
لذا فمن الأسهل للمهندسين ذوي الخبرة أن يشككوا في أن جميع الحوادث لها سبب جذري واحد، وتقنيات مثل "الأسباب الخمسة" ستؤدي بشكل صحيح (ومتكرر!) إلى هذا السبب الجذري. في الواقع، هذا يتناقض مع تجربتهم الخاصة، حيث لا تتناسب قطع اللغز بشكل جيد في الممارسة العملية. ولذلك، فإنهم يتقبلون هذه الفكرة بسهولة أكبر.
بالطبع، لا أقول إن المطورين ساذجون أو أغبياء أو غير قادرين على فهم كيف يمكن أن يكون الخطي خادعًا.
ولكن يبدو لي أن رد الفعل المشترك من المطورين في هذه المناقشات غالبًا ما يتعلق بحقيقة أن مفهوم الحتمية يخدمهم جيدًا بشكل عام في العمل اليومي. إنهم لا يواجهون عدم الحتمية في كثير من الأحيان كما يضطر المهندسون إلى الإمساك بقطط شرودنغر في بنيتهم التحتية.
قد لا يفسر هذا ردود أفعال المطورين التي تمت ملاحظتها بشكل كامل، ولكنه تذكير قوي بأن ردود أفعالنا عبارة عن مزيج معقد من العديد من العوامل.
من المهم أن نتذكر هذا التعقيد، سواء كنا نتعامل مع حادثة واحدة، أو نتعاون في مسار توصيل البرامج، أو نحاول فهم العالم الأوسع.
المصدر: www.habr.com