SRE (هندسة موثوقية الموقع) - طريقة لضمان توافر مشاريع الويب. يعتبر إطار عمل لـ DevOps ويحكي كيفية النجاح في تطبيق ممارسات DevOps. هذه المقالة عبارة عن ترجمة لنظام الفصل السادس لرصد النظم الموزعة من كتاب هندسة موثوقية الموقع من Google. أعددت هذه الترجمة بنفسي واعتمدت على تجربتي الخاصة في فهم عمليات المراقبة. في قناة telegrammonitorim_it والمدونة على المتوسط ​​، نشرت أيضًا رابطًا لترجمة الفصل الرابع من نفس الكتاب حول أهداف مستوى الخدمة.

الترجمة عن طريق القط. هل لديك قراءة لطيفة!

تمتلك فرق Google SRE المبادئ الأساسية وأفضل الممارسات لإنشاء أنظمة مراقبة وإعلام ناجحة. يقدم هذا الفصل توصيات حول المشكلات التي قد يواجهها زائر صفحة الويب وكيفية حل المشكلات التي تجعل من الصعب عرض صفحات الويب.

حدد

لا توجد مفردات تستخدم لمناقشة الموضوعات المتعلقة بالرصد. حتى في Google ، لا يتم استخدام المصطلحات أدناه بشكل شائع ، لكننا سنورد التفسيرات الأكثر شيوعًا.

مراقبة

جمع ومعالجة وتجميع وعرض البيانات الكمية في الوقت الفعلي عن النظام: عدد الطلبات وأنواع الطلبات ، وعدد الأخطاء وأنواع الأخطاء ، ووقت معالجة الطلب ووقت تشغيل الخادم.

رصد مربع أبيض

المراقبة بناءً على المقاييس التي يتم عرضها بواسطة المكونات الداخلية للنظام ، بما في ذلك السجلات أو مقاييس ملفات التعريف الخاصة بجهاز Java الظاهري أو معالج HTTP الذي يقوم بإنشاء إحصائيات داخلية.

رصد الصندوق الأسود

اختبار سلوك التطبيق من وجهة نظر المستخدم.

لوحة القيادة (لوحات المعلومات)

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

تنبيه (إشعار)

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

السبب الجذري

عيب في البرنامج أو عامل بشري لا ينبغي أن يحدث مرة أخرى عند التخلص منه. يمكن أن يكون للمشكلة عدة أسباب رئيسية: التشغيل الآلي غير الكافي للعمليات ، عيب البرمجيات ، دراسة غير كافية لمنطق التطبيق. يمكن أن يكون كل من هذه العوامل هو السبب الجذري ، ويجب القضاء على كل منها.

العقدة والآلة

مصطلحات قابلة للتبديل للإشارة إلى مثيل واحد لتطبيق قيد التشغيل على خادم فعلي أو جهاز ظاهري أو حاوية. يمكن أن يكون هناك العديد من الخدمات على جهاز واحد. قد تكون الخدمات:

• مرتبطة ببعضها البعض: على سبيل المثال ، خادم ذاكرة التخزين المؤقت وخادم الويب ؛
• خدمات غير مرتبطة على جهاز واحد: على سبيل المثال ، مستودع رمز ومعالج لنظام التهيئة ، مثل Puppet أو Chef .

دفع

أي تغيير في تكوين البرنامج.

لماذا هناك حاجة إلى الرصد

هناك عدة أسباب وراء ضرورة مراقبة التطبيقات:

تحليل الاتجاه الطويل

ما حجم قاعدة البيانات وما مدى سرعة نموها؟ كيف يتغير العدد اليومي للمستخدمين؟

مقارنة الأداء

هل استعلامات Acme Bucket of Bytes 2.72 أسرع من Ajax DB 3.14؟ ما هو أفضل بكثير يتم تخزين الطلبات مؤقتًا بعد ظهور عقدة إضافية؟ هل أصبح الموقع أبطأ مقارنة بالأسبوع الماضي؟

