Гайд для DevOps: навички, ресурси, поради для побудови кар’єри

Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!

Усім привіт! Мене звати Іван Ревчук, я Head of Infrastructure української IT-компанії Brainstack_. Свою кар’єру в ІТ я розпочав понад 10 років тому із системного адміністратора. Згодом я перейшов у DevOps, розвинувся у цій ролі та став лідом. У статті я поділюся головними скілами, які варто прокачати, аби стати затребуваним фахівцем з DevOps.

Якщо ви вже працюєте DevOps, не поспішайте закривати вкладку. Тут я також поділюсь ресурсами, які допоможуть вам розвиватися у цій ролі та отримати підвищення.

Хардскіли для роботи DevOps-інженера

Професія DevOps-інженера перебуває на перетині розробки, тестування, адміністрування та менеджменту. Універсального набору навичок, які б відчинили вам двері в усі компанії відразу, не існує. Усе залежить від технологій та підходів кожного бізнесу. Тому раджу почати з вивчення базових навичок, а потім прокачуватися під вимоги конкретної компанії.

Усі необхідні навички можна розділити на п’ять основних компонентів: Linux, DB, Networking, Development, Cloud. Серед базових скілів, якими має володіти кожен DevOps:

  • поглиблене знання Linux;
  • знання мережі, повне розуміння моделі OSI. Вміння налагоджувати, профілювати та вирішувати мережеві проблеми;
  • досвід роботи з контейнерами та віртуалізацією з використанням Docker, LXC, KVM/QEMU, VMWare;
  • знання основних компонентів Kubernetes: kube-apiserver, kube-scheduler, kube-controller-manager, kube-proxy тощо;
  • знання реляційних і нереляційних баз даних (MySQL, PostgreSQL, Elasticsearch, MongoDB, тощо);
  • досвід роботи з системами моніторингу та збору логів: Zabbix, Grafana, Sentry, ELK stack, Prometheus;
  • досвід роботи з програмним забезпеченням для автоматизації, таким як ansible, puppet або chef;
  • знання локальних інструментів для моніторингу та усунення проблем: tcpdump, ss/netstat, mtr, vmstat, iostat, top, sar, free, pmap, ps, lsof, strace, iproute2 утиліти;
  • вміння писати складні скрипти (shell/python);
  • знання будь-якої хмарної платформи (AWS, GCP, Azure);
  • впевнене володіння принайні однією мовою програмування (Python, Go, PHP, Rust тощо).

Новачку перш за все важливо зрозуміти, як працює структура, а не застрягати у вивченні кожного окремого інструмента. Краще зорієнтуватися в арсеналі навичок допоможуть «дорожні карти».

Джерело

Головні софтскіли для DevOps

Якби мене попросили виокремити найважливішу навичку DevOps, я б назвав уміння працювати в команді. DevOps-інженер — це про постійну комунікацію: із девами, стейкхолдерами, менеджментом і клієнтами.

Наведу свіжий приклад, як мені знадобився цей скіл. До 2022-го року кожна команда розробки у Brainstack_ працювала за своїми підходами та flow. Це було зручно в моменті, але глобально спричиняло ризики та незручності. Тому ми вирішили повністю оновити процес CI/CD в компанії, стандартизувати його для всіх команд, але надати можливість вносити окремі зміни на рівні команди або сервісу.

Так ми запровадили оновлений deploy flow. Він повністю будувався в GitLab з використанням gitlab-ci. Це надало девам єдине оточнення для зберігання, тестування та деплою коду.

Звучить логічно та круто, але втілення цієї ідеї вимагало великої кількості переговорів. Я годинами спілкувався з лідом кожної команди, збирав інформацію й аргументи, доводив, чому оновлення необхідне, розповідав про плани та все погоджував.

Серед інших важливих навичок — вміння самостійно ухвалювати рішення, аналітичне та критичне мислення. DevOps-інженер повинен чітко розуміти, чи варто впроваджувати ту чи іншу технологію/інструмент (eBPF, WebAssembly, OpenAI-рішення тощо), або ж можна обійтися без неї, бо це не дасть значного value для бізнесу.

