Хто такий DevOps Engineer. Огляд професії від Олега Миколайченка

Продовжуємо цикл матеріалів про ІТ-спеціальності. Кожну описує «типовий представник» — досвідчений фахівець і просто авторитетний колега, та сама людина, яка знає всі таємні куточки своєї професії. Ми сподіваємося, ці матеріали допоможуть школярам, студентам, перекваліфікантам, студентам і всім тим, хто зацікавлений у виборі ІТ-спеціальності. Цикл не тільки допоможе оцінити перспективи, а й дасть можливість краще зрозуміти індустрію і особливості професії зсередини. Обговорюйте і доповнюйте матеріал в коментарях, щоб зробити його ще корисніше.

Про професію розповідає Олег Миколайченко, SQUAD, Head of Infrastructure.

Залишити коментар
Хто такий DevOps Engineer. Огляд професії від Олега Миколайченка

Продовжуємо цикл матеріалів про ІТ-спеціальності. Кожну описує «типовий представник» — досвідчений фахівець і просто авторитетний колега, та сама людина, яка знає всі таємні куточки своєї професії. Ми сподіваємося, ці матеріали допоможуть школярам, студентам, перекваліфікантам, студентам і всім тим, хто зацікавлений у виборі ІТ-спеціальності. Цикл не тільки допоможе оцінити перспективи, а й дасть можливість краще зрозуміти індустрію і особливості професії зсередини. Обговорюйте і доповнюйте матеріал в коментарях, щоб зробити його ще корисніше.

Про професію розповідає Олег Миколайченко, SQUAD, Head of Infrastructure.

Чим займається DevOps Engineer

Олег Миколайченко, SQUAD, Head of Infrastructure
DevOps Engineer — це саме та роль в розробці, межі якої нескінченно розмиті, але в той же час мають відчутні обриси. Коли говорять про DevOps, мають на увазі інфраструктуру для проектів (сервера, хмарні рішення, автоматизацію, балансувальники і т. п.), процеси складання і деплойменту (CI/CD — це сюди, численні рішення Jenkins/CircleCI/TravisCI/etc.) і звичайно величезну базу знань про мікросервіси, архітектурах, високому навантаженні, і основних контейнерних платформах. На цьому етапі плюс-мінус виглядає на адекватну позицію, але якщо сюди додати відповідальність за моніторинг, централізований збір логів, метрики, графіки, оповіщення про інциденти, on-call (раптом, вночі щось впало) і ключову роль в розробці архітектур для сервісів (звичайно, NALSD)-виходить такий собі багаторукий шайтан — переросток з купою обов’язків і величезною зарплатою. А, мало не забув: якщо десь у веб-сервісі або додатку є проблема, і ніхто не знає звідки ростуть ноги і хто її може вирішити — це теж до DevOps-ам. Виходить, DevOps — на додаток до комунікатор-роутер-вирішувач-проблем. Давайте розберемося, як виглядає звичайний робочий день інженера з команди DevOps. 

 Як виглядає типовий день DevOps Engineer 

Не вигадуючи абстрактних інженерів у вакуумі, я візьму кількох колег з команди і покажу приблизне навантаження протягом дня:

  1. Дейлі синк. Відповіді на питання — що робив вчора, що вийшло і не вийшло, які плани на сьогодні. Обов’язково вказує Jira тікети у звіті, показує постійний прогрес. 
  2. Робота над своїм пріоритетом, наприклад, кумулятивний дашборд для всіх сервісів. Описує графіки в grafanalib, дивиться результати в Grafana. 
  3. Взаємодія з розробниками -
  4. попросили поправити TTL для AWS SQS, зайшов в репозиторій з Infrastructure as a Code, додав рядок в Terraform, застосував зміни. 
  5. Повернувся до минулого довгострокового завдання над реалізацією Jenkins в хмарі, автоматизував пайплайни, переніс репозиторій. 
  6. Пообідавши. Жарт — вже, звичайно, вечір. Книги, курси, Самонавчання. Документація. 
  7. Підключився на кілька мітингів, поправив iam роль з доступами, задоволений закрив ноут, і ближче до вечора отримав алерт з моніторинг системи — впав сервіс. 
  8. Полагодив сервіс. 

