Два инженера, у обоих пять лет в DevOps и одинаковый стек в резюме: Kubernetes, Terraform, GitLab и вот это вот всё. Весной оба ходили по собеседованиям, но первый собрал офферы уровня “мидл, 200”, второй ушёл с “сеньор, 300” (алгоритмические секции первый, к слову, проходил лучше). Разница больше миллиона в год при неотличимых резюме. Ниже рамка, которая по моему мнению объясняет за что доплачивают, и три вопроса, чтобы найти в ней себя.
За что доплачивают 160 тысяч в месяц
По калькулятору Хабр Карьеры медиана мидл-девопса сейчас (10 августа 2026) 197к рублей, сеньора - 298к рублей. Рынок который год платит сеньорам ощутимо больше, хотя списки требований в вакансиях обоих грейдов - я ради интереса прошёлся по двум десяткам - почти под копирку.
Такие деньги не платят за “знает больше тулзов”. На собеседовании разница между этими двумя инженерами вскрывается не на вопросе “как настроить ingress”, оба настроят. Она вскрывается на трёх других вопросах: почему выбрали именно это решение? что будет, если оно упадёт в пятницу вечером? сколько это стоит компании? Первый инженер уверенно отвечает на вопросы типа “как”. Второй ответит на все три.
Выглядит это примерно так.
Почему Kafka, а не managed-очередь у облака?
Ну… она уже стояла, когда я пришёл.
Честный ответ мидла, ничего постыдного. Сеньорский вариант звучал бы примерно:
Считали. Managed выходила дешевле по эксплуатации, но нам нужен replay за неделю, и по хранению это ломало весь бюджет. Так и остались на Kafka… расчёт где-то в ADR лежит, могу поднять.
Причём второй ответ мог привести ровно к тому же выбору - платят не за выбор, за расчёт. Рынок покупает право не проверять за человеком решения и цену ошибки, которую ему можно доверить.
Рамка, по которой нас меряют, стоит на трёх гнилых ногах
Откройте любую вакансию: “Senior DevOps-инженер: от 5 лет опыта, экспертное знание Kubernetes, самостоятельность, ответственность” (цитата собирательная, но вы её узнали). Это и есть традиционная рамка: годы, глубина стека, самостоятельность.
Годы опыта. Резюме не отличает “пять лет разных задач от одного года, повторённого пять раз” - шутка старая, но фильтруют по годам до сих пор всерьёз. Я работал с инженером, у которого было много лет стажа и ни одного самостоятельно выбранного инструмента - всегда исполнял чужие решения, причём исполнял хорошо. А парень со вторым годом опыта в одиночку прожил пять проектов заказчика с нуля: сам выбирал, сам обосновывал, сам потом разгребал. По резюме первый старше. По типу решений - младше на голову!
Самостоятельность. Определение замкнуто само на себя: самостоятельный это тот, кто работает без присмотра. А если он без присмотра уверенно делает не то? Хуже: в зрелой команде самостоятельность выглядит как правильные вопросы в правильный момент - то есть внешне неотличима от “постоянно спрашивает”. Спросите трёх тимлидов, что такое самостоятельность, и получите три несовместимых ответа.
Глубина стека. Обнуляется при смене стека. Компания переехала с Jenkins на GitLab CI - и “глубокое знание Jenkins” осталось в прошлой жизни вместе с частью зарплатных ожиданий. Знание внутренностей инструмента это прокси-метрика: собеседующие любят её, потому что она проверяется парой вопросов. Тип ответственности одним вопросом не проверяется, только историей решений, поэтому про него почти и не спрашивают.
Грейд - это тип ответственности
Рамка, которой стал пользоваться я (и которую рынок, судя по вилкам, применяет не формулируя): грейд определяется типом решений, за которые ты отвечаешь, и ценой твоей ошибки. Стаж и стек - обёртка.
Формулы такие:
Мидл - “делаю надёжно”. Задачи класса “один сервис, известный контекст”: исполнить выбранное решение так, чтобы оно не разваливалось. Артефакты: работающий пайплайн, конфиг, стенд.
Сеньор - “проектирую и обосновываю”. Задачи класса “несколько систем, неполная информация”: выбрать решение и защитить выбор. Артефакты: ADR (architecture decision record), дизайн-док, расчёт стоимости.
Руководитель - “управляю рисками и экономикой”. Задачи класса “организация”: решить, что мы вообще делаем, что это стоит и какие риски несём. Артефакты: бизнес-кейс, SLO как контракты, план и цена миграции.
Различия удобно раскладывать по трём осям:
Ось | Мидл | Сеньор | Руководитель |
|---|---|---|---|
Scope - на что влияет твоё решение | Задача, один сервис | Система, несколько команд | Портфель систем, организация |
Risk ownership - чей риск ты несёшь | Свой таск: ошибку поймает ревью | Прод целиком: ошибку увидят все | Бизнес: ошибку заметит клиент или регулятор |
Economics - считаешь ли ты деньги | Не обязан | Обосновываешь стоимость решения | Управляешь бюджетом и ценой простоя |
Один тикет, три головы
Тикет в бэклоге: “Переехать на новый container registry”. Повод обычный - уходим с Docker Hub из-за лимитов и рисков вендора.
Мидл читает тикет как план работ. Зеркалирует образы, перенастраивает аутентификацию в CI, обновляет values во всех чартах, гоняет тестовые сборки, пишет план отката, проводит миграцию в ночное окно и ничего не роняет. Это “делаю надёжно” - работа, на которой держится вообще всё. Плохой мидл на этом же тикете положит деплой на сутки.
Сеньор читает тикет как вопрос. Зачем едем - лимиты можно закрыть прокси-кэшем за день? Если едем: managed registry облака, self-hosted Harbor или кэш поверх старого - что из этого мы потянем эксплуатировать? Кто будет чистить старые теги, когда хранилище доползёт до 4 ТБ? Что случится с деплоями, когда registry ляжет - а он ляжет! На выходе - ADR со сравнением, ценой каждого варианта и планом отката. Иногда на выходе “не переезжаем, ставим кэш” - и это тоже результат, сэкономивший три недели работы.
Руководитель читает тикет как строку в бюджете рисков. Registry - единая точка отказа всех деплоев компании. Что дороже: миграция сейчас, силами двух инженеров на три недели, или риск, что вендор закроет доступ в самый неудобный момент? Едем до пикового сезона или после? Какой SLA нужен новому хранилищу и сколько мы готовы за него платить? Решение может звучать как “едем в сентябре, после очередного релиза - и вот почему не сейчас…”.
Одна тема. Три разные работы. Эта разница и продаётся как грейд - а списком технологий в резюме её не предъявишь. Те двое (из заголовка) отличались ровно этим. (Джун в рамке тоже существует: он исполняет шаги мидлового плана под чужим ревью. Ось та же, что у мидла, просто короче.)
Почему в одной компании ты сеньор, а в другой - мидл
Грейд ходит за масштабом рисков компании, человек тут вторичен. В стартапе на сотню клиентов цена твоей худшей ошибки - день простоя и десяток недовольных писем. В финтехе с миллионом транзакций в сутки тот же самый промах - регуляторный штраф и заголовки в СМИ. “Сеньор” стартапа и “сеньор” банка - разные профессии с одинаковым названием: им доверяют разную цену ошибки.
Отсюда два неприятных следствия.
Первое: титул не переносится. Переходя в компанию с бОльшим масштабом рисков, ты опускаешься на ступень - не потому что стал хуже, а потому что местную цену ошибки тебе ещё не доверяют. На Хабре в прошлом году описывали обратный ход - опытные разработчики сами просят грейд ниже: кто-то банально ради второй работы, но чаще - чтобы снизить ожидания и цену ошибки, которую на них повесят. В рамке ответственности этот парадокс исчезает: люди торгуются не за название, а за риск, который готовы нести.
Второе: спорить “я же сеньор, у меня в трудовой написано” бессмысленно. Покупают не строчку в трудовой, а способность нести местный риск. Может и обидно, но так устроена система - и кто это принял, тратит на собеседованиях меньше нервов.
Обратная сторона того же правила: в маленькой компании легко “стать сеньором” за год, потому что ты несёшь весь прод. Скоуп при этом - три сервера и пятнадцать контейнеров. Приходишь в компанию, где один только мониторинг больше твоего бывшего прода в несколько раз и выясняется, что сеньорского в тебе была строчка в оффере.
Знакомый инженер проходил это на себе: ушёл из аутсорс компании в крупный финтех, и его бывший “весь прод” оказался там долей нагрузки одного кластера из десятка. Полгода “мидловых” тикетов и нытья в личке, что каждый его MR ревьюят по три дня. Через полтора года - сеньор уже по местной шкале. Я называл бы это перекалибровкой.
Три вопроса, чтобы найти себя на карте
Самооценка грейда врёт в обе стороны - у сильных в минус, у остальных в плюс. Поэтому дальше только факты за последнее время.
1. Вопрос про деньги (ось Economics). Какое моё решение последним стоило или сэкономило (или заработало) компании заметную сумму - и знаю ли я хотя бы её порядок? Решения есть, сумм не знаешь - работаешь мидлом, что бы ни было написано в оффере. Считал деньги до принятия решения - сеньор. Есть своя строка в бюджете - руководитель.
2. Вопрос про чужие ошибки (ось Risk ownership). Когда я в последний раз останавливал чужое техническое решение, письменно объяснив почему? Мидл отвечает за свои ошибки. Сеньор - за ошибки системы, включая чужие: увидел, что коллега тащит в прод бомбу - остановил и обосновал. Если всё, что ты когда-либо останавливал это собственный код, ось риска у тебя пока мидловая. Как у большинства, к слову: у меня самого она сдвинулась году эдак на пятом, и то после предотвращенного инцидента.
3. Вопрос про формулировки (ось Scope). Задачи приходят ко мне как “сделай X” или как “разберись с Y”? Кто превращает жалобу “у нас медленно деплоится” в конкретные тикеты - я или кто-то до меня? Превращение боли в план - сеньорская работа. Исполнение плана - мидловая, даже если план сложный.
Профиль почти наверняка выйдет неровным: сеньор по Scope, мидл по Economics - обычное дело. Зато сразу видно, какую ось качать.
Качаются оси скучно. Economics - узнай, во что обходится час простоя твоего главного сервиса; одна цифра, а разговор с бизнесом будет уже другой. Risk ownership - напиши ADR задним числом на решение, которое живёт в вашем проде без обоснования, и отдай старшему коллеге на растерзание. Scope - возьми следующую жалобу (“пайплайн постоянно падает”, “стейдж вечно разломан”) и сам преврати её в план из тикетов, раньше, чем это сделает твой лид.
Границы рамки
Оговорка, без которой рамка превратится в ещё один культ. Во-первых, это модель, чтобы планировать свой рост, а не оружие для спора с работодателем. Грейд в отдельно взятой компании определяет компания - у неё на это есть причины (см. выше про масштаб рисков). Приносить эту табличку на перформанс-ревью как ультиматум - очень плохая идея.
Во-вторых, “выше” не значит “обязан”. Осознанно работать мидлом, который делает надёжнее всех в округе - нормальная карьера. Рамка нужна, чтобы выбор уровня был выбором, а не дефолтом, случившимся сам собой.
И честная дыра в модели, чтобы вы не думали, будто она объясняет всё: куда класть стафф-инженеров без команды, я до сих пор не знаю - у меня они висят где-то между сеньором и руководителем и слегка ломают табличку.
Расскажите в комментариях про самое дикое несовпадение грейда и человека, которое видели: сеньор, “нанятый” исполнять чужие тикеты (в моей практике это случилось недавно), или джун, в одиночку тащивший прод банка. Особенно интересно, чем кончилось.
