Live-данные · обновлено 23.06.26

SRE-инженер: кто это и чем занимается

SRE-инженер, или Site Reliability Engineer, делает надёжность production-сервиса инженерной задачей. Он переводит эксплуатацию из ручного реагирования в измеримые правила: SLI, SLO, error budget, observability, incident response, postmortem и automation. Смысл роли — не набор терминов, а управление риском пользовательского сценария.

По данным SkillStat на 23.06.26, в Москве и МО видно 43 вакансий SRE-инженера. Зарплата показана как оценка: 245 000 ₽, выборка — n=11. Это ориентир по вакансиям, а не гарантия для каждого грейда. Частые навыки: Kubernetes, Linux, CI/CD, Python, Docker и Grafana.

Страница объясняет, кто такой SRE-инженер, чем он занимается каждый день, как читать зарплату и спрос, как войти в профессию и как сравнивать курсы с требованиями работодателей.

КВ Кузнецов Вячеслав · Технический редактор · DevOps/SRE-техлид · опыт 10+ лет
Вакансии
43
Москва и МО · 23.06.26
Оценка зарплаты
245 000 ₽
Оценка по профессии и близкому рынку
Спрос
20 / 100
Низкий · #35
Уровень
Middle
54% вакансий
Формат
гибридный формат
удал. 14% · гибрид 60% · офис 26%
Выборка зарплат
11
вакансий с зарплатой

Как ещё называют SRE-инженера

В вакансиях и статьях одна и та же зона ответственности может называться по-разному. Важно читать не только название роли, но и задачи: SLO, incident response, observability, on-call, postmortem, automation и право менять причины сбоев.

Прямые названия
SRE-инженерSite Reliability Engineerинженер по надёжностиинженер надёжности сервиса
Смежные названия
production engineerreliability engineerplatform reliability engineerDevOps/SRE engineer
Все профессии

Коротко о профессии

SRE-инженер делает надёжность управляемой. Он помогает команде не просто реагировать на падения, а заранее понимать, какие пользовательские сигналы важны, какой уровень доступности нужен продукту и где ручная работа должна быть заменена инженерным решением.

В центре роли — SLI, SLO, бюджет ошибок, наблюдаемость, реагирование на инциденты, разборы без обвинений и снижение ручной рутины. Это не набор модных терминов, а способ договориться, сколько риска компания готова принять ради скорости изменений.

От системного администратора SRE отличается фокусом на продуктовой надёжности и инженерном устранении повторяемых причин. Он не только поддерживает инфраструктуру, но и меняет правила релизов, мониторинг, архитектуру и поведение команд после инцидентов.

Для этой профессии доступны ограниченные данные. Аналитика носит ориентировочный характер.

По зарплате у профессии нет достаточной собственной актуальной выборки. Поэтому на странице показана оценка с явной маркировкой источника, а не точная медиана только по текущим активным вакансиям.

Как читать данные SkillStat по SRE

Числовые метрики показывают вакансии Москвы и Московской области. Описание роли, задач и навыков относится к профессии в целом.

Регион
Москва и МО
Срез
23.06.26
Зарплата
Оценка по профессии и близкому рынку
Выборка
n=11
Методология зарплат Методология спроса

Как мы считали

  • Рыночные метрики на странице относятся к Москве и Московской области. Описание задач, практик, инструментов и карьерных переходов шире региона и относится к профессии SRE в целом.
  • Зарплатная оценка 245 000 ₽ показана в estimated-режиме по расширенному окну профессии. Её нельзя читать как гарантированную медиану для Junior, Middle, Senior или Lead.
  • Вакансии, спрос, формат работы, работодатели и доли навыков меняются. Для точных чисел используйте live-виджеты страницы; текст объясняет, как интерпретировать эти данные.
  • FAQPage-разметка строится только по видимому FAQ на странице. Article-разметка использует фактические даты публикации и обновления, а экспертный reviewer не размечается, пока он не указан в источнике.

Актуальные данные по профессии

Актуальный срез по вакансиям, зарплате, спросу и динамике найма для SRE-инженера в Москве и МО.

Вакансии Количество активных вакансий на сегодня в регионе Москва и МО. Не включает закрытые или приостановленные.
43
активных вакансий
Москва и МО · текущий срез 23.06.26
7 дней назад
60
16.06.26 -28%
30 дней назад
73
24.05.26 -41%
Спрос 50 = средний по рынку, 100 = в 4× больше вакансий чем у средней IT-профессии. Метрика считается по актуальной выборке Москва и МО.
20
из 100
Ранг по спросу
#35 из 71
Статус
Низкий
Топ спроса
#1
Системный аналитик
645
#2
Продакт-менеджер
521
#3
Бизнес-аналитик
504
Оценка зарплаты
Оценка
245 000₽
Москва и МО · Оценка по профессии и близкому рынку
Смежная роль: Инженер поддержки · n=78
Смежная роль: DevOps-инженер · n=57
Вакансии профессии за 180 дней · n=25
Диапазон и позиция в зарплатном рейтинге не показаны: зарплата рассчитана в estimated-режиме, поэтому SkillStat не выводит эти значения, чтобы не создавать ложную точность.
Средний тренд Сначала сравниваем последние 30 дней с предыдущими 30. Если в одном из окон меньше 14 точек, пробуем 45, 60, 90 дней. Ряд использует ту же семантику активных публичных вакансий, что и верхнее число.
↓ 16.1%
последние 30 дней vs предыдущие 30
среднее последнего окна ниже предыдущего
61 против 72 вакансий, последние 30 дней vs предыдущие 30
сглаживание 30 дней

Кто такой SRE-инженер

SRE-инженер, или Site Reliability Engineer, делает надёжность продукта инженерной задачей. Он работает с production-сервисами, где сбой видит пользователь: API отвечает медленно, оплата не проходит, очередь растёт, релиз ломает важный сценарий или команда тонет в шумных алертах.

Работа обычно идёт по понятному циклу. Сначала SRE выбирает пользовательские сигналы и описывает SLI, SLO и бюджет ошибок. Затем строит наблюдаемость: метрики, логи, трассировки, алерты и дашборды с ясным действием. Во время инцидента он помогает исследовать причину, снизить ущерб, держать коммуникацию и выбрать откат или обходной путь. После восстановления команда проводит постмортем и превращает выводы в reliability fix: изменение кода, инфраструктуры, лимитов, релиза или инструкции восстановления.

Эта роль близка к DevOps, системному администрированию и платформенной инженерии, но фокус уже. DevOps чаще отвечает за процесс поставки и инфраструктурные практики, системный администратор — за работоспособность систем, Platform Engineer — за внутреннюю платформу. SRE держит в центре продуктовую надёжность, инциденты и повторяемые причины сбоев.

Поэтому сильный SRE ценен не количеством графиков. Он помогает команде видеть риск заранее, снижать ручную нагрузку и договариваться о балансе между скоростью релизов и устойчивостью сервиса.

Рабочий объект

Надёжность сервиса: SLO, инциденты, наблюдаемость, ручная рутина и безопасные релизы

Главная ценность

Снижает пользовательский риск и превращает сбои в инженерные улучшения, а не в повторяемые пожары

Ключевой риск

Без права менять причины сбоев SRE превращается в дежурную команду, которая только тушит последствия

Что означает инженерно управлять надёжностью

Инженер по надёжности не просто наблюдает за системой. Он помогает команде определить, какие признаки действительно важны для пользователя, как измерять качество работы сервиса и где вложение сил даст наибольший эффект для устойчивости.

Благодаря этому разговор о сбоях перестаёт быть эмоциональным и превращается в понятную инженерную работу с риском и приоритетами.

На практике это означает постоянный перевод хаоса в правила. Нужно понять, какой показатель связан с опытом пользователя, где алерт должен быть срочным, какой ручной шаг пора заменить кодом и когда команде выгоднее временно замедлить релизы.

Почему надёжность шире мониторинга

Графики и уведомления сами по себе ничего не спасают, если команда не понимает, какой сигнал важен и что делать после него. Сильный специалист по надёжности строит не набор экранов наблюдения, а систему решений: как замечать проблему, как разбирать причину и как уменьшать вероятность её повторения.

Именно поэтому в профессии так важны спокойная диагностика, работа с ручной рутиной и исправление причин, а не только симптомов.

С чем не путать эту роль

Инженер по надёжности близок к эксплуатации и платформенной работе, но его фокус уже: устойчивость пользовательского сервиса и снижение повторяемости сбоев. Если роль сводится только к поддержке инфраструктуры, теряется её главный смысл.

