7. التنسيق#

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

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

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

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

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

7.1.1. السياق#

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

ذلك الرابط هو Orchestrator.

في الفصل 3 وضعناه في مركز إطار NAF كالكتلة التي تنسّق جميع الأخرى. الفصل 5 أظهر كيف يطبّق المنفِّذ تغييرات التهيئة؛ الفصل 6 أظهر كيف يتحقق الرصد الشامل من النتائج. هذا الفصل يُظهر كيف يُرتِّب المنسِّق كليهما، ويتعامل مع كل ما يمكن أن يسوء بينهما.

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

7.1.2. الأهداف#

على المنسِّق تحقيق خمسة أهداف:

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

2. الاستجابة للأحداث تلقائياً، بأو بدون بدء بشري. موافقة ServiceNow، تنبيه الرصد الشامل، فحص امتثال مجدول: يجب أن يتمكن جميعها من تشغيل سير العمل دون أن يبدأه إنسان يدوياً.

3. تنفيذ مرن وقابل للتوسع. سير عمل يُلامس 800 مفتاح بالتوازي يجب أن يكتمل بموثوقية. يجب أن ينجو من إعادة تشغيل. يجب أن يتعامل مع الأعطال الجزئية دون فقدان العمل الذي أتمّته الأجهزة التي نجحت.

4. توفير رؤية مقاومة للتلاعب. يحتاج المشغّلون رؤية ما يعمل الآن. يحتاج المدققون رؤية ما عمل الشهر الماضي، ومن شغّله، وأي إصدار من سير العمل عمل، وما أنتجته كل خطوة. يجب تلبية كلا الحاجتين من نفس النظام.

5. إدارة تعريفات سير العمل كبرمجيات إنتاج. سير عمل ينشر على 800 مفتاح إنتاجي لا يمكن تغييره باستهتار. المنطق نفسه يحتاج الحفظ والإصدار والاختبار والترقية إلى الإنتاج بنفس الانضباط المطبَّق على أي كود يعمل في الإنتاج.

7.1.3. الركائز#

خمس ركائز تدعم هذه الأهداف:

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

7.1.4. النطاق#

المنسِّق ينسِّق. لا يتصرف.

في النطاق:

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

خارج النطاق:

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

خطأ شائع هو بناء منسِّق يُكرِّر مسؤوليات التنفيذ أو التخزين لجيرانه. يجب أن تبقى الواجهة بين الكتل نظيفة.

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

7.2. الوظائف#

تُحقَّق الأهداف والركائز الخمسة من خلال خمس وظائف أساسية. كل منها يرتبط مباشرةً بهدف وركيزة داعمة:

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

graph LR

    subgraph الأهداف
        direction TB
        A1[تنسيق سير عمل متعدد الكتل من البداية إلى النهاية]
        A2[الاستجابة للأحداث تلقائياً]
        A3[تنفيذ مرن وقابل للتوسع]
        A4[رؤية وتدقيق مقاومان للتلاعب]
        A5[تغييرات آمنة على خطوط الإنتاج]
    end

    subgraph الركائز
        direction TB
        B1[محرك سير العمل: التعريف والتشغيل والتتبع]
        B2[طبقة التشغيل: يدوي ومجدول ومدفوع بالأحداث]
        B3[تنفيذ مرن: دائم وإعادة محاولة وتراجع على نطاق واسع]
        B4[التدقيق والرصد: كل خطوة مسجلة]
        B5[إدارة خطوط الأنابيب: الحفظ والإصدار والترقية بأمان]
    end

    subgraph الوظائف
        direction TB
        C1[محرك سير العمل]
        C2[التشغيل]
        C3[المرونة والتوسع]
        C4[الحالة وقابلية التتبع]
        C5[إدارة خطوط الأنابيب]
    end

    A1 --> B1 --> C1
    A2 --> B2 --> C2
    A3 --> B3 --> C3
    A4 --> B4 --> C4
    A5 --> B5 --> C5

    classDef row1 fill:#eef7ff,stroke:#4a90e2,stroke-width:1px;
    classDef row2 fill:#ddeeff,stroke:#4a90e2,stroke-width:1px;
    classDef row3 fill:#cce5ff,stroke:#4a90e2,stroke-width:1px;
    classDef row4 fill:#b3d8ff,stroke:#4a90e2,stroke-width:1px;
    classDef row5 fill:#99ccff,stroke:#4a90e2,stroke-width:1px;

    class A1,B1,C1 row1;
    class A2,B2,C2 row2;
    class A3,B3,C3 row3;
    class A4,B4,C4 row4;
    class A5,B5,C5 row5;

