حول المسؤولين والمطورين والارتباك الذي لا نهاية له وتحول DevOps داخل الشركة

حول المسؤولين والمطورين والارتباك الذي لا نهاية له وتحول DevOps داخل الشركة

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

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

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

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

نعني بالبنية التحتية الخارجية كل ما يضمن أداء الخدمة أو المنتج الذي يقوم الفريق بتطويره. هذه هي خوادم التطبيقات أو مواقع الويب والاستضافة والخدمات الأخرى التي تضمن عمل المنتج.

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

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

من هم DevOps؟ Devops هم الأشخاص الذين يتحدثون عن تفاعل تطوير البرمجيات مع البنية التحتية الخارجية. وبشكل أكثر دقة، يشارك المطورون المعاصرون في عمليات التطوير والنشر بشكل أعمق بكثير من مشاركة المسؤولين الذين قاموا ببساطة بتحميل التحديثات إلى بروتوكول نقل الملفات. تتمثل إحدى المهام الرئيسية لمهندس DevOps الآن في ضمان عملية تفاعل مريحة ومنظمة بشكل فعال بين فرق التطوير والبنية التحتية للمنتج. هؤلاء الأشخاص هم المسؤولون عن نشر أنظمة التراجع والنشر، وهؤلاء الأشخاص هم الذين يأخذون بعض العبء عن كاهل المطورين ويركزون قدر الإمكان على مهمتهم بالغة الأهمية. في الوقت نفسه، لن يقوم المطورون مطلقًا بتشغيل كابل جديد أو إصدار كمبيوتر محمول جديد من الغرفة الخلفية (ج) KO

ما هي الفائدة؟

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

ولكن ماذا يعني هذا بالنسبة للأعمال؟

التوظيف، كل شيء عن ذلك.

قمت بفتح وظيفة شاغرة لـ "مسؤول النظام"، والمتطلبات المذكورة هناك هي "التفاعل مع التطوير والعملاء"، و"نظام توصيل CI/CD"، و"صيانة خوادم الشركة ومعداتها"، و"إدارة الأنظمة الداخلية" وما إلى ذلك. على؛ أنت تفهم أن صاحب العمل يتحدث هراء. المهم هو أنه بدلاً من "مسؤول النظام" يجب أن يكون المسمى الوظيفي "DevOps Engineer"، وإذا تم تغيير هذا المسمى، فإن كل شيء يقع في مكانه الصحيح.

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

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

لا لا ومرة ​​أخرى لا. إن مسؤولي البنية التحتية الذين سيديرون الخوادم الداخلية للشركة، أو يشغلون مناصب دعم L2/L3 ويساعدون الموظفين الآخرين، لم يختفوا ولن يرحلوا.

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

مشكلة DevOps أخرى

في الواقع، لا يقتصر كل شيء على مجرد التوظيف والارتباك المستمر بين المسؤولين والمطورين. في مرحلة ما، واجهت الشركة مشكلة تقديم التحديثات وتفاعل فريق التطوير مع البنية التحتية النهائية.

ربما كان ذلك عندما وقف عم ذو عيون متلألئة على خشبة أحد المؤتمرات وقال: "نحن نفعل هذا ونطلق عليه اسم DevOps. هؤلاء الرجال سيحلون جميع مشاكلك" - وبدأوا في الحديث عن مدى جودة الحياة في الشركة بعد تطبيق ممارسات DevOps.

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

الموقف. مطلوب DevOps لنشر نظام التراجع عن الإصدار دون الخوض في كيفية عمله. لنفترض أنه يوجد داخل نظام المستخدمين حقول منفصلة للاسم الأول واسم العائلة وكلمة المرور. يتم إصدار نسخة جديدة من المنتج، ولكن بالنسبة للمطورين، فإن "التراجع" هو مجرد عصا سحرية ستصلح كل شيء، وهم لا يعرفون حتى كيف تعمل. لذلك، على سبيل المثال، في التصحيح التالي، قام المطورون بدمج حقلي الاسم الأول والأخير، وطرحوه في الإنتاج، ولكن الإصدار بطيء لسبب ما. ماذا يحدث؟ تأتي الإدارة إلى المطورين وتقول "اسحب المفتاح!"، أي تطلب منه العودة إلى الإصدار السابق. ماذا يفعل المطورون؟ إنه يعود إلى الإصدار السابق، ولكن نظرًا لأن المطورين لم يرغبوا في معرفة كيفية إجراء هذا التراجع، لم يخبر أحد فريق المطورين أن قاعدة البيانات تحتاج أيضًا إلى التراجع. ونتيجة لذلك، يتعطل كل شيء بالنسبة لنا، وبدلاً من موقع الويب البطيء، يرى المستخدمون الخطأ "500"، لأن الإصدار القديم لا يعمل مع حقول قاعدة البيانات الجديدة. Devops لا يعرف عن هذا. المطورين صامتون. تبدأ الإدارة في فقدان أعصابها وأموالها وتتذكر النسخ الاحتياطية، وتعرض التراجع عنها حتى "يعمل شيء ما على الأقل". ونتيجة لذلك، يفقد المستخدمون جميع بياناتهم خلال فترة زمنية.

تذهب المكسرات، بالطبع، إلى Devops، والتي "لم تصنع نظام التراجع المناسب"، ولا أحد يهتم بأن الموس في هذه القصة هم مطورون.

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

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

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

المصدر: www.habr.com

إضافة تعليق