تنبيه (الإخطارات)

شيء ما مكسور ويحتاج شخص ما لإصلاحه. أو سوف ينفجر شيء ما قريبًا ويجب على شخص ما التحقق منه قريبًا.

إنشاء لوحات المعلومات

يجب أن تجيب لوحات المعلومات على الأسئلة الأساسية وتتضمن بعض "الإشارات الذهبية الأربع" - زمن الانتقال وحركة المرور والأخطاء والتحميل (التشبع).

إجراء تحليل بأثر رجعي (تصحيح)

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

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

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

تحديد التوقعات المعقولة من نظام المراقبة

يعد إعداد مراقبة تطبيق معقد في حد ذاته مهمة هندسية صعبة. حتى مع وجود بنية تحتية كبيرة من الأدوات لجمع وعرض وتنبيه ، فإن فريق Google SRE الذي يتكون من 10-12 عضوًا يشتمل عادة على شخص أو شخصين هدفهم الرئيسي هو إنشاء وصيانة أنظمة المراقبة. انخفض هذا المبلغ بمرور الوقت حيث نقوم بتعميم البنية التحتية للرصد ومركزتها ، لكن كل فريق من العاملين في SRE عادة ما يكون لديه موظف مراقبة واحد على الأقل. يجب أن أقول أنه على الرغم من أنه من المثير للاهتمام مشاهدة لوحات معلومات نظام المراقبة ، فإن فرق SRE تتجنب بعناية المواقف التي تتطلب من شخص ما أن ينظر إلى الشاشة لمراقبة المشاكل.

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

لقد عمل فريق Google SRE بنجاح متفاوت مع تسلسل هرمي التبعية المعقد. نادرًا ما نستخدم قواعد مثل "إذا اكتشفت أن قاعدة البيانات قد بدأت تعمل ببطء ، فستتلقى إخطارًا بشأن تباطؤ قاعدة البيانات ، وإلا فإنني أتلقى تنبيهًا بشأن موقع بطيء التشغيل." تنطبق القواعد المعتمدة على التبعية عادة على الأجزاء غير المستقرة من نظامنا ، مثل نظام لتصفية حركة مرور المستخدم إلى مركز البيانات. على سبيل المثال ، "إذا تم تكوين تصفية حركة المرور إلى مركز البيانات ، فلا تحذرني من التأخير في معالجة طلبات المستخدم" - فهذه قاعدة عامة للإشعارات من مركز البيانات. يدعم عدد قليل من الفرق في Google التسلسلات الهرمية المعقدة للاعتمادية نظرًا لأن بنيتنا التحتية لديها معدل إعادة بيع مستمر.

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

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

الأعراض مقابل الأسباب

يجب أن يجيب نظام المراقبة الخاص بك على سؤالين: "ما الذي تم كسره" و "لماذا اندلع"
"المكسور" يتحدث عن الأعراض ، و "لماذا يتم كسرها" عن السبب. يوضح الجدول أدناه أمثلة على هذه الحزم.

"ماذا" و "لماذا" هي بعض من أهم لبنات البناء لإنشاء نظام مراقبة جيد مع أقصى إشارة والحد الأدنى من الضوضاء.

الصندوق الاسود مقابل المربع الابيض

نحن نجمع بين مراقبة الصندوق الأبيض الواسعة مع مراقبة الصندوق الأسود المتواضعة للمقاييس الحيوية. أسهل طريقة لمقارنة Black-box مع White-box هي أن Black-box موجهة للأعراض وتتسم بردود فعل أكثر من كونها مراقبة استباقية: "النظام لا يعمل الآن." يعتمد المربع الأبيض على إمكانيات التحقق من النظام الداخلي: سجلات الأحداث أو خوادم الويب. وبالتالي ، فإن المربع الأبيض يسمح لك باكتشاف المشاكل المستقبلية ، والأعطال التي تبدو وكأنها إعادة إرسال الطلب ، إلخ.

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