Аби робити ефективні зміни, фахівець має досконало розуміти, які сервіси зараз використовує компанія, та постійно експерементувати з конфігурацією та оптимізацією, аби взяти від них максимум. Наприклад, від зміни конфігурації СУБД можна збільшити перфоманс в десятки разів.

Саме тому перед зміною технології варто поставити собі просте питання: «Для чого?». Зміни мають приносити реальні переваги для бізнесу, а не бути самоціллю. З досвіду я бачив, як компанії змінювали СУБД, системи моніторингу, мови програмування, наймали нові команди, але проблеми з продуктивністю та втратами для бізнесу залишалися через відсутність зваженого підходу.

DevOps-інженер має постійно балансувати між швидкістю, якістю, безпекою, ефективністю, надійністю, зручністю та продуктивністю, ухвалюючи рішення з урахуванням всіх факторів.

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

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

Роботодавці більш зацікавлені в DevOps-інженерах, які пройшли шлях від helpdesk до сисадміна, трохи попрацювали Linux-адміном, Net-адміном або DB-адміном, в процесі ще написали свій pet-проєкт будь-якою мовою програмування.

Це показник того, що фахівець розуміє можливості інфраструктури, має навички комунікації з девелоперами, користується офіційною документацією.

Досить органічно можна перейти в DevOps з ролі тестувальника чи розробника. Ці фахівці вже володіють певними важливими навичками, які знадобляться у майбутній професії.

Наприклад, тестувальники мають досвід автоматизації та розуміють мови програмування, вміють тестувати інфраструктурні зміни, взаємодіяти з розробниками, знають DevOps-тулсет для моніторингу. До того ж, їхній склад мислення дозволяє прорахувати більшість edge-кейсів перед деплоєм у прод.

Щодо розробників, то їхня в перевага у розумінні, що можна «викосити» з етапу збирання програми, вмінні виправити код конфігурації, швидко додати нові метрики чи нову бібліотеку, а також полагодити баг в опенсорсних DevOps-тулах.

Мати такі скіли — цінно, але все ж вчитися доведеться. Незалежно від вашого бекграунду, краще почати з базових речей: Linux, Networking, DB. Це та основа на якій будується весь сучасний цифрорвий світ.

Наступний крок — курси на Udemy, Pluralsight, acloud.guru та educative.io. Вони будуть доповненням до базових речей і дадуть конкретику вже в розрізі сервісів, які використовуються в DevOps.

Ось декілька прикладів корисних програм:

Одні лише курси не забезпечать вас роботою. Вони дають лише базове розуміння про процеси, підходи й інструменти в DevOps, а також напрямок роботи — наприклад, як зробити так, щоб ваш сайт розгортався в AWS-клауді. Після курсів у вас ще залишиться багато gapʼів у знаннях. Потрібно буде багато самостійно розбиратися, читати й пробувати.

Обов’язково ознайомлюйтеся з офіційною документацією сервісу, з яким ви розбираєтеся — там міститься найбільш детальна інформація. Ченджлоги при оновленнях — теж must read. Так ви краще зрозумієте нові можливості та убезпечите себе від ризику падіння після оновлення.

Бонус: корисні книги, сайти та канали DevOps-інженеру

Зібрав корисні сайти, літературу та канали в Telegram і на YouTube, які допоможуть прокачати навички та опанувати нові інструменти DevOps-інженерам. Ресурси будуть корисні як новачкам, так і профі, які прагнуть розвиватися.

Сайти:

Книги:

Telegram- та YouTube-канали:

  • CatOps — Telegram-канал девопсів з України, де зібрані апдейти нових версій інструментів, закордонні статті, авторські огляди та інформація про тематичні івенти.
  • Неправильний DevOps — подкасти про DevOps та SRE.
