Вопросы на собеседовании SRE-инженера

Пример сильного ответа

SLI — это измеримая метрика качества сервиса: доля успешных запросов, задержка, насыщенность. SLO — внутренняя цель по этой метрике, например 99,9% успешных запросов за месяц. SLA — внешнее обязательство перед клиентом с последствиями и штрафами, и он всегда мягче внутреннего SLO. Разница в адресате и последствиях: SLI измеряет, SLO направляет команду, SLA защищает отношения с заказчиком. В моей практике на сервисе с четырьмя SLI держали SLO по доступности 99,9%, а SLA с заказчиком — 99,5%, и это давало запас на плановые работы и на разбор инцидентов без давления извне.

• Чётко разделяет три понятия по адресату и последствиям
• Есть личный пример с конкретными цифрами целей
• Показано понимание запаса между SLA и SLO

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Error budget — это допустимая доля ошибок в рамках SLO: если цель по доступности близка к ста процентам, бюджет на месяц измеряется десятками минут. Это переводит разговор о надёжности из эмоций в цифры. Пока бюджет есть, команда спокойно выпускает релизы и экспериментирует; бюджет исчерпан — приоритет переключается на надёжность и технический долг. Мне приходилось вводить такое правило в команде из двенадцати человек: релизы шли ежедневно, бюджет держался, но после серии инцидентов остаток ушёл в ноль, и мы на две недели заморозили новые фичи и занялись причинами отказов.

• Определение дано через цифры, а не абстракции
• Показано, как бюджет меняет решения команды
• Есть реальный кейс с заморозкой релизов

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Если целей раньше не было, я не начинаю с красивых цифр, а иду от пользовательских сценариев: какие действия клиента критичны и как мы поймём, что они ломаются. Дальше собираю две-три метрики-кандидата — доступность, задержку, долю ошибок — и пару недель просто измеряю их без обязательств, чтобы увидеть реальный уровень и сезонность. Потом выбираю минимальный набор, который отражает опыт пользователя, а не внутреннее устройство, и ставлю цель чуть выше текущего уровня. На одном сервисе такой подход дал один основной SLI вместо восьми бесполезных дашбордов и снизил число ложных алертов примерно на 40%.

• Виден системный подход, а не угадывание цифр
• Упомянут период наблюдения без обязательств
• Есть измеримый результат: меньше ложных алертов

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Toil — это ручная, повторяющаяся, автоматизируемая работа без долгосрочной ценности: перезапуски, выдача доступов, разбор однотипных тикетов. Он опасен тем, что растёт вместе с сервисом и съедает время на развитие. Мой подход такой: сначала измеряю, куда уходит время дежурства, потом ранжирую задачи по частоте и стоимости и автоматизирую самое дорогое, а не самое интересное. В команде из восьми человек на рутину уходило около трети дежурства; за полгода мы снизили это примерно до десяти процентов за счёт автоперезапусков, шаблонов и self-service доступов.

• Точное определение toil и его признаков
• Приоритизация по частоте и стоимости, а не по интересу
• Конкретный результат: доля рутины заметно снижена

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

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

• Чёткое различие: известные вопросы против новых
• Объяснение через реальный сценарий инцидента
• Названы инструменты: трассировки, логи, кардинальность

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Kubernetes для меня — декларативная система: я описываю желаемое состояние, а control plane приводит реальность к нему. В control plane входят API-сервер, etcd как хранилище состояния, планировщик и контроллер-менеджер; на нодах работают kubelet, CRI и CNI. Когда я выполняю kubectl apply, манифест уходит на API-сервер, проходят аутентификация, авторизация и admission-проверки, объект сохраняется в etcd. Затем контроллеры создают ReplicaSet и поды, планировщик выбирает ноду, kubelet через CRI запускает контейнеры, а сервис получает endpoints. На одном из проектов через такой поток проходило около 200 деплойментов в неделю, и большинство ошибок ловилось на этапе admission-политик, ещё до продакшена.

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

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Первым делом я смотрю kubectl describe pod и логи предыдущей попытки: контейнер уже перезапускался, поэтому логи текущего запуска часто пустые. Дальше разбираю exit code и события. OOMKilled указывает на лимиты памяти, ошибка запуска команды — на неверный entrypoint или конфиг, падение при старте — на недоступные зависимости, секреты, PVC. Часто причина в readiness-пробе или в миграциях базы. Полезно запустить под с переопределённой командой и зайти внутрь, проверить сеть и переменные окружения. Такая последовательность даёт результат: большинство инцидентов разбирается за 10–15 минут, а не за час.

• Порядок диагностики от простого к сложному
• Связаны симптомы и типовые причины
• Есть измеримый результат по времени

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Requests — это гарантия для планировщика, limits — потолок потребления. Requests я задаю по реальному p95-потреблению из метрик, а limits по памяти ставлю близко к requests, чтобы под не выбивался из своего класса и не ронял соседей по ноде. CPU limits стараюсь не занижать, потому что троттлинг бьёт по latency сильнее, чем кажется. HPA настраиваю по метрикам, которые действительно коррелируют с нагрузкой: RPS, длина очереди, а не только CPU. На последнем сервисе такой подход снизил расход ресурсов примерно на 30% при том же SLA.

