من هم ديفوبس؟

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

لا نزال نبحث عن زملاء ، لأن وراء DevOps طبقة كبيرة جدًا من أنواع مختلفة من المهندسين.

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

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

فمن هم مهندسو ديفوبس؟

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

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

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

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

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

بناء المهندس / مهندس الإصدار

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

العمليات مختلفة جدا

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

• TechOps - enike مسؤولي النظام الملقب HelpDesk Engineer
• LiveOps - مسؤولو النظام المسؤولون في المقام الأول عن البيئات الإنتاجية
• CloudOps - مسؤولو النظام المتخصصون في "السحب" العامة لـ Azure و AWS و GCP ، إلخ.
• PlatOps / InfraOps / SysOps - مسؤولو نظام البنية التحتية.
• NetOps - مسؤولي الشبكة
• SecOps - مسؤولو النظام المتخصصون في أمن المعلومات - توافق PCI ، توافق CIS ، الترقيع ، إلخ.

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

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

هل هذا هو الحال في شركتك؟ - أنا أشك في ذلك. في معظم الحالات ، يكون هذا إما تكنولوجيا المعلومات أو البحث والتطوير.

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

الموارد DevOps السوق

دعونا نلقي نظرة على عدد قليل من فرص العمل DevOps من شركات مختلفة.

نحن على استعداد لمقابلتك إذا كنت:

1. تملك Zabbix ومعرفة ما هو بروميثيوس ؛
2. إيبتبلس.
3. طالب دراسات عليا
4. أستاذ Ansible.
5. جورو لينكس
6. تعرف على كيفية استخدام debug وابحث عن مشكلات التطبيق مع المطورين (php / java / python) ؛
7. التوجيه لا يسبب لك نوبات الغضب.
8. إيلاء اهتمام كبير لأمن النظام ؛
9. النسخ الاحتياطي "كل شيء وكل شيء" ، وكذلك بنجاح استعادة هذا "كل شيء وكل شيء" ؛
10. أنت تعرف كيفية تكوين النظام للضغط من الحد الأدنى - الحد الأقصى ؛
11. تكوين النسخ المتماثل وقت النوم على بوستجرس و MySQL؛
12. يعد إعداد وضبط CI / CD من أجلك ضرورة مثل الإفطار / الغداء / العشاء.
13. لديهم خبرة مع AWS ؛
14. على استعداد لتطوير مع الشركة ؛

لذلك:

• 1 إلى 6 - مسؤول النظام
• 7 - قليلا من إدارة الشبكة ، والتي تناسبها أيضا إلى مسؤول النظام ، المستوى الأوسط
• 8 - قليلا من الأمن ، وهو إلزامي لمسؤول نظام متوسط ​​المستوى
• 9-11 - مسؤول النظام الأوسط
• 12 - حسب مجموعة المهام ، إما مسؤول النظام الأوسط أو مهندس البناء
• 13 - المحاكاة الافتراضية - مسؤول النظام الأوسط ، أو ما يسمى CloudOps ، المعرفة المتقدمة لخدمات منصة استضافة معينة ، من أجل الاستخدام الفعال للأموال وتقليل العبء على الخدمة

بتلخيص هذا المنصب الشاغر ، يمكننا القول أن مسؤول النظام الأوسط / الكبير يكفي للاعبين.

بالمناسبة ، لا تفصل بشدة المشرفين على Linux / Windows. بالطبع ، أنا أفهم أن الخدمات والأنظمة في هذين العالمين مختلفة ، ولكن لكل فرد أساس واحد وأن أي مسؤول يحترم نفسه يكون على دراية بواحد أو بآخر ، وحتى إذا لم يكن مألوفًا ، فلن يكون من الصعب على المسؤول المختص التعرف على هذا.

النظر في وظيفة شاغرة أخرى:

1. خبرة في بناء أنظمة محملة للغاية ؛
2. معرفة ممتازة بنظام التشغيل Linux ، والبرمجيات على مستوى النظام ، ومكدس الويب (Nginx ، PHP / Python ، HAProxy ، MySQL / PostgreSQL ، Memcached ، Redis ، RabbitMQ ، ELK) ؛
3. تجربة مع أنظمة المحاكاة الافتراضية (KVM ، VMWare ، LXC / Docker) ؛
4. معرفة لغات البرمجة ؛
5. فهم مبادئ تشغيل شبكات بروتوكولات الشبكة ؛
6. فهم مبادئ بناء أنظمة تحمل الأخطاء ؛
7. الاستقلال والمبادرة

تحليل:

