مقدمة

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

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

مشكلة الحمل المعرفي

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

يعطي إطار عمل Team Topologies المؤثر، الذي طوّره Matthew Skelton وManuel Pais، هذه المشكلة اسمًا - الحمل المعرفي الدخيل - ويجادل صراحة بأن الغرض المركزي لمنصة داخلية مصممة جيدًا هو تقليل هذا النوع بالضبط من الحمل على ما يُسميه الإطار الفرق المُحاذاة مع التدفق، الفرق المسؤولة مباشرة عن تسليم القيمة للمستخدمين النهائيين. الهدف ليس إلغاء ملكية المطورين لما يبنونه ويشغّلونه، بل منحهم الملكية عبر واجهات تُخفي التعقيد العرضي - التعقيد العارض لصيغة YAML الخاصة بـKubernetes أو غرائب واجهة برمجة تطبيقات مزود السحابة - مع الحفاظ على رؤيتهم وسيطرتهم على التعقيد الجوهري الخاص فعليًا بمنطق عمل تطبيقهم وسلوكه.

ما توفره منصة مطورين داخلية ناضجة

تتمحور منصة مطورين داخلية ناضجة عادة حول بوابة ذاتية الخدمة أو واجهة سطر أوامر تتيح للمطور تخصيص الموارد التي يحتاجها - خدمة جديدة، قاعدة بيانات، طابور رسائل، خط أنابيب CI/CD - عبر واجهة بسيطة وذات رأي، بدلاً من الحاجة لكتابة Terraform أو بيانات Kubernetes الخام بأنفسهم. أصبحت Backstage، المنصة مفتوحة المصدر التي طُوِّرت أصلاً في Spotify وتستضيفها الآن مؤسسة الحوسبة السحابية الأصيلة، تطبيقًا مرجعيًا مؤثرًا بشكل خاص لهذا النمط، توفر كتالوج برمجيات يمنح كل فريق رؤية لما يوجد من خدمات عبر المؤسسة ومن يملكها وكيفية توثيقها، إلى جانب نظام قوالب يتيح للمطورين هيكلة خدمة جديدة مُهيَّأة بالكامل - كاملة مع CI/CD والمراقبة وتخصيص البنية التحتية - خلال دقائق بدلاً من الأيام أو الأسابيع.

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

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

المنصة كمنتج، لا كتفويض

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

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

قياس نجاح المنصة

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

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

دراسة حالة: رحلة Spotify مع Backstage

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

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

الخاتمة

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