ثورة هندسة المنصات: لماذا مات DevOps

وعد DevOps الذي انكسر

كان من المفترض أن يُحرر DevOps المطورين. أن يهدم الجدار بين التطوير والعمليات. أن يمنح المهندسين ملكية شاملة لخدماتهم من البداية إلى النهاية. أصبح شعار “You build it, you run it” هو المبدأ السائد. وعلى مدار عقد كامل، أعادت المؤسسات هيكلة ثقافتها الهندسية بالكامل حول هذا المبدأ.

المشكلة أن “أنت تبنيه، أنت تشغّله” تحوّل إلى “أنت تبنيه، أنت تشغّله، أنت تُهيّئ خط أنابيب CI/CD، أنت تكتب كود Terraform، أنت تدير ملفات Kubernetes، أنت تُصلح أخطاء شبكة الخدمات (Service Mesh)، أنت تُعدّ حزمة المراقبة، أنت تتعامل مع تنبيهات الحوادث في الثالثة صباحاً، وما زال عليك تسليم الميزات في الوقت المحدد.”

انفجر الحمل المعرفي على المطورين الأفراد. وثّقت تقارير State of DevOps السنوية من Puppet — التي تُنتج الآن تحت إشراف Perforce — تعقيد سلسلة الأدوات المتنامي كموضوع رئيسي، حيث حملت نسخة 2024 عنواناً فرعياً صريحاً هو “The Evolution of Platform Engineering” اعترافاً بالمشكلة. يستهلك الوقت المخصص لمهام البنية التحتية “غير البرمجية” ما بين 30 إلى 40% من أسبوع المطور في كثير من المؤسسات. انخفضت درجات رضا المطورين بشكل ملحوظ بين عامَي 2023 و2024 — حيث أفاد 80% من المطورين بعدم السعادة أو الرضا السلبي في استطلاع Stack Overflow لعام 2024 — قبل تعافٍ طفيف في 2025، حين ارتفعت نسبة السعادة المُعلنة من 20% إلى 24%.

هندسة المنصات (Platform Engineering) هي ردّ الصناعة: بدلاً من مطالبة كل مطور بأن يكون خبير DevOps شاملاً، يتم بناء منصة مطورين داخلية (IDP — Internal Developer Platform) تُجرّد تعقيد البنية التحتية وتوفر “مسارات ذهبية” (Golden Paths) للخدمة الذاتية — سير عمل مُهيّأ مسبقاً وذو رأي محدد يتيح للمطورين النشر والمراقبة وإدارة الخدمات دون أن يصبحوا متخصصين في Kubernetes.

تتوقع Gartner أنه بحلول عام 2026، ستكون 80% من مؤسسات هندسة البرمجيات الكبرى قد أنشأت فرق هندسة منصات كمزودين داخليين للخدمات والمكونات والأدوات القابلة لإعادة الاستخدام لتسليم التطبيقات — ارتفاعاً من 45% في 2022.

ما هي منصة المطورين الداخلية؟

منصة المطورين الداخلية (IDP) هي طبقة من الأدوات والأتمتة، يبنيها فريق منصة مخصص، تقع بين المطورين والبنية التحتية الأساسية. توفر واجهات خدمة ذاتية للمهام الشائعة: تجهيز البيئات، نشر الخدمات، إعداد قواعد البيانات، تهيئة المراقبة، إدارة الأسرار (Secrets)، والوصول إلى السجلات.

مبدأ التصميم الأساسي هو التجريد دون فقدان السيطرة. يجب أن يتمكن المطور الذي يطلب قاعدة بيانات PostgreSQL جديدة من الحصول عليها بملء نموذج أو تنفيذ أمر CLI — دون الحاجة إلى فهم وحدات Terraform وسياسات الشبكة وتكوينات النسخ الاحتياطي وأدوار IAM التي تجعلها تعمل. لكن المنصة لا ينبغي أن تمنع المستخدمين المتقدمين من الوصول إلى عناصر التحكم منخفضة المستوى عندما يحتاجون إليها فعلاً.

