Мої кроки на шляху до DevOps Engineer. Історія про пошук і зміну роботи

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

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

У цій статті розповідаю про мій кар’єрний шлях, які перешкоди траплялися, скільки компаній змінив і чому їх змінював, що вивчав для кожної з позицій. Сподіваюсь, це буде цікаво та корисно іншим початківцям в ІТ і тим, хто хоче розвиватися в DevOps.

Компанія номер 1 — перша серйозна робота

На мій погляд, свій повноцінний шлях в ІТ я розпочинав у 2015 році, під час денного навчання у тепер уже Дніпровському політехнічному університеті. Тоді я, як інженер підтримки чи системний адміністратор, пройшов свою, хоч і не велику, але все ж технічну співбесіду.

Співбесіда. Основні вимоги до позиції сапорт-інженера були на той момент:

• адекватність;
• знання апаратної частини комп’ютера;
• базове розуміння мереж;
• знати хоча б одну схему обтиснення кабелю;
• і, звичайно ж, вміння налаштовувати принтера, куди ж без них.

Співбесіда пройшла успішно. Оскільки це була перша серйозна робота, вирішив для себе, що з будь-якого місця, де я працюватиму, я повинен виносити щось корисне для себе, і приносити максимальну користь роботодавцю. Як інакше тоді рости?

Примітка/порада: на той момент я не уявляв, де і ким я хочу бути, але розумів, що мовчки програмувати я не хотів.

Почав знайомитись із Linux. У компанії він майже не застосовувався, але були люди, котрі його знали.

Що вивчав у компанії 1:

• навчався комунікувати;
• навчався дивитися в корінь проблеми та вигадувати рішення, а не просто виконувати команди. Це могли бути різні завдання — від автоматизації до прокладання кабелів;
• вивчав Linux, налаштувавши собі робочий комп’ютер, і намагаючись виконувати рутинні речі саме на ньому (від себе додам, що було боляче);
• вивчав bash;
• вивчав англійську мову.

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

Компанія номер 2 — перша цікава робота

Пропрацювавши в першій компанії півтора року, отримав офер у другу компанію, яка займалася розробкою браузерних ігор, на посаду системного інженера/ адміністратора.

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

Примітка/порада: на запитання, на які ви не знаєте відповіді, не відповідайте «не знаю». Краще відповісти, наприклад, так: «Дозвольте мені записати це питання/ кейс, тому що я не мав досвіду роботи з цим/ подібним інструментом/ кейсом, але вирішив би це завдання/ кейс ось так», і пропонуєте своє рішення з поясненням, чому саме так.

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

Що вивчав і з чим працював у компанії 2:

• продовжив заглиблюватися в Linux;
• став працювати та конфігурувати сервери;
• познайомився з пайплайнами;
• познайомився з процесами розробки, у нас була щось подібне до agile і все це було в Jira;
• займався просто автоматизацією на bash;
• познайомився з хмарами;
• робив свої перші міграції сервісів компанії;
• вивчав як працює Acrive Derectory, знакомився с софтом за допомогою якого ведеться облік обладнання, займався покупками заліза та подальшим оновленням як серверів, так і офісного обладнання;
• вивчав англійську мову.

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

• Linux;
• автоматизація;
• магічні пайплайни;
• хмари.

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

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

Пропрацювавши рік у компанії номер 2, я періодично почав отримувати інші пропозиції. Приємне почуття, що на твій досвід є постійний попит.

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

До цього часу періодично ходжу на співбесіди, щоб тримати себе у формі.

Примітка/порада: вміння себе продавати — це окремий скіл, не менш важливий, ніж ваші технічні навички.

У результаті, я одержав наступний офер.

Компанія номер 3 — велика та розгалужена

Завжди манила атмосфера великих компаній. Потрапив у невелику команду сапорт-інженером, але рівень нижче, ніж будь-коли, де я працював (L3).

Треба вже було вміти розумітися на sql-скриптах, займатися автоматизацією.

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

Основні вимоги були:

• впевнені знання Linux;
• базове розуміння sql-запитів та розуміння як працюють бази, як керувати правами та інше;
• досвід в автоматизації;
• вміння вести зрозумілу та просту документацію;
• надання сапорту для команди розробки.

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

Що вивчав у компанії номер 3:

• автоматизацію з допомогою jenkins;
• sql;
• agile;
• Python;
• bash;
• продовжував заглиблюватися у Linux;
• англійську мову, але тепер вже застосовував її на практиці з користувачами та у документації.

Примітка/порада: все нове — це страх, і це нормально. Бійся, але роби.

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

На той момент стало ще очевидніше, чим мені все ж таки хотілося займатися.

Примітка/порада: якщо у вас є розуміння, ким хочете бути, але не знаєте, що вчити, відкрийте, наприклад сайт з пропозиціями про роботу, як от jobs.dou.ua, виберіть кілька відповідних вакансій за спеціалізацією, яка вас цікавить, та визначте, чи є вимоги, в яких у вас мало досвіду — їх і вивчайте.

Компанія номер 4 — складнощі внутрішнього переходу

Маючи досвід роботи в компанії з ім’ям, було легше шукати роботу. Спробувавши дві співбесіди на DevOps-інженера, зрозумів, що я ще трохи не дотягую. Але оскільки всі свої прогалини зазначав, була певна подібність плану, за яким можна було вчитися.

Тоді відправив резюме на сапорт/системного інженера до чергової великої компанії, де я тоді хотів працювати, та отримав офер. Мені здавалося, що в таких великих компаніях можна не погано вирости.

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

Основні вимоги були:

• Знання Active Directory;
• Знання Linux;
• Знання апаратної частини комп’ютерів/ серверів;
• вміння працювати зі світчами;
• знання мережі.

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

Співбесіда на DevOps-інженера. Основні вимоги були:

• знання Linux;
• знання ci/cd;
• хмари;
• розуміння infrastructure as code;
• розуміння ansible;
• розуміння bash;
• принципи DevOps.

І тяжкі кілька днів очікування та довгоочікуваний офер на DevOps-інженера.

Примітка/порада: якщо ви хочете чогось навчатися, краще приділяти час потрохи, але регулярно. Тобто 30-60 хвилин на день можуть бути ефективнішими, ніж раз на тиждень виділити 3,5-7 годин на навчання. За тривалі перерви можна загубити контекст.

Після отримання офера, настав момент ейфорії, який одразу і закінчився. Виникли деякі складнощі з переходом усередині компанії в інший департамент, що мене сильно засмутило.

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

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

Так і зробив, і десь через 4-5 спроб отримав офер в компанію номер 5.

Компанія номер 5 — розвиток продовжується

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

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

Основні вимоги були:

• знання теорії;
• розуміння ci/cd;
• розуміння infrastructure as code і досвід з якимось інструментом, у мене був ansible і cloudformation;
• вміння працювати з хмарами;
• знання Linux;
• знання якоїсь скриптової мови, у мене був bash;
• розуміння мереж.

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

Замiсть висновку

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

Корисні матеріали (стосовно DevOps-напрямку)

• Google SRE Books — безкоштовнi книжки вiд Google дались важко, але без цього нікуди.
• The Linux Command Line — є кілька видань цієї книги, для напрацювання бази підійде будь-яка, головне практика.
• Вправи з інструментів DevOps.
• DevOps роадмап на Github.
• Періодична таблиця інструментів DevOps.
• Нетворк Чак популiстично розповiдає про технології.
• Принципи успіху Рея Далі(мотивацiйне).