👍ПодобаєтьсяСподобалось9
До обраногоВ обраному13
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

За статтю дякую, зі свого боку я б додав до софт скілів — психолог, дипломат, політик і головний скілл — Оракул + Телепат :)

DevOps-інженер — це про постійну комунікацію

Девопсам треба комунікувати не більше, ніж розробникам чи тестерам.

Припускаю, звідки ноги ростуть у цієї помилкової думки: оскільки хмарних сисадмінів обзивають назвою методології, яка передбачає тісну комунікацію між командами, то й автоматично приписують нам цю «комунікацію» як функцію.

вам доведеться пройти всі кола пекла

Нащо лякати людей? Природнього і стійкого зацікавлення ОС і серверами цілком достатньо. На «кола пекла» аж ніяк не тягне.

До війни взагалі гребли всіх підряд. Зустрічав джунів, які не вміють у Баш, але нині то рідкість (як і джуни).

Девопсам треба комунікувати не більше, ніж розробникам чи тестерам.

З мого і не лише мого досвіду набагато більше, бо оновлення умовного eks кластера потребує консолідації різних команд і людей, зазвичай у великому проекті цим займається тех лід девопс, або якийсь девопс груп менеджер, звичайному джун-мідл воно не потрібно, але якщо ти відповідаєш за інфру, деплой, білд, тест etc — спілкування буде багато. Якщо проект великий, яким користується млн юзераів — спілкування буде ще більше.

Нащо лякати людей?

тому що це факт :)

— був у тебе ArgoCD старий, вирішив ти його оновити і почалось — випиляли певні параметри, перенесли їх в окремі конфіги
— був у тебе Jenkins, оновив ти його через Helm у своєму кластері, а він не встає, тому що maintainer чарту не вважає за потрібне перевіряти сумісність модулів і починаються танці з прибиванням цвяхами версій у values...
— був у тебе кубік а Амазоні, прийшов час його оновити і почалось — докер випиляли, деплойменти були в кластері кубіка через Jenkins з примонтованим docker, якого немає, тобто у тебе посипляться всі білди...
— почав у тебе сипатись білд фронта по OOMKIller і починається футбол як його оптимізувати, чи додавати ресурсів чи брати окремий сервер чи деви мають почати займатись оптимізацієй
— приходить до тебе лід девів і каже — набуя нам те лайно Jenkins ми хочемо TeamCity, ми ж велика компанія і хочемо щось платне, а не опенсорс...
Таких прикладів тьма і це часто пекло і саме цьому порог входу на рівень адекватний дуже високий

До війни взагалі гребли всіх підряд

ну потім менеджери за голову хватаються і не розуміють що їм робити і шукають досвідчених. В цілому завдяки таким рішенням у нормальних пацанів завжди буде робота :)

Девопсам треба комунікувати не більше, ніж розробникам чи тестерам.

Посперечаюсь конкретно з цим. Сильно залежить від культури компанії, і я вірю що десь в ідеальному світі Tech Lead дає гарну мапу інфраструктури, бек дає Docker Container і детальну інструкцію як розгорнути його застосунок, а фронт не забув сказати що воно написано на Next.js і прийдеться трошки потанцювати з Amplify... але так далеко не завжди.

DevOps як і будь-яка сервісна роль вимагає більше комунікації ніж конвеєрні ролі типу Developer бо взаємодіє він з багатьма аспектами системи. Ну і DevOps доволі часто працює з декількома командами що автоматично збільшує кількість комунікацій.

Роботодавці більш зацікавлені в DevOps-інженерах, які пройшли шлях від helpdesk до сисадміна, трохи попрацювали Linux-адміном, Net-адміном або DB-адміном, в процесі ще написали свій pet-проєкт будь-якою мовою програмування.

Пилосос джунів вайтішників

Десь я на доу ці діагоами ьачив
Разів 5.

Ну якщо вже до ліда довлужився

Гайд для ПРАКТИК DevOps

Підписатись на коментарі