تتجه معظم فرق هندسة المنصات (Platform Teams) حالياً لمناقشة قضية جوهرية: هل يجب السماح لوكلاء البرمجة المعتمدين على الذكاء الاصطناعي (AI Coding Agents) بفتح طلبات سحب (Pull Requests) لتعديل البنية التحتية؟ الإجابة الحقيقية لا تتعلق بمدى موثوقية الوكلاء، بل بمدى قدرة المنصة نفسها على استيعاب التغييرات الخاطئة والمدمرة قبل انتشارها.
تجسد حادثة شركة Replit الشهيرة هذا الخطر، حيث تسبب وكيل ذكاء اصطناعي عن طريق الخطأ في مسح قاعدة بيانات إنتاجية وإنشاء آلاف الحسابات الوهمية، مما سلط الضوء على أن الأتمتة لا تفرق بين التغيير الجيد والسيئ، بل تعمل فقط على تسريع وتيرة النتائج، سواء كانت صحيحة أو كارثية.
مخاطر الأتمتة في عصر GitOps
تعتمد معظم المنصات السحابية الحديثة على منهجية GitOps، حيث يمثل مستودع Git الحالة المنشودة للبنية التحتية. ورغم فوائدها في التدقيق والاتساق، إلا أن الأتمتة تعمل هنا كـ "مضخم للأخطاء"؛ فالمخطأ الواحد يمكن أن ينتشر عبر كامل البنية التحتية في ثوانٍ. ومع دخول وكلاء الذكاء الاصطناعي، تزداد وتيرة طلبات التغيير بشكل هائل، بينما تظل قدرة المراجعة البشرية محدودة، مما يجعل المراجعة البشرية "أندر مورد" في خط الإنتاج التقني.
خمس طبقات لبناء المرونة السحابية
لضمان سلامة المنصة، يجب بناء حماية متعددة الطبقات لا تعتمد على هوية من يقوم بالتغيير، بل على متانة النظام نفسه:
- الطبقة الأولى: الاختبارات المبكرة: استخدام التطوير القائم على الاختبار (TDD) وبيئات الـ Canary لمراقبة سلوك التغييرات في بيئة كاملة قبل وصولها للمستخدمين.
- الطبقة الثانية: التجريد والتهيئة (Abstraction): تقليل مساحة الخطأ عبر توفير واجهات مبسطة بدلاً من ملفات YAML الخام. يمكن استخدام أدوات مثل kro (Kube Resource Orchestrator) لتحويل مجموعة موارد معقدة إلى واجهة برمجة تطبيقات (API) بسيطة، أو مشروع Score لتبسيط احتياجات المطورين. هذا يجعل التغييرات حتمية (Deterministic) ويمنع الذكاء الاصطناعي من "الارتجال" في الحقول غير المعروفة.
- الطبقة الثالثة: حمايات Kubernetes الأصلية: تفعيل سياسات التحكم في الوصول (RBAC)، واستخدام Kyverno كـ "برج مراقبة" يمنع أي طلب لا يطابق معايير المنصة، بالإضافة إلى ميزانيات تعطيل الـ Pods (Pod Disruption Budgets).
- الطبقة الرابعة: حماية مزود السحابة: تفعيل خاصية "حماية الحذف" (Deletion Protection) على مستوى الموارد الأساسية لمنع المسح العرضي.
- الطبقة الخامسة: المراجعة البشرية: الحفاظ على دور الخبراء عبر آليات مثل CODEOWNERS لضمان عدم تجاوز أي تغيير للمراجعة البشرية.
مفهوم "العلم الواحد" ونموذج الثقة الصفرية
بدلاً من جعل كل طبقة حماية قراراً منفصلاً، يقترح المقال تبسيط الأمر عبر "علم واحد" (One Flag). عند ضبط حقل معين كـ protected: true في تعريف المورد، تقوم المنصة تلقائياً بتفعيل حماية الحذف في السحابة، ومنع تغيير المنطقة الجغرافية، وتفعيل سياسات Kyverno الصارمة. هذا النهج يطبق مبدأ الثقة الصفرية (Zero Trust) على أتمتة البنية التحتية؛ حيث لا يُفترض أن الوكيل أو الإنسان موثوق، بل يتم تصميم النظام بحيث لا يمكن إجراء تغييرات مدمرة دون طلب إذن صريح وواضح يسهل رصده أثناء المراجعة.
ما الذي يتغير عملياً؟
هذا التوجه ينقل عبء الأمان من "مراقبة المستخدمين" إلى "تحصين المنصة". بالنسبة لمهندسي المنصات، يعني هذا التوقف عن محاولة تقييد قدرات الذكاء الاصطناعي، والبدء في بناء أنظمة تجعل الخطأ مستحيلاً تقنياً أو على الأقل محدود الأثر (Bounded Blast Radius). الهدف هو الوصول إلى مرحلة تتبنى فيها الفرق المنصة لأنها المسار الأسرع والأكثر أماناً، وليس لأنها تفرض قيوداً تعيق العمل.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.