لماذا لا يهتم المهندسون بمراقبة التطبيق؟

كل ذلك مع الجمعة! الأصدقاء ، نواصل اليوم سلسلة من المنشورات المخصصة لدورة الممارسات والأدوات الخاصة بـ DevOps ، لأن الفصول في المجموعة الجديدة في الدورة ستبدأ في نهاية الأسبوع القادم. لذلك دعونا نبدأ!



المراقبة سهلة . هذه حقيقة معروفة. ارفع Nagios ، وقم بتشغيل NRPE على النظام البعيد ، وقم بتكوين Nagios على منفذ NRPE TCP 5666 ولديك مراقبة.

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

(عادة ما يقومون بتثبيت PNP4Nagios و RRDtool و Thruk ، وإعداد الإشعارات في Slack والانتقال مباشرة إلى nagiosexhange ، ولكن الآن دعه يذهب).

المراقبة الجيدة معقدة للغاية في الواقع ، تحتاج حقًا إلى معرفة الأجزاء الداخلية للتطبيق الذي تشاهده.

هل الرصد صعب؟

أي خادم ، سواء Linux أو Windows ، بحكم التعريف سوف يخدم بعض الأغراض. Apache ، Samba ، Tomcat ، تخزين الملفات ، LDAP - كل هذه الخدمات فريدة أو أكثر من ناحية أو أكثر. لكل منها وظيفتها الخاصة ، وخصائصها الخاصة. هناك طرق مختلفة للحصول على المقاييس ، KPI (مؤشرات الأداء الرئيسية) ، والتي تهمك عندما يكون الخادم قيد التحميل.


الصورة لوقا شيسر على Unsplash


(أرغب في رسم لوحات البيانات الخاصة بي بألوان نيون زرقاء - تنهد حالمة - ... هم ...)

يجب أن يكون لدى أي برنامج يوفر خدمات آلية لجمع المقاييس. يحتوي Apache على وحدة mod-status تعرض صفحة mod-status الخادم. يحتوي Nginx على stub_status . لدى Tomcat JMX أو تطبيقات ويب خاصة تعرض المقاييس الأساسية. MySQL لديه أمر "إظهار الحالة العالمية" ، إلخ.
فلماذا لا يقوم المطورون بتضمين مثل هذه الآليات في التطبيقات التي يقومون بإنشائها؟

هل المطورين يفعلون هذا فقط؟

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


أرسلت بواسطة تيم غو على Unsplash

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

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

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

ومع ذلك ، فإن مهندسي النظام عادة لا يحفرون في الكود ، مما يكسبون المال لشركتهم. يحتاجون إلى كبار المطورين الذين يفهمون أهمية مسؤولية مهندس النظام في اكتشاف المشاكل ، وزيادة الوعي بمشاكل الأداء ، وما شابه ذلك.

هذا الشيء يخلص

تصف عقلية المطورين تضافر تفكير المطور (devs) والاستغلال (ops). يجب على أي شركة تدعي أنها "تقوم بتطوير" أن:

1. لقول ما قد لا يفعلونه (تلميح إلى الميم من فيلم "Princess Bride" - "لا أعتقد أنه يعني ما تعتقد أنه يعني!")
2. تعزيز موقف التحسين المستمر للمنتجات.

لا يمكنك تحسين منتج وتعرف أنه قد تم تحسينه إذا كنت لا تعرف كيف يعمل حاليًا. لن تتمكن من معرفة كيفية عمل المنتج إذا لم تفهم كيف تعمل مكوناته ، والخدمات التي يعتمد عليها ، ونقاط الألم الرئيسية والاختناقات.
ما لم تكن تلاحظ الاختناقات المحتملة ، لا يمكنك اتباع أسلوب Five Why عند كتابة Postmortem. لا يمكنك جمع كل شيء على شاشة واحدة لمعرفة كيفية عمل المنتج أو لمعرفة كيف يبدو "طبيعيًا وسعيدًا".

تحول اليسار ، اليسار ، قلت ، NOOOOOOOO-

بالنسبة لي ، أحد المبادئ الرئيسية لـ Devops هو "shift left". يعني التحول إلى اليسار في هذا السياق حدوث تحول في القدرة ( وليس المسؤولية ، ولكن فقط القدرة) على القيام بما يهتم به مهندسو النظام عادة ، على سبيل المثال ، إنشاء مقاييس الأداء ، واستخدام السجلات بشكل أكثر كفاءة ، وما إلى ذلك ، إلى اليسار في دورة حياة تسليم البرنامج ( تسليم البرمجيات دورة الحياة).


الصورة من قبل NESA بواسطة صناع على Unsplash

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

باختصار

1. أحضر الحصان إلى الماء. أظهر للمطورين عدد المشكلات التي يمكنهم تجنبها لأنفسهم ، ومساعدتهم على تحديد مؤشرات الأداء الرئيسية المناسبة والمقاييس لتطبيقاتهم بحيث يكون هناك صيحات أقل من مالك المنتج الذي يصرخ عليه CTO. جلبهم إلى النور ، بهدوء وهدوء. إذا لم ينجح ذلك ، فقم برشوة وتهديد وإقناع أي منهما أو مالك المنتج من أجل الحصول بسرعة على هذه المقاييس من التطبيقات ، ثم رسم المخططات. سيكون هذا صعبًا ، حيث لن يتم اعتباره أولوية ، وسيكون هناك العديد من المشروعات المدرة للدخل في انتظار التنفيذ في خريطة طريق المنتج. لذلك ، ستحتاج إلى حالة عمل لتبرير الوقت والمال الذي يتم إنفاقه على تنفيذ المراقبة في المنتج.
2. مساعدة مهندسي النظام في الحصول على قسط كاف من النوم. أظهر لهم أن استخدام قائمة مراجعة إصدار الإصدار لأي منتج أمر جيد. والتحقق من أن جميع التطبيقات قيد الإنتاج مغطاة بمقاييس ستساعدك في الحصول على ليلة نوم جيدة ، مما يتيح للمطورين معرفة ما ينجح وأين لا يعمل. ومع ذلك ، فإن الطريقة الصحيحة لإزعاج واضطراب أي مطور ومالك منتج و CTO هي دفع العصي إلى العجلات والمقاومة. سيؤثر هذا السلوك على تاريخ إصدار أي منتج إذا انتظرت مرة أخرى حتى اللحظة الأخيرة ، لذلك انتقل مرة أخرى إلى اليسار وقم بتضمين هذه المشكلات في أقرب وقت ممكن في خطة المشروع. إذا لزم الأمر ، شق طريقك إلى اجتماعات المنتج. ارتداء شارب وهمية وشعرت أو شيء من هذا القبيل ، فإنه لا يفشل أبدا. الإبلاغ عن مخاوفك ، وإظهار فوائد واضحة ، والتبشير.
3. تأكد من أن المطورين (dev) والتشغيل (ops) يفهمان معنى وعواقب نقل مقاييس المنتج إلى المنطقة الحمراء. لا تترك العملية باعتبارها الحارس الوحيد على أداء المنتج ؛ تأكد من مشاركة المطورين أيضًا في هذا المنتج (#productsquads).
4. سجلات شيء عظيم ، ولكن المقاييس أيضا. اجمعها ولا تدع سجلاتك تصبح نفايات في كرة مشتعلة ضخمة من العبث. اشرح للمطورين وأشرح لهم لماذا لا أحد غيرهم سيفهم سجلاتهم ، ويظهر لهم ما يشبه مشاهدة سجلات عديمة الفائدة في الساعة 3:15 صباحًا.

الصورة ماركو هورفات على Unsplash

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