عند جمع القياس عن بُعد ، تكون مراقبة الصندوق الأبيض مطلوبة لتصحيح الأخطاء. إذا كانت خوادم الويب تستجيب ببطء لاستعلامات قاعدة البيانات ، فستحتاج إلى معرفة مدى سرعة تفاعل خادم الويب مع قاعدة البيانات ومدى سرعة الاستجابة. خلاف ذلك ، لا يمكنك التمييز بين خادم قاعدة البيانات البطيئة ومشكلة الشبكة بين خادم الويب وقاعدة البيانات.

تتمتع ميزة مراقبة الصندوق الأسود بميزة أساسية عند إرسال التنبيهات: يمكنك بدء إشعار إلى المستلم عندما تكون المشكلة قد أدت بالفعل إلى أعراض حقيقية. من ناحية أخرى ، بالنسبة لمشكلة الصندوق الأسود التي لم تنشأ بعد ، ولكن وشيكة ، والرصد لا طائل منه.

أربع إشارات ذهبية

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

تأخير

الوقت اللازم لمعالجة الطلب. من المهم التمييز بين تأخير الطلبات الناجحة وغير الناجحة. على سبيل المثال ، يمكن تشخيص خطأ HTTP 500 الناجم عن فقدان الاتصال بقاعدة بيانات أو الواجهة الخلفية الأخرى بسرعة كبيرة ، ومع ذلك ، قد يشير خطأ HTTP 500 إلى فشل الطلب. يمكن أن يؤدي تحديد تأثير الخطأ 500 على التأخير الكلي إلى استنتاجات خاطئة. من ناحية أخرى ، فإن الخطأ البطيء هو حتى خطأ سريع! لذلك ، من المهم تتبع التأخير بخطأ ، وليس تصفية الأخطاء فقط.

مرور

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

أخطاء

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

التشبع

يوضح المقياس مدى استخدام خدمتك. هذا هو مقياس مراقبة النظام الذي يحدد الموارد الأكثر محدودية (على سبيل المثال ، في نظام ذا ذاكرة محدودة ، فإنه يُظهر الذاكرة ، في نظام به قيود I / O ، يظهر رقم I / O). لاحظ أن العديد من الأنظمة تقلل من الأداء قبل أن تصل إلى الاستخدام بنسبة 100٪ ، لذلك من المهم وجود غرض للاستخدام.

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

أخيرًا ، يرتبط التشبع أيضًا بتنبؤات التشبع الوشيك ، على سبيل المثال: "يبدو أن قاعدة البيانات الخاصة بك سوف تملأ القرص الصلب الخاص بك في 4 ساعات."

إذا قمت بقياس جميع الإشارات الذهبية الأربعة وعندما تنشأ مشكلة مع أحد المقاييس (أو ، في حالة التشبع ، مشكلة تقريبًا) ، قم بإخطار الشخص ، سيتم مراقبة خدمتك بشكل أو بآخر.

القلق حول الذيل (أو الأجهزة والأداء)

عند إنشاء نظام مراقبة من نقطة الصفر ، من المغري تطوير نظام يعتمد على متوسط ​​القيم: متوسط ​​زمن الوصول ، أو متوسط ​​استخدام عقد وحدة المعالجة المركزية أو متوسط ​​شغل قاعدة البيانات. خطر المثالين الأخيرين واضح: يتم التخلص من المعالجات وقواعد البيانات بطريقة لا يمكن التنبؤ بها للغاية. الشيء نفسه ينطبق على التأخير. إذا قمت بتشغيل خدمة ويب بمتوسط ​​تأخير يبلغ 100 مللي ثانية عند 1000 طلب في الثانية ، فقد يستغرق 1٪ من الطلبات 5 ثوانٍ. إذا كان المستخدمون يعتمدون على العديد من خدمات الويب هذه ، فإن النسبة المئوية التاسعة والتسعين للواجهة الخلفية يمكن أن تصبح بسهولة وقت استجابة الواجهة المتوسطة.

