8. طبقة العرض#

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

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

لقد أدت الأتمتة مهمتها. لكن النتيجة كانت غير مرئية.

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

الأتمتة نجحت. نموذج الوصول لم ينجح.

كلا هذين الإخفاقين هما إخفاقا طبقة العرض. الأول هو غياب حلقة التغذية الراجعة؛ والثاني هو غياب ضوابط الأمان. يُغلق هذا الفصل تلك الثغرة.

8.1. الأسس#

8.1.1. السياق#

كل مكوِّن بنيوي تناولناه حتى الآن يواجه الداخل: نحو المكوِّنات الأخرى أو نحو المهندسين الذين يفهمون المنصة. يحتفظ Source of Truth (SoT) بنية الشبكة لأنظمة الأتمتة. يُطبِّق المنفِّذ التغييرات على الأجهزة. يتحقق Observability من النتائج. ويُنسِّق Orchestrator جميعها. لكل من هذه المكوِّنات واجهة مستخدم أو واجهة برمجة تطبيقات أو كلتاهما، مصممة للأشخاص الذين بنوا المنصة ويشغِّلونها، لا لكل من يحتاج إلى التفاعل معها.

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

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

8.1.2. الأهداف#

تخدم طبقة العرض ثلاثة أهداف تتماشى مباشرةً مع ثلاث وظائف معمارية.

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

2. خدمة كل نوع من المستهلكين عبر الواجهة الملائمة لسير عمله. يختلف مهندس الشبكات عن مدير فريق التطبيقات في الاحتياجات والعمق التقني وتوقعات طريقة تواصل الأتمتة معهم. توفر طبقة العرض أسطحاً متعددة: بوابات واجهة المستخدم الرسومية، وCommand Line Interface (CLI)، وتكاملات ChatOps، كلها مدعومة بنفس الواجهة ونفس نموذج الوصول، مع عرض الحالة للجمهور الذي بدأ الإجراء.

3. ربط المنصة ثنائي الاتجاه بالأنظمة الخارجية وإيصال النتائج مجدداً عبر القنوات التي يستخدمها المستهلكون بالفعل. يعمل فريق التطبيقات بالفعل في ServiceNow. يعمل خط أنابيب CI/CD بالفعل في نظام التحكم بالإصدار. ينبغي للمنصة أن تلتقي بهم حيث هم: تستلم الطلبات من أنظمتهم وترسل النتائج إلى تلك الأنظمة ذاتها، دون إلزامهم بأداة جديدة في سير عملهم.

8.1.3. الركائز#

ثلاث ركائز تدعم هذه الأهداف، واحدة لكل وظيفة:

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

8.1.4. النطاق#

طبقة العرض تعرض. لا تُنتج.

في النطاق:

• طبقة الواجهة البرمجية: المصادقة والتفويض والإصدار وتحديد معدل الطلبات لجميع المستهلكين
• واجهات المستهلك المبنية على تلك الواجهة: بوابات واجهة المستخدم الرسومية، وواجهة سطر الأوامر، وChatOps، وأسطح الهاتف المحمول
• التكاملات الخارجية: سير عمل نظام إدارة الخدمات، وخطافات خط أنابيب CI/CD، وتسليم خطافات الويب
• الإشعارات الصادرة: عمليات استرداد الحالة، وتنبيهات الدفع، وأحداث قناة المراسلة
• لوحات بيانات العمليات عند عرضها لجماهير من غير المهندسين (التحكم في الوصول، والتحديد بحسب الجمهور، والتضمين في البوابات؛ معمارية المقاييس الأساسية مبيَّنة في الفصل السادس)

خارج النطاق:

• إنتاج البيانات (Observability، الفصل السادس)
• عرض الإعداد ومعالجة القوالب (مصدر الحقيقة، الفصل الرابع)
• تنفيذ سير العمل وإنتاج سجل التدقيق (Orchestrator، الفصل السابع)

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

8.2. الوظائف#

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

1. طبقة الواجهة البرمجية: العقد ونموذج الوصول لجميع المستهلكين
2. واجهات المستهلك: الأسطح المبنية على ذلك العقد
3. التكاملات والإشعارات: الاتصالات بالأنظمة الخارجية والتسليم الصادر

