بناء Azure يصمد في العالم الحقيقي — مع Mike Martin [MVP]

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

في هذه الحلقة من M365.FM، يتحدث Mirko Peters مع Mike Martin [MVP] عن شكل بنية Azure عندما يُضطر النظام إلى الصمود في ظروف الإنتاج الحقيقية، لا مجرد أن يبدو جيدًا على المخطط.

يجلب Mike عقودًا من الخبرة في التطوير والبنية التحتية والهندسة المعمارية والقيادة والتدريب والتوجيه، إضافة إلى Microsoft Azure. ومن أقوى ملاحظاته أن كثيرًا من المشكلات التي يواجهها المهندسون اليوم ليست جديدة. فنظام DNS ما زال يتعطل، وتبعيات عناوين IP ما زالت مهمة، والتكاليف ما زالت تشكل مشكلة، والتكاملات ما زالت تفشل، والتبعيات ما زالت تختفي في أسوأ لحظة ممكنة.

ما تغيّر هو مستوى التعقيد الذي نبنيه حول هذه المشكلات.

من Visual Basic إلى بنية Azure الحديثة
يستعرض Mike نحو ثلاثة عقود من العمل في تقنية المعلومات، بدءًا من مطور Visual Basic في تسعينيات القرن الماضي، مرورًا بالأنظمة الموزعة والشبكات وبرمجيات المؤسسات والبنية التحتية، وصولًا إلى Azure.

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

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

يرى Mike أن كثيرًا من الفرق اليوم تجعل المشكلات البسيطة معقدة دون داعٍ. فالبنية الجيدة لا تعني غالبًا إضافة مزيد من التقنيات، بل معرفة ما يجب عدم إضافته.

ماذا يفعل مهندس Azure فعليًا؟
بالنسبة إلى Mike، لا تتعلق الهندسة المعمارية باختيار أكبر عدد من خدمات Azure أو إنتاج مخطط مبهر.

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

تشمل الهندسة المعمارية أكثر بكثير من الحوسبة:

• الهوية
• الشبكات
• تدفقات البيانات
• الأمان
• المراقبة
• التكامل
• التبعيات
• قابلية التوسع
• العمليات
• الاسترداد
• النشر
• التكلفة

كما يتحدى Mike الفكرة القائلة إن السحابة الأصلية تعني تلقائيًا Kubernetes أو الحاويات. فمنصة Azure توفر كثيرًا من الخدمات المُدارة والأصلية التي يمكنها حل المشكلات دون إدخال أعباء تشغيلية غير ضرورية.

دور المهندس هو فهم الحل كاملًا واختيار أبسط بنية تلبي المتطلبات الحقيقية.

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

قبل الاختيار بين Azure Kubernetes Service أو App Service أو Azure Functions أو الحاويات أو Service Bus أو منصة أخرى، يجب على الفرق أولًا أن تفهم ما الذي يحتاجه الحل فعليًا.

أسئلة يجب طرحها:

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

تقود هذه الأسئلة مباشرة إلى مفاهيم مثل اتفاقيات مستوى الخدمة SLA وأهداف مستوى الخدمة SLO وأهداف زمن الاسترداد RTO وأهداف نقطة الاسترداد RPO.

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

RTO وRPO دون المصطلحات المعقدة
غالبًا ما يُناقش RTO وRPO بوصفهما اختصارات تقنية، لكن معناهما الحقيقي موجّه نحو الأعمال.

• RTO — زمن الاسترداد المستهدف: كم بسرعة يجب أن يعود النظام بعد الفشل؟
• RPO — نقطة الاسترداد المستهدفة: ما مقدار فقدان البيانات المقبول؟

قد يتحمل نظام مراقبة غير حرج عدة ساعات من التوقف أو فقدان البيانات، بينما قد يتطلب نظام يدعم فرق الطوارئ أو العمليات المالية أو التجارة أو البنية التحتية الحرجة استعادةً خلال دقائق.

النقطة المهمة أن هذه الأرقام لا ينبغي أن يخترعها المهندس. يجب أن تُستمد من الأثر الفعلي للفشل على العمل.

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

المرونة ليست هي نفسها التوافر العالي
يستخدم Mike تشبيهًا بسيطًا لتوضيح الفرق بين التوافر والمرونة.

قد يكون لدى النظام عالي التوافر مكوّن آخر جاهز لتولي المهمة عند فشل المكوّن الأساسي.

أما النظام المرن فهو مصمم لامتصاص المشكلات ومواصلة العمل والتعافي بسلاسة والعودة إلى الوضع الطبيعي دون أن ينهار كليًا.

هذا الفرق مهم. فقد يكون التطبيق متاحًا من الناحية الفنية لكنه يقدم تجربة سيئة. فقد يكون:

• بطيئًا
• مقيّدًا بالحد من المعدل
• متاحًا جزئيًا
• معتمدًا على خلفية متعثرة
• متأثرًا بمشكلة في التكامل
• تحت ضغط إقليمي

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

Azure لا يجعل تطبيقك مرنًا تلقائيًا
من الافتراضات الخطيرة أنه بما أن Azure نفسه عالي التوافر، فإن أي تطبيق يعمل عليه يرث هذه المرونة تلقائيًا.

هذا غير صحيح.

توفر Microsoft الخدمات والإمكانات التي تجعل البنى المرنة ممكنة، لكن على العميل أن يصمم من أجل المرونة.

وهنا تظهر أهمية الأنماط المعمارية:

• قاطع الدائرة (Circuit breakers)
• الاقتران الضعيف (Loose coupling)
• المعالجة غير المتزامنة
• التوسع المستقل
• مناطق توافر متعددة
• مناطق متعددة
• آليات التحويل عند الفشل
• المراقبة
• البنية التحتية ككود
• إجراءات استرداد مختبرة

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

لماذا يهم التصميم غير المتزامن
من أقوى الأمثلة في الحلقة الأنظمة التي تشهد ارتفاعات متوقعة في حركة المرور، مثل بوابات الضرائب الحكومية.

مشكلة تصميم شائعة تحدث عندما يعتمد كل إجراء على عملية خلفية متزامنة.

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

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

وهذا يحقق عدة مزايا:

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

وهم التوافر بنسبة 100 بالمئة
موضوع رئيسي آخر في النقاش هو الهوس بالتوافر بنسبة 100 بالمئة.

يوضح Mike بجلاء أن 100 بالمئة من وقت التشغيل ليست هدفًا معماريًا واقعيًا.

يتكون الحل عادةً من عدة خدمات، ولكل خدمة اتفاقية SLA خاصة بها. وعند دمج عدة تبعيات معًا، فإن