<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Part 2: Architectural Building Blocks on Designing Network Automation at Scale</title><link>https://designingnetworkautomation.com/ar/series/part2-architectural-building-blocks/</link><description>Recent content in Part 2: Architectural Building Blocks on Designing Network Automation at Scale</description><generator>Hugo</generator><language>ar</language><atom:link href="https://designingnetworkautomation.com/ar/series/part2-architectural-building-blocks/index.xml" rel="self" type="application/rss+xml"/><item><title>04 - مصدر الحقيقة</title><link>https://designingnetworkautomation.com/ar/series/part2-architectural-building-blocks/04-source-of-truth/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://designingnetworkautomation.com/ar/series/part2-architectural-building-blocks/04-source-of-truth/</guid><description>&lt;h1 id="4-مصدر-الحقيقة">4. مصدر الحقيقة&lt;a class="anchor" href="#4-%d9%85%d8%b5%d8%af%d8%b1-%d8%a7%d9%84%d8%ad%d9%82%d9%8a%d9%82%d8%a9">#&lt;/a>&lt;/h1>
&lt;p>كانت خدمة جديدة بحاجة إلى الإطلاق بنهاية الأسبوع. كان التغيير بسيطاً في ظاهره: VLAN جديد، وشبكة فرعية جديدة، وقواعد جدار حماية محدّثة، ومجتمع BGP جديد على أجهزة التوجيه الطرفية. كان مهندس الشبكة يعرف تماماً ما يجب فعله. غير أن ما تلا ذلك كان أربعة أيام من التنسيق عبر خمسة أنظمة: أداة IPAM لحجز الشبكة الفرعية، وCMDB لتسجيل الخدمة، ومنصة إدارة جدار الحماية لدفع السياسة الجديدة، ونظام تهيئة أجهزة التوجيه لمجتمع BGP، ومنصة الرصد لإضافة الحدود الجديدة. كان لكل نظام واجهته الخاصة ونموذج بياناته الخاص وسير عمل موافقته الخاص. وبسبب غياب أي مرجع مشترك، كان على المهندس نقل السياق يدوياً: نسخ القيم من نظام إلى آخر، آملاً ألا يحدث أي انحراف بين الخطوات.&lt;/p></description></item><item><title>05 - التنفيذ</title><link>https://designingnetworkautomation.com/ar/series/part2-architectural-building-blocks/05-execution/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://designingnetworkautomation.com/ar/series/part2-architectural-building-blocks/05-execution/</guid><description>&lt;h1 id="5-التنفيذ">5. التنفيذ&lt;a class="anchor" href="#5-%d8%a7%d9%84%d8%aa%d9%86%d9%81%d9%8a%d8%b0">#&lt;/a>&lt;/h1>
&lt;p>كان كتاب التشغيل يعمل بشكل مثالي لأشهر: عشرة مفاتيح وصول في المختبر، دقيقتان من البداية إلى النهاية، نتائج نظيفة في كل مرة. حين قرر الفريق طرحه على الجرد الكامل من 800 مفتاح، لم يتوقع أحد مشكلة. تحدّثت الـ600 جهاز الأولى بلا عوائق. ثم تباطأت المهمة. ثم توقفت. بدأ خادم RADIUS، الذي تلقّى فجأة 150 طلب مصادقة SSH متزامناً، برفض الاتصالات. توقف Ansible عند 150 جهازاً في منتصف التنفيذ. قتل مهندس المهمة.&lt;/p></description></item><item><title>06 - الرصد الشامل</title><link>https://designingnetworkautomation.com/ar/series/part2-architectural-building-blocks/06-observability/</link><pubDate>Mon, 12 Jan 2026 00:00:00 +0000</pubDate><guid>https://designingnetworkautomation.com/ar/series/part2-architectural-building-blocks/06-observability/</guid><description>&lt;h1 id="6-الرصد-الشامل">6. الرصد الشامل&lt;a class="anchor" href="#6-%d8%a7%d9%84%d8%b1%d8%b5%d8%af-%d8%a7%d9%84%d8%b4%d8%a7%d9%85%d9%84">#&lt;/a>&lt;/h1>
&lt;p>فشل وحدة مروحة في موجّه أساسي لمزود خدمة بصمت خلال الليل. لم تُرسَل أي تنبيهات. اكتشف النظام الفرعي لإدارة الحرارة في بطاقات الخطوط ارتفاع درجات الحرارة، وبدأ في تقليل أداء دوائر ASICs المسؤولة عن إعادة التوجيه لحماية الأجهزة. انخفض الإنتاجية على رابط عبور في الإنتاج بنسبة 40%. لم يرصد نظام المراقبة شيئاً: كانت مستشعرات الحرارة التي يستطلعها موجودة على وحدة الإشراف في الهيكل، لا على بطاقات الخطوط الفردية. كانت استطلاعات SNMP تُجرى كل خمس دقائق وتُفيد بأن الجهاز سليم. أظهرت عدادات الواجهة إنتاجية منخفضة، لكن لم يُهيَّأ أي حد لهذا النمط لأن الرابط كان دائماً أقل من طاقته الكاملة.&lt;/p></description></item><item><title>07 - التنسيق</title><link>https://designingnetworkautomation.com/ar/series/part2-architectural-building-blocks/07-orchestration/</link><pubDate>Fri, 20 Mar 2026 00:00:00 +0000</pubDate><guid>https://designingnetworkautomation.com/ar/series/part2-architectural-building-blocks/07-orchestration/</guid><description>&lt;h1 id="7-التنسيق">7. التنسيق&lt;a class="anchor" href="#7-%d8%a7%d9%84%d8%aa%d9%86%d8%b3%d9%8a%d9%82">#&lt;/a>&lt;/h1>
&lt;p>قام فريق الشبكة بكل شيء بشكل صحيح. كان لديهم مصدر حقيقة متين، وكتيبات تشغيل مُختبَرة لكل عملية، ودليل إجراءات واضح لتنفيذها. على الورق، كان نشر خدمة VLAN جديدة مؤتمتاً بالكامل. في الواقع، استغرق نصف يوم ومهندسة بعينها.&lt;/p>
&lt;p>كانت تلك المهندسة تعرف التسلسل. أولاً، التحقق من اكتمال بيانات مصدر الحقيقة. ثم تشغيل كتيب الفحوصات المسبقة. ثم مراجعة المخرجات، والبحث عن الأجهزة الفاشلة، والقرار بالمتابعة أو التوقف. ثم تشغيل كتيب النشر. ثم الانتظار. ثم تشغيل كتيب التحقق. ثم تحديث تذكرة ServiceNow يدوياً. إن فشل أي جهاز في منتصف الطريق، التراجع قبل أن تلاحظ الأجهزة الأخرى. كان كل ذلك موثقاً في دليل إجراءات، خطوة بخطوة، في مستند مشترك لم يستوعبه أحد آخر بالكامل.&lt;/p></description></item><item><title>08 - طبقة العرض</title><link>https://designingnetworkautomation.com/ar/series/part2-architectural-building-blocks/08-presentation/</link><pubDate>Sat, 28 Mar 2026 00:00:00 +0000</pubDate><guid>https://designingnetworkautomation.com/ar/series/part2-architectural-building-blocks/08-presentation/</guid><description>&lt;h1 id="8-طبقة-العرض">8. طبقة العرض&lt;a class="anchor" href="#8-%d8%b7%d8%a8%d9%82%d8%a9-%d8%a7%d9%84%d8%b9%d8%b1%d8%b6">#&lt;/a>&lt;/h1>
&lt;p>كانت أتمتة الشبكات المحلية (VLAN) تعمل منذ ستة أسابيع. كان فريق الشبكات فخوراً بما أنجزه. كل صباح، تصل ثلاثة أو أربعة طلبات خدمة جديدة من فرق التطبيقات، ويتولى المنسِّق معالجتها دون أن يلمس أحد في فريق الشبكات لوحة المفاتيح. النشر يعمل. المحولات مُهيَّأة. الشبكة بصحة جيدة.&lt;/p>
&lt;p>وصل التصعيد يوم الخميس. كان مدير فريق التطبيقات يتساءل لماذا يستغرق تنفيذ طلبات VLAN من ثلاثة إلى خمسة أيام عمل بينما البوابة تُظهِر &amp;ldquo;تم الإرسال&amp;rdquo;. راجع فريق الشبكات طابور العمل لديهم: لا طلبات معلقة، وجميع عمليات النشر ناجحة. لقد عالجت منظومة الأتمتة كل طلب في غضون عشرين دقيقة من استلامه. لكن تذاكر ServiceNow لا تزال تُظهِر &amp;ldquo;قيد التنفيذ&amp;rdquo;، لأن أحداً لم يكتب التكامل الذي يُحدِّثها.&lt;/p></description></item><item><title>09 - الشبكة</title><link>https://designingnetworkautomation.com/ar/series/part2-architectural-building-blocks/09-the-network/</link><pubDate>Sun, 29 Mar 2026 00:00:00 +0000</pubDate><guid>https://designingnetworkautomation.com/ar/series/part2-architectural-building-blocks/09-the-network/</guid><description>&lt;h1 id="9-الشبكة">9. الشبكة&lt;a class="anchor" href="#9-%d8%a7%d9%84%d8%b4%d8%a8%d9%83%d8%a9">#&lt;/a>&lt;/h1>
&lt;p>كانت أتمتة الشبكات المحلية (VLAN) تعمل في المختبر منذ ثلاثة أسابيع. ثلاثة محولات، واحد من كل مورِّد، وجميع سير العمل ناجحة. شعر الفريق بثقة. في أول تشغيل إنتاجي، فشل 23 من أصل 800 محول في شبكة الحرم. كلها HPE. كلها تعمل بإصدار برامج ثابتة لم يوثِّقه أحد.&lt;/p>
&lt;p>كان الـ playbook يتحقق من استجابة الخطأ من كل جهاز بعد دفع إعداد VLAN. في أنظمة HPE الحديثة، تُرجع VLAN الموجودة مسبقاً رمز الخطأ &lt;code>duplicate-vlan&lt;/code>. في هذا الإصدار الأقدم من البرامج الثابتة، أرجعت الحالة ذاتها &lt;code>vlan-exists&lt;/code>. كُتب الـ playbook ليُعامل &lt;code>duplicate-vlan&lt;/code> كإشارة تكافؤ أداتي، أي &amp;ldquo;هذا موجود بالفعل، لا بأس&amp;rdquo;. لم يُكتَب لمعالجة &lt;code>vlan-exists&lt;/code>، فعامله كفشل. أبلغ ثلث أسطول HPE عن فشل. جرى التراجع بنظافة. ظلت تذكرة فريق التطبيقات مفتوحة لثلاث ساعات إضافية بينما دقَّق فريق الشبكات يدوياً أي المحولات جرى إعدادها فعلاً وأيها لم يجرِ.&lt;/p></description></item></channel></rss>