graph LR

    subgraph الأهداف
        direction TB
        A1[واجهة برمجية مستقرة وموثَّقة ونموذج وصول متسق]
        A2[السطح المناسب لكل نوع من المستهلكين]
        A3[تكامل ثنائي الاتجاه مع الأنظمة الخارجية]
    end

    subgraph الركائز
        direction TB
        B1[طبقة الواجهة البرمجية: ذات إصدار وموثَّقة ومستقرة]
        B2[واجهات المستهلك: واجهة رسومية وسطر أوامر وChatOps وهاتف]
        B3[التكاملات والإشعارات: نظام إدارة الخدمات وCI/CD وخطافات الويب]
    end

    subgraph الوظائف
        direction TB
        C1[طبقة الواجهة البرمجية]
        C2[واجهات المستهلك]
        C3[التكاملات والإشعارات]
    end

    A1 --> B1 --> C1
    A2 --> B2 --> C2
    A3 --> B3 --> C3

    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;

    class A1,B1,C1 row1;
    class A2,B2,C2 row2;
    class A3,B3,C3 row3;

8.2.1. طبقة الواجهة البرمجية#

تناول الفصل الرابع واجهة برمجة مصدر الحقيقة بالتفصيل: كيفية استعلام أنظمة الأتمتة عن بيانات النية، وأنماط الاستهلاك (REST وGraphQL والخطافات)، ونموذج القراءة والكتابة لإعداد الشبكة. الواجهة البرمجية المُناقشة هنا تختلف في غرضها: إنها العقد الموجَّه للخارج لمستهلكي منصة الأتمتة ككل. بينما تُجيب واجهة مصدر الحقيقة على سؤال “كيف ينبغي أن تبدو الشبكة؟"، تُجيب واجهة طبقة العرض على سؤال “ما الذي تفعله منصة الأتمتة وكيف أتفاعل معها؟” قد تكون كلتاهما واجهات REST؛ إلا أنهما تخدمان جماهير مختلفة بنماذج وصول مختلفة.

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

لا ينبغي لواجهة طبقة العرض أن تعكس واجهات المكوِّنات الداخلية. إن تعرُّض نقطة نهاية /v1/sot/vlans/ تُوكِّل مباشرةً إلى واجهة مصدر الحقيقة، أو نقطة نهاية /v1/orchestrator/jobs/ تُغلِّف معرِّفات وظائف المنسِّق، يُقيِّد المستهلكين بتفاصيل التنفيذ الداخلية. عندما تستبدل مكوِّناً بآخر، يجب تحديث كل خط أنابيب CI/CD خزَّن تلك المعرِّفات. ينبغي لواجهة طبقة العرض أن تُعرِّض مفاهيم على مستوى المنصة بدلاً من ذلك: نقطة نهاية /v1/requests/ تمثِّل طلب خدمة بصرف النظر عن المنسِّق الذي عالجه، ونقطة نهاية /v1/services/vlan/ تُرجع الحالة الراهنة للشبكة المحلية مجمَّعةً من مصدر الحقيقة والرصد الشامل دون الكشف عن المكوِّن الذي أمدَّ بكل جزء من البيانات. يحصل المستهلكون على عقد مستقر؛ ويمكن للتنفيذ الداخلي أن يتطور بحرية خلفه.

8.2.1.1. ما تُعرِّضه الواجهة البرمجية#

تُعرِّض الواجهة البرمجية فئتين من نقاط النهاية:

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

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

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

8.2.1.2. الإصدار والاستقرار#

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

النهج القياسي: الإصدار عبر بادئة الرابط (/v1/، /v2/) أو ترويسة Accept، والحفاظ على الإصدار السابق خلال نافذة إهمال محددة، وإيصال التغييرات القاطعة عبر سجل التغييرات. خط أنابيب CI/CD يستدعي /v1/workflows/trigger منذ ثمانية أشهر لا ينبغي أن يكتشف يوم اثنين أن نقطة النهاية انتقلت دون تحذير.

8.2.1.3. المصادقة والتفويض#

تُجيب المصادقة على: من أنت؟ يُجيب التفويض على: ماذا مُسمَح لك بفعله؟

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

