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. Месяц 1. Выберите один сервис, который вы и так трогаете. Опишите, что для него «нормально живо»: время ответа, ошибка, окно обслуживания. Даже если SLO формально никто не подписывал — вы сформулируете учебный.
  2. Месяц 2. Два реальных или учебных инцидента в формате postmortem. Один автоматический шаг вместо ручного. В резюме текущая работа языком надёжности, не «сопровождение серверов».
  3. Месяц 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 без практики. Письмо: генератор, правьте под инциденты из объявления.

Как читать вакансии SRE

Каталог: вакансии SRE. Зелёные признаки входа или аккуратного middle-minus: существующий контур мониторинга, наставник, описанный on-call, задачи на автоматизацию известного toil.

Красные: «построите платформу с нуля», безлимитный онколл без компенсации в тексте, стек из всего облака, «рассмотрим выпускника курсов». Вилку зарплаты собирайте фильтрами каталога по грейду и формату, не из книжки SRE и не из чата.

Удалёнка с дежурствами — это про часовые пояса и правила эскалации, не про «без звонков». Соседний материал по поясам, если формат распределённый: часовые пояса в удалённой команде.

Сомнительные объявления (доступ к продакшну до договора, оплата обучения) проверяйте как обычно: мошенничество.

Резюме и интервью

Заголовок: SRE / надёжность и инциденты — или DevOps Engineer, если так назван слот, но в задачах надёжность. Стек: то, чем вы реально чинили. Linux, сети на уровне «почему сервис не видит БД», IaC если есть. Не двадцать облачных продуктов.

Каркас: резюме DevOps по структуре, акцент сместить на инциденты и SLO. Навыки без каши: навыки DevOps — берите принцип короткого списка. Проверка: cv-review.

Интервью: разбор падения, как режете алертный шум, что такое SLO на пальцах, как не автоматизировать хаос. Готовьте один postmortem вслух. Подготовка: interview-prep, вопросы про роль: вопросы на DevOps-интервью — часть пересекается.

Учебный postmortem и runbook: шаблоны

Рекрутеру нужен не скрин Grafana, а текст, по которому видно, что вы умеете восстанавливать и учиться. Учебный postmortem на одну-две страницы:

  1. Кратко: сервис, симптом, длительность, пользовательский эффект даже если пользователи учебные.
  2. Timeline: когда заметили, что проверили, что сделали, когда стало лучше.
  3. Причина: не «человеческий фактор», а «алерт не смотрел на зависимость БД» или «рестарт без drain».
  4. Что изменили: новый алерт, скрипт, пункт в runbook. Если ничего не изменили — это дневник, не разбор.

Runbook на простой:

Симптом: healthcheck 3 минуты красный. Проверить: процесс жив, диск, логи ошибки БД. Если БД недоступна — не рестартовать приложение пачкой, эскалировать по списку. Если процесс умер — команда запуска из README, затем проверить метрику ошибок. После восстановления — запись в лог инцидента: время, действие, кто дежурил.

Это учебный уровень. Его достаточно, чтобы отличить вас от человека с CKA и без истории падения. Не копируйте чужой postmortem крупной аварии «для солидности»: на созвоне попросят детали, которых у вас нет.

Неделя поиска: 8–12 вакансий из каталога SRE и соседнего DevOps, где в тексте инциденты, алерты, on-call с рамкой. Письмо — симптом, что автоматизировали, ссылка на postmortem. Вилку не ставьте из книжки Google: соберите по фильтрам каталога. Если дежурства не обсуждаются до оффера, спросите сами до согласия: окна, компенсация, кто второй в эскалации.

Частые вопросы

Можно ли стать SRE без разработки?

Сложнее. Нужен минимум: читать чужой сервис, писать скрипты, понимать, что меняете в проде. Чистый «только клики в панели» на рынке 2026 слабый вход. Доберите автоматизацию, не обязательно становиться backend-разработчиком годами. Учебный runbook плюс один скрипт восстановления закрывают этот пробел быстрее курса Go «для SRE».

Обязателен ли Kubernetes?

Нет на любом входе. Обязателен там, где он в задачах. Учебный k8s без сервиса и инцидента — декорация. Сертификат — не должность. Если в целевых объявлениях Compose и виртуалки, не тратьте квартал на экзамен администратора кластера.

Нужна ли книга Google SRE наизусть?

Нужны идеи: SLO, error budget, toil. Цитаты главы не нанимают. На созвоне просят ваш случай, не пересказ. Достаточно уметь на пальцах объяснить, зачем не чинить всё руками каждую ночь и как алерт связан с пользовательским эффектом.

On-call на junior — норма?

С рамкой, наставником и документооборотом — бывает. Безлимит и «сам виноват, если не проснулся» в вакансии без опыта — плохой слот. Спрашивайте правила дежурства до оффера.

Чем отличаться от DevOps в резюме?

Историями восстановления и явными SLO/алертами, не словом Reliability в summary. Если историй нет — сначала контур, потом переименование.

С какого языка скриптов?

Того, на котором чините. Bash + Python типичны. Не учите Go «для SRE» вместо первого runbook.

Что сделать сейчас

На этой неделе опишите для одного сервиса, что значит «жив», и повесьте один алерт на простой. На следующей устройте учебное падение и напишите postmortem на страницу. Это важнее нового курса по service mesh.

Не записывайтесь на CKA, пока нет timeline восстановления. Экзамен не дежурство. Если уже админите сервис на работе — переведите текущие падения на язык SLO в резюме в тот же день, не ждите идеального кластера.

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