Инженерия надёжности становится по-настоящему полезной там, где команда готова измерять устойчивость, учиться на инцидентах и менять систему, а не просто быстрее тушить пожары. Это делает роль ближе к инженерии продукта, чем к простому дежурству по инфраструктуре.

Коротко о профессии SRE-инженера

Эта таблица помогает быстро понять профессию и не спутать SRE с обычным администрированием Kubernetes или дежурной эксплуатацией.

Параметр Значение Как читать
Кто это Инженер по надёжности production-сервисов Отвечает за пользовательский опыт, а не только за состояние серверов
Главная задача Сделать надёжность измеримой и управляемой Команда договаривается о SLI, SLO и допустимом риске
Что делает Строит observability, участвует в incident response, снижает toil После восстановления должен появиться engineering fix, а не только закрытый инцидент
За что отвечает SLO, error budget, alert quality, runbook-и, postmortem, capacity SRE полезен там, где ему дают менять причины сбоев
Ключевые практики SLI, SLO, SLA, Error Budget, Toil, On-call, Incident Response, Blameless Postmortem Это ядро роли; Kubernetes и CI/CD только помогают его реализовать
Ключевые навыки Kubernetes, Linux, Python, CI/CD, Docker, Grafana Частотность навыков смотрите в live-блоке SkillStat; список не равен полному учебному плану
Зарплатная оценка 245 000 ₽, оценка-режим, n=11 Ориентир по Москве и МО на 23.06.26, не гарантия по каждому грейду
Вакансии и спрос 43 вакансий, спрос 20/100, ранг #35 из 71 Роль не массовая; часть спроса спрятана в DevOps/SRE и platform reliability
Формат работы Удалённо 14%, гибрид 60%, офис 26% Для SRE важны не только дни в офисе, но и правила on-call и эскалаций
Уровень входа Junior 8%, Middle 7.7%, Senior 38.5%, Lead — Рынок ориентирован на опытных инженеров; новичку нужен сильный учебный кейс
Кому подходит Инженерам, которым интересны сбои, метрики, причины и системные улучшения Нужны спокойствие, документация и готовность спорить о риске на языке данных
Где работает Финтех, SaaS, облака, маркетплейсы, high-load, внутренние платформы SRE особенно нужен там, где простой стоит денег или доверия
Куда растёт Senior SRE, Lead SRE, Platform Engineer, Staff Engineer, Infrastructure Architect Рост идёт через ответственность за reliability practice и архитектурные решения

Рабочий день SRE-инженера: от алерта до postmortem

Рабочий день SRE редко состоит только из мониторинга. Хороший сценарий начинается с сигнала, проходит через восстановление и заканчивается изменением, которое снижает повторяемость проблемы.

Ситуация Что проверяет SRE Какой результат ожидается Когда нужна эскалация Что улучшить после инцидента
Рост latency SLO по задержке, свежие релизы, зависимости, нагрузку, базу данных Понять impact и снизить задержку без хаотичных изменений Если затронут критичный пользовательский путь или burn rate растёт Уточнить SLI, пороги алерта, capacity и rollback-критерии
Падение availability Долю успешных запросов, регионы, балансировку, health checks, внешние зависимости Вернуть доступность и зафиксировать timeline Если SLO нарушается или инцидент выходит за командный контур Добавить защиту от повторения и проверить runbook
Ошибки после релиза Версию, canary-сигналы, error rate, логи, изменения конфигурации Принять решение: остановить rollout, откатить или включить обходной путь Если ошибка влияет на оплату, авторизацию или критичный API Уточнить pre-release checks и критерии отката
Перегрузка базы данных Latency запросов, connection pool, locks, slow queries, saturation Снизить нагрузку и сохранить целостность данных Если деградация влияет на несколько сервисов или риск потери данных растёт Пересмотреть capacity planning, индексы, лимиты и алерты
Очередь растёт быстрее обработки Producer/consumer rate, lag, retry, dead-letter queue, зависимые сервисы Остановить рост backlog или безопасно ограничить входящий поток Если накопление угрожает SLO или бизнес-операциям Уточнить autoscaling, backpressure и дашборд очередей
Шумный алерт Связь алерта с пользовательским impact, частоту, владельца, действие Оставить только сигнал, по которому нужно действовать Если шум скрывает реальный инцидент или будит on-call без причины Переписать правило, добавить runbook и удалить дубли
Kubernetes-под часто рестартует Events, readiness/liveness, лимиты ресурсов, зависимости, последние изменения Понять, это симптом приложения, ресурсов или конфигурации Если рестарты бьют по SLO или затрагивают несколько реплик Уточнить лимиты, probes, rollout strategy и дашборд
Проблема с внешней зависимостью SLO зависимости, timeout, retries, fallback, impact на пользователя Снизить влияние сбоя поставщика на свой сервис Если нет обходного пути или клиентский сценарий остановлен Добавить graceful degradation и коммуникационный шаблон
Недостаток capacity перед пиком Прогноз нагрузки, saturation, лимиты, autoscaling, историю похожих периодов Подготовить запас мощности без бессмысленного оверпровижининга Если прогноз показывает риск нарушения SLO Обновить capacity model и нагрузочные проверки в стенде
Ночной on-call-инцидент Severity, impact, известный runbook, владельцев, безопасные варианты восстановления Восстановить сервис и не потерять факты для postmortem Если runbook не покрывает ситуацию или нужен product/engineering decision Снизить шум, уточнить эскалации и убрать повторяемую причину
Внешние источники
Google SRE: Managing Incidents Google SRE: Postmortem Culture

SRE-практики: SLI, SLO, SLA, Error Budget, Toil и Postmortem

SRE-практики нужны, чтобы команда могла обсуждать надёжность как инженерный риск. Цель не в абсолютной доступности. Такая цель часто слишком дорогая и всё равно не отменяет сбои внешних зависимостей.

Термин Простое объяснение Зачем нужен бизнесу Как применяет SRE Типичная ошибка новичка
SLI Измеримый показатель сервиса Показывает, где пользователь реально чувствует качество Выбирает latency, availability, error rate или другой сигнал Мерить то, что легко собрать, а не то, что важно пользователю
SLO Целевой уровень SLI Помогает договориться о допустимом качестве Формулирует реалистичную цель и период измерения Требовать абсолютную доступность без обсуждения цены и риска
SLA Соглашение с последствиями при нарушении Защищает ожидания клиента и бизнеса Помогает не провалить SLA через SLO и мониторинг Путать SLA с внутренней инженерной целью
Error Budget Допустимый запас ошибок внутри SLO Балансирует скорость релизов и устойчивость Смотрит burn rate и предлагает замедлить рискованные изменения Использовать как наказание, а не инструмент договорённости
Error Budget Policy Правила действий при сгорании бюджета Убирает споры в момент кризиса Заранее фиксирует, когда стопорить релизы или чинить надёжность Не согласовать policy с продуктом и разработкой
Burn Rate Скорость расходования error budget Показывает, насколько быстро команда приближается к нарушению SLO Использует для приоритета инцидента и алертов Смотреть только дневную среднюю и пропустить быстрый пожар
Golden Signals Latency, traffic, errors, saturation Дают базовый взгляд на состояние сервиса Строит дашборды и алерты вокруг пользовательского риска Считать четыре сигнала полной observability
Observability Метрики, логи, трассировки, алерты и контекст Сокращает время понимания проблемы Связывает сигналы с SLO и инцидентами Коллекционировать графики без действия
Alert Quality Качество сигнала для on-call Снижает шум и выгорание Оставляет алерты с понятным impact и runbook Будить команду по симптомам без действия
Toil Ручная повторяемая работа без долгосрочной ценности Съедает инженерное время и растёт вместе с масштабом Автоматизирует или убирает причину Героически делать одно и то же руками
Runbook Инструкция восстановления для известной ситуации Снижает зависимость от памяти конкретного инженера Пишет безопасные шаги, эскалации и критерии остановки Сделать runbook без владельца и обновления
Playbook Сценарий действий для класса проблем Помогает команде действовать согласованно Описывает роли, коммуникации и ветки решений Путать playbook с разовой заметкой
On-call Дежурство по production-сервису Даёт быстрый канал реагирования Улучшает алерты, эскалации и runbook-и Строить практику на постоянном героизме
Incident Response Организованное реагирование на сбой Снижает ущерб и время восстановления Ведёт факты, роли, коммуникацию и восстановление Хаотично менять всё подряд без timeline
Blameless Postmortem Разбор инцидента без поиска виноватого Превращает сбой в улучшение системы Фиксирует impact, причины и action items Написать отчёт без изменений после него
MTTR Среднее время восстановления Показывает скорость возврата сервиса Снижает через runbook-и, rollback и диагностику Оптимизировать MTTR и забыть про частоту инцидентов
MTTD Среднее время обнаружения Показывает, как быстро команда узнаёт о проблеме Улучшает через SLO monitoring и алерты Полагаться на жалобы пользователей как главный сигнал
Capacity Planning Планирование мощности под нагрузку Снижает риск деградации в пиковые периоды Смотрит тренды, лимиты, очереди и saturation Покупать запас без понимания bottleneck
Canary Release Постепенный выпуск изменения на часть трафика Уменьшает риск массового сбоя Смотрит SLO-сигналы и останавливает rollout Делать canary без метрик успеха
Rollback Возврат к безопасному состоянию Сокращает impact неудачного релиза Заранее описывает критерии и путь отката Думать об откате только после аварии
Внешние источники
Google SRE: Service Level Objectives Google SRE: Eliminating Toil

