الأنظمة القديمة مشكلة تضخيم للوكلاء

الادعاء قيد الفحص

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

تضخيم، وليس جدة

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

هذا التحول يهم أكثر حيث تفتقر واجهة قديمة إلى ثلاث خصائص محددة:

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

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

A close-up of a person with a bionic arm leaning on a CRT TV under green lighting.

آلية ملموسة تجعل هذا واضحاً. تخيل نقطة نهاية SOAP أو REST قديمة تعرض عملية createRecord بدون مفتاح idempotency وبدون حصة لكل principal. حلقة وكيل واحدة بسياسة إعادة المحاولة عند المهلة ستُصدر، تحت خلفية بطيئة، نفس الكتابة المنطقية عدة مرات. كل محاولة تبدو صالحة للخادم. النتيجة ليست حادثاً أمنياً بالمعنى الكلاسيكي؛ إنها حادث جودة بيانات يجب بعد ذلك تسويته يدوياً. اضرب ذلك في سرب وستكون تكلفة التسوية هي الضرر الحقيقي.

ضوابط تعمل عند الحدود

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

ثلاثة ضوابط تحمل معظم الثقل.

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

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

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

agent -> boundary gateway -> legacy interface
              |
              |- principal identity
              |- per-endpoint budget
              |- idempotency store
              |- audit log (append-only)
              |- read/write routing (replica vs system of record)

Close-up shot of illuminated aircraft cockpit controls with green lighting.

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

لماذا إعادة الكتابة هي الخطوة الأولى الخاطئة

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

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

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

ما يجب فعله أولاً

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

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