أنماط المصادقة لمنصات أتمتة الشبكات:

• تكامل SSO / LDAP: المعيار المؤسسي. يُصادق المهندسون وفرق التطبيقات بهويتهم المؤسسية. لا اعتمادات منفصلة للإدارة، وإلغاء التزويد تلقائي عند مغادرة شخص ما.
• OAuth 2.0 / OIDC: للأنظمة الخارجية ومستخدمي بوابة الويب. يُنتج رموزاً قصيرة العمر بدلاً من اعتمادات طويلة الأمد.
• رموز الواجهة البرمجية ذات النطاق المحدود: للوصول البرمجي من خطوط أنابيب CI/CD ونصوص الأتمتة. يكون كل رمز محدود النطاق بمجموعة محددة من الأذونات ذات انتهاء صلاحية محدد. الرمز المشترك للمسؤولين الذي يستخدمه جميع المستهلكين ليس مصادقة: إنه كلمة مرور مشتركة لا يمكن إلغاؤها دون تعطيل كل المستدعين في آنٍ واحد.

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

• read-only (للقراءة فقط): عرض أي بيانات، دون تشغيل أي إجراءات
• operator (مشغِّل): تشغيل سير عمل موافق عليه مسبقاً، والموافقة على البوابات، وتقديم طلبات الخدمة
• engineer (مهندس): إدارة سير العمل الكاملة، وصلاحية الكتابة في مصدر الحقيقة، وعرض جميع سجلات التدقيق
• admin (مسؤول): إعداد المنصة، وإدارة المستخدمين، ودوران الاعتمادات

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

flowchart TD
    RO[read-only]
    OP[operator]
    ENG[engineer]
    ADM[admin]

    RO -->|يُضيف: تشغيل سير العمل + الموافقة على البوابات| OP
    OP -->|يُضيف: صلاحية الكتابة في مصدر الحقيقة + إدارة سير العمل| ENG
    ENG -->|يُضيف: إعداد المنصة + إدارة المستخدمين| ADM

    style RO fill:#e8f5e9,stroke:#4caf50
    style OP fill:#c8e6c9,stroke:#388e3c
    style ENG fill:#a5d6a7,stroke:#2e7d32
    style ADM fill:#66bb6a,stroke:#1b5e20

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

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

8.2.1.4. تحديد معدل الطلبات#

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

تحديد معدل الطلبات عند حد الواجهة البرمجية: حدود لكل رمز (طلبات في الدقيقة لكل مستهلك)، وحدود الانفجار (الطلبات المتزامنة الجارية)، وحدود خاصة بالعمليات (سير عمل ترقية البرامج الثابتة لا ينبغي أبداً أن يشغِّل أكثر من مثيل واحد لكل جهاز في آنٍ واحد). ينبغي أن تُرجع استجابات تحديد معدل الطلبات HTTP 429 مع ترويسة Retry-After، لا ملء طابور صامت يظهر كمهلة انتهت بعد ساعات.

8.2.1.5. REST وGraphQL وواجهة بروتوكول سياق النموذج#

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

واجهة Model Context Protocol (MCP) هي سطح الذكاء الاصطناعي لطبقة العرض. تماماً كما يصل مشغِّلو البشر إلى المنصة عبر واجهة سطر الأوامر وفرق التطبيقات عبر البوابة، يصل وكلاء Large Language Model (LLM) إليها عبر خادم بروتوكول سياق النموذج (MCP). يستدعي الوكيل الأدوات (استعلام حالة سير العمل، وتشغيل إجراء تصحيح، وقراءة سجل التدقيق) بأي تسلسل تقتضيه عملية استدلاله، وفقاً لنفس نموذج التحكم بالوصول القائم على الأدوار المطبَّق على أي مستدعٍ آخر. يرتبط هذا مباشرةً بنمط التنسيق الوكيلي المُقدَّم في الفصل السابع (القسم 7.2.7): خادم بروتوكول سياق النموذج لطبقة العرض هو الواجهة التي تجعل تلك الأنماط قابلةً للتشغيل عبر المنصة الكاملة دون تكاملات مُرمَّزة ثابتة بين الوكيل وكل مكوِّن فردي.