• Чётко различает requests и limits по смыслу
• Объясняет выбор метрик для HPA
• Подкреплено цифрой экономии ресурсов

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Инфраструктуру описываю кодом: Terraform для облачных ресурсов, Helm и манифесты в Git для кластера, Ansible для конфигурации узлов. Для меня это про воспроизводимость и предсказуемость: любое окружение поднимается из репозитория, изменения проходят ревью и попадают дальше только через пайплайн. Заодно становится видно drift — расхождение реального состояния с описанным. На одном проекте развёртывание стенда с нуля сократилось с нескольких дней ручной работы до часа, а число инцидентов из-за ручных правок заметно упало. Код можно откатить, а память человека — нет.

• Названы конкретные инструменты и их роли
• Аргумент про воспроизводимость и откат
• Есть сравнение результата до и после

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Пайплайн строю так, чтобы быстрые проверки шли первыми: линтеры, unit-тесты, сборка образа, сканирование уязвимостей, затем выкладка в стейдж и smoke-тесты. В прод — через canary или blue-green с автоматическим откатом по метрикам ошибок и latency. Обязательны feature flags, миграции базы, совместимые с предыдущей версией, и понятная процедура rollback. На последнем проекте такой процесс давал до 20 релизов в неделю при доле неуспешных деплоев меньше 2%, а путь от коммита до прода занимал около 30 минут. Главное — сделать безопасный релиз дешевле, чем долгий согласованный.

• Показан принцип «быстрые проверки первыми»
• Упомянут безопасный релиз и откат
• Есть метрики частоты и качества релизов

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

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

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

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

В моей практике алертинг строится вокруг симптомов, а не причин. Ситуация: дежурного будили сотни уведомлений, большинство — шум. Задача — оставить только то, что влияет на пользователей. Действую так: сначала определяю SLO и error budget, затем алерты только на выгорание бюджета и на явную деградацию. Технические метрики — в дашборды, не в пейджер. Обязательно добавляю подавление дублей и группировку по сервису. Результат: количество ночных пейджеров сократилось примерно на 80%, при этом ни одного крупного инцидента не пропустили.

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

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

В моей практике основной стек observability — Prometheus для метрик, Grafana для визуализации, Loki для логов и Jaeger для трейсинга. Дашборды строю по Golden Signals: latency, traffic, errors, saturation, плюс бизнес-метрики. Для каждого сервиса — отдельный дашборд с SLO и алертами. Важно, чтобы графики отвечали на вопрос «что делать», а не просто рисовали красивые линии. Раньше время диагностики инцидента занимало около 30 минут, сейчас удаётся сократить до 10–15. Также использую OpenTelemetry для сквозной трассировки.

• Показывает конкретный стек и подход к дашбордам.
• Есть измеримый результат: сокращение времени диагностики.
• Ответ структурирован и ориентирован на пользу для бизнеса.

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Постмортем провожу без поиска виноватых: цель не наказать, а убрать условия для повтора. Собираю факты по хронологии — что заметили, когда, какие сигналы были, а каких не хватило. Разбираю не только техническую первопричину, но и процесс: почему изменение прошло незамеченным, почему алерт сработал поздно или его не было вовсе. Итог — список действий с владельцами и сроками, где технические исправления идут в бэклог, а не «когда-нибудь». На разбор крупного инцидента обычно уходит около часа встречи, и примерно треть действий — это улучшение наблюдаемости и процессов.

• Сразу снимает тему поиска виноватых
• Разбирает и технику, и процессы, а не только код
• Действия с владельцами и сроками, а не протокол ради протокола

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Capacity planning начинаю не с железа, а с нагрузки: смотрю, какие есть пользовательские сценарии, какая у них сезонность и пики, и перевожу это в метрики — запросы в секунду, задержки, потребление ресурсов на единицу трафика. Дальше строю прогноз с запасом и проверяю его нагрузочным тестированием, а не только расчётом. Заранее определяю, что делаем при росте: горизонтальное масштабирование, лимиты и квоты, автомасштабирование или резерв. В одном проекте такой подход позволил переживать сезонный рост трафика примерно втрое без деградации и без закупки лишних мощностей — запас держали около тридцати процентов.

• Capacity planning начинается с нагрузки, а не с железа
• Прогноз проверяется нагрузочным тестом, а не только расчётом
• Есть результат: рост втрое без деградации и лишних затрат

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.

Пример сильного ответа

Моя задача была — не назначать SLO «с потолка», а вывести их из ожиданий бизнеса. Сначала я собираю с владельцем продукта и поддержкой, что для пользователя значит «работает»: доступность, задержка, доля успешных заказов. Дальше смотрю фактические метрики за пару месяцев и ставлю цель чуть выше текущего уровня, чтобы она была достижимой. Например, для одного сервиса мы вышли на 99,9% доступности, а бюджет ошибок — около 43 минут в месяц. Эти минуты команда тратит на релизы; когда бюджет исчерпан, рискованные изменения замораживаются и приоритет уходит на надёжность. Раз в квартал пересматриваем — цифры должны отражать реальность.

• SLO выводится из потребностей пользователя, а не из красивой цифры
• Есть конкретный результат: 99,9% и бюджет около 43 минут
• Показан механизм последствий: бюджет кончился — релизы заморожены

Возьмите структуру и подставьте свой опыт — заученный чужой ответ интервьюер слышит сразу.