Мок-интервью для SRE — практика с AI

SRE-интервью — это цикл, где глубина DevOps встречается с инженерной строгостью разработки, и офферы получают те, кто умеет переходить от пятиминутной сортировки инцидента к тридцатиминутному разговору про дизайн SLO, не теряя аудиторию. Большинство кандидатов теряют оффер не на мелочах по Linux, а в момент, когда их спрашивают: «какой у вас бюджет ошибок на этот квартал и как вы к нему пришли». Это руководство показывает, как использовать мок-интервью с AI, чтобы отрепетировать именно SRE-цикл.

Типичные раунды интервью для SRE

SRE-цикл — самый длинный в инфраструктуре, обычно 5–6 раундов. Скрининг с рекрутером; телефонный скрининг по основам (внутренности Linux, сети, основы распределённых систем); интервью с кодом (Python или Go, обычно парсинг логов или сборка небольшого CLI, иногда с лёгкими структурами данных); раунд реагирования на инциденты или траблшутинга («продакшен лежит — ведите звонок»); раунд system design («спроектируйте глобальный балансировщик нагрузки с доступностью 99,99%»); и поведенческий раунд с нанимающим менеджером. Senior- и staff-циклы добавляют раунд по SLO и стратегии надёжности, где вы обосновываете компромиссы на уровне организации.

Раунд реагирования на инциденты и раунд стратегии надёжности — там, где моки с AI окупаются особенно сильно. Оба — открытые разговоры под давлением времени, оба вознаграждают структурное мышление, оба наказывают за общие ответы. Мок с AI почти точно воспроизводит формат разворачивающегося сбоя: расплывчатая вводная, нарастающие follow-up-вопросы, оценка по тому, как вы сужаете пространство поиска. Раунд system design тоже хорошо ложится — у SRE-дизайна свой вкус (доступность, радиус поражения, графы зависимостей), который мок может прорабатывать прицельно.

Главные технические темы

SLO и бюджеты ошибок

Словарь из книги Google SRE — обязательный минимум. Будьте готовы: SLI vs SLO vs SLA, выбор SLI, которые реально важны клиентам (доля успешных запросов, задержка p99, свежесть — а не загрузка CPU), математика бюджета ошибок (месячный SLO 99,9% даёт вам 43 минуты бюджета), политика бюджета ошибок (что вы делаете, когда его исчерпали — заморозка релизов, депроритизация фич, обязательный постмортем). Любимый вопрос: «у команды доступность 99,95%, но клиенты жалуются — в чём дело?» Сильные ответы препарируют определение SLI, окно агрегации и опыт каждого отдельного клиента.

Реагирование на инциденты

Мок будет моделировать это напрямую. Будьте готовы к структурному ритму сортировки: сначала оцените радиус поражения (кто затронут, сколько), затем стабилизируйте (откат, сброс трафика, масштабирование мощностей), затем диагностируйте (логи, трассировки, недавние изменения) и только потом беритесь за долгосрочное исправление. Роль IC (incident commander) — отдельный навык: будьте готовы рассказать, как вы координируете работу, когда трое печатают одновременно. Культура постмортемов: безвинная (blameless), пункты действий с владельцами и разница между корневой причиной и способствующими факторами.

Linux и внутренности ОС

Будьте готовы: модель процессов, сигналы, файловые дескрипторы, OOM killer и как предсказать, кого он выберет, cgroups и namespaces, /proc и /sys для живой интроспекции, системные вызовы и strace, eBPF для трассировки в продакшене без перезапуска сервисов и сети Linux (iptables, conntrack, netfilter). Любимый вопрос: «load average — 200, а CPU на 30%. В чём дело?» Сильные ответы отделяют runnable-процессы от спящих и указывают на IO wait, борьбу за блокировки или потоки.

Сети

Senior-SRE циклы копают глубоко. Будьте готовы: TCP-рукопожатие, slow start и контроль перегрузки, разница между задержкой и пропускной способностью в одном разговоре, DNS (и почему DNS — это половина мировых сбоев), TLS-рукопожатия и OCSP stapling, основы BGP для глобальной инфраструктуры, anycast vs unicast-маршрутизация, типы балансировщиков нагрузки (L4 vs L7, аппаратные vs программные, sticky vs round-robin). Любимый сценарий: «задержка из EU в US-East удвоилась в 3 часа ночи, без деплоя. Разберите со мной этот случай».

