5. التنفيذ#

كان كتاب التشغيل يعمل بشكل مثالي لأشهر: عشرة مفاتيح وصول في المختبر، دقيقتان من البداية إلى النهاية، نتائج نظيفة في كل مرة. حين قرر الفريق طرحه على الجرد الكامل من 800 مفتاح، لم يتوقع أحد مشكلة. تحدّثت الـ600 جهاز الأولى بلا عوائق. ثم تباطأت المهمة. ثم توقفت. بدأ خادم RADIUS، الذي تلقّى فجأة 150 طلب مصادقة SSH متزامناً، برفض الاتصالات. توقف Ansible عند 150 جهازاً في منتصف التنفيذ. قتل مهندس المهمة.

ما جاء بعد ذلك كان المشكلة الأصعب: لم يعرف أحد أي 600 جهاز قد تحدّثت وأيها الـ150 التي لم تتحدّث. لم يُسجَّل أي حالة تنفيذ. أعادوا تشغيل كتاب التشغيل وأملوا أن ينقذهم ثبات نتيجة التكرار، وقد فعل ذلك تلك المرة. لكن الحادثة كشفت شيئاً مهماً: كانت طبقة التنفيذ مصممة للمختبر، لا للشبكة. السرعة، والتوازي، وحدود الخطأ، وتتبع الحالة، لم يُؤخذ أي منها في الاعتبار. الأتمتة كانت تعمل؛ معمارية التنفيذ لم تكن كذلك.

يفكر معظم الناس في أتمتة الشبكة على النحو التالي: “خذ البيانات ذاتها، وبلا الاتصال بوصفك إنساناً عبر الـCLI، افعل شيئاً على الشبكة.” أراهن أن معظم من يبدؤون بأتمتة الشبكة يبدؤون من هنا. ونعم، هذا ما تفعله كتلة التنفيذ. لكن كما رأيت طوال هذا الكتاب، أتمتة الشبكة أكبر من هذه الخطوة الأولى، والتنفيذ مجرد مكوّن واحد ضمن معمارية.

تتفاعل كتلة التنفيذ مباشرةً مع الشبكة للعمليات الأكثر خطورة (مثل تغييرات التهيئة أو إعادة التشغيل). فلا تتخطّ هذا الفصل؛ من الضروري الإتقان فيه.

في هذا الفصل، سنستعرض الأهداف والأعمدة التي توفرها هذه الكتلة، والقدرات الداخلية التي تحتاجها لتحقيقها.

5.1. الأساسيات#

5.1.1. السياق#

يحدد التنفيذ كيفية تنفيذ الإجراءات. ماذا يأتي من كتلة النوايا، ومتى يأتي من التنسيق.

في مشاريع أتمتة الشبكة المبكرة، يمكن أن يكون سكريبت يُرجع واجهة لجهاز واسم واجهة معين الإنجاز الأول. يمكن أن تنمو تلك الرحلة إلى نظام أكثر تطوراً بكثير.

5.1.2. الأهداف#

ماذا يحتاج نظام التنفيذ أن يفعل فعلاً؟ خمسة أشياء تهم:

1. الحصول على البيانات الصحيحة في المكان الصحيح. قبل تنفيذ أي شيء، تحتاج إلى معرفة ماذا تنفّذ (النوايا)، وأين تنفّذه (أي الأجهزة)، وكيف تصل إليها (بيانات الاعتماد وتفاصيل الاتصال). هذا يعني سحب الجرد وجلب الحالة المقصودة من مصدر الحقيقة (المزيد عنه في الفصل 4)، وأحياناً الاستعلام عن بيانات الرصد لفهم الظروف الراهنة. بدون هذا التكامل، محرك تنفيذك مجرد أوامر عمياء. لصحتك النفسية، تجنّبها.

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

3. تتبع الحالة بمرور الوقت. العمليات على مستوى الشبكة ليست فورية. قد تنشر على مئات الأجهزة على مدى ساعات. أي الأجهزة نجحت؟ أيها فشلت؟ أيها لا تزال معلقة؟ إدارة الحالة تُمكّن أيضاً ثبات نتيجة التكرار (تشغيل المهمة ذاتها مرتين يعطي نفس النتيجة)، والتراجع (تراجع ما فعلتَه للتو)، والاستئناف (المتابعة من حيث توقفت بعد إخفاق). بدون تتبع الحالة، كل تنفيذ قمار بالنتيجة الواحدة.

4. التنفيذ بموثوقية على نطاق واسع. السكريبت الذي يعمل لـ5 أجهزة كثيراً ما ينكسر (أو يتدهور) عند 500 جهاز. تحتاج إلى التنفيذ المتوازي، ومعالجة الأخطاء، وإعادة المحاولة، وتحديد المعدل، وقدرات التشغيل التجريبي. ينبغي للنظام التعامل برشاقة مع الإخفاقات الجزئية، وتوفير تغذية راجعة واضحة حول ما أخطأ، وعدم ترك الشبكة أبداً في حالة غير محددة. العمليات المختلفة تحتاج استراتيجيات مختلفة. بعضها سريع ومتوازٍ، والآخر بطيء ومتسلسل.

5. العمل مع أي جهاز شبكة أو منصة. شبكتك على الأرجح تحتوي Cisco وArista وJuniper وApplication Programming Interface (API)ات السحابة وصناديق Linux وجدران حماية وموازنات تحميل. كل منها يتحدث بروتوكولات مختلفة وله أنماط تشغيلية مختلفة. طبقة تنفيذك تحتاج محوّلات لجميعها، بواجهة مشتركة حتى لا تكترث بقية أتمتتك بالاختلافات.

مع هذه الأهداف في الذهن، ما القدرات المعمارية التي تحتاجها فعلاً؟

5.1.3. الأعمدة#

كل هدف يترجم إلى قدرات محددة:

1. طبقة تكامل البيانات. محرك تنفيذك لا يقوم في عزلة. يحتاج وصولاً برمجياً إلى مصدر الحقيقة (الجرد وبيانات الاعتماد والنوايا)، وأنظمة الرصد (الحالة الراهنة ومقاييس الصحة)، وربما أنظمة أخرى (التذاكر وإدارة التغيير وسير عمل الموافقة). يعني ذلك تنفيذ عملاء Application Programming Interface (API)، ومعالجة المصادقة بأمان، وتخزين البيانات مؤقتاً بشكل ملائم، والتحقق من توافر كل ما هو مطلوب قبل بدء التنفيذ.

