في الوقت الحالي، يعد هذا هو المركز الأغلى تقريبًا في السوق. إن الضجة حول مهندسي "DevOps" تتجاوز كل الحدود التي يمكن تخيلها، بل إنها أسوأ مع كبار مهندسي DevOps.
أعمل كرئيس لقسم التكامل والأتمتة، تخمين فك التشفير باللغة الإنجليزية - مدير DevOps. ومن غير المرجح أن يعكس النص الإنجليزي أنشطتنا اليومية، لكن النسخة الروسية في هذه الحالة أكثر دقة. نظرًا لطبيعة نشاطي، فمن الطبيعي أن أحتاج إلى إجراء مقابلات مع أعضاء فريقي المستقبليين، وخلال العام الماضي، مر من خلالي حوالي 50 شخصًا، وتم قطع نفس العدد على الشاشة المسبقة مع الموظفين لدي.
ما زلنا نبحث عن زملاء، لأنه خلف علامة DevOps هناك طبقة كبيرة جدًا من أنواع مختلفة من المهندسين المختبئين.
كل ما هو مكتوب أدناه هو رأيي الشخصي، ليس من الضروري أن توافق عليه، لكنني أعترف أنه سيضيف بعض اللون إلى موقفك من الموضوع. على الرغم من خطر فقدان الحظوة، إلا أنني أنشر رأيي لأنني أعتقد أن له مكانًا.
لدى الشركات مفاهيم مختلفة حول هوية مهندسي DevOps، ومن أجل توظيف الموارد بسرعة، فإنهم يعلقون هذه التسمية على الجميع. الوضع غريب للغاية، لأن الشركات مستعدة لدفع أجور غير واقعية لهؤلاء الأشخاص، وتلقي، في معظم الحالات، مسؤول أداة لهم.
إذن من هم مهندسو DevOps؟
لنبدأ بتاريخ ظهورها - ظهرت عمليات التطوير كخطوة أخرى نحو تحسين التفاعل في الفرق الصغيرة لزيادة سرعة إنتاج المنتج، كنتيجة متوقعة. وكانت الفكرة هي تعزيز فريق التطوير بالمعرفة بالإجراءات والأساليب في إدارة بيئة المنتج. بمعنى آخر، يجب على المطور أن يفهم ويعرف كيف يعمل منتجه في ظروف معينة، ويجب أن يفهم كيفية نشر منتجه، وما هي خصائص البيئة التي يمكن تعديلها لتحسين الأداء. لذلك، لبعض الوقت، ظهر المطورون الذين يتبعون نهج DevOps. قام مطورو DevOps بكتابة نصوص برمجية للإنشاء والتعبئة لتبسيط أنشطتهم وأداء بيئة الإنتاج. ومع ذلك، فإن تعقيد بنية الحل والتأثير المتبادل لمكونات البنية التحتية مع مرور الوقت بدأ في تدهور أداء البيئات؛ ومع كل تكرار، كان هناك حاجة إلى فهم أعمق بشكل متزايد لمكونات معينة، مما يقلل من إنتاجية المطور بسبب الوظائف الإضافية. تكاليف فهم المكونات وأنظمة الضبط لمهمة محددة. نمت تكلفة المطور، وتكلفة المنتج معه، وقفزت متطلبات المطورين الجدد في الفريق بشكل حاد، لأنهم كانوا بحاجة أيضًا إلى تغطية مسؤوليات تطوير "النجم"، وبطبيعة الحال، أصبحت "النجوم" أقل وأقل توفرا. ومن الجدير بالذكر أيضًا أنه، من خلال تجربتي، هناك عدد قليل من المطورين المهتمين بتفاصيل معالجة الحزم بواسطة نواة نظام التشغيل، وقواعد توجيه الحزم، والجوانب الأمنية للمضيف. وكانت الخطوة المنطقية هي جذب مسؤول على دراية بهذا الأمر وإسناد مسؤوليات مماثلة إليه، الأمر الذي مكن، بفضل خبرته، من تحقيق نفس المؤشرات بتكلفة أقل مقارنة بتكلفة التطوير "النجم". تم وضع هؤلاء المسؤولين في فريق وكانت مهمته الرئيسية هي إدارة بيئات الاختبار والإنتاج، وفقًا لقواعد فريق معين، مع تخصيص الموارد لهذا الفريق المعين. هذه هي الطريقة التي ظهرت بها DevOps في الواقع في أذهان الأغلبية.
جزئيًا أو كليًا، بمرور الوقت، بدأ مسؤولو النظام في فهم احتياجات هذا الفريق المعين في مجال التطوير، وكيفية تسهيل الحياة للمطورين والمختبرين، وكيفية طرح التحديث وعدم الاضطرار إلى البقاء طوال الليل يوم الجمعة في المكتب، وتصحيح أخطاء النشر. مر الوقت، والآن أصبح "النجوم" مسؤولي النظام الذين فهموا ما يريده المطورون. ومن أجل تقليل التأثير، بدأت أدوات الإدارة في الظهور؛ وتذكر الجميع الأساليب القديمة والموثوقة لعزل مستوى نظام التشغيل، والتي مكنت من تقليل متطلبات الأمان، وإدارة جزء الشبكة، وتكوين المضيف باعتبارها بالكامل، ونتيجة لذلك، تقليل متطلبات "النجوم" الجديدة.
لقد ظهر شيء "رائع" - عامل الإرساء. لماذا رائع؟ نعم، فقط لأن إنشاء العزلة في chroot أو السجن، بالإضافة إلى OpenVZ، يتطلب معرفة غير تافهة بنظام التشغيل، على النقيض من ذلك، تسمح لك الأداة المساعدة ببساطة بإنشاء بيئة تطبيق معزولة على مضيف معين مع كل ما هو ضروري بالداخل واليد يتولى زمام التطوير مرة أخرى، ولا يمكن لمسؤول النظام الإدارة إلا باستخدام مضيف واحد فقط، مما يضمن أمانه وتوافره العالي - وهو تبسيط منطقي. لكن التقدم لا يزال قائما وأصبحت الأنظمة أكثر تعقيدا مرة أخرى، وهناك المزيد والمزيد من المكونات، ولم يعد مضيف واحد يلبي احتياجات النظام ومن الضروري بناء مجموعات، ونحن نعود مرة أخرى إلى مسؤولي النظام الذين هم قادرة على بناء هذه الأنظمة.
دورة بعد دورة، تظهر أنظمة مختلفة تعمل على تبسيط التطوير و/أو الإدارة، وتظهر أنظمة التنسيق، والتي تكون سهلة الاستخدام حتى تحتاج إلى الانحراف عن العملية القياسية. ظهرت أيضًا بنية الخدمات الصغيرة بهدف تبسيط كل ما هو موضح أعلاه - علاقات أقل وأسهل في الإدارة. في تجربتي، لم أجد بنية خدمات صغيرة تمامًا، أود أن أقول إن 50 إلى 50 - 50 بالمائة من الخدمات الصغيرة، والصناديق السوداء، جاءت، وخرجت معالجة، والخمسون الأخرى عبارة عن كتلة متراصة ممزقة، والخدمات غير قادرة على العمل بشكل منفصل عن الخدمات الأخرى عناصر. كل هذا فرض قيودًا مرة أخرى على مستوى معرفة المطورين والمسؤولين.
تستمر "التقلبات" المماثلة في مستوى معرفة الخبراء بمورد معين حتى يومنا هذا. ولكننا نستطرد قليلاً، فهناك نقاط كثيرة تستحق تسليط الضوء عليها.
مهندس البناء / مهندس الإصدار
مهندسون متخصصون للغاية ظهروا كوسيلة لتوحيد عمليات إنشاء البرامج وإصداراتها. في عملية إدخال Agile على نطاق واسع، يبدو أنهم توقفوا عن الطلب، لكن هذا ليس هو الحال. ظهر هذا التخصص كوسيلة لتوحيد تجميع وتسليم البرمجيات على نطاق صناعي، أي. باستخدام التقنيات القياسية لجميع منتجات الشركة. مع ظهور DevOps، فقد المطورون وظائفهم جزئيًا، نظرًا لأن المطورين هم الذين بدأوا في إعداد المنتج للتسليم، ونظرًا للبنية التحتية المتغيرة ونهج التسليم في أسرع وقت ممكن بغض النظر عن الجودة، فقد تحولوا بمرور الوقت إلى عائق للتغييرات، لأن الالتزام بمعايير الجودة يؤدي حتمًا إلى إبطاء عمليات التسليم. لذا، تدريجيًا، انتقل جزء من وظائف مهندسي البناء/الإصدار إلى مسؤولي النظام.
العمليات مختلفة جدا
ننتقل مرة أخرى، ووجود مجموعة كبيرة من المسؤوليات ونقص الموظفين المؤهلين يدفعنا نحو التخصص الصارم، مثل الفطر بعد المطر، تظهر عمليات مختلفة:
- TechOps - مسؤولو نظام enikey المعروفون أيضًا باسم HelpDesk Engineer
- LiveOps - مسؤولو النظام المسؤولون بشكل أساسي عن بيئات الإنتاج
- CloudOps - مسؤولو النظام المتخصصون في السحابات العامة Azure وAWS وGCP وما إلى ذلك.
- PlatOps/InfraOps/SysOps - مسؤولو نظام البنية التحتية.
- NetOps - مسؤولي الشبكات
- SecOps - مسؤولو النظام المتخصصون في أمن المعلومات - الامتثال لـ PCI، والامتثال لـ CIS، والتصحيح، وما إلى ذلك.
DevOps هو (من الناحية النظرية) شخص يفهم بشكل مباشر جميع عمليات دورة التطوير - التطوير والاختبار، ويفهم بنية المنتج، وقادر على تقييم المخاطر الأمنية، وعلى دراية بالمناهج وأدوات التشغيل الآلي، على الأقل بدرجة عالية بالإضافة إلى ذلك، يفهم المستوى أيضًا دعم إصدار المنتج قبل وبعد المعالجة. شخص قادر على العمل كمدافع عن كل من العمليات والتطوير، مما يسمح بالتعاون الإيجابي بين هاتين الركيزتين. يفهم عمليات تخطيط العمل من قبل الفرق وإدارة توقعات العملاء.
لأداء هذا النوع من العمل والمسؤوليات، يجب أن يكون لدى هذا الشخص الوسائل اللازمة لإدارة ليس فقط عمليات التطوير والاختبار، ولكن أيضًا إدارة البنية التحتية للمنتج، بالإضافة إلى تخطيط الموارد. لا يمكن أن يكون موقع DevOps، بهذا المفهوم، موجودًا في تكنولوجيا المعلومات، أو في البحث والتطوير، أو حتى في مكتب إدارة المشاريع، بل يجب أن يكون له تأثير في جميع هذه المجالات - المدير الفني للشركة، والمدير الفني الرئيسي.
هل هذا صحيح في شركتك؟ - أشك. في معظم الحالات، يكون هذا إما تكنولوجيا المعلومات أو البحث والتطوير.
سيؤدي نقص الأموال والقدرة على التأثير على واحد على الأقل من مجالات النشاط الثلاثة هذه إلى تحويل ثقل المشكلات نحو حيث يكون تطبيق هذه التغييرات أسهل، مثل تطبيق القيود الفنية على الإصدارات المتعلقة بالكود "القذر" وفقًا لقواعد ثابتة أنظمة التحليل. أي أنه عندما يحدد مكتب إدارة المشاريع موعدًا نهائيًا صارمًا لإصدار الوظائف، لا يمكن للبحث والتطوير أن ينتج نتيجة عالية الجودة خلال هذه المواعيد النهائية وينتجها بأفضل ما يمكنه، مما يترك إعادة البناء لوقت لاحق، وتقوم DevOps المتعلقة بتكنولوجيا المعلومات بحظر الإصدار باستخدام الوسائل التقنية . إن عدم القدرة على تغيير الوضع، في حالة الموظفين المسؤولين، يؤدي إلى ظهور فرط المسؤولية عما لا يستطيعون التأثير عليه، خاصة إذا كان هؤلاء الموظفون يفهمون ويرون الأخطاء، وكيفية تصحيحها - "النعيم هو الجهل"، ونتيجة للإرهاق وفقدان هؤلاء الموظفين.
سوق موارد DevOps
دعونا نلقي نظرة على العديد من الوظائف الشاغرة لمناصب DevOps من شركات مختلفة.
نحن على استعداد للقاء معك إذا كنت:
- أنت تمتلك Zabbix وتعرف ما هو بروميثيوس؛
- إيتابلز;
- طالب دكتوراه باش؛
- البروفيسور أنسيبل؛
- خبير لينكس؛
- معرفة كيفية استخدام تصحيح الأخطاء والعثور على مشكلات التطبيق مع المطورين (php/Java/python)؛
- التوجيه لا يجعلك في حالة هستيرية؛
- إيلاء اهتمام كبير لأمن النظام؛
- النسخ الاحتياطي "أي شيء وكل شيء"، وكذلك استعادة هذا "أي شيء وكل شيء" بنجاح؛
- أنت تعرف كيفية تكوين النظام بطريقة تحصل على الحد الأقصى من الحد الأدنى؛
- قم بإعداد النسخ المتماثل قبل الذهاب إلى السرير على Postgres وMySQL؛
- يعد إعداد CI/CD وضبطه أمرًا ضروريًا بالنسبة لك مثل الإفطار/الغداء/العشاء.
- لديك خبرة مع AWS؛
- على استعداد للتطوير مع الشركة.
لذلك:
- من 1 إلى 6 - مسؤول النظام
- 7 - القليل من إدارة الشبكة، والتي تناسب أيضًا مسؤول النظام، المستوى المتوسط
- 8 - القليل من الأمان، وهو أمر إلزامي لمسؤول النظام من المستوى المتوسط
- 9-11 – مدير النظام الأوسط
- 12 — اعتمادًا على المهام المعينة، إما مسؤول النظام الأوسط أو مهندس البناء
- 13 - المحاكاة الافتراضية - مسؤول النظام الأوسط أو ما يسمى CloudOps، معرفة متقدمة بخدمات موقع استضافة معين، من أجل الاستخدام الفعال للأموال وتقليل العبء على الصيانة
تلخيصًا لهذا المنصب الشاغر، يمكننا القول أن مدير النظام الأوسط/الكبير يكفي للرجال.
بالمناسبة، لا ينبغي عليك تقسيم المسؤولين على Linux/Windows بشدة. بالطبع، أنا أفهم أن خدمات وأنظمة هذين العالمين مختلفة، ولكن الأساس للجميع هو نفسه وأي مسؤول يحترم نفسه على دراية بالواحد والآخر، وحتى لو لم يكن على دراية به، فسوف لن يكون من الصعب على المسؤول المختص التعرف عليه.
دعونا نفكر في وظيفة شاغرة أخرى:
- خبرة في بناء أنظمة عالية التحميل.
- معرفة ممتازة بنظام التشغيل Linux وبرامج النظام العامة ومكدس الويب (Nginx، PHP/Python، HAProxy، MySQL/PostgreSQL، Memcached، Redis، RabbitMQ، ELK)؛
- خبرة في أنظمة المحاكاة الافتراضية (KVM، VMWare، LXC/Docker)؛
- إتقان لغات البرمجة النصية؛
- فهم مبادئ تشغيل شبكات بروتوكول الشبكة؛
- فهم مبادئ بناء أنظمة متسامحة مع الأخطاء؛
- الاستقلال والمبادرة؛
دعنا ننظر إلى:
- 1- مدير نظام أول
- 2 - اعتمادًا على المعنى الموضوع في هذه المجموعة - مسؤول النظام الأوسط/الكبير
- 3 - خبرة العمل، بما في ذلك، قد تعني - "لم تقم المجموعة برفع الأجهزة الافتراضية، ولكنها أنشأتها وأدارتها، وكان هناك مضيف Docker واحد، ولم يكن الوصول إلى الحاويات متاحًا" - مسؤول النظام الأوسط
- 4 - مسؤول النظام المبتدئ - نعم، مسؤول لا يعرف كيفية كتابة نصوص الأتمتة الأساسية، بغض النظر عن اللغة، وليس مسؤولاً - enikey.
- 5- مدير النظام الأوسط
- 6- مدير نظام أول
للتلخيص - مسؤول النظام الأوسط/الكبير
واحدة أخرى:
- تجربة المطورين؛
- خبرة في استخدام منتج واحد أو أكثر لإنشاء عمليات CI/CD. سيكون Gitlab CI ميزة؛
- العمل مع الحاويات والمحاكاة الافتراضية؛ إذا كنت تستخدم عامل الإرساء، فهذا جيد، ولكن إذا كنت تستخدم k8s، فهذا رائع!
- خبرة في العمل ضمن فريق رشيق.
- معرفة أي لغة برمجة؛
دعونا نرى:
- 1 - امممم...ماذا يعني الرجال؟ =) على الأرجح أنهم أنفسهم لا يعرفون ما هو مخفي وراء ذلك
- 2- مهندس بناء
- 3- مدير النظام الأوسط
- 4 - المهارة الناعمة، لن نأخذها في الاعتبار الآن، على الرغم من أن Agile شيء آخر يتم تفسيره بطريقة مناسبة.
- 5 - مطول جدًا - يمكن أن تكون لغة نصية أو لغة مجمعة. أتساءل عما إذا كانت الكتابة بلغة Pascal و Basic في المدرسة تناسبهم؟ =)
أود أيضًا أن أترك ملاحظة بخصوص النقطة 3 من أجل تعزيز فهم سبب تغطية مسؤول النظام لهذه النقطة. Kubernetes هو مجرد تنسيق، أداة تقوم بتجميع الأوامر المباشرة لبرامج تشغيل الشبكة ومضيفي المحاكاة الافتراضية/العزل في بضعة أوامر وتسمح لك بإجراء التواصل معهم بشكل مجرد، هذا كل شيء. على سبيل المثال، لنأخذ "إنشاء إطار عمل" Make، والذي، بالمناسبة، لا أعتبره إطار عمل. نعم، أنا أعرف عن موضة الدفع في أي مكان، حيث يكون ذلك ضروريًا وليس هناك حاجة إليه - تغليف Maven في Make، على سبيل المثال، على محمل الجد؟
في الأساس، يعد Make مجرد غلاف فوق الغلاف، مما يبسط أوامر التجميع والربط وبيئة التجميع، تمامًا مثل k8s.
ذات مرة، أجريت مقابلة مع رجل يستخدم k8s في عمله فوق OpenStack، وتحدث عن كيفية نشر الخدمات عليه، ومع ذلك، عندما سألت عن OpenStack، اتضح أنه تمت إدارته، كما تم رفعه بواسطة النظام المسؤولين. هل تعتقد حقًا أن الشخص الذي قام بتثبيت OpenStack، بغض النظر عن النظام الأساسي الذي يستخدمه خلفه، غير قادر على استخدام k8s؟ =)
مقدم الطلب هذا ليس في الواقع DevOps، ولكنه مسؤول النظام، وبشكل أكثر دقة، مسؤول Kubernetes.
دعونا نلخص مرة أخرى - سيكون مسؤول النظام الأوسط/الكبير كافيًا بالنسبة لهم.
كم يزن بالجرام
نطاق الرواتب المقترحة للوظائف الشاغرة المشار إليها هو 90 ألف - 200 ألف
الآن أود أن أقارن بين المكافآت المالية لمسؤولي النظام ومهندسي DevOps.
من حيث المبدأ، لتبسيط الأمور، يمكنك تشتيت الدرجات بناءً على خبرة العمل، على الرغم من أن هذا لن يكون دقيقًا، إلا أنه سيكون كافيًا لأغراض المقالة.
الخبرة:
- ما يصل إلى 3 سنوات - جونيور
- ما يصل إلى 6 سنوات - المتوسطة
- أكثر من 6 - كبار
يقدم موقع البحث عن الموظفين:
مسؤولي النظام:
- جونيور - سنتين - 2 ألف فرك.
- المتوسطة - 5 سنوات - 70 ألف فرك.
- كبير - 11 سنة - 100 ألف فرك.
مهندسو DevOps:
- جونيور - سنتين - 2 ألف فرك.
- المتوسطة - 3 سنوات - 160 ألف فرك.
- كبير - 6 سنة - 220 ألف فرك.
وفقًا لتجربة "DevOps"، تم استخدام تجربة أثرت بطريقة أو بأخرى على SDLC.
يترتب على ما سبق أن الشركات في الواقع لا تحتاج إلى DevOps، كما يمكنها توفير ما لا يقل عن 50 بالمائة من التكاليف المخطط لها في البداية عن طريق تعيين مسؤول؛ علاوة على ذلك، يمكنها تحديد مسؤوليات الشخص الذي تبحث عنه بشكل أكثر وضوحًا. وملء الحاجة بشكل أسرع. يجب ألا ننسى أيضًا أن التقسيم الواضح للمسؤوليات يسمح لنا بتقليل متطلبات الموظفين، فضلاً عن خلق جو أكثر ملاءمة في الفريق، بسبب عدم وجود تداخلات. الغالبية العظمى من الوظائف الشاغرة مليئة بالأدوات المساعدة وعلامات DevOps، لكنها لا تستند إلى المتطلبات الفعلية لمهندس DevOps، بل طلبات فقط لمسؤول الأداة.
تقتصر عملية تدريب مهندسي DevOps أيضًا على مجموعة من الأعمال والمرافق المحددة، ولا توفر فهمًا عامًا للعمليات وتبعياتها. من الجيد بالتأكيد أن يتمكن الشخص من نشر AWS EKS باستخدام Terraform، جنبًا إلى جنب مع Fluentd Sidecar في هذه المجموعة ومكدس AWS ELK لنظام التسجيل في 10 دقائق، باستخدام أمر واحد فقط في وحدة التحكم، ولكن إذا لم يفهم الأمر مبدأ معالجة السجلات نفسها وما هي الحاجة إليها، إذا كنت لا تعرف كيفية جمع المقاييس عليها وتتبع تدهور الخدمة، فسيظل نفس الشيء الذي يعرف كيفية استخدام بعض الأدوات المساعدة.
ومع ذلك، فإن الطلب يخلق العرض، ونحن نرى سوقًا محمومًا للغاية لوظيفة DevOps، حيث لا تتوافق المتطلبات مع الدور الفعلي، ولكنها تسمح فقط لمسؤولي النظام بكسب المزيد.
فمن هم؟ DevOps أم مسؤولي النظام الجشعين؟ =)
كيف تستمر في العيش؟
يجب على أصحاب العمل صياغة المتطلبات بشكل أكثر دقة والبحث عن الأشخاص المطلوبين بالضبط، وعدم التخلص من التسميات. أنت لا تعرف ما تفعله DevOps، ولن تحتاج إليها في هذه الحالة.
العمال - تعلم. قم بتحسين معرفتك باستمرار، وانظر إلى الصورة العامة للعمليات وتتبع المسار إلى هدفك. يمكنك أن تصبح من تريد، عليك فقط أن تحاول.
المصدر: www.habr.com