Dziiiiiiin! في الثالثة صباحًا ، تشاهد حلمًا رائعًا وفجأة - جرس. هذا الأسبوع أنت في الخدمة ، ويبدو أن شيئًا ما قد حدث. يدعو النظام الآلي إلى معرفة ما هو الأمر. هذه نقطة مهمة في إدارة أنظمة الكمبيوتر الحديثة ، ولكن دعونا نرى كيفية جعل الإشعارات أكثر ملاءمة للأشخاص.
تعرف على فلسفة المراقبة التي ولدت على مدار عدة عقود من واجباتي في فرق المراقبة المختلفة. تأثرت إلى حد كبير بالكتاب المقدس الحقيقي من Rob Evashchuk My Philosophy on Alerting ، المتضمنة في كتاب Google SRE ، وكتاب اعتبارات John Alspo لتصميم التنبيه .
Kelly Dunn و Aridzhit Mukheryi و Maxim Petazzoni - شكرًا للمساعدة في تحرير المنشور .
ما هي القضية؟
قررت الخروج باختصار جميل مثل طريقة استخدام Brendan Gregg أو طريقة توم ويلكي RED . أنا أسمي هذا الأسلوب CASE . يصف أربع نقاط تحتاج إلى الانتباه إليها عند العمل باستخدام المراقبة التلقائية:
إذا كنت تستخدم CASE ، فإنك تعامل الإخطارات مع عدم مبالاة صحية ولا تستيقظ الناس في الليل. يجب أن يتم تقييم المراقبة بانتظام من أجل المنفعة والفعالية. عندما يتلقى شخص ما إشعارًا ، سيكون لديه نماذج عقلية أفضل ومزيد من الثقة.
لتيسير التذكر ، تخيل أنك بحاجة إلى CASE [أي ، الحالة ، والسبب هو تعليق مترجم ] لتبرير كل حالة تأهب. : النظارات الشمسية:
ولماذا هذا كل شيء؟
واجب يمكن أن يكون عذاب . لأسباب كثيرة. وقضية لن القضاء عليهم جميعا. ولكن مع ذلك في الليل سوف تستيقظ من الإخطارات أفضل. تغطي هذه الطريقة العمليات التنظيمية المختلفة التي ستساعد أيضًا في هذا الأمر.
جمال أساليب RED و USE هو أنه بمساعدتهم ، لا نعرف فقط كيفية العمل ، ولكننا نتحدث أيضًا نفس اللغة مع بعضنا البعض. آمل أنه مع طريقة CASE سيكون من الأسهل مناقشة الإخطارات التي تحمي أنظمتنا ، لكن لا تعطِ الراحة للزملاء.
خلاصة القول هي أنك تحتاج إلى إنشاء ثقافة في المنظمة حيث يتم التعامل مع الإخطارات باللامبالاة الصحية. قد يتم إنشاء إعلامات في هذه الحالة ، ولكن ليس حقيقة أنها لن تفقد القيمة في وقت لاحق. لماذا قمنا بإعداد هذا الإشعار؟ هل تمت مراجعة معاييرها منذ فترة طويلة؟ مع CASE ، يمكن الإجابة على هذه الأسئلة.
سياق ثقيل - سياق ملزم
الساعة 3 صباحًا ليست أفضل وقت لقراءة الرسائل التي تحتوي على الكثير من الكلمات الطنانة. للرد بفعالية ، تحتاج إلى معلومات. من الناحية المثالية ، يجب أن تكون هذه معلومات حول مشكلة محددة ، يكون السياق فيها واضحًا على الفور ، وتحتاج إلى تكوين الإشعارات بحيث يكون ذلك ممكنًا. هذه هي "الملاحظة" و "التوجه" من دورة NORD . ليس من المؤسف أن تقضي بعض الوقت في هذا الإعداد ، لأن صرف انتباه الشخص باستمرار يكون أكثر تكلفة. دعونا نحترم بعضنا البعض.
المشاكل لها العديد من المصادر. أشباح خاصة.
كيفية مساعدة المصاحبة؟ يرى الضابط المناوب الإخطار أولاً ، لذلك يبني جميع الفرضيات بناءً عليه. ثم ينظر إلى التعليمات ولوحات المعلومات ، ولكن هل هناك دائمًا معلومات حول إشعار محدد ، وليس فقط معلومات عامة؟ تنصح Alspo "بالتفكير في كيفية تفسير الإشعار أو الرد عليه" (الشريحة 29) 1 . يركز الإخطار الجيد على ما يصاحب ذلك ، ولا يتم تكوينه فقط على قيمة عتبة.
لذلك ، إليك أفكار لتحسين سياق الإعلام:
- أظهر للمستخدم شيئًا مفيدًا ومُنشأًا على وجه التحديد ، وليس مجرد تعليمات عادية أو لوحة معلومات. في السابق ، استخدمنا أنا والأشخاص لوحات المعلومات للتحقيق ، وتم تكوينها لإشعارات محددة. هذا سوف يساعد إذا كانت المشكلة معروفة ، والخلط فقط في حالات أخرى. هنا تحتاج إلى إيجاد توازن.
- أخبرنا عن سجل الإشعارات: هل هو جديد؟ هل غالبا ما تعمل؟ هل هو موسمي؟
- عرض التغييرات الأخيرة في حالة النظام. هل تغير أي شيء مؤخرًا؟ (على سبيل المثال ، نشر أو تمكين / تعطيل وظيفة.)
- إظهار العلاقة وإعطاء معلومات للنموذج العقلي: يجب أن تكون تبعيات النظام مرئية بوضوح ، ويفضل أن يكون ذلك مع إشارة إلى قابلية التشغيل.
- قم بربط المستخدم بالفريق بسرعة: هل يرى الأحداث الحالية أم هل يمكنه معرفة من آخر في الشركة تلقى الإخطار؟ هل تم تنشيط برنامج إدارة الحوادث ؟
من الناحية المثالية ، يقدم برنامج إدارة الحوادث نصائح حول كيفية تحسين سياق الإعلام عند التحقيق في الحوادث. هناك دائما شيء للعمل عليه!
عملي - قيمة عملية
يجب أن تفعل ما يصاحب ذلك ردا على الإخطار؟ إذا لم يكن هناك شيء يجب القيام به أو أنه من غير الواضح ما يجب فعله ، فلماذا أيقظت؟ من الضروري تجنب الإخطارات التي تتولى الخدمة ولا تتطلب إجراءً.
ماذا تفعل؟ ماذا تحتاج؟
في السابق ، عندما كانت الأنظمة بسيطة وكانت الفرق صغيرة ، أنشأنا المراقبة لمواكبة التطورات. الإخطار بزيادة الحمل على الكومة سوف يعطينا سياقًا إذا تعطلت الخدمة. على نطاق واسع ، سوف تخلط هذه الإخطارات فقط ، لأن أنظمتنا تعمل دائمًا في حالة تدهور شديد الشدة. هذا يؤدي بسرعة إلى التعب من الإخطارات ، وبطبيعة الحال ، إلى فقدان الحساسية. لذلك ، يتجاهل المصاحب أو حتى يقوم بتصفية هذه الإشعارات ولا يستجيب لها دائمًا حسب الحاجة. لا تسقط في هذا الفخ! لا تقم بتكوين جميع الإشعارات في صف واحد ، بحيث يمكنك إرسالها لاحقًا عن طريق البريد إلى بعض مجلدات godforsaken.
إليك ما يبدو عليه الإشعار ذي القيمة العملية:
- يتطلب الإشعار اتخاذ إجراء ، وليس فقط الإبلاغ عن الأخبار.
- هذا الإجراء صعب أو محفوف بالمخاطر لأتمتة. إذا كان الإجراء ممكنًا ، فقم به وأتمتة ، توقف عن مضايقة الناس!
- يحتوي الإشعار على توصيات عاجلة في شكل اتفاقية مستوى الخدمة (SLA) أو وقت الاسترداد المستهدف (RTO). ثم يمكن للمضيف استخدام برنامج إدارة الحوادث في المنظمة.
أريد أن أوضح: أنا لا أقول أن الإخطارات يجب أن تأتي فقط على أهم اتفاقيات مستوى الخدمة (أهداف مستوى الخدمة ، أهداف مستوى الخدمة) لواجهة برمجة التطبيقات. مراقبة SLO مجزأة ومقسمة باستمرار ويتطلب نفس النهج لجميع الخدمات. من الواضح أنك ستتعقب أهم اتفاقيات SLO للعملاء الذين يدفعون لك. لكن البنية التحتية لـ SLO ، مثل قواعد البيانات ، تحتاج أيضًا إلى مراقبتها. قريبا سوف تضطر إلى التعامل مع العملاء الداخليين ودعمهم. وهلم جرا الإعلان اللانهائي.
القائم على الأعراض - التركيز على الأعراض
سواء أعجبك ذلك أم لا ، فأنت تعمل في نظام موزع (Kavaj) 2 . نتيجة لذلك ، يمكنك استخدام تكتيكات مختلفة لعزل الخدمات وحمايتها من حالات الفشل (Trainor et al.) 3. على الرغم من أن مجموعة البيانات المهملة طويلة المدى أو استعلام مدروس إلى قاعدة البيانات يشير إلى وجود مشاكل ، فلا توجد حاجة للاندفاع لإصلاحها إذا لم يواجه المستخدمون أية مشكلات في المستقبل القريب.
هذه إشارات مهمة ، ويمكن أن تكون ذات قيمة عملية ، ولكن إذا لم تتداخل مع المستخدمين ، فهذا ليس بالأمر الملح للغاية لتشتيت الانتباه. الإخطارات المستندة إلى السبب هي لقطات لنماذجنا العقلية لفشل النظام. من الأفضل تتبع الأعراض المهمة من محاولة سرد جميع الأسباب المحتملة للفشل.
لكي تكون الإعلامات ذات قيمة عملية ، ركز على مؤشرات الأداء المهمة للمستخدمين. Evashchuk يدعو هذا "مراقبة للمستخدمين". تذكر أن هذه الفلسفة تحتاج إلى تطبيقها في جميع أنحاء المنظمة. إذا واجهت الخدمة مشاكل عاجلة في مكان ما في البنية التحتية ، فسيقوم الفريق المناسب بالتعامل معها. تعد حماية الأنظمة من مثل هذه الإخفاقات مشكلة منفصلة تمامًا (Trainer et al. ، قسم عن استراتيجيات تقليل التبعيات الحرجة) 3 .
الأعراض ليست متقلبة جدا
يتذكر ريتشارد كوك أنه يوجد في النظم المعقدة الكثير من العيوب وأوجه القصور والمشاكل 4 . محاولة لسرد جميع الأسباب المحتملة - العمل سيزيف. تحاول وصف المشاكل ، وهي تتغير في كل وقت. تعتقد سيندي سريدهاران أن "الأنظمة لا يجب أن تكون في حالة ممتازة كل ثانية" ومن الأفضل استخدام نهج أكثر إنسانية ( "مراقبة النظم الموزعة" ، 7) 5 .
تجنب الإخطارات الحادث
عادةً ما يتم تكوين إعلامات لأسباب لتصحيح الحوادث. وهذه الإشعارات المحدودة حول حقيقة ما حدث تخلق شعورًا زائفًا بالثقة ، لأنه في كل مرة يأتي النظام بطرق جديدة لكسرها.
لا تنخدع بإخطارات الأسباب. فكر بشكل أفضل:
- لماذا لم يلاحظ الإشعار المستند إلى الأعراض المشكلة؟
- هل سيكون من المفيد تحسين سياق المستخدم؟
- كيفية تحسين أدوات المراقبة من أجل تشخيص الإخطارات بشكل أسرع وعدم تجميع ما حدث؟
لن تساعد أدوات المراقبة للتشخيص إلا إذا أخذتها كوسيلة للانتقال من أعراض إلى حل. بدون هذه التعليقات ، سوف تغمرك ببساطة الإخطارات والرسوم البيانية المتأخرة عن الإخفاقات السابقة - وليس كلمة عن الإخفاقات المستقبلية. بالنسبة لمنظمة ، هذه فرصة رائعة للانتقال من الدفاع إلى الهجوم. وسيكون للمطورين ومديري المنتجات نفس التوقعات والأهداف الواضحة. Case - CASE (: wink :) - لكل إخطار واضح.
معتدلة التسامح الإخطارات القائمة
في بعض الأحيان ، لا يترك لنا نظامنا أي خيار من حيث الإشعارات بناءً على السبب. وأحيانًا يدرك الحاضرون جيدًا أن الأعراض ستؤدي بالضرورة إلى حدوث خلل ، مما يعني أنه يحتوي على قيمة عملية. ربما لم تكن متأكدًا مما يجري وتقوم بإعداد إعلامات لإعادة التأمين. دعونا نأمل أن يكون هذا الإجراء مطلوبًا مؤقتًا حتى نغير النظام لحل مشكلة تدهور الأداء.
كن على علم بمكونات CASE الأخرى عند التعامل مع مثل هذه الحالات. إذا كان هذا مؤقتًا ، فهذا لا يعني أنه لا يمكنك التفكير برأسك.
تقييم - التقييم
أي تغييرات في النظام (كود جديد ، بنية أساسية جديدة ، أي شيء جديد) تعمل على توسيع نطاق الإخفاقات (Cook، 3). 4 هل لا يزال هذا الإشعار يعمل كما هو متوقع؟ تعد نماذج النظم العقلية الواضحة وذات الصلة وخبرة الاستجابة لبعض الإخطارات لدعم النهج الوقائي من السمات الرئيسية لمنظمة موجهة نحو التعلم . العيوب في النظم تتطور باستمرار ، ويجب علينا مواكبة لهم.
تحتاج إلى إجراء تقييم مستمر لجودة كل إشعار حتى تعمل كما هو متوقع. القادة الأعزاء! سيكون من الأسهل على فرقك إذا ساعدتهم في إعداد هذه العملية! فيما يلي بعض الأفكار للتقييم:
- استخدم هندسة الفوضى أو أيام الألعاب أو طرق اختبار الإخطار الأخرى. يمكن للفريق القيام بذلك من تلقاء نفسه دون استخدام نظام إدارة الحوادث الثقيلة!
- قم بتضمين جمع البيانات عن جميع إخطارات الحوادث في برنامج إدارة الحوادث. حدد علامة مفيدة أو ضارة أو غير لائقة أو غير مفهومة ، إلخ. استخدمها كردود فعل.
- الإخطارات الصحيحة نادرة ومدققة بعناية. تأكد من أن جميع الروابط تعمل ، وأشر إلى السياق الصحيح ، وما إلى ذلك.
- إذا لم يتم إطلاق النار أو الإشعال في كثير من الأحيان ، فهناك خطأ ما في ذلك. إصلاحه أو إزالته. احذر من الإفراط في السلبية أو النشاط!
- تعيين الطوابع الزمنية لانتهاء الصلاحية للإشعارات. إذا انقضى تاريخ انتهاء الصلاحية ، فقم بتقييم الإشعار باستخدام طريقة CASE وقم بتحديث الطابع الزمني. تحقق بانتظام من تاريخ انتهاء الصلاحية ، كما هو الحال مع الطعام.
- تبسيط عملية تحسين الإخطارات. استخدم المراقبة في شكل تعليمات برمجية وقم بتخزين الإشعارات في مستودع Git. تجمع طلبات المساعدة في جذب فريق ، وسيكون لديك تاريخ من الإخطارات السابقة. وستتوقف عن الخوف من تغيير الإشعارات أو طلب إذن من المسؤولين عنها.
- قم بإعداد إشعارات الملاحظات ، حتى لو كان مجرد نموذج Google ، بحيث يقوم الأشخاص الذين يقومون بواجب الخدمة بتمييز الإشعارات على أنها غير مجدية أو متطفلة. قم بتضمين رابط أو دعوة للعمل في الإشعار نفسه وتحقق من التعليقات بانتظام.
- حدد قاعدة في الفريق - دع الحاضرين يعملون على تبسيط الواجب عندما يكون هناك القليل من العمل. دع كل شيء يصبح أفضل بعدك مما كان عليه من قبل.
استنتاج
أعتقد أن طريقة CASE تساعد المطورين والمؤسسات على مناقشة إعداد وإرسال الإشعارات التلقائية. يمكن لأحد المطورين البدء في تقييم الإشعارات باستخدام طريقة CASE ، وبعد ذلك ستنضم إليه المؤسسة بأكملها مع المطورين الآخرين وبرامج الإدارة وإدارة الحوادث للحفاظ على الإشعارات في حالة جيدة. ليست هناك حاجة إلى أدوات خاصة أو عمليات معقدة لهذا الغرض.
يجب أن تفكر الصناعة بأكملها في العامل البشري أثناء أداء الواجب دون المساس بخدمة العملاء من الدرجة الأولى. كل هذه الأدوات والممارسات يمكن ويجب تحسينها. آمل أن تساعد طريقة CASE في ذلك.
استمتع الإخطارات المحسنة!