يختلف REST وبروتوكول سياق النموذج في من يقود التفاعل. في تكامل REST، يعرف المستهلك مسبقاً نقاط النهاية التي يستدعيها وبأي ترتيب: يستدعي خط أنابيب CI/CD POST /v1/requests/vlan، ثم يستطلع GET /v1/requests/{id} حتى الاكتمال. التسلسل ثابت في الكود. مع بروتوكول سياق النموذج، يقرر وكيل Large Language Model (LLM) في وقت التشغيل الأدوات التي يستدعيها وبأي تسلسل، بناءً على نتيجة كل استدعاء سابق. المستهلك ليس خط أنابيب بمخطط استدعاء محدد مسبقاً؛ إنه نظام استدلال يقرأ كل نتيجة قبل تقرير ما يفعله تالياً. يُحدِّد خادم بروتوكول سياق النموذج الأدوات المتاحة ومخططاتها؛ ويقرر الوكيل كيفية استخدامها. يجعل ذلك بروتوكول سياق النموذج مناسباً للاستعلامات التشغيلية المفتوحة (“تحقَّق من مشكلة الاتصال بين المبنى ب والنواة”) التي ستستلزم من المطور توقع كل تسلسل استدعاء ممكن لو نُفِّذت بـ REST. كما يجعل التفويض أكثر حساسية: وكيل بصلاحية وصول واسعة للأدوات يمكنه الجمع بين العمليات بطرق لم يُصمَّم نموذج الوصول لها صراحةً. يجب تطبيق نموذج التحكم بالوصول القائم على الأدوار على مستوى الأداة، لا على مستوى الخادم فحسب.

8.2.2. واجهات المستهلك#

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

8.2.2.1. واجهة المستخدم الرسومية وبوابة الخدمة الذاتية#

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

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

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

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

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

8.2.2.2. واجهة سطر الأوامر#

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

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

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

مبادئ تصميم واجهة سطر أوامر منصة الأتمتة:

• بنية أمر اسم الشيء-الفعل المتسقة (workflow run، وworkflow status، وrequest list) تُعيَّن بشكل قابل للتنبؤ على عمليات الواجهة البرمجية
• مخرجات قابلة للقراءة آلياً عبر علامة --json لكي تتمكن نصوص خط الأنابيب من تحليل النتيجة
• إعداد يراعي البيئة: نقطة نهاية الواجهة البرمجية والرمز يُقرأان من ملف إعداد أو متغيرات بيئة، لا يُرمَّزان ثابتاً في النصوص
• نفس التحكم بالوصول القائم على الأدوار المطبَّق على الواجهة البرمجية ينطبق على واجهة سطر الأوامر: رمز ذو أذونات مستوى المشغِّل لا يستطيع تشغيل عمليات مستوى المسؤول بصرف النظر عن السطح المستخدَم

8.2.2.3. المراسلة الفورية والهاتف المحمول#

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

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

• تدفقات الموافقة: رسالة Slack مع زرَّي “موافقة” و"رفض" تُتيح لمهندس الشبكات التصرف على بوابة معلقة دون مغادرة Slack. يستدعي النقر على الزر نقطة نهاية الواجهة البرمجية للموافقة بهوية المهندس، المُحللة من خلال تكامل SSO للمنصة مع OAuth الخاص بـ Slack.
• استعلامات الحالة: @netbot status app-payments يُرجع حالة سير العمل الراهنة في رسالة قناة منسَّقة.
• الإجراءات السريعة: @netbot compliance-check building-b يُشغِّل سير عمل تحقق خفيفة الوزن ويُنشر النتيجة مُضمَّنة.

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

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

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

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

8.2.2.4. متى تبني مقابل قبول الواجهات المدمجة#

لدى كل مكوِّن تقريباً واجهة مستخدم بالفعل. لـ AWX بوابة سير عمل. لـ Nautobot واجهة ويب. لـ Grafana لوحات بيانات. هذه الواجهات المدمجة كافية للجمهور الهندسي الذي يفهم المنصة. لا ينبغي أن يكون قرار بناء طبقة عرض مخصصة هو الافتراضي.

تسلسل قرار عملي:

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

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

8.2.2.5. التوثيق والتقارير#

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

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

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

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

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

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

