3. التفكير المعماري#

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

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

لكنني مؤمن بضرورة فهم السبب قبل الماهية، فلنفهم أولاً دواعي الاستعانة بمعمارية.

3.1. لماذا تهم المعمارية المرجعية#

“الأحرار وحدهم من نالوا التعليم.” إبكتيتوس

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

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

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

تحل المعمارية المرجعية هذه المشكلات بتوفير نموذج ذهني واحد وواضح لكيفية تنظيم أنظمة الأتمتة. تُحدد:

• ما الذي يجب أن يفعله كل مكون ← مسؤولياته
• كيف تتفاعل المكونات ← واجهاتها وتدفقات البيانات
• أين يمكنك الاختيار ← أي الأدوات تستخدم
• أين تحتاج إلى اتساق ← كيف تتحدث المكونات مع بعضها

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

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

3.2. معمارية أتمتة الشبكات#

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

• المعمارية المرجعية لـNetwork to Code، جهد جماعي بقيادة فريق معمارية NTC (كنت جزءاً منه لأربع سنوات)، مُصمَّم لدعم أتمتة الشبكات الفعّالة والمفهومة عبر مجموعة واسعة من حالات الاستخدام.
• Network Automation and Programmability 2nd Edition by O’Reilly، جهد لربط أجزاء محتوى الكتاب مع مُؤلفَيّ: Matt Oswalt وScott S. Lowe وJason Edelman.
• إطار NAF كان مشروعاً مجتمعياً تحت مظلة NAF بقيادة مشتركة مع Wim Henderickx وDinesh Dutt وClaudia de Luna وRyan Shaw وDamien Garros، بهدف مساعدة المبتدئين والممارسين ذوي الخبرة على بناء حلول أتمتة بطريقة منظمة وقابلة للتكرار.

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

الثلاثة تكاملية لا متنافسة. مقارنة موجزة تُوضّح متى يكون كل منها أكثر فائدة:

يُحدد إطار NAF العقود بين الكتل ويترك خيارات التطبيق مفتوحة. تُكمّل معمارية NTC تلك الخيارات بتوصيات أدوات محددة. إن كان فريقك يستخدم أدوات NTC، ينطبق كلاهما في آن واحد دون تعارض.

يقترح NAF Framework المعمارية التالية:

block-beta
    columns 7
    
	space:1	
    block:layer1:5
        Presentation["العرض"]
    end
	space:1

    space:7

    
    block:Observability:2
        columns 2
        %% ObsLabel["Observabilit"]:2
        ObservedState[("الحالة المرصودة")]:1
        ObservedLogic["المنطق المرصود"]:1
    end

	space
    
	block:Orchestration:1
		columns 1
		OrchLabel["التنسيق"]:1
	end

	space
    
    block:Intent:2
        columns 2
        %% IntLabel["Intent"]:2
        IntendedState[("الحالة المقصودة")]:1
        IntendedLogic["المنطق المقصود"]:1
    end
    
    space:7

	space

    
    Collector["المُجمِّع"]:2
	space
    Executor["المُنفِّذ"]:2
	space
    
	space:7
	space:1
    
    block:layer4:5
        NetworkInfra["البنية التحتية للشبكة"]
    end
    
    Presentation <--> Observability
    Presentation <--> Orchestration
    Presentation <--> Intent
    
    Observability <--> Orchestration
    Orchestration <--> Intent
    
    Collector --> Observability
    Collector <--> Orchestration
	NetworkInfra --> Collector
    
    Orchestration --> Executor
    Intent --> Executor
    Executor --> NetworkInfra
    
    classDef darkStyle fill:#5a4149,stroke:#4a9eff,stroke-width:2px,color:#e8e8e8,font-size:20px,font-weight:bold
    
    class Presentation,NetworkInfra,ObsLabel,IntLabel,Collector,Executor,ObservedState,ObservedLogic,IntendedState,IntendedLogic,OrchLabel darkStyle

