المراقبة وإدارة الأعطال ObservabilityObservability and incident response

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

يبدأ الحادث من أثر يراه العميل، ولو بقيت كل الخوادم مضاءة باللون الأخضر.

كل الرسوم البيانية خضراء، فليش العملاء يشتكون؟

وهذا أشهر مشهد في غرفة عمليات: لوحة كاملة خضراء، وتويتر مليء بشكاوى.

والسبب أن اللوحة تراقب آلاتك أنت، والعميل يعيش شيئاً آخر.

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

فالفرق أن اللوحة تقيس أن النظام يستجيب، والعميل يريد أن العملية تنجح.

ولهذا فأول مقياس يجب أن يُبنى في أي منتج مالي ليس استهلاك المعالج، بل شيء من نوع: كم نسبة المدفوعات الناجحة في آخر خمس دقائق مقارنة بالمعتاد في هذا الوقت من الأسبوع؟

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

راقب النتيجة قبل الآلة

وقد تعمل وحدة المعالجة عند ٩٠ بالمئة ولا يتأثر أحد. وقد تعمل عند ٢٠ بالمئة بينما تفشل كل الدفعات بسبب شهادة منتهية. ولذلك نبه على نسبة نجاح الدفع وزمنه وتراكم العمليات المعلقة قبل استهلاك الخادم.

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

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

اتبع دفعة واحدة

ويُسمى المعرف الذي يرافق العملية عبر الأنظمة «معرّف الربط» Correlation ID. فيبدأ مع طلب العميل، ثم يظهر في خدمة الدفع وطابور الرسائل والسجل واتصال المزود. ويستطيع المهندس البحث عنه ليرى القصة كاملة.

ولا تستخدم رقم البطاقة أو الهوية لهذا الغرض. فأنشئ قيمة عشوائية لا تكشف بيانات العميل. واربط بها معرف المزود والقيد دون نشر الأسرار في السجلات.

واجعل السجل يذكر الحدث والحالة والزمن والخدمة والنتيجة. فلا تكتب فشل فقط. واكتب أن طلب الدفع p_123 انتهت مهلته بعد ٣ ثوان عند المزود، وأن حالته ما زالت مجهولة. ويقلل الوصف وقت التخمين.

اكتب دليل التشغيل قبل العطل

ويعني «دليل التشغيل» Runbook خطوات معدة لمعالجة فشل محدد. فقد يشرح كيف تتحقق من توقف مزود البطاقات، وكيف تمنع طلبات جديدة، ومن يتصل بالشريك، وكيف تؤكد سلامة السجل.

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

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

أدر الحادث بأدوار واضحة

وعند وقوع العطل، عيّن قائداً واحداً ينسق القرار. وعيّن شخصاً للتحقيق وآخر للتواصل وتسجيل الخط الزمني. ولا تجعل عشرين شخصاً يغيرون النظام في الوقت نفسه داخل مكالمة صاخبة.

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

وحدث العملاء بما تعرفه فعلاً. فقل إن دفعات البطاقات تتأخر منذ ١٠:١٥ وإن الفريق يحقق. ولا تعد بموعد لم تثبته، ولا تقل إن كل شيء يعمل بينما الدعم يستقبل الشكاوى.

اعرف ساعة الإبلاغ

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

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

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

تراجع ثم طابق

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

وحدد معيار التعافي قبل إغلاق الحادث. فيجب أن تعود نسبة النجاح، ويتوقف تراكم الطابور، وتُعالج الحالات المعلقة، وتثبت المطابقة عدم ضياع المال. وقد يعود التطبيق بينما يبقى العمل المالي ساعات.

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

راجع النظام بلا لوم

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

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

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

قس قدرة الاستجابة

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

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

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