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