تحتوي هذه المعمارية على الكتل التالية، وفق التعريفات الواردة في الوثيقة:

• Intent (Architectural Block): يُحدد المنطق اللازم للتعامل مع Desired State للشبكة وتخزينه، بما يشمل توقعات الإعداد والتشغيل.
• Executor: يشمل المهام الفعلية المُطبَّقة على الشبكة لدفع التغييرات (تحديث الإعداد) وفق الحالة المقصودة.
• Collector: في المقابل، يركز هذا المكون على استرداد (قراءة) Actual State للشبكة.
• Observability: يُخزّن Actual State للشبكة ويُحدد منطق معالجتها.
• Orchestrator: يُحدد كيفية تنسيق مهام الأتمتة وتنفيذها استجابةً للأحداث.
• Presentation (Layer): يوفر الواجهات التي يتفاعل من خلالها المستخدمون مع النظام، بما فيها لوحات التحكم وواجهات المستخدم الرسومية (ITSM) وأدوات Command Line Interface (CLI).

هذه المعمارية ليست اعتباطية؛ إنها النتيجة الطبيعية لتطبيق مبادئ هندسة البرمجيات على عمليات الشبكات.

يهدف إطار NAF إلى مساعدة معماريي أتمتة الشبكات على تنظيم حلولهم بالإشارة إلى وظائف كل وحدة وتحديد MUST وSHOULD وMAY (بأسلوب RFC). ثم يمكنك تقرير كيفية تطبيقها لحل حالات استخدامك الخاصة.

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

الآن، سنستعرض الكتل المختلفة لتقديمها.

3.2.1. النوايا أو مصدر الحقيقة#

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

تُسمّيها المعمارية “النوايا”، لكنني أُطابقها مع مصطلح شائع آخر: مصدر الحقيقة (SoT). يُساء فهم مصطلح SoT أحياناً، وأريد البدء بتوضيح ما يعنيه SoT أو النوايا (سأستخدمهما بالتبادل طوال الكتاب).

كما تتخيل، يمكن أن يمثل هذا بيانات متنوعة للغاية تشمل الأجهزة وعناوين IP وبنية تحتية لمركز البيانات (رفوف وكابلات) وبروتوكولات التوجيه والخدمات الافتراضية والأسرار والحدود التشغيلية وقوالب الإعداد وتجريدات الخدمة أو السياسة. جانب رئيسي هو أن هذه البيانات يجب أن تكون منظمة لتكون مفهومة من قِبل الآلات. ثم يجب أن تدعم عمليات الإنشاء والقراءة والتحديث والحذف وأن تكون متاحة عبر Application Programming Interface (API) موحدة وموثقة جيداً كـRepresentational State Transfer (REST) أو GraphQL.

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

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

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

إن كنت تحاول فهم أي الأدوات الفعلية يمكن أن تندرج ضمن هذه الفئة، إليك بعض الأمثلة: ملفات CSV/YAML/JavaScript Object Notation (JSON)، وGit، وNetBox، وNautobot، وInfrahub، وInfoblox، أو أي قواعد بيانات عامة الغرض.

راجع الفصل الرابع للتعمق في بناء مصدر الحقيقة وإدارته.

3.2.2. المُنفِّذ#

المُنفِّذ مسؤول عن تطبيق (كتابة) الحالة المطلوبة القادمة من النوايا في حالة الشبكة الفعلية، بالتفاعل مع الشبكة عبر واجهات مختلفة كـSSH وNETCONF وgNMI/gNOI وREST APIs.

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

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

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

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

الأدوات التي تندرج في معظمها ضمن هذه الفئة هي Ansible، وTerraform/OpenTofu، أو أي نوع من السكريبتات التي تستفيد من مكتبات كـNetmiko، وScrapli، أو Napalm، أو حتى Kubernetes CRD (مورد مخصص).

توجّه إلى الفصل الخامس لاستكشاف أطر التنفيذ وأنماط ثبات النتيجة واستراتيجيات التطبيق.

3.2.3. المُجمِّع#