Observability: метрики, логи, трассировки и алерты

Observability в SRE нужна не ради красивых графиков, а ради быстрого ответа: что сломалось, кого затронуло, нарушен ли SLO, что безопасно делать сейчас и что улучшить после инцидента.

Слой наблюдаемости Что показывает Примеры сигналов Какие инструменты встречаются Какую ошибку помогает найти
Метрики Числовое состояние сервиса во времени Latency, traffic, errors, saturation, queue lag Prometheus, Grafana, Zabbix, cloud monitoring Рост задержки, saturation, падение успешных запросов
Логи События и контекст внутри приложения или инфраструктуры Ошибки, audit events, Nginx logs, application logs ELK Stack, Loki, cloud logging Неожиданное поведение после релиза или ошибки интеграции
Трассировки Путь запроса через сервисы Spans, dependency latency, error path OpenTelemetry, Jaeger, cloud tracing Медленную зависимость или узкое место в цепочке
Алерты Сигналы, требующие действия SLO violation, burn rate, error spike, saturation Alertmanager, Grafana Alerting, Zabbix Проблему, которую нужно поднять до on-call
Дашборды Сводную картину для диагностики Golden signals, release markers, dependency panels Grafana, cloud dashboards Непонятную связь между релизом и деградацией
Synthetic monitoring Проверку сценария извне Login, checkout, API health, endpoint probes Blackbox exporters, cloud monitoring Сбой, видимый пользователю, но не видимый серверу
Real User Monitoring Фактический опыт пользователей Client latency, browser errors, geography, device RUM-платформы, frontend monitoring Проблему на клиенте или в конкретном регионе
SLO monitoring Состояние цели надёжности Availability SLO, latency SLO, success rate Prometheus, Grafana, SLO tooling Нарушение пользовательского уровня, а не просто серверную метрику
Error budget burn Скорость расходования допустимого риска Fast burn, slow burn, remaining budget SLO tools, Prometheus rules Ситуацию, когда проблема быстро превращается в нарушение SLO
Business metrics Влияние технического сбоя на продукт Оплаты, заказы, регистрации, успешные операции BI, product analytics, custom metrics Сбой, который инфраструктура считает нормой, а бизнес уже видит как потерю

SRE, DevOps, Platform Engineer, системный администратор, Cloud Engineer и Production Engineer

В вакансиях роли часто смешиваются. Практическая граница проходит по результату: кто отвечает за поставку, кто за платформу, кто за инфраструктуру, а кто за измеримую надёжность production-сервиса.

Роль Главный фокус Чем занимается Какие метрики важны Где пересекается с SRE Чем отличается от SRE Когда нужна компании
SRE-инженер Измеримая надёжность сервиса SLO, incident response, observability, toil reduction, postmortem SLI, SLO, burn rate, MTTR, MTTD, alert noise С DevOps, platform, cloud, backend ownership Это сама роль: reliability outcome в центре Есть критичные сервисы, on-call и цена простоя
DevOps-инженер Поставка, автоматизация и инфраструктурные практики CI/CD, IaC, окружения, deployment, инфраструктурный workflow Deployment frequency, lead time, failure rate, infra health CI/CD, Kubernetes, Terraform, monitoring DevOps шире про delivery; SRE уже про SLO и инциденты Нужно ускорить и стабилизировать delivery
Platform Engineer Внутренняя платформа для разработчиков Developer portal, paved roads, self-service, platform APIs Adoption, developer experience, platform SLO Kubernetes, CI/CD, observability, стандарты Строит продукт для разработчиков; SRE отвечает за надёжность сервисов Много команд и нужен единый путь разработки
Системный администратор Работоспособность систем и инфраструктуры Серверы, сети, доступы, обновления, backup, заявки Uptime узлов, ресурсы, tickets, backup success Linux, сети, мониторинг, восстановление Чаще поддерживает компоненты; SRE меняет причины пользовательских сбоев Нужна стабильная инфраструктурная эксплуатация
Cloud Engineer Облачная инфраструктура VPC, IAM, compute, storage, backup, cloud security, cost Availability cloud resources, cost, quota, security posture Cloud monitoring, IaC, capacity, resilience Облако — среда работы; SRE фокусируется на SLO сервиса Компания активно использует cloud-платформу
Production Engineer Production-среда и производственные ограничения Производительность, релизы, эксплуатация, диагностика, scaling Latency, throughput, error rate, resource use Инциденты, performance, capacity, reliability fixes Название может быть шире или ближе к product engineering Нужна инженерия вокруг живого production
Infrastructure Engineer Инфраструктурные компоненты Сети, хранилища, кластеры, виртуализация, базовые сервисы Resource health, utilization, fault domains Linux, Kubernetes, networking, monitoring Может не отвечать за пользовательский SLO Нужна команда базовой инфраструктуры
Backend-разработчик с production ownership Код сервиса и его поведение в production Фичи, API, производительность, логи, исправления после инцидентов Error rate, latency, business success, deploy health SLO, observability, postmortem, rollback Пишет продуктовый код; SRE помогает строить reliability-практику шире Команда владеет сервисом от кода до эксплуатации

Уровни SRE: Intern, Junior, Middle, Senior, Lead

В данных SkillStat по SRE заметна ориентация на опытных специалистов. Грейд определяется не набором бейджей, а зоной ответственности за сервис, инциденты и риск.

Уровень Роль Типичные задачи Какие навыки нужны Какие инструменты Доказательство уровня Куда расти дальше
Intern / стажёр Помогает команде эксплуатации и наблюдаемости Читает runbook-и и собирает факты Linux/HTTP/DNS/Git/мониторинг Linux, Git, Grafana, простые логи Учебный сервис с README и метриками Junior SRE или infrastructure support
Junior SRE Работает рядом с on-call и не принимает риск один Базовые алерты, runbook, дежурства Linux/сети/мониторинг/Docker/CI/CD Grafana, Prometheus, Docker, GitLab CI, Zabbix Алерт с действием и учебный postmortem Middle SRE, DevOps/SRE, NOC/platform junior
Middle SRE Берёт service ownership в понятном контуре Observability, incident response, SLO SLI/SLO, Kubernetes, CI/CD, troubleshooting Kubernetes, Prometheus, Grafana, ELK/Loki, Terraform Сервис с SLO, rollback и reliability fix Senior SRE или Platform Engineer
Senior SRE Владеет риском надёжности сервиса SLO ownership, error budget, incident leadership Архитектура, distributed systems, бизнес-риск Kubernetes/cloud/OpenTelemetry/dependency metrics Кейс снижения повторных инцидентов Lead SRE, Staff SRE, Infrastructure Architect
Lead SRE Строит reliability practice команды или направления On-call, postmortem culture, стандарты observability Лидерство, стандарты, приоритизация риска SLO tooling, incident management, platform standards Стандарт SLO/alerting и улучшение процесса Head of Reliability, Engineering Manager, Staff/Principal
Staff / Principal SRE Решает системные reliability-проблемы на уровне компании Стратегия надёжности и cross-team incidents Глубокая инженерия и влияние без прямого управления Зависит от платформы компании Комплексный reliability improvement across teams Технический лидер инфраструктуры или архитектуры

Чем занимается SRE-инженер

Требования

