مراجعة البنية التحتية تحتاج سؤالين مختلفين: من يستطيع الوصول إلى المهمة أثناء تشغيلها؟ وما الذي قد يبقى بعد انتهائها؟ إعادة استخدام التخزين تجعل السؤال الثاني ضروريًا لمنصات SaaS متعددة العملاء وبيئات تشغيل AI Agents.
إفصاح جديد، لا حادثة بدأت اليوم
يوضح تقرير Cloudflare بتاريخ 24 سبتمبر خللًا أُبلغ عنه في 4 سبتمبر، واكتمل تنظيف آثاره في 19 سبتمبر. كتابة 4 KiB داخل كتلة معاد استخدامها بحجم 64 KiB قد تُبقي 60 KiB من بيانات عميل سابق. شمل الإصلاح تصفير الكتل واستبدال الأقراص واللقطات القديمة. تقول الشركة إن السجلات المتاحة لم تُظهر استغلالًا خبيثًا، ولا يلزم تعديل إعدادات العملاء. تأكيد الباحثين منقول عبر التقرير؛ لم نُجرِ اختبارًا مستقلًا.
كيف يحتوي قرص جديد على بيانات قديمة؟
تشرح وثائق dm-thin في Linux إمكانية مشاركة عدة أقراص افتراضية في مساحة تخزين فعلية واحدة. تربط عملية التخصيص العناوين المنطقية بكتل فعلية، ويعطّل الخيار skip_block_zeroing تصفير الكتل عند تخصيصها. وجوده لا يضمن خلو الأجزاء غير المكتوبة من بيانات سابقة.
تخيّل إعادة الاستخدام كتغيير للمالك، لا كتغيير تلقائي لكل بايت. هنا نتحدث عن دورة حياة التخزين: قد يتحقق التطبيق من صلاحيات المستخدم بشكل صحيح، بينما يعتمد على تسليم غير آمن للموارد في طبقة أدنى.
التخزين المؤقت ليس شهادة محو
تصف وثائق دورة حياة الحاويات آلة افتراضية مخصصة لكل حاوية وقرصًا مؤقتًا، مع قرص جديد وفق صورة الحاوية عند تشغيلها بعد السكون. هذا يشرح ما يراه التطبيق خلال دورة الحياة، وليس ضمانًا عامًا لكل طريقة لتنفيذ التخزين الفعلي.
في مراجعة الأركتكشر، افصل ثلاثة عقود: عزل التنفيذ، واستمرارية البيانات، وتنظيف الموارد. حدّد المكوّن المسؤول عن كل عقد والدليل الذي يثبت تطبيقه. نجاح اختبار تسجيل الدخول لا يختبر كيف انتقلت مساحة التخزين من عميل إلى آخر.
اختبار عملي لمنصتك أنت
الخطوات التالية تصميم اختبار مقترح، وليست إعادة تنفيذ للحادثة ولا تجربة على بنية تخص الآخرين. استخدم بيئة staging معزولة تملكها، وعميلين تجريبيين، وبيانات عشوائية غير حساسة.
ابدأ بتسجيل معرّف الموارد المخصصة للعميل A، واكتب علامة عشوائية داخل مساحة عمله المؤقتة. جرّب الإغلاق الطبيعي، والإنهاء القسري، والحذف. بعدها خصّص مساحة للعميل B عبر الواجهة المدعومة، وتحقق من أنه لا يرى إلا بياناته المتوقعة. أضف سيناريو الاستعادة من صورك أو لقطاتك المجهزة مسبقًا.
إذا كنت تدير طبقة التخزين نفسها، أضف فحوصًا أدنى تناسب storage driver داخل مختبر قابل للحذف. اختبارات التطبيق وحدها لا تثبت تنظيف الكتل الفعلية التي لا يستطيع الوصول إليها. لا تفحص أقراص إنتاج مشتركة ولا تحاول استخراج محتوى يخص عميلًا آخر.
سجّل إصدار runtime وإعدادات التخزين ومصدر الصورة ومسار التنظيف الذي نُفّذ. فشل متقطع في الاختبار مؤشر يستحق التحقيق، وليس نسبة يمكن تعميمها على كل المهام.
ماذا يعني ذلك لمنصات SaaS وAI Agents؟
خذ مثالًا توضيحيًا: خدمة لتحويل المستندات تشغّل مهمة لكل تاجر. معرّف المهمة وملفاتها المؤقتة والمدخلات المخزنة في الكاش والسجلات وبيانات الاعتماد تحتاج ملكية واضحة. ابنِ قائمة موارد حول المهمة بدل افتراض أن حذف سجلها من قاعدة البيانات يزيل كل حالة التشغيل.
إذا كان AI Agent يشغّل كودًا يقدّمه المستخدم، اجعل القائمة نفسها جزءًا من إنهاء الجلسة. امنحها بيانات الاعتماد الضرورية فقط، واضبط انتهاء صلاحيتها بشكل مستقل، ولا تضع بيانات المستخدم داخل صور قابلة لإعادة الاستخدام. هذه توصيات تصميمية، وليست ادعاء بأن الحادثة كشفت كل أنواع الموارد المذكورة.
يبقى عزل العملاء في قاعدة البيانات ضروريًا، لكنه يعالج حدودًا مختلفة. اربطه بـمراقبة تشغيلية واضحة لتتبّع فشل التنظيف من دون نسخ محتوى حساس إلى السجلات.
المقايضات والقرار الهندسي
يميّز دليل Kubernetes لتعدد العملاء بين مستويات مختلفة للعزل؛ وNamespaces وحدها ليست جوابًا كاملًا عندما لا يثق العملاء ببعضهم. مشاركة البنية أو زيادة الفصل بين العملاء تتطلبان افتراضات أمنية وتكاليف تشغيلية مختلفة.
قبل تحسين زمن بدء المهمة، ضع شروط قبول لإعادة الاستخدام: اكتمال التنظيف، واعتماد مصدر الصورة، وانتهاء بيانات الاعتماد، واجتياز التحقق. قِس هذا المسار على حملك الفعلي. لا يقدّم هذا المقال قياسًا لتكلفة التصفير أو ادعاءً بتوفير مالي.
الخلاصة سؤال تضيفه إلى مراجعة التصميم المقبلة: هل تستطيع شرح واختبار الرحلة كاملة، من آخر كتابة للعميل الأول إلى أول قراءة للعميل التالي؟
المراجع الرسمية
تدعم هذه المراجع سلوك الأدوات المذكورة. الأمثلة وقرارات التصميم توضيحية، ويجب تكييفها مع متطلبات المشروع وإصداراته.
إعداد: Noor Yasser
تعمل على تحدٍ تقني مشابه؟
أساعد الفرق على تحويل القرار المعماري إلى نطاق واضح وتنفيذ يمكن تشغيله ومراجعته بثقة.
