أخبار التقنية

تطور DevOps: لماذا تكتسب هندسة النظام الأساسي زخماً


الفكرة وراء DevOps هي أنها تجمع بين عمليات التطوير وتكنولوجيا المعلومات – Dev وOps – لتسهيل إنشاء البرامج ونشرها. تعتمد هندسة النظام الأساسي على ذلك من خلال فريق مكون من مديري المنتجات والمهندسين، الذين يقومون بإنشاء وصيانة البنية التحتية المشتركة التي يحتاجها المطورون.

ويتوقع المحلل التكنولوجي جارتنر أنه بحلول عام 2026، 80٪ من مؤسسات هندسة البرمجيات سيتم إنشاء فرق المنصة كمقدمين داخليين للخدمات والأدوات القابلة لإعادة الاستخدام لتوصيل التطبيقات.

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

ووجدت أن فريق المنصة أصبح مسؤولاً عن “إطفاء الحرائق بشكل عام، وبناء وتنفيذ العمليات الأمنية”.

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

الدفاع عن الأمن في الداخل

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

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

وبالنظر إلى النتائج على نطاق أوسع، فإن زيادة سرعة تسليم المنتج كانت الهدف الأسمى للشركات التي تتبنى هندسة المنصات، يليها تحسين الأمان والامتثال. قال ما يقرب من النصف (43٪) إن عمر فريقهم يتراوح بين ثلاث وخمس سنوات؛ على الرغم من أن ربعهم قالوا إن عمر فريقهم يتراوح بين ستة وتسعة أعوام، وقال 17% منهم إن عمر فريقهم يبلغ من العمر عامًا إلى عامين تقريبًا.

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

وتابعت: “يمكن لهندسة المنصات أن تكون بمثابة حاجز ضد فوضى الأدوات والمهام والمعلومات”. “من خلال توحيد الأدوات والعمليات، يمكن أن يحرر المطورين من عبء أن يصبحوا خبراء في الأدوات حتى يتمكنوا من التركيز على نقاط قوتهم الأساسية: كتابة تعليمات برمجية رائعة.”

غالبًا ما تتعاون فرق هندسة المنصات جنبًا إلى جنب مع الهندسة والعمليات أو داخلها، لكن موقعهم داخل المؤسسة يمكن أن يختلف اعتمادًا على نطاق الدعم الخاص بهم. وفي حين قال 23% من المشاركين إن فريق هندسة المنصة كان فريقاً منفصلاً تحت الهندسة، قال 22% إنه كان ضمن فريق العمليات، وقال 21% إنه كان ضمن الفريق الهندسي، بينما قال 14% إنه كان ضمن فريق المنتج.

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

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

في حين قال ما يزيد قليلاً عن النصف أن مدير المنتج أمر بالغ الأهمية لتحقيق النجاح، وصفه 21% بأنه من الجيد أن يكون لديك، وقال 18% إنه مهم ولكنه ليس حاسماً، وقال 9% إنه ليس ضرورياً.

ويبدو أن هذا المفهوم لا يقتنع به الجميع، على الأقل حتى الآن. ووجد الاستطلاع أن 65% من المشاركين قالوا إن فريق هندسة المنصة كان “مهمًا ويتلقى استثمارًا مستمرًا”. لكن 16% وصفوه بأنه “مشروع عاطفي”، ووصفه 12% بأنه “اختبار تجريبي” حيث يعتمد الاستثمار المستقبلي على نجاحه أو فشله.

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

وأوضح أن “معظم المؤسسات تدرك التأثير الذي يمكن أن يحدثه فريق المنصة على عملياتها”. “هناك قوة في الاتساق بين الفرق وكيفية تعاملهم مع عملهم. كلما زاد الاتساق بين الفرق والأدوات والعمليات، أصبحت البنية التحتية الخاصة بك أكثر أمانًا وفعالية وتوحيدًا. قامت شركة Puppet باستطلاع رأي 500 متخصص في مجال التكنولوجيا يعملون مع أو ضمن فريق منصة.

مارغريت ليقال، مدير إدارة المنتجات في Puppet by Perforce، إن هندسة المنصات هي تطور طبيعي وليست بديلاً. وقالت لمجلة Computer Weekly: “إننا نشهد الآن تحقيق فوائد الأتمتة على مستوى المؤسسة، مع كون الخدمة الذاتية جزءًا أساسيًا منها”. “في السابق، كانت الأتمتة على مستوى الفرد أو الفريق. لقد تطورت إلى المستوى التنظيمي حيث يمكن أن تساعد فوائد التوحيد والأتمتة في تقليل العبء المعرفي وزيادة إنتاجية المطورين.

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



Source link

زر الذهاب إلى الأعلى