Як я пройшов шлях у DevOps від Trainee до Senior та Team Lead. Яких помилок припустився

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

Привіт! Мене звати Керім, я DevOps-інженер з понад 10-річним досвідом у галузі ІТ, з яких близько 8 років спеціалізуюся на DevOps. Я починав із дата-аналітики, пережив досвід світчингу, коли довелося переходити з Middle-позиції на позицію Trainee. Зараз очолюю напрям DevOps у компанії VeliTech.

Усе частіше бачу, що багатьом початківцям у DevOps важко зрозуміти, які навички необхідні для просування й за що братися передусім. Тому в цьому блозі я вирішив поділитися своїм шляхом від Trainee до Senior та Team Lead. Я розповім про поширені помилки, дам поради, на що звернути увагу на кожному з етапів, підсвічу, як відбувається перехід між грейдами та чому спеціалісти застрягають на півдорозі.

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

Хочу звернути увагу: обов’язки, повноваження і стек DevOps-інженера сильно залежать від специфіки бізнесу та напряму компанії. Стек DevOps в продуктовій компанії відрізняється від DevOps в аутсорсинговій або аутстафній компанії. Мій досвід — переважно про аутсорс і продукт, і менше — про аутстаф.

Початок кар’єри

Треба повернутися на 10 років тому, це був 2014 рік. Тоді напрям DevOps Україні лише почав розвиватися. Перші курси DevOps готували саме DevOps-інженерів і мало зачіпали методологію.

Я закінчив Академію митної служби України як девелопер, мій напрям був повʼязаний з прикладним програмуванням. Розробляв прості програми, орієнтовані на роботу з даними. Почав працювати дата-інженером на позиції Junior і доріс до позиції Middle дата-інженера. Це були enterprise-бази даних, СУБД Oracle, SQL Server, Sybase.

Моє зізнання, звісно, може викликати суперечки (мовляв, у базах даних є де розвернутися), утім — у якийсь момент мені стало нудно. Крім того, мені тоді не вистачало операційного досвіду саме системного адміністрування.

Я пробував влаштуватися на роботу в п’ятірку кращих великих компаній, проходив інтерв’ю, але основний фідбек — що мені потрібно підтягнути SysOps-частину. Тому я активно почав працювати над заповненням прогалин у досвіді.

Знайшов курс, присвячений DevOps, від компанії SoftServe. Це був один з перших наборів компанії. На той момент я мало що знав про DevOps. Знав, що ця методологія зародилася не в ІТ, а початково використовувалась менеджерами для підвищення результативності.

Я зацікавився: почав читати статті, книги — зокрема «Проєкт Фенікс». Хоча це більше ліричний роман, ніж технічна книга, було цікаво. Я починав цей шлях, щоб закрити прогалини в знаннях. Але згодом, занурившись у курс і методологію, вирішив змінити спеціалізацію з дата-інженерії на DevOps.

На проходження курсу пішло 4 місяці (по три години на день 5 днів на тиждень у лабораторії). Потім відкрилася відповідна вакансія. Думаю, IT-спільнота розуміє, як боляче світчитися — особливо з позиції Middle на Trainee. Матеріально це також була втрата. Але я бачив перспективу, і мені це було реально цікаво.

Тож у 2014-2015 роках я перейшов у DevOps і розпочав свій новий кар’єрний шлях.

На той момент я ще не вмів працювати з Linux як з основною ОС, не вмів писати скрипти з нуля. Було багато страхів і внутрішніх сумнівів: а чи витримаю я? чи зможу конкурувати з молодшими за віком, які починали з DevOps з нуля? Але з часом я зрозумів, що мій бекграунд — це не мінус, а перевага. Він дав мені системне мислення, розуміння даних, досвід роботи з великими системами. І головне — навчив вчитися.

Мої перші кроки в DevOps

Те, що говорили про DevOps у 2013-2014 роках, геть відрізняється від того, чим він є тепер. Це було щось нове, що цікаво спробувати. Я добре розумів, на що йду, і які компроміси доведеться прийняти, але внутрішнє відчуття підказувало: за DevOps — майбутнє, і згодом напрям стане ключовим для індустрії. Передусім мене мотивувала інженерна цікавість.

На позиції Trainee я пробув 3-4 місяці, потім перейшов на позицію Junior DevOps-інженера.

Я досі пам’ятаю перше завдання, яке мені доручили — автоматизувати деплой простого вебзастосунку. Це був Jenkins і купа shell-скриптів, які я тоді писав як «поет у темряві», методом проб і помилок. Але саме це дало мені перше відчуття контролю: я натискаю кнопку — і щось працює. Це було величезне джерело мотивації.

З викликів — у 2014-2016 роках не настільки був популярним cloud. Ринок приблизно ділився 70 на 30. 70% — так званий private cloud, тобто власні дата-центри. І лише 30% — cloud, що лише набирав обертів. Крім того, тоді cloud-технології не мали такої кількості інструментів, які покривають потреби Solution-архітекторів, зокрема DevOps.

Коли я починав, мені потрібно було занурюватися в базові SysOps-теми (мережі, як працюють віртуалізації, операційні системи, як збирати кластери). Я впевнений, що зараз, при наявності cloud-технологій, багато DevOps-інженерів навіть особливо в це не заглиблюються. Вони можуть натиснути п’ять кнопок, і в них з’явиться приватна мережа й побудований VPN-тунель з’єднання.

Тоді ж багато роботи було через командний рядок, скрипти (Bash, Python, Shell). Пізніше з’явилися тулзи конфігураційного менеджменту, як-от Ansible, Puppet, Chef.

Однак зараз розумію, що знання OSI-моделі, протоколів IPv4, IPv6, TCP/IP — це база в частині нетворкс, яку має мати будь-який operations-інженер (DevOps, SysOps, AppsOps, SecurityOps) й навіть частково девелопер.

Поради для Junior у DevOps

Навчитися працювати з документацією, читати її. 80% майбутньої роботи — це розбиратися, орієнтуватися і розуміти документацію різної якості.

Освоїти базові теми — мережі, бази даних (хоча б адміністрування баз даних — які існують види баз даних, як їх підняти, які параметри у движках баз даних є, на що вони можуть вплинути, як правильно розвернути ту чи іншу базу даних).

Щодо application lifecycle management — зануритися в специфіку мови, на якій розробляється застосунок, зрозуміти її недоліки та особливості. Якщо йдеться про високорівневі мови, наприклад, Java, добре мати розуміння, як працює JV-машина та application-сервери.

Концептуально зрозуміти, як працює Continuous Integration і Continuous Delivery — на якому етапі який процес завершується, що таке CI, що таке CD, де закінчується CI, де починається CD, що є результатом роботи CI. Як правило, за карʼєру у вас буде змінюватися більш як 5-6 інструментів CI- чи CD-частини, але у всіх закладена базова концепція Application Life Cycle Management (Continuous Integration, Continuous Delivery і Continuous Deployment — залежно від тої стратегії, яка вибрана на вашому продукті).

Розібратися з хмарними технологіями. Вибрати якийсь один із трійки популярних клауд-провайдерів і базово розібратися в інструментах, які він дає.

Розвивати софт-скіли. Роль DevOps — комунікація між відділами, які мають конфлікт інтересів. Так, Development Department повинен щось постійно покращувати й змінювати. Operations Department відповідає за те, щоб все працювало стабільно, тому не зацікавлений в тому, щоб щось мінялося. DevOps має знаходити баланс і забезпечувати безперервний процес. Також важливий нетворкінг усередині комʼюніті, обмін досвідом.

А інше — configuration management, оркестрації, infrastructure as a code — це вже буде залежати від специфіки проєкту, стеку конкретної компанії або корпоративного стандарту.

