Пост большой, тут немного выдержек (компания не указана)

DevOps Engineer

Пост большой, тут немного выдержек Как вырасти до мидла: на что на самом деле смотрят тимлиды при оценке DevOps-инженеров https://habr.com/ru/companies/flant/articles/1049626/ Я Алексей Сартаков, тимлид команды DevOps-инженеров во «Фланте». За годы работы вижу одну закономерность: быстрее растут не те, кто знает больше, а те, кто умеет видеть связи, вовремя задавать вопросы и брать ответственность за результат, а не только за строчку в манифесте чарта. В этой статье разберу типичные ошибки, которые тормозят junior-инженеров, дам конкретные советы, как менять подход к работе, и расскажу, как мы помогаем инженерам расти внутри компании. ... **Junior видит только свою задачу** Junior получает поручение кубернетизировать приложение. Фокус узкий: нужно, чтобы под поднялся и приложение запустилось. Чаще всего инженер возьмёт пример из документации или скопирует манифесты из другого проекта, подставит свои значения и применит. Никакого контекста про то, где хранить секреты, как настроить health checks, что будет при падении пода, как это повлияет на мониторинг или соседние сервисы. **Middle видит весь проект — паттерны и связи** Middle не ограничивается командой apply, а продумывает эксплуатацию: где хранить секреты, какие пробы настроить, как распределить ресурсы. Он понимает, что деплой — это не разовое действие, а настройка рабочего процесса, который должен стабильно функционировать и давать понятные сигналы о своём состоянии. **Senior видит и понимает архитектуру, может её улучшать** Senior смотрит на деплой и думает не про конкретный сервис, а про целые паттерны: «А как это поведёт себя под нагрузкой? Что будет, когда через полгода придёт новая команда и попробует это обновить? Как моё решение повлияет на устоявшиеся процессы CI/CD, не станет ли новое приложение узким местом?» Senior-инженер думает наперёд: как конкретное решение задачи аукнется в будущем, где могут возникнуть проблемы, как будет устроено взаимодействие с другими процессами и командами. Он уже может влиять на проект: предлагать архитектурные решения, критиковать подходы, внедрять стандарты. ... **Этап 1: «Я знаю всё»** Молодой инженер узнаёт несколько вещей. Успешно запускает проект. И думает: «О, я разобрался, я знаю, как это работает». Это самый опасный момент, потому что на деле он находится в начале пути и пока не видит множества трудностей, которые поджидают на каждом шагу. **Этап 2: «Я ничего не знаю»** Вдруг рушатся предположения, которые казались очевидными. И инженер осознаёт: «Я не понимаю даже базовое». Это психологически грустный, но очень полезный этап. **Этап 3: «Я ничего не знаю, но все приходят ко мне за советом» ** На этом этапе находятся уже и middle, и senior. Инженер знает, что знаний всегда недостаточно. Но он понимает суть, поэтому, когда приходит сложная задача, может помочь. **Этап 4: «Ничего не знаю, но умею и могу всё»** Тех, кто дошёл до третьего этапа, раньше часто называли визардами (от англ. wizard — волшебникам). Но в нашей инженерной вселенной есть и следующий уровень — гуру. Встретить такого специалиста сейчас так же сложно, как единорога, но они точно существуют.  ... Итоги: что нужно помнить **1. Рост начинается в голове, а не в стеке технологий.** Переход на следующий уровень — это не про изучение новых фреймворков, а про смену оптики: от «закрыть задачу» к «понять, как решение встроится в систему и повлияет на другие компоненты». **2. Две привычки, которые тормозят прогресс:** Слепой копипаст без разбора последствий. Молчание вместо своевременного вопроса. Замените их на осознанную проверку (шаг → подтверждение) и культуру диалога. **3. Глубина важнее ширины.** Не распыляйтесь на всё подряд. Разберитесь досконально в одном реальном проекте, слушайте, как подходят к проблемам старшие коллеги, и честно озвучивайте свои цели руководителю на one-on-one. **4. Рост можно увидеть и измерить.** Готовность к новому уровню проявляется не в сертификатах, а в поведении: вы спрашиваете о контексте, берёте на себя ответственность за результат, не паникуете при потоке инцидентов на дежурстве и начинаете видеть паттерны, а не только отдельные баги. **Главное:** грейд — это не статус в приказе. Это зрелость мышления, которую вы прокачиваете каждый день осознанными решениями, правильными вопросами и готовностью брать ответственность за систему, а не только за свой кусок кода.