بالقياس على المُنفِّذ، المُجمِّع مسؤول عن استرداد البيانات التشغيلية الفعلية من الشبكة عبر واجهات وبروتوكولات مختلفة (نفس واجهات المُنفِّذ، إضافةً إلى أخرى كـSNMP والسجلات أو تلمتريا قائمة على التدفق).

وجهة كل هذه البيانات هي كتلة الرصد، حيث تُستخدَم البيانات لتشغيل قرارات الأتمتة.

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

أمثلة على الأدوات التي تندرج ضمن هذه الفئة: Telegraf، وVector، وgNMIc، وPMACCT، وgoFlow، وAkvorado، أو أي نوع من السكريبتات التي تستفيد من مكتبات لجلب البيانات من الشبكة.

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

3.2.4. الرصد#

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

يجب أن تكشف بيانات هذه الكتلة التباينات ذات الصلة بين Desired State وActual State للشبكة، مُولِّدةً أحداثاً (أو تنبيهات) يمكن أن تُشغّل أنظمة التخفيف.

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

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

في مراقبة الشبكة التقليدية، كانت جميع وظائف الرصد (والجمع) مُدمجة في صندوق واحد كبير (أدوات كـNagios، وLibreNMS، وSpectrum، وما إلى ذلك).

حالياً، تكتسب أنظمة أكثر تنوعاً تتكامل شعبيةً، إذ يحظى Prometheus وInfluxDB بشعبية كـTime Series Database (TSDB) أو Elasticsearch، وأنظمة مرتبطة أخرى تُدير التنبيهات (Alertmanager) والتصور (Grafana، Kibana). أفرز هذا بعض المكدسات الشائعة: ELK، وTIG، وTPG.

تعرّف على معمارية المراقبة واستراتيجيات التنبيه وأفضل ممارسات الرصد في الفصل السادس.

3.2.5. المُنسِّق#

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

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

في العمليات اليدوية، يكون هذا عادةً مُعرَّفاً بشكل فضفاض في قائمة مراجعة للعملية الواجب اتباعها.

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

أمثلة هنا: AAP أو AWX (Ansible Automation Platform)، وWindmill، أو Prefect.

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

تعمّق في الفصل السابع للتعرف على تصميم سير العمل والأتمتة المدفوعة بالأحداث ومنصات التنسيق.

3.2.6. العرض#

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

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

بطريقة أو بأخرى، يجب أن تتيح هذه الطبقة مصادقة وتفويضاً مرنين (إنها نقطة الدخول لنظامك)، ثم تتكيف مع الاحتياجات الفعلية. أحياناً يمكن أن تكون منصة خاصة بالشبكات، أو أحياناً يمكن أن تتكامل مع أنظمة الشركة (ServiceNow، وSlack، وما إلى ذلك).

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

استكشف تجربة المستخدم وتصميم الواجهة وأنماط التكامل في الفصل الثامن.

3.2.7. الشبكة#

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

الشبكة نفسها قيد وعامل تمكين لمعمارية أتمتتك بأكملها. على خلاف الكتل الست السابقة التي تتحكم فيها، قد تكون البنية التحتية للشبكة (أجهزتك ومنصاتك وخدماتك واتصالاتها) محدودة القدرات مما يؤثر على الممكن.

تندرج قدرات الشبكة ضمن عدة فئات:

• الواجهات والبروتوكولات: ما الواجهات الإدارية التي تدعمها شبكتك؟ SSH CLI؟ NETCONF؟ gNMI؟ REST APIs؟ SNMP؟ بعض المنصات تدعم كثيراً، وبعضها يدعم القليل. هذه الخيارات تُقيّد مباشرة ما يمكن للمُجمِّع والمُنفِّذ فعله.
• نماذج البيانات: حتى لو كان الجهاز يدعم gNMI، فإن نماذج YANG التي يكشفها قد تكون غير مكتملة. على سبيل المثال، قد يدّعي جهازك دعم gNMI لكنه لا يكشف الإعداد المحدد الذي تحتاج إلى إدارته. فهم هذه الفجوات أمر بالغ الأهمية أثناء التخطيط.
• نضج التشغيل: المنصات الأحدث قد تمتلك واجهات API حديثة لكن سلوكيات غير موثقة. المنصات الأقدم قد تكون مستقرة لكنها تفتقر كلياً إلى واجهات API. تحتاج إلى تقييم النضج الفعلي، لا الميزات المُروَّج لها.