تتضمن بنية منصة المطورين الداخلية الحديثة عادةً:

بوابة المطورين — واجهة ويب حيث يمكن للمطورين اكتشاف الخدمات المتاحة، والاطلاع على التوثيق، والتحقق من حالة عمليات النشر، وبدء سير العمل الشائعة. يُعد Backstage من Spotify الإطار مفتوح المصدر المهيمن لبناء بوابات المطورين، مع أكثر من 3,400 جهة مُتبنية في بداية 2026 — بما فيها Expedia وHP وAirbnb وLEGO وToyota ووزارة الدفاع الأمريكية — ويستحوذ على 89% من حصة السوق بين أُطر بوابات المطورين الداخلية.

كتالوج الخدمات — سجل لكل خدمة وواجهة برمجة تطبيقات (API) ومكتبة ومكون بنية تحتية في المؤسسة، مع معلومات الملكية والتوثيق وخرائط التبعيات. يحل هذا مشكلة “من يملك هذا؟” التي تعاني منها المؤسسات الهندسية الكبيرة.

المسارات الذهبية — قوالب مُهيّأة مسبقاً وذات رأي محدد للعمليات الشائعة. “نشر خدمة مصغرة جديدة” ليست مهمة مفتوحة بل سير عمل موجّه يُنشئ المستودع ويُهيّئ CI/CD ويُجهّز البنية التحتية ويُعدّ المراقبة ويُضيف الخدمة إلى الكتالوج — في دقائق بدلاً من أيام.

تجهيز البنية التحتية بالخدمة الذاتية — يطلب المطورون موارد البنية التحتية (قواعد بيانات، طوابير رسائل، حاويات تخزين، فضاءات أسماء Kubernetes) عبر المنصة بدلاً من تقديم تذاكر لفريق عمليات مركزي. تتولى المنصة التجهيز والتهيئة وضوابط الأمان وتتبع التكاليف تلقائياً.

Backstage: الأساس مفتوح المصدر

أطلقت Spotify مشروع Backstage كبرنامج مفتوح المصدر في 2020، وأصبح المعيار الفعلي لبناء بوابات المطورين. يوفر Backstage بنية قائمة على الإضافات (Plugins) حيث يمكن للمؤسسات دمج أدواتها الخاصة — GitHub وJenkins وArgoCD وPagerDuty وDatadog وTerraform وAWS وGCP — في تجربة مطور موحدة.

بحلول عام 2026، يضم نظام Backstage البيئي أكثر من 210 إضافة مجتمعية تغطي CI/CD وتجهيز البنية التحتية والفحص الأمني وإدارة التكاليف وتوثيق واجهات برمجة التطبيقات، مع أكثر من 1,600 مساهم و60,000 مساهمة إجمالية. قبلت CNCF مشروع Backstage كمشروع في مرحلة الحضانة (Incubating) في مارس 2022، مما يشير إلى تبنٍّ ونضج على مستوى الصناعة.

الفكرة الجوهرية وراء Backstage هي أن مشكلة تجربة المطور هي في الأساس مشكلة تكامل وليست مشكلة أدوات. تمتلك معظم المؤسسات بالفعل أدوات كافية للـ CI/CD والمراقبة والبنية التحتية. ما ينقصها هو واجهة موحدة تجمع هذه الأدوات بطريقة قابلة للاكتشاف وسهلة الاستخدام دون خبرة عميقة في كل أداة على حدة.

من بين الشركات التي تبني على Backstage:

Spotify (المُبتكر) يستخدم Backstage لإدارة أكثر من 14,000 مكون برمجي عبر أكثر من 2,700 مهندس، موفراً بوابة واحدة لإنشاء الخدمات والتوثيق والنشر وإدارة الحوادث.

Netflix يستخدم منصة داخلية (مبنية جزئياً على أنماط Backstage) تمكّن المطورين من الانتقال من “لديّ فكرة” إلى “قيد التشغيل في الإنتاج” بأقل جهد في البنية التحتية.