2. آليات تشغيل مرنة. طرق متعددة للبدء مهمة. المشغّلات المتزامنة تشمل استدعاءات Representational State Transfer (REST) Application Programming Interface (API) (الاستدعاء المباشر)، وWebhooks (تكامل النظام الخارجي)، وNPCs. المشغّلات غير المتزامنة تشمل مستمعي الأحداث (التفاعل مع تنبيهات الرصد أو تغييرات حالة الجهاز أو الأحداث الخارجية)، والجداول الزمنية (التنفيذ الدوري الشبيه بـcron أو المهام المجدولة لمرة واحدة)، ومستهلكي قوائم انتظار الرسائل. يساعد التسلسل الأساسي أيضاً: ينتهي تنفيذ ما ويُشغّل آخر.

3. بنية إدارة الحالة. هذا يتجاوز “هل يمتلك الجهاز هذه التهيئة.” تحتاج حالة التنفيذ (أي المهام تعمل، ومعلقة، ومكتملة، وفاشلة)، والحالة المطلوبة (ما ينبغي تهيئته)، والحالة الفعلية (ما هو مُهيَّأ). يستلزم ذلك تخزيناً مستمراً، ودعم المعاملات للعمليات الذرية، وآليات قفل لمنع التعارضات المتزامنة، ونموذج حالة واضح. يجب أن تتعامل البنية مع السيناريوهات الموزعة حيث تُشارَك الحالة عبر عمال تنفيذ متعددين.

4. محرك تنفيذ قوي. هذا قلب النظام. يدعم كلاً من سير العمل الأمري (تشغيل الأمر 1، ثم الأمر 2، ثم الأمر 3) والنهج التعريفي (اجعل الجهاز يبدو هكذا، استنتج الخطوات بنفسك). يتعامل المحرك مع التزامن (التنفيذ على أجهزة متعددة بالتوازي أو في دفعات)، وينفّذ منطق إعادة المحاولة مع التراجع الأسي، ويوفر قدرات التشغيل التجريبي (توقع ما سيحدث بلا تنفيذ)، ويلتقط سجلات تنفيذ مفصلة، ويتعامل برشاقة مع الإخفاقات الجزئية. معالجة الأخطاء حاسمة: حين يفشل شيء ما، هل تُلغي كل شيء، أم تتابع مع أجهزة أخرى، أم تعيد المحاولة؟

5. طبقة تجريد البروتوكول. أجهزة الشبكة خليط غير متجانس. بعضها يتحدث Secure Shell (SSH) ويتوقع أوامر Command Line Interface (CLI). غيرها يستخدم NETCONF أو RESTCONF. الأجهزة الحديثة تدعم gRPC Network Management Interface (gNMI) للتوجيه التدفقي والتهيئة. المنصات السحابية تكشف Representational State Transfer (REST) APIs. يحتاج نظام تنفيذك محوّلات لجميع هذه، يقدّم واجهة موحدة للمنطق عالي المستوى. تتعامل هذه الطبقة مع تجميع الاتصالات وإدارة الجلسات والمصادقة وتنسيق الأوامر وتحليل الردود. التجريد الجيد يعني إمكانية إضافة دعم لنوع جهاز جديد بلا إعادة كتابة أتمتتك بأكملها.

5.1.4. النطاق#

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

ما يدخل في النطاق:

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

ما يخرج عن النطاق:

• تحديد ما يجب تهيئته (تلك مهمة النوايا)
• تنسيق سير عمل معقدة متعددة الخطوات وتحديد وقت التشغيل (تلك مهمة التنسيق)
• التخزين الطويل الأمد وتحليل نتائج التنفيذ (تلك مهمة الرصد)

فكّر في التنفيذ بوصفه المحرك في السيارة: يوفر القوة والحركة، لكنه لا يقرر إلى أين تذهب أو متى تنعطف. تلك القرارات تأتي من السائق (التنسيق) باتباع خريطة (النوايا).

5.2. الوظائف#

خمسة مجالات وظيفية رئيسية تعمل معاً لتعديل حالة الشبكة بأمان وموثوقية:

1. تكامل البيانات: استرجاع الجرد وبيانات الاعتماد والنوايا وبيانات الرصد من الأنظمة المنبعية
2. التشغيل: بدء التنفيذ عبر آليات متزامنة أو غير متزامنة
3. إدارة الحالة: تتبع تقدم التنفيذ، وتمكين ثبات نتيجة التكرار والتراجع
4. المحرك: المنطق الأساسي الذي ينفّذ المهام بالتزامن المناسب ومعالجة الأخطاء
5. محوّل الشبكة: الواجهات الخاصة بالبروتوكول للتواصل مع أجهزة الشبكة المتنوعة

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

graph LR
    subgraph Goals
        G1[الحصول على البيانات الصحيحة في المكان الصحيح]
        G2[البدء عند الحاجة]
        G3[تتبع الحالة بمرور الوقت]
        G4[التنفيذ بموثوقية على نطاق واسع]
        G5[العمل مع أي جهاز شبكة أو منصة]
    end

    subgraph Pillars
        P1[طبقة تكامل البيانات]
        P2[آليات تشغيل مرنة]
        P3[بنية إدارة الحالة]
        P4[محرك تنفيذ قوي]
        P5[طبقة تجريد البروتوكول]
    end

    subgraph Functionalities
        F1[تكامل البيانات]
        F2[التشغيل]
        F3[إدارة الحالة]
        F4[المحرك]
        F5[محوّل الشبكة]
    end

    G1 --> P1 --> F1
    G2 --> P2 --> F2
    G3 --> P3 --> F3
    G4 --> P4 --> F4
    G5 --> P5 --> F5

المعمارية الداخلية تبدو هكذا:

graph TD
    A[تكامل البيانات] --> C[المحرك]
    B[التشغيل] --> C[المحرك]
    C --> E[إدارة الحالة]
    E --> C
    C --> D[محوّل الشبكة]
    classDef component fill:#e1f5ff,stroke:#4a90e2,stroke-width:2px;
    class A,B,C,D,E component;

5.2.1. تكامل البيانات#

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

5.2.1.1. الجرد#

تحدد بيانات الجرد الأجهزة المستهدفة. تناولنا ذلك في الفصل 4، لكن كحد أدنى:

• الهدف: عنوان IP أو FQDN للوصول إلى الجهاز
• المنصة/نظام التشغيل: نوع الجهاز والمورد وإصدار نظام التشغيل (يحدد البروتوكول والأوامر المستخدمة)
• بيانات الاعتماد: اسم المستخدم/كلمة المرور، ومفاتيح Secure Shell (SSH)، ورموز Application Programming Interface (API)، ومسارات الشهادات
• معاملات الاتصال: منفذ Secure Shell (SSH)، وقيم المهلة، ونقاط نهاية Application Programming Interface (API)
• البيانات الوصفية: موقع الموقع، والدور (عمود فقري/ورقة/حافة)، والبيئة (إنتاج/تجهيز)

ينبغي أن تأتي بيانات الجرد من مصدر الحقيقة. استخدام الملفات فقط يعمل جيداً في البيئات صغيرة جداً. يستعلم محرك تنفيذك عن Application Programming Interface (API) مصدر الحقيقة وقت التشغيل (أو يتلقى البيانات عبر التنسيق عند التشغيل). بعض الأنظمة تُخزّن الجرد مؤقتاً لتحسين الأداء مع فترات تحديث قابلة للتهيئة، أو تستفيد من الجرد المدفوع بالأحداث الذي يجمع المشغّل مع المعلومات المرتبطة.

لا تخزّن بيانات الاعتماد أبداً في ملفات الجرد أو السجلات. استخدم نظام إدارة أسرار (HashiCorp Vault، وAWS Secrets Manager، وCyberArk) وأدخل بيانات الاعتماد وقت التنفيذ. ينبغي لمصدر الحقيقة توفير مؤشرات لتلك البيانات الحساسة واسترجاعها وقت التشغيل. ينبغي لمحرك تنفيذك دعم مصادر بيانات اعتماد متعددة وتجاوزات بيانات اعتماد لكل جهاز.

5.2.1.2. البيانات المقصودة#

البيانات المقصودة هي ما تريد تهيئته أو تغييره. تأتي هذه من كتلة النوايا/مصدر الحقيقة وقد تشمل:

• مخرجات التهيئة: مخرجات جاهزة للنشر يمكن أن تكون بيانات منظمة تُستخدم مباشرةً مع الـAPIات، أو مجموعة أوامر CLI تبني التهيئة.
• الأوامر: أوامر Command Line Interface (CLI) محددة أو استدعاءات Application Programming Interface (API) لتنفيذ عمليات الأجهزة.
• الملفات: صور البرامج للترقيات، وملفات التهيئة للاستيراد.

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

توصيتي هي استهلاك مخرجات التهيئة مباشرةً. ينبغي لكتلة النوايا أن تكون مسؤولة عن توليد مخرجات التهيئة بمنطقها الخاص، مُخرِجةً قوالب التهيئة بالبيانات المنظمة التي تمثل الحالة (تهيئات VLAN وسياسات التوجيه وACLات).

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

5.2.1.3. البيانات المرصودة#

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

إليك بعض حالات الاستخدام حيث تُستخدم بيانات الرصد بالقرب من تدفق التنفيذ:

• التحقق المسبق للتنفيذ: هل الجهاز متاح؟ هل توجد مساحة قرص كافية للترقية؟ هل توجد جلسات نشطة ستتعطل؟
• التدهور الرشيق: قبل إعادة تشغيل مفتاح، استعلم عن الرصد لمعرفة ما إذا كانت هناك اتصالية متكررة. إن لم تكن، أخّر أو ألغِ.
• المنطق الشرطي: طبّق التهيئة فقط إن تحققت شروط معينة (CPU أقل من الحد، لا تنبيهات نشطة، الوقت ضمن النافذة)
• تصريف السعة: قبل تنفيذ عملية تصريف، تأكد من أن السعة المتاحة كافية لاستيعاب التغيير بلا كسر SLOات.

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

نمط شائع: أدوات مثل وحدات “فحوصات صحة الشبكة” في Ansible أو مهام جمع البيانات في Nornir تشغّل استعلامات رصد قبل وبعد التنفيذ، مقارنةً النتائج لاكتشاف التغييرات غير المتوقعة. نهج “اللقطة قبل/بعد” يلتقط التراجعات التي ستمر بخلاف ذلك دون أن تُلاحَظ.

5.2.2. التشغيل#

التنفيذ لا يبدأ من تلقاء نفسه. شيء ما يجب أن يُشغّله. تدعم أنظمة التنفيذ الحديثة آليات تشغيل متعددة:

متزامن (فوري، حاجب):

• استدعاءات Representational State Transfer (REST) Application Programming Interface (API): نظام خارجي أو مستخدم يستدعي نقطة نهاية Application Programming Interface (API)، ويتشغّل التنفيذ، وتشمل الاستجابة النتائج. بسيط ومباشر.
• Webhooks: الأنظمة الخارجية (Term "git" not found، التذاكر، CI/CD) ترسل طلبات HTTP حين تقع الأحداث. النمط الشائع: دفع Term "git" not found يُشغّل نشر التهيئة.
• أوامر Command Line Interface (CLI): يشغّل المهندسون أوامر تستدعي التنفيذ مباشرةً (ansible-playbook، terraform apply، سكريبتات مخصصة). هذه الأوامر جزء من طبقة العرض الخفيفة التي توفرها هذه الأدوات (المزيد في الفصل 8).

غير متزامن (مؤجّل أو مدفوع بالأحداث):

• مستمعو الأحداث: التفاعل مع الأحداث من الرصد (جهاز معطل، تجاوز حد)، وقوائم انتظار الرسائل، أو الأنظمة الخارجية. الأتمتة المدفوعة بالأحداث في Ansible (EDA) بنت هذا النمط صراحةً: استمع للأحداث، وطابق القواعد، وشغّل كتب التشغيل تلقائياً.
• قوائم انتظار الرسائل: مهام مُقدَّمة إلى قائمة انتظار (RabbitMQ، وKafka، وAWS SQS)، ويسحبها العمال وينفّذونها. يُمكّن التخزين المؤقت والأولوية في الانتظار وتحديد المعدل.

النهج الصحيح يعتمد على حالة استخدامك. التغييرات الفورية (إصلاح مشكلة إنتاجية) تحتاج مشغّلات متزامنة. الأتمتة التفاعلية (الاستجابة للتنبيهات) تستخدم مستمعي الأحداث. اعتبارات الحجم مهمة أيضاً، كما سنتناول في الفصل 11.

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

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

5.2.3. إدارة الحالة#

إدارة الحالة تتعلق بتتبع أين أنت في التنفيذ وكيف يبدو العالم حتى تتمكن من اتخاذ قرارات ذكية. هناك فئتان رئيسيتان:

• حالة التنفيذ (تتبع الأتمتة نفسها):

  • أي الأجهزة تمت معالجتها؟
  • أي المهام نجحت وفشلت أو معلقة؟
  • إن فشلت مهمة بخطأ عابر، هل يمكننا إعادة المحاولة؟
  • إن انقطع التنفيذ، هل يمكننا الاستئناف من حيث توقفنا؟

• حالة البنية التحتية الفعلية (تتبع حالة التهيئة المستهدفة):

  • ما الذي هو مُهيَّأ حالياً؟

نهجان موجودان:

• عديم الحالة/بلا وكيل (مثل Ansible). كل تنفيذ يعمل باستقلالية. لا حالة مستمرة بين التشغيلات. كل تنفيذ يبدأ من جديد: جمع الحالة الراهنة، حساب الفرق، تطبيق التغييرات. أبسط في التشغيل (لا قاعدة بيانات للحالة)، لكن أقل كفاءة (تُعيد اكتشاف كل شيء في كل مرة) وبلا تراجع مدمج.