Що потрібно знати DevOps інженеру 

Супер детально можна ознайомитися на Github — у відмінному roadmap для вивчення та підготовки, а я зроблю акцент на найважливіших аспектах і галузях знань. 

Перше — і найважливіше, це soft skills і комунікація. Важливо вміти спілкуватися, знаходити спільну мову, розв’язувати проблеми, інакше — роадмап не працює. 

Друге — для Junior і для Mega Senior набір технологій і арсенал інструментів буде однаковим. Секрет в тому, що глибина знань може бути різною. Якщо зелений інженер може поверхнево знати про процеси та  потоки Linux, то досвідчений зубр девопса знатиме й розумітиме внутрішню кухню: 

  • системні виклики для реалізації процесів і потоків; 
  • статуси процесів і їх значення;           
  • за секунду побачить типову проблему, і точно вдарить молотком, вирішивши її за 10 хвилин;     
  • знає, як роздути цю роботу на 3 дні;
  • напише fork / exec, запустить strace, підключиться bcc і ще купа всього-всього. 

Третє — потрібно вибрати свій стек, і свій набір технологій. Моя рекомендація — AWS, Terraform, Kubernetes, Prometheus Stack, EFK. Звучить просто, на ділі — адище з купи інформації, великий поріг входження і навчання не менше ніж рік. Якщо розпорошуватися і додати ще фішечок — є ймовірність закінчити навчання в той момент, коли технологія застаріла і більше нікому не потрібна. 

Де вчитися DevOps методології 

Ідеально — відразу вміти, якщо так не виходить — бажано Завантажити себе теорією з книг, і реалізацією на будь-якому pet-project. Книжки для вивчення Я дам в окремому розділі, а тут зроблю акцент на завданні, яке допоможе зрозуміти, чи вийде пройти співбесіду на позицію DevOps Engineer: напишіть додаток на Python або Go, реалізуйте 3 ендпоінта — /get, /put, /reset з відповідною логікою, суть програми — вважати запити. Запакуйте його в Docker, і запустіть в AWS EKS в кількості 100 реплік з автоскейлінгом. При зміні вихідного коду, Jenkins повинен перезібрати контейнер, і деплоїти нову версію в кластер. Кластер, звичайно, описаний в Infrastructure as a Code. Потрібно налаштувати доставку логів в окремий EFK, додати метрики в додаток (наприклад, prometheus-exporter) і налаштувати оповіщення в месенджер. Вбиваєте додаток — приходить оповіщення.

Якщо ви це зробили — супер, можна пробувати проходити співбесіди, і я даю гарантію що досвід вирішення подібного завдання буде дуже

До речі. Для поліпшення коду і рішення можна показати свої напрацювання хлопцям зі спільноти ukrops.club — завжди дуже цінні подарунки, поради, вектори розвитку. Це найактивніше і домашнє DevOps ком’юніті. Курси можна дивитися на Udemy, Pluralsight, особливо — на acloud.guru. Також дуже раджу educative.io — Learn DevOps for Developers, і обов’язково — самонавчання, stackowerflow, і всі книжки по тобі з приставкою «Deep Dive».  

Якщо ви — вже досвідчений зубр DevOps — у такому випадку варто підписатися на CNCF, Hashicorp, Monitorama конференції й чекати апдейтів. Якщо ви — DevOps Manager — в такому випадку конференція DevOps Days саме для вас. 

Що почитати — книги 

Давайте пройдемося по книгах, які must have, і в кінці я додам трохи особистих супер корисних знахідок. Поїхавши:

  1. Continuous Delivery: Reliable Software Releases — найцінніша і важлива книга для розуміння конвеєра розробки, безперервної доставки, стратегій ролаута та інших базових понять. Дуже стара (2011), але актуальна, і такий і залишиться. Класика. Читати по діагоналі — тільки для розуміння основних концепцій. 
  2. SRE Books — набір з 3 книг (багато хто думає, що достатньо однієї — ні), з реальними життєвими прикладами розв’язання проблем, реалізацією систем, архітектур і декількох інженерних підходів. З книг потрібно винести практики формування постмортемів, NALSD, SLO/SLI/SLA, підходи для resilience/recovery/disaster і т. д. Читати й перечитувати — обов’язково. 
  3. Cloud Native DevOps with Kubernetes — тут все зрозуміло, це технік про Kubernetes. Читати вдумливо, гуглити незрозумілі терміни або вирази, поставити на стіл як швидкий довідник з розв’язання проблем. 
  4. Infrastructure as Code: Dynamic Systems for the Cloud Age — теж технічна, тільки тут про Terraform — важливо, потрібно, корисно. 