7.2.1. محرك سير العمل#

محرك سير العمل هو جوهر المنسِّق. يُعرِّف العمليات متعددة الخطوات، ويُنفِّذها، ويتتبع حالتها، ويتعامل مع العلاقات بين الخطوات.

قبل الخوض في الأنماط، يستحق تسمية الأساليب الأربعة الجوهرية للتنسيق، لأن هذا الاختيار يُشكِّل كل شيء آخر.

7.2.1.1. أساليب التنسيق#

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

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

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

• الوكيلي (حلقة الإدراك-المنطق-التصرف): Large Language Model (LLM) أو نظام ذكاء اصطناعي يعمل كطبقة المنطق. يرصد الوكيل الحالة الراهنة (من الرصد الشامل أو مصدر الحقيقة)، ويستنتج الإجراء المطلوب، ويستدعي المنفِّذ. بدلاً من اتباع رسم بياني محدد مسبقاً، يتخذ قرارات ديناميكياً وقت التشغيل. هذا النهج الذي يقايض الحتمية بالمرونة ويُشكِّل الأساس المعماري للشبكات المستقلة. يغطي القسم 7.2.7 هذا بعمق؛ الفصل 17 يوسعه للاستقلالية الكاملة.

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

7.2.1.2. أنماط سير العمل#

ضمن النهج القائم على DAG، أربعة أنماط تغطي معظم سير عمل أتمتة الشبكة الحقيقية:

• التسلسلي: الخطوات تعمل واحدة تلو الأخرى؛ كل منها يعتمد على اكتمال السابقة بنجاح. مناسب حين يُطلَب ترتيب صارم: التحقق من النوايا، ثم الفحص المسبق، ثم التنفيذ، ثم التحقق.

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

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

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

flowchart TD
    subgraph تسلسلي
        S1[الخطوة أ] --> S2[الخطوة ب] --> S3[الخطوة ج]
    end

    subgraph FanOut["التوسع والتجميع"]
        F0[البداية] --> F1[الجهاز 1]
        F0 --> F2[الجهاز 2]
        F0 --> F3[الجهاز N]
        F1 --> FJ[التجميع]
        F2 --> FJ
        F3 --> FJ
    end

    subgraph Saga["نمط Saga - التراجع عند الفشل"]
        P1[الخطوة 1] --> P2[الخطوة 2] --> P3[الخطوة 3]
        P3 -- فشل --> R3[تراجع 3]
        R3 --> R2[تراجع 2]
        R2 --> R1[تراجع 1]
    end

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

7.2.1.3. إدارة التبعيات#

نادراً ما تتواجد خطوات سير العمل في عزلة. يحتاج المحرك إلى التعبير عن ثلاثة أنواع من التبعيات وإنفاذها:

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

• تبعيات متعددة المدخلات (التجميع): خطوة تنتظر فروعاً متوازية متعددة قبل المتابعة. المحرك يحتفظ بالحالة لكل فرع ويُشغِّل خطوة الدمج فقط حين تتحقق سياسة الاكتمال المُهيَّأة: اكتمل الجميع، أو N من M، أو النجاح الأول.

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

7.2.2. التشغيل#

يجب أن يبدأ سير العمل بطريقة ما. يُجيب التشغيل عن سؤالين: ما الذي يُسبِّب بدء سير العمل، وما الذي يختبره المُستدعي بعد ذلك.