• 1 - مسؤول النظام الأقدم
• 2 - حسب المعنى المستثمر في هذه المجموعة - مدير النظام الأوسط / الأعلى
• 3 - الخبرة ، بما في ذلك ، قد تعني - "المجموعة لم تثر ، ولكن تم إنشاؤها وإدارة الأجهزة الافتراضية ، كان هناك مضيف Docker واحد ، توتر الوصول إلى الحاويات" - مسؤول النظام الأوسط
• 4 - مسؤول النظام المبتدئين - نعم ، لا يستطيع المشرف كتابة نصوص التشغيل الآلي الأولية ، بغض النظر عن اللغة ، وليس المسؤول - enikey.
• 5 - مسؤول النظام الأوسط
• 6 - مسؤول النظام الأقدم

تلخيص - الأوسط / كبار مسؤول النظام

واحد آخر:

1. تجربة devops.
2. خبرة في استخدام منتج واحد أو أكثر لتشكيل عمليات CI / CD. Gitlab CI سيكون ميزة.
3. العمل مع الحاويات والمحاكاة الافتراضية. إذا كنت تستخدم عامل ميناء - جيد ، ولكن إذا k8s - عظيم!
4. خبرة في فريق رشيق.
5. معرفة أي لغة البرمجة ؛

لنرى:

• 1 - هم ... ماذا يعني الرجال؟ =) على الأرجح أنهم أنفسهم لا يعرفون ما وراء ذلك
• 2 - بناء المهندس
• 3 - مسؤول النظام الأوسط
• 4 - مهارة لينة ، لن نفكر فيها حتى الآن ، على الرغم من أن Agile هو شيء آخر يتم تفسيره على أنه مريح.
• 5 - ضخم جدًا - يمكن أن يكون لغة برمجة أو يتم تجميعها. ومن المثير للاهتمام ، هل كتب في المدرسة عن Pascal and Basic؟ =)

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

ذات مرة ، قابلت شخصًا استخدم k8s في عمله أعلى OpenStack ، وتحدث عن كيفية نشر الخدمات عليه ، ومع ذلك ، عندما سألت عن OpenStack ، اتضح أنه تتم إدارته ، كما يتم رفعه من قبل مسؤولي النظام. هل تعتقد حقًا أن الشخص الذي رفع OpenStack ، بغض النظر عن النظام الأساسي الذي يستخدم خلفه ، غير قادر على استخدام k8s؟ =)
هذا المتقدم ليس في الواقع DevOps ، ولكنه مسؤول النظام نفسه ، ولكي يكون أكثر دقة ، مسؤول Kubernetes.

نلخص مرة أخرى - سيكون مسؤول النظام الأوسط / الأقدم كافياً بالنسبة لهم.

كم لشنق في غرام

انتشار المرتبات المعروضة للوظائف الشاغرة بين 90 و 200 ألف
الآن أود أن أرسم بالتوازي بين المكافآت المالية لمسؤولي النظام ومهندسي DevOps.

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

تجربة:

1. أقل من 3 سنوات - جديد
2. أقل من 6 سنوات - الأوسط
3. أكثر من 6 - كبار

يقدم موقع البحث عن الموظف:
مسؤولو النظام:

1. صغار - 2 سنة - 50K فرك.
2. منتصف - 5 سنوات - 70K روبل.
3. كبار - 11 سنة - 100K روبل.

المهندسين DevOps:

1. صغار - 2 سنة - 100K فرك.
2. منتصف - 3 سنوات - 160k فرك.
3. كبار - 6 سنوات من العمر - فرك 220K.

وفقًا لتجربة "DevOps" ، استخدمنا هذه التجربة ، على الأقل التي تؤثر على SDLC.

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

تقتصر عملية تدريب مهندسي DevOps أيضًا على مجموعة من الأعمال والمرافق المحددة ولا توفر فهمًا عامًا للعمليات وتوابعها. هذا أمر جيد بالطبع عندما يمكن للشخص استخدام AWS EKS للانضمام إلى AWS EKS جنبًا إلى جنب مع السيارة الجانبية Fluentd في هذه المجموعة ومكدس AWS ELK لنظام التسجيل في 10 دقائق ، باستخدام أمر واحد فقط في وحدة التحكم ، ولكن إذا كان لا يفهم مبدأ المعالجة سجلات والسبب في الحاجة إليها ، وليس لمعرفة كيفية جمع المقاييس عليها وتتبع تدهور الخدمة ، ثم سيكون enikey نفسه ، قادرة على استخدام بعض المرافق.

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

من هم؟ DevOps أو مسؤولي النظام الجشع؟ =)

كيف نعيش أكثر؟

لأصحاب العمل - من الأصح صياغة المتطلبات والبحث عن من يحتاجون إليها بالضبط ، وليس نشر الملصقات. أنت لا تعرف ما تفعله DevOps - أنت لا تحتاج إليها في هذه الحالة.

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