Тимлид команды DevOps во «Фланте» свёл рост DevOps-инженера к одной показательной задаче: нужно не просто задеплоить приложение в Kubernetes, а понять, как решение повлияет на секреты, ресурсы, мониторинг и дальнейшую поддержку. Для русскоязычного IT-рынка это важный сигнал: переход в middle по-прежнему измеряют не числом инструментов в резюме, а тем, умеет ли инженер видеть систему целиком.
Об этом сообщает Habr / Карьера со ссылкой на материал Алексея Сартакова, тимлида команды DevOps-инженеров во «Фланте». Его главный тезис довольно неприятен для тех, кто рассчитывал закрыть вопрос грейда парой сертификатов и двумя годами на проекте: набор технологий сам по себе почти ничего не гарантирует. По словам автора, тимлиды смотрят прежде всего на способ мышления. Один инженер закрывает тикет и идёт дальше, другой сразу задаёт вопросы о конфигурации, отказоустойчивости, лимитах ресурсов, хранении секретов и том, как новый сервис встроится в существующие процессы. Именно между этими двумя подходами и проходит граница между junior и middle.
В статье это объясняют на простом примере с кубернетизацией нового приложения. Junior, по версии автора, обычно решает задачу линейно: берёт deployment.yaml из документации или соседнего проекта, подставляет свой образ и применяет манифест. Такой подход для начинающего инженера не считается ошибкой сам по себе, но он почти всегда живёт в узком контуре: приложение поднялось, тикет закрыт, что будет дальше с эксплуатацией, не очень важно. Middle работает иначе. Он заранее думает, где хранить секреты и конфиги, какие пробы нужны сервису, какие requests и limits выставить, как приложение будет масштабироваться и что увидят коллеги в мониторинге, если что-то сломается. Senior уходит ещё дальше: он смотрит уже не на отдельный деплой, а на паттерн для всей платформы, на совместимость с CI/CD, на сценарии восстановления, канареечные релизы и на то, не создаёт ли команда себе новый класс проблем через полгода.
В этой логике самый болезненный вывод для рынка такой: рост DevOps-инженера начинается не в тот момент, когда он выучил очередной инструмент, а в тот, когда перестал работать в вакууме собственной задачи. Для тимлида показатель зрелости не в том, что инженер знает названия Vault, HPA или GitOps, а в том, задаёт ли он правильные вопросы до продакшена, а не после инцидента. Для работодателей это тоже удобная рамка. Она позволяет отделять специалистов, которые умеют аккуратно воспроизводить найденные решения, от тех, кто способен брать ответственность за результат и предсказывать последствия изменений в системе.
Отдельный пласт статьи посвящён тому, почему junior-инженеры застревают на старте. Первая типичная ошибка, по наблюдению автора, это шаблонное копирование без понимания. Рецепт «нагуглил, вставил, сработало» выглядит быстрым, но плохо переживает реальную эксплуатацию. В одной команде манифест или скрипт могут взлететь без вопросов, в другой те же действия приведут к неочевидным сбоям, потому что контекст другой. Поэтому автор настаивает на более медленной, но рабочей модели: «шаг - подтверждение». Сделал изменение, понял, что именно оно меняет, проверил результат, только потом идёшь дальше. Для DevOps это звучит почти банально, но именно на таких базовых привычках потом держится работа с инцидентами, миграциями и сложными деплоями.
Вторая ошибка, которую Сартаков выделяет отдельно, это молчание. Junior застрял, но не просит помощи, потому что боится показаться слабым, отвлечь коллегу или не оправдать ожиданий. Для тимлида это, пожалуй, более тревожный сигнал, чем сам факт незнания. Неумение вовремя вынести проблему наружу удлиняет задачу, увеличивает риск неправильного решения и съедает время всей команды. В DevOps-среде, где цена промаха часто измеряется стабильностью сервиса, такая автономность легко превращается из добродетели в проблему. По сути, автор напоминает очевидную, но вечно игнорируемую вещь: middle отличается от junior не мифической безошибочностью, а тем, что лучше управляет неопределённостью, быстрее уточняет контекст и раньше понимает, когда нужно подключать других.
Любопытно, что материал описывает и психологическую сторону роста. Автор делит развитие инженера на несколько состояний: от раннего «я уже всё понял» через неприятное, но полезное «я почти ничего не понимаю» к более зрелому «я знаю, что знаний всегда недостаточно, но могу разбираться в сложных задачах». В этой схеме middle и senior объединяет не уверенность в собственной непогрешимости, а как раз осторожность. Чем опытнее инженер, тем меньше он полагается на самоуверенность и тем больше на проверку гипотез, наблюдаемость и понимание зависимостей. Это довольно точное описание того, как выглядит взросление в инфраструктурных командах: чем ближе человек к продакшену, тем меньше в нём желания играть в технического героя и тем больше привычки работать с риском хладнокровно.
Для разработчиков и компаний из этого следует вполне прикладной вывод. Если команда оценивает рост DevOps-инженера только по списку освоенных инструментов, она сама выращивает перекос в сторону демонстративной экспертизы вместо системного мышления. Если же критерием становится влияние решений на надёжность, поддержку, CI/CD и соседние сервисы, разговор о грейдах становится заметно честнее. В таком подходе middle уже не человек, который просто пережил два годовых review, а инженер, способный видеть последствия своих действий за пределами собственного тикета. И это, похоже, намного полезнее для отрасли, чем очередная гонка по чек-листу из модных DevOps-инструментов.
На фоне охлаждения найма и более жёстких требований к эффективности инфраструктурных команд такой сдвиг в критериях выглядит закономерным: бизнесу всё меньше нужен человек, который умеет нажимать правильные кнопки, и всё больше нужен тот, кто понимает, зачем их вообще нажимать. Вопрос теперь не в том, сколько junior-специалистов выучат новый стек, а в том, сколько из них успеют перестроить способ мышления до того, как рынок окончательно перестанет платить за простое копирование готовых решений.