كيف يختلف التشغيل عن الفصل 5: في الفصل 5، التشغيل يشير إلى كيفية استدعاء المشغّل أو النظام لمحرك التنفيذ مباشرةً: استدعاء API لـAWX، وإطلاق قالب من Command Line Interface (CLI). هذا تشغيل على مستوى التنفيذ. هنا، يصف التشغيل ما يُسبِّب للمنسِّق بدء سير العمل، الذي قد يستدعي بدوره المنفِّذ كواحدة من خطوات عدة. المنسِّق يستقبل التشغيل ويقرر سير العمل الكامل المُشغَّل. المنفِّذ يُنفِّذ فقط ما يأمره به المنسِّق.

7.2.2.1. أوضاع التشغيل#

أربعة أوضاع تغطي الطيف الكامل من البشري إلى المؤتمت بالكامل:

• استدعاء API: يكشف المنسِّق نقطة نهاية HTTP. يستدعيها مشغّل يدوياً، أو زر واجهة مستخدم، أو نظام خارجي (ServiceNow، Nautobot، خط أنابيب CI/CD) حين يقع حدث. هذه آلية واحدة: ما يختلف هو من يبدأ الاستدعاء وهل يحمل بيانات حدث منظمة. مناسب لأي تغيير يحتاج البدء الآن، سواء كان المبادر إنساناً أو نظاماً.

• المجدول: جدول زمني شبيه بـcron يبدأ سير العمل في وقت مُهيَّأ. فحوصات الامتثال الليلية، تدقيقات البرامج الأسبوعية، تقارير الطاقة الشهرية. معظم المنسِّقات تدعم هذا أصلياً؛ بعض الفرق تستخدم مجدول خارجي وتستدعي API المنسِّق.

• قائمة الرسائل: يستهلك المنسِّق رسائل من قائمة (Kafka، NATS، RabbitMQ) ويبدأ سير عمل لكل رسالة. هذا يفصل منتج الحدث عن المنسِّق: المنتج ينشر ويتحرك؛ المنسِّق يعالج بوتيرته الخاصة. مناسب لتدفقات أحداث عالية الحجم حيث ضمانات التسليم-مرة-واحدة-كحد-أقصى من استدعاءات API المباشرة غير كافية.

الاختيار بين الدفع (استدعاء API) والسحب (قائمة رسائل، مجدول) يعتمد على الحجم وتحمل الاقتران. استدعاءات API أبسط لكن تتطلب من المُرسِل معرفة نقطة نهاية المنسِّق. قوائم الرسائل تتوسع بشكل أفضل للتدفقات عالية الحجم لكنها تُضيف بنية تحتية للتشغيل.

7.2.2.2. عقد الاستجابة#

حالما يبدأ سير العمل، يحتاج المُستدعي معرفة ما يتوقعه:

• متزامن: ينتظر المُستدعي حتى يكتمل سير العمل ويستقبل النتيجة مباشرةً. مناسب للعمليات القصيرة (أقل من 30 ثانية) حيث يحتاج المُستدعي النتيجة للمتابعة. معظم حالات الاستخدام التفاعلية تبدأ هنا وتكتشف أنها تجاوزتها حين تحاول تشغيل نشر يستغرق 10 دقائق ويُهلت عميل الـAPI.

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

• هجين: يبدأ سير العمل بشكل غير متزامن، لكن يمكن للمُستدعي اختيارياً الحجب على نقطة نهاية انتظار متزامنة إن احتاج. نمط مريح يتجنب إجبار المُستدعين على الاختيار مسبقاً.

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

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

7.2.3. المرونة والتوسع#

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

المرونة على مستوى طبقة التنفيذ، المُغطاة في الفصل 5، تُعالج ثبات النتيجة وإعادة المحاولة على مستوى الجهاز الفردي. ما لا يُعالجه الفصل 5 هو متانة مستوى سير العمل: ما الذي يحدث حين يُعاد تشغيل المنسِّق نفسه في منتصف التشغيل، حين يفشل 40 من 800 جهاز في الفحوصات المسبقة، أو حين لا تُحلَّ تبعية وسير العمل يتعلق. توسيع المنسِّق نفسه، بما يشمل التوافر العالي والعمال الأفقيين وحمل قاعدة البيانات تحت التشغيلات المتزامنة، هو اهتمام بنية تحتية يُعالَج في الفصل 11.

7.2.3.1. الحالة الدائمة#

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

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

7.2.3.2. استراتيجيات إعادة المحاولة#

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

يجب أن يُميِّز تهيئة إعادة المحاولة بين:

• الأعطال العابرة: انقطاعات شبكة، مهلات API، تنازع موارد مؤقت. إعادة المحاولة مع تراجع أسّي.
• الأعطال الدائمة: بيانات اعتماد سيئة، جهاز في وضع الصيانة، تهيئة لا تنطبق على نوع هذا الجهاز. إيقاف وتصعيد.

يجب أن تُحدِّد تعريف سير العمل سياسة إعادة المحاولة لكل خطوة. خطوة الفحص المسبق وخطوة دفع التهيئة لهما دلالات فشل مختلفة ولا ينبغي مشاركة نفس إعدادات إعادة المحاولة.

7.2.3.3. التراجع والتعويض#

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

يُعالج نمط Saga هذا بتعريف معاملة تعويضية لكل خطوة. إن نجح سير العمل حتى الخطوة N ثم فشل، يشغّل إجراءات تعويضية للخطوات N-1 حتى 1 بالترتيب العكسي. في نشر VLAN: إن نجح دفع التهيئة على 30 جهازاً وفشل على الجهاز الـ31، يتراجع نمط Saga من 30 عملية دفع ناجحة قبل الإفادة بالفشل.

يتطلب نمط Saga أن تُعرَّف المعاملات التعويضية مسبقاً، وقت تصميم سير العمل. هذا عمل إضافي مسبق. البديل هو اكتشاف الساعة 2 صباحاً أن شبكتك في حالة لا يصفها أي دليل إجراءات.

7.2.3.4. التحكم في التزامن#

التوسع عبر 800 جهاز في آنٍ واحد سيُرهق معظم طبقات التنفيذ. التحكم في التزامن على مستوى التنسيق يعني:

• التجميع: تشغيل N جهازاً بالتوازي، انتظر اكتمال المجموعة، ثم شغّل المجموعة التالية. يتحكم هذا في نطاق الانتشار: إن كشفت تهيئة سيئة عن مشكلة، لم تُلامس بعد جميع الـ800 جهاز.
• تحديد المعدل: طبقة التنفيذ لها حدود؛ المنسِّق يجب أن يحترمها. لا تدع قائمة AWX تمتلئ بـ800 وظيفة متزامنة.
• حدود النجاح الجزئي: عرِّف ما يعنيه النجاح على نطاق واسع. قد يكون تهيئة 798 من 800 جهاز بشكل صحيح كافياً للمتابعة؛ 600 من 800 يجب أن يوقف سير العمل ويُصعِّد.

7.2.3.5. المهلة وقاطع الدائرة#

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

يوسِّع نمط Circuit Breaker هذا للأعطال المتكررة: إن فشلت خطوة أكثر من N مرة في نافذة زمنية، توقف عن المحاولة وأطلق تنبيهاً. يمنع هذا من إبقاء جهاز واحد غير قابل للوصول سير العمل مفتوحاً لساعات.

7.2.3.6. المرونة عبر حدود الكتل#

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

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

يجب تصنيف أعطال الحدود بين الكتل صراحةً في تعريف سير العمل:

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

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

7.2.4. الحالة وقابلية التتبع#

حين يسوء الأمر الساعة 3 صباحاً، يحتاج سؤالان إجابة فورية: ما الحالة الراهنة لسير العمل، ومن شغّله؟

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

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

قابلية التتبع هي اهتمام مشترك عبر منصة الأتمتة: مصدر الحقيقة يسجل كل تغيير في النوايا؛ الرصد الشامل يسجل كل تغيير في حالة الشبكة. لكن لا أي من هذين السجلين يخبرك من بدأ سير العمل، وأي خطوات عملت بالتسلسل، وما سبّب النتيجة. فقط سجل تدقيق المنسِّق يسدّ تلك الثغرة. لأن المنسِّق ينسِّق جميع الكتل الأخرى، أثره هو الرؤية المرجعية لكل ما حدث عبر نظام الأتمتة الكامل لحدث معين.

7.2.4.1. الحالة ليست حالة الشبكة#

هذا التمييز سهل الفوت. في الفصل 6، “الحالة” تعني الحالة التشغيلية للشبكة: عدادات الواجهة، جلسات BGP، CPU الجهاز. في الفصل 5، “الحالة” تعني نوايا التهيئة المطلوبة المحمولة في مصدر الحقيقة. هنا، الحالة تعني حالة تنفيذ سير العمل ذاته: أي خطوات عملت، أيها يعمل، أيها فشل، وما أنتجته.

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

7.2.4.2. آلة الحالة لسير العمل#

كل تشغيل لسير العمل يتحرك عبر آلة حالة مُعرَّفة:

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

كل خطوة ضمن سير العمل تحمل حالتها الخاصة. تشغيل توسع ناجح جزئياً يجب أن يُظهر بالضبط أي أجهزة نجحت، وأيها فشل، وأيها تخطّى. “سير العمل فشل” غير مفيد بدون التفصيل لكل جهاز.

7.2.4.3. متطلبات سجل التدقيق#

يجب أن يحتوي كل سجل تشغيل لسير العمل، كحد أدنى:

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

يجب أن يكون هذا السجل مقاوماً للتلاعب: لا يمكن تعديله بعد الحقيقة. في البيئات المنظَّمة، سجل تدقيق المنسِّق هو سجل إدارة التغيير. إن كان هذا السجل قابلاً للتغيير، نظام إدارة التغيير غير جدير بالثقة.

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

7.2.5. إدارة خطوط الأنابيب#

سير عمل يُهيِّئ 800 مفتاح إنتاجي هو، من الناحية المعمارية، برمجيات إنتاج. التحدي الرئيسي ليس فقط الإصدار: بل كيف تحفظ وتتحقق وتُرقِّي تعريفات سير العمل حتى يكون المنطق ذاته موثوقاً مثل البنية التحتية التي يديرها.

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

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

7.2.5.1. الاستراتيجيات#

• تعريفات مدعومة بـGit: خزِّن تعريفات سير العمل في نظام تحكم الإصدار. تسحب أداة التنسيق من Git عند النشر، لا من تحريرات واجهة المستخدم المحلية. هذا يمنحك تاريخاً وعملية مراجعة والقدرة على التراجع إلى أي إصدار سابق.

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

• الطرح التدريجي كناري: نسخة سير عمل جديدة تتعامل مع عدد صغير من التشغيلات أولاً. سير عمل ترقية البرامج الثابتة قد يطبّق النسخة الجديدة على 10 أجهزة قبل ترقيتها للأسطول الكامل. المشكلات تظهر على 10 أجهزة، لا 800.

7.2.5.2. اختبار تغييرات التنسيق#

يمكن اختبار تعريفات سير العمل قبل الإنتاج:

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

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

7.2.6. مشهد الحلول#

تنويه: الأدوات المُدرجة هنا أمثلة لأغراض توضيحية، لا توصيات. لكل منها بنية معمارية مختلفة وملف مقايضات. قيِّمها وفق قدرات فريقك والأدوات الموجودة والقيود التشغيلية.

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

سؤال معماري واحد يتقاطع مع جميع هذه: هل تُخدِّم أداة تنسيقك أيضاً كمحرك تنفيذ، أم هما منفصلان؟ AWX/AAP يدمج كليهما في واحد. Prefect وTemporal وWindmill منسِّقات تستدعي أدوات تنفيذ منفصلة (Ansible، سكريبتات مخصصة، APIs). النموذج المدمج أبسط في التشغيل؛ النموذج المنفصل يمنحك مرونة أكبر لتبديل محركات التنفيذ بشكل مستقل. الفصل 3 قدَّم هذه المقايضة تحت الاقتران الأدنى.

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

هذه الأدوات تتداخل بشكل كبير: Python تعمل في كلٍّ من Prefect وWindmill؛ كلٌّ من Prefect وTemporal يمكنهما استدعاء Ansible. نقطة انطلاق تقريبية: إن كان فريقك Ansible أولاً ويريد مكونات جديدة أدنى حداً، قوالب سير عمل AWX هي الملاءمة الطبيعية؛ إن أردت خطوط أنابيب أولاً بالكود وقابلة للاختبار بانضباط هندسة البرمجيات، كلٌّ من Prefect وWindmill يعملان بنماذج تشغيلية مختلفة؛ إن كانت المتانة تحت الفشل الجزئي هي القيد الرئيسي، نموذج إعادة التشغيل في Temporal مبني لهذا الغرض. عامل هذا كنقطة انطلاق للتقييم، لا إجابة نهائية.

7.2.7. المنسِّق الوكيلي#

أسلوب التنسيق الوكيلي المُدرَج في 7.2.1 يُقدِّم نموذج تنفيذ مختلف: بدلاً من اتباع DAG مُعرَّف مسبقاً، يستقبل Large Language Model (LLM) هدفاً ويُحدِّد تسلسل الإجراءات وقت التشغيل. يرصد الوكيل الحالة الراهنة من كتلتَي الرصد الشامل ومصدر الحقيقة، ويستنتج الإجراء الذي يُغلق الفجوة، ويستدعي المنفِّذ، ويُعيد الرصد للتحقق من النتيجة. إن لم تكن النتيجة ما توقَّع، يستنتج من جديد. منطق القرار غير مُرمَّز في تعريف سير العمل؛ يعيش في تفكير النموذج.

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

التداعية المعمارية هي أن الكتل لا تحتاج معرفة بعضها أو معرفة الوكيل. واجهة MCP هي العقد. مصدر الحقيقة الذي يُجيب على استدعاءات REST من سير عمل قائم على DAG اليوم سيُجيب على استدعاءات أدوات MCP من وكيل ذكاء اصطناعي بدون تعديل. الحدود النظيفة بين الكتل تُؤتي ثمارها هنا بطريقة لا يفعلها الاقتران الشديد أبداً.

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

يُقدِّم هذا القسم النمط. المعالجة المعمارية الكاملة، بما يشمل كيفية توسع التنسيق الوكيلي إلى عملية مستقلة مستمرة عبر الشبكة الكاملة، في الفصل 17.

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

7.3.1. تنسيق دورة حياة خدمة VLAN للحرم الجامعي#

تابعنا نفس الشبكة الجامعية عبر الجزء الثاني. في الفصل 4، خزّنا طلب خدمة VLAN في Nautobot: معرّف VLAN والشبكة الفرعية والمفاتيح المستهدفة وقوالب التهيئة لكل مورد. في الفصل 5، استخدمنا Ansible عبر AWX لدفع تلك التهيئة إلى مفاتيح الحرم. في الفصل 6، تحققنا من النشر وبدأنا مراقبة الخدمة.

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

السيناريو

فريق التطبيقات قدّم طلباً لقطاع تطبيق جديد: VLAN app-payments، الشبكة الفرعية 10.22.14.0/24، مُنشَرة على جميع مفاتيح الوصول في building-b عبر أكوام Cisco وArista. قُدِّم الطلب عبر ServiceNow وتلقّى للتو الموافقة النهائية.

تلك الموافقة تُطلق webhook. يستقبله المنسِّق ويبدأ سير عمل نشر خدمة VLAN.

سير العمل

ننفِّذ هذا كقالب سير عمل AWX، متسقاً مع طبقة التنفيذ الموجودة. تدعم AWX قوالب سير العمل التي تُسلسِل قوالب الوظائف مع التفريع الشرطي وبوابات الموافقة، وهو ما يكفي لهذا السيناريو.

flowchart TD
    A[webhook ServiceNow\nطلب VLAN معتمد] --> B[الخطوة 1: التحقق من مصدر الحقيقة\nاستعلام Nautobot لسجلات الأجهزة\nواكتمال تعريف VLAN]
    B --> C{بيانات مصدر الحقيقة مكتملة؟}
    C -- لا --> Z1[إيقاف: إشعار المهندس\nوتحديث تذكرة ServiceNow]
    C -- نعم --> D[الخطوة 2: فحوصات مسبقة موسعة\nإمكانية الوصول وحالة VLAN\nعبر جميع المفاتيح المستهدفة]
    D --> E{الفحوصات المسبقة اجتازت؟}
    E -- فشل --> Z2[إيقاف: تقرير بفشل\nكل جهاز إلى ServiceNow]
    E -- اجتازت --> F[الخطوة 3: بوابة الموافقة\nتوقيع بشري اختياري\nقبل التنفيذ في الإنتاج]
    F --> G[الخطوة 4: تنفيذ النشر\nplaybook Ansible عبر AWX]
    G --> H[الخطوة 5: تحقق موسع\nفحص الرصد لكل مفتاح]
    H --> I{جميع الأجهزة تم التحقق منها؟}
    I -- نجاح كامل --> J[الخطوة 6: إشعار\nتحديث تذكرة ServiceNow\nنشر على Slack]
    I -- فشل جزئي --> K[الخطوة 6أ: تعويض Saga\nتراجع النطاق الفاشل فقط]
    K --> J

الخطوة 1: التحقق من مصدر الحقيقة

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

الخطوة 2: فحوصات مسبقة عبر المفاتيح المستهدفة (توسع)

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

الخطوة 3: بوابة الموافقة

توقيع بشري اختياري قبل الدفع الإنتاجي. لدى المهندس 30 دقيقة للموافقة أو الرفض؛ مهلة تتقدم تلقائياً وتُسجَّل. يحمل المنسِّق سير العمل في حالة انتظار مع تبعية خارجية حتى تصل الموافقة أو تنتهي النافذة.

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

الخطوة 4: تنفيذ النشر

يُشغِّل المنسِّع قالب وظيفة AWX من الفصل 5، يمرّر المعاملات من خطوة التحقق من مصدر الحقيقة، وينتظر النتيجة. المنفِّذ يتعامل مع البقية. هذا هو فصل الاهتمامات في الواقع العملي: المنسِّق يقرر التصرف، المنفِّذ يتصرف.

الخطوة 5: تحقق الرصد الشامل (توسع)

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

الخطوة 6: توجيه النتيجة

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

العودة إلى المهندسة من المقدمة

يُظهر سير العمل هذا جميع الكتل السبع من إطار NAF في الفصل 3 تعمل معاً: Nautobot (مصدر الحقيقة) وفّر النوايا، AWX (المنفِّذ) طبّقها، Prometheus (الرصد الشامل) تحقق من النتيجة، قالب سير عمل AWX (المنسِّق) نسّق التسلسل الكامل، وwebhook ServiceNow (العرض، مُغطى في الفصل 8) شغّل التدفق بأكمله من طلب فريق التطبيقات.

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

7.4. الملخص#

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

في جوهره، يرتكز التنسيق على محرك سير عمل يُعرِّف كيفية هيكلة العمليات متعددة الخطوات وتنفيذها. الاختيار بين المتكامل وDAG والكوريوغرافي والوكيلي قرار معماري، لا تفضيل أدوات. نموذج DAG مع أنماطه المسماة (التسلسلي والتوسع والشرطي وSaga) هو المعيار الإنتاجي لأتمتة الشبكة. نمط الوكيلي، المُقدَّم في القسم 7.2.7 مع Model Context Protocol (MCP) كطبقة واجهة، يمثّل مقايضة مختلفة ويتلقى معالجته الكاملة في الفصل 17.

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

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

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

جمع سيناريو خدمة VLAN الجامعية هذه الوظائف الخمس معاً: سير عمل من عشر خطوات مُشغَّل بـwebhook من ServiceNow، ينسِّق التحقق من مصدر الحقيقة والفحوصات المسبقة والتنفيذ وتحقق الرصد الشامل وتعويض Saga، بلا مهندس في حلقة التنسيق. السؤال الطبيعي التالي هو من يرى سير العمل هذا يعمل وكيف يتتبع فريق التطبيقات الذي شغّله تقدمه. هذه طبقة العرض، المُغطاة في الفصل 8.

💬 Found something to improve? Send feedback for this chapter