لدعم الأتمتة بشكل فعّال، يجب أن توفر بنيتك التحتية للشبكة في المثالية:

• بيئات التطوير والاختبار: مثل تطوير البرمجيات، تحتاج الأتمتة إلى أماكن آمنة للاختبار. قد يعني هذا: شبكات مختبر (غالباً مكلفة ومحدودة)، أو بيئات شبكية افتراضية (Containerlab، GNS3)، أو محاكيات يوفرها الموردون (Cisco DevNet، Arista EOS-lite).
• واجهات متسقة: إن كان 90% من أجهزتك تدعم NETCONF لكن 10% تدعم SSH فحسب، ستحتاج إما إلى التوحيد أو بناء منفّذات متعددة. كل تناقض يزيد التعقيد.
• تلمتريا كافية: إن كنت لا تستطيع الحصول على البيانات التي تحتاجها من أجهزتك، يصبح الرصد عديم المعنى. تأكد من أن أجهزتك تستطيع بث التلمتريا (تلمتريا تدفقية، وSNMP، وسجلات نظام) بالدقة والمعلومات التي تحتاجها.

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

افهم قدرات الشبكة وواجهات API الأجهزة وبيئات الاختبار في الفصل التاسع.

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

3.2.8. مثال عملي#

قبل التعمق في كل كتلة، دعونا نستعرض سيناريو ملموساً يُظهر كيف تعمل المعمارية معاً.

المشكلة: قدّم فريق تطبيقات طلباً لقطاع تطبيق جديد: VLAN جديد وشبكة فرعية IP وسياسة توجيه ومنطقة تحكم في الوصول عبر شبكة campus غير متجانسة تضم نحو 800 مفتاح وصول وتوزيع من Cisco وArista وHPE. يحتاج فريق العمليات إلى تنفيذه شاملاً دون عمل CLI يدوي على مئات الأجهزة.

كيف يمكن للمعمارية حله:

1. النوايا (مصدر الحقيقة): يُدخل مهندس شبكة تعريف الخدمة الجديدة في Nautobot: معرف VLAN والشبكة الفرعية وسياسة التوجيه وقوالب الإعداد لكل مورد ومجموعات المفاتيح التي تنطبق عليها. يُخزَّن هذا كـDesired State، المرجع الوحيد للحقيقة لـ800 جهاز.
2. Orchestrator: يستقبل AWX webhook من Nautobot حول التغيير ويُشغّل سير عمل التنفيذ، منسّقاً الخطوات بالترتيب الصحيح ومُعالجاً الإخفاقات لكل جهاز.
3. Executor: يقرأ كتيب تشغيل Ansible من Nautobot Application Programming Interface (API)، ويُصيّر إعداداً خاصاً لكل مورد (Cisco وArista وHPE تتطلب صياغات مختلفة)، ويدفع التغييرات عبر NETCONF. كل تشغيل ثابت النتيجة: تشغيله مرة أخرى على مفاتيح مُعدَّة بالفعل لا يُحدث أي تغيير.
4. Collector: بعد النشر، يتصل مُجمِّع gNMIc بكل مفتاح ويسترد عضوية VLAN الفعلية وحالة الواجهة وإدخالات التوجيه.
5. Observability: تتدفق البيانات المجموعة إلى Time Series Database (TSDB) في Prometheus. يُقارن استعلام Desired State (من النوايا) بـActual State (من Collector). تُكشَف المفاتيح التي يغيب عنها VLAN كمقاييس وتُشغّل تنبيهات.
6. Orchestrator: حين يُطلَق تنبيه (“VLAN 210 غائب عن access-switch-b3-07”)، يُعيد سير عمل AWX تشغيل Executor تلقائياً على ذلك المفتاح ويُعيد جمع البيانات ويتحقق من الإصلاح.
7. Presentation (Layer): تُظهر لوحة تحكم جميع المفاتيح الـ800 مُجمَّعةً حسب المبنى والمورد، مُسلّطةً الضوء على الملتزم منها (✅) والمنحرف (❌). يستطيع فريق التطبيقات تتبع النشر دون صلاحية الوصول إلى CLI. يمكن لعمليات تقنية المعلومات تشغيل معالجات يدوية دون كتابة كود.
8. الشبكة: نجاح هذا التدفق يعتمد على ما تدعمه الأجهزة فعلياً. على Cisco وArista، NETCONF يعمل بسلاسة. بعض مفاتيح HPE تدعم SSH CLI فقط، لذا يتولى مسار منفّذ منفصل التعامل معها، أقل أناقةً لكنه ضروري. لا معمارية تُزيل قيود الموردين؛ إنها فحسب تجعلها صريحة.