Распределённые системы

SRE-раунды по дизайну их обожают. Будьте готовы: CAP и PACELC, модели согласованности (строгая, итоговая, причинная, read-your-writes), консенсус (Raft, набросок Paxos), выбор лидера, стратегии шардирования и ребалансировки, топологии репликации (sync vs async, опасности multi-leader), распределённые транзакции (saga, two-phase commit и почему его никто не запускает), токены идемпотентности и семантика очередей (at-most-once vs at-least-once vs exactly-once и что на практике реально означает exactly-once).

Стек наблюдаемости

Prometheus, Grafana, Loki, Tempo или Jaeger, OpenTelemetry. Будьте готовы: кардинальность метрик и сколько она стоит, алертинг на симптомы vs причины, что делает хороший runbook, сэмплирование логов на масштабе (и почему счёт за логи — вторая по величине статья инфраструктурных расходов), стратегии сэмплирования трассировок (head-based vs tail-based) и как проектировать дашборды для дежурного, у которого 30 секунд до того, как нужно принять решение.

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

• «Продакшен лежит. Последний деплой был 4 часа назад. Ведите звонок по инциденту». (Ритм сортировки, вопрос об откате, коммуникация, поза IC.)
• «Задайте SLO для платёжного API. Отстоите своё число перед CFO, который хочет 100%». (Стоимость «девяток», концепция бюджета ошибок, воспринимаемая клиентом доступность.)
• «Спроектируйте глобальный балансировщик нагрузки с доступностью 99,99%». (DNS-маршрутизация, anycast, health checks, региональный failover, радиус поражения.)
• «Половина запросов к одному микросервису медленные, но только в 4 утра по UTC. Разберитесь». (Cron-задачи, GC, ротация логов, окна бэкапов, очистки по retention.)
• «Вы исчерпали квартальный бюджет ошибок. PM хочет на следующей неделе выкатить большую фичу. Что вы скажете?» (Политика бюджета, заморозка, переговоры, путь эскалации.)

Поведенческие фокусы — что ищут нанимающие менеджеры

Нанимающие менеджеры на SRE отбирают по трём конкретным качествам. Первое — спокойствие под огнём: умеете ли вы сохранять ровный голос, когда ситуация становится скверной? Мок не смоделирует кортизол, но проверит, держится ли ваше структурное мышление, когда вводная становится неоднозначной. Второе — безвинная культура: каждая история постмортема должна фокусироваться на системных причинах (у нас не было алерта, runbook устарел, инструмент деплоя это пропустил), а не на человеке, который нажал кнопку. Третье — деловое суждение о надёжности: staff- и principal-SRE спорят с PM и руководством о том, сколько стоит надёжность. Сильные истории показывают, как вы обосновали это цифрами, а не «ощущениями». Ждите вопросов про запомнившийся сбой, случай, когда вы исчерпали SLO, момент, когда вы сказали «нет» фиче ради надёжности.

Как использовать практику мок-интервью с AI для этой роли

Установите тип интервью «Технический скрининг» или «Сценарий» в зависимости от того, что прорабатываете. Для практики SLO и стратегии надёжности вставьте ситуацию вашей текущей команды как контекст и попросите AI сыграть скептичного CFO или PM. Для реагирования на инциденты переключитесь в режим «Сценарий» и попросите AI вести разворачивающийся сбой 15–20 минут. Мок оценивает, как вы сужаете пространство поиска, а не дошли ли вы до «правильной» корневой причины.

Для system design проводите «System Design» с SRE-специфичными задачами: спроектируйте глобальный rate limiter, спроектируйте multi-region failover базы данных, спроектируйте control plane, который не уронит сам себя. AI будет давить на доступность и радиус поражения так, как это делает SRE-интервьюер, — а не на UX для пользователя.

Один прогон, который окупается быстро: проведите пять подряд сценариев инцидентов в разных доменах (платежи, стриминг видео, внутренний API, ML-инференс, файловое хранилище). Распознавание паттерна «это деплой, зависимость, проблема с данными или мощности» — самый переносимый навык SRE-интервью.

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