Є жарт в IT: хто такий Junior? Junior — це людина, яка має навчитися працювати. Від неї не вимагається уміння ухвалювати важливі рішення, вона просто має виконувати рутинні завдання. Будь-яка її робота буде перевірятися ментором або Team Lead.

А якщо завдання будуть виконані якісно й не породжуватимуть якихось додаткових проблем — це взагалі знахідка. Хорошими рисами для Junior є ініціативність, старанність і допитливість. Ідеально, щоб людина не просто виконувала технічне завдання, а й намагалася зрозуміти, навіщо це й на що впливає, не боялася ставити запитання.

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

Ще один важливий момент — це вміння ставити правильні питання. Коли ти джун, дуже легко впасти в синдром самозванця і боятись виглядати «дурним». Але правда в тому, що хороші питання — це маркер зрілості. Якщо ви питаєте — значить, хочете розібратись. Це цінно.

Хто такий Middle

Стрибок між Junior і Middle зайняв у мене приблизно два роки.

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

На Middle-позиції зростає автономність і довіра з боку команди. Завдання стають масштабнішими, можуть зачіпати кілька департаментів і впливати на роботу системи чи продукту. Це перший крок до Senior-позиції. Middle-інженер — це той, хто вже навчився працювати.

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

У цьому грейді я навчився «продавати» свої рішення. Раніше я просто виконував те, що потрібно. А як Middle я почав аргументувати вибір інструментів, будувати Proof of Concept, пояснювати ризики. Це вже була не просто реалізація — це був інженерний вплив.

Хто такий Senior

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

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

І таким чином я прийшов у VeliTech 5 років тому. Шлях від Senior до Team Lead тривав 1,5 року. На позиції Team Lead я пробув, мабуть, 2,5 року. І зараз — більш як рік — я на позиції Head of DevOps, курую напрямом DevOps у компанії.

Передусім Senior-позиція — це про автономність. Фактично це Middle-інженер, який має ще глибше зануритись в технічні деталі технології та вміти працювати самостійно. Senior бере завдання і виконує його від початку до кінця. Це людина, яка має своє бачення розвитку певного напряму.

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

Крім того, Senior має вміти менторити своїх колег. Він повинен допомагати піднімати їхній рівень, особливо в тих аспектах, які Junior чи Middle можуть не помітити. Senior має більше досвіду, тому його завдання — перевіряти роботу тіммейтів, звертати увагу на потенційно проблемні місця та допомагати уникати помилок.

Одна з порад для Senior — не надто суворо ставитися до помилок підопічних. Знаходити баланс між критикою і підтримкою, щоб не демотивувати людину.

Senior — це не той, хто «все знає». Це той, хто знає, де шукати, як думати, і що робити, коли не знаєш. Це вміння не тільки будувати рішення, а й зменшувати складність, робити команду сильнішою — через менторство, документацію, через автоматизацію рутин.

Помилки, які роблять всі, і я зокрема

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

Діяти без погодження, навіть із найкращими намірами

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

Мій факап. Коли я починав, працював над великим ентерпрайз-проєктом зі специфічним стеком на основі Erlang і not only SQL data storage. Це рідкісна технологія з мінімально розвиненим ком’юніті, тому будь-які зміни потрібно було вносити дуже обережно, орієнтуючись лише на документацію, адже порадитися майже не було з ким.

Я працював з React-кластером і мав виконати його апгрейд із реальними даними. Для підготовки я підняв тестовий кластер, щоб потренуватися перед застосуванням змін на продакшн. Але через постійні стреси на той момент спрацював людський фактор: я помилково запустив Configuration Management Tool в Ansible, направив не на той environment і провів неконтрольований апгрейд продакшн бази даних. Це було дуже ризиковано.

На щастя, даунтайму і наслідків не було, я це все-таки проганяв на тестовій площадці на локальному комп’ютері. Але сам факт неконтрольованого релізу, який міг вплинути на роботу фінансової структури, залишився. Це одна з ситуацій, за яку мені досі соромно.

Робити щось руками

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