الفهم الجوهري: لم تقم أداة واحدة بهذا. عملت Nautobot (النوايا) وAnsible (المُنفِّذ) وgNMIc (المُجمِّع) وPrometheus (الرصد) وAWX (المُنسِّق) ولوحة Grafana (العرض) معاً. قدّمت المعمارية النموذج الذهني لكيفية تكاملها.

هذا ما يُتيحه التفكير المعماري: أتمتة منهجية قابلة للتركيب.

طوال الجزء الثاني (الفصول 4-9) سنعود إلى نفس شبكة campus هذه لاستكشاف كل كتلة بنائية بعمق: يُخزّن SoT تعريف خدمة VLAN (الفصل الرابع)، وينشره المُنفِّذ (الفصل الخامس)، ويراقبه الرصد (الفصل السادس)، ويُنسّق المُنسِّق دورة الحياة الكاملة (الفصل السابع)، وتكشف طبقة العرض عنه لجماهير مختلفة (الفصل الثامن)، ويختتم فصل الشبكة بوابة ما قبل الإنتاج القائمة على المحاكاة (الفصل التاسع). حيثما تشير الأمثلة إلى أداة مصدر حقيقة، تُستخدَم Nautobot وNetBox بالتبادل؛ الأنماط المعمارية هي نفسها بصرف النظر عما تختار.

3.3. كيفية استخدام المعمارية#

الآن بعد أن فهمت الكتل البنائية المختلفة لمعمارية أتمتة شبكات NAF، قد تتساءل: “كيف أبدأ فعلياً بهذا في مشاريعي؟”

3.3.1. نهج تبني تدريجي#

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

flowchart LR
    A[فهم الوضع الراهن]:::phase1 --> B[التخطيط لمسيرة الأتمتة]:::phase2
    B --> C[اتخاذ قرارات أفضل للأدوات والتصميم]:::phase3
    C --> D[التصميم للتكامل]:::phase4
    D --> E[التواصل مع أصحاب المصلحة]:::phase5
    E --> F[التطور التدريجي]:::phase6

    classDef phase1 fill:#e0f7fa,stroke:#333,stroke-width:2px;
    classDef phase2 fill:#b2ebf2,stroke:#333,stroke-width:2px;
    classDef phase3 fill:#80deea,stroke:#333,stroke-width:2px;
    classDef phase4 fill:#4dd0e1,stroke:#333,stroke-width:2px;
    classDef phase5 fill:#26c6da,stroke:#333,stroke-width:2px;
    classDef phase6 fill:#00bcd4,stroke:#333,stroke-width:2px;

المرحلة الأولى: فهم الوضع الراهن

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

