نضج هندسة المنصات لا يقاس بوجودها بل بمدى الخدمة الذاتية التي تقدمها

يرى Atulpriya Sharma، بصفته CNCF Ambassador ومنظّم Platform Engineering TCG، أن السؤال الأهم في هندسة المنصات ليس ما إذا كانت المؤسسة قد بنت منصة، بل كيف يتفاعل المطورون فعلياً مع قدراتها. فالمؤسسات التي لا تملك منصة رسمية بعد تعتمد غالباً على السكربتات المتناثرة والمعرفة الفردية، بينما قد تملك مؤسسات أخرى بوابة مطورين وواجهة CLI ومسارات جاهزة، لكنها لا تزال تعالج الطلبات يدوياً. في الحالتين، تكمن المشكلة في نضج الواجهة التي تستهلك عبرها الفرق قدرات المنصة.

تستند المادة إلى نموذج نضج هندسة المنصات من CNCF، الذي يقيس خمسة جوانب بصورة مستقلة: الاستثمار، والتبني، والواجهات، والعمليات، والقياس. ولكل جانب أربعة مستويات هي: المؤقت، والتشغيلي، والقابل للتوسع، والتحسيني. ولا تنتقل المؤسسة وفق النموذج كوحدة واحدة؛ إذ يمكن أن تتقدم في جانب بينما تبقى متأخرة في جانب آخر. ويركز التحليل على جانب الواجهات، أي النماذج وواجهات CLI والبوابات وواجهات API التي يستخدمها المطورون.

أربع مراحل لواجهة المنصة

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

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

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

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

لماذا تتوقف المؤسسات عند المستوى الثاني؟

يحدد التحليل أربع مشكلات متكررة. الأولى هي مشكلة الطوابير: تغطي المسارات الذهبية الحالات الشائعة، لكن الحالات الاستثنائية قد تمثل 30% من العمل في المؤسسات الكبيرة. ويورد الكاتب مثالاً لمنظمة تجزئة استخدمت مساراً ذهبياً لنشر Kubernetes عبر Helm charts وArgoCD، فبلغ التبني 85% خلال ستة أشهر، لكن تراكمت 40 حالة استثناء وأصبح الفريق ينفق 60% من وقته على إعدادات خارج المسار.

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

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

ما الذي يتغير عملياً؟

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

ومن المستوى الثاني إلى الثالث، يجب التوقف عن كون فريق المنصة حلقة بشرية إلزامية. ويتطلب ذلك جعل المسارات الذهبية قابلة للضبط، مع خيارات متحقق منها وقيود تفرضها السياسات بدلاً من القيم الصلبة، مع توفير مخارج للحالات المشروعة. كما يوصي التحليل بقياس الطلبات قبل أتمتتها؛ ففي مثال من قطاع الإعلام، أدى تسجيل الطلبات ثلاثة أشهر إلى اكتشاف أن 20% من أنواع الطلبات تمثل 80% من الحجم، فبُنيت الخدمة الذاتية لهذه الأنماط أولاً وانخفض التراكم 60% خلال ستة أشهر.

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

قراءة certi.news

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

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