Від секретаря суду до DevOps-інженера: через досвід, помилки та усвідомлений вибір

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

Мене звуть Дмитро Калиновський. Я DevOps Engineer. Загалом працюю в IT близько 7 років, а загальний стаж — 11 років. Колись я працював у суді, потім — у техпідтримці, пробував себе в QA та SMM, а тепер я DevOps-інженер. Мій кар’єрний шлях був далекий від прямолінійного, але кожен етап дав мені цінний досвід. Якщо ви замислюєтесь про зміну професії, але не можете зробити перший крок — розповім, як я впорався з цим викликом і що дізнався дорогою.

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

Мій професійний шлях розпочався досить рано: вже на першому курсі юридичного факультету я влаштувався працювати секретарем суду.

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

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

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

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

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

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

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

Перший крок в IT: Інженер технічної підтримки

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

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

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

Виклики та ключові уроки

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

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

16-17 травня, Київ. Квитки тут!👇

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

Однак згодом я помітив, що довгі зміни (зазвичай по 12 годин, а інколи й більше) та постійна напруга почали переважувати задоволення від вирішених завдань. Перепрацювання не оплачувалися, а енергія, яку я вкладав, не поверталася ані у вигляді визнання, ані у вигляді грошей. В якийсь момент я вигорів. Багато моїх друзів також звільнялися, і це лише підсилювало відчуття невизначеності: що далі? Чіткого «останнього випадку» не було — скоріше, з’явилася можливість змінити сферу, і я вирішив нею скористатися. У той час мій найкращий друг працював в інтернет-магазині, і в них якраз відкрилася вакансія SMM-спеціаліста...

Занурення в SMM: пошук себе і зіткнення з рутиною

Після вигорання в техпідтримці я все ще шукав справу, яка б мене запалювала. Думка про те, що доведеться вчитися чомусь новому, ніколи мене не лякала — навпаки, це підштовхувало. Коли мій найкращий друг запропонував спробувати себе в SMM в інтернет-магазині, де він працював, я вирішив: чому б і ні? Можливість працювати пліч-о-пліч з близькою людиною надихала, і я з ентузіазмом погодився.

Очікування були величезні. Я нічого не розумів ні в SEO, ні в SMM, але горів бажанням розібратися і показати результат. Мені здавалося, що це буде творча робота, де я міг би проявити себе, освоїти щось абсолютно нове і, можливо, знайти своє покликання.

Мої обов’язки виявилися досить різноманітними. Я займався контент-наповненням: прописував плани виходу постів у блог, додавав нові товари на сайт, знімав і монтував відео для YouTube-каналу магазину. Роботи було багато, і спочатку це мене захопило. Поки я поринав у нову для себе тему, стрес, звичний по техпідтримці, відступив. До того ж колектив був невеликим і затишним — нас було всього четверо, і ми добре проводили час разом. Атмосфера в команді була теплою, що сильно відрізнялося від напружених буднів у підтримці.

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

В якийсь момент я зрозумів, що не хочу більше витрачати на це ні дня. Знімати відео, закуповувати посилання, займатися сайтом — все це перестало мене чіпляти. Я прийшов до власника і чесно сказав: «Я більше не хочу цим займатися». І пішов. Без плану, без наступного кроку — просто в порожнечу. Десь місяць я нічого не робив, насолоджуючись перепочинком і намагаючись зрозуміти, що далі. Але тут грянув ковід, і реальність швидко нагадала про себе: потрібно було думати, як продовжувати забезпечувати себе і сім’юю

Повернення в техпідтримку: новий погляд і старт саморозвитку

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

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

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

У цей період я почав дивитися на техпідтримку по-іншому. Досвід у SMM, хоч і невдалий, дав мені розуміння того, як важлива чітка комунікація з замовниками — я став краще пояснювати їм суть проблем. А знайомі завдання з ПО та базами даних тепер здавалися легшими: я вже знав, де шукати рішення, і почувався впевненіше. Але головне — я зрозумів, що не хочу залишатися на цьому рівні. В якийсь момент я підійшов до керівництва і сказав: «Хочу рости далі. Що можна зробити?»

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

Паралельно я не сидів, склавши руки, в техпідтримці. Разом з колегами, багато з яких до цього часу залишаються моїми друзями, ми почали впроваджувати прості Bash- та Python-скрипти, щоб автоматизувати рутинні завдання для одного з клієнтів. Це був мій перший крок до роботи з інфраструктурою. Виходило так, що я розвивався одразу у двох напрямках: як майбутній QA і як інженер, який спрощує процеси. Тоді я ще не знав, що саме цей коктейль навичок визначить моє майбутнє в ролі DevOps.

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

Інфраструктурна підтримка в QA і шлях до DevOps

Власне, я почав активно шукати роботу, відгукуючись на вакансії в QA. Але я не зациклювався лише на цьому — з цікавістю вислуховував пропозиції рекрутерів, був відкритий до нових можливостей. Одного разу мені запропонували співбесіду на роль сапорт-спеціаліста. Я спробував, але з ряду причин не підійшов. Однак у HR була пропозиція: вона знала колегу, якому мій набір навичок міг би бути корисним.

Так я дізнався про вакансію в команді QA — спеціаліста, який слідкував би за працездатністю тестового середовища. Це було наче створено для мене: я любив таку роботу, до того ж вже розбирався в тестуванні. Коли я отримав офер, а потім побачив суму компенсації, радості не було меж.

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

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

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

За три роки я виріс у практиках DevOps: автоматизація, інфраструктура, взаємодія з командами стали моїм полем. Це був досвід, близький до сучасної розробки — з релізами, CI/CD і реальними задачами. Я зрозумів, що це моє.

DevOps: усвідомлений вибір і нові горизонти

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

Я зрозумів, що потрібно знову актуалізувати знання та шукати нові горизонти. Записався на курси DevOps і почав впроваджувати нові процеси на поточному місці — наприклад, автоматизацію, яка могла б стати в пригоді на майбутній роботі. Паралельно вивчав ринок: які технології в тренді, що потрібно підтягнути, з чим я вже працював або міг адаптувати. Jenkins, Kubernetes і контейнери стали моїми цілями — я занурювався в них через курси та практику, хоч це і давалося з труднощами. Одного разу HR з нової компанії запропонував співбесіду з офісною роботою. Я віднісся скептично, але коли дізнався, що офіс — той самий, де я працював до війни, і який обожнював, вирішив, що це знак. Пройшов етапи співбесіди й отримав офер.

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

Підсумок та поради тим, хто хоче змінити професію

Шлях від секретаря суду до DevOps був непростим, але захоплюючим. Найскладніше — моменти сумнівів: чи на своєму я місці, чи роблю все правильно, чи це мій максимум? Але кожен етап навчив мене чомусь важливому. Відповідальність з державної служби, комунікація з техпідтримки, наполегливість з QA — все стало в нагоді. Головне, що допомагає щодня — не боятися нового та бути готовим до викликів.

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