сценарии, критерии и постановка задачи

  • Определять и поддерживать SLI, SLO, бюджет ошибок и практики измерения надёжности продукта.
  • Убирать повторяемую ручную работу кодом, runbook-ами, самовосстановлением и изменением слабых мест.
Система

данные, api, статусы и интеграции

  • Строить наблюдаемость: метрики, логи, трассировки, алерты, дашборды и правила эскалации.
  • Планировать мощность, лимиты и отказоустойчивость, чтобы рост нагрузки не превращался в аварии.
Команда

согласование и работа с разработкой

  • Участвовать в инцидентах, проводить постмортемы и превращать выводы в инженерные изменения.
  • Помогать командам выпускать изменения безопасно: постепенная выкладка, откат и проверка готовности сервиса.

Как выглядит работа по задаче

Работа SRE идёт от пользовательского риска к инженерному изменению. Сначала нужно измерить надёжность, затем построить наблюдаемость, реагировать на инциденты и убирать повторяемую ручную работу.

Шаг 01

Определяет сигналы

Выбирает SLI и SLO, которые отражают реальный опыт пользователя, а не только состояние серверов.

Шаг 02

Строит наблюдаемость

Настраивает метрики, логи, трассировки, дашборды и алерты с понятным действием.

Шаг 03

Реагирует на инцидент

Помогает восстановить сервис, координирует факты, коммуникацию и эскалации.

Шаг 04

Разбирает инцидент

Находит системные причины без обвинений и фиксирует изменения, которые нужно сделать.

Шаг 05

Снижает ручную рутину

Автоматизирует повторяемую работу и меняет слабые места в коде, инфраструктуре или процессе.

SRE-инженер и системный администратор: в чём разница

Системный администратор чаще отвечает за стабильность инфраструктуры, а SRE связывает эксплуатацию с продуктовой надёжностью, релизами и инженерными изменениями.

01
Фокус
SRE-инженер

Пользовательская надёжность сервиса, SLO, инциденты и снижение ручной рутины.

Системный администратор

Работоспособность серверов, сетей, систем и инфраструктурных компонентов.

02
Подход
SRE-инженер

Измеряет риск, автоматизирует повторяемую работу и меняет причины сбоев.

Системный администратор

Настраивает, поддерживает, обновляет и восстанавливает инфраструктуру.

03
Инциденты
SRE-инженер

После восстановления проводит разбор инцидента и добивается системных улучшений.

Системный администратор

Чаще отвечает за оперативное восстановление работоспособности системы.

04
Метрики
SRE-инженер

SLI, SLO, бюджет ошибок, время восстановления, шум алертов, ручная рутина и пользовательский эффект.

Системный администратор

Доступность узлов, ресурсы, резервные копии, обновления, инвентаризация и заявки.

05
Результат
SRE-инженер

Сервис меняется быстрее без неконтролируемого роста риска.

Системный администратор

Инфраструктура работает стабильно и предсказуемо в заданных правилах.

Навыки SRE-инженера: что требуют работодатели

Работодатели обычно смотрят на два слоя навыков. Первый слой — core reliability skills. В него входят SLI, SLO, бюджет ошибок и incident response. Рядом стоят постмортемы, observability, качество алертов, планирование мощности и снижение повторяемых сбоев. Второй слой — инфраструктурный tooling context. Здесь важны Linux, сети, Kubernetes, Docker и CI/CD. Дополняют картину облака, Terraform, Prometheus и Grafana. Для части ролей важны логи, трассировки, базы данных и scripting.

На собеседовании часто проверяют не список инструментов, а ход мысли. Например: сервис стал медленным после релиза. Алерты шумят, база упёрлась в лимиты, очередь растёт. Ночью всё починили руками, но причина осталась. Сильный кандидат задаёт вопросы про SLO, пользователей и последние изменения. Потом уточняет зависимости, откат, метрики и план предотвращения повторения.

Для senior-позиций важны культура разборов без обвинений, влияние на разработчиков, архитектурные ограничения и планирование мощности. SRE не должен молча принимать любой риск и потом отвечать за последствия. Он обязан уметь объяснить, почему релиз, лимит или архитектурный компромисс опасен для сервиса.

В текущем активном срезе по этой роли 43 вакансий. Список работодателей ниже построен по накопленной статистике SkillStat, поэтому его нужно читать как ориентир по источникам вакансий, а не как долю текущего рынка.
Топ работодателей
Компании, которые встречаются в вакансиях по профессии SRE-инженер
1
Сбер. IT
23 вак.
2
Fix Price. IT
9 вак.
3
Альфа-Банк. ИТ-специалисты
9 вак.
4
ГКУ Инфогород
8 вак.
5
VK, VK Tech
8 вак.
6
RWB (Wildberries & Russ)
6 вак.
Полная карта навыков SRE-инженер →
Вход через junior
8%
от рынка

Рынок ориентирован на опытных специалистов.

На одну junior-вакансию приходится примерно 5 senior-позиции.
Навыков на вакансию
16
в среднем

Столько требований работодатели обычно собирают в одной позиции по этой роли.

Курс · подобран по данным рынка

Лучший курс для SRE-инженера

Соответствие рассчитано по стеку из 43 вакансий — это не реклама, а совпадение со спросом работодателей.

Лучшее совпадение
76%
соответствие
Практикум
Практикум
онлайн · с куратором
SRE — обеспечение надёжности систем
4 месяцев Сертификат
★4.5
от 4 490 ₽/мес

Навыки SRE-инженера: ядро, инфраструктура, код и коммуникация

Навыки SRE лучше делить на четыре слоя. Так проще не утонуть в инструментах и понять, что именно доказывает готовность к роли.

Группа Что входит Зачем нужно Как доказать
Reliability skills SLI, SLO, SLA, Error Budget, Incident Response, Postmortem, Toil reduction, Observability, Alert quality, Capacity planning, On-call, Rollback/canary Чтобы управлять надёжностью через данные и действия Показать SLO, алерт, incident timeline, postmortem и action items
Infrastructure/tooling Linux, сети, DNS, HTTP, Kubernetes, Docker, CI/CD, Terraform, Ansible, Prometheus, Grafana, ELK, PostgreSQL, Redis, Kafka, Nginx, cloud Чтобы понимать, где и почему ломается production-сервис Развернуть учебный сервис, добавить observability и описать failure modes
Programming/scripting Python, Go, Bash, SQL, YAML, Helm, IaC, автоматизация runbook-ов Чтобы снижать toil и связывать системы между собой Сделать небольшую автоматизацию повторяемой операции и объяснить риск
Soft skills Спокойствие в инциденте, коммуникация, приоритизация, системное мышление, документация, blameless-культура Чтобы команда восстанавливалась быстро и училась на сбоях Показать postmortem, runbook и решения, согласованные с разработкой и продуктом

Инструменты SRE-инженера

Инструменты в резюме лучше описывать через результат: что вы измеряли, какой риск снижали, как восстанавливали сервис и какую ручную работу убрали.