إن أبسط طريقة للتمييز بين المتوسط ​​البطيء و "ذيل" الاستعلامات بطيئة جدًا هي جمع أبعاد الاستعلام المعبر عنها في الإحصائيات (أداة مناسبة لعرض الرسوم البيانية) بدلاً من التأخير الفعلي: عدد الطلبات التي قدمتها الخدمة ، والتي استغرقت ما بين 0 مللي ثانية و 10 ms ، بين 10 ms و 30 ms ، بين 30 ms و 100 ms ، بين 100 ms و 300 ms ، إلخ. إن توسيع حدود المدرج التكراري تقريبًا بشكل كبير (مع معامل تقريبي 3) غالباً ما يكون طريقة بسيطة لتصور توزيع الاستعلامات.

اختيار المستوى التفصيلي الصحيح للقياسات

يجب قياس عناصر مختلفة من النظام بدرجات متفاوتة من التفاصيل. على سبيل المثال:

• مراقبة استخدام وحدة المعالجة المركزية الحمل في فترة زمنية محددة لن تظهر القيم المتطرفة على المدى الطويل التي تؤدي إلى الكمون العالية.
• من ناحية أخرى ، بالنسبة لخدمة ويب تركز على ما لا يزيد عن 9 ساعات من التوقف في السنة (99.9٪ من وقت التشغيل السنوي) ، من المحتمل أن يكون التحقق من استجابة HTTP البالغ 200 أكثر من مرة أو مرتين في الدقيقة متكررًا بشكل غير ضروري.
• وبالمثل ، فإن التحقق من توفر مساحة خالية على القرص الثابت بنسبة 99.9٪ أكثر من مرة واحدة كل دقيقتين ربما لا يكون ضروريًا.

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

1. قياس استخدام وحدة المعالجة المركزية كل ثانية.
2. تقليم التفاصيل إلى 5 ٪.
3. إجمالي المقاييس كل دقيقة.

ستسمح هذه الاستراتيجية بجمع البيانات بدرجة عالية من الدقة دون التعرض للتحليل العالي والتخزين.

بسيطة بقدر الإمكان ، ولكن ليس أسهل

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

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

مصادر المضاعفات المحتملة لا تنتهي أبدا. مثل جميع أنظمة البرمجيات ، يمكن أن تصبح المراقبة معقدة للغاية بحيث تصبح هشة ويصعب تغييرها وصيانتها.

لذلك ، صمم نظام المراقبة الخاص بك من أجل تبسيطه قدر الإمكان. عند اختيار ما تريد تتبعه ، تذكر ما يلي:

• , , , .
• , , (, SRE), .
• , , - - , .

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

ربط المبادئ معا

يمكن دمج المبادئ التي تمت مناقشتها في هذا الفصل في فلسفة المراقبة والتنبيه التي يتم اعتمادها واحترامها بواسطة فرق Google SRE. من المستحسن الالتزام بفلسفة المراقبة هذه ، فهي نقطة انطلاق جيدة لإنشاء أو مراجعة منهجية التنبيه ويمكن أن تساعد في طرح الأسئلة الصحيحة على خدمة التشغيل ، بغض النظر عن حجم مؤسستك أو تعقيد الخدمة أو النظام.

عند إنشاء قواعد مراقبة وتنبيه عن طريق طرح الأسئلة التالية ، يمكنك تجنب الإيجابيات الخاطئة والتنبيهات غير الضرورية:

• هل تكتشف هذه القاعدة وجود حالة غير قابلة للاكتشاف في النظام تكون ملحة وتدعو إلى اتخاذ إجراء وتؤثر حتما على المستخدم؟
• , , ? ?
• , ? , , , - , ?
• ? ? ? ?
• , ?

تعكس هذه الأسئلة الفلسفة الأساسية للتنبيهات وأنظمة التنبيه:

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

