مرحبا يا هبر! منذ عشر سنوات ، كنت أدعم أنظمة تقنية Highload IT. لن أكتب في هذه المقالة حول مشاكل تكوين nginx للعمل في وضع 1000+ RPS أو أشياء تقنية أخرى. سوف أشارك الملاحظات حول المشكلات في العمليات التي تنشأ في دعم وتشغيل مثل هذه الأنظمة.
مراقبة
لا ينتظر الدعم الفني حتى يصل أحد التطبيقات بمحتوى "لماذا ... الموقع متوقف مرة أخرى؟". الدعم بعد دقيقة واحدة من تعطل الموقع يجب أن يرى المشكلة بالفعل ويبدأ في حلها.
ولكن الموقع هو غيض من فيض . توفره هو واحد من أول من يتم رصدها.
ماذا عن الموقف عندما تتوقف بقايا بضائع المتجر عبر الإنترنت عن نظام تخطيط موارد المؤسسات؟ أو هل توقف نظام CRM الذي يقوم بحساب الخصومات للعملاء عن الاستجابة؟ في الوقت نفسه ، يعمل الموقع. يحصل Zabbix الشرطي على استجابة 200. لم يتلقى التحول في الخدمة أي إخطارات من المراقبة ويتفقد بسعادة الحلقة الأولى من الموسم الجديد من Game of Thrones.
غالبًا ما تكون المراقبة محدودة فقط عن طريق قياس حالة الذاكرة وذاكرة الوصول العشوائي وتحميل معالجات الخادم. لكن من الأهمية بمكان بالنسبة للأعمال التجارية الحصول على توفر المنتج على موقع ما. يؤدي الانخفاض الشرطي لجهاز ظاهري واحد في الكتلة إلى توقف حركة المرور عن التدفق إليه وسيزيد التحميل على الخوادم الأخرى. الشركة لن تخسر المال.
لذلك ، بالإضافة إلى مراقبة المعايير الفنية لأنظمة التشغيل على الخوادم ، تحتاج إلى تكوين مقاييس العمل. المقاييس التي تؤثر بشكل مباشر على المال. تفاعلات مختلفة مع الأنظمة الخارجية (CRM و ERP وغيرها). عدد الطلبات لفترة معينة من الوقت. أذونات العميل الناجحة أو غير الناجحة والمقاييس الأخرى.
التفاعل مع الأنظمة الخارجية
أي موقع ويب أو تطبيق للهاتف المحمول يبلغ حجم مبيعاته السنوية أكثر من مليار روبل يتفاعل مع الأنظمة الخارجية. بدءاً من CRM و ERP السابق ذكرهما ، وينتهي بنقل بيانات المبيعات إلى نظام بيانات خارجية كبير لتحليل عمليات الشراء وتزويد العميل بالمنتج الذي سيشتريه بالتأكيد (في الواقع ، لا). كل نظام من هذا القبيل لديه دعمه الخاص. وغالبا ما يسبب التواصل مع هذه الأنظمة الألم. خاصةً عندما تكون المشكلة عالمية وتحتاج إلى تحليلها في أنظمة مختلفة.
بعض الأنظمة تعطي الهاتف أو البرقية لمسؤوليها. تحتاج في مكان ما إلى كتابة رسائل إلى المديرين أو الذهاب إلى متتبعات الأخطاء في هذه الأنظمة الخارجية. حتى في سياق شركة واحدة كبيرة ، غالبًا ما تعمل أنظمة مختلفة في أنظمة محاسبة تطبيقات مختلفة. في بعض الأحيان يصبح من المستحيل تتبع حالة الطلب. تتلقى طلب في جيرا الشرطي واحد. ثم ، في تعليقات جيرا الأولى ، تضع رابطًا للمهمة في جيرا أخرى. في جيرا الثانية في التطبيق ، يكتب شخص ما بالفعل تعليقًا
تحتاج إلى الاتصال بالمسؤول الشرطي Andrei لحل المشكلة. و هكذا.
أفضل حل لهذه المشكلة هو إنشاء مساحة واحدة للاتصال ، على سبيل المثال ، في سلاك. دعوة لجميع المشاركين في تشغيل أنظمة خارجية. وكذلك تعقب واحد ، حتى لا تتكرر التطبيقات. يجب مراقبة التطبيقات في مكان واحد ، بدءًا من تنبيهات المراقبة إلى عرض الأخطاء في المنتجات. ستقول إن هذا غير واقعي وقد حدث تاريخياً أننا نعمل في تعقب واحد ، وهم في مسار آخر. ظهرت أنظمة مختلفة ، وكان لديهم فرق تكنولوجيا المعلومات الخاصة بهم. أوافق ، وبالتالي يجب حل المشكلة من الأعلى على مستوى CIO أو مالك المنتج.
يجب أن يوفر كل نظام تتفاعل معه الدعم كخدمة مع SLA واضح لحل المشاكل حسب الأولوية. وليس عندما يكون لدى المسؤول الشرطي Andrey دقيقة لك.
رجل - عنق الزجاجة
هل يوجد لدى كل شخص في المشروع (أو المنتج) مثل هذا الشخص الذي تسببت مغادرته في إجازة في تشنج السلطات؟ يمكن أن يكون مهندس devops أو محلل أو مطور. بعد كل شيء ، يعرف فقط المهندس devops الحاويات التي يتم تثبيتها على الخوادم ، وكيفية إعادة تحميل الحاوية في حالة وجود مشكلة ، وبالفعل لا يمكن حل أي مشكلة معقدة دون ذلك. المحلل هو الوحيد الذي يعرف كيف تعمل الآلية المعقدة الخاصة بك. ما تدفقات البيانات تذهب أين. في ما المعلمات من الطلبات التي الخدمات ، والتي سوف نتلقى الإجابات.
من سيفهم بسرعة سبب وجود أخطاء في السجلات وإصلاح الخلل الحرج بسرعة في المنتج؟ بالطبع نفس المطور. هناك آخرون ، لكنه لسبب ما يفهم فقط كيفية ترتيب الوحدات النمطية المختلفة للنظام.
جذر هذه المشكلة هو عدم وجود وثائق . بعد كل شيء ، إذا تم وصف جميع خدمات نظامك ، فسيكون من الممكن التعامل مع المشكلة بدون محلل. إذا اختارت Devops بضعة أيام من جدولها المزدحم ووصفت جميع الخوادم والخدمات والتعليمات لحل المشكلات النموذجية ، فيمكن حل مشكلة في غيابها بدونها. لا حاجة لقضاء إجازة لإنهاء البيرة بسرعة على الشاطئ والبحث عن خدمة الواي فاي لحل المشكلة.
الكفاءة والمسؤولية من موظفي الدعم
في المشروعات الكبيرة ، لا تبخل الشركات برواتب المطورين. يطاردون الوسطاء المكلفين أو كبار السن من مشاريع مماثلة. مع الدعم ، الوضع مختلف قليلاً. إنهم يحاولون بكل طريقة ممكنة لتقليل هذه التكاليف. الشركات تستأجر enikeyshikov منخفضة التكلفة يوم أمس وتدخل بجرأة في المعركة. هذه الإستراتيجية ممكنة عندما يتعلق الأمر بموقع بطاقات أعمال لبعض المصانع في زيلينوغراد.
إذا كنا نتحدث عن متجر كبير على الإنترنت ، فكل ساعة تعطل تكلف أكثر من الراتب الشهري لأحد المسؤولين enikeik. خذ لنقطة انطلاق 1 مليار روبل من مبيعاتها السنوية. هذا هو الحد الأدنى لدوران أي متجر على الإنترنت من تصنيف
TOP-100 لعام 2018 . اقسم هذا المبلغ على عدد الساعات في السنة واحصل على أكثر من 100000 روبل من الخسائر الصافية. وإذا لم تحسب ساعات الليل ، فيمكنك مضاعفة المبلغ بأمان.
لكن المال ليس هو الشيء الرئيسي ، أليس كذلك؟ (لا ، بالطبع الشيء الرئيسي) لا تزال هناك خسائر السمعة. يمكن أن تسبب ساعة سقوط المتجر الشهير على الإنترنت موجة من المراجعات على الشبكات الاجتماعية والمنشورات في وسائل الإعلام المواضيعية. ومحادثات الأصدقاء في المطبخ بأسلوب "لا تشتري أي شيء هناك ، وموقعها متوقف باستمرار" لا تناسب القياس على الإطلاق.
الآن مسؤولة. في ممارستي ، كانت هناك حالة لم يستجب فيها المسؤول في الوقت المناسب لإخطار نظام المراقبة بعدم إمكانية الوصول إلى الموقع. في صيف ممتع مساء الجمعة ، كان موقع أحد المتاجر المعروفة على الإنترنت في موسكو بهدوء. في صباح يوم السبت ، لم يفهم منتج هذا الموقع سبب عدم فتح الموقع ، وكان هناك صمت في محادثات الدعم والتنبيهات العاجلة في سلاك. مثل هذا الخطأ كلفنا مبلغًا من ستة أرقام ، وعمل هذا الضابط المناوب.
المسؤولية هي مهارة يصعب تطويرها. الشخص لديه أم لا. لذلك ، في المقابلات ، أحاول تحديد وجودها بمختلف الأسئلة التي تُظهر بشكل غير مباشر ما إذا كان الشخص معتادًا على تحمل المسؤولية. إذا أجاب شخص أنه اختار جامعة لأن والديه قالا ذلك أو غيرا وظيفته لأن زوجته قالت إنه لا يتلقى الكثير ، فمن الأفضل عدم التورط مع هؤلاء الأشخاص.
التفاعل مع فريق التطوير
عندما يواجه المستخدمون مشكلات بسيطة على المنتج أثناء التشغيل ، يحلهم الدعم بمفردهم. يحاول إعادة إنشاء المشكلة وتحليل السجلات وما إلى ذلك. ولكن ماذا تفعل عندما ينبثق خطأ على همز؟ في هذه الحالة ، يبدأ الدعم في مهمة المطورين ، وهنا تبدأ المتعة.
مثقلة باستمرار المطورين. انهم يخلقون ميزات جديدة. إصلاح الخلل مع الدرس البيع ، ويقول ليس الأكثر إثارة للاهتمام. المواعيد النهائية لاستكمال سباق المقبل على. ثم يأتي الناس غير السارة من الدعم ويقولون: "إسقاط عاجل كل شيء ، لدينا مشاكل". أولوية هذه المهام ضئيلة. خاصةً عندما لا تكون المشكلة الأكثر أهمية وتعمل الوظيفة الرئيسية للموقع ، وعندما لا يعمل مدير الإصدار بعيون منتفخة ولا يكتب: "عاجل لإحضار هذه المهمة إلى الإصدار التالي أو الإصلاح العاجل".
تنتقل المهام ذات الأولوية العادية أو المنخفضة من الإصدار إلى الإصدار. إلى السؤال "متى سيتم إكمال المهمة؟" ستتلقى إجابات بأسلوب: "أنا آسف ، الآن هناك الكثير من المهام ، اطلب خيوط فريق أو مدير إصدارات."
المشكلات في المنتج لها أولوية أعلى من إنشاء ميزات جديدة. المراجعات السيئة لن تمنعك من الانتظار إذا واجه المستخدمون الأخطاء باستمرار. من الصعب استعادة السمعة التالفة.
يتم حل مشكلات التفاعل بين التطوير والدعم بواسطة DevOps. غالبًا ما يستخدم هذا الاختصار كشخص معين يساعد في إنشاء بيئات اختبار للتطوير ، ويقوم بإنشاء خطوط أنابيب CI \ CD ويعرض الكود الذي تم اختباره بسرعة في الإنتاج. DevOps هي طريقة لتطوير البرمجيات عندما يتفاعل جميع المشاركين في العملية عن كثب مع بعضهم البعض ويساعدون على إنشاء وتحديث منتجات وخدمات البرامج بسرعة. أعني المحللين والمطورين والمختبرين والدعم.
الدعم والتطوير في هذا النهج ليست إدارات مختلفة مع أهدافها وأهدافها. التنمية تشارك في العملية والعكس بالعكس. إن العبارة الشهيرة للفرق الموزعة: "المشكلة ليست في جانبي" لا يتم رؤيتها في كثير من الأحيان في غرف الدردشة ، ويصبح المستخدمون النهائيون أكثر سعادة.