Вопросы на собеседовании SRE и как на них отвечать

Вы прочитали сотню списков вопросов по DevOps, и ни один не совпадает с описанием вакансии, на которую вы откликнулись. Этот разрыв реален, и этот раздел объясняет, что оценивает собеседование SRE, прежде чем списки вопросов ниже перейдут к деталям. Коротко: на первом месте рассуждения о надёжности, на втором месте глубина системных знаний, на третьем месте код.

Важное различие состоит в разнице между знанием инструмента и пониманием того, что значит надёжность. Кандидат, который может перечислить команды Kubernetes, но не может объяснить, для чего нужен бюджет ошибок, столкнётся с трудностями, а кандидат, который ясно рассуждает об отказах, измерениях и компромиссах, сможет освоить инструменты уже на работе. Интервьюеры выстраивают раунды исходя из этого убеждения.

Типичный процесс включает основы надёжности, живое упражнение по отладке, раунд проектирования, сфокусированный на отказах, раунд по коду, построенный вокруг автоматизации, и поведенческий раунд о дежурствах. Некоторые компании встраивают отладку в раунд проектирования; немногие пропускают её полностью, потому что именно этот раунд отличает тех, кто реально носил пейджер, от тех, кто лишь читал об этом.

Это раунд, где важна терминология, потому что у этих терминов есть точный смысл, и интервьюеры слушают, правильно ли вы их используете. Потренируйтесь проговаривать определения вслух своими словами, а не заучивать формулу.

• В чём разница между SLI, SLO и SLA?
• Как бы вы выбрали SLI для сервиса, от которого зависят другие команды?
• Что такое бюджет ошибок, и что должна делать команда, когда он исчерпан?
• Является ли доступность в сто процентов разумной целью? Обоснуйте ответ.
• Как задать цель по доступности для совершенно нового сервиса без истории?
• Сервис каждый месяц укладывается в свой SLO, но пользователи продолжают жаловаться. Что пошло не так?
• Как процентили задержки меняют способ измерения сервиса?

Последние два вопроса разделяют кандидатов. Оба проверяют, понимаете ли вы, что SLO является показателем пользовательского опыта, а не оценка, которую нужно защищать, и что средние значения скрывают именно те запросы, которые по-настоящему злят людей.

Раунды по отладке обычно проходят вживую и в формате диалога: интервьюер описывает симптомы, а вы продвигаетесь к причине, запрашивая доказательства. Оценивают именно ваш метод, поэтому проговаривайте его вслух. Говорите, что бы вы проверили, что исключил бы каждый результат, и что бы вы проверили дальше.

• Задержка сервиса резко выросла в полдень без какого-либо деплоя. Опишите ход расследования.
• Пользователи сообщают о периодических сбоях, но ваши дашборды выглядят нормально. Куда вы посмотрите?
• Объясните, что происходит между вводом URL и отрисовкой страницы.
• На хосте высокий load average, но низкая загрузка CPU. Что происходит?
• Как вы находите, какой процесс заполняет диск, и что вы делаете в первую очередь?
• Опишите, как бы вы отлаживали сбой разрешения DNS внутри кластера.
• Какие режимы отказа бывают у повторных попыток, и как сделать их безопасными?
• Как бы вы спроектировали проверки работоспособности для сервиса за балансировщиком нагрузки?
• Что происходит, когда исчерпан пул соединений к базе данных, и как это обнаружить?

Раунды проектирования продолжают ту же логику: вас просят что-то спроектировать, а затем спрашивают, что может сломаться. Будьте готовы без напоминания говорить о каскадных отказах, обратном давлении (backpressure), плавной деградации и запасе мощности, потому что упоминание этого по своей инициативе и есть настоящий сигнал. Более узкоспециализированные наборы вопросов по ролям собраны в банке вопросов для собеседований.

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

Представьте платформенного инженера, который готовится к роли, связанной с надёжностью. У него был инцидент, когда изменение конфигурации положило внутренний API на часть утра, и в первом варианте своей истории он винил пропущенный этап ревью. Переписав историю вокруг того, что он наблюдал, что пробовал, почему откат занял столько времени, и какое оповещение он добавил впоследствии, он превратил оправдание в доказательство здравого суждения. Именно такую форму хотят видеть интервьюеры.

Проговаривайте эти истории вслух перед собеседованием. Молчаливое перечитывание скрывает места, где хронология рассыпается, а инструмент для тренировочного собеседования может задавать вам вопросы на время, чтобы вы услышали собственные паузы. Во время живого собеседования SubcueAI расшифровывает вопрос и составляет структурированный ответ на экране, работая из нативного десктопного приложения для macOS или Windows либо из боковой панели браузерного расширения в Chrome и Edge, без какого-либо бота, присоединяющегося к звонку. Он не помогает на прокторируемом тестировании или упражнении по отладке с показом экрана, где всё, что видите вы, видно и интервьюеру.