هذا النهج يمحو بعض الاختلافات: إذا كان الإخطار يستوفي الشروط الأربعة السابقة ، فلا يهم ما إذا كان قد تم إرسال الإشعار من نظام مراقبة White-Box أو Black-Box. يعزز هذا النهج أيضًا بعض الاختلافات: من الأفضل إنفاق المزيد من الجهد على تحديد الأعراض بدلاً من الأسباب ؛ عندما يتعلق الأمر بالأسباب ، فأنت بحاجة فقط للقلق بشأن الأسباب التي لا مفر منها.

رصد طويل الأجل

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

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

Bigtable SRE: تنبيه التاريخ

يتم توفير البنية الأساسية الداخلية لـ Google وقياسها من حيث مستوى الخدمة (SLO). منذ عدة سنوات ، كانت خدمة SLO في Bigtable تعتمد على متوسط ​​أداء المعاملات الاصطناعية التي تحاكي عميلاً عاملاً. نظرًا لوجود مشكلات في Bigtable وفي المستويات المنخفضة من مكدس تخزين البيانات ، كان متوسط ​​الأداء ناتجًا عن الذيل "الكبير": كان الأسوأ بنسبة 5٪ من الطلبات أبطأ كثيرًا من الباقي.

تم إرسال إعلامات البريد الإلكتروني عند اقترابها من عتبة SLO ، وتم إرسال التنبيهات إلى المرسِل عندما تم تجاوز SLO. تم إرسال كلا النوعين من التنبيهات في كثير من الأحيان بما فيه الكفاية ، وتستهلك كميات غير مقبولة من الوقت الهندسي: قضى الفريق قدرا كبيرا من الوقت في تحليل التنبيهات للعثور على عدد قليل من التي كانت ذات صلة حقا. غالبًا ما فاتنا مشكلة أثرت فعليًا على المستخدمين ، لأن بعض التنبيهات فقط كانت مخصصة لهذه المشكلة. كانت العديد من التنبيهات غير ملحّة نظرًا لوجود مشاكل مفهومة في البنية التحتية وتم إعدادها بطريقة قياسية ، أو لم تتم معالجتها على الإطلاق.

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

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

Gmail: استجابات قابلة للتنبؤ بها وخوارزمية من الأشخاص

في البداية ، تم إنشاء Gmail على نظام التحكم في عملية Workqueue المعدّل ، والذي تم إنشاؤه لدفعة أجزاء فهرس بحث العملية. تم تكييف Workqueue مع العمليات الطويلة الأمد ، ثم تم تطبيقه لاحقًا على Gmail ، ولكن تبين أن بعض الأخطاء في كود جدولة العتامة صعبة للغاية.

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

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

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

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

على المدى الطويل

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

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

استنتاج

الطريق إلى المراقبة والتنبيهات الصحية بسيط ومباشر. إنه يركز على أعراض المشكلة التي يتم إصدار التنبيهات الخاصة بها ، ومراقبة السبب بمثابة أداة مساعدة لتصحيح المشكلات. تكون أعراض المراقبة أسهل كلما كنت أعلى في المجموعة التي تتحكم فيها ، رغم أن مراقبة تحميل قاعدة البيانات والأداء يجب أن يتم ذلك مباشرة. إشعارات البريد الإلكتروني لها فوائد محدودة للغاية وتميل إلى النمو بسهولة إلى ضوضاء ؛ بدلاً من ذلك ، يجب عليك استخدام لوحة معلومات تراقب جميع المشكلات الحالية التي يتم إرسالها عبر البريد الإلكتروني. يمكن أيضًا إقران لوحة المعلومات بسجل أحداث لتحليل الارتباطات التاريخية.

على المدى الطويل ، من الضروري تحقيق تنبيهات ناجحة حول الأعراض والمشاكل الحقيقية التي لا يمكن تجنبها ، وتكييف الأهداف لضمان أن الرصد يدعم التشخيص السريع.

شكرا لقراءة الترجمة إلى النهاية. الاشتراك في بلادي آر حول برقية مراقبة monitorim_it و بلوق على وسائل .