وزارة الدفاع الأمريكية تبنّت Backstage كجزء من Platform One، منصتها لتطوير ونشر البرمجيات وفق DevSecOps التي يُشغّلها سلاح الجو الأمريكي، مما يُظهر أن هندسة المنصات وصلت إلى القطاعات الحكومية والدفاعية.

المسارات الذهبية: ذات رأي محدد بالتصميم

مفهوم “المسارات الذهبية” (أو “الطرق المعبّدة”) هو جوهر هندسة المنصات. المسار الذهبي هو طريقة مدعومة ومُوصى بها لإنجاز مهمة — ليست الطريقة الوحيدة، لكنها الطريقة التي قام فريق المنصة بتحسينها واختبارها وتأمينها وتوثيقها.

على سبيل المثال، قد يتضمن المسار الذهبي لـ “نشر خدمة مصغرة Python جديدة”:

1. قالب مستودع GitHub بهيكل مشروع قياسي وDockerfile وتهيئة CI/CD

2. إنشاء تلقائي لفضاء أسماء Kubernetes مع حدود الموارد وسياسات الشبكة

3. لوحات مراقبة مُهيّأة مسبقاً وقواعد تنبيه

4. فحص أمني آلي في خط أنابيب CI

5. تسجيل الخدمة في الكتالوج مع قوالب الملكية والتوثيق

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

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

مقاييس DORA وقاعدة الأدلة

يقيس فريق DevOps Research and Assessment — المعروف اختصاراً بـ DORA — (وهو الآن جزء من Google Cloud) أداء تسليم البرمجيات منذ أكثر من عقد عبر تقريره السنوي State of DevOps. يتتبع الإطار مقاييس رئيسية — تكرار النشر، والمهلة الزمنية لتطبيق التغييرات، ومعدل فشل التغييرات، ووقت التعافي من النشر الفاشل (أُعيدت تسميته من متوسط وقت الاستعادة في 2025، مصحوباً بإضافة مقياس خامس: معدل إعادة العمل).

يقدم بحث DORA أدلة مهمة — وإن كانت دقيقة — لصالح هندسة المنصات:

وجد تقرير DORA 2024 أن 90% من المؤسسات المستطلعة تُبلغ الآن عن امتلاكها قدرات هندسة منصات، مما يعكس التبني السريع والواسع للنهج. غير أن النتائج لم تكن إيجابية بشكل موحد: فالفرق التي اعتمدت بشكل كبير على المنصات شهدت انخفاضاً بنسبة 8% في الإنتاجية، ربما بسبب الاختبارات وضوابط الأمان الإضافية التي تفرضها حواجز المنصة. في الوقت نفسه، ارتبطت استقلالية المطورين — التي تُتيحها منصات الخدمة الذاتية المُصممة جيداً — بتحسن بنسبة 5% في الإنتاجية.

تجاوز تقرير DORA 2025 مستويات الأداء البسيطة ليُحدد سبعة نماذج فريق متمايزة، معترفاً بأن فعالية الهندسة أكثر تعقيداً من مجرد تصنيف “أداء عالٍ” مقابل “أداء منخفض”. ظلت مقاييس أداء تسليم البرمجيات مستقرة إجمالاً، لكن التقرير أكد أن جودة المنصة — وليس مجرد وجودها — هي ما يحدد النتائج. والأهم من ذلك، أظهرت نتائج 2025 أن جودة المنصة ترتبط مباشرة بقدرة الذكاء الاصطناعي على تعزيز أداء الفرق، مما يجعل منصات المطورين الداخلية القوية شرطاً مسبقاً للاستفادة من التطوير بمساعدة الذكاء الاصطناعي.

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

التحول التنظيمي: فرق المنصات

تتطلب هندسة المنصات تغييراً تنظيمياً وليس مجرد أدوات تقنية. إن إنشاء فريق منصة مخصص — يمثل عادةً 5 إلى 15% من المنظمة الهندسية — هو شرط أساسي.

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

