جييييييين! في الساعة الثالثة صباحًا ، أنت تشاهد حلمًا رائعًا ، وفجأة - مكالمة. أنت في الخدمة هذا الأسبوع ، ولا بد أن شيئًا ما قد حدث. يستدعي نظام آلي لاكتشاف الخطأ. هذه نقطة مهمة في إدارة أنظمة الكمبيوتر الحديثة ، ولكن دعنا نرى كيفية جعل الإشعارات أكثر ملاءمة للأشخاص.
تلبية فلسفة المراقبة ، التي ولدت على مدى عدة عقود من واجباتي في فرق المراقبة المختلفة. لقد تأثرت إلى حد كبير بالكتاب المقدس الحقيقي لروب يفاشوك (فلسفة إشعاري) ، المضمنة في كتاب ، وكتاب جون Allspaugh (ملاحظات على تكوين التنبيهات).
, и شكرا لمساعدتي في تحرير المنشور.
ما هي CASE؟
قررت أن أصل باختصار جميل ، مثل أو . اسميها طريقة CASE. يصف أربع نقاط يجب الانتباه إليها عند العمل مع المراقبة التلقائية:
- (رابط إلى السياق)
- (قيمة عملية)
- (التركيز على الأعراض)
- (درجة)
إذا كنت تستخدم CASE ، فإنك تتعامل مع الإشعارات بلامبالاة صحية ولا تستيقظ الأشخاص ليلاً. يجب تقييم الرصد بانتظام من أجل الفائدة والفعالية. عندما يتلقى الشخص إشعارًا ، سيكون لديه نماذج عقلية أفضل وثقة أكبر.
لتسهيل التذكر ، تخيل أنك بحاجة إلى CASE [أي حالة ، والسبب هو ملاحظة المترجم] لتبرير كل تنبيه. :نظارة شمسيه:
ولماذا كل هذا؟
. لأسباب عدة. ولن تقضي CASE عليهم جميعًا. ولكن مع ذلك في الليل سوف تستيقظ من الإخطارات الأفضل. تغطي هذه الطريقة العمليات التنظيمية المختلفة التي ستساعد أيضًا في هذا الأمر.
يكمن جمال أساليب RED و USE في أنه بمساعدتهم لا نعرف فقط كيفية العمل ، ولكن أيضًا نتحدث نفس اللغة مع بعضنا البعض. آمل أن تسهل طريقة CASE مناقشة الإخطارات التي تحمي أنظمتنا ولكنها تطارد زملائنا.
خلاصة القول هي أننا بحاجة إلى خلق ثقافة في المؤسسة حيث يتم التعامل مع الإشعارات بلامبالاة صحية. يمكن إنشاء الإخطارات على أساس الحالة ، ولكن ليس من المؤكد أنها لن تفقد قيمتها لاحقًا. لماذا قمنا بإعداد هذا الإخطار؟ هل تم مراجعة المعايير لفترة طويلة؟ مع CASE ، يمكن الإجابة على هذه الأسئلة.
سياق ثقيل - ملزم بالسياق
3 صباحًا ليس أفضل وقت لقراءة الرسائل التي تحتوي على الكثير من الكلمات الطنانة. للرد بشكل فعال ، تحتاج إلى معلومات. من الناحية المثالية ، يجب أن تكون هذه معلومات حول مشكلة معينة ، يكون سياقها واضحًا على الفور ، ويجب تكوين الإخطارات بحيث يكون ذلك ممكنًا. هذه "الملاحظة" و "التوجه" . ليس من المؤسف قضاء بعض الوقت في هذا المكان ، لأن تشتيت انتباه الشخص باستمرار يكون أكثر تكلفة. دعونا نحترم بعضنا البعض.
المشاكل لها مصادر عديدة. خاصة الأشباح.
كيف تساعد المصاحبة؟ بادئ ذي بدء ، يرى المصاحب الإخطار ، فيبني عليه جميع الفرضيات. ثم يلقي نظرة على التعليمات ولوحات المعلومات ، ولكن هل هناك دائمًا بيانات حول إشعار محدد ، وليس مجرد معلومات عامة؟ ينصح Olspaugh "بالتفكير في كيفية تفسير الإشعار أو الرد عليه" (الشريحة 29). يكون الإعلام الجيد موجهًا للحاضر ولا يتم تكوينه فقط بواسطة عتبة.
لذلك ، إليك أفكار حول كيفية تحسين سياق الإخطارات:
- أظهر للمستخدم شيئًا مفيدًا ومصممًا لغرض معين ، وليس فقط التعليمات المعتادة أو لوحة القيادة. في الماضي ، كنت أنا والرجال نستخدم لوحات المعلومات الاستقصائية التي تم إعدادها لإشعارات محددة. سيساعد هذا في حالة معرفة المشكلة ، والتشويش فقط في حالات أخرى. هنا تحتاج إلى إيجاد توازن.
- أخبرنا عن تاريخ الإشعار: هل هو جديد؟ هل تعمل في كثير من الأحيان؟ هل هو موسمي؟
- إظهار التغييرات الأخيرة في حالة النظام. هل تغير أي شيء مؤخرًا؟ (على سبيل المثال ، قم بنشر أو تمكين / تعطيل الوظيفة.)
- أظهر العلاقات وقدم معلومات للنموذج العقلي: يجب أن تكون تبعيات النظام مرئية بوضوح ، ويفضل أن يكون ذلك مع إشارة إلى قابلية التشغيل.
- ربط المستخدم بسرعة بالفريق: هل يرى الأحداث الحالية أم يمكنه معرفة من تلقى الإشعار أيضًا في الشركة؟ برنامج مفعل؟
من الناحية المثالية ، يقدم برنامج إدارة الحوادث المشورة بشأن كيفية تحسين سياق الإخطار في التحقيقات في الحادث. هناك دائما شيء للعمل عليه!
قابلة للتنفيذ - قيمة عملية
هل ينبغي للمرافق أن يفعل شيئًا ردًا على الإخطار؟ إذا لم تكن بحاجة إلى فعل أي شيء أو لم يكن من الواضح ما يجب عليك فعله ، فلماذا استيقظت؟ تحتاج إلى تجنب الإشعارات التي تصل إلى الخدمة ولا تتطلب اتخاذ إجراء.
ما يجب القيام به؟ ماذا تريد؟
في الماضي ، عندما كانت الأنظمة بسيطة وكانت الفرق صغيرة ، قمنا بإعداد المراقبة لنكون على دراية فقط. سيعطينا الإشعار بأن الحمل على كومة الذاكرة المؤقتة قد زاد السياق إذا تعطلت الخدمة لاحقًا. على نطاق واسع ، فإن مثل هذه الإشعارات ستربك فقط ، لأن أنظمتنا تعمل دائمًا في حالة تدهور متفاوتة الخطورة. هذا يؤدي بسرعة إلى وبالطبع فقدان الحساسية. لذلك ، يتجاهل المصاحب أو حتى يقوم بتصفية مثل هذه الإشعارات ولا يستجيب لها دائمًا كما ينبغي. لا تسقط في هذا الفخ! لا تقم بإعداد جميع الإخطارات على التوالي ، بحيث يمكنك لاحقًا إرسالها إلى البريد في مجلد godforsaken.
إليك ما يبدو عليه الإشعار بقيمة عملية:
- يتطلب الإخطار اتخاذ إجراءات ، وليس مجرد الإبلاغ عن الأخبار.
- هذا الإجراء صعب أو محفوف بالمخاطر في أتمتة. إذا كان من الممكن أتمتة الإجراء ، فقم بأتمتة الإجراء ، وتوقف عن إزعاج الناس!
- يحتوي الإشعار على توصيات عاجلة في شكل (جيش تحرير السودان) أو (R.T.O.). يمكن للمضيف بعد ذلك استدعاء برنامج إدارة الحوادث الخاص بالمنظمة.
أريد أن أوضح: أنا لا أقول أن الإشعارات يجب أن تأتي فقط لأهم SLO (أهداف مستوى الخدمة ، أهداف مستوى الخدمة) لواجهة برمجة التطبيقات. مراقبة SLO مجزأة ومقسمة باستمرار وتتطلب نفس النهج لجميع الخدمات. من الواضح أنك ستتتبع أهم SLOs للعملاء الذين يدفعون لك. لكن SLOs للبنية التحتية ، مثل قواعد البيانات ، تحتاج أيضًا إلى التتبع. سيتعين عليك قريبًا التعامل مع العملاء الداخليين ودعمهم. وهكذا إلى ما لا نهاية.
على أساس الأعراض - التركيز على الأعراض
شئنا أم أبينا انت تعمل بنظام موزع (كواج). نتيجة لذلك ، تستخدم أساليب مختلفة لعزل الخدمات وحمايتها من الفشل (ترينور وآخرون) 3. وعلى الرغم من أن عملية جمع البيانات المهملة المطولة أو استعلام قاعدة البيانات الذي تم التفكير فيه يشير إلى وجود مشكلات ، يجب ألا تتسرع في إصلاحها إذا لم يواجه المستخدمون مشكلات في المستقبل القريب.
هذه إشارات مهمة ، ويمكن أن تكون ذات قيمة عملية ، ولكن إذا لم تزعج المستخدمين ، فليس من الملح بما يكفي لتشتيت الانتباه. الإخطارات المستندة إلى السبب هي لقطات لنماذجنا العقلية لفشل النظام. من الأفضل تتبع الأعراض المهمة بدلاً من محاولة سرد جميع الأسباب المحتملة للفشل.
لكي تكون الإشعارات قابلة للتنفيذ ، ركز على التي تعتبر مهمة للمستخدمين. يسميها Evashchuk "المراقبة للمستخدمين". تذكر أنه يجب تطبيق هذه الفلسفة في جميع أنحاء المنظمة. إذا كانت الخدمة تعاني من مشاكل ملحة في مكان ما في أعماق البنية التحتية ، فسيتم الاهتمام بها من قبل الفريق المناسب. تعد حماية الأنظمة من مثل هذه الإخفاقات مسألة منفصلة تمامًا (المدرب وآخرون ، القسم الخاص باستراتيجيات تقليل التبعيات الحرجة).
الأعراض ليست متغيرة
يتذكر ريتشارد كوك أن الأنظمة المعقدة مليئة بالعيوب والعيوب والمشاكل.. محاولة سرد جميع الأسباب المحتملة هي المخاض العبثي. أنت تحاول وصف المشاكل ، وهي تتغير طوال الوقت. تعتقد سيندي سريدهاران أن "الأنظمة لا يجب أن تكون في حالة ممتازة كل ثانية" وأنه من الأفضل استخدام نهج أكثر إنسانية ( ("Distributed Systems Watch") ، 7).
تجنب الإخطارات بعد وقوع الحادث
عادة ، يتم تكوين إخطارات الأسباب لإصلاح الحوادث. وهذه الإخطارات المحدودة حول حقيقة ما حدث تخلق إحساسًا زائفًا بالثقة ، لأن النظام يأتي في كل مرة بطرق جديدة للكسر.
لا تنخدع بإشعارات الأسباب. فكر بشكل أفضل:
- لماذا لم يلاحظ الإخطار المستند إلى الأعراض المشكلة؟
- هل سيكون من المفيد تحسين السياق للمستخدم؟
- كيفية تحسين أدوات المراقبة للتشخيص بشكل أسرع وعدم تجميع الإخطارات حول ما حدث؟
لن تساعد أدوات المراقبة التشخيصية إلا إذا كنت تراها كوسيلة للانتقال من الأعراض إلى الحل. بدون هذه التعليقات ، ستغمر ببساطة بالإخطارات والمخططات المتأخرة للإخفاقات السابقة - وليس كلمة واحدة عن الإخفاقات المستقبلية. بالنسبة للمنظمة ، هذه فرصة رائعة للانتقال من الدفاع إلى الهجوم. وسيكون للمطورين ومديري المنتجات نفس التوقعات والأهداف الواضحة. الحالة - CASE (: wink :) - لكل إخطار واضح.
الإخطارات القائمة على السبب مقبولة باعتدال
في بعض الأحيان ، يترك لنا نظامنا القليل من الخيارات أو لا يترك لنا أي خيار فيما يتعلق بالإخطارات القائمة على السبب. وأحيانًا يدرك الحاضرون جيدًا أن الأعراض ستؤدي بالضرورة إلى الفشل ، مما يعني أنه يحتوي على قيمة عملية. ربما لست متأكدًا مما يحدث وتقوم بإعداد الإشعارات لتكون في الجانب الآمن. دعونا نأمل أن يكون هذا الإجراء مطلوبًا بشكل مؤقت حتى نغير النظام لمعالجة مشكلة تدهور الأداء.
ضع في اعتبارك المكونات الأخرى لـ CASE عند التعامل مع هذه المواقف. فقط لأنه مؤقت لا يعني أنه يمكنك التوقف عن التفكير.
مقيمة
أي تغيير في النظام (رمز جديد ، بنية تحتية جديدة ، أيًا كان جديدًا) يوسع نطاق الإخفاقات (Cook ، 3). هل ما زال هذا الإخطار يعمل كما هو متوقع؟ نماذج ذهنية واضحة وحديثة للأنظمة وخبرة في الرد على بعض إشعارات الدعم هي السمات الرئيسية . تتطور عيوب الأنظمة باستمرار ، وعلينا مواكبة ذلك.
تحتاج إلى تقييم جودة كل إشعار باستمرار حتى يعمل على النحو المتوقع. أيها القادة الأعزاء! سيكون الأمر أسهل بكثير على فرقك إذا ساعدتهم في بدء هذه العملية وتشغيلها! فيما يلي بعض أفكار التقييم:
- استخدم , أو طرق اختبار الإخطار الأخرى. يمكن للفريق القيام بذلك بأنفسهم دون الحاجة إلى استخدام نظام إدارة الحوادث الثقيلة!
- دمج جمع البيانات لجميع إخطارات الحادث في برنامج إدارة الحوادث. ضع علامة على أنها مفيدة ، أو ضارة ، أو غير مناسبة ، أو غير مفهومة ، إلخ. استخدمها كتعليقات.
- تنطلق الإخطارات المناسبة بشكل غير منتظم ويتم اختبارها بعناية. تأكد من أن جميع الروابط تعمل ، وتشير إلى السياق الصحيح ، وما إلى ذلك.
- إذا لم يتم إطلاق الإشعار أو إطلاقه كثيرًا ، فهناك خطأ ما في ذلك. إصلاحه أو حذفه. احذر من السلبية المفرطة أو النشاط المفرط!
- تعيين الطوابع الزمنية للإشعارات مع تاريخ انتهاء الصلاحية. إذا انتهى تاريخ انتهاء الصلاحية ، فقم بتقييم الإشعار باستخدام طريقة CASE وقم بتحديث الطابع الزمني. تحقق من تاريخ انتهاء الصلاحية بانتظام ، تمامًا كما هو الحال مع الطعام.
- تبسيط عملية تحسين الإخطارات. استخدم إشعارات المراقبة والمراقبة القائمة على الكود في مستودع Git. تساعد طلبات السحب في إشراك الفريق ، وسيكون لديك سجل بالإشعارات السابقة. ولن تخاف بعد الآن من تغيير الإشعارات أو طلب الإذن من المسؤولين عنها.
- احصل على ملاحظات الإشعارات ، حتى لو كان ذلك سهلاً لجعل الحاضرين يضعون علامة على الإشعارات على أنها غير مجدية أو متطفلة. قم بتضمين ارتباط أو عبارة تحث المستخدم على اتخاذ إجراء في الإشعار نفسه ومراجعة التعليقات بانتظام.
- ضع قاعدة في الفريق - دع الحاضرين يعملون على تبسيط الواجب عندما يكون هناك القليل من العمل. دع كل شيء بعد أن يكون أفضل قليلاً مما كان عليه من قبل.
اختتام
أعتقد أن طريقة CASE تساعد المطورين والمؤسسات في مناقشة إعداد وإرسال الإشعارات التلقائية. يمكن لأحد المطورين البدء في تقييم الإشعارات باستخدام طريقة CASE ، ثم تنضم المؤسسة بأكملها مع المطورين الآخرين ، والإدارة ، وبرامج إدارة الحوادث للحفاظ على الإخطارات في حالة جيدة. لا يتطلب أي أدوات خاصة أو عمليات معقدة.
تحتاج الصناعة بأكملها إلى التفكير في العامل البشري أثناء الخدمة دون التضحية بخدمة العملاء من الدرجة الأولى. كل هذه الأدوات والممارسات يمكن ويجب تحسينها. آمل أن تساعد طريقة CASE في ذلك.
استمتع بالإخطارات المحسنة!
المصدر: www.habr.com