• مع الحالة (مثل Terraform). يحتفظ النظام بملف حالة مستمر يتتبع ما نُشر آخر مرة. في كل تشغيل، قارن الحالة المطلوبة (تهيئتك) بالحالة المسجّلة (ما نشرته آخر مرة) بالحالة الفعلية (ما على الجهاز). هذا يُمكّن تخطيطاً دقيقاً للتغيير، وتنفيذاً كفؤاً (غيّر فقط ما يختلف)، وتراجعاً (عود إلى الحالة السابقة). لكن الآن لديك ملف حالة تحميه وتقفله وتزامنه عبر مشغّلين متعددين.

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

• حد واضح (ما العمليات داخل المعاملة)
• سجل دائم للحالة قبل التغيير (للتراجع)
• آلية قفل أو إيجار لمنع التغييرات المتزامنة من كسر الذرية

على أرض الواقع، تستخدم معظم أتمتة الشبكة سلوكاً “شبيهاً بالمعاملة” بدلاً من دلالات ACID الصارمة، لأن ليس كل الأجهزة تدعم الالتزام/التراجع الأصلي. رغم ذلك، يمكنك تقريب المعاملات عن طريق أخذ اللقطات، واستخدام التهيئات المرشحة (حين يكون ذلك مدعوماً)، وفرض أقفال حصرية، وجعل مسارات التراجع جزءاً من الدرجة الأولى في تدفق التنفيذ.

التحدي؟ مزامنة الحالة ومشاركتها. إن عدّل أشخاص أو أنظمة متعددة أجهزة الشبكة، تتقادم الحالة. يعالج Terraform هذا بتخزين الحالة البعيد والقفل. يتجنب Ansible المشكلة بكونه عديم الحالة لكنه يضحي بالكفاءة. الحل الوسط: تخزين الحالة الراهنة مؤقتاً، والتحقق قبل كل عملية، وبناء أنماط “الاتساق النهائي” حيث تُقبَل التناقضات العابرة.

5.2.3.1. ثبات نتيجة التكرار#

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

كيف تحقق الأدوات ثبات نتيجة التكرار:

• وحدات مدمجة (مثل Ansible): معظم وحدات Ansible مصممة لتكون ثابتة النتيجة. وحدة ios_vlan تتحقق من وجود VLAN قبل إنشائه. إن كان موجوداً بالفعل بالتهيئة الصحيحة، يُبلّغ Ansible “ok” (لا تغيير). يستلزم ذلك من مؤلف الوحدة تنفيذ منطق التحقق.

• مقارنة الحالة (مثل Terraform): يقارن Terraform الحالة المطلوبة بالحالة الراهنة، يحسب الفرق، ويطبق الاختلافات فقط. إن شغّلت terraform apply مرتين بلا تغييرات في تهيئتك، التشغيل الثاني لا يفعل شيئاً.

• الـAPIات التعريفية (مثل NETCONF/YANG): بعض البروتوكولات تتعامل مع ثبات نتيجة التكرار بشكل أصلي. <edit-config> في NETCONF مع عملية merge ثابت النتيجة بطبيعته: يدمج تهيئتك مع التهيئة الحالية، ينشئ أو يحدّث حسب الحاجة.

• التحقق اليدوي (مثل السكريبتات الخام): إن كنت تكتب سكريبتات Python أو Go، تنفّذ ثبات نتيجة التكرار بنفسك: استعلم عن الحالة الراهنة، قارنها بالحالة المطلوبة، أجرِ تغييرات فقط إن وجد فرق.

ثبات نتيجة التكرار أصعب مما يبدو. ماذا لو كان VLAN موجوداً لكن بإعدادات خاطئة؟ هل تحدّثه (مع احتمال تعطيل حركة المرور) أم تُبلّغ عن تعارض؟ ماذا عن الإخفاقات العابرة (جهاز غير متاح مؤقتاً)؟ يجب على منطق إعادة المحاولة التمييز بين “العملية مُنجزة بالفعل” (نجاح ثابت النتيجة) و"العملية فشلت" (خطأ حقيقي).

ثبات نتيجة التكرار الكامل يضيف عبئاً. كل عملية تستلزم الاستعلام عن الحالة الراهنة أولاً. للنشر الواسع النطاق، هذا يُبطّئ الأمور. بعض الفرق تقبل “ثابت النتيجة في الغالب” (يعمل 99% من الوقت) بدلاً من “ثابت النتيجة تماماً” (يعمل دائماً، لكن ببطء).

ثبات نتيجة التكرار متطلب للنهج التعريفي. شخص ما يجب أن يتحمل عبء توفير ثبات النتيجة وإخفاء التعقيد عن الجميع الآخرين.

5.2.4. المحرك#

محرك التنفيذ هو المنطق الأساسي الذي يأخذ مهمة (“هيّئ هذا VLAN على هذه الـ50 مفتاحاً”) وينفّذها بأمان وكفاءة. هذا ليس التنسيق. تنسّق كتلة التنسيق مهام تنفيذ متعددة عبر الزمن والتبعيات. المحرك فقط يشغّل مهمة واحدة بشكل جيد (أو سلسلة بسيطة من المهام).

ما يفعله:

• يقبل تعريف مهمة (ما يجب فعله، وأي الأجهزة)
• يقسّمها إلى عمليات ذرية (إجراءات لكل جهاز)
• ينفّذ العمليات بالتزامن المناسب (متسلسل، ومتوازٍ، ودفعات)
• يتعامل مع الأخطاء وإعادة المحاولة والتراجع
• يُبلّغ عن التقدم والنتائج

قد يهيّئ محرك تنفيذ 100 جهاز توجيه بالتوازي، لكنه لا يقرر متى يهيّئها، وأي التهيئات يطبق بناءً على منطق الأعمال، أو ما يفعله بعد ذلك بناءً على النتائج. تلك اهتمامات التنسيق. التنفيذ هو حصان العمل؛ التنسيق هو المشرف.

مع ذلك، غالباً ما تدعم محركات التنفيذ التسلسل البسيط: “افعل المهمة أ، ثم المهمة ب على الأجهزة ذاتها.” هذا تسلسل أساسي، لا تنسيق كامل. حين تحتاج سير عمل معقدة (انتظر موافقة خارجية، وتفرّع بناءً على النتائج، ونسّق عبر أنظمة متعددة) تحتاج طبقة تنسيق حقيقية (المزيد في الفصل 7).

5.2.4.1. اللغات#

كيف تحدد منطق التنفيذ؟ أساليب اللغات المختلفة لها مقايضات مختلفة:

كثير من الفرق تستخدم DSLs (Ansible) للأنماط الشائعة وتنزل إلى الكود المخصص (وحدات Python والإضافات) لحالات الحافة المعقدة. هذا يوازن بين سهولة الوصول والقوة. عامل الإنسان عادةً يقرر أي النهجين يفوز، المزيد عن ذلك في الفصل 13.