ملف مهارات مهندس المنصات مميز: خبرة عميقة في البنية التحتية وDevOps مقترنة بتفكير مُنتجي وحسّ تجربة مستخدم وقدرة على بناء أدوات خدمة ذاتية يمكن للمستخدمين غير المتخصصين التعامل معها. هذا المزيج نادر وذو قيمة عالية — تحمل أدوار هندسة المنصات علاوات رواتب تتراوح بين 15 و25% مقارنة بأدوار DevOps المماثلة في 2026، بمتوسط تعويض يبلغ حوالي 172,000 دولار لمهندس المنصات مقارنة بنحو 143,000 دولار لمهندس DevOps.

المخاطرة التنظيمية هي خلق “اختناق فريق المنصة” الذي يحل محل “اختناق فريق العمليات” القديم — حيث يُحظر المطورون في انتظار ميزات المنصة بدلاً من انتظار الدعم التشغيلي. تتجنب فرق المنصات الناجحة ذلك من خلال بناء قدرات خدمة ذاتية لا تتطلب تدخل فريق المنصة للمهام الروتينية، مع تخصيص وقت فريق المنصة لبناء قدرات جديدة ومعالجة الحالات الاستثنائية.

مشهد الموردين

يتطور مشهد موردي هندسة المنصات بسرعة، حيث يُطلق مزودو الخدمات السحابية منتجات ويسحبون أخرى مع نضوج السوق:

Humanitec يوفر Platform Orchestrator تجارياً — إلى جانب محركات مفتوحة المصدر ومواصفة أحمال العمل Score — يفصل سير عمل المطورين عن تكوينات مستوى البنية التحتية، مما يُمكّن فرق المنصات من بناء منصات مطورين داخلية دون البدء من الصفر. متاح عبر AWS Marketplace وGoogle Cloud Marketplace.

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

AWS أطلقت AWS Proton لقوالب البنية التحتية، لكنها أعلنت إيقافه في 2025 (ينتهي الدعم في أكتوبر 2026)، مع التوصية بالانتقال إلى CloudFormation Git Sync أو Harmonix On AWS — مما يوضح سرعة تحول مشهد الموردين. Azure يقدم Azure Deployment Environments لتجهيز البنية التحتية بالخدمة الذاتية، بينما ينتقل Microsoft Dev Box (بيئات التطوير بالخدمة الذاتية) إلى Windows 365 اعتباراً من أواخر 2025. GCP يدعم Backstage عبر إضافات مجتمعية لـ Cloud Build وGCP Projects وCloud Storage، وتُستخدم بنيته التحتية (GKE وCloud Run وCloud SQL) بشكل شائع لاستضافة نسخ Backstage.

GitLab وGitHub يُدمجان قدرات هندسة المنصات مباشرة في منصاتهما — GitHub Actions كـ CI/CD بالخدمة الذاتية، ومنصة GitLab لـ DevSecOps كبديل IDP شامل.

ما القادم: المنصات المدعومة بالذكاء الاصطناعي

التقاء هندسة المنصات مع الذكاء الاصطناعي هو الحدود التالية. في عام 2026، تشمل التطبيقات المبكرة:

تجهيز البنية التحتية باللغة الطبيعية: “أنشئ بيئة اختبار لخدمتي مع قاعدة بيانات PostgreSQL وذاكرة تخزين مؤقت Redis” — والمنصة تُولّد وتُنفّذ البنية التحتية ككود (Infrastructure-as-Code) تلقائياً.

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

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

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

المصادر

• Gartner — Platform Engineering Prediction
• Puppet/Perforce — State of DevOps Report 2024
• Stack Overflow — Developer Survey 2025
• DORA — State of DevOps 2024
• DORA — State of DevOps 2025
• Spotify — Backstage Open Source
• CNCF — Backstage Project
• Humanitec — Platform Orchestrator
• Port — Developer Portal Platform
• AWS — AWS Proton End of Support
• Microsoft — Azure Deployment Environments
• Team Topologies — Matthew Skelton & Manuel Pais