Однак часто буває таке, що люди стикаються з труднощами в коді, особливо в стресових ситуаціях або під тиском таймінгів. Тоді виникає спокуса «швидко зробити руками», щоб потім виправити. Але це одна з найбільших помилок і ризиків.

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

Мій факап. У нашій компанії, коли я починав працювати, був самописний інструмент Continuous Integration/Continuous Delivery, побудований на Jenkins Scripted Pipeline. Він базувався на великій і заплутаній shared-бібліотеці.

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

Одного разу, коли я вже був на позиції Senior, мені потрібно було терміново розібратися, виправити проблему і внести зміни до бібліотеки для продакшну. Через поспіх я випустив один важливий кейс, не до кінця протестував зміни й запустив їх. У результаті це стало неконтрольованим впливом на продакшн-систему, що спричинило даунтайм частини критично важливих сервісів.

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

Як компанія вирішує, що співробітник готовий перейти на новий грейд

Особисто я не підтримую ідею прив’язки до стажу. Наприклад, щоб бути Middle-спеціалістом, не обов’язково мати три роки досвіду, оскільки кожен може проходити ці роки по-різному. Хтось може виконувати одну і ту ж задачу і не отримати потрібного досвіду. Тому оцінка готовності перейти на новий рівень має бути ситуативною.

Водночас я не прихильник виключно суб’єктивних оцінок. Коли Team Lead вирішує, що співробітник готовий до підвищення, це може бути спонтанним рішенням, продиктованим настроєм чи одиничною ситуацією.

Ми з командою прагнемо уникати таких оцінок і впроваджуємо прозорі методи. Проводимо щорічне performance review, за результатами якого складається індивідуальний план розвитку (IDP). В ньому прописуються конкретні цілі, терміни та рекомендації щодо розвитку технічних і софт-скілів. Це дозволяє кожному розуміти, які скіли потрібно розвивати для переходу на новий рівень.

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

Чому люди застрягають на пів дорозі

Переважно через вигорання. Думаю, кожен стикався з цим, і я також мав таку проблему. Особисто я бачу це тісно пов’язаним із балансом між роботою та особистим життям (Work-Life Balance). Початківці часто намагаються довести свою цінність через оверперфоманс. Така практика стає звичною, і тільки питання часу — коли врешті людина вигорить.

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

І третє — відчуття, що досягнуто вже достатньо. Важливо постійно залишатися «голодним» на нові знання та навички. Це допоможе уникнути стагнації й рухатись вперед до нових кар’єрних вершин.

Висновок

У цьому матеріалі я спробував на прикладі власного досвіду показати, як пройти шлях від Trainee до Team Lead у DevOps, на що потрібно звернути увагу на кожному з етапів, як проходить перехід між етапами та яких помилок варто уникати.

Головний урок, який я виніс: DevOps — це не лише про технічні інструменти чи методологію. Це про мислення, сміливість змінювати себе й готовність не здаватися. Кар’єрний шлях у цій сфері — це марафон, а не спринт.

І найголовніше: якщо щось дійсно цікавить і надихає вас, не бійтеся починати спочатку, навіть якщо це потребує відмови від комфорту. Адже саме такі рішення допомагають рухатися вперед.

FAQ

Як не розгубитися у виборі стеку

Багато початківців паралізує кількість інструментів у DevOps. Корисно знати:

Що брати першим — інструменти, які майже всюди:

Linux, Bash, Docker, Git;
один хмарний провайдер (AWS або GCP);
CI/CD (GitLab CI, GitHub Actions, Jenkins);
базовий IaC (Terraform або Ansible).

І що не обов’язково на старті:

Kubernetes (можна торкнутися, але не лізти в прод одразу);
Helm, Prometheus, CloudFormation тощо.

Рекомендація: не намагайтесь вивчити все одразу. Навіть Senior не знають «усе». В DevOps важливо навчитися думати як інженер: що автоматизувати, як логічно будувати процеси. Стек — це інструмент, а не ціль.