اعرف قبل أن يتصل بك العميل

الجمعة، الساعة 16:40. يكتب إليك أحد العملاء أن تطبيقك «بطيء منذ هذا الصباح». تفتح لوحة المتابعة فتجد كل شيء أخضر. المعالج لا يتجاوز 30%، والذاكرة مستقرة، ومسبار التوفر يردّ بالرمز 200 منذ ثلاثة أسابيع دون انقطاع. لم تلاحظ شيئًا، ومع ذلك فالعميل محق. بعد ساعة تكتشف أن 4% من الطلبات تستغرق أكثر من عشر ثوانٍ، وكلها على نقطة الدخول نفسها، وكلها لعملاء تحتوي حساباتهم على أكثر من عشرة آلاف سطر. لم يكن بوسع أي من مساباتك أن يرى ذلك: فقد كانت تتحقق من أن الخدمة تستجيب، لا من أنها تستجيب بشكل صحيح للجميع.

هذه الفجوة ليست عيبًا في الأدوات، بل عيب في المنهج. المسبار يتحقق من فرضية صغتَها مسبقًا: «هل العملية حية؟»، «هل القرص ممتلئ؟». وهو ممتاز في كشف الأعطال التي سبق أن واجهتها، لكنه أعمى عن كل ما سواها. أما في بيئة الإنتاج، فالحوادث المكلفة هي في الغالب تلك التي لم يتوقعها أحد: تبعية (dependency) تبطؤ دون أن تتوقف، أو ذاكرة تخزين مؤقت (cache) تفرغ، أو استعلام SQL تغيّرت خطة تنفيذه بعد ترقية إصدار. فالسؤال المفيد إذن ليس «هل لديّ ما يكفي من المسابر؟»، بل «عندما يقع حادث غير مسبوق، هل تتيح لي بياناتي أن أفهم ما جرى دون نشر أي شيفرة جديدة؟». وهذا بالضبط ما تعنيه الملاحظية (observability)، وهو معيار قابل للقياس وليس شعارًا ترويجيًا لدى الموردين.