1. الضرورة الحتمية للأتمتة#
منذ أن ظهر Software-Defined Networking (SDN) وDevOps، لم يتوقف المهندسون عن الجدال حول ما إذا كانت أتمتة الشبكات ضرورة أم رفاهية أم مجرد تعقيد لا داعي له. الإجابة؟ يعتمد الأمر على السياق. شركات الحوسبة الضخمة (Hyperscalers) تحتاجها فعلاً: بدأت في مطلع العقد الثاني من الألفية الثالثة لأنه لم يكن أمامها خيار آخر. أما الشركات الصغيرة فقد لا تحتاج إلى أتمتة كاملة على الإطلاق. ومعظم الشبكات تقع في مكان ما بين الحالتين. تُشكّل الثقافة والمهارات ونضج الأدوات وأولويات الأعمال مدى سرعة التبني. واليوم، تتوافق هذه العوامل جميعها. باتت الأتمتة حتماً لا مفر منه.
أمضى فريق الشبكات في شركة لوجستية إقليمية ثلاث سنوات في بناء ما أسموه منصة الأتمتة الخاصة بهم. كتيبات Ansible للتوفير التلقائي لـ VLAN، وإعداد BGP للجيران، وتصليب الأجهزة. كان كودهم يعيش في Git. كانت التغييرات تمر بمراجعة الأقران. وكان النشر يستغرق دقائق بدلاً من أيام. بكل المقاييس المتاحة لهم، كانوا يُطبّقون الأتمتة بالطريقة الصحيحة.
ثم استحوذت الشركة على منافس لها وتضاعف حجمها بين عشية وضحاها. مواقع جديدة، موردان جديدان، واصطلاحات تسمية تتعارض مع اصطلاحاتهم. في المرة الأولى التي شغّلوا فيها كتيب التوفير على البيئة الجديدة، فشل بسبب حالة طرفية. أصلحوه. فشل بسبب حالة أخرى. بعد ستة أسابيع من الاستحواذ، كان أحد المهندسين يقضي وقتاً أطول في صيانة الأتمتة مما كان سيستغرقه تشغيل الشبكة يدوياً.
كان تحليل ما بعد الحادثة مزعجاً. الأدوات لم تُخفق. Ansible كان يعمل بشكل جيد. ما أخفق كان غير مرئي: لم يكن ثمة وصف موحد لما يُفترض أن تبدو عليه الشبكة. كل كتيب كان يحمل افتراضاته الخاصة حول اصطلاحات التسمية واستراتيجيات توزيع عناوين IP وسلوك الموردين. حين تغيرت البيئة، انهارت كل الافتراضات في آن واحد. لقد آلت الفريق أتمتة شبكتهم القائمة، لا بناء منصة قادرة على التكيف مع التغيير.
هذا هو النمط الكامن في قلب كل توقف في مسيرة الأتمتة. تبلغ المؤسسات نقطةً تتحول فيها الأتمتة المبنية لمشاكل اليوم إلى عائق أمام الغد.
1.1. العاصفة المثالية#
لم تعد الأتمتة اختيارية. تتعامل شركات الحوسبة الضخمة مع نمو متفجر مدفوع بـArtificial Intelligence (AI): مئات الآلاف من Central Processing Unit (CPU)s وحدات Graphics Processing Unit (GPU) تتواصل عبر Ethernet فائق السرعة. تتصارع الشركات ومزودو الخدمات مع البنية التحتية القديمة، والخدمات الجديدة، والتوسع الفوضوي بين السحابة والبنية المحلية والحافة، وتصاعد التكاليف.
كل القطاع التقني الآخر انتقل إلى نموذج API أولاً والخدمة الذاتية. يتوقع المطورون الشيء ذاته من الشبكات. أعباء عمل التعلم الآلي تحتاج إلى بيانات منظمة. الأمن والامتثال يحتاجان إلى عمليات آلية وقابلة للتدقيق.
السؤال لم يعد “هل نُؤتمت؟” بل صار: “لماذا لم نفعل ذلك بعد؟”
على الرغم من الفوائد الواضحة، تعرقل عدة عوائق عملية التبني، ولا تزال كثيرة منها قائمة:
- غياب نماذج النوايا: كانت الشبكات تُوصف من خلال إعدادات الأجهزة، لا من خلال سؤال “كيف يُفترض أن تتصرف الشبكة فعلياً؟” بدون بيانات نوايا واضحة، تظل الأتمتة هشة ومرتكزة على الأجهزة.
- تصاميم فوضوية وغير متسقة: الأتمتة تحتاج إلى قابلية التنبؤ. الشبكات المليئة باستثناءات وحلول ترقيعية مؤقتة وحالات فردية يستحيل أتمتتها. التصاميم النظيفة والمعيارية هي الفائزة.
- تشتت الموردين: مزيج من الموردين والمنصات والخدمات يعني صداعاً دائماً في التكامل.
- مهارات غير ملائمة: قلة من المهندسين كانوا يجمعون بين الشبكات وتطوير البرمجيات. جعلت هذه الفجوة تصميم الأتمتة أمراً عسيراً.
- الخوف من التغيير: الشبكات بالغة الأهمية. جعلت إدارة التغيير المحافظة من الصعب تبرير الأتمتة.
- غياب بيئات اختبار آمنة: كانت معظم الفرق تفتقر إلى مختبرات مناسبة تُطابق بيئة الإنتاج. كان اختبار الأتمتة بأمان شبه مستحيل.
هذه العوائق لا تعمل بشكل مستقل. إنها تُعزز بعضها بعضاً: بدون نماذج نوايا، تبقى الأتمتة هشة؛ والأتمتة الهشة تُضخّم الخوف من التغيير؛ والخوف من التغيير يسد الطريق أمام الاستثمار اللازم لبناء المهارات وبيئات الاختبار التي ستُقلص الهشاشة.
flowchart LR
subgraph التحديات التقنية
A[غياب نماذج النوايا]
B[تصاميم فوضوية]
C[تشتت الموردين]
D[غياب بيئات الاختبار]
end
subgraph التحديات التنظيمية
E[مهارات غير ملائمة]
end
A --> F[الخوف من التغيير]
B --> F
C --> F
D --> F
E --> F
F -->|يحد من الاستثمار| E
F -->|يبطئ التقدم في| A
style F fill:#ffcccc,stroke:#cc0000,stroke-width:2px
البشرى السارة: بحلول عام 2025، بدأت معظم هذه العوائق في التلاشي. الشركات والموردون يتحركون إلى الأمام. يُظهر استطلاع حالة أتمتة الشبكات الذي أجراه Chris Grundemann (منتدى أتمتة الشبكات) هذا التحول يحدث الآن. ومع ذلك، لا توجد وصفة سحرية واحدة. فهم العقلية يأتي أولاً.
1.2. كيفية التعامل مع أتمتة الشبكات#
يتناول هذا الكتاب مفاهيم المعمارية الأساسية التي تحتاجها لنجاح أتمتة الشبكات. لا تُطارد أداة بعينها: لا يوجد حل سحري شامل. يأتي النجاح من الجمع بين ثلاث ركائز: الأشخاص، والعمليات، والتكنولوجيا (بهذا الترتيب).
1.2.1. الركائز الثلاث للنجاح#
كهرم ماسلو (تحتاج إلى أساس متين قبل أن تبني أعلى)، كل ركيزة تدعم التي فوقها.
flowchart BT
A[الأشخاص] --> B[العمليات]
B --> C[التكنولوجيا]
style A fill:#ffcccc
style B fill:#ffe6cc
style C fill:#ffffcc
- الأشخاص: الأتمتة تحيا أو تموت بحسب الأشخاص الذين يُصمّمونها ويبنونها ويُشغّلونها. افهم احتياجاتهم. مكّنهم من خلال التدريب والتعاون.
- العمليات: يهم التوافق المؤسسي. اربط مخرجات الأتمتة بقيمة قابلة للقياس: خفض التكاليف، وتسريع التسليم، وتحسين الموثوقية.
- التكنولوجيا: الأدوات موجودة. التحدي يكمن في اختيار المناسب منها ودمجه ضمن معمارية سليمة.
وازن بين هذه الثلاثة، وستصبح الأتمتة قدرة مؤسسية لا مجرد مشروع تقني. التغيير تدريجي. يتحقق التقدم خطوة بخطوة. ستواجه معضلة الشراء مقابل البناء مراراً: نتناولها في كل أرجاء الكتاب.
1.3. كيف تبدو الواقع فعلياً#
تسلك كل مؤسسة مسارها الخاص. تبدأ معظمها بسكريبتات صغيرة، ثم تتوسع إلى إدارة الإعدادات وفحوصات الامتثال واستكشاف الأخطاء.
1.3.1. فهم طيف الأتمتة#
تتقدم نضج الأتمتة من العمليات اليدوية إلى الشبكات ذاتية التشغيل:
graph LR
A[العمليات اليدوية] --> B[المهام البرمجية]
B --> C[أتمتة سير العمل]
C --> D[الأنظمة القائمة على النوايا]
D --> E[الشبكات ذاتية التشغيل]
style A fill:#ffcccc
style B fill:#ffe6cc
style C fill:#ffffcc
style D fill:#ccffcc
style E fill:#ccccff
العمليات اليدوية: كل تغيير قرار بشري يُنفَّذ يدوياً عبر Command Line Interface (CLI). سريعة لمهندس واحد على جهاز مألوف، غير موثوقة عند أي حجم. الشبكة لا تزيد اتساقاً عن آخر شخص لمسها. لا توجد سجلات تدقيق تتجاوز سجلات تسجيل الدخول.
المهام البرمجية: تُلف الأعمال المتكررة في سكريبتات. سكريبت يُولّد إعدادات من جدول بيانات؛ حلقة تطبق نفس التغيير على خمسين جهازاً. هشة عند الحواف: كل تباين في حالة الجهاز أو سلوك المورد أو اصطلاح التسمية يتطلب سكريبتاً جديداً أو استثناءً جديداً. هذا هو المكان الذي تبدأ منه معظم الفرق، وحيث تبقى كثيراً منها.
أتمتة سير العمل: تُستبدل السكريبتات بكتيبات تشغيل وخطوط أنابيب منظمة. التغييرات قابلة للتكرار والتدقيق، ويمكن تشغيلها عبر واجهات الخدمة الذاتية. لا تزال الأتمتة تصف كيفية إعداد الأجهزة لا ما ينبغي أن تبدو عليه الشبكة. يبقى التوفيق بين الحالات نشاطاً يدوياً. كثيراً ما تصف الفرق في هذه المرحلة أتمتتها بأنها تعمل بشكل جيد، حتى تتغير البيئة.
الأنظمة القائمة على النوايا: تُوصف الشبكة من حيث النوايا (ما تريده) لا من حيث الإعدادات (كيفية تحقيقه). تحتفظ مصادر الحقيقة بتلك النوايا كبيانات منظمة. تُترجم محركات الأتمتة النوايا إلى حالة الجهاز وتتحقق من النتيجة. حين تتغير البيئة، تبقى النوايا ثابتة وتتكيف طبقة التنفيذ. يتمحور معظم هذا الكتاب حول بناء هذه الطبقة بشكل جيد: مصادر الحقيقة والتنفيذ والرصد والتنسيق وكتل العرض في الجزء الثاني هي مكونات نظام قائم على النوايا.
الشبكات ذاتية التشغيل: يرصد النظام حالته الخاصة، ويكتشف الانحرافات عن النوايا، ويُغلق الحلقة دون تدخل بشري. يتطلب ذلك أن تكون طبقة النوايا موثوقة ومفهومة جيداً ومُشغَّلة بانضباط. تستكشف الأجزاء الرابع والخامس الأنماط التي تُمكّن ذلك: الأتمتة ذات الحلقة المغلقة، والشبكات ذاتية التشغيل، والشروط التنظيمية التي تجعل التشغيل الذاتي جديراً بالثقة.
تبني الأجزاء من الأول إلى الثالث من هذا الكتاب الأساس المعماري للأنظمة القائمة على النوايا. تتناول الأجزاء الرابع والخامس ما يلزم للتقدم نحو التشغيل الذاتي. تقع معظم المؤسسات اليوم بين المهام البرمجية وأتمتة سير العمل. الهدف ليس القفز إلى الأمام: بل بناء كل طبقة على أسس متينة حتى لا تستلزم الطبقة التالية إعادة بناء ما سبقها.
ما يتغير فعلياً مع الحجم ليس الهدف بل المعمارية. الأتمتة المصممة لخمسين جهازاً تكشف اختصاراتها عند خمسمائة. تفشل كتيبات التشغيل التي تنطوي على افتراضات ضمنية حول التسمية حين تنمو الشبكة إلى ما هو أبعد من المعرفة العملية لفريق واحد. يفحص الجزء الثالث ما الذي يتعطل حين تنتقل منصة الأتمتة من عشرات الأجهزة إلى آلاف، وكيف نُصمّم لذلك منذ البداية.
ثمة فائدة خفية لأتمتة الشبكات تتمثل في دفعك إلى تبسيط معمارية شبكتك قدر الإمكان لتيسير الأتمتة. التعقيد الذي كان محتملاً في ظل الإدارة اليدوية يصبح عائقاً فعلياً حين تضطر الأتمتة إلى التعامل مع كل استثناء.
الأتمتة الكاملة هدف بعيد المدى. الأتمتة لا تحل محل الأشخاص: بل تُضخّم الخبرة وتتيح للمهندسين التركيز على التصميم وحل المشكلات. المكاسب الحقيقية هي الاتساق والموثوقية والسرعة. كما تُتيح الأتمتة أشياء يستحيل تنفيذها يدوياً على نطاق واسع: التحقق الفوري، وفحوصات الامتثال الآنية، والتغييرات المنسقة عبر مئات المواقع في آن واحد.
إليك بعض الأمثلة على ما تبدو عليه الأتمتة في بيئات مختلفة:
شركات الحوسبة الضخمة
- أخذ تصميم وتوسيعه في جميع البيانات اللازمة لنوايا الشبكة: الرفوف والأجهزة والكابلات وعناوين Internet Protocol (IP) والشبكات المتراكبة. استخدام ذلك لتوليد Bill of Materials (BOM) وإعدادات الإقلاع المقدَّمة عبر Zero Touch Provisioning (ZTP) حين تتصل الأجهزة.
- ربط بيانات الرصد (المقاييس والسجلات والتدفقات) في أحداث آنية مُثرَاة بالسياق. تشغيل سير عمل يُخفف مشكلات المستخدمين: استنزاف الاتصالات مع الإبقاء على الطاقة ضمن اتفاقية مستوى الخدمة.
مزودو الخدمات
- اختبار متعدد الجوانب لروابط الإنترنت عبر مزودي العبور. الإبقاء على فقدان الحزم والتأخير ضمن النطاق المقبول. اكتشاف المشكلات واستنزاف الحركة من الروابط المشكوك فيها. إعادتها حين تُصلَح.
- مراقبة إشعارات صيانة الدوائر من المزودين (بريد إلكتروني، webhooks). تحويلها إلى بيانات منظمة. كتم التنبيهات أو الاستجابة الاستباقية لتقليل الأثر.
الشركات
- بوابة خدمة ذاتية يُحدد فيها المستخدمون سياسات الأمن. تحويلها إلى قواعد جدار حماية وفق سياسة التطبيق. تمكين دورة حياة القاعدة التي تُنظّف القواعد غير المستخدمة.
- تحديث الأجهزة وإدارة دورة حياتها. اكتشاف أجهزة End of Life (EOL)، والإشارة إلى ثغرات البرامج، وأتمتة الترقيات، وتيسير هجرات المنصات.
المفتاح: تحديد العمليات الأكثر استهلاكاً للوقت أو عرضةً للخطأ أو بالغة الأهمية. وفهم كيف تدعم أعمالك. ثم تطويرها إلى نسخ أكثر كفاءة وآلية.
هذه الحلول يمكن أن تكون بسيطة أو معقدة، لكنها تشترك في أنماط مشتركة. يُحلّل هذا الكتاب تلك الأنماط ويختتم بحالات استخدام واقعية متطورة في الجزء الخامس – الأنماط وحالات الاستخدام.
حتى مع حسن النية، تسوء الأمور أحياناً. فيما يلي أبرز المزالق الشائعة التي ينبغي تجنبها.
1.3.2. المزالق الشائعة التي ينبغي تجنبها#
ستكتشف كثيراً من المزالق عبر صفحات هذا الكتاب لأنني اختبرتها بنفسي. إليك بعضها لتبقيها في مقدمة أولوياتك:
- محاولة أتمتة كل شيء دفعة واحدة: ابدأ بخطوات صغيرة. اختر حالات استخدام ذات أثر عالٍ ومخاطر منخفضة لبناء الثقة والخبرة.
- تضمين النوايا داخل الأدوات: حين تعيش اصطلاحات التسمية واستراتيجيات توزيع عناوين IP وافتراضات سلوك الموردين داخل كتيبات التشغيل والسكريبتات بدلاً من مرجع مشترك، لا يوجد وصف موحد لما ينبغي أن تبدو عليه الشبكة. حين تتغير البيئة، تنهار كل الافتراضات المضمّنة في آن واحد. تنتمي النوايا إلى مكان واحد تشترك فيه كل مكونات الأتمتة.
- الاستهانة بجودة البيانات: الأتمتة لا تتجاوز جودة بياناتها. استثمر مبكراً في الدقة والاتساق.
- البناء دون اختبار: اختبر وتحقق قبل النشر في الإنتاج.
- أتمتة الشبكة الحالية بدلاً من التصميم للتغيير: الأتمتة المبنية حول الطوبولوجيا والموردين واصطلاحات التسمية الحالية تعمل حتى يتغير شيء ما. قبل بناء أي مكون أتمتة، لا تسأل “هل يعمل هذا الآن؟” بل اسأل “هل يظل يعمل حين تتغير البيئة؟” ترميز الشبكة الحالية في الأتمتة يُراكم ديناً تقنياً يتضاعف مع كل تطور في الأعمال.
- البناء للمهندسين الذين بنوه لا للأشخاص الذين يستخدمونه: منصة الأتمتة المصممة فقط للفريق الذي بناها هي نقطة فشل واحدة. فريق التطبيقات الذي يُقدّم طلب خدمة، والمشغّل الذي يوافق على بوابة تغيير، والمدقق الذي يراجع تقرير امتثال — لكل منهم احتياجات مختلفة ومفردات مختلفة وتوقعات مختلفة. مراعاة هؤلاء المستخدمين منذ البداية تُشكّل كل قرار معماري: كيف تُبنى الـAPI، وكيف تُعرض الأخطاء، وكيف يُوصَّل الحالة. الأتمتة التي يفهمها المهندسون لكن لا يستطيع المستهلكون استخدامها ستُتجاوز في صمت.
أخيراً: دع عملك يتحدث عن نفسه. كيف؟ حدّد مقاييس موضوعية وتتبعها لإظهار فوائد أتمتة الشبكات وتأثيرها على الأعمال.
1.3.3. قياس نجاح الأتمتة#
ركّز على مجموعتين: المقاييس التقنية ومقاييس الأعمال. كلاهما مهم للقيادة.
المقاييس التقنية:
- متوسط وقت الاستعادة (MTTR): ما مدى سرعة اكتشاف مشكلات الشبكة وتشخيصها وحلها؟
- معدل نجاح التغييرات: ما نسبة تغييرات الشبكة التي تُنشر دون التسبب في حوادث؟
- Configuration Drift: ما مدى اتساق إعدادات الأجهزة عبر الشبكة؟
- سرعة النشر: ما مدى سرعة تطبيق خدمات جديدة أو تغييرات في الإعدادات؟
مقاييس الأعمال:
- توافر الخدمة: هل الخدمات التي تُديرها الأتمتة أكثر موثوقية من تلك التي تُدار يدوياً؟
- إنتاجية المهندسين: هل تقضي الفرق وقتاً أطول في العمل الاستراتيجي مقابل المهام التشغيلية؟
- وضع الامتثال: ما مدى سرعة التحقق من انتهاكات الامتثال ومعالجتها؟
- استخدام الموارد: هل تستثمر طاقة الشبكة وأداءها بشكل أفضل؟
تتبع هذه المقاييس بانتظام. إنها تبرر الاستثمار المستمر وتُظهر أين يمكن التحسين. يتناول الفصل السادس كيف تجمع كتلة الرصد (Observability) هذه المقاييس وتُبرزها؛ ويربطها الفصل الرابع عشر بقيمة الأعمال والتفكير في المنصة كمنتج.
1.4. خلاصة#
كانت منصة أتمتة الشركة اللوجستية كفؤة من الناحية التقنية. الإخفاق كان معمارياً: لا وصف موحد للنوايا، ولا فصل بين ما ينبغي أن تبدو عليه الشبكة وكيفية الوصول إلى ذلك، ولا طريقة للتفكير في النظام حين تتغير البيئة. هذا النمط من الإخفاق ليس استثنائياً. إنه المخرج الافتراضي حين تُعامَل الأتمتة باعتبارها مجموعة من السكريبتات لا منصة ذات تصميم مبدئي.
القوى التي تدفع الأتمتة هيكلية لا اختيارية: حجم البنية التحتية الحديثة، وتوقع الخدمة الذاتية بسرعة المطورين، والتكلفة المتصاعدة لتشغيل الشبكات يدوياً. تكتشف المؤسسات التي تتعامل مع الأتمتة باعتبارها مشكلة أدوات أن كل بيئة جديدة تتطلب إعادة البناء من الصفر. أما المؤسسات التي تتعامل معها باعتبارها مشكلة معمارية فتبني شيئاً يتضاعف مع الوقت.
الركائز الثلاث (الأشخاص، العمليات، التكنولوجيا) هي سلسلة تبعيات لا قائمة مراجعة. اختيارات التكنولوجيا التي تصمد هي تلك التي تُتخذ في خدمة عمليات واضحة، من قِبل أشخاص يفهمون المشكلة. الحصول على هذا الترتيب صحيحاً هو ما يُميّز الأتمتة التي تنمو عن الأتمتة التي يجب إعادة بنائها كل بضع سنوات.
يمتد طيف الأتمتة من العمليات اليدوية عبر المهام البرمجية وأتمتة سير العمل والأنظمة القائمة على النوايا وصولاً إلى الشبكات ذاتية التشغيل. تقع معظم المؤسسات اليوم في مكان ما في المنتصف. يبني هذا الكتاب الأساس المعماري لطبقة النوايا: يُرسي الجزءان الأول والثاني الـ"لماذا" و"الكيف"، ويفحص الجزء الثالث ما الذي يتغير مع الحجم، ويستكشف الجزءان الرابع والخامس الأنماط التي تُمكّن الخطوة نحو التشغيل الذاتي.
الإخفاق المعماري المحدد في قصة الشركة اللوجستية ليس مصادفة. إنه المخرج الافتراضي حين تُصمَّم الأتمتة بدون مبادئ صريحة: لا نوايا مشتركة، ولا فصل بين ما ينبغي أن تبدو عليه الشبكة وكيفية الوصول إلى ذلك، ولا طريقة للتفكير في النظام حين تتغير البيئة. يُسمّي الفصل الثاني تلك المبادئ ويربط كلاً منها بفئة الإخفاق التي يمنعها.
💬 Found something to improve? Send feedback for this chapter