SRE (Site Reliability Engineer): профессия, зарплата и где учиться

SRE (Site Reliability Engineer) — это инженер, который отвечает за то, чтобы продукт работал надёжно при любой нагрузке. Подход родился в Google, где DevOps-практики формализовали через SLI, SLO и error budgets: вместо «давайте не будем ронять прод» появились численные цели доступности и бюджет ошибок. От обычного DevOps-инженера SRE отличается фокусом на математике надёжности и распределённых системах. Зарплатная вилка в Москве в 2026 году — от 280 до 600 тысяч рублей в зависимости от грейда. Чем занимается SRE SRE живёт между разработкой и эксплуатацией. Половина времени уходит на инженерию: пишет автоматизацию инцидентов, доводит мониторинг до состояния, когда алерты приходят строго по делу, проектирует деградацию сервиса при отказе зависимостей. Вторая половина — операционная работа: дежурства on-call, разбор инцидентов, выкатка изменений в инфраструктуре. Типичный день начинается с проверки дашбордов и очереди алертов за ночь. Если ночью что-то падало, SRE открывает таймлайн в системе инцидентов, восстанавливает картину по логам и метрикам, фиксирует action items. Дальше — митинг с командой разработки сервиса, чьи SLO просели за неделю: обсуждаете, на что тратится error budget, какие релизы откладываете до стабилизации. Между встречами — код-ревью pull request'ов в репозиторий с runbook'ами и terraform-модулями, написание скриптов для автоматического failover, работа над capacity planning на следующий квартал. Раз в две-три недели SRE проводит game day или chaos-эксперимент: намеренно роняет одну из зависимостей в стейджинге и проверяет, как ведёт себя система. Цель не в том, чтобы поймать команду на ошибке, а в том, чтобы найти точки, где надёжность держится на удаче, а не на дизайне. Результаты эксперимента превращаются в задачи для команды разработки и в обновления для runbook'ов. Большой пласт работы — формализация SLO. Для каждого важного сервиса SRE вместе с продуктом формулирует, что значит «работает»: задержка ответа на 99-м перцентиле, доля успешных запросов, доступность зависимостей. Из SLO выводится error budget — допустимый объём «плохих» секунд в месяц. Если бюджет израсходован, релизы фичей замораживаются и команда переключается на стабилизацию. Этот механизм превращает дискуссии о приоритетах в численные. Отдельная часть работы — blameless post-mortem после инцидента. SRE собирает таймлайн, выявляет root cause через метод «5 почему» или причинно-следственный анализ, формулирует контрмеры на уровне дизайна, а не на уровне «будем внимательнее». Хороший пост-мортем читается всей инженерной организацией и становится частью общей культуры. Hard skills и инструменты SRE — это инженер, которому одинаково комфортно с кодом, инфраструктурой и распределёнными системами. Базовый стек 2026 года выглядит так. Языки — Go и Python для инструментов и автоматизации, Bash для быстрых скриптов. Знание языка основного продукта (Java, Kotlin, Node.js) обязательно для участия в архитектурных дискуссиях и для чтения кода сервисов, чьи SLO вы поддерживаете. Observability — Prometheus, VictoriaMetrics, Grafana, OpenTelemetry, Loki или ClickHouse для логов, Tempo или Jaeger для трейсов. Умение писать PromQL без подсказок и настраивать SLO-based alerting через multi-window burn rate. Kubernetes и cloud-native — глубоко: operator pattern, custom resources, networking (CNI, service mesh типа Istio или Cilium), HPA/VPA, PodDisruptionBudget. Понимание, как ведёт себя кластер при потере зоны доступности и как корректно эвакуировать нагрузку. Distributed systems — consensus (Raft, Paxos), CAP-теорема на практике, sharding, репликация, очереди (Kafka, NATS), кэши и их инвалидация. Без этого SRE не отличит граф зависимостей с одним SPOF от устойчивого. Infrastructure as Code — Terraform или OpenTofu, Pulumi, Helm, Kustomize. Дисциплина GitOps: ArgoCD или Flux как источник правды для кластеров. Chaos engineering — Chaos Mesh, Litmus, Gremlin. Умение спроектировать эксперимент с явной гипотезой и blast radius, восстановить систему и описать выводы. Базы данных и storage — индексы и планы запросов в PostgreSQL, понимание реплик и failover, объектное хранилище и бэкапы. SRE часто оказывается тем, кто разруливает деградацию из-за тяжёлого SQL. CI/CD и release engineering — canary и blue-green релизы, feature flags, progressive delivery через Argo Rollouts или Flagger, автоматический rollback по сигналам мониторинга. Карьерный путь: junior → middle → senior Junior SRE в Москве в 2026 году получает 180–260 тысяч рублей. На этом грейде ожидается уверенный Linux, Kubernetes на уровне пользователя, базовая автоматизация на Python или Go и понимание HTTP/TCP. Junior много дежурит в паре с более опытным коллегой, пишет runbook'и по уже разобранным инцидентам, чинит мелкие баги в автоматизации. Главная задача первого года — научиться вести инцидент: коммуникация в чатах, эскалация, корректный handover на следующую смену. Параллельно нарабатывается чтение чужого кода: terraform-модули, helm-чарты, скрипты предыдущих SRE. Middle SRE зарабатывает 280–420 тысяч. К этому моменту вы уверенно проектируете SLO для сервиса средней сложности, ведёте крупные инциденты как incident commander, пишете нетривиальные операторы Kubernetes или контроллеры. Middle отвечает за качество on-call ротации в команде: дежурный график, чек-листы, тренировки. На этом уровне начинается осознанный выбор: углублять системный профиль (perf, kernel, networking) или идти в сторону платформы и developer experience. Middle проводит ревью архитектурных RFC от команд разработки и принимает решения, проходит ли сервис в продакшн с точки зрения надёжности. Senior SRE в крупных компаниях получает 450–600 тысяч и выше, в финтехе и больших экосистемах потолок размывается за счёт RSU и годовых бонусов. Senior отвечает не за один сервис, а за надёжность направления: проектирует cross-team стандарты, ведёт capacity planning на год вперёд, влияет на архитектурные решения других команд. От него ждут публичных пост-мортемов, в которых разобраны причины уровня дизайна, а не «опечатался в конфиге». Senior часто оказывается тем, кто разрабатывает культуру инцидентов в компании: формат таймлайна, шаблон пост-мортема, ритуал blameless review с участием разработки и менеджеров. Дальше путь раздваивается. Staff и Principal SRE — это техническая ветка с горизонтом ответственности на всю платформу компании. Они проектируют SLO-фреймворки для десятков сервисов, ведут стратегические инициативы по надёжности и являются техническими консультантами для CTO. SRE Manager — управленческая ветка, где половину времени занимают найм, грейды, бюджеты и переговоры с продуктом по приоритетам надёжности. Сколько зарабатывает SRE в 2026 году Москва задаёт верхнюю планку рынка. Junior SRE стартует с 180–260 тысяч рублей, middle закрепляется в коридоре 280–420 тысяч, senior получает 450–600 тысяч, в крупных финтехах и e-commerce встречаются предложения 700+ тысяч с учётом долгосрочных бонусов. Опционы и RSU в российских компаниях встречаются реже, чем в международных, но в публичных эмитентах и больших экосистемах они есть. Санкт-Петербург отстаёт от Москвы примерно на 10–15%: junior 160–230 тысяч, middle 250–370 тысяч, senior 400–550 тысяч. Региональные офисы Казани, Новосибирска, Екатеринбурга, Иннополиса предлагают 130–200 тысяч на старте и 350–500 тысяч на senior-уровне, при этом часть позиций гибридные или удалённые. В небольших городах рынок SRE-вакансий узкий, основная масса предложений идёт от распределённых команд с центрами в Москве. Удалёнка с привязкой к московским ставкам — рабочая модель: крупные продуктовые компании платят по столичной сетке независимо от прописки, если кандидат сильный. Удалённая работа на иностранных работодателей из дружественных юрисдикций добавляет ещё 30–60% к рублёвому эквиваленту, но требует валютного оформления и налогового резидентства. Дополнительные надбавки получают SRE с глубокой экспертизой в безопасности (PCI DSS, ФЗ-152), в финтех-нагрузках (платёжные шлюзы, биржевые системы) и в эксплуатации крупных Kubernetes-кластеров на тысячи узлов. На зарплату в SRE сильнее всего влияет глубина в распределённых системах, опыт работы с реальными инцидентами на нагруженных системах (от тысяч RPS) и умение писать качественный код. Сертификации помогают в первые годы, дальше решают портфолио инцидентов и архитектурные решения. Кандидат, который умеет на интервью разобрать архитектуру конкретного сервиса до SPOF, чёткой стратегии деградации и измеримых SLO, ценится сильно выше того, кто хорошо знает CLI всех инструментов. Где учиться Базовое образование для SRE — высшее техническое: прикладная математика и информатика, программная инженерия, информатика и вычислительная техника, информационные системы и технологии. Те же ФГОС-направления, что у DevOps-инженера: 09.03.01, 09.03.02, 09.03.03, 09.03.04, 02.03.02. Степени магистра обычно не требуют, но магистратура по распределённым системам или системному программированию даёт фору на старте. Часть SRE приходит со специальностей информационной безопасности (10.03.01) — там сильнее системная база и дисциплина работы с инцидентами. Профессионалы из смежных областей — backend-разработчики, системные администраторы Linux, инженеры эксплуатации — переходят в SRE через прокачку трёх блоков: распределённые системы, Kubernetes на продакшн-уровне, observability. Полезные ресурсы — открытые книги Google «Site Reliability Engineering» и «The Site Reliability Workbook», курс MIT 6.824 по распределённым системам, материалы CNCF, документация Prometheus и OpenTelemetry. Из практического — собственная домашняя лаборатория на k3s или kind, в которой вы воспроизводите типовые сценарии: split brain в БД, OOM-каскад, медленная сеть между зонами. Курсы переквалификации работают как стартовая точка, но не заменяют практику. Хороший pet-проект для портфолио — развернуть нагруженное приложение с явными SLO, настроить полный observability-стек, провести два-три chaos-эксперимента и оформить пост-мортем по собственному инциденту. Этот артефакт на собеседовании работает сильнее любого сертификата. Сертификации, которые реально читают рекрутеры: CKA и CKAD от CNCF, AWS Certified Solutions Architect или эквивалент Yandex Cloud, Google Professional Cloud DevOps Engineer. На собеседованиях в крупные компании больше веса имеет system design интервью и разбор кейса по реальному инциденту, чем строчка в резюме. Похожие специализации Platform Engineer — собирает внутреннюю платформу для разработчиков (golden path, шаблоны, self-service инфраструктура), фокус на developer experience. Production Engineer — термин из Meta и нескольких крупных российских компаний, по сути близок к SRE, но чуть глубже в код продукта. DevOps-инженер — родительская роль, шире по спектру, но без жёсткого фокуса на SLO и надёжность. Cloud-инженер — отвечает за cloud-инфраструктуру и стоимость, пересекается с SRE на стыке capacity planning и архитектуры. Chaos Engineer — узкая роль внутри SRE-направления в крупных компаниях, занимается только хаос-экспериментами и устойчивостью.