На даний момент це чи не найдорожча позиція на ринку. Суєта навколо «DevOps» інженерів перевершує всі мислимі межі, а тим гірше з Senior DevOps інженерами.
Я працюю керівником відділу інтеграції та автоматизації, вгадайте англійську розшифровку – DevOps Manager. Чи відбиває саме англійська розшифровка нашу повсякденну діяльність — навряд, а от російський варіант у цьому випадку точніший. За родом моєї діяльності, природно, що мені необхідно співбесідувати майбутніх членів моєї команди і, за минулий рік, через мене пройшло людина 50, а ще стільки ж зрізалося на прескрині з моїми співробітниками.
Ми все ще знаходимося в пошуку колег, тому що за лейблом DevOps ховається дуже великий прошарок різного роду інженерів.
Все написане нижче є моєю особистою думкою, ви не зобов'язані погоджуватися з ним, проте припускаю, що внесе відтінок у ваше ставлення до теми. Незважаючи на ризик потрапити в немилість, я публікую свою думку, оскільки вважаю, що йому є місце бути.
Компанії по-різному розуміють, хто такі DevOps інженери і заради швидкого найму ресурсу вішають цей лейбл усім. Ситуація досить дивна, оскільки компанії готові платити нереальні винагороди цим людям, отримуючи за них здебільшого адміна-тулзиста.
То хто ж такі DevOps інженери?
Почнемо з історії появи - Development Operations з'явився як ще один крок до оптимізації взаємодії в малих командах для підвищення швидкості виробництва продукту, як очікуваного наслідку. Ідея полягала в тому, щоб посилити команду розробки знаннями про процедури та підходи в управлінні продуктовим середовищем. Іншими словами, розробник повинен розуміти і знати, як його продукт працює в тих чи інших умовах, повинен розуміти як деплоїти його продукт, які характеристики середовища підкрутити, щоб підвищити продуктивність. Так, протягом деякого часу з'явилися розробники з DevOps підходом. DevOps розробники писали скрипти складання та упаковки для спрощення своєї діяльності та працездатності продуктивного середовища. Однак, складність архітектури рішень та взаємний вплив компонентів інфраструктури з часом погіршувати робочі показники середовищ, з кожною ітерацією були потрібні все більш глибокі розуміння тих чи інших компонентів, знижуючи продуктивність самого розробника через додаткові витрати на розуміння компонентів та тюнінгу систем під конкретне завдання . Власна вартість розробника зростала, вартість продукту разом з ним різко підскочили вимоги до нових розробників у команді, адже їм необхідно було також покривати обов'язки «зірки» розробки і, природно, «зірки» ставали дедалі менш доступними. Також варто відзначити, що, на мій досвід, мало кому з розробників цікава специфіка обробки пакетів ядром операційної системи, правила маршрутизації пакетів, аспекти безпеки хоста. Логічним кроком було залучити адміністратора, який саме з цим знаком і покласти подібного формату обов'язки саме на нього, що завдяки його досвіду дозволило досягти тих же показників меншою вартістю порівняно з вартістю «зірки» розробки. Таких адміністраторів поміщали в команду та основним його завданням було управління тестовими та продуктивними середовищами, на правилах конкретно взятої команди, з ресурсами виділеними саме цій команді. Так, власне, і з'явилися DevOps у поданні більшості.
Частково чи повністю, згодом, ці системні адміністратори почали розуміти потреби саме цієї конкретної команди в галузі розробки, як спростити життя розробникам та тестувальникам, як викотити оновлення та не залишитися ночувати у п'ятницю в офісі, виправляючи помилки деплою. Час минав, тепер «зірками» ставали системні адміністратори, які розуміють, чого хочуть розробники. З метою мінімізації імпакту почали підтягуватися утиліти управління, всі згадали старі та надійні методи ізоляції рівня ОС, які дозволяли мінімізувати вимоги щодо безпеки, управління мережевої частини, та й конфігурації хоста загалом і, як наслідок, знизити вимоги до нових «зірок».
З'явилася чудова річ — docker. Чому чудова? Та тільки тому, що створення ізоляції в chroot або jail, так само як OpenVZ, вимагало нетривіальних знань ОС, яка у контру утиліті дозволяє елементарно створити ізольоване середовище додатку на деякому хості з усім необхідним усередині і передати кермо управління розробці знову, а системному адміністратору управляти тільки лише одним хостом, забезпечуючи його безпеку та високу доступність - логічне спрощення. Але прогрес не стоїть на місці і системи знову стають все складнішими, складнішими все більше і більше, один хост вже не задовольняє потребам системи і необхідно будувати кластери, ми знову повертаємося до системних адміністраторів, які здатні побудувати дані системи.
Цикл за циклом, з'являються різні системи, що спрощують розробку та/або адміністрування, з'являються системи оркестрації, які рівно до тих пір, поки не потрібно відійти від стандартного процесу, прості у використанні. Мікросервісна архітектура також з'явилася з метою спрощення всього описаного вище менше взаємозв'язків, простіше в управлінні. У своєму досвіді я не застав повністю мікросервісну архітектуру, я сказав би 50 на 50 — 50 відсотків мікросервісів, чорні коробки, прийшло на вхід, вийшло оброблене, інші 50 — роздертий моноліт, сервіси нездатні працювати окремо від інших компонентів. Усе це знову наклало обмеження рівень знань як розробників, і адміністраторів.
Подібні «гойдалки» рівня експертних знань того чи іншого ресурсу продовжуються й донині. Але ми трохи відволіклися, є чимало моментів, які варто висвітлити.
Build Engineer/Release Engineer
Дуже вузькоспеціалізовані інженери, що з'явилися як засіб стандартизації процесів складання ПЗ та його релізів. У процесі введення повального Agile начебто вони перестали бути затребувані, проте це не так. Ця спеціалізація виникла як стандартизації саме збирання і постачання ПЗ у промислових масштабах, тобто. використовуючи стандартну техніку для всіх продуктів компанії. З появою DevOps розробників частково втратили функції, оскільки саме розробники стали готувати продукт до постачання, а враховуючи змінну інфраструктуру та підхід у максимально швидкому постачанні без огляду на якість згодом перетворилися саме на стопор змін, оскільки дотримання стандартів якості неминуче уповільнює постачання. Так, поступово частина функціоналу Build/Release інженерів перекочувала на плечі системних адміністраторів.
Ops'и такі різні
Ми рухаємося далі і знову наявність великого кола обов'язків та нестача кваліфікованих кадрів штовхає нас на жорстку спеціалізацію, як гриби після дощу, з'являються різні Operations:
- TechOps - системні адміністратори енікеї HelpDesk Engineer
- LiveOps — системні адміністратори, які переважно відповідають за продуктивні середовища
- CloudOps — системні адміністратори, що спеціалізуються на публічних «хмарах» Azure, AWS, GCP, etc.
- PlatOps/InfraOps/SysOps – системні адміністратори інфраструктури.
- NetOps - мережні адміністратори
- SecOps - системні адміністратори, що спеціалізуються на інформаційній безпеці - PCI compliance, CIS compliance, patching, etc.
DevOps - (теоретично) персона, яка не з чуток розуміє всі процеси циклу розробки - розробку, тестування, що розуміє архітектуру продукту, здатна оцінити ризики безпеки, знайома з підходами і засобами автоматизації, хоча б на високому рівні, крім цього розуміє також перед і пост- релізну підтримку товару. Персона здатна виступати адвокатом як Operations, так і Development, що дозволяє побудувати сприятливу співпрацю між цими двома стовпами. Розуміє процеси планування робіт командами та управління очікуваннями замовника.
Для виконання подібних робіт та обов'язків дана персона повинна мати засоби управління не тільки процесами розробки, тестування, а й управління інфраструктурою продукту, а також планування ресурсів. DevOps у цьому розумінні не може бути ні в IT, ні в R&D, ні навіть у PMO, він повинен мати вплив у всіх цих галузях — технічний директор компанії, Chief Technical Officier.
Чи це так у вашій компанії? - Сумніваюся. Найчастіше це або IT, або R&D.
Нестача коштів та можливості впливу хоча б на один із цих трьох напрямків діяльності зробить зміщення ваги проблем у бік де ці зміни простіше застосувати, як наприклад застосування технічних обмежень на релізи у зв'язку з «брудним» кодом за даними систем статичного аналізатора. Тобто коли PMO встановлює жорсткий термін на випуск функціоналу, R&D не може видати якісний результат у ці терміни і видає його як може, залишивши рефакторинг на потім, DevOps, що стосується IT, технічними засобами блокує реліз. Нестача повноважень на зміну ситуації у випадку з відповідальними співробітниками веде до прояву гіпервідповідальності за те, на що вони не можуть вплинути, тим більше якщо ці співробітники розуміють і бачать помилки, і як їх виправити — «Щастя в невіданні», і як наслідок до вигоряння та втрати цих співробітників.
Ринок DevOps ресурсів
Розгляньмо кілька вакансій на позицію DevOps від різних компаній.
Ми готові з Вами зустрінеться, якщо Ви:
- Володієте Zabbix і знаєте, що таке Prometheus;
- Iptables;
- Аспірант BASH;
- Професор Ansible;
- Гуру Linux;
- Вмієте користуватися дебагом та спільно з розробниками знаходити проблеми додатків (php/java/python);
- Роутінг не викликає у Вас істерик;
- Приділяєте значну увагу безпеці системи;
- Бекапіте "все і вся", а також успішно відновлюєте це "все і вся";
- Вмієте налаштувати систему так, щоб вичавити з мінімуму максимум;
- Налаштовуєте реплікації перед сном на Postgres та MySQL;
- Налаштування та коригування CI/CD для Вас – це необхідність як сніданок/обід/вечеря.
- Маєте досвід роботи з AWS;
- Готові розвиватися разом із компанією;
Отже:
- з 1 по 6 - системний адміністратор
- 7 - трохи мережевого адміністрування, що теж укладається в сісадміну, рівня Middle
- 8 - трохи безпеки, що обов'язково для сисадміну рівня Middle
- 9-11 - Middle System Administrator
- 12 — Залежно від поставлених завдань або Middle System Administrator, або Build Engineer
- 13 — Віртуалізація — Middle System Administrator, або так званий CloudOps, розширені знання саме сервісів конкретного хостингу майданчика, для ефективного використання коштів та зниження навантаження на обслуговування
Резюмуючи з цієї вакансії можна сказати, що хлопцям достатньо Middle/Senior System Administrator.
До речі, не варто поділяти адмінів на Linux/Windows. Я звичайно розумію, що сервіси і системи цих двох світів різняться, але основа у всіх одна і будь-який поважаючий себе адмін знайомий як з одним, так і з іншим, і навіть якщо не знайомий, то для грамотного адміна не важко ознайомиться з цим.
Розглянемо іншу вакансію:
- Досвід побудови високонавантажених систем;
- Відмінні знання ОС Linuх, загальносистемного ПЗ та веб-стека (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Досвід роботи із системами віртуалізації (KVM, VMWare, LXC/Docker);
- володіння скриптовими мовами;
- розуміння принципів роботи мереж мережевих протоколів;
- Розуміння принципів побудови відмовостійких систем;
- Самостійність та ініціативність;
Розбираємо:
- 1 — Senior System Administrator
- 2 — Залежно від змісту вкладеного в цей стек — Middle/Senior System Administrator
- 3 - Досвід роботи, в тому числі, може означати - "Кластер не піднімав, але створював і керував віртуалками, був один Docker хост, доступ до контейнерів натил" - Middle System Administrator
- 4 - Junior System Administrator - так, адмін не вміє писати елементарні скрипти автоматизації, незалежно від мови, не адмін - енікей.
- 5 - Middle System Administrator
- 6 — Senior System Administrator
Резюмуючи — Middle/Senior System Administrator
Ще одна:
- Досвід роботи devops;
- Досвід використання одного або декількох продуктів для формування CI/CD процесів. Gitlab CI буде перевагою;
- Робота з контейнерами та віртуалізацією; Якщо використали docker – добре, а якщо k8s – чудово!
- Досвід роботи у agile-команді;
- Знання будь-якої мови програмування;
Подивимося:
- 1 - Хм ... Що хлопці мають на увазі? =) Швидше за все вони самі не знають, що за цим ховається
- 2 - Build Engineer
- 3 - Middle System Administrator
- 4 - Софт-скіл, розглядати поки не будемо, хоча Agile ще одна річ, яку інтерпретують так, як зручно.
- 5 — Надто розлогово — це може бути скриптова мова або компілювана. Цікаво, а писав у школі на Pascal та Basic їх влаштує? =)
Хотілося б також залишити ремарку щодо 3 пунктів, щоб зміцнити розуміння, чому цей пункт покривається сисадміном. Kubernetes лише оркестрація, тулза яка обертає прямі команди драйверам мережі та хостам віртуалізації/ізоляції в пару команд і дозволяє зробити спілкування з ними абстрактним, от і все. Наприклад візьмемо 'build framework' Make, якого фреймворком я, до речі, не вважаю. Так, я знаю про моду пхати Make куди завгодно, де потрібно і не потрібно - обернути Maven в Make, наприклад, серйозно?
По суті Make просто обгортка над shell, що спрощує саме команди компіляції, лінківки, компіляції оточення, так само як і k8s.
Одного разу, я співбесідував хлопця, який використовував k8s у своїй роботі поверх OpenStack, і він розповідав як розгортав сервіси на ньому, проте, коли я запитав саме про OpenStack, виявилося, що він адмініструється, так само як і піднімається системними адміністраторами. Ви правда думаєте, що людина, що підняла OpenStack незалежно від того, яку платформу вона використовує позаду неї, не здатна використовувати k8s?=)
Даний претендент насправді не DevOps, а той самий Системний Адміністратор і, щоб бути точніше, Kubernetes Administrator.
Резюмуємо вкотре — Middle/Senior System Administrator їм буде достатньо.
Скільки вішати у грамах
Розкид запропонованих зарплат для зазначених вакансій — 90к-200к.
Тепер хотілося б провести паралель між грошовими винагородами Системних Адміністраторів та DevOps Engineers.
У принципі, для спрощення можна грейди з досвіду роботи розкидати, хоч це й не буде точним, для цілей статті вистачить.
досвід:
- до 3-х років - Junior
- до 6-ти років - Middle
- більше 6-ти - Senior
Сайт пошуку співробітників пропонує:
System Adminsitrators:
- Junior - 2 роки - 50к руб.
- Middle - 5 років - 70к руб.
- Senior - 11 років - 100к руб.
DevOps Engineers:
- Junior - 2 роки - 100к руб.
- Middle - 3 роки - 160к руб.
- Senior - 6 років - 220к руб.
За стажем «DevOps»'ів використовувався стаж, що хоч якось зачіпає SDLC.
З вищезазначеного випливає, що насправді компаніям не потрібні DevOps'и, а також що вони могли заощадити не менше 50 відсотків від запланованих витрат, найнявши саме Адміністратора, більше того, вони могли б чіткіше визначити обов'язки шуканої людини і швидше закрити потребу. Не варто також забувати, що чіткий поділ відповідальності дозволяє знизити вимоги до персоналу, а також створити більш сприятливу атмосферу в колективі через відсутність перетинів. У переважній більшості вакансії рясніють утилітами та DevOps лейблами, проте не мають в основі дійсно вимоги до DevOps Engineer, лише запити на тулзового адміністратора.
Процес навчання DevOps інженерів також обмежений лише набором специфічних робіт, утиліт, що не дає загального розуміння процесів та їх залежностей. Це звичайно добре, коли людина може використовувати Terraform задеплоїти AWS EKS, у зв'язці з Fluentd сайд-каром в цьому кластері і AWS ELK стеком для системи логування за 10 хвилин, використовуючи лише одну команду в консолі, але якщо вона не буде розуміти сам принцип обробки логів і для чого вони потрібні, не знати як збирати метрики по них і відстежувати деградацію сервісу, то це буде той самий енікей, який вміє використовувати деякі утиліти.
Проте попит породжує пропозицію, і ми бачимо вкрай перегрітий ринок позиції DevOps, де вимоги не відповідають реальній ролі, а лише дозволяють системним адміністраторам заробляти більше.
То хто ж вони? DevOps'и чи жадібні системні адміністратори? =)
Як далі жити?
Роботодавцям — точніше формулювати вимоги та шукати саме тих, хто потрібен, а не розкидатися лейблами. Ви не знаєте, чим займаються DevOps — вони вам не потрібні в такому випадку.
Працівникам - Вчитися. Постійно удосконалювати свої знання, дивитися на загальну картину процесів та відстежувати шлях до поставленої мети. Можна стати ким захочеш, треба лише постаратися.
Джерело: habr.com