Джун SRE-инженер в среднем получает 178 тысяч рублей, а медианная зарплата по роли уже дошла до 320 тысяч. Для российского IT-рынка это редкий случай, когда высокий чек начинается не где-то на уровне «сеньор с седыми висками», а заметно раньше. Если коротко: бизнес все хуже переносит простои, а значит специалисты по надежности перестали быть внутренней роскошью и стали прямой страховкой от потерь.
Об этом сообщает Habr / Карьера в разборе о профессии SRE. Издание напоминает базовую вещь, которую в компаниях обычно вспоминают уже после аварии: когда сервис падает на 20 минут в час пик, потери считаются не абстрактным «негативным пользовательским опытом», а репутацией, сорванными транзакциями и деньгами. Поэтому SRE-инженер оказался в числе самых дорогих технических специалистов: его работа напрямую завязана на то, чтобы цифровые продукты не сыпались под нагрузкой, не умирали после релизов и не превращали дежурную смену в пожарную часть.
Формально SRE, или Site Reliability Engineering, появился в Google в начале 2000-х. Автор подхода Бен Трейнор описывал его просто: это то, что получается, если дать software-инженеру операционную работу. На практике SRE-инженер стоит на стыке разработки и эксплуатации: он не только следит за системой, но и пишет код, который делает ее устойчивее. В его зоне ответственности не одна кнопка «перезапустить сервис», а целая инженерная дисциплина: цели по доступности, мониторинг, инциденты, автоматизация рутины, планирование мощностей и безопасные выкаты новых версий.
Самый показательный кусок этой работы связан с SLO и error budget. SLO, то есть Service Level Objective, задает измеримую цель по надежности. В источнике приводится пример: 99,9% запросов должны укладываться в 200 мс. Для бизнеса это уже не язык инфраструктурных заклинаний, а вполне понятный контракт с продуктом: насколько быстро и стабильно должен работать сервис, чтобы им вообще можно было пользоваться без боли. Error budget, в свою очередь, вводит неприятную, но полезную взрослость: если вы обещали 99,9%, значит у вас есть лишь 0,1% допустимой ненадежности за период. Этот бюджет можно тратить на релизы и изменения, но если он выгорел, разработку приходится притормозить и чинить систему. И вот тут SRE перестает быть «еще одним DevOps» и становится человеком, который помогает бизнесу выбирать между скоростью поставки фич и риском очередного падения.
Вторая часть роли еще практичнее и потому дороже: инциденты, постмортемы и борьба с ручным трудом. Когда что-то уже упало, SRE устраняет проблему, а потом разбирает причины без театра с поиском виноватых. Логика простая: если инцидент повторяется, значит система была спроектирована так, что это вообще стало возможно. Отсюда и принцип toil reduction, который Habr / Карьера отдельно подчеркивает: если операцию пришлось делать руками больше двух раз, ее пора автоматизировать. Для компаний это звучит особенно трезво. Рынок уже прошел стадию, когда можно было бесконечно компенсировать плохую архитектуру героизмом дежурной команды. Героизм выгорает, сотрудники уходят, а ручные костыли однажды отказывают в самый неудобный момент.
Еще одна дорогая зона ответственности SRE — масштабирование и релизы. Перед распродажами, крупными маркетинговыми кампаниями, сезонными пиками или важными выкладками кто-то должен ответить на неприятный вопрос: выдержит ли система то, что на нее сейчас навалят. SRE прогнозирует потребность в ресурсах, настраивает автомасштабирование, проводит нагрузочное тестирование и участвует в выборе стратегии выката. Канареечные релизы, blue-green деплой, постепенное повышение доли трафика на новую версию с автоматическим откатом при сбоях — все это уже не факультатив для «технологически зрелых», а нормальный набор инструментов для компаний, которым дорого обходится каждый простой. Особенно в финтехе, e-commerce и сервисах с высокой транзакционной нагрузкой, где цена ошибки быстро выходит за пределы неприятного поста в соцсетях.
Цифры по зарплатам в материале выглядят как отдельный аргумент в пользу того, что рынок всерьез оценил надежность. По данным зарплатного калькулятора Habr Карьеры, медиана по SRE составляет 320 тысяч рублей. Джуны получают в среднем 178 тысяч, мидлы — 253 тысячи, сеньоры — 420 тысяч, лиды — около 527 тысяч. Верхняя граница в профессии превышает 800 тысяч рублей. CEO/CTO Atlantis Андрей Гостюхин объясняет этот разрыв просто: хороший SRE должен понимать разработку, инфраструктуру, сети, базы данных, контейнеризацию, облака, мониторинг и эксплуатационные процессы одновременно. Но решает не только ширина стека. По его словам, главный фактор в том, что результат работы SRE напрямую связан с доступностью бизнеса, а опыт аварий и восстановления систем на курсах не выдают вместе с сертификатом.
Отсюда и любопытный карьерный парадокс. С одной стороны, профессия не выглядит закрытым клубом для избранных: в материале говорится, что войти в SRE можно за 6-9 месяцев целенаправленного обучения. С другой — это не короткая дорога в легкие деньги. Курсы по DevOps, облакам, Linux, мониторингу, инцидентам и даже английскому могут дать базу, и Habr / Карьера перечисляет несколько программ для старта. Но верх рынка получает не тот, кто выучил названия Kubernetes и Terraform, а тот, кто понимает, как проектировать отказоустойчивые системы и что делать, когда все уже пошло не по плану. Для работодателей это означает рост спроса на инженеров с реальным продакшен-опытом. Для разработчиков и системных администраторов — понятный карьерный маршрут в одну из самых денежных инфраструктурных специализаций.
На этом фоне главный вопрос уже не в том, останется ли спрос на SRE, а в том, как быстро российские компании перестроят под него свои процессы. Пока одни еще спорят, нужен ли им отдельный SRE-инженер или хватит универсального DevOps, другие давно считают не вакансии, а минуты простоя. И, похоже, рынок все яснее отвечает: надежность стала не приложением к разработке, а самостоятельной бизнес-функцией с очень конкретным ценником.