SRE (هندسة موثوقية الموقع) هي طريقة لضمان توافر مشاريع الويب. ويعتبر إطار عمل لـ DevOps ويتحدث عن كيفية تحقيق النجاح في تطبيق ممارسات DevOps. الترجمة في هذه المقالة الكتب من جوجل. لقد قمت بإعداد هذه الترجمة بنفسي واعتمدت على تجربتي الخاصة في فهم عمليات المراقبة. في قناة التليجرام и كما قمت بنشر رابط لترجمة الفصل الرابع من نفس الكتاب عن أهداف مستوى الخدمة.
الترجمة عن طريق القطة. استمتع بالقراءة!
تتمتع فرق SRE التابعة لشركة Google بالمبادئ الأساسية وأفضل الممارسات لإنشاء أنظمة مراقبة وإشعارات ناجحة. يقدم هذا الفصل إرشادات حول المشكلات التي قد يواجهها زائر صفحة الويب وكيفية حل المشكلات التي تجعل عرض صفحات الويب أمرًا صعبًا.
حدد
لا توجد مفردات واحدة تستخدم لمناقشة المواضيع المتعلقة بالرصد. حتى على Google، لا يتم استخدام المصطلحات الواردة أدناه بشكل شائع، ولكننا سندرج التفسيرات الأكثر شيوعًا.
رصد
جمع ومعالجة وتجميع وعرض البيانات الكمية في الوقت الفعلي حول النظام: عدد الطلبات وأنواع الطلبات وعدد الأخطاء وأنواع الأخطاء ووقت معالجة الطلب ووقت تشغيل الخادم.
مراقبة الصندوق الأبيض
المراقبة بناءً على المقاييس التي تعرضها مكونات النظام الداخلية، بما في ذلك السجلات أو مقاييس ملفات تعريف Java Virtual Machine أو مقاييس معالج HTTP التي تنشئ إحصائيات داخلية.
مراقبة الصندوق الأسود
اختبار سلوك التطبيق من وجهة نظر المستخدم.
لوحة القيادة
واجهة (عادة ما تكون على شبكة الإنترنت) توفر نظرة عامة على المؤشرات الصحية الرئيسية للخدمات. قد تحتوي لوحة المعلومات على مرشحات، والقدرة على تحديد المؤشرات المعروضة، وما إلى ذلك. تم تصميم الواجهة لتحديد المؤشرات الأكثر أهمية للمستخدمين. يمكن للوحة المعلومات أيضًا عرض معلومات لموظفي الدعم الفني: قائمة انتظار الطلبات، وقائمة الأخطاء ذات الأولوية العالية، والمهندس المعين لمنطقة مسؤولية معينة.
تنبيه (إعلام)
الإخطارات التي يعتزم تلقيها شخص ما عبر البريد الإلكتروني أو وسائل أخرى، والتي قد تنتج عن أخطاء أو زيادة في قائمة انتظار الطلبات. يتم تصنيف الإخطارات على النحو التالي: التذاكر، وتنبيهات البريد الإلكتروني، ورسائل المراسلة الفورية.
السبب الجذري
عيب برمجي أو خطأ بشري، لا ينبغي أن يتكرر مرة أخرى بمجرد تصحيحه. قد يكون للمشكلة عدة أسباب رئيسية: عدم كفاية أتمتة العملية، أو وجود عيب في البرنامج، أو عدم كفاية توضيح منطق التطبيق. قد يكون كل من هذه العوامل هو السبب الجذري، ويجب التخلص من كل واحد منها.
العقدة والآلة (العقدة والآلة)
مصطلحات قابلة للتبديل للإشارة إلى مثيل واحد لتطبيق قيد التشغيل على خادم فعلي أو جهاز افتراضي أو حاوية. يمكن لجهاز واحد استضافة العديد من الخدمات. يمكن أن تكون الخدمات:
- متصلة ببعضها البعض: على سبيل المثال، خادم التخزين المؤقت وخادم الويب؛
- خدمات غير مرتبطة على قطعة واحدة من الأجهزة: على سبيل المثال، مستودع التعليمات البرمجية ومعالج لنظام التكوين، مثل أو .
دفع
أي تغيير في تكوين البرنامج.
لماذا المراقبة مطلوبة
هناك عدة أسباب وراء ضرورة مراقبة التطبيقات:
تحليل الاتجاهات طويلة المدى
ما حجم قاعدة البيانات وما مدى سرعة نموها؟ كيف يتغير العدد اليومي للمستخدمين؟
مقارنة الأداء
هل الطلبات أسرع على Acme Bucket of Bytes 2.72 مقارنة بـ Ajax DB 3.14؟ ما مدى جودة تخزين الطلبات مؤقتًا بعد ظهور عقدة إضافية؟ هل يعمل الموقع بشكل أبطأ مقارنة بالأسبوع الماضي؟
التنبيه (الإخطارات)
هناك شيء مكسور ويحتاج شخص ما إلى إصلاحه. أو سوف يتعطل شيء ما قريبًا ويحتاج شخص ما إلى التحقق منه قريبًا.
إنشاء لوحات المعلومات
يجب أن تجيب لوحات المعلومات على الأسئلة الأساسية وأن تتضمن شيئًا من — التأخير (زمن الوصول)، وحركة المرور (حركة المرور)، والأخطاء (الأخطاء) وحجم التحميل (التشبع).
إجراء التحليل بأثر رجعي (تصحيح الأخطاء)
لقد زاد تأخير معالجة الطلب، ولكن ماذا حدث في نفس الوقت تقريبًا؟
تعتبر أنظمة المراقبة مفيدة كمصدر للبيانات لأنظمة ذكاء الأعمال وتسهيل تحليل الحوادث الأمنية. ونظرًا لأن هذا الكتاب يركز على المجالات الهندسية التي تتمتع فيها شركات SRE بالخبرة، فلن نناقش تقنيات المراقبة هنا.
تسمح المراقبة والتنبيهات للنظام بإخبارك عندما يتعطل أو على وشك الانهيار. عندما يتعذر على النظام إصلاح نفسه تلقائيًا، نريد أن يقوم الإنسان بتحليل التنبيه وتحديد ما إذا كانت المشكلة لا تزال نشطة وحلها وتحديد السبب الجذري. إذا لم تقم بتدقيق مكونات النظام، فلن تتلقى تنبيهًا أبدًا لمجرد أن "هناك شيئًا غريبًا بعض الشيء".
إن إثقال كاهل الشخص بالإشعارات هو استخدام مكلف إلى حد ما لوقت الموظف. إذا كان الموظف يعمل، فسيقوم التنبيه بمقاطعة عملية العمل. إذا كان الموظف في المنزل، فإن التنبيه يقطع الوقت الشخصي وربما ينام. عندما تتكرر التنبيهات، يقوم الموظفون بتصفحها أو تأجيلها أو تجاهل التنبيهات الواردة. ومن وقت لآخر يتجاهلون التنبيه الحقيقي الذي تخفيه أحداث الضوضاء. يمكن أن تستمر انقطاعات الخدمة لفترات طويلة من الوقت حيث تمنع أحداث الضوضاء تشخيص المشكلة وتصحيحها بسرعة. تتمتع أنظمة الإنذار الفعالة بنسبة إشارة إلى ضوضاء جيدة.
وضع توقعات معقولة لنظام المراقبة
يعد إعداد المراقبة لتطبيق معقد مهمة هندسية معقدة في حد ذاتها. حتى مع وجود بنية تحتية كبيرة لأدوات الجمع والعرض والتنبيه، فإن فريق Google SRE المكون من 10 إلى 12 عضوًا يضم عادةً شخصًا أو شخصين هدفهم الأساسي هو إنشاء أنظمة المراقبة وصيانتها. لقد انخفض هذا العدد بمرور الوقت حيث نقوم بتوحيد البنية التحتية للمراقبة وجعلها مركزية، ولكن كل فريق SRE عادةً ما يكون لديه شخص واحد على الأقل مخصص للمراقبة فقط. علينا أن نقول أنه على الرغم من أن لوحات معلومات نظام المراقبة مثيرة للاهتمام للغاية للنظر إليها، إلا أن فرق SRE تتجنب بعناية المواقف التي تتطلب من شخص ما النظر إلى الشاشة لمراقبة المشكلات.
بشكل عام، انتقلت Google إلى أنظمة مراقبة بسيطة وسريعة باستخدام أدوات التحليل المثالية بعد وقوع الحادث. نحن نتجنب الأنظمة "السحرية" التي تحاول التنبؤ بالحدود أو اكتشاف السبب الجذري تلقائيًا. إن أجهزة الاستشعار التي تكتشف المحتوى غير المقصود في طلبات المستخدم النهائي هي المثال المضاد الوحيد؛ وطالما ظلت هذه المستشعرات بسيطة، يمكنها اكتشاف أسباب الحالات الشاذة الخطيرة بسرعة. تعد التنسيقات الأخرى لاستخدام بيانات المراقبة، مثل تخطيط السعة أو التنبؤ بحركة المرور، أكثر تعقيدًا. إن المراقبة على مدى فترة زمنية طويلة جدًا (أشهر أو سنوات) بمعدل أخذ عينات منخفض (ساعات أو أيام) ستكشف عن اتجاه طويل المدى.
حقق فريق Google SRE نجاحًا متباينًا مع التسلسلات الهرمية المعقدة للتبعيات. نادرًا ما نستخدم قواعد مثل "إذا اكتشفت أن قاعدة البيانات بطيئة، أحصل على تنبيه بأن قاعدة البيانات بطيئة، وإلا أحصل على تنبيه بأن الموقع بطيء". تشير القواعد المستندة إلى التبعية عادةً إلى أجزاء غير قابلة للتغيير من نظامنا، مثل نظام تصفية حركة مرور المستخدم إلى مركز البيانات. على سبيل المثال، "إذا تم تكوين تصفية حركة المرور إلى مركز البيانات، فلا تنبهني بشأن التأخير في معالجة طلبات المستخدم" فهي إحدى القواعد العامة للتنبيهات من مركز البيانات. يدعم عدد قليل من الفرق في Google التسلسلات الهرمية المعقدة للتبعيات نظرًا لأن بنيتنا التحتية تتمتع بمعدل ثابت من إعادة الهيكلة المستمرة.
لا تزال بعض الأفكار الموضحة في هذا الفصل ذات صلة: هناك دائمًا فرصة للانتقال بشكل أسرع من الأعراض إلى السبب الجذري، خاصة في الأنظمة المتغيرة باستمرار. لذلك، بينما يوضح هذا الفصل بعض أهداف أنظمة المراقبة وكيفية تحقيق تلك الأهداف، فمن المهم أن تكون أنظمة المراقبة بسيطة ومفهومة لكل فرد في الفريق.
وبالمثل، للحفاظ على مستويات الضوضاء منخفضة ومستويات الإشارة مرتفعة، يجب أن تكون أساليب مراقبة الأصول المنبهة بسيطة وموثوقة للغاية. يجب أن تكون القواعد التي تولد تحذيرات للأشخاص سهلة الفهم وتمثل مشكلة واضحة.
الأعراض مقابل الأسباب
يجب أن يجيب نظام المراقبة الخاص بك على سؤالين: "ما الذي انكسر" و"لماذا انكسر".
"ما الذي كسر" يتحدث عن العرض، و"لماذا كسر" يتحدث عن السبب. ويبين الجدول أدناه أمثلة على هذه الاتصالات.
عرض
سبب
الحصول على خطأ HTTP 500 أو 404
ترفض خوادم قاعدة البيانات الاتصالات
استجابات الخادم بطيئة
استخدام عالي لوحدة المعالجة المركزية (CPU) أو كابل إيثرنت تالف
لا يتلقى المستخدمون في القارة القطبية الجنوبية صور GIF للقطط
CDN الخاص بك يكره العلماء والقطط، لذلك تم إدراج بعض عناوين IP في القائمة السوداء
أصبح المحتوى الخاص متاحًا من كل مكان
أدى طرح إصدار برنامج جديد إلى جعل جدار الحماية ينسى جميع قوائم ACL ويسمح للجميع بالدخول
يعد "ماذا" و"لماذا" من أهم العناصر الأساسية لإنشاء نظام مراقبة جيد بأقصى قدر من الإشارة وأقل قدر من الضوضاء.
الصندوق الأسود مقابل الصندوق الأبيض
نحن نجمع بين مراقبة الصندوق الأبيض الشاملة ومراقبة الصندوق الأسود المتواضعة للمقاييس المهمة. أسهل طريقة لمقارنة الصندوق الأسود بالصندوق الأبيض هي أن الصندوق الأسود يركز على الأعراض وهو تفاعلي وليس مراقبة استباقية: "النظام لا يعمل بشكل صحيح في الوقت الحالي". يعتمد المربع الأبيض على إمكانيات التحقق الداخلية للأنظمة: سجلات الأحداث أو خوادم الويب. وبالتالي، يتيح لك المربع الأبيض اكتشاف المشكلات الوشيكة، والأخطاء التي تبدو وكأنها إعادة إرسال لطلب، وما إلى ذلك.
لاحظ أنه في النظام متعدد الطبقات، يكون العَرَض في منطقة مسؤولية أحد المهندسين هو عرض في منطقة مسؤولية مهندس آخر. على سبيل المثال، انخفض أداء قاعدة البيانات. تعد عمليات قراءة قاعدة البيانات البطيئة أحد أعراض قاعدة البيانات SRE التي تكتشفها. ومع ذلك، بالنسبة لواجهة SRE الأمامية التي تراقب موقع ويب بطيئًا، فإن سبب قراءة قاعدة البيانات البطيئة نفسها هو بطء قاعدة البيانات. لذلك، تركز مراقبة المربع الأبيض أحيانًا على الأعراض وأحيانًا تركز على السبب، اعتمادًا على مدى اتساع نطاقها.
عند جمع القياس عن بعد لتصحيح الأخطاء، يلزم مراقبة المربع الأبيض. إذا كانت خوادم الويب بطيئة في الاستجابة لاستعلامات قاعدة البيانات، فأنت بحاجة إلى معرفة مدى سرعة اتصال خادم الويب بقاعدة البيانات ومدى سرعة استجابته. وإلا فلن تتمكن من التمييز بين خادم قاعدة البيانات البطيء ومشكلة الشبكة بين خادم الويب وقاعدة البيانات.
تتمتع مراقبة الصندوق الأسود بميزة رئيسية عند إرسال التنبيهات: حيث تقوم بتشغيل الإشعار إلى المستلم عندما تؤدي المشكلة بالفعل إلى ظهور أعراض حقيقية. في المقابل، لا جدوى من المراقبة لمشكلة الصندوق الأسود التي لم تظهر بعد ولكنها وشيكة.
أربع إشارات ذهبية
إشارات المراقبة الذهبية الأربعة هي الكمون، وحركة المرور، والأخطاء، والتشبع. إذا كان بإمكانك قياس أربعة مقاييس لنظام المستخدم فقط، فركز على تلك الأربعة.
تأخير
الوقت اللازم لمعالجة الطلب. من المهم التمييز بين زمن الوصول للطلبات الناجحة وغير الناجحة. على سبيل المثال، يمكن تشخيص خطأ HTTP 500 الناتج عن فقدان الاتصال بقاعدة بيانات أو أي واجهة خلفية أخرى بسرعة كبيرة، ومع ذلك، قد يشير خطأ HTTP 500 إلى فشل الطلب. قد يؤدي تحديد تأثير الخطأ 500 على زمن الوصول الإجمالي إلى استنتاجات خاطئة. ومن ناحية أخرى، الخطأ البطيء هو خطأ سريع! لذلك، من المهم مراقبة زمن وصول الأخطاء بدلاً من مجرد تصفية الأخطاء.
مرور
يتم قياس عدد الطلبات المقدمة إلى نظامك بمقاييس النظام عالية المستوى. بالنسبة لخدمة الويب، يمثل هذا القياس عادةً عدد طلبات HTTP في الثانية، مقسومًا على طبيعة الطلبات (على سبيل المثال، المحتوى الثابت أو الديناميكي). بالنسبة لنظام البث الصوتي، قد يركز هذا القياس على سرعة الإدخال/الإخراج للشبكة أو عدد الجلسات المتزامنة. بالنسبة لنظام تخزين القيمة الرئيسية، يمكن أن يكون هذا القياس عبارة عن معاملات أو نتائج بحث في الثانية.
أخطاء
هذا هو معدل الطلبات الفاشلة الصريحة (مثل HTTP 500)، أو الضمنية (مثل HTTP 200 ولكنها مدمجة مع محتوى غير صالح) أو السياسة (على سبيل المثال "إذا التقطت استجابة في ثانية واحدة، فإن أي ثانية واحدة تعتبر خطأ"). إذا لم تكن رموز استجابة HTTP كافية للتعبير عن جميع حالات الفشل، فقد تكون هناك حاجة إلى بروتوكولات ثانوية (داخلية) لاكتشاف الفشل الجزئي. قد لا تكون مراقبة جميع هذه الطلبات الفاشلة مفيدة، في حين أن اختبارات النظام الشاملة ستساعد في اكتشاف أنك تقوم بمعالجة محتوى غير صحيح.
تشبع
يوضح المقياس مدى كثافة استخدام خدمتك. هذا هو مقياس مراقبة النظام الذي يحدد الموارد الأكثر تقييدًا (على سبيل المثال، في نظام مقيد بالذاكرة، يُظهر الذاكرة، على نظام الإدخال/الإخراج المقيد، يُظهر عدد عمليات الإدخال/الإخراج). لاحظ أن العديد من الأنظمة تؤدي إلى انخفاض الأداء قبل أن تصل إلى نسبة 100% من الاستخدام، لذا فإن وجود هدف استخدام أمر مهم.
في الأنظمة المعقدة، يمكن استكمال التشبع بقياسات حمل ذات مستوى أعلى: هل تستطيع خدمتك التعامل بشكل صحيح مع حركة المرور المزدوجة، أو التعامل مع حركة مرور أكثر بنسبة 10% فقط، أو التعامل مع حركة مرور أقل مما تفعل حاليًا؟ بالنسبة للخدمات البسيطة التي لا تحتوي على معلمات تغير تعقيد الطلب (على سبيل المثال، "لا تعطني شيئًا" أو "أحتاج إلى عدد صحيح رتيب فريد")، والتي نادرًا ما تغير التكوين، قد تكون قيمة اختبار التحميل الثابت كافية. ومع ذلك، كما تمت مناقشته في الفقرة السابقة، يجب أن تستخدم معظم الخدمات إشارات غير مباشرة مثل استخدام وحدة المعالجة المركزية (CPU) أو عرض النطاق الترددي للشبكة، والتي لها حد أعلى معروف. غالبًا ما يكون الكمون المتزايد مؤشرًا رئيسيًا للتشبع. يمكن أن يوفر قياس وقت الاستجابة المئوي التاسع والتسعين في نافذة صغيرة (على سبيل المثال، دقيقة واحدة) إشارة مبكرة جدًا للتشبع.
أخيرًا، يرتبط التشبع أيضًا بالتنبؤات حول التشبع الوشيك، على سبيل المثال: "يبدو أن قاعدة بياناتك سوف تملأ محرك الأقراص الثابتة لديك خلال 4 ساعات".
إذا قمت بقياس جميع الإشارات الذهبية الأربعة وعندما تكون هناك مشكلة في أحد المقاييس (أو، في حالة التشبع، مشكلة قريبة)، فإنك تنبه شخصًا ما، وستتم تغطية خدمتك بشكل أو بآخر عن طريق المراقبة.
مخاوف بشأن "الذيل" (أو الأجهزة والأداء)
عند إنشاء نظام مراقبة من البداية، هناك إغراء لتطوير نظام يعتمد على متوسط القيم: متوسط زمن الوصول، أو متوسط استخدام وحدة المعالجة المركزية للعقد، أو متوسط امتلاء قاعدة البيانات. إن خطر المثالين الأخيرين واضح: يتم التخلص من المعالجات وقواعد البيانات بطريقة لا يمكن التنبؤ بها على الإطلاق. الأمر نفسه ينطبق على التأخير. إذا قمت بتشغيل خدمة ويب بمتوسط زمن وصول يبلغ 100 مللي ثانية مع 1000 طلب في الثانية، فقد يستغرق 1% من الطلبات 5 ثوانٍ. إذا كان المستخدمون يعتمدون على العديد من خدمات الويب هذه، فإن النسبة المئوية الـ 99 لواجهة خلفية واحدة يمكن أن تصبح بسهولة متوسط وقت الاستجابة للواجهة الأمامية.
إن أبسط طريقة للتمييز بين المتوسط البطيء للطلبات والذيل البطيء جدًا هي جمع قياسات الطلبات المعبر عنها في الإحصائيات (أداة جيدة للعرض هي الرسوم البيانية) بدلاً من زمن الاستجابة الفعلي: كم عدد الطلبات التي قدمتها الخدمة والتي استغرقت ما بين 0 مللي ثانية و10 مللي ثانية، بين 10 مللي ثانية و30 مللي ثانية، بين 30 مللي ثانية و100 مللي ثانية، بين 100 مللي ثانية و300 مللي ثانية، وما إلى ذلك. غالبًا ما يكون توسيع حدود الرسم البياني بشكل كبير (بعامل تقريبي 3) طريقة بسيطة لتصور التوزيع من الطلبات.
اختيار المستوى المناسب من التفاصيل للقياسات
يجب قياس العناصر المختلفة للنظام على مستويات مختلفة من التفاصيل. على سبيل المثال:
- لن تُظهِر مراقبة استخدام وحدة المعالجة المركزية على مدار فترة زمنية ارتفاعات طويلة المدى تؤدي إلى فترات استجابة عالية.
- من ناحية أخرى، بالنسبة لخدمة ويب لا تستهدف أكثر من 9 ساعات من التوقف سنويًا (وقت تشغيل سنوي بنسبة 99,9%)، فمن المحتمل أن يكون التحقق من استجابة HTTP 200 أكثر من مرة أو مرتين في الدقيقة أمرًا متكررًا دون داع.
- وبالمثل، ربما لا يكون من الضروري التحقق من مساحة القرص الصلب للتأكد من توفرها بنسبة 99,9% أكثر من مرة كل دقيقة أو دقيقتين.
انتبه إلى كيفية تنظيم دقة قياساتك. يمكن أن يوفر جمع حمل وحدة المعالجة المركزية مرة واحدة في الثانية بيانات مثيرة للاهتمام، ولكن مثل هذه القياسات المتكررة قد تكون مكلفة للغاية لجمعها وتخزينها وتحليلها. إذا كان هدف المراقبة الخاص بك يتطلب دقة عالية ولا يتطلب استجابة عالية، فيمكنك تقليل هذه التكاليف عن طريق إعداد مجموعة المقاييس على الخادم ثم إعداد نظام خارجي لتجميع تلك المقاييس وتجميعها. يمكنك:
- قياس حمل وحدة المعالجة المركزية كل ثانية.
- تقليل التفاصيل إلى 5%.
- تجميع المقاييس كل دقيقة.
ستسمح لك هذه الإستراتيجية بجمع البيانات بدقة عالية دون تكبد تكاليف تحليل وتخزين عالية.
بسيطة قدر الإمكان، ولكن ليس أبسط
يمكن أن يؤدي تراكب المتطلبات المختلفة فوق بعضها البعض إلى نظام مراقبة معقد للغاية. على سبيل المثال، قد يحتوي نظامك على العناصر المعقدة التالية:
- تنبيهات وفقًا لحدود مختلفة لزمن وصول معالجة الطلب، بنسب مئوية مختلفة، لجميع أنواع المؤشرات المختلفة.
- كتابة تعليمات برمجية إضافية لكشف وتحديد الأسباب المحتملة.
- قم بإنشاء لوحات المعلومات ذات الصلة لكل سبب من الأسباب المحتملة للمشاكل.
مصادر المضاعفات المحتملة لا تنتهي أبدًا. مثل جميع الأنظمة البرمجية، يمكن أن تصبح المراقبة معقدة للغاية بحيث تصبح هشة ويصعب تغييرها وصيانتها.
لذلك، قم بتصميم نظام المراقبة الخاص بك لتبسيطه قدر الإمكان. عند اختيار ما تريد تتبعه، ضع ما يلي في الاعتبار:
- يجب أن تكون القواعد التي تحدد الأحداث الحقيقية في أغلب الأحيان بسيطة ويمكن التنبؤ بها وموثوقة قدر الإمكان.
- يجب إزالة تكوين جمع البيانات وتجميعها والتنبيه الذي يتم إجراؤه بشكل غير متكرر (على سبيل المثال، أقل من ربع سنوي لبعض فرق SRE).
- المقاييس التي تم جمعها ولكن لم يتم عرضها في أي لوحة معلومات معاينة أو المستخدمة بواسطة أي تنبيه هي مرشحة للحذف.
في جوجل، يعمل جمع وتجميع المقاييس الأساسية، جنبًا إلى جنب مع التنبيهات ولوحات المعلومات، بشكل جيد كنظام مستقل نسبيًا (يتم تقسيم نظام مراقبة جوجل فعليًا إلى عدة أنظمة فرعية، لكن الأشخاص عادة ما يكونون على دراية بجميع جوانب هذه الأنظمة الفرعية). قد يكون من المغري الجمع بين المراقبة والتقنيات الأخرى لفحص الأنظمة المعقدة: ملفات تعريف النظام التفصيلية، وتصحيح أخطاء العمليات، وتتبع التفاصيل حول الاستثناءات أو حالات الفشل، واختبار التحميل، وجمع السجلات وتحليلها، أو فحص حركة المرور. في حين أن معظم هذه الأشياء لها قواسم مشتركة مع المراقبة الأساسية، فإن خلطها معًا سيؤدي إلى نتائج كثيرة جدًا ويخلق نظامًا معقدًا وهشًا. كما هو الحال مع العديد من الجوانب الأخرى لتطوير البرمجيات، فإن دعم الأنظمة المختلفة بنقاط تكامل واضحة وبسيطة وغير مترابطة هو أفضل استراتيجية (على سبيل المثال، استخدام واجهة برمجة تطبيقات الويب لاسترداد البيانات المجمعة بتنسيق يمكن أن يظل ثابتًا على مدى فترة طويلة من الزمن ).
ربط المبادئ معًا
يمكن دمج المبادئ التي تمت مناقشتها في هذا الفصل في فلسفة المراقبة والتنبيه التي يتم اعتمادها واتباعها من قبل فرق Google SRE. إن الالتزام بفلسفة المراقبة هذه أمر مرغوب فيه، ويعد نقطة انطلاق جيدة لإنشاء أو مراجعة منهجية التنبيه الخاصة بك، ويمكن أن يساعدك على طرح الأسئلة الصحيحة المتعلقة بوظيفة العمليات الخاصة بك، بغض النظر عن حجم مؤسستك أو مدى تعقيد الخدمة أو النظام.
عند إنشاء قواعد المراقبة والتنبيه، يمكن أن يساعدك طرح الأسئلة التالية في تجنب النتائج الإيجابية الخاطئة والتنبيهات غير الضرورية:
- هل تكتشف هذه القاعدة حالة النظام الملحة التي لا يمكن اكتشافها، والتي تدعو إلى اتخاذ إجراء، وتؤثر حتمًا على المستخدم؟
- هل يمكنني تجاهل هذا التحذير مع العلم أنه حميد؟ متى ولماذا يمكنني تجاهل هذا التحذير وكيف يمكنني تجنب هذا السيناريو؟
- هل يعني هذا التنبيه أن المستخدمين يتأثرون سلبًا؟ هل هناك مواقف لا يتأثر فيها المستخدمون سلبًا، مثل تصفية حركة المرور أو عند استخدام أنظمة الاختبار التي يجب تصفية التنبيهات لها؟
- هل يمكنني اتخاذ إجراء استجابة لهذا التنبيه؟ هل هذه الإجراءات عاجلة أم يمكن الانتظار حتى الصباح؟ هل يمكن أتمتة الإجراء بأمان؟ هل سيكون هذا الإجراء حلاً طويل الأمد أم حلاً مؤقتًا؟
- يتلقى بعض الأشخاص تنبيهات متعددة بشأن هذه المشكلة، فهل هناك طريقة لتقليل عدد التنبيهات؟
تعكس هذه الأسئلة الفلسفة الأساسية لأنظمة التنبيهات والتحذير:
- في كل مرة يأتي تنبيه، لا بد لي من الرد على الفور. يمكنني الرد بشكل عاجل عدة مرات في اليوم قبل أن أشعر بالتعب.
- يجب أن يكون كل تنبيه ذا صلة.
- يجب أن تتطلب كل استجابة للإنذار تدخلاً بشريًا. إذا كان من الممكن معالجة الإشعار تلقائيًا، فلا ينبغي أن يصل.
- يجب أن تكون التنبيهات حول مشكلة أو حدث جديد لم يكن موجودًا من قبل.
هذا النهج يطمس بعض الفروق: إذا استوفى التنبيه الشروط الأربعة السابقة، فلا يهم ما إذا كان التنبيه قد تم إرساله من نظام مراقبة الصندوق الأبيض أو الصندوق الأسود. ويعزز هذا النهج أيضًا بعض الاختلافات: فمن الأفضل أن نبذل المزيد من الجهد في تحديد الأعراض بدلاً من بذل جهد في تحديد الأسباب؛ عندما يتعلق الأمر بالأسباب، ما عليك سوى القلق بشأن الأسباب الحتمية.
مراقبة طويلة المدى
في بيئات الإنتاجية الحالية، تقوم أنظمة المراقبة بمراقبة نظام إنتاج دائم التطور مع بنية البرامج المتغيرة وخصائص عبء العمل وأهداف الأداء. قد تصبح التنبيهات التي يصعب تشغيلها تلقائيًا أمرًا شائعًا، وربما تستحق المعالجة. في هذه المرحلة، يجب على شخص ما العثور على الأسباب الجذرية للمشكلة والقضاء عليها؛ إذا لم يكن هذا الحل ممكنًا، فإن الاستجابة للتنبيه تتطلب أتمتة كاملة.
ومن المهم أن يتم اتخاذ قرارات المراقبة مع وضع الأهداف طويلة المدى في الاعتبار. كل تنبيه يتم تشغيله اليوم يصرف انتباه الشخص عن تحسين النظام غدًا، لذلك غالبًا ما يكون هناك انخفاض في توفر أو أداء النظام الإنتاجي للوقت اللازم لتحسين نظام المراقبة على المدى الطويل. دعونا نلقي نظرة على مثالين لتوضيح هذه الظاهرة.
Bigtable SRE: قصة الإفراط في التنبيه
عادةً ما يتم توفير البنية الأساسية الداخلية لشركة Google وقياسها وفقًا لمستوى الخدمة (SLO). منذ سنوات عديدة، كان SLO الخاص بخدمة Bigtable يعتمد على متوسط أداء المعاملة الاصطناعية التي تحاكي عميلًا حيًا. نظرًا لوجود مشكلات في Bigtable والمستويات المنخفضة لمكدس التخزين، كان متوسط الأداء مدفوعًا بذيل "كبير": كانت أسوأ 5% من الاستعلامات غالبًا أبطأ بشكل ملحوظ من البقية.
تم إرسال إشعارات البريد الإلكتروني عند الاقتراب من حد SLO، وتم إرسال تنبيهات المراسلة عند تجاوز SLO. تم إرسال كلا النوعين من التنبيهات في كثير من الأحيان، مما استهلك قدرًا غير مقبول من الوقت الهندسي: قضى الفريق قدرًا كبيرًا من الوقت في فرز التنبيهات للعثور على القليل منها ذي الصلة بالفعل. لقد فاتنا في كثير من الأحيان مشكلة أثرت فعليًا على المستخدمين لأن بعض التنبيهات فقط كانت تتعلق بهذه المشكلة المحددة. العديد من التنبيهات لم تكن عاجلة بسبب مشاكل مفهومة في البنية التحتية وتمت معالجتها بطريقة قياسية، أو لم تتم معالجتها على الإطلاق.
لمعالجة الموقف، اتخذ الفريق نهجًا ثلاثي المحاور: أثناء العمل الجاد لتحسين أداء Bigtable، قمنا مؤقتًا بتعيين هدف SLO الخاص بنا ليكون النسبة المئوية الخامسة والسبعين لزمن استجابة الاستجابة للاستعلام. لقد قمنا أيضًا بإيقاف تشغيل تنبيهات البريد الإلكتروني نظرًا لوجود الكثير منها بحيث كان من المستحيل قضاء الوقت في تشخيصها.
أتاحت لنا هذه الإستراتيجية فرصة للبدء في إصلاح المشكلات طويلة المدى في Bigtable والمستويات الأدنى من حزمة التخزين، بدلاً من إصلاح المشكلات التكتيكية باستمرار. يمكن للمهندسين إنجاز العمل دون تعرضهم لوابل من التنبيهات طوال الوقت. في النهاية، سمح لنا تأجيل معالجة التنبيهات مؤقتًا بتحسين جودة خدماتنا.
Gmail: استجابات بشرية خوارزمية يمكن التنبؤ بها
في بدايته، تم بناء Gmail على نظام إدارة عمليات Workqueue المعدل الذي تم تصميمه لتجميع أجزاء العملية في فهرس البحث. تم تكييف قائمة انتظار العمل مع العمليات طويلة الأمد وتم تطبيقها لاحقًا على Gmail، ولكن ثبت أنه من الصعب جدًا إصلاح بعض الأخطاء في كود الجدولة غير الشفاف.
في ذلك الوقت، تم تنظيم مراقبة Gmail بحيث يتم تشغيل التنبيهات عند إلغاء المهام الفردية باستخدام Workqueue. لم يكن هذا النهج مثاليًا، لأنه حتى في ذلك الوقت، كان Gmail ينفذ عدة آلاف من المهام، وتم توفير كل منها لجزء صغير من المائة من مستخدمينا. لقد كنا مهتمين جدًا بتزويد مستخدمي Gmail بتجربة مستخدم جيدة، ولكن التعامل مع هذا العدد الكبير من التنبيهات كان بعيدًا عن متناول اليد.
لمعالجة هذه المشكلة، أنشأ Gmail SRE أداة للمساعدة في تصحيح أخطاء المجدول بأفضل شكل ممكن لتقليل التأثير على المستخدمين. أجرى الفريق بعض المناقشات حول ما إذا كان يجب ببساطة أتمتة الدورة بأكملها بدءًا من اكتشاف المشكلة وحتى علاجها حتى يتم العثور على حل طويل الأمد، لكن البعض كان يشعر بالقلق من أن مثل هذا الحل قد يؤخر إصلاح المشكلة فعليًا.
كان هذا التوتر شائعًا في الفريق وغالبًا ما كان يعكس عدم الثقة في الانضباط الذاتي: فبينما يرغب بعض أعضاء الفريق في إتاحة الوقت للإصلاح الصحيح، يشعر آخرون بالقلق من نسيان الإصلاح النهائي وأن الإصلاح المؤقت سيستغرق إلى الأبد. تستحق هذه المشكلة الاهتمام لأنه من السهل جدًا حل المشكلات مؤقتًا بدلاً من جعل الوضع دائمًا. يلعب المديرون والموظفون الفنيون دورًا رئيسيًا في تنفيذ الإصلاحات طويلة المدى، ودعم وترتيب أولويات الإصلاحات المحتملة طويلة المدى حتى بعد أن يهدأ "الألم" الأولي.
يجب أن تكون التنبيهات المنتظمة والمتكررة والاستجابات الخوارزمية علامة حمراء. إن إحجام فريقك عن أتمتة هذه التنبيهات يعني أن الفريق يفتقر إلى الثقة في إمكانية الوثوق بالخوارزميات. وهذه مشكلة خطيرة تحتاج إلى معالجة.
طويل الأمد
هناك موضوع مشترك يربط بين أمثلة Bigtable وGmail: المنافسة بين التوفر على المدى القصير والطويل. في كثير من الأحيان، يمكن لجهد قوي أن يساعد النظام الهش على تحقيق توافر عالي، ولكن هذا المسار عادة ما يكون قصير الأجل، ومليئًا بإرهاق الفريق والاعتماد على عدد صغير من أعضاء نفس الفريق البطولي.
غالبًا ما يكون التخفيض المتحكم فيه على المدى القصير للتوافر مؤلمًا، ولكنه مهم من الناحية الاستراتيجية لاستقرار النظام على المدى الطويل. ومن المهم عدم النظر إلى كل تنبيه على حدة، ولكن النظر فيما إذا كان المستوى الإجمالي لحجم التنبيه يؤدي إلى نظام صحي يمكن الوصول إليه بشكل صحيح مع فريق قابل للاستمرار وتوقعات إيجابية. نقوم بتحليل إحصائيات تكرار التنبيه (يتم التعبير عنها عادةً كحادث لكل نوبة، حيث قد يتكون الحادث من عدة حوادث ذات صلة) في تقارير ربع سنوية إلى الإدارة، مما يسمح لصانعي القرار بالحصول على رؤية مستمرة لحمل نظام التنبيه والصحة العامة للفريق.
اختتام
إن الطريق إلى المراقبة والتنبيه الصحيين بسيط وواضح. فهو يركز على أعراض المشكلة التي تؤدي إلى تشغيل التنبيهات، كما تعمل مراقبة السبب بمثابة أداة مساعدة لتصحيح الأخطاء. تكون مراقبة الأعراض أسهل كلما كنت في مستوى أعلى في المكدس الذي تتحكم فيه، على الرغم من أن مراقبة تحميل قاعدة البيانات وأدائها يجب أن تتم مباشرة على قاعدة البيانات نفسها. إشعارات البريد الإلكتروني لها فائدة محدودة للغاية وتميل إلى أن تصبح ضجيجًا بسهولة؛ بدلاً من ذلك، يجب عليك استخدام لوحة معلومات تراقب جميع المشكلات الحالية التي تؤدي إلى تنبيهات البريد الإلكتروني. يمكن أيضًا إقران لوحة المعلومات بسجل الأحداث لتحليل الارتباطات التاريخية.
على المدى الطويل، من الضروري تحقيق تناوب ناجح للتنبيهات حول الأعراض والمشاكل الحقيقية الوشيكة، وتكييف الأهداف لضمان أن المراقبة تدعم التشخيص السريع.
شكرا لقرائتكم الترجمة للنهاية. اشترك في قناتي على التليجرام خاصة بالمراقبة и .
المصدر: www.habr.com