8.2.3. التكاملات والإشعارات#

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

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

8.2.3.1. تكامل نظام إدارة خدمات تكنولوجيا المعلومات#

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

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

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

نموذج ServiceNow لـ “طلب خدمة شبكية جديدة” يلتقط بالضبط الحقول التي يحتاجها نموذج مصدر الحقيقة ويُقدِّمها بالتنسيق المنظَّم الذي تتوقعه طبقة الواجهة البرمجية. النموذج هو طبقة العرض؛ لا يرى المستهلك استدعاء الواجهة البرمجية. عند الإرسال، تتحقق طبقة العرض من صحة الحمولة، وتُصادق رمز حساب الخدمة الذي يستخدمه تكامل نظام إدارة الخدمات، وتُعيد توجيه الطلب المهيكَّل إلى المنسِّق.

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

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

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

8.2.3.2. تكامل خط أنابيب CI/CD#

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

هنا أيضاً تكسب واجهة سطر الأوامر مكانتها في السياقات الآلية. خطوة خط أنابيب تُشغِّل netauto workflow run vlan-deploy --params params.json --wait أسهل في تصحيح الأخطاء، وأسهل في ضبط الإصدار، وأسهل في الاستبدال من استدعاء HTTP خام يُنشئ حمولة الواجهة البرمجية مضمَّنة. رمز الخروج المنظَّم لواجهة سطر الأوامر يُعيَّن مباشرةً على شرط نجاح أو فشل خطوة خط الأنابيب.

8.2.3.3. إشعارات الدفع وتسليم خطافات الويب#

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

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

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

الأدوات المذكورة هنا أمثلة لأغراض تفسيرية، لا توصيات. قيِّمها مقابل قدرات فريقك والأدوات الموجودة والقيود التشغيلية.

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

نموذجان يتعايشان في منصات الأتمتة الناضجة.

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

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

يهم فهم ما هو داخل الواجهات المدمجة لقرارات التخصيص. NetBox مبني على Django (Python)؛ واجهة الويب وواجهة REST البرمجية هي عروض Django ونقاط نهاية إطار عمل REST لـ Django. Nautobot يشترك في الأصل ذاته. Infrahub يستخدم FastAPI. “مكوِّن طبقة العرض” في أدوات مصدر الحقيقة هذه هو إطار ويب ناضج: قابل للتخصيص من خلال الإضافات والعروض المخصصة وامتدادات المسلسِل. هذا هو قوته (موثَّق جيداً، صالح للإنتاج) وقيده أيضاً (أنت تُخصِّص داخل إطار مصمَّم أساساً لحالة استخدام مصدر الحقيقة، لا لحالة استخدام بوابة الخدمة الذاتية).

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

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

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

8.3.1. سطحان، ثلاثة جماهير، منصة واحدة#

تابعنا شبكة الحرم الجامعي عبر جميع أجزاء الجزء الثاني. جرى تصميم طلب خدمة VLAN لـ app-payments في مصدر الحقيقة في الفصل الرابع، ونشره من قِبَل المنفِّذ في الفصل الخامس، والتحقق منه بواسطة مكوِّن الرصد الشامل في الفصل السادس، وتنسيقه من البداية إلى النهاية بواسطة المنسِّق في الفصل السابع. ما لم يُعالَج قط هو كيف يتفاعل ثلاثة جماهير مختلفة مع ذلك سير العمل.

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

الجماهير الثلاثة

• يُقدِّم فريق التطبيقات الطلبات من خلال نموذج ServiceNow. يريدون معرفة متى تكون الخدمة جاهزة وما الذي حدث إن فشلت. لا ينبغي لهم الحاجة إلى فتح AWX أو Nautobot. ServiceNow هو طبقة العرض لديهم؛ واجهة المنصة البرمجية شيء لا يرونه قط.

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

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

سطحا طبقة العرض

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