5.2.4.2. الأمري مقابل التعريفي#

الأمري: تحدد كيف تفعل شيئاً، خطوة بخطوة.

التعريفي: تحدد ما ينبغي أن تكون عليه الحالة النهائية، والأداة تستنتج الكيفية.

باختصار، فضّل التعريفي حين يُناسب.

طريقة جيدة لرؤية الفرق هي النظر إلى Ansible الذي يدعم كليهما:

• Ansible الأمري:

  - name: Create VLAN 100
    cisco.ios.ios_command:
      commands:
        - vlan 100
        - name Engineering

  أنت حرفياً تخبر Ansible بالأوامر التي يشغّلها. إن كان VLAN موجوداً، هذا لا يزال يشتغل (وإن كان قد يكون ثابت النتيجة اعتماداً على الوحدة).

• Ansible التعريفي:

  - name: Ensure VLAN 100 exists
    cisco.ios.ios_vlans:
      config:
        - vlan_id: 100
          name: Engineering
      state: merged

  تصف الحالة المطلوبة. Ansible يستنتج ما هي الأوامر التي سيشغّلها. إن كان VLAN 100 موجوداً بالفعل بالاسم الصحيح، Ansible لا يفعل شيئاً.

معظم الفرق تستخدم التعريفي حين يكون ممكناً، والأمري حين يكون ضرورياً. تذكر فقط: التعريفي يعني أن شخصاً آخر يتحمل العبء، حتى لو بدا بسيطاً من الخارج.

5.2.4.3. المتسلسل مقابل المتوازي#

خياران موجودان لتشغيل المهام:

• التنفيذ المتسلسل: معالجة الأجهزة واحداً تلو الآخر. هيّئ الجهاز 1، انتظر الاكتمال، هيّئ الجهاز 2، إلخ. آمن (ترى الإخفاقات فوراً ويمكنك التوقف)، لكن بطيء (100 جهاز = 100× وقت جهاز واحد).

• التنفيذ المتوازي: معالجة أجهزة متعددة في آن واحد. هيّئ الأجهزة 1-10 معاً، ثم 11-20، إلخ.

flowchart TD
    subgraph تسلسلي
        S1[الجهاز 1] --> S2[الجهاز 2] --> S3[الجهاز 3]
    end
    subgraph متوازٍ
        P0[البدء] --> P1[الجهاز 1]
        P0 --> P2[الجهاز 2]
        P0 --> P3[الجهاز 3]
    end

لماذا وُجد Nornir: كان Ansible في الأصل متسلسلاً. لأتمتة الشبكة على نطاق واسع، كان هذا بطيئاً بشكل مؤلم. أضاف Ansible strategy: free ثم forks لاحقاً لتمكين التوازي، لكنه لا يزال مصمماً أساساً للتنفيذ المتسلسل. بُني Nornir من الأساس مع التوازي: يستخدم الترابط (Threading) بشكل افتراضي للتنفيذ على أجهزة متعددة في آن واحد. هذا يجعله أسرع بـ10-100 مرة لأعداد كبيرة من الأجهزة.

اعتبارات للتنفيذ المتوازي:

• تأثير مستوى التحكم: ضرب 1000 جهاز في آن واحد قد يُثقل شبكات الإدارة ومصادر البيانات وأنظمة المصادقة أو مستويات التحكم للأجهزة.
• التعامل مع التبعيات: إن تعتمد أجهزة على بعضها (العمود الفقري قبل الأوراق)، تحتاج ترتيباً. التوازي الخالص لا يعمل.
• نطاق تأثير الخطأ: إن كانت أتمتتك تحتوي خللاً، التنفيذ المتوازي ينشره على أجهزة كثيرة قبل أن تلاحظ. التنفيذ المتسلسل يفشل على الجهاز 1، وتتوقف قبل إلحاق الضرر بالأجهزة 2-100.

توصيتي: استخدم التنفيذ المتوازي مع تقسيم الدفعات. عالج الأجهزة في مجموعات من 10-50 (اعتدت تسميتها “موجات”)، تحقق من نجاح كل دفعة قبل الاستمرار. هذا يوازن بين السرعة والأمان. المزيد عن استراتيجيات النشر في الفصل 10.

5.2.4.4. التشغيل التجريبي (وضع التخطيط)#

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

مثال (خطة Terraform لـAWS VPC بتغييرات قابلة للمراجعة):

Terraform will perform the following actions:

  # aws_vpc.main will be created
  + resource "aws_vpc" "main" {
      + cidr_block           = "10.10.0.0/16"
      + enable_dns_support   = true
      + enable_dns_hostnames = true
      + tags = {
          + "Name" = "core-vpc"
        }
    }

Plan: 1 to add, 0 to change, 0 to destroy.

هذا ما يوقّع عليه المراجعون: الموارد والسمات التي ستتغير بالضبط، بلا لمس السحابة.

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

من تجربتي، تقديم قدرات التشغيل التجريبي مفيد جداً في الأيام الأولى لمشروع أتمتة للحصول على قبول مهندسي الشبكة. لاحقاً، تتراجع أهميته.

5.2.4.5. المرونة#

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

منطق إعادة المحاولة:

• الإخفاقات العابرة (مهلة الاتصال، ارتفاع مؤقت في المعالج) ينبغي أن تُشغّل إعادة المحاولة مع التراجع الأسي
• ميّز الأخطاء القابلة للإعادة (مهلة) من الأخطاء الدائمة (فشل مصادقة، خطأ صياغة)
• قيّد محاولات إعادة المحاولة لتجنب الحلقات اللانهائية

استراتيجيات المهلة:

• مهل الاتصال: كم من الوقت تنتظر استجابة الجهاز قبل الاستسلام
• مهل المهمة: كم من الوقت يمكن أن تعمل عملية كاملة (يمنع التوقف على أجهزة عالقة)
• مهل عالمية: أقصى وقت تنفيذ لمهمة كاملة

معالجة الأخطاء:

• الفشل السريع: جهاز واحد يفشل، ألغِ كل شيء (آمن لكن غير كفؤ)
• الاستمرار: سجّل الإخفاق، تابع مع أجهزة أخرى (كفؤ لكن قد ينشر الضرر)
• مبني على الحد: إن فشل أكثر من 10% من الأجهزة، توقف (متوازن)

قدرات التراجع:

• أخذ لقطات التهيئة قبل التغييرات
• إن فشل التنفيذ، استعد اللقطات تلقائياً
• دعم وضع التشغيل التجريبي: أظهر ما سيتغير بلا تغييره فعلاً

قواطع الدائرة:

• إن كان جهاز يفشل باستمرار، علّمه كغير صحي وتخطَّه مؤقتاً
• يمنع إضاعة الوقت في محاولات متكررة للاتصال بأجهزة معطلة

