ما هو المطلوب لنجاح شركة تكنولوجيا المعلومات في عام 2019؟ المحاضرون في konfs و mitaps يتحدث الكثير من الكلمات الصاخبة وليس دائما واضحة للناس العاديين. النضال من أجل النشر ، والخدمات المصغرة ، ورفض المتراصة ، وتحول DevOps وأكثر من ذلك بكثير. إذا تجاهلت الجمال اللفظي وتحدثت مباشرة والروسية ، فإن الأمر كله يتعلق بفكرة بسيطة: صنع منتج عالي الجودة ، والقيام به مع الراحة للفريق.
هذا الأخير أصبح مهم للغاية. توصلت Business أخيرًا إلى نتيجة مفادها أن عملية التطوير المريحة تعمل على تحسين الإنتاجية ، وإذا تم تصحيح كل شيء ويعمل كالساعة ، فإنه يوفر أيضًا مجالًا للمناورة في المواقف الحرجة. مرة واحدة ، من أجل هذه المناورة ، ابتكر شخص ذكي نسخًا احتياطيًا ، لكن الصناعة تتطور ، وتوصلنا إلى مهندسي DevOps - أشخاص يحولون عملية التفاعل بين التطوير والبنية التحتية الخارجية إلى شيء مناسب ولا يتعلق بالشامانية.
القصة بأكملها من "modulo" جميلة ، لكن ... حدث أن جزءًا من المشرفين كانوا يطلق عليهم اسم DevOps فجأة ، وبدأ مهندسو DevOps أنفسهم في طلب مهارات التخاطر والاستبصار على الأقل.
قبل الحديث عن المشكلات الحديثة لتوفير البنية التحتية ، دعونا نقرر ما نعنيه بهذا المصطلح. حتى الآن ، تطورت الحالة بطريقة توصلنا إليها إلى ازدواجية هذا المفهوم: يمكن أن تكون البنية التحتية خارجية مشروطة وداخلية مشروطة.
يجب أن تعني البنية الأساسية الخارجية كل ما يضمن قابلية الخدمة لخدمة أو منتج يقوم الفريق بتطويره. هذه هي خوادم التطبيقات أو المواقع ، وخدمات الاستضافة وغيرها من الخدمات التي تضمن أداء المنتج.
تشمل البنية التحتية الداخلية الخدمات والمعدات التي يستخدمها فريق التطوير نفسه وغيره من الموظفين ، والتي عادة ما يكون هناك الكثير. هذه هي خوادم داخلية لأنظمة تخزين الأكواد ومدير مهام تم نشره محليًا وكل شيء وكل شيء موجود داخل إنترانت الشركة.
ماذا يفعل مسؤول النظام في الشركة؟ بالإضافة إلى إدارة هذه الشبكة الداخلية للشركات نفسها ، فإنها غالبًا ما تتحمل عبء المخاوف الاقتصادية لضمان توفر المعدات المكتبية. المسؤول هو نفس الشخص الذي يسحب بسرعة وحدة نظام جديدة خارج الغرفة الخلفية أو كمبيوتر محمول احتياطي جاهز للعمل ، ويقدم لوحة مفاتيح جديدة ويزحف على أربع جولات حول المكاتب ، ويمتد خارج كابل إيثرنت. المسؤول هو المالك المحلي والسيد ليس فقط للخوادم الداخلية والخارجية ، ولكن أيضًا مسؤول تنفيذي في مجال الأعمال. نعم ، يمكن لبعض المسؤولين العمل فقط في مستوى النظام ، بدون أجهزة. يجب تمييزها في فئة فرعية منفصلة من "مسؤولي نظام البنية التحتية". وشخص متخصص في صيانة المعدات المكتبية على وجه الحصر ، لحسن الحظ ، إذا كان لدى الشركة أكثر من مائة شخص ، فإن العمل لا ينتهي أبدًا. لكن لا أحد ولا الآخرون لا.
ومن هم ديفوبس؟ Devops هم الرجال الذين يتحدثون عن تفاعل تطوير البرمجيات مع البنية التحتية الخارجية. بتعبير أدق ، تشارك برامج التطوير الحديثة في عمليات التطوير والنشر أعمق بكثير من المسؤولين الذين شاركوا في تحديث التحديثات على بروتوكول نقل الملفات. تتمثل إحدى المهام الرئيسية لمهندس DevOps الآن في ضمان عملية تفاعل مريحة ومبنية بكفاءة بين فرق التطوير والبنية الأساسية للمنتج. هؤلاء الأشخاص هم المسؤولون عن نشر أنظمة الاستعادة والنشر ، هؤلاء الأشخاص هم الذين يشاركون في عملية تحميل المطورين ويركزون قدر الإمكان على مهمتهم البالغة الأهمية. في الوقت نفسه ، لن يمد المطوِّرون أبدًا كابلًا جديدًا أو يعطون كمبيوتر محمولًا جديدًا من الغرفة (الغرف) الخلفية
ما هي الفائدة؟
على السؤال "من هو DevOps؟" يبدأ نصف موظفي المجال في الاستجابة بشيء مثل "حسنًا ، هذا باختصار هو المشرف الذي ..." وما يلي. نعم ، ذات مرة ، عندما كانت مهنة DevOps-engineer قد بدأت للتو من أكثر المسؤولين موهبة فيما يتعلق بالخدمة ، لم تكن الاختلافات بينهم واضحة للجميع. لكن الآن ، عندما بدأت وظائف المطورين والمسؤولين في الفريق تختلف اختلافًا جذريًا ، فإن الخلط بينها وبينهم ، أو حتى وضع علامة متساوية بينهم ، أمر غير مقبول.
لكن ماذا يترجم إلى أعمال؟
التوظيف ، كل شيء عنه.
يمكنك فتح الوظيفة الشاغرة "مسؤول النظام" ، وهناك المتطلبات المذكورة: "التفاعل مع التطوير والعملاء" ، "نظام تسليم CI / CD" ، "خدمة خوادم ومعدات الشركة" ، "إدارة الأنظمة الداخلية" وما إلى ذلك ؛ أنت تفهم أن صاحب العمل يحمل بعض الهراء. المهم هو أنه بدلاً من "مسؤول النظام" في عنوان الوظيفة الشاغرة ، يجب أن يكون "DevOps-engineer" ، وإذا تم تغيير هذا العنوان ، فسيصبح كل شيء في مكانه الصحيح.
ومع ذلك ، ما الانطباع الذي يتم إنشاؤه عند قراءة مثل هذا المنصب الشاغر؟ أن الشركة تبحث عن مشغل متعدد الأدوات ، يقوم بنشر كل من نظام مراقبة ومراقبة الإصدار ويهز أسنانه بأسنانه ...
ولكن حتى لا تزيد درجة إدمان المخدرات في سوق العمل ، يكفي استدعاء الوظائف الشاغرة بأسمائها الصحيحة ونفهم بوضوح أن مهندس DevOps ومسؤول النظام هما كيانان مختلفان. إن الرغبة الوحيدة التي لا يمكن كبتها لدى بعض أصحاب العمل في تقديم قائمة متطلبات ممكنة للمرشح تؤدي إلى حقيقة أن مسؤولي النظام "الكلاسيكي" يتوقفون عن فهم ما يحدث حولهم. ماذا ، تتحول المهنة وتتخلف عن الحياة؟
لا ، لا ، ولا مرة أخرى. مسؤولو البنية التحتية الذين سيتولون إدارة الخوادم الداخلية للشركة ، أو يشغلون وظائف دعم L2 / L3 ويساعدون الموظفين الآخرين ، لم يذهبوا إلى أي مكان ولن يذهبون.
هل يمكن أن يصبح هؤلاء المتخصصون مهندسين من DevOps؟ بالطبع يمكنهم ذلك. في الواقع ، هذه هي البيئة الشقيقة الخاصة بهم ، والتي تتطلب مهارات إدارة النظام ، ولكن بالإضافة إلى ذلك ، العمل مع أنظمة المراقبة والتوصيل ، وبشكل عام ، يتم إضافة تفاعل وثيق مع فريق التطوير والاختبار.
مشكلة DevOps أخرى
في الواقع ، لا يقتصر كل شيء على التوظيف والارتباك المستمر بين المسؤولين والمسؤولين. في مرحلة ما ، واجه العمل مشكلة تقديم التحديثات وتفاعل فريق التطوير مع البنية التحتية النهائية.
ربما كان هذا عندما جاء عم بعيون محترقة إلى مكان المؤتمر وقال: "ونحن نفعل هذا ونطلق عليه DevOps. سوف يحل هؤلاء الأشخاص جميع مشاكلك "- وبدأوا في معرفة مدى عيشه في الشركة بعد تنفيذ ممارسات DevOps.
ومع ذلك ، لا يكفي توظيف مهندس DevOps لكي يعمل كل شيء كما يجب. يجب أن تمر الشركة تمامًا بتحويل DevOps ، أي أنه ينبغي فهم دور وقدرات مطوري البرامج لدينا بوضوح إلى جانب فريق تطوير واختبار المنتج. لدينا قصة "جميلة" حول هذا الموضوع ، والتي توضح تماما كل القصدير في الأماكن.
الوضع. يُطلب من Devops نشر نظام إرجاع النسخة ، دون الخوض بشكل خاص في كيفية عمله. لنفترض ، داخل نظام المستخدمين ، أن هذه حقول منفصلة تحت الاسم الأول واسم العائلة وكلمة المرور. تم إصدار نسخة جديدة من المنتج ، ولكن بالنسبة للمطورين ، فإن "الاستعادة" هي مجرد عصا سحرية تعمل على إصلاح كل شيء ، وحتى أنهم لا يعرفون كيف يعمل. لذلك ، على سبيل المثال ، قام مطورو البرامج في التصحيح التالي بجمع حقلي الاسم الأول والأخير ، وطرحوه في المنتج ، ويبطئ الإصدار لسبب ما. ما الذي يحدث؟ يأتي الدليل إلى devoop ويقول "سحب مفتاح السكين!" ، هذا ، يطلب منه العودة إلى الإصدار السابق. ما يفعله devops؟ يتم الرجوع إلى الإصدار السابق ، ولكن نظرًا لأن المطورين لم يرغبوا في فهم كيفية إجراء هذا الاستعادة ، لم يخبر أحد المطورين أنه من الضروري أيضًا استعادة القاعدة. نتيجة لذلك ، كل شيء يسقط بالنسبة لنا ، وبدلاً من موقع التباطؤ ، يرى المستخدمون الخطأ "500" ، لأن الإصدار القديم لا يعمل مع حقول قاعدة البيانات الجديدة. Devops ليست على علم بذلك. وضعت صامتة. تبدأ الإدارة في فقدان الأعصاب والمال واسترجاع النسخ الاحتياطية ، وعرضت التراجع عنها حتى "يعمل شيء على الأقل". نتيجة لذلك ، يفقد المستخدمون جميع بياناتهم لفترة من الوقت.
تذهب المكسرات ، بالطبع ، إلى devops ، الذين "لم يصنعوا نظام الاستعادة الصحيح" ، وحقيقة أن موس في هذه القصة هم مطورون لا يزعج أي شخص.
الاستنتاج بسيط: بدون اتباع نهج طبيعي لـ DevOps على هذا النحو ، لا يوجد الكثير منه.
الشيء الرئيسي الذي يجب تذكره: مهندس DevOps ليس ساحرًا ، وبدون اتصالات عالية الجودة وتفاعل ثنائي الاتجاه مع التنمية ، لن يكون قادرًا على التعامل مع مهامه. لا يمكن ترك Devops بمفردهم مع "مشاكلهم" أو إعطاء الأمر "لا تذهب إلى المطورين ، يرمزون إلى أعمالهم" ، ثم يأملون في أن يعمل كل شيء كما يجب في لحظة حرجة. لذلك لا يعمل.
أساسا ، DevOps هي الكفاءات على حافة بين الإدارة والتكنولوجيا. علاوة على ذلك ، ليس من الواضح أنه في مجموعة التقنيات هذه يجب أن يكون هناك أكثر من الإدارة. إذا كنت تريد حقًا إنشاء عمليات تطوير أسرع وأكثر فاعلية ، فيجب أن تثق بـ devs. إنه يعرف الأدوات الصحيحة ، وقد قام بتنفيذ مشاريع مماثلة ، وهو يعرف كيفية القيام بذلك. ساعده ، استمع لنصيحته ، لا تحاول عزله في وحدة مستقلة. إذا كان بإمكان المشرفين العمل من تلقاء أنفسهم ، فالمصلحون عديم الجدوى في هذه الحالة ، فلن يكونوا قادرين على مساعدتك في أن تصبح أفضل إذا لم ترغب أنت بنفسك في قبول هذه المساعدة.
والشيء الأخير: التوقف عن الإساءة إلى مسؤولي البنية التحتية. لديهم مجال عملهم المهم للغاية. نعم ، يمكن أن يصبح المسؤول مهندس DevOps ، ولكن يجب أن يحدث هذا بناءً على طلب الشخص نفسه ، وليس من أسفل العصا. ولا حرج في حقيقة أن مسؤول النظام يريد أن يبقى مسؤول النظام - هذه هي مهنته المنفصلة وحقه. إذا كانت هناك رغبة في إجراء تحول مهني ، فلا يجب أن ننسى بأي حال من الأحوال أنه لن يكون من الضروري بناء المهارات التكنولوجية فحسب ، بل المهارات الإدارية أيضًا. من المحتمل أن تقوم كقائد بجمع كل هؤلاء الأشخاص معًا وتعلم التواصل بلغة واحدة.