الحقيقة هي أن جميع فرقنا مبنية على أنظمة معلومات وخدمات مصغرة وواجهات منفصلة ، لذلك لا ترى الفرق الصحة العامة للنظام بأكمله ككل. على سبيل المثال ، قد لا يعرفون كيف يؤثر جزء صغير في الواجهة الخلفية العميقة على الواجهة الأمامية. يقتصر نطاق اهتماماتهم على الأنظمة التي يتكامل معها نظامهم. إذا كان الفريق وخدمته "أ" لا علاقة لهما تقريبًا بالخدمة "ب" ، فإن هذه الخدمة تكاد تكون غير مرئية للفريق.
فريقنا ، بدوره ، يعمل مع أنظمة تتكامل بقوة مع بعضها البعض: هناك العديد من الاتصالات بينها ، وهذه بنية تحتية كبيرة جدًا. ويعتمد عمل المتجر الإلكتروني على كل هذه الأنظمة (بالمناسبة لدينا عدد ضخم).
لذلك اتضح أن قسمنا لا ينتمي إلى أي فريق ، ولكنه منعزل قليلاً. في هذه القصة بأكملها ، مهمتنا هي أن نفهم بطريقة معقدة كيفية عمل أنظمة المعلومات ، ووظائفها ، وتكاملها ، وبرمجياتها ، وشبكاتها ، وأجهزتها ، وكيف أن كل هذا مترابط.
يبدو النظام الأساسي الذي تعمل عليه متاجرنا عبر الإنترنت كما يلي:
- أمامي
- وسط المكتب
- مكتب خلفي
بقدر ما نود ، ولكن لا يوجد شيء من هذا القبيل تعمل جميع الأنظمة بسلاسة وبدون عيوب. النقطة ، مرة أخرى ، هي عدد الأنظمة والتكامل - مع مثل لدينا ، بعض الحوادث لا مفر منها ، على الرغم من جودة الاختبار. علاوة على ذلك ، سواء داخل نظام منفصل أو من حيث اندماجها. وتحتاج إلى مراقبة حالة النظام الأساسي بالكامل بشكل شامل ، وليس أي جزء منفصل منه.
من الناحية المثالية ، يجب أتمتة مراقبة سلامة النظام الأساسي بالكامل. وقد توصلنا إلى المراقبة كجزء لا مفر منه من هذه العملية. في البداية ، تم تصميمه فقط للجزء الأمامي ، بينما كان لمتخصصي الشبكات ومسؤولي البرامج والأجهزة أنظمة المراقبة الخاصة بهم حسب الطبقات. كل هؤلاء الأشخاص تابعوا المراقبة على مستواهم فقط ؛ ولم يكن لدى أي شخص فهم شامل أيضًا.
على سبيل المثال ، في حالة تعطل آلة افتراضية ، في معظم الحالات لا يعرفها سوى المسؤول المسؤول عن الأجهزة والجهاز الظاهري. في مثل هذه الحالات ، رأى الفريق الأمامي حقيقة تعطل التطبيق ، لكن لم يكن لديهم بيانات عن تعطل الجهاز الظاهري. ويمكن للمسؤول معرفة من هو العميل ، وتخيل ما يتم تشغيله على هذا الجهاز الظاهري الآن ، بشرط أن يكون هذا نوعًا من المشاريع الكبيرة. ربما لا يعرف شيئًا عن الصغار. في أي حال ، يحتاج المسؤول إلى الذهاب إلى المالك ، والسؤال عما كان موجودًا على هذا الجهاز ، وما الذي يجب استعادته وما الذي يجب تغييره. وإذا تعطل شيء خطير للغاية ، فإنهم بدأوا يركضون في دوائر - لأن لا أحد رأى النظام ككل.
في النهاية ، تؤثر هذه القصص المتباينة على الواجهة الأمامية بأكملها والمستخدمين ووظيفة عملنا الأساسية ، المبيعات عبر الإنترنت. نظرًا لأننا لسنا جزءًا من فريق ، ولكننا نشارك في تشغيل جميع تطبيقات التجارة الإلكترونية كجزء من متجر عبر الإنترنت ، فقد أخذنا على عاتقنا مهمة إنشاء نظام مراقبة شامل لمنصة التجارة الإلكترونية.
هيكل النظام والمكدس
بدأنا بتحديد عدة طبقات من المراقبة لأنظمتنا ، وفي سياقها نحتاج إلى جمع المقاييس. وكان لابد من دمج كل هذا ، وهو ما فعلناه في المرحلة الأولى. الآن ، في هذه المرحلة ، نضع اللمسات الأخيرة على مجموعة المقاييس عالية الجودة لجميع طبقاتنا من أجل بناء ارتباط وفهم كيفية تأثير الأنظمة على بعضها البعض.
أدى عدم وجود مراقبة شاملة في المراحل الأولى من إطلاق التطبيقات (منذ أن بدأنا في بنائه عندما كانت معظم الأنظمة قيد التشغيل) إلى حقيقة أن لدينا دينًا تقنيًا كبيرًا لإعداد مراقبة النظام الأساسي بالكامل. لم يكن بمقدورنا التركيز على إعداد مراقبة نظام معلومات واحد والعمل على رصده بالتفصيل ، لأن بقية الأنظمة كانت ستبقى بدون مراقبة لبعض الوقت. لحل هذه المشكلة ، حددنا قائمة بالمقاييس الأكثر ضرورة لتقييم حالة نظام المعلومات حسب الطبقات وبدأنا في تنفيذها.
لذلك قرروا أن يأكلوا الفيل على أجزاء.
يتكون نظامنا من:
- المعدات؛
- نظام التشغيل؛
- البرمجيات؛
- أجزاء واجهة المستخدم في تطبيق المراقبة ؛
- مقاييس العمل
- تطبيقات التكامل؛
- أمن المعلومات؛
- الشبكات.
- موازن حركة المرور.
في مركز هذا النظام يراقب نفسه. من أجل فهم حالة النظام بأكمله بشكل عام ، تحتاج إلى معرفة ما يحدث للتطبيقات الموجودة في كل هذه الطبقات وفي سياق مجموعة التطبيقات بأكملها.
لذا ، حول المكدس.
نحن نستخدم برمجيات مفتوحة المصدر. في المركز لدينا Zabbix ، والذي نستخدمه بشكل أساسي كنظام تنبيه. يعلم الجميع أنها مثالية لمراقبة البنية التحتية. ماذا يعني هذا؟ هذه هي المقاييس منخفضة المستوى التي تمتلكها كل شركة لديها مركز بيانات خاص بها (ولدى Sportmaster مراكز بيانات خاصة بها) - درجة حرارة الخادم وحالة الذاكرة والغارة ومقاييس جهاز الشبكة.
لقد قمنا بدمج Zabbix مع Telegram messenger و Microsoft Teams ، والتي يتم استخدامها بنشاط في فرق. يغطي Zabbix طبقة الشبكة الفعلية والأجهزة والبرامج جزئيًا ، لكنه ليس حلاً سحريًا. نحن نثري هذه البيانات من بعض الخدمات الأخرى. على سبيل المثال ، فيما يتعلق بمستوى الأجهزة ، نقوم بالاتصال مباشرة عبر API بنظام المحاكاة الافتراضية الخاص بنا ونجمع البيانات.
ماذا بعد. بالإضافة إلى Zabbix ، نستخدم Prometheus ، والذي يسمح بمراقبة المقاييس في تطبيق بيئة ديناميكي. وهذا يعني أنه يمكننا تلقي مقاييس التطبيق عبر نقطة نهاية HTTP ولا تقلق بشأن المقاييس التي يجب تحميلها وأيها لا. بناءً على هذه البيانات ، يمكنك عمل استعلامات تحليلية.
تنقسم مصادر البيانات للطبقات الأخرى ، على سبيل المثال ، مقاييس الأعمال ، إلى ثلاثة مكونات.
أولاً ، هذه أنظمة أعمال خارجية ، Google Analytics ، نجمع المقاييس من السجلات. نحصل منهم على بيانات حول المستخدمين النشطين والتحويلات وكل شيء آخر يتعلق بالعمل. ثانيًا ، إنه نظام مراقبة واجهة المستخدم. يجب وصفها بمزيد من التفصيل.
ذات مرة ، بدأنا بالاختبار اليدوي ، وتطور إلى اختبارات تلقائية وظيفية وتكاملية. لقد جعلنا المراقبة منه ، تاركين الوظائف الرئيسية فقط ، وربطنا بعلامات ثابتة قدر الإمكان ولا تتغير غالبًا بمرور الوقت.
يشير هيكل الفريق الجديد إلى أن جميع أنشطة التطبيق محصورة في فرق المنتج ، لذلك توقفنا عن إجراء الاختبارات البحتة. بدلاً من ذلك ، قمنا بمراقبة واجهة المستخدم من الاختبارات ، المكتوبة بلغة Java و Selenium و Jenkins (تُستخدم كنظام لإطلاق التقارير وإنشاءها).
أجرينا الكثير من الاختبارات ، لكننا في النهاية قررنا الذهاب إلى الطريق الرئيسي ، مقياس المستوى الأعلى. وإذا كان لدينا الكثير من الاختبارات المحددة ، فسيكون من الصعب تحديث البيانات باستمرار. سيؤدي كل إصدار لاحق إلى كسر النظام بأكمله بشكل كبير ، وسنتعامل فقط مع إصلاحه. لذلك ، ربطنا بأشياء أساسية جدًا نادراً ما تتغير ، ونراقبها فقط.
أخيرًا ، ثالثًا ، مصدر البيانات هو نظام تسجيل مركزي. بالنسبة للسجلات ، نستخدم Elastic Stack ، ومن ثم يمكننا سحب هذه البيانات إلى نظام المراقبة الخاص بنا لمقاييس الأعمال. بالإضافة إلى كل هذا ، تعمل خدمة API الخاصة بالمراقبة ، المكتوبة بلغة Python ، والتي تستعلم عن أي خدمات عبر واجهة برمجة التطبيقات وتأخذ البيانات منها إلى Zabbix.
التخيل سمة أخرى لا يمكن الاستغناء عنها للرصد. نحن نبنيها على أساس غرافانا. من بين أنظمة التصور الأخرى ، تبرز من حيث أنه من الممكن تصور المقاييس من مصادر البيانات المختلفة على لوحة القيادة. يمكننا جمع مقاييس المستوى الأعلى لمتجر عبر الإنترنت ، على سبيل المثال ، عدد الطلبات التي تم تقديمها في الساعة الأخيرة من DBMS ، ومقاييس أداء نظام التشغيل الذي يشغل هذا المتجر عبر الإنترنت من Zabbix ، ومقاييس مثيلات هذا التطبيق من Prometheus. وكل هذا سيكون على لوحة تحكم واحدة. مرئية ويمكن الوصول إليها.
اسمحوا لي أن أشير إلى الأمن - نحن الآن بصدد وضع اللمسات الأخيرة على النظام ، والذي سوف ندمجه لاحقًا مع نظام المراقبة العالمي. في رأيي ، المشاكل الرئيسية التي تواجه التجارة الإلكترونية في مجال أمن المعلومات تتعلق بالروبوتات والمحللين والقوة الغاشمة. يجب مراقبة ذلك لأنها يمكن أن تؤثر جميعًا بشكل حاسم على أداء تطبيقاتنا والسمعة من وجهة نظر العمل. ونقوم بتغطية هذه المهام بنجاح بالمكدس المختار.
نقطة أخرى مهمة هي أن بروميثيوس يجمع طبقة التطبيق. هو نفسه مندمج أيضًا مع Zabbix. ولدينا أيضًا سرعة الموقع ، وهي خدمة تتيح لنا وفقًا لذلك النظر في المعلمات مثل سرعة تحميل صفحتنا ، والاختناقات ، وعرض الصفحة ، وتحميل البرامج النصية ، وما إلى ذلك ، كما يتم دمجها عبر واجهة برمجة التطبيقات. لذلك يتم جمع المقاييس في Zabbix ، على التوالي ، ننبه أيضًا من هناك. تذهب جميع التنبيهات حتى الآن إلى الطرق الرئيسية للإرسال (في الوقت الحالي ، هذه هي البريد الإلكتروني والبرقية ، وقد تم توصيل MS Teams مؤخرًا). هناك خطط لضخ التنبيه إلى هذه الحالة التي تعمل فيها الروبوتات الذكية كخدمة وتوفر معلومات المراقبة لجميع فرق المنتجات المهتمة.
بالنسبة لنا ، لا تعد مقاييس أنظمة المعلومات الفردية مهمة فحسب ، بل تعد أيضًا المقاييس العامة عبر البنية التحتية بأكملها التي تستخدمها التطبيقات: مجموعات من الخوادم الفعلية التي تشغل الأجهزة الافتراضية ، وموازنات حركة المرور ، وموازن تحميل الشبكة ، والشبكة نفسها ، واستخدام قنوات الاتصال. مقاييس إضافية لمراكز البيانات الخاصة بنا (لدينا العديد منها والبنية التحتية مهمة جدًا).
تتمثل مزايا نظام المراقبة لدينا في أنه بمساعدته نرى الحالة الصحية لجميع الأنظمة ، يمكننا تقييم تأثيرها على بعضنا البعض وعلى الموارد المشتركة. وفي النهاية يسمح بتخطيط الموارد ، وهو أيضًا مسؤوليتنا. نحن ندير موارد الخادم - تجمع في إطار التجارة الإلكترونية ، ونقدم معدات جديدة ونخرجها من الخدمة ، ونشتري معدات جديدة ، ونجري تدقيقًا لاستخدام الموارد ، وما إلى ذلك. كل عام ، تخطط الفرق لمشاريع جديدة ، وتطور أنظمتها ، ومن المهم بالنسبة لنا تزويدهم بالموارد.
وبمساعدة المقاييس ، نرى اتجاه استهلاك الموارد بواسطة أنظمة المعلومات لدينا. وبالفعل على أساسها يمكننا التخطيط لشيء ما. على مستوى المحاكاة الافتراضية ، نقوم بجمع البيانات والاطلاع على معلومات حول الكمية المتاحة من الموارد في سياق مراكز البيانات. وبالفعل داخل مركز البيانات ، يمكنك أن ترى الاستخدام والتوزيع الفعلي واستهلاك الموارد. علاوة على ذلك ، مع كل من الخوادم المستقلة والآلات الافتراضية ومجموعات الخوادم المادية ، والتي تدور عليها جميع هذه الأجهزة الافتراضية بقوة.
توقعات - وجهات نظر
الآن لدينا جوهر النظام ككل جاهز ، ولكن لا تزال هناك لحظات كافية للعمل عليها. هذه على الأقل طبقة من أمان المعلومات ، ولكن من المهم أيضًا الوصول إلى الشبكة وتطوير التنبيهات وحل المشكلة المتعلقة بالارتباط. لدينا الكثير من الطبقات والأنظمة ، وهناك العديد من المقاييس في كل طبقة. اتضح ماتريوشكا إلى درجة ماتريوشكا.
مهمتنا في النهاية هي إجراء التنبيهات الصحيحة. على سبيل المثال ، إذا كانت هناك مشكلة في الجهاز ، مرة أخرى ، مع جهاز افتراضي ، وكان هناك تطبيق مهم ، ولم يتم نسخ الخدمة احتياطيًا بأي شكل من الأشكال. نكتشف أن الآلة الافتراضية قد ماتت. ثم ينبهون مقاييس الأعمال: اختفى المستخدمون في مكان ما ، ولا يوجد تحويل ، وواجهة المستخدم غير متوفرة ، والبرامج والخدمات ماتت أيضًا.
في هذه الحالة ، سوف نتلقى رسائل غير مرغوب فيها من التنبيهات ، وهذا لم يعد يتناسب مع تنسيق نظام المراقبة الصحيح. يطرح سؤال الارتباط. لذلك ، من الناحية المثالية ، يجب أن يقول نظام المراقبة لدينا: "يا رفاق ، ماتت الآلة المادية الخاصة بك ، ومعها هذا التطبيق ومثل هذه المقاييس" ، بمساعدة تنبيه واحد ، بدلاً من قصفنا بشدة بمئات التنبيهات. يجب عليها الإبلاغ عن الشيء الرئيسي - السبب ، الذي يساهم في سرعة القضاء على المشكلة بسبب توطينها.
تم بناء نظام معالجة الإشعارات والتنبيهات لدينا حول خدمة الخط الساخن على مدار الساعة طوال أيام الأسبوع. يتم إرسال جميع التنبيهات التي تعتبر ضرورية بالنسبة لنا ويتم تضمينها في قائمة التحقق إلى هناك. يجب أن يحتوي كل تنبيه على وصف: ما حدث ، وماذا يعني في الواقع ، وماذا يؤثر. وأيضًا رابط إلى لوحة القيادة وإرشادات حول ما يجب فعله في هذه الحالة.
هذا كل ما يتعلق بمتطلبات إنشاء التنبيه. علاوة على ذلك ، يمكن أن يتطور الموقف في اتجاهين - إما أن تكون هناك مشكلة وتحتاج إلى حل ، أو كان هناك فشل في نظام المراقبة. لكن على أي حال ، عليك أن تذهب وتكتشف ذلك.
في المتوسط ، ينخفض إلينا الآن حوالي مائة تنبيه يوميًا ، وهذا مع مراعاة حقيقة أن ارتباط التنبيهات لم يتم تكوينه بشكل صحيح بعد. وإذا احتجنا إلى القيام بعمل تقني ، وقمنا بإيقاف تشغيل شيء ما بالقوة ، فإن عددهم ينمو بشكل كبير.
بالإضافة إلى مراقبة الأنظمة التي نقوم بتشغيلها وجمع المقاييس التي تعتبر مهمة من جانبنا ، يسمح لنا نظام المراقبة بجمع البيانات لفرق المنتج. يمكنهم التأثير على تكوين المقاييس داخل أنظمة المعلومات التي تتم مراقبتها هنا.
يمكن أن يأتي زميلنا ويطلب إضافة بعض المقاييس التي ستكون مفيدة لنا وللفريق. أو ، على سبيل المثال ، قد لا يكون لدى الفريق ما يكفي من المقاييس الأساسية التي لدينا ، فهم بحاجة إلى تتبع بعض المقاييس المحددة. في Grafana ، نقوم بإنشاء مساحة لكل فريق وإصدار حقوق المسؤول. أيضًا ، إذا احتاج الفريق إلى لوحات معلومات ، لكنهم لا يستطيعون / لا يعرفون كيفية القيام بذلك ، فنحن نساعدهم.
نظرًا لأننا خارج تيار خلق قيمة الفريق وإصداراتها والتخطيط لها ، فقد توصلنا تدريجيًا إلى استنتاج مفاده أن إصدارات جميع الأنظمة سلسة ويمكن نشرها يوميًا ، دون التنسيق معنا. ومن المهم بالنسبة لنا تتبع هذه الإصدارات ، لأنها يمكن أن تؤثر على تشغيل التطبيق وتعطل شيء ما ، وهذا أمر بالغ الأهمية. لإدارة الإصدارات ، نستخدم Bamboo ، حيث نحصل على البيانات من واجهة برمجة التطبيقات ويمكننا معرفة الإصدارات التي ظهرت فيها أنظمة المعلومات وحالتها. والشيء الأكثر أهمية في أي وقت. نحن نضع علامات الإصدار على المقاييس الهامة الرئيسية ، والتي تعتبر من الناحية المرئية دالة للغاية في حالة حدوث مشاكل.
بهذه الطريقة يمكننا أن نرى العلاقة بين الإصدارات الجديدة والقضايا الناشئة. الفكرة الرئيسية هي فهم كيفية عمل النظام على جميع الطبقات ، لتحديد موقع المشكلة بسرعة وحلها بنفس السرعة. في الواقع ، غالبًا ما يحدث أن يتم قضاء معظم الوقت في عدم حل المشكلة ، ولكن في العثور على السبب.
وفي هذا الاتجاه ، في المستقبل ، نريد التركيز على المبادرة. من الناحية المثالية ، أود أن أعرف مقدمًا عن مشكلة وشيكة ، وليس بعد وقوعها ، من أجل التعامل مع منعها ، وليس حلها. في بعض الأحيان تكون هناك إيجابيات خاطئة لنظام المراقبة ، سواء بسبب خطأ بشري أو بسبب التغييرات في التطبيق ، ونحن نعمل على ذلك ، وتصحيح الأخطاء ، ومحاولة تحذير المستخدمين من ذلك قبل أي تلاعب في نظام المراقبة الذي يستخدمه معنا. ، أو تنفيذ هذه الأحداث في النافذة الفنية.
لذا فقد تم إطلاق النظام ويعمل بنجاح منذ بداية الربيع ... ويظهر ربحًا حقيقيًا للغاية. بالطبع ، هذه ليست نسخته النهائية ، وسوف نقدم العديد من الميزات المفيدة. ولكن في الوقت الحالي ، مع وجود العديد من عمليات الدمج والتطبيقات ، فإن أتمتة المراقبة أمر لا غنى عنه حقًا.
إذا كنت تراقب أيضًا مشاريع كبيرة بعدد كبير من عمليات الدمج - فاكتب في التعليقات ما وجدته لهذا الغرض.