مرحبًا حبر! لقد قمت بدعم أنظمة تكنولوجيا المعلومات Highload لمدة عشر سنوات. لن أكتب في هذه المقالة عن مشكلات إعداد nginx للعمل في وضع 1000+ RPS أو أشياء فنية أخرى. وسوف أشارك ملاحظاتي حول المشاكل في العمليات التي تنشأ في دعم وتشغيل هذه الأنظمة.
رصد
الدعم الفني لا ينتظر حتى وصول الطلب بمحتوى "ماذا لماذا... الموقع لا يعمل مرة أخرى؟" في غضون دقيقة واحدة بعد تعطل الموقع، من المفترض أن يرى فريق الدعم المشكلة بالفعل ويبدأ في حلها. لكن الموقع هو قمة جبل الجليد. يعد توفره من أوائل الأشياء التي يتم رصدها.
ماذا تفعل مع الموقف عندما لا تصل البضائع المتبقية من المتجر عبر الإنترنت من نظام تخطيط موارد المؤسسات (ERP)؟ أم أن نظام CRM الذي يقوم باحتساب الخصومات للعملاء توقف عن الاستجابة؟ يبدو أن الموقع يعمل. يتلقى Zabbix الشرطي 200 رد. ولم تتلق وردية المناوبة أي إشعارات من الرصد وهي تتابع بسعادة الحلقة الأولى من الموسم الجديد لمسلسل Game of Thrones.
غالبًا ما تقتصر المراقبة على قياس حالة الذاكرة وذاكرة الوصول العشوائي (RAM) وتحميل معالج الخادم فقط. ولكن بالنسبة للأعمال التجارية، من المهم جدًا الحصول على توفر المنتج على الموقع الإلكتروني. سيؤدي الفشل المشروط لجهاز ظاهري واحد في المجموعة إلى توقف حركة المرور عن الذهاب إليه وسيزداد الحمل على الخوادم الأخرى. الشركة لن تخسر المال.
لذلك، بالإضافة إلى مراقبة المعلمات الفنية لأنظمة التشغيل على الخوادم، تحتاج إلى تكوين مقاييس الأعمال. المقاييس التي تؤثر بشكل مباشر على المال. التفاعلات المختلفة مع الأنظمة الخارجية (CRM، ERP وغيرها). عدد الطلبات لفترة معينة من الزمن. تفويضات العميل الناجحة أو غير الناجحة والمقاييس الأخرى.
التفاعل مع الأنظمة الخارجية
يتفاعل أي موقع ويب أو تطبيق للهاتف المحمول يبلغ حجم مبيعاته السنوية أكثر من مليار روبل مع الأنظمة الخارجية. بدءاً من CRM و ERP المذكورين أعلاه وانتهاءً بنقل بيانات المبيعات إلى نظام Big Data خارجي لتحليل المشتريات وتقديم المنتج للعميل الذي سيشتريه بالتأكيد (في الواقع، لا). كل نظام من هذا القبيل له دعمه الخاص. وغالبا ما يسبب التواصل مع هذه الأنظمة الألم. خاصة عندما تكون المشكلة عالمية وتحتاج إلى تحليلها في أنظمة مختلفة.
توفر بعض الأنظمة رقم هاتف أو برقية لمسؤوليها. في مكان ما تحتاج إلى كتابة رسائل إلى المديرين أو الذهاب إلى متتبعي الأخطاء في هذه الأنظمة الخارجية. حتى في سياق شركة واحدة كبيرة، غالبًا ما تعمل أنظمة مختلفة في أنظمة محاسبة تطبيقية مختلفة. في بعض الأحيان يصبح من المستحيل تتبع حالة الطلب. تتلقى طلبًا في Jira مشروطة واحدة. ثم في تعليق هذه الجيرا الأولى قمت بوضع رابط للمشكلة في جيرا أخرى. في جيرا الثانية في التطبيق، شخص ما يكتب بالفعل تعليقا تحتاج إلى الاتصال بالمسؤول الشرطي Andrey لحل المشكلة. وهلم جرا.
الحل الأفضل لهذه المشكلة هو إنشاء مساحة واحدة للتواصل، على سبيل المثال في Slack. دعوة جميع المشاركين في عملية تشغيل الأنظمة الخارجية للانضمام. وأيضًا أداة تعقب واحدة حتى لا تتكرر التطبيقات. يجب تتبع التطبيقات في مكان واحد، بدءًا من مراقبة الإشعارات وحتى إخراج حلول الأخطاء في المستقبل. ستقول أن هذا غير واقعي وقد حدث تاريخيًا أننا نعمل في جهاز تتبع واحد، وهم يعملون في جهاز آخر. ظهرت أنظمة مختلفة، وكان لديهم فرق تكنولوجيا المعلومات المستقلة الخاصة بهم. أوافق، وبالتالي يجب حل المشكلة من الأعلى على مستوى مدير تكنولوجيا المعلومات أو مالك المنتج.
يجب أن يقدم كل نظام تتفاعل معه الدعم كخدمة مع اتفاقية مستوى خدمة واضحة لحل المشكلات حسب الأولوية. وليس عندما يكون لدى المشرف الشرطي أندريه دقيقة واحدة لك.
رجل عنق الزجاجة
هل كل شخص في مشروع (أو منتج) لديه شخص تسبب إجازته في حدوث تشنجات بين رؤسائه؟ يمكن أن يكون هذا مهندسًا أو محللًا أو مطورًا. بعد كل شيء، فقط مهندس المطورين يعرف أي الخوادم بها أي حاويات مثبتة، وكيفية إعادة تشغيل الحاوية في حالة حدوث مشكلة، وبشكل عام، لا يمكن حل أي مشكلة معقدة بدونه. المحلل هو الوحيد الذي يعرف كيف تعمل آليتك المعقدة. ما هي تدفقات البيانات التي تذهب إلى أين. تحت أي معايير للطلبات، وأي خدمات، وأي منها سنتلقى ردودًا.
من سيفهم بسرعة سبب وجود أخطاء في السجلات ويصلح الخلل الخطير في المنتج على الفور؟ طبعا نفس المطور هناك آخرون، ولكن لسبب ما هو الوحيد الذي يفهم كيفية عمل الوحدات المختلفة للنظام.
أصل هذه المشكلة هو عدم وجود وثائق. بعد كل شيء، إذا تم وصف جميع خدمات نظامك، فسيكون من الممكن التعامل مع المشكلة دون محلل. إذا استغرق Devops بضعة أيام من جدوله المزدحم ووصف جميع الخوادم والخدمات والتعليمات لحل المشكلات النموذجية، فيمكن حل المشكلة في غيابه بدونه. لا تحتاج إلى الانتهاء بسرعة من تناول البيرة على الشاطئ أثناء إجازتك والبحث عن شبكة Wi-Fi لحل المشكلة.
كفاءة ومسؤولية موظفي الدعم
في المشاريع الكبيرة، لا تبخل الشركات على رواتب المطورين. إنهم يبحثون عن الوسطاء أو كبار السن الباهظين من مشاريع مماثلة. مع الدعم الوضع مختلف قليلا. إنهم يحاولون تقليل هذه التكاليف بكل الطرق الممكنة. تقوم الشركات بتوظيف عمال Enikey غير المكلفين بالأمس وتخوض المعركة بجرأة. هذه الإستراتيجية ممكنة إذا كنا نتحدث عن موقع ويب لبطاقة العمل لمصنع في زيلينوغراد.
إذا كنا نتحدث عن متجر كبير عبر الإنترنت، فإن كل ساعة من التوقف تكلف أكثر من الراتب الشهري لمسؤول Enikey. لنأخذ مليار روبل من حجم الأعمال السنوي كنقطة انطلاق. هذا هو الحد الأدنى لدوران أي متجر عبر الإنترنت من التصنيف . اقسم هذا المبلغ على عدد الساعات في السنة واحصل على أكثر من 100 روبل من صافي الخسائر. وإذا لم تحسب ساعات الليل، فيمكنك مضاعفة المبلغ بأمان.
لكن المال ليس هو الشيء الرئيسي، أليس كذلك؟ (لا، الشيء الرئيسي بالطبع) هناك أيضًا خسائر في السمعة. يمكن أن يؤدي سقوط متجر معروف عبر الإنترنت إلى موجة من المراجعات على الشبكات الاجتماعية والمنشورات في الوسائط المواضيعية. ومحادثات الأصدقاء في المطبخ بأسلوب "لا تشتري أي شيء هناك، موقع الويب الخاص بهم معطل دائمًا" لا يمكن قياسها على الإطلاق.
الآن إلى المسؤولية. في ممارستي، كانت هناك حالة عندما لم يستجب المسؤول المناوب في الوقت المناسب لإخطار من نظام المراقبة حول عدم توفر الموقع. في أمسية صيفية ممتعة يوم الجمعة، كان الموقع الإلكتروني لمتجر إلكتروني معروف في موسكو يقبع بهدوء. صباح يوم السبت، لم يفهم مدير المنتج لهذا الموقع سبب عدم فتح الموقع، وكان هناك صمت في محادثات الدعم والإشعارات العاجلة في Slack. مثل هذا الخطأ كلفنا مبلغًا من ستة أرقام، وهذا الضابط المناوب وظيفته.
المسؤولية هي مهارة يصعب تطويرها. سواء كان لدى الإنسان ذلك أم لا. لذلك، خلال المقابلات، أحاول التعرف على وجودها من خلال أسئلة مختلفة تظهر بشكل غير مباشر ما إذا كان الشخص معتاداً على تحمل المسؤولية. إذا أجاب الشخص بأنه اختار الجامعة لأن والديه قالا ذلك أو غير وظيفته لأن زوجته قالت إنه لا يكسب ما يكفي، فمن الأفضل عدم التورط مع هؤلاء الأشخاص.
التفاعل مع فريق التطوير
عندما يواجه المستخدمون مشكلات بسيطة مع أحد المنتجات أثناء التشغيل، يقوم الدعم بحلها من تلقاء نفسه. يحاول إعادة إنتاج المشكلة، وتحليل السجلات، وما إلى ذلك. ولكن ماذا تفعل عند ظهور خطأ في المنتج؟ في هذه الحالة، يقوم الدعم بتعيين المهمة للمطورين وهنا تبدأ المتعة.
المطورين مثقلون باستمرار. إنهم يخلقون ميزات جديدة. إصلاح الأخطاء في المبيعات ليس هو النشاط الأكثر إثارة للاهتمام. المواعيد النهائية تقترب لإكمال السباق التالي. ثم يأتي أشخاص غير سارة من الدعم ويقولون: "اترك كل شيء على الفور، لدينا مشاكل". أولوية هذه المهام ضئيلة. خاصة عندما لا تكون المشكلة هي الأكثر أهمية وتعمل الوظيفة الرئيسية للموقع، وعندما لا يتجول مدير الإصدار بعيون منتفخة ويكتب: "أضف هذه المهمة بشكل عاجل إلى الإصدار التالي أو الإصلاح العاجل."
يتم نقل المشكلات ذات الأولوية العادية أو المنخفضة من إصدار إلى إصدار. على السؤال "متى ستكتمل المهمة؟" سوف تتلقى إجابات بأسلوب: "عذرًا، هناك الكثير من المهام في الوقت الحالي، اسأل قادة فريقك أو مدير الإصدار."
تحظى مشكلات الإنتاجية بأولوية أعلى من إنشاء ميزات جديدة. لن تستغرق المراجعات السيئة وقتًا طويلاً إذا عثر المستخدمون باستمرار على الأخطاء. من الصعب استعادة السمعة المتضررة.
يتم حل مشكلات التفاعل بين التطوير والدعم بواسطة DevOps. غالبًا ما يستخدم هذا الاختصار في شكل شخص معين يساعد في إنشاء بيئات اختبار للتطوير، وبناء خطوط أنابيب CICD، وإدخال التعليمات البرمجية المختبرة في الإنتاج بسرعة. DevOps هو أسلوب لتطوير البرمجيات عندما يتفاعل جميع المشاركين في العملية بشكل وثيق مع بعضهم البعض ويساعدون في إنشاء منتجات وخدمات البرامج وتحديثها بسرعة. أعني المحللين والمطورين والمختبرين والدعم.
في هذا النهج، الدعم والتطوير ليسا أقسامًا مختلفة لها أهدافها وغاياتها الخاصة. التنمية تشارك في التشغيل والعكس صحيح. العبارة الشهيرة للفرق الموزعة: "المشكلة ليست في جانبي" لم تعد تظهر في الدردشات كثيرًا، وأصبح المستخدمون النهائيون أكثر سعادة قليلاً.
المصدر: www.habr.com