الهدف لجميع قادة فريق مطوري البرامج هو العثور على مكان سعيد حيث المطورين يقضون يومهم في التطور ونشر التعليمات البرمجية. يدعم فريق المنصة عمل مطوري البرامج هؤلاء، ويراقب احتياجاتهم ويستجيب لها.
ومع ذلك، فإن وظيفة مطور البرامج اليوم هي أكثر من مجرد كتابة التعليمات البرمجية. بفضل انتشار ديف أوبسيميل مطورو البرامج إلى تحمل مسؤولية كبيرة: فهم يمتلكون تطوير الميزات وإصلاحات الأخطاء وخط أنابيب النشر ومراقبة الأداء والبنية التحتية السحابية وأمان التعليمات البرمجية الخاصة بهم.
تتكيف اتجاهات تطوير البرمجيات باستمرار لمساعدة فرق البرمجيات على مواكبة المتطلبات المتزايدة لمجتمع رقمي متزايد، ويدرك قادة الأعمال قيمة مبادرات الأعمال التي تعتمد على البرمجيات.
يُنظر إلى توفير بوابة مطور داخلية ذاتية الخدمة (IDP) على أنها وسيلة لتقديم تجربة جيدة لمطوري البرامج، الذين يريدون حرية الاختيار من بين مجموعة منسقة من الأدوات والتقنيات لمساعدتهم على كتابة التعليمات البرمجية. النقطة الأساسية هي أن هذه الأدوات “منسقة”. هناك مسارات إرشادية للخدمة الذاتية وتلبي هذه الأدوات المنسقة معايير الشركة للأمن السيبراني وأفضل الممارسات.
توقع المحلل جارتنر أنه بحلول عام 2028، ستوفر 85% من المؤسسات التي لديها فرق هندسة الأنظمة الأساسية IDPs لتحسين تجربة المطورين وتسريع ابتكار المنتجات. تُعرّف Gartner بوابات المطورين الداخلية بأنها أدوات تتيح اكتشاف الخدمة الذاتية والأتمتة والوصول إلى المكونات القابلة لإعادة الاستخدام والأدوات وخدمات النظام الأساسي وأصول المعرفة في بيئات تطوير البرامج الحديثة.
لاحظت شركة التحليل أن هذه البوابات تساعد في تحسين تجربة المطورين وموثوقية الخدمة مع تمكين الإدارة المركزية والرؤية المشتركة عبر فرق متعددة.
يغطي تعريف Gartner لموفر الهوية (IDP) للخدمة الذاتية للمطورين ميزات مثل كتالوجات البرامج وملكيتها ومقاييس الجودة والأمان؛ قوالب السقالات؛ الوثائق المتعلقة بالمنتج والأداة؛ روابط للأدوات والحزم المنسقة؛ وإجراءات الخدمة الذاتية، مثل توفير البيئات وتنفيذ مسارات البيانات.
يقول جارتنر إن IDP يجب أن يوفر مكانًا واحدًا يمكن الذهاب إليه لفرق متعددة والأدوار الوظيفية المختلفة داخل تلك الفرق، لمساعدتهم على فهم الوضع الحالي للنشاط الهندسي الذي يشمل البنية التحتية والتطبيقات والبيئات ومكونات النظام الأساسي وملكيتهم عبر المؤسسة.
يبدو مثل هذا التنظيم للأصول اللازمة لتطوير البرمجيات بسرعة وكفاءة وأمان بمثابة خطوة منطقية في الاتجاه الصحيح. ولكن كما ماندي وولز، مناصرة DevOps في PagerDutyيلاحظ أن جعل الأمر يعمل ليس بالأمر السهل. مع كل تكرار لنموذج تطوير البرمجيات، ستكون هناك مشاكل في مرحلة التأسيس، حيث تتعارض الأدوات الجديدة مع الأساليب التقليدية والإدارة والممارسات الثقافية.
وتقول: “يجب على الفرق التي تنطلق في رحلتها نحو نماذج تطوير الخدمة الكاملة أن تنتقل بعناية من عملية “نحن ننشر” التي تعتمد على العمليات إلى نموذج “أنت تنشر، ونحن نراقب” الذي يقوده المطورون”.
في تجربتها في مراقبة الشركات من جميع الأحجام والأنواع وهي تقوم بعملية التحول، لاحظت وولز أن هندسة النظام الأساسي والموثوقية بحاجة إلى التطور معًا لتمكين المطورين مع ضمان الجهوزية والثقة بأي ثمن.
في الواقع، ترى جارتنر أن فرق هندسة المنصات تتحمل مسؤولية توفير بوابة الخدمة الذاتية للمطورين لفرق تطوير المنتجات. وقد يتم توفيره إما كمنصة مستقلة أو كمكونات متكاملة لمنصات DevOps ومنصات المطورين الداخلية الأوسع.
في حين أن بعض الأصوات في الصناعة تدعي أن هندسة المنصات تضيف تعقيدًا غير ضروري أو تعيد السيطرة على مركزيتها، فإن المشكلة الحقيقية بالنسبة إلى وولز هي التوازن.
وتقول: “لا ينبغي حماية المطورين من السياق التشغيلي وبيئات النشر. إن فهم حقائق الإنتاج يؤدي إلى برامج أفضل وأكثر مرونة. فكر في الأمر مثل تصميم سيارة دون رؤية الطريق على الإطلاق – وهذا من شأنه أن يجعل من الصعب توقع الأداء، أو التآكل، أو السلامة في الحياة الواقعية”.
ووفقا لوولز، فإن هندسة المنصات التي تتم بشكل صحيح تمكن من تحقيق الاستقلالية الإنتاجية، وليس الجهل. وتقول: “يحتاج الفريق المنتج والمرن إلى معرفة بيئات الإنتاج للاستفادة من جميع الموارد والميزات المتاحة التي تقدمها”.
يجب أن يتم تصميم الموثوقية، وليس إضافتها لاحقًا
بالنسبة إلى وولز، لا ينبغي أن يكون هدف الخدمة الذاتية مجرد التسليم الأسرع – بل يجب أن يكون التسليم المستدام. إنها ترى الموثوقية كرياضة جماعية حيث يمتلك المطورون الكود الخاص بهم في الإنتاج ويوفر مهندسو المنصات الأدوات وحواجز الحماية والقياس عن بعد. يضمن مهندسو الموثوقية أن النظام بأكمله يلبي أهداف واتفاقيات مستوى الخدمة. وبدون ممارسات الموثوقية المضمنة، يحذر وول من أن الخدمة الذاتية يمكن أن تؤدي بسرعة إلى زيادة التحميل التشغيلي وإرهاق التنبيه.
نظرًا لأن الخدمة الذاتية للمطورين أصبحت هي القاعدة، لم تعد الموثوقية موجودة في صومعة العمليات فقط. ستكون المؤسسات الأكثر نجاحًا هي تلك التي تجعل الاستعداد التشغيلي ووقت التشغيل المستمر جزءًا من تجربة المطور نفسها
جدران ماندي، PagerDuty
وتقول: “النقطة المهمة هي أن تشمل الخدمة الذاتية الحقيقية إمكانية الملاحظة والتنبيه وسير العمل بالحوادث من اليوم الأول”.
يعتقد وولز أن الموثوقية هي مهمة الجميع. وتقول: “نظرًا لأن الخدمة الذاتية للمطورين أصبحت هي القاعدة، لم يعد من الممكن أن تعيش الموثوقية في صومعة العمليات فقط. وستكون المؤسسات الأكثر نجاحًا هي تلك التي تجعل الاستعداد التشغيلي ووقت التشغيل المستمر جزءًا من تجربة المطور نفسها”.
للموثوقية آثار على الخدمة الذاتية للمطورين، والتي، وفقًا لولز، لا ينبغي أن تؤخذ على أنها تعني “الجميع لأنفسهم”. وتقول: “المسؤولية المشتركة مدعومة بعملية قوية وواضحة. ويمكن أن تتعايش الحوكمة والجاهزية مع حرية المطورين”.
وكما يشير وولز، فإن هذا يعني ملكية محددة بوضوح، ومن هو تحت الطلب ومن يحافظ على ماذا، طبقة بعد طبقة. وتوصي بمشاركة نتائج التشريح بعد الوفاة، واستعراضات الموثوقية، وما شابه ذلك بين جميع الفرق.
يقترح PagerDuty نموذجًا لمنصات الخدمة الذاتية للمطورين حيث تحول عمليات تكنولوجيا المعلومات وفرق النظام الأساسي التركيز من تنفيذ عمليات النشر إلى مراقبتها ودعمها. تقول الجدران أن هذا يتطلب:
لوحات معلومات مركزية لإمكانية المراقبة من أجل الوعي الظرفي الموحد.
توجيه التنبيه الآلي بناءً على ملكية الخدمة.
رؤية الحوادث في الوقت الحقيقي وتنسيق الاستجابة.
أفضل الممارسات المنسقة عبر المؤسسة فيما يتعلق بالتنبيهات ورسائل السجل والقياس عن بعد لتعزيز إمكانية المراقبة عبر الخدمات.
وتضيف: “إذا كنت تريد حقًا تمكين المطورين من امتلاك خدماتهم دون عزلهم، فيجب أن يكون التعاون مدمجًا في إمكانية المراقبة”.
التأكيد على التغيير الإجرائي
جنبًا إلى جنب مع التغييرات في عمليات تكنولوجيا المعلومات وفرق هندسة النظام الأساسي، مات سوندرز، نائب رئيس DevOps في Adaptavistيقول مطور البرمجيات إن الخدمة الذاتية تتطلب أيضًا تغييرًا تنظيميًا وثقافيًا.
حتى أفضل أدوات المطورين لن يكون لها التأثير الذي تريده دون إجراء تغييرات ثقافية وإجرائية دقيقة
مات سوندرز، خبير التكيف
“لكي تنجح أدوات الخدمة الذاتية، يجب أن ترغب فرق التطوير في استخدامها. وبالمثل، فإن الفرق التي تنجح في بناء أدوات المطورين تجري أبحاثًا مناسبة للمستخدم، وتحدد أولويات الميزات وتقدم الدعم المستمر،” كما يقول.
“تستخدم فرق النظام الأساسي الناجحة نهجًا تكراريًا مستمرًا، حيث تعامل المطورين كعملاء مناسبين وترفض السماح لهذا العمل بأن يكون مشروعًا جانبيًا. كما يقومون أيضًا بقياس التبني بعناية، وإيقاف الميزات غير المستخدمة وإجراء تحسينات متعمدة بناءً على السلوك الملحوظ، وليس الافتراضات.”
بالنسبة لسوندرز، تصبح قاعدة المعرفة المشتركة المتوفرة من خلال منصات المطورين الداخلية أصلًا حيًا يتوسع بشكل أفضل بكثير من الدعم المخصص أو المعرفة القبلية غير الموثقة. لكن إدارة التغيير أمر أساسي.
ويضيف: “حتى أفضل أدوات المطورين لن يكون لها التأثير الذي تريده دون إجراء تغييرات ثقافية وإجرائية دقيقة. إن ضمان وجود توافق ثقافي، وضبط سير العمل وعمليات صنع القرار لتمكين ذلك، لا يقل أهمية عن الأدوات المستخدمة في بناء منصة ناجحة”.
اعتماد الذكاء الاصطناعي المؤسسي
نظرًا لكل الضجيج الذي تشهده الصناعة حول استخدام الذكاء الاصطناعي (AI) في المؤسسة، فإن فرق تطوير البرمجيات تشعر بالقلق من التعقيد الذي يضيفه الذكاء الاصطناعي إلى بناء تطبيقات المؤسسة.
تشير دراسة أجرتها مؤسسة Gartner إلى أن مطوري البرامج يشعرون بالقلق من أن بناء قدرات الذكاء الاصطناعي في التطبيقات يمثل تحديًا كبيرًا. وهذا، وفقًا لشركة Gartner، هو سبب الاهتمام الكبير بالأشخاص النازحين داخليًا في المؤسسات الكبيرة، والتي تستخدمهم لتقديم أدوات منسقة ومكونات قابلة لإعادة الاستخدام وتوصيات سير العمل القياسية.
من خلال تمكين اكتشاف الخدمة الذاتية والوصول إلى نماذج الذكاء الاصطناعي وأطر التنسيق وأدوات المراقبة ومنصات ModelOps، تشير Gartner إلى أن هذه الإمكانات تعني أن IDP يمكنه مساعدة فرق متعددة على التنقل في التعقيد الفني لبناء قدرات GenAI.
ومع ذلك، وفقا لشركة جارتنر خارطة طريق لاعتماد التكنولوجيا في المؤسسات الكبيرة لعام 2025يعد عدم التوافق الفني أو تعقيد البنية عامل الخطر الأساسي الذي يؤثر على الاعتماد الناجح لبوابات المطورين الداخلية.
وهذا يعني أن الخدمة الذاتية في تطوير البرمجيات، من خلال IDP، من المرجح أن تصبح أكثر انتشارًا مع نمو الذكاء الاصطناعي المؤسسي والحاجة إلى فرق البرمجيات لبث الذكاء الاصطناعي في أنظمة تكنولوجيا المعلومات للشركات. ولكن، بغض النظر عن مدى تعقيد بناء تطبيقات الذكاء الاصطناعي، فإن طرح IDP للخدمة الذاتية لمطوري البرامج هو أول حجر عثرة من المحتمل أن يواجهه العديد من قادة تكنولوجيا المعلومات في المؤسسات.