flowchart TD
    subgraph المستهلكون
        AT[فريق التطبيقات]
        NE[مهندس الشبكات]
        SA[مدقق الأمان]
    end

    subgraph PL[طبقة العرض]
        SN[ServiceNow]
        PORTAL[البوابة المخصصة]
        API[طبقة الواجهة البرمجية: المصادقة · التحكم بالوصول · الإصدار]
    end

    subgraph Blocks[مكوِّنات المنصة]
        ORC[المنسِّق]
        SOT[مصدر الحقيقة]
        OBS[الرصد الشامل]
    end

    AT --> SN
    NE & SA --> PORTAL
    SN & PORTAL --> API
    API --> ORC & SOT & OBS

    classDef presentation fill:#f0e6ff,stroke:#9b59b6,color:#4a235a
    classDef api fill:#e8e8e8,stroke:#555,color:#111,font-weight:bold
    classDef block fill:#f5f5f5,stroke:#999,color:#333

    class SN,PORTAL presentation
    class API api
    class ORC,SOT,OBS block

الخطوة 1: ServiceNow بوصفه سطح فريق التطبيقات

يملأ فريق التطبيقات نموذج ServiceNow: اسم الخدمة (app-payments)، وحجم الشبكة الفرعية (/24)، والمبنى (building-b)، والفريق الطالب، والمبرر التجاري. عند الإرسال، يستدعي ServiceNow طبقة الواجهة البرمجية للمنصة مباشرةً كجزء من أتمتة سير عمله الخاص. تتحقق طبقة الواجهة البرمجية من صحة الحمولة مقابل نموذج بيانات مصدر الحقيقة، وتُصادق رمز حساب الخدمة الذي يستخدمه ServiceNow، وتُعيد توجيه الطلب المهيكَّل إلى المنسِّق.

إن فشل التحقق (مثلاً، المبنى المطلوب لا يُطابق أي موقع في مصدر الحقيقة، أو حجم الشبكة الفرعية يتعارض مع تخصيص موجود)، تُرجع طبقة الواجهة البرمجية خطأً مهيكَلاً فوراً، قبل بدء أي سير عمل في المنسِّق. يُحدِّث ServiceNow التذكرة بسبب فشل واضح: “building-c غير موجود في سجل المواقع” أو “تتعارض الشبكة الفرعية /24 مع التخصيص الموجود 10.22.14.0/24 في building-b.” يرى فريق التطبيقات الرفض في تذكرتهم ويمكنهم تصحيح الطلب دون إشراك مهندس شبكات. لا تُنشأ حالة سير عمل جزئية ولا تُحتاج عملية تراجع نمط Saga (نمط التعويض التسلسلي)، لأن سير العمل لم يبدأ أصلاً.

مع تقدم سير العمل، تشترك طبقة العرض في أحداث حالة المنسِّق وتُترجمها إلى تحديثات لتذاكر ServiceNow: “اكتمل التحقق في مصدر الحقيقة”، “تجري عمليات الفحص المسبق: 24 محولاً”، “بوابة الموافقة: في انتظار توقيع المهندس”، “مكتمل: 24/24 محولاً مُهيَّأ”. يراقب فريق التطبيقات تذكرتهم تتحدث دون معرفة وجود المنسِّق أو مصدر الحقيقة أو AWX.

الخطوة 2: سطح بوابة الموافقة

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

الخطوة 3: عرض التدقيق

بعد ثلاثة أشهر، يستعلم مدقق الأمان عن واجهة طبقة العرض البرمجية: “أرني سجل التغيير الكامل للشبكة المحلية app-payments في المبنى ب.” تُجمِّع نقطة نهاية التدقيق للقراءة فقط ثلاثة مصادر:

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

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

ما يُثبته ذلك

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

8.4. خلاصة#

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

طبقة الواجهة البرمجية هي الأساس. المصادقة والتفويض المفروضان على حد الواجهة البرمجية (لا في كل أداة) هو ما يفصل الأتمتة في متناول الجميع عن الأتمتة الخطرة. الإصدار والعقود المستقرة هو ما يفصل المنصة عن النموذج الأولي الذي يُعطِّل مستدعيه عند كل تحديث. تُمتد واجهة Model Context Protocol (MCP) نموذجَ الوصول ذاته إلى وكلاء Large Language Model (LLM) القائمين، مما يجعل المنصة متاحةً لأنماط التنسيق الوكيلية المُقدَّمة في الفصل السابع والمُطوَّرة أكثر في الفصل السابع عشر.

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

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

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

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

💬 Found something to improve? Send feedback for this chapter