قائد DevOps يطلق nib: وكيل يقسّم عملية النشر على AWS إلى مراحل وفحوصات وتراجع

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

مؤلف هذا التحليل يدير فريق DevOps في استوديو ألعاب ولديه 15 عامًا من الخبرة. صاغ أسلوبه في التخطيط بشكل رسمي وسلّمه لوكيل يحمل اسم nib (Neuro Infrastructure Builder).

كيف يخطط المهندس المتمرس

يبدأ بجمع السياق: ما هو المشروع، وكيف صُممت البنية التحتية الحالية، وما المعروف عن المنتجات المذكورة في المهمة. ثم تُقسَّم المهمة إلى مراحل كبرى: شيفرة البنية التحتية، وسير عمل البناء والنشر، وإنشاء الموارد، والنشر، والتحقق. والأهم من القائمة نفسها هو الاعتماديات بين المراحل، فهي التي تحدد ما يمكن تنفيذه بالتوازي.

تُفصَّل كل مرحلة إلى إجراءات أولية: تعديل ملف، أو تنفيذ أمر، أو إجراء استدعاء API. ويلزم لكل إجراء فحص وخطوة تراجع. فمثلًا، بعد terraform plan يجب ألا يحتوي diff على أي destroy، وبعد apply يجب أن تكون RDS في حالة available. أما عمود «التراجع» فيُترك فارغًا في أغلب الأحيان. ويتساءل المؤلف: متى كتبتَ آخر مرة خطة تراجع قبل أن تحتاج إليها؟

تنكسر العملية في ثلاثة مواضع. تسقط البنود من الذاكرة عند تبدل السياق: فقد نقل المؤلف ذات مرة حاويات الأصول بين سحابتين ونسي CORS. وتُقتطع الفحوصات تحت ضغط المواعيد النهائية لأن تخطيها لا يكسر شيئًا فورًا. ولا يوجد تقدير للحجم: فما دامت المهمة غير مفصّلة، فإن «يوم أو يومان» ليس تقديرًا بل مجرد إحساس.

ماذا يفعل nib

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

تحل قاعدة معرفة محل سياق المهندس: وصف الشركة، ونظام التحكم بالإصدارات VCS، وCI/CD، ومخطط الشبكات، وقواعد التسمية. وعند اكتمال الخطة يكتب nib تقريرًا ويحدّث القاعدة، فتبدأ المهمة التالية بما تعلمه الوكيل في المهمة السابقة.

التثبيت محلي: git clone وmake setup وDocker ومفتاح أي مزود متوافق مع OpenAI. وتُوصَل الأدوات عبر MCP بنقل HTTP: GitHub وواجهة AWS API وSearXNG للبحث في الوثائق. ويوفر خادم AWS أداتين فقط (استدعاء CLI ومساعد الأوامر)، بينما يوفر GitHub نحو عشرين أداة. ولتفادي تضخم السياق، يختار nib في مرحلة التفكيك فئات الأدوات اللازمة فقط.

أين قد تتعرض للأذى

إعدادات الأمان في المثال سخية. فـ READ_OPERATIONS_ONLY: false يسمح بالتعديلات، وREQUIRE_MUTATION_CONSENT: false يلغي التأكيد من جهة خادم MCP. ويبقى التأكيد الوحيد هو زر Execute داخل nib نفسه. أما AUTH_TYPE: no-auth فمقبول فقط لأن المنفذ غير منشور للخارج، والخدمة مرئية داخل شبكة docker وحدها.

تُخزَّن الأسرار في موضعين. مفاتيح AWS لازمة لحاوية aws-mcp، لذا فهي في ملف .env. أما رمز GitHub فيُمرَّر في ترويسة من nib إلى خادم MCP ويُحفظ في أسرار nib مع قائمة بيضاء للمضيفين. ويحتاج GitHub إلى رمز classic بنطاقَي repo وworkflow، ودون الثاني لن يتمكن الوكيل من إيداع الملفات في .github/workflows.

الخلاصة العملية

القيمة الرئيسية هنا ليست في سحر الوكيل، بل في الانضباط ذاته: إجراء وفحص وتراجع في كل خطوة. وحتى من دون nib يستحق هذا الجدول أن يُكتب قبل بدء العمل، والتقدير بعدد الإجراءات أصدق من «يوم أو يومين». وإذا جرّبت الأداة فاستخدم حساب AWS معزولًا للاختبار ولا تمنح الوكيل صلاحيات أوسع من اللازم. يغطي هذا الجزء قاعدة المعرفة فقط، ويعد المؤلف بتناول القواعد والمهارات في مقالة قادمة.