مقدمة في هندسة المنصات: التجاوز التدريجي لأنظمة التذاكر التقليدية في Azure

By Mirko Peters · 2026-08-13

Automatically translated with AI from the original post. Read the English original

Titelbild: Platform Engineering 101: Moving Beyond Traditional Ticketing Systems in Azure

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

في منشور المدونة المرافق هذا، سنتوسّع بشكل كبير في المفاهيم الأساسية التي ناقشناها على الهواء. سنستكشف كيف يمكن للمؤسسات التي تعتمد Microsoft Azure أن تتحرر من هذه الحلقة اليدوية المُرهِقة للروح، من خلال تبنّي منهجية هندسة المنصات التحويلية، وبناء منصات مطوّرين داخلية متينة (IDPs).

مقدمة: عنق الزجاجة في التذاكر التقليدية على Azure

دعونا نرسم صورة مألوفة. انتقلت مؤسستكم بأعبائها إلى Microsoft Azure. تبنّيتم السحابة، وأنتم تستخدمون Azure Kubernetes Service (AKS) وAzure SQL وCosmos DB وApp Services. على الورق، أنتم حديثون. لكن إن نظرتم بعناية إلى سير عملكم، ستجدون أن المطوّرين يتعاملون مع Azure تماماً كما كانوا يتعاملون مع غرفة الخوادم المحلية: من خلال جدار من البيروقراطية وطوابير التذاكر.

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

ما هي هندسة المنصات ولماذا تهم؟

إذن، كيف نصلح هذا؟ هنا تأتي هندسة المنصات. في السنوات الأخيرة، برزت هندسة المنصات بوصفها التطوّر الحاسم لـ DevOps. فبينما أزال DevOps الجدار الفاصل بين التطوير والعمليات من الناحية النظرية، فإن كثيراً من المؤسسات في الممارسة العملية ألقت كل العبء التشغيلي على عاتق المطوّرين. أصبح يُتوقع من المطوّرين فجأة أن يكونوا خبراء في Kubernetes وTerraform وأمن الشبكات وسياسات Azure IAM، بينما يحاولون في الوقت نفسه كتابة منطق الأعمال.

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

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

ما بعد العمليات اليدوية: رؤية منصات المطوّرين الداخلية

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

المشكلة مع السكريبتات المرتجلة والتوفير العشوائي (Wild West)

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

النقطة المثالية لمنصة المطورين الداخلية

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

الركائز الأساسية لبناء منصة مطورين مبنية على Azure

عند بناء منصة المطورين الداخلية الخاصة بكم على Microsoft Azure، تحتاجون إلى الاعتماد على أساس معماري متين. دعونا نستعرض الركائز الأساسية التي تجعل منصة Azure ناجحة.

1. البنية التحتية كشيفرة (IaC) وكتالوجات الوحدات

يقع في قلب أي منصة سحابية البنية التحتية كشيفرة. وفي منظومة Azure، يعني ذلك عادةً استخدام Terraform أو Bicep أو قوالب Azure Resource Manager (ARM). ومع ذلك، فإن كتابة ملفات Bicep وحدها لا تكفي. يجب على فريق المنصة إنشاء كتالوج منتقى من القوالب المعيارية القابلة لإعادة الاستخدام والآمنة. فعلى سبيل المثال، بدلًا من ترك المطور يكتب إعداد قاعدة البيانات من الصفر، توفر المنصة وحدة Azure SQL تتضمن بالفعل تشفيرًا على مستوى المؤسسات، وتكاملًا مناسبًا مع الشبكات، وإعدادات النسخ الاحتياطي المُهيأة مسبقًا. ما على المطور سوى تزويد اسم التطبيق والمستوى المطلوب.

2. نهج الشيفرة مع Azure Policy

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

3. التكامل السلس بين CI/CD وGitOps

لا ينبغي أن تعيش منصة IDP في عزلة. يجب أن تتكامل بشكل أصيل مع نظام التحكم في الإصدارات وخطوط النشر لديكم. وسواء كنتم تستخدمون GitHub Actions أو Azure DevOps أو ArgoCD لتطبيق GitOps، ينبغي للمنصة أن تنسق خط المعالجة من إيداع الشيفرة وحتى النشر على Azure بسلاسة. وينبغي أن يتمكن المطورون من تشغيل البيئات أو إيقافها مباشرةً من طلبات السحب الخاصة بهم.

4. الرصد الموحد والمراقبة

لا يمكنكم إدارة ما لا تستطيعون قياسه. توفر المنصة الجيدة إمكانية الرصد الجاهزة من خلال ربط التطبيقات مباشرةً بـ Azure Monitor وApplication Insights وAzure Log Analytics. فعندما يُنشئ المطور خدمة مصغرة جديدة عبر المنصة، يتم تهيئة السجلات والمقاييس وتتبع الطلبات وربطها تلقائيًا دون الحاجة إلى تنفيذ يدوي للتزويد بأدوات القياس.

تسريع الجداول الزمنية للتسليم وتقليل احتكاك المطورين

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

الوقت حتى السوق وتكرار النشر

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

القضاء على إرهاق المطورين

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

أفضل الممارسات لتطبيق هندسة المنصات في مؤسستكم

يبدو بناء منصة مطورين داخلية على Azure أمرًا رائعًا، لكن كيف تنفذونه فعليًا دون إحداث اضطراب كبير؟ إليكم بعض أفضل الممارسات التي نوصي بها مستمعينا وعملاءنا الاستشاريين.

التعامل مع المنصة كمنتج

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

ابدأ صغيرًا بمنصة الحد الأدنى القابلة للتطبيق (MVP)

لا تحاول بناء منصة ضخمة وشاملة لكل شيء منذ اليوم الأول. ابدأ بحالة استخدام واحدة تحل مشكلة رئيسية. على سبيل المثال، ابدأ بأتمتة توفير الخدمات الصغيرة (microservices) القياسية على Azure Kubernetes Service مع التسجيل وقواعد البيانات المدمجة. وبمجرد أن يكون ذلك ناجحًا ويُعتمد، وسّع قدرات المنصة بشكل تدريجي.

ركّز بقوة على وثائق المطورين وتجربة البوابة

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

الخلاصة: تمكين فرق التطوير الحديثة للمستقبل

أنظمة التذاكر التقليدية من مخلفات حقبة مضت. فهي تبطئ الابتكار، وتُحبط المواهب الهندسية، ولا تستفيد من القوة الحقيقية ومرونة البنية التحتية السحابية مثل Microsoft Azure. ومن خلال تبني هندسة المنصات وبناء منصات مطورين داخلية مدروسة وآمنة ومؤتمتة، تستطيع المؤسسات القضاء على الاختناقات، وفرض حوكمة متينة، وإطلاق العنان للإمكانات الكاملة لفرق التطوير لديها.

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