SRE — не синоним DevOps и не «админ, который выучил Prometheus». Site Reliability Engineering нанимает за надёжность сервиса: SLO, бюджет ошибки, разбор инцидентов, автоматизация того, что иначе будут кликать руками в три ночи. Если в резюме только Docker и Jenkins без истории падения и восстановления, вы ближе к входу в DevOps, чем к SRE.
В 2026-м в СНГ и на русскоязычной удалёнке слово SRE часто ставят на вакансии платформы. Читайте задачи. Ниже — какие инциденты и автоматизация уже считаются входом, как не прыгать в «владелец Kubernetes-кластера без опыта» и чем собрать доказательство за квартал.
Коротко:
- SRE продаёт устойчивость и восстановление, DevOps чаще — поставку и контур сборки. Соседние навыки, разные акценты в файле.
- Вход: один сервис с метриками, алертами, runbook и разбором учебного инцидента.
- Сертификат Kubernetes не равен должности SRE.
- Junior SRE в объявлении с on-call 24/7 и «спроектируете платформу» — почти всегда middle.
- Ищите SLO, инциденты, автоматизацию toil, а не только слово SRE в заголовке.
Кому этот вход подходит — и кому нет
Подходит, если вам интересно, почему сервис лёг и как сделать, чтобы так не повторилось. Сильный смежный старт: админка, сопровождение, junior DevOps, backend, который уже дежурил по своим сервисам. Слабый старт: только курс Kubernetes и желание «дежурить как в Google» без одного учебного падения.
Не подходит, если вы хотите только собирать пайплайны без онколла — честнее DevOps-вход. Не подходит, если цель — безопасность периметра без надёжности сервиса — это другая дверь. Не подходит вакансия безлимитного онколла «сам виноват» для человека без наставника: это не школа SRE, это выгорание в первый месяц.
Книга Google SRE полезна как словарь. Она не заменяет ваш timeline инцидента. На созвоне просят случай, не главу про error budget. Сформулируйте учебный SLO даже если никто его не подписывал: так вы тренируете язык роли.
SRE, DevOps, эксплуатация — где границы
Эксплуатация классическая: сервис жив, бэкапы, доступы, «починить вечером». DevOps-вход чаще про CI/CD, окружения, инфраструктуру как код. Разбор: как стать DevOps-инженером. SRE добавляет явную речь про уровень сервиса: что считаем достаточно живым, сколько падений вписываемся, что автоматизируем, потому что это повторяющийся ручной ад.
На маленьких командах один человек носит все три ярлыка. На рынке вакансий ярлык врёт. Калибруйтесь по тексту: есть ли postmortem, SLO, error budget, on-call с правилами, или только «поддерживать k8s».
Если вам ближе пайплайны сборки без онколла — не насилуйте заголовок SRE. Если ближе безопасность периметра — соседняя дверь Security Engineer, не «SRE+Sec» в одной строке без доказательств.
Что уже считается входом, а что ещё нет
Уже вход (учебный или с работы админом/разработчиком):
- Сервис, который вы сами роняли и поднимали по инструкции, не «интуитивно».
- Метрика золотых сигналов хотя бы на уровне: жив ли, отвечает ли, ошибается ли, медленно ли.
- Алерт, который срабатывает на простой, а не на всё подряд.
- Короткий postmortem: что случилось, timeline, что изменили в системе, чтобы не повторилось.
- Скрипт вместо трёх ручных шагов восстановления — даже маленький.
Ещё не вход: «настроил Nginx по гайду», «есть Certified Kubernetes Administrator», «хочу дежурить». Сертификат может помочь пройти HR-фильтр в корпорации. Он не заменяет разбор инцидента. Не делайте экзамен работой.
Какой контур собрать за квартал
Возьмите один учебный сервис (свой API или простой стек) и обвяжите его как будто это прод с низким, но честным SLA.
Недели 1–4. Деплой воспроизводимый: docker compose или один манифест. Логи структурировано. Healthcheck. Документ: как поднять с нуля за 15 минут.
Недели 5–8. Метрики и два-три алерта. Искусственно сломайте зависимость (БД выключили, диск заполнили в учебной среде). Запишите timeline. Напишите runbook на одну страницу.
Недели 9–12. Автоматизируйте один toil: рестарт по условию, чистка, проверка сертификата, бэкап с проверкой, что восстанавливается. Postmortem в репозитории. Честно: нет настоящего трафика, нет распределённой трассировки, нет хаоса на кластере из пятидесяти нод.
Это слабее промышленного SRE. Это сильнее курса «основы Grafana» без падения.
Не называйте учебный контур «платформой компании». На собеседовании спросят про трафик, SLA и кто дежурил в выходные. Честный ответ «учебный сервис, настоящего трафика нет, вот как я ронял БД и что изменил в алерте» сильнее легенды. Если прод под NDA, вынесите в публичный репозиторий только схему восстановления и вымышленные имена сервисов — без секретов и без внутренних URL.
Пример 1. Переход с эксплуатации / junior DevOps
Исход: админка, поддержка серверов или CI. Цель — роль с надёжностью, не «ещё больше пайплайнов».
- Месяц 1. Выберите один сервис, который вы и так трогаете. Опишите, что для него «нормально живо»: время ответа, ошибка, окно обслуживания. Даже если SLO формально никто не подписывал — вы сформулируете учебный.
- Месяц 2. Два реальных или учебных инцидента в формате postmortem. Один автоматический шаг вместо ручного. В резюме текущая работа языком надёжности, не «сопровождение серверов».
- Месяц 3. Заголовок SRE / надёжность, инциденты, автоматизация toil — или DevOps с акцентом на SLO, если вакансии так названы. Отклики только туда, где в задачах инциденты и метрики, не greenfield-платформа.
Не увольняйтесь в день, когда прочитали про Google SRE book. Сначала язык задач в файле и один публичный учебный контур, если прод под NDA.
Пример 2. Сопроводительное на junior / middle-minus SRE
Вакансия: SRE, сопровождение сервисов, алерты, дежурства с ограничениями, автоматизация, русский язык. Kubernetes в плюсах.
Откликаюсь на SRE с алертами и разбором инцидентов.
По вакансии нужно держать сервисы в понятных SLO, разбирать падения и убирать ручные шаги. Обвязал учебный API: healthcheck, метрики, алерт на простой, runbook, postmortem учебного падения БД, скрипт проверки бэкапа. Репозиторий: [ссылка]. Kubernetes в проде не администрировал — в вакансии он в плюсах; готов разобрать ваши алерты на созвоне.
Дежурства в заявленном окне готовы обсуждать по правилам команды, не «24/7 без рамки». Тестовое на runbook или разбор логов — на этой неделе.
Честный минус по k8s лучше, чем строка CKA без практики. Письмо: генератор, правьте под инциденты из объявления.