• هل بياناتك مُبعثرة عبر أنظمة متعددة؟
• هل تجمع حالة الشبكة بشكل فعّال، أم أنك تعمل في العمى؟
• كيف تُنفّذ التغييرات حالياً؟ يدوياً؟ بسكريبتات عشوائية؟ أطر منظمة؟

إن اكتشفت قدرات تنفيذ ممتازة لكن رصداً ضعيفاً، فقد حددت مشكلة ذات أثر كبير لحلها التالي.

المرحلة الثانية: التخطيط لمسيرة الأتمتة

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

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

أولوِ الأولوية بحسب الأثر على الأعمال، لا بحسب اكتمال المعمارية.

المرحلة الثالثة: اتخاذ قرارات أفضل للأدوات والتصميم

عند تقييم أدوات جديدة أو بناء حلول مخصصة، اسأل نفسك:

• أي كتلة معمارية تخدمها هذه الأداة؟
• هل تتكامل جيداً مع مكوناتي الأخرى؟
• ما تدفقات البيانات التي أحتاجها بين الكتل؟

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

المرحلة الرابعة: التصميم للتكامل

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

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

هذا الفصل هو ما يُتيح لكل مكون التطور بشكل مستقل.

المرحلة الخامسة: التواصل مع أصحاب المصلحة

توفر المعمارية لغة مشتركة لمناقشة الأتمتة مع جماهير مختلفة:

• للإدارة: “نعزز وضعنا الرصدي لتخفيض MTTR.”
• لفريقك: “دعونا نُوحّد كيفية إرسال مُجمِّعنا للبيانات إلى الرصد.”
• للأقسام الأخرى: “طبقة عرضنا ستتكامل مع نظام ITSM لديكم.”

اللغة المعمارية الواضحة تُقلص الارتباك وتُساعد في كسب الدعم.

المرحلة السادسة: التطور التدريجي

تُتيح المعمارية استبدال المكونات مع تغيير احتياجاتك:

• اليوم قد تستخدم Git كمصدر حقيقة، لكن غداً يمكن تبني NetBox أو Infrahub دون إعادة تصميم سير عمل الأتمتة بالكامل، طالما حافظت على واجهات واضحة.
• قد تبدأ بسكريبت بسيط كمُنسِّق، لتستبدله لاحقاً بـAAP أو Windmill.
• يمكنك الانتقال من TSDB إلى آخر في الرصد دون تعطيل كيفية استرداد المُجمِّع لبياناته.

هذا النهج التطوري يُقلّص المخاطر ويُتيح التعلم أثناء التقدم.

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

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

3.3.2. المزالق الشائعة الواجب تجنبها#

لنكن صريحين: ستقع في أخطاء. لكن التعلم من الآخرين يُوفّر عليك ألماً كثيراً. إليك المزالق الشائعة:

1. محاولة تطبيق كل شيء دفعة واحدة

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

   النهج الأفضل: ابدأ بكتلة أو اثنتين تحلان أكثر مشكلاتك إلحاحاً. ابنِ تدريجياً. النجاح المبكر يبني الزخم والدعم.

2. الإيمان بـ"أداة واحدة تحكمهم جميعاً"

   يدّعي بعض الموردين أن منصتهم تفعل كل شيء. وإن صح ذلك أحياناً، فكثيراً ما يعني:

   • أنت مُقيَّد بطريقتهم في فعل الأشياء.
   • لا يمكنك استبدال المكونات لاحقاً.
   • تدفع مقابل ميزات لا تحتاجها.

   النهج الأفضل: اختر أفضل الأدوات لكل كتلة، لكن تأكد من أن واجهات API ونقاط التكامل واضحة. اقبل أنك قد تحتاج إلى دمج 3-5 أدوات، لكنك ستكتسب مرونة.

3. تجاهل قيود الشبكة

   تُصمّم مُنفِّذاً رائعاً باستخدام gNMI، لكن 30% من أجهزتك تدعم SSH CLI فقط. أو تريد تلمتريا تدفقية، لكن منصاتك الأقدم تدعم SNMP فحسب.

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