Инструмент / класс Для чего нужен На каком уровне нужен Как безопасно описать в резюме Что важно понимать
Linux База эксплуатации, процессы, ресурсы, сеть, логи Junior+ Работал с диагностикой Linux-сервисов и ресурсных ограничений Не путать знание команд с пониманием причин деградации
Kubernetes Оркестрация контейнеров, rollout, probes, resources Junior+/Middle Поддерживал сервисы в Kubernetes и разбирал рестарты, rollout и лимиты Kubernetes — часть SRE, а не вся профессия
Docker Контейнеризация приложения и окружения Junior+ Собирал и запускал сервисы в контейнерах для стенда и диагностики Важно понимать сеть, volumes, образы и ограничения
Helm Шаблоны деплоя в Kubernetes Middle Описывал конфигурацию деплоя и безопасные изменения values Шаблон не должен скрывать риск релиза
Terraform Infrastructure as Code Middle+ Описывал воспроизводимое окружение и изменения через review Нужны state, plan, drift и безопасный rollout
Ansible Автоматизация конфигураций и операций Junior+/Middle Автоматизировал повторяемые инфраструктурные операции Не превращать playbook в опасную ручную кнопку
CI/CD, GitLab CI, Jenkins Поставка изменений и контроль релиза Junior+ Улучшал pipeline, проверки и rollback-контур Delivery должен быть связан с SLO-сигналами
Prometheus Сбор и запрос метрик Junior+/Middle Описывал сервисные метрики, SLI и алерты Метрика должна вести к действию
Grafana Дашборды и алерты Junior+ Делал дашборд по latency, traffic, errors, saturation Дашборд без владельца быстро устаревает
Alertmanager Маршрутизация алертов и on-call Middle Настраивал маршруты, группировку и подавление шума Важно не скрыть реальный инцидент
Zabbix Мониторинг инфраструктуры Junior+ Поддерживал инфраструктурные проверки и эскалации Инфраструктурный сигнал нужно связать с сервисным impact
ELK Stack / Loki Логи и поиск событий Junior+/Middle Использовал логи для диагностики инцидентов Логи должны иметь контекст и не хранить лишние секреты
OpenTelemetry / Jaeger Трассировки и связь сервисов Middle+ Добавлял трассировку для поиска медленных зависимостей Трассировка полезна только при понятной карте сервиса
Nginx Reverse proxy, routing, логи, TLS-контур Junior+/Middle Разбирал ошибки маршрутизации и edge latency Нужно понимать клиентский impact
PostgreSQL, Redis, Kafka Базы, кэш, очереди и их метрики Middle+ Диагностировал latency, saturation, lag и retry Не делать опасных действий без DBA/owner и плана восстановления
Cloud monitoring Сигналы облачной инфраструктуры Middle Связывал cloud-метрики с SLO сервиса Cloud health не всегда равен user health
DNS, Load balancer Доступность и маршрутизация трафика Junior+/Middle Разбирал проблемы доступности и внешнего доступа Ошибки здесь быстро становятся пользовательскими
Python, Go, Bash, SQL Автоматизация, tooling, проверки, анализ Junior+ Писал небольшие утилиты и запросы для устранения toil Код должен быть проверяемым и безопасным
Jira / incident management Задачи, timeline, action items, коммуникация Junior+ Вёл incident ticket, postmortem actions и follow-up Задача без владельца и срока не снижает риск
Status page / коммуникации Информирование пользователей и бизнеса Middle+ Готовил фактические обновления без лишних обещаний Коммуникация должна быть точной и согласованной
Смежные профессии
DevOps-инженер 12 Инженер поддержки 11 Тимлид 7 Go-разработчик 7 Python-разработчик 6 DevSecOps-инженер 6

Сколько зарабатывает SRE-инженер

Для SRE-инженера сейчас доступна рыночная оценка дохода, а не точная медиана только по текущим активным вакансиям. Её лучше читать вместе с подписью источника и структурой рынка по уровням.
Оценка зарплаты Оценка
245 000₽
Москва и МО · Оценка по профессии и близкому рынку
Смежная роль: Инженер поддержки · n=78
Смежная роль: DevOps-инженер · n=57
Вакансии профессии за 180 дней · n=25
Опора оценки
11
наблюдений в опорном срезе
Диапазон и позиция в зарплатном рейтинге не показаны: зарплата рассчитана в estimated-режиме, поэтому SkillStat не выводит эти значения, чтобы не создавать ложную точность.
На 23.06.26 SkillStat показывает для SRE-инженера в Москве и МО зарплатную оценку 245 000 ₽. Это оценка-режим: расчёт опирается на расширенное окно вакансий, текущая зарплатная выборка — n=11. Зарплатную оценку SkillStat нужно читать как ориентир по вакансиям за 180 дней в регионе и на дату среза, а не как гарантированную медиану для каждого SRE-инженера.
Зарплата по грейдам
Медиана зарплаты по грейду. n — выборка вакансий с указанной суммой.

Для estimated-режима грейдовые зарплаты не показываются, чтобы не создавать ложную точность.

Распределение по уровням
Middle
54% рынка
Senior
39%
Middle
54%
Junior
8%
По структуре вакансий видно, какой уровень для этой профессии считается базовым на рынке. Это помогает читать грейды не как абстрактную лестницу, а как реальную точку входа и роста.
Дополнительный разбор

Где начинается рост

Оценка особенно чувствительна к грейду. В SRE-выборке рынок смещён к опытным специалистам: Senior — 39%, Middle — 38.5%, Lead — —, Junior — 8%. Поэтому число стоит сопоставлять с on-call-зоной, критичностью сервиса, SLO ownership и incident leadership.

Что говорит структура рынка

Доход растёт, когда SRE не только поддерживает кластер, а меняет причины сбоев. Выше ценятся SLO, observability, incident response, capacity planning, postmortem fixes, automation, Kubernetes/cloud-scale infrastructure, Terraform/CI/CD и scripting.

Вакансии SRE-инженера: спрос и динамика рынка

Спрос на SRE-инженера лучше читать как сочетание объёма найма, ранга профессии в общей выборке и устойчивости вакансий во времени. Виджеты выше дают быстрый срез рынка, а график ниже помогает понять, насколько этот спрос поддерживается от месяца к месяцу.

Активные вакансии
43
в активном найме
Москва и МО · текущий срез 23.06.26
7 дней назад
60
16.06.26 -28%
30 дней назад
73
24.05.26 -41%
Спрос
20
из 100
Ранг по спросу
#35 из 71
Статус
Низкий
Среднее число активных вакансий по месяцам
Блок показывает среднее число активных вакансий за месяц, чтобы видеть общую картину без шума отдельных дней.
июнь 57 неполный -15
май 72 +1
апрель 71 +6
март 65 -13
февраль 78
Июнь пока показан как текущий неполный месяц, поэтому его лучше читать как живую картину рынка, а не как итог месяца.
Дополнительный разбор

Числа в виджетах дают live-срез рынка, а текст ниже объясняет факторы спроса. В текущем срезе SkillStat по Москве и МО у SRE-инженера 43 активных вакансий; статус спроса — низкий, позиция — #35 из 71. Это не массовая junior-роль: Junior даёт 8%, а отношение senior-позиций к junior — 5.0.

Формат работы смешанный: удалённо 14%, гибрид 60%, офис 26%. Средняя вакансия требует около 16 навыков. Работодатель обычно ищет связку reliability practice и инфраструктурного контекста: SLO, incident response, observability, on-call, Kubernetes, Linux, CI/CD и scripting.

Часть спроса спрятана в соседних названиях: DevOps/SRE, production engineer, infrastructure reliability engineer, platform reliability engineer или Platform Engineer с reliability-зоной. Настоящую SRE-позицию отличает право менять причины сбоев, а не только поддерживать инфраструктуру по заявкам.

Формат работы SRE-инженера

Этот срез показывает, в каком формате работодатели чаще всего открывают вакансии по профессии: удалённо, гибридно или с полной привязкой к офису.

Сейчас сильнее всего выражен гибридный формат: его отрыв от следующего сценария составляет около 35 п.п.
Удалённо
14%
Гибрид
60%
Офис
26%
По 43 вакансиям

Карьерный путь SRE-инженера

Грейдовые медианы не показаны: для SRE-инженера сейчас используется estimated-режим зарплаты, поэтому SkillStat не выводит отдельные зарплаты по уровням, чтобы не создавать ложную точность.

01
Junior

Вход обычно идёт через поддержку инфраструктуры, системное администрирование, DevOps, backend или cloud engineering. Junior работает с runbook-ами и алертами. Ему нужны Linux, сети, мониторинг и понимание типовых сбоев.

02
Middle

Middle берёт service ownership. Он ведёт наблюдаемость, улучшает алерты и участвует в incident response. Его изменения уже должны быть связаны с пользовательским риском.

03
Senior

Senior отвечает за SLO, error budget и incident leadership. На этом уровне важны capacity planning и архитектурные решения, которые снижают повторяемость сбоев.

04
Lead

Lead SRE строит reliability practice: стандарты наблюдаемости, правила on-call и культуру постмортемов. На всех уровнях рост идёт по двум линиям: ядро надёжности и инструментальный контекст.

Где работает SRE-инженер

Финтех и платежи

Надёжность напрямую связана с транзакциями, доверием клиентов, регуляторикой и ценой простоя.

Интернет-торговля и доставка

Пиковые нагрузки, заказы, оплата и логистика требуют быстрых релизов без разрушения сервиса.

SaaS и облачные платформы

Критичны доступность API, разделение общих ресурсов между клиентами, наблюдаемость и предсказуемое восстановление.

Путь в профессию: SRE-инженером

Практический путь входа в профессию: что освоить сначала, как собрать рабочую базу и на чём быстрее всего набирается прикладная уверенность.

01
Освоить эксплуатационную базу

Linux, сети, DNS и базы данных. Затем очереди, контейнеры, облака и типовые причины сбоев.