نقاط التفتيش:

• احفظ التقدم دورياً
• إن تعطّل التنفيذ، استأنف من آخر نقطة تفتيش بدلاً من البدء من جديد

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

نمط مفيد: عامل “أوضاع الأمان” كحالات تنفيذ من الدرجة الأولى. اعرض التهيئة المقصودة، وحلّل التهيئة الراهنة، واجمع الحقائق، ثم طبّق (merged/replaced/overridden) فقط بعد اجتياز بوابات التحقق. هذا يعطيك نقاط تفتيش حتمية قبل لمس الإنتاج.

5.2.5. محوّل الشبكة#

تتحدث أجهزة الشبكة بروتوكولات مختلفة. تُجرّد طبقة محوّل الشبكة هذه الاختلافات حتى لا تكترث الطبقات العليا بما إذا كانت تتحدث إلى مفتاح Cisco عبر Secure Shell (SSH) أو مفتاح Arista عبر Representational State Transfer (REST) Application Programming Interface (API).

5.2.5.1. الواجهات#

تدعم الأجهزة المختلفة واجهات إدارة مختلفة:

بعض المكتبات توفر طبقة تجريد مع واجهة مشتركة عبر المنصات، مثل:

• NAPALM (Network Automation and Programmability Abstraction Layer with Multivendor support): مكتبة Python توفر API موحّداً عبر الموردين.
  • تدعم Cisco وArista وJuniper وغيرها
  • تحت الغطاء، تستخدم البروتوكول المناسب (Secure Shell (SSH)، Application Programming Interface (API)، NETCONF)
  • حالة الاستخدام: بيئات متعددة الموردين حيث تريد كود أتمتة متسقاً
• Pybatfish: ليست مكتبة نقل للأجهزة، لكنها رفيقة قوية لأمان التنفيذ. نمط عملي هو “خطط/طبّق مع NAPALM أو Ansible، تحقق من سلوك الشبكة مع pybatfish قبل وبعد التغييرات.”

لماذا تستخدم طبقة تجريد؟ بدلاً من كتابة كود مختلف لـCisco مقابل Juniper، تعطيك NAPALM واجهة واحدة. استدعِ get_facts() وتستنتج NAPALM كيفية الحصول على حقائق الجهاز سواء كان جهاز Cisco IOS (عبر Secure Shell (SSH)) أو Arista EOS (عبر eAPI) أو Juniper Junos (عبر NETCONF). المقايضة: التجريد يخفي الميزات الخاصة بالمورد. للعمليات الشائعة (الحصول على التهيئة، دفع التهيئة، الحصول على الحقائق)، رائع. للعمليات الأكثر تقدماً أو الميزات الغريبة للمورد، تعود إلى الواجهات الأصلية لأنها على الأرجح غير مُنفَّذة.

5.2.5.2. العمليات#

تنفيذ الشبكة ليس مجرد إدارة تهيئة:

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

أين ينتمي التحقق والعرض: يملك مصدر الحقيقة النوايا و(اختيارياً) التهيئات المُولَّدة مسبقاً. يملك التنفيذ فحوصات الأمان على مستوى الجهاز والتحقق التشغيلي (إمكانية الوصول والفحوصات قبل/بعد). يقرر التنسيق متى يتحقق وماذا يفعل بالنتائج (يوافق، أو يتوقف، أو يتراجع، أو يُصعّد). إن أردت قاعدة بسيطة: التحقق الذي يغيّر سير العمل ينتمي إلى التنسيق؛ التحقق الذي يغيّر إجراءات الجهاز ينتمي إلى التنفيذ.

5.2.6. الحلول#

كثير من الأدوات موجودة لتنفيذ الشبكة، ومقارنتها تساعد على فهم المقايضات:

كثير من الفرق تستخدم أدوات متعددة اعتماداً على حالة الاستخدام والبنية التحتية للشبكة.

5.2.7. التوفير بلا لمس (ZTP)#

التوفير بلا لمس (ZTP - Zero Touch Provisioning) هو نمط تنفيذ مميز حيث يُقلع جهاز للمرة الأولى ويسترجع تهيئته الكاملة ويطبّقها تلقائياً بلا أي تدخل بشري على الجهاز. تدفق البيانات مختلف هيكلياً عن عمليات اليوم-2 ويستحق المعاملة كنمط معماري مُسمَّى.

تدفق ZTP

flowchart LR
    A[الجهاز يُقلع\nبلا تهيئة] --> B[DHCP يخصص\nIP الإدارة\nوعنوان bootstrap]
    B --> C[الجهاز يجلب\nتهيئة bootstrap\nمن الخادم]
    C --> D[الجهاز يُصادق\nعلى مصدر الحقيقة\nوشبكة الإدارة]
    D --> E[المُنسِّق يكتشف\nجهازاً جديداً ويُشغّل\nمهمة التوفير الكاملة]
    E --> F[المُنفِّذ يطبق\nالنوايا الكاملة من مصدر الحقيقة]

الرؤية الجوهرية هي أن خطوة الإقلاع متعمداً دنيا: التهيئة الكافية فقط لإدخال الجهاز إلى شبكة الإدارة وتمكينه من المصادقة. يتشغّل التوفير الكامل بعد ذلك كمهمة مُنفِّذ قياسية، سحباً للنوايا الكاملة من مصدر الحقيقة. هذا يعني أن ZTP يُعيد استخدام خط أنابيب التنفيذ ذاته كعمليات اليوم-2 بدلاً من استلزام نظام توفير منفصل.

أنماط ZTP الشائعة

يُدخل ZTP تبعية تسلسلية: يجب تسجيل الجهاز في مصدر الحقيقة قبل أن يُقلع مادياً، وإلا خادم bootstrap لا تتوفر لديه بيانات لتوليد تهيئة منها. في سيناريو الحرم الجامعي، يُعالج ذلك من خلال مزامنة ServiceNow إلى Nautobot: حين يُضاف مفتاح كأصل في ServiceNow (قبل وصوله إلى الموقع)، يُنشئ Nautobot تلقائياً سجل الجهاز بالموقع والدور والمورد. حين يُقلع المفتاح، مصدر الحقيقة جاهز بالفعل.

5.2.8. التنفيذ الهجين والسحابي#

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

مشكلة التباين

المعمارية الموصى بها

أبقِ النوايا (مصدر الحقيقة) والتنسيق موحّدين. نفس طلب الأعمال الذي ينشئ VLAN على مفاتيح الحرم الجامعي قد يحتاج أيضاً إلى إنشاء مجموعة أمان في AWS. يملك مصدر الحقيقة كليهما. ينسّق المُنسِّق كليهما. فقط في طبقة محوّل الشبكة (5.2.5) يتباين مسار التنفيذ: محوّل واحد يتعامل مع NETCONF/Ansible ضد مفاتيح الحرم الجامعي؛ آخر يتعامل مع Terraform أو APIs مزوّد السحابة ضد البيئة السحابية.

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

يجب أن تستوعب استراتيجية مدير الأسرار كلاً من بيانات اعتماد أجهزة الشبكة طويلة الأمد والرموز السحابية قصيرة الأمد. للمنصات السحابية، ينبغي توليد بيانات الاعتماد عند بدء المهمة وعدم تخزينها أبداً. يوفر معظم مزوّدي السحابة آليات لذلك (ملفات تعريف مثيلات AWS، وهويات Azure المُدارة، وهوية عبء عمل GCP). تبقى بيانات اعتماد أجهزة الشبكة في Vault وتُحقن وقت التشغيل. لا ينبغي للمُنفِّذ أبداً الاحتفاظ ببيانات الاعتماد بين تشغيلات المهمة بصرف النظر عن نوع الهدف.

5.2.9. اعتبارات الأمان#

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

إدارة بيانات الاعتماد

لا ينبغي أبداً أن تظهر بيانات اعتماد أجهزة الشبكة في كتب التشغيل أو القوالب أو تعريفات المهام أو التحكم في الإصدارات. النمط واضح: تخزين الأسرار في مدير أسرار مخصص (HashiCorp Vault، وAWS Secrets Manager، وCyberArk) وحقنها وقت التشغيل في بيئة المُنفِّذ. يجلب المُنفِّذ بيانات الاعتماد عند بدء المهمة؛ لا يحتفظ بها بشكل دائم.

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

الحد الأدنى من الصلاحيات لكل عملية

لا تحتاج كل عملية تنفيذ المستوى ذاته من الوصول. عمليات القراءة (جمع الحقائق والفحوصات التجريبية والتحقق قبل النشر) ينبغي أن تستخدم بيانات اعتماد للقراءة فقط. ينبغي لعمليات الكتابة استخدام بيانات اعتماد محدودة النطاق لنوع التغيير: مهمة نشر تغييرات VLAN لا ينبغي أن تملك بيانات اعتماد تتيح تغيير تهيئات BGP. حيث تدعم منصة الشبكة التحكم في الوصول المبني على الأدوار (أدوار Arista، ومستويات صلاحية Cisco، والتحكم في وصول NETCONF)، استخدمه لتحديد نطاق تأثير أي جلسة مُخترَقة.

عبر مثال الحرم الجامعي، يعني ذلك أن مهمة نشر VLAN على مفتاح Arista تستخدم دوراً يتيح تهيئة VLAN والواجهة لكن لا يمكنه لمس تهيئة بروتوكول التوجيه أو إعدادات مستوى الإدارة.

فصل المخاوف

من يمكنه تشغيل التنفيذ ومن يمكنه تعديل منطق الأتمتة ينبغي أن يكونا أدواراً مختلفة مع ضوابط وصول مختلفة. المشغّل الذي يوافق ويشغّل مهمة نشر VLAN لا يحتاج، ولا ينبغي أن يملك، صلاحية تعديل أدوار Ansible أو قوالب كتاب التشغيل التي تنفّذها. في AWX وAAP، يُفرَض ذلك من خلال تعيينات الأدوار: “مُشغّل المهمة” يمكنه بدء قوالب مهام معتمدة مسبقاً؛ “محرر المشروع” يمكنه تغيير منطق الأتمتة الأساسي.

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

متطلبات مسار التدقيق

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

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

تجزئة شبكة البنية التحتية للأتمتة

ينبغي للمُنفِّذ ومستوى التحكم الخاص به (AWX، وعقد التحكم في Ansible) أن يقعا في مقطع شبكة إدارة. ينبغي لحركة التنفيذ إلى الأجهزة التدفق عبر شبكة الإدارة خارج النطاق حيث يكون ذلك متاحاً، لا عبر مستوى البيانات ذاته الذي قد يعدّله المُنفِّذ. ينبغي لوصول الداخل لتشغيل المهام استلزام المصادقة وألا يكون متاحاً من الشبكات غير الموثوقة.

نمط إخفاق عملي ينبغي تجنّبه: المُنفِّذ المتاح من VLAN مستخدم الإنتاج يعني أن أي جهاز مُخترَق في ذلك VLAN يمكنه محتملاً تشغيل تغييرات الشبكة. وصول مستوى الإدارة ينتمي إلى شبكة مستوى الإدارة.

5.3. مثال تطبيقي#

5.3.1. حالة الاستخدام: نشر VLAN آلي عبر حرم جامعي غير متجانس#

نتابع مع شبكة الحرم الجامعي من الفصل 4. تعريف خدمة VLAN (معرّفه والشبكة الفرعية وقوالب التهيئة لكل مورد ومجموعات المفاتيح المستهدفة) مخزون الآن في مصدر الحقيقة. يركز هذا الفصل على كيفية التقاط كتلة التنفيذ لتلك النوايا ونشرها بموثوقية عبر جميع الـ800 مفتاح.

السيناريو: يطلب فريق أعمال VLAN جديداً لتطبيق جديد. يأتي الطلب من خلال نظام تذاكر بتفاصيل: معرف VLAN والاسم ومواقع الحرم الجامعي والموافقة. تنشر عمليات الشبكة هذا VLAN عبر مفاتيح الوصول/التوزيع من Arista وHPE وCisco، وتتحقق من الاتصال، وتُبلّغ عن النجاح.

المتطلبات:

• نشر تهيئة VLAN على مفاتيح متعددة بالتوازي
• التحقق من الشروط المسبقة (VLAN غير موجود بالفعل، المفاتيح متاحة)
• إجراء تشغيل تجريبي لإظهار ما سيتغير
• تنفيذ النشر الفعلي مع قدرة التراجع إن حدثت إخفاقات
• التحقق بعد النشر (VLAN نشط، لا أخطاء)

5.3.2. معمارية الحل#

تكبير لعرض المعمارية الكاملة قبل الغوص في تفاصيل التنفيذ:

1. مصدر الحقيقة: NetBox (يخزن الجرد وتعريفات VLAN)
2. التنسيق/التشغيل: تنسيق قالب سير عمل AWX (إطلاق عبر API وwebhook وجدول)
3. الرصد: يوفر بيانات آنية لاتخاذ القرارات
4. التنفيذ:
   • محرك التنفيذ: قوالب/مهام مهام Ansible (فحص مسبق وتشغيل تجريبي ونشر وتحقق وتراجع)
   • تكامل البيانات: إضافة جرد NetBox في Ansible/AWX
   • محوّلات الشبكة: وحدات Ansible لـCisco IOS XE وArista EOS وHPE/Aruba
   • إدارة الحالة: حالة مهمة/سير عمل AWX لكل مرحلة ونتائج لكل مضيف، مع مهمة تراجع على مسارات الإخفاق

