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

Как отвечать: Разведите три понятия: SLI — измеряемый показатель (доступность, латентность), SLO — внутренняя цель, SLA — внешнее обязательство с санкциями. Приведите пример из практики.

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

Как отвечать: Начните с пользовательского опыта: доступность, латентность, доля ошибок. Опишите, как валидируете метрику с владельцем продукта и избегаете метрик ради метрик.

Как отвечать: Дайте определение ручной повторяемой работы без долгосрочной ценности, приведите примеры автоматизации из опыта и цель Google — не более 50% времени на toil.

Как отвечать: Объясните: мониторинг отвечает на известные заранее вопросы, observability позволяет исследовать неизвестные проблемы через метрики, логи и трейсы. Упомяните три столпа.

Как отвечать: Пройдите цепочку: API-сервер, etcd, scheduler, kubelet и контейнерный рантайм. Покажите понимание control plane и того, где искать сбой на каждом шаге.

Как отвечать: Покажите методичность: kubectl describe и logs, проверка liveness/readiness-проб, ресурсов и лимитов, образа и конфигов — от симптома к первопричине.

Как отвечать: Расскажите про requests и limits для CPU/памяти, QoS-классы подов, настройку HPA по метрикам и типичные ошибки — OOMKilled из-за заниженных лимитов.

Как отвечать: Приведите опыт с Terraform или Ansible: декларативность, воспроизводимость окружений, code review изменений инфраструктуры и снижение configuration drift.

Как отвечать: Упомяните автотесты, канареечные и blue-green деплои, feature flags, автоматический откат по метрикам и связь с error budget.

Как отвечать: Расскажите про Vault или аналоги, ротацию секретов, принцип минимальных привилегий, RBAC в Kubernetes и аудит доступа.

Как отвечать: Ключевая идея — алерты на симптомы для пользователя, а не на каждую метрику: связь с SLO, приоритизация, устранение шума, эскалация и дежурства.

Как отвечать: Назовите реальный стек: Prometheus и PromQL, Grafana, Loki или ELK для логов, Jaeger или Tempo для трейсов. Покажите, как дашборд отвечает на вопросы об SLO.

Как отвечать: Опишите blameless-подход: хронология, первопричина и способствующие факторы, конкретные action items с владельцами и сроками — без поиска виноватых.

Как отвечать: Расскажите про анализ трендов, нагрузочное тестирование, запас мощности под пиковые события (распродажи, сезонность) и автомасштабирование.

Как отвечать: Назовите выбор SLI — доступность и латентность, целевые значения SLO по боли пользователей, расчёт error budget, алертинг на скорость расхода и политику релизов при его исчерпании.

Как отвечать: Посчитайте (примерно 43 минуты в месяц), свяжите с error budget и покажите, как он влияет на решения: канареечные релизы, скорость выкатки, приоритеты задач.

Как отвечать: Покажите работу с распределённой системой: трейсинг запроса, латентность по перцентилям (p95, p99), внешние зависимости и база данных — а не только CPU и память.

Как отвечать: Покажите прагматизм: сначала наблюдаемость и алерты, затем устранение единых точек отказа, runbook-и, изоляция сбоев — и только потом архитектурные изменения.

Как отвечать: Ответьте по STAR: масштаб и влияние на пользователей, ваши действия в роли incident-реагирующего, результат и что изменили в системе после постмортема.

Как отвечать: Покажите партнёрскую позицию: объяснение через error budget и пользовательский опыт, поиск компромисса и встраивание надёжности в процесс, а не запреты.

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

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

Как отвечать: Дайте конкретику: что автоматизировали, сколько часов toil сэкономили, как измерили эффект и как команда приняла изменение.

Как отвечать: Свяжите с практикой: домашний кластер или pet-проекты, книги (Google SRE Book), доклады и CNCF-ландшафт, опыт внедрения нового инструмента на прошлом месте.