02
Научиться наблюдаемости

Настраивать метрики, логи, трассировки и алерты вокруг пользовательских сценариев.

03
Поработать с инцидентами

Разобраться в эскалациях, восстановлении, коммуникации и разборах инцидентов без обвинений.

04
Автоматизировать рутину

Искать повторяемую ручную работу и заменять её кодом, инструкцией восстановления или изменением процесса.

05
Связать надёжность с продуктом

Понять, какой уровень доступности нужен пользователям и какую цену компания готова платить.

Production-like сервис с SLO, инцидентом и исправлением

Для начинающего SRE сильнее всего работает один цельный учебный кейс: небольшой сервис, измеримая надёжность, наблюдаемость, безопасный инцидент в стенде, восстановление, postmortem и конкретное улучшение после разбора.

01

README с описанием сервиса, пользовательского сценария, SLI, SLO и условий, при которых SLO считается нарушенным.

02

Дашборд Prometheus/Grafana или аналогичный набор метрик: latency, traffic, errors, saturation и бизнес-сигнал, если он уместен для учебного сервиса.

03

Алерт с понятным действием: что проверяет дежурный, когда нужна эскалация и как понять, что это пользовательский риск, а не шум.

04

Runbook восстановления: безопасные проверки, порядок коммуникации, критерии отката и условия, при которых нужен более опытный инженер.

05

Учебный postmortem без поиска виноватого: факты, impact, причины, что сработало, что не сработало и какие action items уменьшают повторение.

06

Небольшая автоматизация toil: скрипт, проверка, конфигурационное изменение или улучшение runbook-а, которое убирает повторяемую ручную операцию.

07

Rollback или canary-сценарий в тестовой среде с объяснением, какой риск он снижает и как команда принимает решение об откате.

Путь в профессию
Как стать SRE-инженером: данные из вакансий
Roadmap, junior-рынок, проекты для портфолио, первый оффер — без обещаний, с цифрами.
Как стать SRE-инженером
Курсы · подобрано по данным рынка

Курсы для SRE-инженера

Сопоставили программы с реальным стеком из 43 вакансий — оценка соответствия рассчитана автоматически, это не реклама.

Соответствие — доля ключевых навыков из вакансий, которые охватывает программа курса

Roadmap SRE на 6–12 месяцев

Roadmap лучше проходить через один учебный сервис, постепенно добавляя эксплуатацию, наблюдаемость, инциденты и автоматизацию. На старте не нужно тонуть в редких enterprise-инструментах, сложном distributed systems design и chaos engineering до базовой подготовки.

Период Что учить Практика Что показать
0–1 месяц Linux, сети, DNS, HTTP, базовое понимание production-сервисов, инцидент, алерт, лог, метрика Поднять простой сервис и научиться смотреть его состояние README с архитектурой, зависимостями и первыми метриками
2–3 месяц Docker, CI/CD, Git, базовый Python или Bash, базы данных, простой деплой Собрать контейнер, pipeline и окружение для тестового сервиса Рабочий деплой, логирование и простая проверка здоровья
3–5 месяц Kubernetes, Prometheus, Grafana, алерты, логи, трассировки, SLI/SLO/SLA, error budget Добавить observability и описать пользовательский SLO Дашборд, SLO, alert rule и объяснение выбора сигналов
5–8 месяц Incident response, runbook, postmortem, rollback/canary, capacity planning, учебные нагрузочные сценарии Провести безопасный учебный инцидент в стенде Timeline, runbook, postmortem и reliability improvement
8–12 месяц Terraform, Ansible, OpenTelemetry, ELK/Loki/Jaeger, toil reduction, подготовка резюме Сделать воспроизводимое окружение и автоматизацию ручного шага IaC, automation case и описание результата в резюме
Куда смотреть в вакансиях DevOps/SRE, support infrastructure, NOC, platform junior, cloud support Искать задачи с observability, on-call, incident response и SLO Не продавать себя как Senior SRE без production-опыта

Как перейти в SRE из смежных профессий

В SRE часто переходят не напрямую с нуля, а из ролей, где уже есть часть production-контекста. Ниже — что сохранить и что добрать.

Откуда переход Что уже полезно Чего не хватает Что учить в первую очередь Какие вакансии смотреть Что показать Ошибка
DevOps CI/CD, IaC, Kubernetes, delivery SLO, error budget, incident leadership SRE-практики, alert quality, postmortem DevOps/SRE, Platform Reliability Снижение шума алертов и SLO-кейс Считать SRE просто новым названием DevOps
Системное администрирование Linux, сети, восстановление, мониторинг Разработка, SLO, product impact Python/Bash, Prometheus/Grafana, incident response Infrastructure SRE, support infrastructure Runbook, диагностика, automation toil Остаться только в заявках и серверах
Backend Код сервиса, API, ошибки, производительность Инфраструктура, on-call, observability Linux, Kubernetes, monitoring, rollback Backend with production ownership, SRE junior-adjacent Сервис с метриками и postmortem Игнорировать эксплуатационные ограничения
Техническая поддержка Пользовательский impact, коммуникация, tickets Глубина Linux/сети/сервисов Linux, HTTP, логи, мониторинг Infrastructure support, NOC, junior SRE-adjacent Incident timeline и runbook Описывать только общение без инженерии
NOC Алерты, эскалации, дежурства Причины сбоев и инженерные изменения SLO, Prometheus/Grafana, Linux, automation NOC to SRE, operations engineer Улучшение алерта и эскалации Остаться диспетчером сигналов
Cloud engineering Cloud resources, IAM, VPC, monitoring Service SLO and incident practice SLO, Kubernetes, observability, postmortem Cloud SRE, platform reliability Cloud service SLO и capacity case Свести SRE к настройке облака
Platform engineering Internal platform, self-service, Kubernetes Пользовательский SLO и on-call сервисов Reliability practice, incident response Platform Reliability Engineer Платформенный SLO и adoption-impact Оптимизировать DX без связи с reliability
QA / performance testing Тестовые сценарии, нагрузка, дефекты Production ownership, observability, recovery Linux, monitoring, SLO, incident response Performance/SRE, reliability testing Capacity planning для учебного сервиса Остановиться на тестах без эксплуатации

Что показать в портфолио начинающему SRE

Портфолио SRE должно показывать не только инфраструктуру, но и ход надёжности: сигнал, риск, восстановление, postmortem и улучшение.

Кейс Что показать Инструменты Результат Как описать в резюме
Учебный сервис с SLI/SLO Пользовательский сценарий, SLI, SLO, период измерения API service, Prometheus, Grafana Понятная цель надёжности Описал SLO для учебного сервиса и связал его с пользовательским сценарием
Дашборд Latency, traffic, errors, saturation Prometheus/Grafana Видно состояние сервиса и деградацию Собрал дашборд golden signals для диагностики
Алерт с действием Порог, impact, runbook, эскалация Alertmanager, Grafana Alerting On-call понимает, что делать Улучшил alert quality и снизил шум
Runbook восстановления Проверки, критерии остановки, владельцы Markdown, Jira/issue tracker Меньше зависимости от памяти инженера Написал runbook для типового инцидента
Postmortem учебного инцидента Timeline, impact, root causes, action items Markdown, dashboard links Сбой превращён в улучшения Провёл blameless postmortem с follow-up задачами
Rollback-сценарий Критерии отката и безопасный путь CI/CD, Kubernetes Понятно, когда и как вернуть сервис Описал rollback-критерии по SLO-сигналам
Canary-релиз Постепенный rollout и метрики успеха Kubernetes, CI/CD, Grafana Риск релиза ограничен Проверял canary через error rate и latency
Анализ error budget Remaining budget, burn rate, решение команды SLO tooling, Prometheus Есть правило, когда снижать риск Связал burn rate с решением о релизе
Снижение шумных алертов До/после, частота, действие Alertmanager, Grafana Меньше ложных вызовов Переписал алерты вокруг пользовательского impact
Автоматизация ручной операции Повторяемый шаг и безопасная автоматизация Python, Bash, Ansible Меньше toil Автоматизировал ручную проверку и добавил guardrails
Логи и трассировка Корреляция запроса, ошибка, dependency latency Loki/ELK, OpenTelemetry, Jaeger Быстрее поиск причины Добавил tracing/log context для диагностики
Capacity planning Прогноз нагрузки и bottleneck Prometheus, Grafana, simple load test Понятен предел учебного сервиса Оценил capacity и предложил план роста
IaC-окружение Воспроизводимый стенд Terraform, Ansible Среду можно пересобрать Описал инфраструктуру как код для учебного стенда
Kubernetes deploy с observability Deployment, probes, resources, metrics Kubernetes, Helm, Prometheus Сервис не просто запущен, а наблюдаем Развернул сервис в Kubernetes с SLO-сигналами

