من يلاحظ أن موقعك أو تطبيق أعمالك توقف عن أداء مهمته؟

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

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

ماذا تعني كلمة «يعمل» في خدمتك؟

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

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

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

افحص من الخارج وافهم ما يحدث في الداخل

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

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

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

كل تنبيه يحتاج إلى مستلم وخطوة تالية

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

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

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

اجعل الفحوص الوظيفية آمنة

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

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

اطلب عرض فشل فعلي في بيئة اختبار

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

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