4. افتراض بساطة الواجهات

   تقول: “المُنفِّذ سيستدعي واجهة API للنوايا للحصول على الحالة المطلوبة.” لكن النوايا تستخدم NetBox مع امتدادات مخصصة، والمُنفِّذ يتوقع YAML مسطحاً. فجأة تكتب طبقات ترجمة.

   النهج الأفضل: استثمر مسبقاً في واجهات واضحة وموثقة جيداً. استخدم المعايير حيثما أمكن (REST APIs، وgRPC، وتعريفات مخطط واضحة). الواجهات الجيدة تكلف أقل الآن من طبقات الترجمة لاحقاً.

5. بناء أدوات مخصصة حين تتوفر أدوات جيدة

   يقرر فريقك بناء مُجمِّع مخصص لأن “لا أداة تلبي احتياجاتنا تماماً”. بعد ستة أشهر، لديك 3,000 سطر كود يصون خطوط تلمتريا خاصة.

   النهج الأفضل: قيّم الأدوات الموجودة أولاً (Telegraf، وVector، وgNMIc). تُعالج 80% من حالات الاستخدام وهي مُختبَرة في المعارك. خصّصها أو ابنِ محولات إن لزم، لكن لا تبنِ من الصفر.

6. معاملة الرصد كفكرة لاحقة

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

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

7. نسيان المستخدمين

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

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

هذه المزالق ليست نظرية - إنها أنماط من مشاريع أتمتة حقيقية. التعلم منها الآن سيجعل معمارتيك أقوى.

3.3.3. من أين تبدأ#

تُحدد المعمارية سبع كتل. لا أحد يُطبّق السبع دفعة واحدة. في الممارسة، نمطان من البداية يُمثّلان غالبية حالات النشر الحقيقية.

النمط أ: البداية بالإعداد (الأكثر شيوعاً)

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

flowchart LR
    A[النوايا / SoT] --> B[المُنفِّذ] --> C[الرصد] --> D[المُنسِّق] --> E[العرض]
    style A fill:#4a9eff,color:#fff
    style B fill:#4a9eff,color:#fff
    style C fill:#7db8f7,color:#fff
    style D fill:#b8d4f5,color:#333
    style E fill:#ddeeff,color:#333

النمط ب: البداية بالرؤية

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

flowchart LR
    A[المُجمِّع] --> B[الرصد] --> C[النوايا / SoT] --> D[المُنفِّذ] --> E[المُنسِّق]
    style A fill:#4a9eff,color:#fff
    style B fill:#4a9eff,color:#fff
    style C fill:#7db8f7,color:#fff
    style D fill:#b8d4f5,color:#333
    style E fill:#ddeeff,color:#333

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

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

3.3.4. امتلاك الكتل عبر الفرق#

تطرح الكتل السبع سؤالاً تنظيمياً بقدر ما هو معماري: من يمتلك ماذا، وكيف تتشارك فرق متعددة نفس المنصة دون التعدي على بعضها؟

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

هذا الانقسام له تداعيات على كيفية ترجمة حدود الكتل إلى حدود الفرق. SoT موردٌ مشترك للمنصة، لكن فرقاً مختلفة لها صلاحيات كتابة مختلفة فيه: فريق عناوين IP قد يمتلك بيانات IPAM؛ فريق campus قد يمتلك مخزون المفاتيح؛ فريق الأمن قد يمتلك بيانات سياسة جدار الحماية. يجب أن يتطابق نموذج Term "rbac" not found للـSoT مع حدود الملكية هذه. الكتابة في المجال الخطأ حادثة تشغيلية تنتظر الحدوث.

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

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

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

3.4. الخلاصة#

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

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

في الجزء الثاني من هذا الكتاب، سنتعمق في كل من هذه الكتل البنائية، مستكشفين أنماط التطبيق وأفضل الممارسات والأمثلة الواقعية التي يمكنك تطبيقها في مشاريع أتمتتك الخاصة.

💬 Found something to improve? Send feedback for this chapter