هذا الحل لأغراض توضيحية؛ ليس توصية عالمية.

5.3.3. تدفق التنفيذ#

يتشغّل هذا كسير عمل AWX بعقد مهام متعددة:

1. تغيير نوايا VLAN في NetBox يُشغّل AWX عبر webhook
2. يبدأ سير عمل AWX ويشغّل مزامنة الجرد (NetBox)
3. تتحقق مهمة الفحص المسبق من إمكانية الوصول وحالة VLAN الحالية وحواجز حماية الموقع
4. تُخرج مهمة التشغيل التجريبي مهاماً خاصة بالمورد بلا تطبيق تغييرات
5. عقدة الموافقة (اختيارية) تُبوّب تنفيذ الإنتاج
6. تطبّق مهمة النشر نوايا VLAN في دفعات متوازية عبر الموردين
7. تُأكّد مهمة التحقق الحالة التشغيلية والمقصودة
8. عند الإخفاقات، تعمل مهمة التراجع فقط للنطاق المتأثر
9. الرصد يجمع بيانات قبل/بعد لدعم التحقق النهائي
10. يتشغّل التحقق النهائي ويُنشر ملخص التنفيذ

flowchart TD
    A[تغيير نوايا VLAN في NetBox] --> B[Webhook إلى AWX]
    B --> C[بدء سير عمل AWX]
    C --> E[مزامنة الجرد من NetBox]
    E --> F[مهمة الفحص المسبق]
    F --> G[مهمة التشغيل التجريبي]
    G --> H[عقدة الموافقة]
    H --> I[مهمة النشر]
    I --> J[مهمة التحقق]
    J --> N[جمع بيانات الشبكة]
    N --> L[التحقق النهائي]
    L --> M[تحديث التذكرة والتقرير]

    F -->|فشل| X[التوقف وإرجاع أخطاء التحقق]
    I -->|أجهزة فاشلة| Y[مهمة التراجع للأجهزة المتأثرة]
    Y --> J
    F --> N

    %% --- Styles ---
    classDef sot fill:#cfe8ff,stroke:#0b5fb3,stroke-width:2px;
    classDef orch fill:#ffe0cc,stroke:#c24b00,stroke-width:2px;
    classDef exec fill:#d7f4e1,stroke:#0f7a3b,stroke-width:2px;
    classDef obs fill:#ffd6d6,stroke:#b22222,stroke-width:2px;

    class A sot;
    class B,C,E,H,L,M orch;
    class F,G,I,J,Y,X exec;
    class N obs;

5.3.4. ملخص الحل#

يُجسّد هذا التنفيذ جميع قدرات التنفيذ الرئيسية:

• تكامل البيانات: يسحب الجرد والنوايا من NetBox باستخدام الجرد الديناميكي
• التشغيل: سير عمل AWX يدعم API/webhook/جدول، إضافةً إلى تنفيذ مُبوَّب بالموافقة
• إدارة الحالة: حالة سير عمل/مهمة AWX تتتبع التقدم ومجالات الإخفاق؛ مسار التراجع صريح
• المحرك: يتعامل Ansible مع التنفيذ المتوازي (مُهيَّأ عبر forks/التجميع) ومعالجة الأخطاء والتشغيل التجريبي
• محوّل الشبكة: وحدات الموارد الخاصة بالمورد تُعيّن نوايا واحدة إلى منصات مختلفة (cisco.ios.ios_vlans، وarista.eos.eos_vlans، ووحدات مجموعة HPE/Aruba)
• الرصد: جمع البيانات قبل/بعد يدعم التحقق النهائي والإبلاغ

ميزات المرونة:

• الفحوصات المسبقة تمنع النشر على أجهزة غير متاحة أو إنشاء VLANات مكررة
• التشغيل التجريبي يُظهر التغييرات قبل تطبيقها
• نقاط التفتيش الآمنة تستخدم حالات وحدات الموارد (rendered، وparsed، وgathered) قبل حالات التطبيق (merged، وreplaced، وoverridden)
• الوحدات الثابتة النتيجة تجعل إعادة التشغيل آمنة
• التحقق بعد النشر يلتقط الإخفاقات الصامتة
• التراجع: عقدة تراجع AWX مخصصة تُحدّد نطاق التراجع للأجهزة المتأثرة

اعتبارات التوسع:

• التنفيذ المتوازي عبر forks: 50 يعالج 50 مفتاحاً في آن واحد
• للنشر الأوسع (أكثر من 500 مفتاح)، قسّم إلى مجموعات واستخدم Ansible Tower/AWX لإدارة سير العمل
• أضف تحديد المعدل إن لم تتمكن أنظمة مستوى التحكم أو المصادقة من التعامل مع الحمل

5.4. الملخص#

كتلة التنفيذ هي حيث تصبح أتمتة الشبكة ملموسة: تُدفع التهيئات، وتُعاد تشغيل الأجهزة، وتحدث التغييرات. لكن التنفيذ الموثوق أكثر من مجرد إرسال أوامر عبر Secure Shell (SSH).

يبدأ بتكامل البيانات والتشغيل، ثم يعتمد على إدارة الحالة (ثبات نتيجة التكرار والتراجع والأمان الشبيه بالمعاملة)، ومحرك قادر (خيارات متسلسل/متوازٍ والتشغيل التجريبي/التخطيط والمرونة)، وطبقة محوّل شبكة تخفي اختلافات البروتوكول عبر الموردين. يُغذّي الرصد التحقق والحواجز بينما يقرر التنسيق متى يتابع أو يتوقف. الأدوات أقل أهمية من أنماط التنفيذ: تكامل البيانات، والتشغيل المتعمد، والتنفيذ الحتمي، والتحقق من النتائج، والحفاظ على مسار تراجع نظيف.

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

المراجع وقراءات إضافية#

• Network Programmability and Automation: Skills for the Next-Generation Network Engineer، الطبعة الثانية. O’Reilly Media, 2023. Matt Oswalt, Christian Adell, Scott S. Lowe, and Jason Edelman. الفصل 10 (أدوات الأتمتة) والفصل 12 (معمارية الأتمتة).
• Network Automation Cookbook، الطبعة الثانية. Packt Publishing, 2024. Christian Adell and Jeff Kala.
• توثيق أتمتة شبكة Ansible: https://docs.ansible.com/ansible/latest/network/
• Mastering Python Networking، الطبعة الرابعة. Packt Publishing, 2023. Eric Chou
• توثيق NAPALM: https://napalm.readthedocs.io/
• توثيق Nornir: https://nornir.readthedocs.io/
• أتمتة بنية تحتية الشبكة في Terraform: https://www.terraform.io/use-cases/network-infrastructure-automation

💬 Found something to improve? Send feedback for this chapter