من DevOps إلى هندسة المنصات

من DevOps إلى هندسة المنصات

لقد نجحت حركة DevOps. خطوط أنابيب CI/CD، والبنية التحتية كأكواد، والأحمال العمل في حاويات، وGitOps، ومنظومات الرصد والمراقبة — أصبحت هذه الممارسات متطلبات أساسية في أي منظمة هندسية جادة. لكن مع انتشار التبني من عدد قليل من الفرق النخبوية إلى مئات أو آلاف من فرق المنتجات، ظهرت مشكلة جديدة. الأدوات نجحت. الممارسات كانت سليمة. غير أن الإيصال كان أبطأ مما هو متوقع، والحوادث لا تزال متكررة، والمهندسون ينهكون — ليس لأن التقنية كانت رديئة، بل لأن كل فريق كان يعيد اختراع العجلة ذاتها.

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

هذه هي المشكلة التي تعالجها هندسة المنصات. إنها ليست بديلاً لـ DevOps — بل هي التطور المنطقي التالي حين تصل ممارسات DevOps إلى النطاق التنظيمي.

مشكلة العبء المعرفي

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

فكّر في فريق يبني واجهة برمجة مدفوعات. عبؤه الجوهري ثقيل بالفعل: متطلبات PCI-DSS، ودلالات المعاملات المالية، وضمانات أحادية التأثير، وتكامل اكتشاف الاحتيال، وحالات حافة متعددة العملات. والآن أضف: صيانة وحدات Terraform الخاصة بهم، وتهيئة mTLS بين الخدمات، وإعداد شاشات وتنبيهات Datadog من الصفر، وكتابة سير عمل GitHub Actions الخاص بهم، وإدارة بيانات اعتماد Vault AppRole، وتدوير شهادات TLS. لا شيء من تلك المهام البنية التحتية متعلق بالمجال الذي وُظّف الفريق لفهمه. كل منها عبء خارجي — ويتراكم.

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

فكرة المنصة كمنتج

التحول الذي يُميز هندسة المنصات عن عمليات البنية التحتية التقليدية هو النموذج الذهني للمنصة باعتبارها منتجاً — أحد عملائه هم فرق الهندسة الداخلية. هذه ليست استعارة. لها عواقب تشغيلية مباشرة.

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

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

كيف تختلف هندسة المنصات عن فرق المنصات التقليدية

كان لدى معظم منظمات الهندسة الكبيرة بالفعل ما يُسمى "فريق المنصة" قبل أن تصبح هندسة المنصات تخصصاً متميزاً. الفرق يكمن في التوجه في الغالب. كانت فرق المنصات أو البنية التحتية التقليدية تركّز داخلياً — تمتلك الأنظمة، وتتحكم في الوصول، وتُقدّم فرق المنتجات تذاكر لإنجاز الأمور. كان فريق المنصة بمثابة بوابة، لا مُمكِّن. تعكس هندسة المنصات هذا: الهدف هو أقصى قدر من الخدمة الذاتية. يبني فريق المنصة وحدات أولية ومسارات ذهبية؛ وتستهلكها فرق المنتجات بشكل مستقل دون تقديم تذاكر.

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

أين تُرسم الحدود: مسؤوليات فريق المنصة

يمتلك فريق المنصة الناضج عادةً مساحة السطح التالية، وإن كانت الحدود الدقيقة تتفاوت بحسب المنظمة:

• بوابات المطورين وكتالوجات الخدمات — الباب الأمامي للمنصة الداخلية (مثل Backstage). تُسجّل الفرق الخدمات، وتستهلك قوالب المسارات الذهبية، وتكتشف واجهات برمجية داخلية هنا.
• قوالب CI/CD للمسار الذهبي — سير عمل GitHub Actions قابلة لإعادة الاستخدام، وقوالب ApplicationSet في ArgoCD، وخطوط أنابيب Tekton. يستنسخ الفريق قالباً ويحصل على خط أنابيب جاهز للإنتاج مع SAST وفحص الحاويات وتوليد SBOM وبوابات النشر دون كتابة سطر واحد من YAML خاص بخط الأنابيب من الصفر.
• البنية التحتية ذاتية الخدمة — وحدات Terraform أو تركيبات Crossplane تسمح للفرق بتوفير قواعد بيانات أو قوائم انتظار أو مساحات أسماء Kubernetes عبر ملف YAML manifest أو واجهة مستخدم بوابة، دون لمس الحساب السحابي الأساسي. فريق المنصة يمتلك الوحدة؛ فريق المنتج يمتلك النسخة.
• خط أساسي للرصد والمراقبة — إعدادات سحب Prometheus الافتراضية، وقوالب لوحة قيادة Grafana، واصطلاحات تسجيل منظمة، ونشر جامع OpenTelemetry الذي تحصل عليه كل خدمة مجاناً. تختار الفرق الأدوات الإضافية بدلاً من البدء من الصفر.
• ضمانات الأمان — سياسات قبول OPA/Gatekeeper، وسياسات الشبكة الافتراضية، وأنماط تكامل Vault، وخطافات فحص الأسرار في CI. الأمان مُرمَّز في المنصة بحيث تمتثل الفرق بشكل افتراضي، لا بجهد.

قياس نجاح المنصة: DORA وما بعده

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

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

علاوةً على DORA، تتتبع فرق المنصات:

• معدل تبني المنصة — ما النسبة المئوية من فرق المنتجات على الطريق الذهبي مقابل الذين يحتفظون ببنية تحتية مخصصة؟
• تذاكر التوليد لكل فريق شهرياً — احتكاك المنصة يظهر كتذاكر دعم؛ يجب أن يتراجع هذا مع مرور الوقت.
• الوقت حتى أول نشر (TTFD) — كم من الوقت لخدمة جديدة للوصول إلى الإنتاج لأول مرة؟
• NPS المطورين — استطلاع ربع سنوي يسأل المهندسين عن مدى احتمالية توصيتهم بالمنصة الداخلية. البيانات النوعية تكشف نقاطاً عمياء تفتقدها المقاييس.

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

في نموذج Team Topologies، تكون معظم فرق المنتجات فرقاً محاذية للتدفق — تمتلك تدفق قيمة من البداية إلى النهاية (ميزة منتج، أو خدمة مصغرة، أو رحلة عميل). فرق المنصات هي نوع منفصل من الفرق — توجد لتقليل العبء المعرفي للفرق المحاذية للتدفق، لا لامتلاك أنظمة الإنتاج مباشرةً. لهذا الفصل تضمين مهم: يجب ألا يصبح فريق المنصة تبعية على المسار الحرج لتسليم الفريق المحاذي للتدفق. إذا كان على فريق المنتج انتظار فريق المنصة للموافقة على نشر أو تنفيذه، فقد فشلت المنصة في غرضها. الهدف دائماً هو الخدمة الذاتية.

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