В начале карьеры может казаться, что для перехода с junior-уровня на middle достаточно выучить новые инструменты или просто набить пару лет опыта. На практике всё решает не только техническая база, но и мышление. То, как вы смотрите на задачу: просто «закрыть тикет» или понять, как ваше решение встроится в систему и повлияет на соседние компоненты.
Я Алексей Сартаков, тимлид команды DevOps-инженеров во «Фланте». За годы работы вижу одну закономерность: быстрее растут не те, кто знает больше, а те, кто умеет видеть связи, вовремя задавать вопросы и брать ответственность за результат, а не только за строчку в манифесте чарта.
В этой статье разберу типичные ошибки, которые тормозят junior-инженеров, дам конкретные советы, как менять подход к работе, и расскажу, как мы помогаем инженерам расти внутри компании. А в конце найдёте ссылку на вакансию. После прочтения вы поймёте, каких специалистов мы ищем, и сможете сами оценить, подходим ли мы друг другу.
Переход происходит в сознании, а не в резюме
Как меняется подход инженера с ростом грейда
Представим трёх инженеров разного уровня, которые решают одну и ту же задачу — кубернетизацию нового приложения. Все три выполнят её, но совершенно по-разному.
Junior видит только свою задачу
Junior получает поручение кубернетизировать приложение. Фокус узкий: нужно, чтобы под поднялся и приложение запустилось. Чаще всего инженер возьмёт пример из документации или скопирует манифесты из другого проекта, подставит свои значения и применит. Никакого контекста про то, где хранить секреты, как настроить health checks, что будет при падении пода, как это повлияет на мониторинг или соседние сервисы.
И для этого уровня это очень даже хорошо и валидно. Шаблоны уместны для многих задач, но не очень подходят для способа мышления.
Middle видит весь проект — паттерны и связи
Middle учитывает больше контекста. Когда ему говорят кубернетизировать приложение, он уже спрашивает:
Где будем хранить секреты и конфиги — в ConfigMap, Secret, внешнем vault?
Какие нужны пробы — liveness, readiness, startup?
Как настроить ресурсы — requests и limits?
Как будет работать масштабирование — HPA, VPA, вручную?
Middle не ограничивается командой apply, а продумывает эксплуатацию: где хранить секреты, какие пробы настроить, как распределить ресурсы. Он понимает, что деплой — это не разовое действие, а настройка рабочего процесса, который должен стабильно функционировать и давать понятные сигналы о своём состоянии.
Senior видит и понимает архитектуру, может её улучшать
Senior смотрит на деплой и думает не про конкретный сервис, а про целые паттерны: «А как это поведёт себя под нагрузкой? Что будет, когда через полгода придёт новая команда и попробует это обновить? Как моё решение повлияет на устоявшиеся процессы CI/CD, не станет ли новое приложение узким местом?»
Senior-инженер думает наперёд: как конкретное решение задачи аукнется в будущем, где могут возникнуть проблемы, как будет устроено взаимодействие с другими процессами и командами. Он уже может влиять на проект: предлагать архитектурные решения, критиковать подходы, внедрять стандарты.
Он не просто выполняет задачу. Senior её переосмысляет и предлагает лучший путь — не только для текущего сервиса, но и для всей платформы в целом.
Что это значит в реальной жизни
Junior: скопирует deployment.yaml из документации, подставит свой image, запустит kubectl apply.
Middle: настроит манифест Deployment с проверками работоспособности, вынесет пароли и ключи в Secret, пропишет запросы и лимиты по CPU и памяти, настроит liveness- и readiness-пробы.
Senior: переведёт процесс на GitOps с автопроверкой конфигов, настроит canary-релизы и откат по метрикам. Подготовит документацию и сценарии восстановления, чтобы деплой стал управляемым для всей команды.
Это не просто опыт. Это смена угла зрения на одну и ту же задачу.
Как меняется сознание инженера с опытом
Будучи тимлидом, я заметил, что инженеры могут отличаться этапами развития мышления и восприятия своей экспертности, но в целом можно выделить общие этапы.
Этап 1: «Я знаю всё»
Молодой инженер узнаёт несколько вещей. Успешно запускает проект. И думает: «О, я разобрался, я знаю, как это работает». Это самый опасный момент, потому что на деле он находится в начале пути и пока не видит множества трудностей, которые поджидают на каждом шагу.
Этап 2: «Я ничего не знаю»
Вдруг рушатся предположения, которые казались очевидными. И инженер осознаёт: «Я не понимаю даже базовое». Это психологически грустный, но очень полезный этап. Печально осознавать свою уязвимость, зато с ней инженер гораздо осторожнее. Теперь он всегда думает перед тем, как что-то делать, собирает информацию, формулирует гипотезы.
Этап 3: «Я ничего не знаю, но все приходят ко мне за советом»
На этом этапе находятся уже и middle, и senior. Инженер знает, что знаний всегда недостаточно. Но он понимает суть, поэтому, когда приходит сложная задача, может помочь. При этом он никогда не думает, что знает всё, а просто тщательно прорабатывает и переосмысливает свои решения.
Этап 4: «Ничего не знаю, но умею и могу всё»
Тех, кто дошёл до третьего этапа, раньше часто называли визардами (от англ. wizard — волшебникам). Но в нашей инженерной вселенной есть и следующий уровень — гуру. Встретить такого специалиста сейчас так же сложно, как единорога, но они точно существуют.
Если вы способны мгновенно отдебажить любую проблему, видите нужные строки в тысячах логов, понимаете незнакомый стек с полуслова — и всё это не вызывает ни тени паники, а падения продакшена не выбивают вас из душевного равновесия, то поздравляю: вы достигли нирваны. Вы гуру.
— Что делал гуру до обретения нирваны?
— Сидел в Shell, писал скрипты.
— Что делает гуру теперь?
— Сидит в Shell, пишет скрипты.
Возможно, существуют и другие этапы. Но боюсь, те, кто их достиг, уже переселились в многомерное пространство и общаются исключительно на бинарном языке.
Итого, готовность к переходу на уровень middle и выше наступает, когда совпадают сигналы: инженер перестаёт работать в вакууме своей задачи и начинает оценивать её влияние на систему, а его уверенность трансформируется в предусмотрительность и привычку уточнять контекст. Рост выше по грейду чаще всего связан с готовностью улучшать архитектуру и навыки работы за счёт насмотренности, опыта решения комплексных проблем, понимания сигналов observability и трассировок.
Почему junior-инженеры застревают на старте
Чтобы понять, как junior'ам двигаться дальше, важно разобрать ошибки, с которыми они часто сталкиваются.
Шаблонное копирование без понимания
Это самый распространённый паттерн:
Шаблонное администрирование — это когда ты взял какое-то решение из интернета, нагуглил что-то (или искусственный интеллект насоветовал) — и тут же его применил. Но каждое решение нужно пропускать через себя: через понимание своих действий и правильного ожидания конечного результата.
Правильный подход «Шаг — подтверждение»
Проблема не в том, что просто посмотрел решение. Проблема в том, что не разобрался, как оно работает. «Заклинание», которое мы срисовали и применили, может даже сработать в одном проекте. Но это не значит, что оно сработает везде. Нужно понимать, на что повлияет сделанное. Поэтапно: шаг — подтверждение, шаг — подтверждение.
Это медленнее. Но это правильно. Потому что потом этот проект нужно обслуживать. И если не разбираться, то обслуживать не получится.
Молчание вместо просьбы о помощи
Вторая серьёзная ошибка: junior застрял на задаче, но не говорит никому. За этим молчанием обычно стоят понятные страхи: «Вдруг мой вопрос покажется глупым?», «Коллега явно занят, не хочу отвлекать», «Должен же разобраться сам». Но на практике работает простое правило: если junior не пошёл за помощью, значит, он пошёл не туда.
Это убивает развитие. Потому что junior три дня ходит кругами и не растёт, а просто тратит время впустую.
Конечно, многое зависит от компании, в которой работаешь, и от того, как коллеги реагируют на ошибки. Например, у нас во «Фланте» есть культура помощи. То есть никто не ударит по рукам за глупый вопрос. И все обязательно помогут, так как работа происходит в команде.
Никто за бестолковый вопрос палками не побьёт. С одной стороны, нужно быть осторожным, а с другой — если ты чего-то не сломал и не уронил, значит, ты не попробовал))
Спросить не стыдно. Молчать и ходить кругами — убивать время и мотивацию.
Советы для роста до middle-уровня
Активно слушайте
Я бы посоветовал больше слушать коллег. Например, о чём общаются коллеги на утренних созвонах. Обычно на таких встречах обсуждают, что решают. Чаще всего это не просто болтовня. Это живой паттерн того, как решают реальные проблемы.
Слушайте активно! Задавайте вопросы. Следите, как senior подходит к сложным задачам, какие даёт комментарии. Чаще всего рассказ строится по следующему сценарию:
По задаче решаю проблему X.
1. Определил проблему: воспроизвёл, убедился, что она реальна, и согласовал с заказчиком: «Правильно ли я понял, что ломается именно здесь?»
2. Собрал факты: проверил мониторинг, логи, документацию, нашёл похожие кейсы.
3. Выдвинул гипотезу и проверил: внёс изменение, отследил реакцию системы.
4. Закрыл цикл: убедился, что проблема не возвращается, отчитался заказчику и зафиксировал решение.
И обязательно задавайте вопросы коллегам, например «Как ты пришёл к этой гипотезе?» или «Почему отбросил другие варианты?».
Выберите один проект и разберите его полностью
Не изучайте все проекты поверхностно. Выберите один (простой, но реальный) и погрузитесь. Когда у вас знания разложатся по полочкам хотя бы относительно одного проекта, переходить на middle-уровень будет гораздо проще. Потому что вы аккумулируете не разрозненные факты, а систему: паттерны, связи, принципы. А следующий проект — это всего-навсего надстройка над уже изученным, ведь наверняка найдётся много общего между ними.
Как это выглядит:
Выберите проект.
Прочитайте всю документацию.
Посмотрите в кластер — как устроена инфраструктура, как она выкатывается.
Спросите коллег — почему именно так, а не иначе?
Найдите логи, конфиги, мониторинг.
Разберитесь, как взаимодействуют приложения, где это настраивается.
Проследите, как внешний трафик поступает в кластер.
Представьте, как всё это работает вместе.
Расскажите об этом и снова уточните непонятное.
После этого второй проект не будет таким страшным. Потому что паттерны те же. Просто другие инструменты.
Обозначайте свои амбиции
Не молчите о своих амбициях — расскажите, чего хотите. Например, вы хотите просто перейти на уровень middle. Скажите об этом своему руководителю. Вдруг он сможет дать задачу, которая поможет вырасти в техническом плане.
А может, вы хотите не просто перейти на другой уровень, а углубиться в какую-то область, например стать гуру в базах данных, обогатить палитру изученных технологий.
Если не скажете — никто не узнает. В таком случае вам могут прилетать просто случайные задачи, которые только отсрочат ваше развитие.
Заявить о своих намерениях, интересах и слабых местах можно на performance review или встречах one-on-one. На них можно корректировать свои задачи в соответствии с поставленными целями. Сейчас расскажу, как это устроено во «Фланте».
Инструменты определения роста: как компания понимает, что инженер готов к следующему уровню
Расскажу, как инженеры переходят (или нет) на новый уровень в реальной компании на примере юнита «Фланта» DevOps as a Service.
Performance review
Мне как тимлиду регулярно приходится понимать, что инженеры переходят на уровень выше, и даже подталкивать их к этому. Во «Фланте» это определяется целями, которые мы им ставим при performance review — регулярной встрече с руководителями и HR-менеджером, на которой обсуждаем результаты, сильные стороны и зоны роста, чтобы вместе наметить план развития на следующий период.
One-on-one
Есть ещё один инструмент, который помогает в развитии: регулярные встречи с менеджментом наедине. На них можно корректировать свои задачи в соответствии с целями, заданными на performance review. Ещё можно получить более глубокую обратную связь, принести свои пожелания и предложения или даже сменить вектор развития — если и вам, и команде новое направление кажется более перспективным.
One-on-one — это не отчёт. Это диалог. Здесь вы разговариваете о ваших амбициях, желании и точках роста, задачах и фидбеке на ваши результаты.
Вместе вы корректируете путь.
Испытательный срок (дежурство)
Ещё во «Фланте» есть испытательный срок — три месяца. И главная цель за это время — выйти на дежурство.
Что такое дежурство?
Проблемы валятся на инженера в случайном порядке. Разные клиенты, разные системы, разные проблемы. Нужно быстро:
разобраться, в чём суть инцидента, понять его (например, возникла ошибка при обращении к базе данных);
понять — это инфраструктурная проблема или проблема приложения (например, достигнут максимум коннектов или приложение обращается к несуществующим таблицам):
если это инфраструктурная — решить (понять, почему увеличилось число коннектов, и — если валидно — согласовать увеличение максимума и перезапуск СУБД);
если это ошибка приложения — правильно передать (проверить прохождение миграций, выделить текст ошибки, довести до команды разработки).
Здесь крайне важно не пропустить крит. Инциденты приходят с разными уровнями критичности, и нужно уметь быстро расставлять приоритеты. Кто с этим не справляется — испытательный срок не пройдёт.
Причины провала испытательного срока
1. Софт-скилы не сошлись — не выстроился контакт с командой. Хороший по технике, но закрыт эмоционально. Не общается с заказчиком. Мы существуем в уверенности, что инженер — владелец своей задачи и в том числе отвечает за коммуникации по ней.
2. Инженер не справляется с дежурством — не умеет быстро анализировать, переключаться. Когда на тебя сваливается множество разных проблем одновременно, нужно сохранить голову, быстро найти общее в разных ситуациях, распределить приоритеты, позвать на помощь.
3. Не совпали ожидания по темпам роста. Как ни крути, хард-скилы в нашей работе всё-таки важны: команде сложно вкладываться в развитие новичка, особенно если перспектива растягивается на длительный срок.
Дежурство и испытательный срок в целом — это огромный толчок к развитию. Каждая новая проблема — это новый скилл. Каждое дежурство приносит понимание, которого раньше не было видно. Ведь часто приложения под нагрузкой могут вести себя совершенно иначе.
Итоги: что нужно помнить
1. Рост начинается в голове, а не в стеке технологий.
Переход на следующий уровень — это не про изучение новых фреймворков, а про смену оптики: от «закрыть задачу» к «понять, как решение встроится в систему и повлияет на другие компоненты».
2. Две привычки, которые тормозят прогресс:
Слепой копипаст без разбора последствий.
Молчание вместо своевременного вопроса.
Замените их на осознанную проверку (шаг → подтверждение) и культуру диалога.
3. Глубина важнее ширины.
Не распыляйтесь на всё подряд. Разберитесь досконально в одном реальном проекте, слушайте, как подходят к проблемам старшие коллеги, и честно озвучивайте свои цели руководителю на one-on-one.
4. Рост можно увидеть и измерить.
Готовность к новому уровню проявляется не в сертификатах, а в поведении: вы спрашиваете о контексте, берёте на себя ответственность за результат, не паникуете при потоке инцидентов на дежурстве и начинаете видеть паттерны, а не только отдельные баги.
Главное: грейд — это не статус в приказе. Это зрелость мышления, которую вы прокачиваете каждый день осознанными решениями, правильными вопросами и готовностью брать ответственность за систему, а не только за свой кусок кода.
Если вы уже мыслите как middle — видите систему, задаёте правильные вопросы, не боитесь признавать пробелы и ищете устойчивые решения, — возможно, нам по пути.
У нас открыта вакансия DevOps-инженера.
Будем рады познакомиться.
🎁 Бонус для тех, кто дочитал до конца: запись вебинара с практическим разбором кубернетизации приложений. Там я рассказываю, как последовательно переносить сервис в Kubernetes, чтобы результат можно было масштабировать и переиспользовать.
P. S.
Читайте также в нашем блоге: