توقفت عن الحفر في السجلات

لفترة طويلة، كان تصحيح الأخطاء (debugging) يعني فتح السجلات (logs) أولاً. بدا ذلك كأنه الشيء الصحيح للقيام به. التنبيهات انطلقت، السجلات كانت موجودة، لذا قرأتها. بمرور الوقت، أدركت أن معظم طاقتي لم تكن تُبذل في إصلاح الأخطاء. بل كانت تُبذل في البحث.

لذا توقفت عن الحفر في السجلات.

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

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

المشكلة: السجلات هي شظايا وليست القصة

السجلات هي شظايا. سطر هنا. تتبع مكدس (stack trace) هناك. طابع زمني يطابق تقريباً طابعاً آخر.

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

التدفق القديم كان يبدو هكذا:

انطلاق تنبيه
فتح السجلات
البحث بواسطة معرف الطلب (request id)
القفز بين الخدمات
فتح الكود
تشكيل فرضية
تكرار

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

التحول: توقف عن القراءة وابدأ في الربط

بدلاً من البدء بالسجلات، أبدأ الآن بالخطأ.

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

وظيفة الذكاء الاصطناعي بسيطة. ربط كل شيء قد يكون متعلقاً بهذا الخطأ.

وظيفتي تبقى كما هي. تقرير ما يجب فعله تالياً.

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

ما يفعله الذكاء الاصطناعي فعلياً

لا يوجد سحر متضمن. الخطوات ميكانيكية.

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

تالياً، يستعلم من قاعدة بيانات المراقبة عن أخطاء مشابهة. نفس التوقيع، نفس الخدمة، حمولات مشابهة، نوافذ زمنية قريبة.

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

بعد ذلك، يتحقق من عمليات النشر (deploys) أو الالتزامات (commits) الحديثة التي لمست مسارات الكود المعنية.

المخرج هو تقرير قصير مع أدلة. تتبعات تتكرر. سجلات تصطف. مسارات كود تغيرت مؤخراً.

هذا لا يعطيني الإصلاح. إنه يعطيني المكان الصحيح للنظر.

حواجز الحماية: وصول بدون انكشاف

هذا الجزء يهم أكثر من الذكاء الاصطناعي نفسه.

الذكاء الاصطناعي لديه وصول للقراءة فقط. لا كتابة. لا طفرات (mutations). لا آثار جانبية.

وضع الخصوصية مفعل. البيانات لا تستخدم للتدريب. تستخدم فقط للاستدلال في هذه الجلسة.

الوصول محدد النطاق (scoped). فقط الحقول المطلوبة لتصحيح الأخطاء يتم كشفها. لا وصول واسع لقاعدة البيانات. لا حمولات غير ضرورية.

كل استعلام ونتيجة قابلة للتدقيق.

الهدف ليس إعطاء الذكاء الاصطناعي قوة أكثر. الهدف هو إعطاؤه سياقاً كافياً ليكون مفيداً، دون خلق مخاطر جديدة.

ما تغير بالنسبة لي

بضعة أشياء أصبحت واضحة جداً بعد تبديل تدفقات العمل.

الوقت للوصول للسبب الجذري انخفض بشكل كبير. نحن نتخطى مرحلة التجول.

طلبات السحب (Pull requests) أصبحت أصغر وأكثر تركيزاً. الإصلاحات تستهدف المشكلة الفعلية بدلاً من التخمينات المحيطة.

التحقيقات الخاطئة انخفضت. مواقف أقل حيث يتم قضاء ساعات فقط للاستنتاج أنه لم يكن مرتبطاً.

التنبيهات تبدو أهدأ. عندما ينكسر شيء ما، الخطوة الأولى منظمة، وليست رد فعل.

ما لم يتغير

المهندسون ما زالوا يتخذون القرارات.

الذكاء الاصطناعي لا يفهم سياق المنتج. لا يعرف أولويات العمل أو استراتيجية الطرح (rollout).

الحكم لا يزال مطلوباً. كم هو خطير الإصلاح. هل يجب التراجع (rollback). هل يجب عمل إصلاح سريع (hotfix) أو الانتظار.

الذكاء الاصطناعي يضيق مساحة البحث. البشر ما زالوا يملكون النتيجة.

تدفق عمل يمكنك نسخه

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

لا غوص أعمى في السجلات.

إلى أين يمكن أن يذهب هذا تالياً

فكرة أبقيها في مؤخرة رأسي هي دفع تدفق العمل هذا خطوة أبعد.

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

ليس ليدمج (merge) من تلقاء نفسه. فقط ليفتح طلب سحب (pull request).

طلب السحب سيحتوي على:

السبب الجذري المشتبه به
التتبعات والسجلات الداعمة
تغيير الكود
الاختبارات التي تبرر الإصلاح

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

هذا تدفق عمل أرغب فعلاً في صيانته.

ختاماً: لماذا هذا يهم فعلاً

هذا ليس عن استبدال المهندسين. إنه عن إزالة العمل غير الضروري.

السجلات هي مادة خام. ليست الإجابة. السرعة تأتي من تجميع السياق بسرعة، وليس القراءة بشكل أسرع.

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