Что спрашивают на собеседовании SRE-инженера

На собеседовании SRE проверяют не только инструменты. Важнее ход мысли: как кандидат понимает impact, приоритет восстановления, SLO, безопасный rollback и postmortem.

Тема Пример вопроса Что проверяет интервьюер Как отвечать Что добавить в портфолио
Linux Сервис стал потреблять больше CPU и памяти. Как разбираться? Базовую диагностику и понимание ресурсов От impact и последних изменений к метрикам и гипотезам Дашборд ресурсов и runbook
Сети, DNS, HTTP Пользователи жалуются на недоступность API. Где искать причину? Понимание пути запроса Проверить путь client -> DNS/LB -> app -> dependency Схему запроса и проверки
Kubernetes Pod часто рестартует после релиза. Что смотреть? Понимание probes, events, limits, rollout Сначала impact и events, затем конфигурация и версия Учебный инцидент с рестартами
Docker Почему контейнер локально работает, а в окружении нет? Понимание среды запуска Сравнить env/network/volumes/image/resources Repro case в README
CI/CD Как безопасно выкатывать изменение? Release risk thinking Canary plus SLO-сигналы; критерии остановки; rollback Pipeline с проверками
Terraform/Ansible Как снижать риск инфраструктурных изменений? IaC и review-подход Plan -> small changes -> state -> rollback -> owners IaC стенд
Prometheus/Grafana Какие метрики нужны для сервиса? Выбор SLI и golden signals Начать с пользовательского сценария и SLO Дашборд SLI/SLO
SLI/SLO/SLA Чем отличаются SLI, SLO и SLA? Понимание reliability contract SLI — показатель, SLO — цель, SLA — соглашение с последствиями Документ SLO
Error Budget Что делать, если бюджет ошибок сгорел? Баланс релизов и надёжности Описать policy, risk review и reliability fixes Пример burn rate
Incident Response Как вести инцидент с высоким impact? Роли, приоритет, коммуникация Восстановление; timeline; эскалации; факты Incident timeline
Postmortem Что должно быть в хорошем разборе? Обучение после сбоя Impact; причины; защиты; action items Blameless postmortem
On-call Как бороться с alert fatigue? Зрелость дежурств Проверить impact, action, owner и эскалацию Кейс снижения шума
Capacity planning Как подготовиться к пику нагрузки? Прогноз и bottleneck thinking История нагрузки; saturation; limits; тестовый стенд Capacity model
PostgreSQL/Redis/Kafka Очередь растёт или база тормозит. Что важно? Понимание зависимостей Lag/latency/locks/saturation/retries/impact Дашборд зависимостей
DevOps vs SRE Где граница между DevOps и SRE? Ролевую зрелость DevOps про delivery, SRE про SLO, инциденты и повторяемые причины Сравнение в README

Курсы для SRE-инженера: как выбирать

Курс для SRE стоит оценивать по тому, закрывает ли он reliability-мышление. Kubernetes важен, но курс только про Kubernetes — это инфраструктурная часть SRE, а не полный SRE-трек.

Тип курса Для кого SRE-релевантность Что должно быть в практике Комментарий SkillStat
SRE / reliability engineering DevOps, backend, platform, cloud с опытом Высокая SLI/SLO/Error Budget, observability, incident response, postmortem, on-call, automation Лучший формат, если программа не обещает простую гарантию входа и даёт production-like кейсы
Monitoring / observability Тем, кто уже понимает сервисы и инфраструктуру Высокая как отдельный слой Prometheus, Grafana, logs, traces, alert quality, SLO monitoring Хорошо усиливает роль, если не сводится к дашбордам без действий
Kubernetes Junior/Middle infrastructure, DevOps, backend с production interest Средняя или высокая как инфраструктурная часть Deployments, probes, resources, rollout, observability, incidents Полезно, но не заменяет SLO, error budget, postmortem и on-call
CI/CD и IaC DevOps/SRE-adjacent кандидаты Средняя GitLab CI/Jenkins, Terraform, Ansible, rollback, review, safe changes Нужно связать delivery с SLO-сигналами и risk management
Cloud / Linux / networking Новички и переходящие из поддержки Базовая Linux, DNS, HTTP, cloud monitoring, IAM, VPC, troubleshooting Хороший фундамент, но без incident practice это ещё не SRE

Сертификаты и легальная практика для SRE

Сертификаты помогают структурировать знания, но не заменяют портфолио и опыт работы с инцидентами. Практику стоит проводить в учебных стендах, pet-проектах или внутренних кейсах без раскрытия конфиденциальных данных.

Сертификат / практика Кому подходит Что подтверждает Ограничение
Kubernetes and Cloud Native Associate Новичкам в cloud-native Базовое понимание Kubernetes и cloud-native экосистемы Не доказывает готовность к on-call
Certified Kubernetes Administrator Middle infrastructure/SRE Практическое администрирование Kubernetes Нужен контекст SLO и incident response
Certified Kubernetes Application Developer Backend/DevOps с Kubernetes Работу приложений в Kubernetes Не заменяет observability и reliability practice
Prometheus Certified Associate Тем, кто усиливает monitoring Метрики, Prometheus и базовую наблюдаемость Дашборд без SLO и runbook слаб для SRE
HashiCorp Terraform Associate DevOps, cloud, platform IaC-базу и Terraform workflow Сертификат не показывает безопасный change management
AWS / Google Cloud / Yandex Cloud / Azure Cloud/SRE кандидаты Облачные сервисы, IAM, monitoring, network basics Провайдерский экзамен не заменяет portfolio-кейс
Linux Foundation courses Новички и infrastructure transition Linux, Kubernetes, cloud-native базу Нужна самостоятельная практика на сервисе
SRE Foundation Тем, кто хочет терминологию и процесс SRE-словарь и практики Сам по себе не доказывает инженерную глубину
Учебные стенды и pet-проекты Всем кандидатам без production-доступа SLO, observability, incident drill, runbook, postmortem Не выдавать учебный стенд за production-опыт
Внутренние runbook/postmortem кейсы Работающим инженерам Реальное улучшение процесса Нужно обезличить данные и не раскрывать секреты компании

Плюсы и минусы профессии

Плюсы

  • Высокая ценность для критичных сервисов: SRE влияет на доступность, доверие пользователей и цену простоя.
  • Сильная зарплатная перспектива для специалистов, которые владеют SLO, incident leadership и зрелой observability.
  • Влияние на архитектуру и инженерную культуру, а не только на дежурства и поддержку инфраструктуры.
  • Рост в Lead SRE, Platform Engineer, Staff Engineer, Infrastructure Architect или Engineering Manager.
  • Измеримый результат: меньше повторных инцидентов, меньше шума алертов, быстрее восстановление, понятнее error budget.
  • Работа на стыке разработки, инфраструктуры и продукта, где техническое решение напрямую связано с бизнес-риском.
  • Часть ручной рутины можно автоматизировать и заменить инженерными изменениями.

Минусы

  • Высокий порог входа: нужны Linux, сети, observability, incident response, Kubernetes, CI/CD и scripting.
  • Мало junior-вакансий: рынок SRE заметно смещён к Middle/Senior и Lead.
  • On-call и ночные инциденты могут быть тяжёлыми, если алерты шумные, а эскалации не настроены.
  • Стресс при авариях: нужно сохранять ясность, фиксировать факты и не ухудшать ситуацию хаотичными действиями.
  • Нужен широкий стек, но при этом важно не потерять фокус на SLO и пользовательском impact.
  • Без поддержки разработки SRE превращается в пожарную команду без права менять причины сбоев.
  • Нужно постоянно балансировать скорость релизов и надёжность, а это не всегда популярная позиция.
  • Много коммуникации и документации: postmortem, runbook-и, эскалации и договорённости с продуктом обязательны.

Кому подойдет

Профессия подходит инженерам, которым интересно разбирать сбои до системной причины и строить правила, уменьшающие повторение проблем. Нужны спокойствие под давлением, любовь к измерениям и неприятие ручного героизма как нормы.