Що почитати — Telegram канали 

Кращі канали про DevOps в Telegram — сам читаю, ціную і рекомендую обов’язково підписатися:  

  • Telegram-канал «ДевОпс Інженер» — я веду канал з 2018 року, 5538 підписників;
  • Telegram-канал «CatOps» — засновник Юрій Рочняк, співавтор-Максим Власов 4539 підписників;
  • Telegram-канал «Дайджест Українських Девопсів» — веде Всеволод Поляков, 2895 підписників;
  • Telegram-канал «DevOps простими словами» — канал, де Антон Кошовий з MacPaw ділиться корисними напрацюваннями, 837 підписників. 

Зарплата 

Скільки може заробляти DevOps інженер в Україні? Зовсім недавно (початок 2020) хороші інженери заробляли по $5000, а на даний час ситуація змінилася, і в середньому сильний і досвідчений Senior може спробувати потрапити на позицію з оплатою в $6000-7000. середню температуру по зарплатах можна зрозуміти на DOU.UA: перцентілі явно занижені, і в опитуваннях беруть участь не завжди найбільш високооплачувані інженери. Більш того, учасників опитування не сильно і багато, тому — питання до репрезентативності.  Статистика на даний момент виглядає ось так: 

Моє бачення останніх тенденцій ринку нашої спеціалізації виглядає так: 

  • Junior зарплати не зрушилися: $500 без досвіду, $1.500 — за джуніора, який може самостійно працювати. Вакансій більше — знайти роботу простіше. 
  • Middle підстрибнули з $2.500/ month до $3.500 — $4.500 
  • Senior виросли з $5000 до $6000 
  • Job hoppers/неетичні підходи — можуть пробувати залітати на $7000.

Важливий момент-спочатку зусилля, досягнення і результат, потім — гроші. Навпаки — не працює. 

Кар'єра для DevOps інженера 

Сильно розмиті рамки зон відповідальності дозволяють вибрати свою улюблену спеціалізацію, і стати справжнім експертом в дуже вузькій області: процеси розробки, моніторинг, контейнери, etc. 

У моїх знайомих є показові випадки за прикладом:

  • Senior DevOps -> DevOps Team Lead -> Director of Engineering 
  • Senior DevOps -> Solutions Architect -> VP of Engineering Senior DevOps -> CEO

У кожного з них своя історія, але це точно завжди історії про «values» — коли інженери показують надрезультати, і виростають з рамок своєї відповідальності. Резюмуючи, робиш більше-більше отримуєш, дуже проста істина. Наприклад, у мене вийшло дорости до Head of Infrastructure. Ще є суперський варіант перейти в SRE, якщо є особлива, сильна любов до програмування. SRE — це нова величезна тема, яку я торкнуся в наступній статті. 

Моя порада — пробувати робити акцент не на технологіях (звичайно, Я розумію, це цікаво), а змістити фокус на цінність для компанії або команди, яку вдалося принести. Відмінно працюють подібні підходи:

  1. Моніторинг і графіки (часто викликають вау-ефект і напади кидання грошей в DevOps команду).
  2. Прискорення будь-яких процесів (складання, деплоя, масштабування, etc).
  3. Контроль ресурсів та оптимізація витрат (зекономлене — зароблене)
  4. Відкриті й прозорі постмортеми (у всіх бувають проблеми, важливо -lessons learned.
  5. Робота над брендом компанії (впізнаваність дає поле для зростання, і простіший хайрінг в компанію)

Головне-йти, і у вас все вийде!

Хочете повідомити важливу новину? Пишіть у Telegram-bot.

А також підписуйтесь на наш Telegram-канал — dev.ua | IT України.

Обговорення

Коментарів поки немає.