Подойдет

  • Умение сохранять ясность во время инцидента и отделять факты от догадок.
  • Навык писать постмортемы без обвинений и с конкретными действиями.
  • Готовность спорить о риске релиза на языке данных, а не эмоций.
  • Дисциплина в документации, инструкциях восстановления, дежурствах и эскалациях.
  • Способность договариваться с разработкой о технических изменениях после сбоя.
  • Терпение к постепенному снижению ручной рутины вместо разовых героических исправлений.

Не подойдет

  • Если хочется только настраивать инструменты и не участвовать в инцидентах, коммуникации и изменении процессов, SRE будет слишком широкой ролью.
  • Здесь отвечают за надёжность как систему, а не за красивый мониторинг.

FAQ по профессии SRE-инженер

Кто такой SRE-инженер простыми словами?

SRE-инженер отвечает за надёжность production-сервиса. Он смотрит на пользовательский сценарий, выбирает SLI и SLO, строит наблюдаемость, участвует в инцидентах и добивается исправлений после postmortem.

Чем занимается SRE-инженер?

SRE-инженер измеряет надёжность сервиса, строит observability, улучшает alerting, участвует в incident response и снижает toil. После сбоя он помогает найти системную причину и довести исправление до результата.

Какие навыки нужны Junior SRE?

Junior SRE нужны Linux, базовые сети, DNS, HTTP, Git, Docker, CI/CD, чтение логов, мониторинг и runbook-и. Важно уметь фиксировать факты, эскалировать вовремя и не менять систему без понимания риска.

Можно ли работать SRE удалённо?

Удалённая работа для SRE возможна, но зависит от on-call, доступа к системам, регламентов безопасности и зрелости процессов. В срезе SkillStat по Москве и МО формат распределён так: удалённо 14%, гибрид 60%, офис 26%. Для кандидата важно смотреть не только формат, но и правила дежурств, эскалации, postmortem и компенсацию on-call.

Можно ли стать SRE-инженером с нуля?

Можно, но прямой junior-вход редок. Практичнее идти через Linux, сети, поддержку, DevOps, backend, NOC, cloud или platform engineering. Для старта нужен учебный сервис с SLO, алертами, runbook и postmortem.

Почему зарплата SRE считается в estimated-режиме?

Estimated-режим нужен, когда открытых зарплат мало для точной активной медианы. SkillStat показывает оценку по расширенному окну, чтобы не создавать ложную точность для нишевой и senior-heavy роли.

Сколько зарабатывает SRE-инженер?

На 23.06.26 SkillStat показывает для Москвы и МО оценку 245 000 ₽, выборка n=11. Это ориентир по вакансиям, а не гарантия для каждого грейда или конкретного работодателя.

Есть ли у SRE ночные дежурства?

Да, on-call часто входит в SRE-роль. Зрелая практика не держится на героизме: она снижает шум алертов, задаёт эскалации, улучшает runbook-и и чинит повторяемые причины вызовов.

Какие инструменты должен знать SRE-инженер?

Обычно встречаются Linux, Kubernetes, Docker, CI/CD, Prometheus, Grafana, Alertmanager, ELK/Loki, OpenTelemetry, Terraform, Ansible и облака. Но инструменты нужно объяснять через SLO, incident response и rollback.

Какие курсы подходят для SRE?

Подходят курсы, где есть SLO, error budget, observability, incident response, postmortem, on-call, automation, CI/CD, Terraform, Prometheus, Grafana и Kubernetes как инфраструктурная часть.

Какие языки нужны SRE?

SRE чаще всего нужны Python, Bash, Go и SQL на прикладном уровне. Они помогают автоматизировать toil, писать внутренние утилиты, анализировать логи, работать с API, проверять гипотезы и поддерживать runbook-и. Важно не количество языков, а способность превращать повторяемую ручную операцию в безопасное инженерное решение.

Нужен ли Kubernetes для SRE?

Kubernetes часто нужен, потому что многие production-сервисы работают в контейнерах. Но сам Kubernetes не делает человека SRE. Нужны SLO, incident response, observability, postmortem и понимание риска.

Нужно ли SRE программировать?

Да, но не обязательно как продуктовому backend-разработчику. Код нужен для automation, внутренних утилит, проверок, анализа логов и снижения toil. Часто хватает Python, Bash, Go или SQL для рабочих задач.

Почему у SRE мало junior-вакансий?

SRE связан с production-риском, on-call и решениями, которые влияют на пользователей. Работодатель чаще ищет человека с базой в Linux, сетях, мониторинге, релизах и типовых причинах отказов.

Сколько учиться на SRE-инженера?

На первый осознанный вход обычно нужно 6–12 месяцев, если уже есть базовый IT-фундамент. Новичку нужно пройти Linux, сети, Docker, CI/CD, мониторинг, Kubernetes, Prometheus/Grafana, SLI/SLO, incident response и учебное портфолио. Если опыта в эксплуатации нет, путь чаще начинается через поддержку, NOC, DevOps, cloud или backend.

Чем SRE отличается от системного администратора?

Системный администратор поддерживает серверы, сети, доступы и обновления. SRE связывает инфраструктуру с пользовательской надёжностью, релизами, SLO, runbook-ами и инженерными изменениями после сбоев.

Чем SRE отличается от Cloud Engineer?

Cloud Engineer чаще отвечает за облачную инфраструктуру: сети, IAM, managed-сервисы, cost control и базовые платформенные настройки. SRE использует облако как один из инструментов, но его главный фокус — измеримая надёжность сервиса, SLO, error budget, incident response, observability и снижение повторяемых причин сбоев.

Чем SRE отличается от DevOps?

DevOps чаще отвечает за delivery, инфраструктуру и автоматизацию поставки. SRE держит в центре SLO, error budget, on-call, инциденты и повторяемые причины сбоев. В вакансиях роли часто пересекаются.

Чем SRE отличается от Platform Engineer?

Platform Engineer строит внутреннюю платформу для разработчиков. SRE отвечает за надёжность сервисов и работу команды с риском. Роль становится SRE, когда есть SLO, on-call, incident response и postmortem.

Чем SRE отличается от Production Engineer?

Production Engineer близок к SRE и в некоторых компаниях означает почти ту же зону ответственности. Обычно Production Engineering сильнее подчёркивает эксплуатацию и production ownership, а SRE — формальные практики надёжности: SLI, SLO, error budget, postmortem, toil reduction и инженерные изменения после инцидентов.

Что означает SRE?

SRE означает Site Reliability Engineering. Это инженерный подход к эксплуатации: измеримые цели надёжности, error budget, качественные алерты, автоматизация ручной работы и разбор инцидентов без поиска виноватого.

Что показать в портфолио начинающему SRE?

Покажите учебный сервис с SLI/SLO, дашбордом, алертом, runbook-ом, безопасным инцидентом, rollback-сценарием и postmortem. Важно объяснить риск, действие и улучшение после сбоя.

Что такое blameless postmortem?

Blameless postmortem — это разбор инцидента без поиска удобного виноватого. Его цель — восстановить факты, найти системные причины и превратить выводы в action items.

Что такое error budget?

Error budget — это допустимый запас ненадёжности внутри SLO. Если бюджет не сгорает, команда может двигаться быстрее. Если он исчерпан, приоритетом становятся снижение риска и reliability fixes.

Что такое incident response?

Incident response — это организованное реагирование на сбой. Команда понимает impact, восстанавливает сервис, держит коммуникацию, эскалирует вовремя и не усугубляет ситуацию хаотичными действиями.

Что такое observability?

Observability — это способность понять состояние системы по сигналам: метрикам, логам, трассировкам, алертам и бизнес-показателям. Для SRE она нужна для решений, а не для коллекции графиков.

Что такое SLA?

SLA — это соглашение об уровне сервиса с последствиями при нарушении. SLA ближе к договорённости с клиентом или бизнесом, а SLO — к внутренней инженерной цели команды.

Что такое SLI?

SLI — это измеримый показатель уровня сервиса. Хороший SLI связан с опытом пользователя: успешность запроса, задержка, ошибка, очередь или другой сигнал, по которому видно реальное ухудшение.

Что такое SLO?

SLO — это целевой уровень сервиса, измеряемый через SLI. Он помогает решить, когда можно ускорять релизы, когда нужно чинить надёжность и какой риск команда готова принять.

Что такое toil в SRE?

Toil — это ручная, повторяемая и автоматизируемая работа без долгосрочной ценности. Задача SRE — снижать toil кодом, runbook automation, изменением процесса или исправлением причины.