Интервью по диагностике инцидентов проверяет не проектирование на пустом листе, а поведение инженера в момент, когда система уже деградирует и времени на спокойный перебор вариантов почти нет.
Глава показывает, как в таком формате оцениваются чтение симптомов, приоритизация гипотез, качество проверок и способность удерживать разговор вокруг пользовательского эффекта, а не вокруг случайных догадок.
Для компании это способ увидеть инженерную зрелость в стрессовой ситуации, а для кандидата — понятная карта ожиданий: не метаться по логам, а вести расследование последовательно, с явными приоритетами и проверяемыми версиями.
Практическая польза главы
Декомпозиция инцидента
Разбивайте проблему на плоскости: пользовательский эффект, инфраструктура, данные, релизные изменения.
Дерево гипотез
Стройте приоритизированные гипотезы с явным критерием подтверждения и стоимостью проверки.
Приоритизация сигналов
Опирайтесь на метрики, логи и трассировки, чтобы отсеивать шум и быстрее выходить на первопричину.
Коммуникация под давлением
Держите прозрачный статус, план действий и риски для стейкхолдеров во время инцидента.
Источник
Troubleshooting Interview
Материал основан на статье и выступлении Александра Поломодова на профильной конференции 2022 года.
проверяет не умение рисовать систему с чистого листа, а поведение инженера в момент, когда сервис уже деградирует. Здесь важно замечать симптомы, задавать точные вопросы, быстро сужать круг гипотез и отделять срочную стабилизацию от полноценного исправления.
Чем этот формат отличается от интервью по системному дизайну
В разговор начинается с требований и будущей архитектуры. Здесь же стартовая точка другая: система уже работает нестабильно, пользователи чувствуют проблему, и от кандидата ждут не красивой схемы, а внятного плана расследования.
Зачем компаниям нужен такой формат
Для компании
- •Надёжность всё чаще распределена по продуктовым командам, и инженеры должны уметь сами разбираться со сбоями своих сервисов.
- •В сложных экосистемах важно проверить, умеет ли кандидат думать не только про код, но и про эксплуатацию, зависимости и пользовательский ущерб.
- •Такой формат даёт сигнал о том, как человек поведёт себя в реальном инциденте под давлением времени и неполной информации.
Для кандидата
- •Можно показать зрелость не только через архитектуру, но и через реальную инцидентную логику: от чтения симптомов до выбора приоритетов.
- •Формат быстро высвечивает слабые места: где не хватает инструментов, где гипотезы расползаются, а где теряется связь с пользовательским эффектом.
- •Подготовка к таким интервью хорошо переносится в реальную работу, потому что учит вести расследование последовательно, а не хаотично.
Видеозапись
DevOps & Techlead Conf 2022
Запись выступления с объяснением формата и примерами того, как интервьюер управляет ходом расследования.
Как устроено интервью
Легенда сценария
По сценарию кандидат и интервьюер работают в одной команде . Кандидат играет роль Lead, а интервьюер отвечает за роль Junior. Lead уезжает, Junior остаётся на дежурстве, начинается инцидент, и дальше кандидат должен направлять расследование через вопросы, проверки и команды.
Важная особенность формата: интервьюер намеренно ограничен ролью менее опытного коллеги, поэтому не сможет понять абстрактные команды вроде «посмотри, что там не так». Сигнал снимается именно с точности и последовательности ваших инструкций.
Связанная глава
Интервью по системному дизайну: 7-шаговый подход
Полезно сравнить, как архитектурный разговор меняется, когда вместо проектирования нужно расследовать уже случившийся сбой.
Ход интервью по диагностике инцидентов
9 этапов: от вводных до выводов после инцидентаВводные и правила
Интервьюер объясняет формат и границы взаимодействия в сценарии
Разбор архитектуры
Интервьюер показывает схему системы и проговаривает ключевые компоненты
Уточняющие вопросы
Кандидат проясняет детали системы и устраняет критичные неизвестные
Старт инцидента
Интервьюер сообщает о симптомах и пользовательском эффекте проблемы
Диагностика
Формулирование гипотез, выбор проверок и отсечение неверных версий
Временная стабилизация
Быстрые действия, которые снижают пользовательский ущерб прямо сейчас
Полное устранение проблемы
Исправление сбоя с понятным планом внедрения решения
Корневая причина
Понимание того, почему именно возникла проблема и как связаны все симптомы
Профилактика повторения
Изменения, которые помогут поймать проблему раньше или не допустить её снова
Вводные и правила
Интервьюер объясняет формат и границы взаимодействия в сценарии
Разбор архитектуры
Интервьюер показывает схему системы и проговаривает ключевые компоненты
Уточняющие вопросы
Кандидат проясняет детали системы и устраняет критичные неизвестные
Старт инцидента
Интервьюер сообщает о симптомах и пользовательском эффекте проблемы
Диагностика
Формулирование гипотез, выбор проверок и отсечение неверных версий
Временная стабилизация
Быстрые действия, которые снижают пользовательский ущерб прямо сейчас
Полное устранение проблемы
Исправление сбоя с понятным планом внедрения решения
Корневая причина
Понимание того, почему именно возникла проблема и как связаны все симптомы
Профилактика повторения
Изменения, которые помогут поймать проблему раньше или не допустить её снова
Фундамент
Контейнеризация
Контейнерная платформа задаёт среду, в которой развивается инцидент и где кандидат должен ориентироваться в зависимостях.
Типичный сценарий
Контекст системы
- Несколько миллионов пользователей в день
- Два дата-центра
- Фронтенд на React и бэкенд на Python/Django
- Оба приложения развёрнуты в
- Postgres отвечает за данные, Redis используется как кэш
Симптом
Техподдержка сообщает о росте обращений: сайт заметно замедлился, а часть страниц периодически не открывается.
На первом проходе расследование часто начинают с , чтобы быстро увидеть, что происходит с потоком запросов, ошибками и длительностью, а затем дополняют картину , если нужно понять, не упёрлась ли система в загрузку ресурсов, насыщение или ошибки на конкретном узле.
Фрагмент диалога
Как оценивают кандидата
Инструментарий
Насколько широко кандидат использует метрики, логи, трассировки, дашборды и знания об архитектуре системы.
Методичность
Насколько последовательно он формирует гипотезы, отсеивает шум и двигается от симптомов к проверкам.
Временная стабилизация
Как быстро кандидат предлагает способ снизить пользовательский ущерб, не дожидаясь полного исправления.
Полное устранение проблемы
Умеет ли кандидат довести расследование до исправления, а не остановиться на первом смягчающем действии.
Корневая причина
Понимает ли он, почему именно возникли симптомы и почему выбранное решение действительно должно сработать.
Профилактика повторения
Предлагает ли кандидат изменения в мониторинге, архитектуре или процессах, чтобы проблему поймали раньше или не допустили снова.
Пример итогового профиля
Представим кандидата, который уверенно пользуется диагностическими инструментами и идёт по задаче последовательно, но быстро находит только и не доводит разговор до полного исправления. Если при этом он ещё и не объясняет , итоговая оценка легко опустится до уровня Junior, даже если начало разговора было сильным.
Оценки по осям почти всегда различаются: сильное расследование редко выглядит как ровный профиль без перекосов.
Чем этот формат отличается от интервью по системному дизайну
Диагностика инцидента
- →На старте уже есть работающая, но деградировавшая система.
- →Цель разговора — стабилизировать ситуацию и дойти до первопричины.
- →Интервьюер проверяет качество расследования, приоритизацию действий и операционную ясность.
- →Особенно полезен для ролей в , платформенных команд и ролей, сфокусированных на надёжности.
Системный дизайн
- →Разговор начинается с требований и будущего пользовательского сценария.
- →Цель — собрать архитектуру, которая выдержит нужный масштаб и ограничения.
- →Основной сигнал — зрелость проектирования, декомпозиции и обсуждения рисков.
- →Чаще всего нужен для серверных, платформенных и продуктовых инженерных ролей.
Сильный инженерный профиль выигрывает от обоих навыков: важно не только разбирать сбои, но и строить такие системы, в которых цена инцидента становится ниже.
Как развивать этот навык
Диагностика инцидентов
Теория:
- Практики Google по и рабочей книги Google по эксплуатации надёжных сервисов
- Материалы по надёжности, защитным механизмам и анализу отказов
- Системное знакомство с метриками, логами, трассировками и дашбордами
Практика:
- Участие в и разборе реальных инцидентов
- Чтение публичных отчётов по инцидентам и реконструкция хода расследования
- Тренировка на сценариях, где нужно объяснить и срочную стабилизацию, и долгосрочный фикс
Системное проектирование
Теория:
- Принципы проектирования распределённых систем и работа с ограничениями
- Классы систем, типовые компромиссы и границы применимости решений
Практика:
- Разбор архитектуры реальных систем и решений после инцидентов
- Связывание постфактум-уроков с архитектурными изменениями
- Регулярные тренировочные интервью по системному дизайну и инцидентным сценариям
Источники
Связанные главы
- Пример интервью по диагностике инцидентов - показывает тот же формат на живом сценарии расследования инцидента.
- Интервью по системному дизайну: 7-шаговый подход - помогает сравнить архитектурный разговор с инцидентным сценарием и увидеть, где меняется логика интервью.
- Как оценивают интервью по системному дизайну и как управляется его сложность - объясняет, как интервьюер собирает сигналы и регулирует объём подсказок по ходу разговора.
- Site Reliability Engineering - даёт базовые практики эксплуатации и реакции на продовые инциденты.
- The Site Reliability Workbook - добавляет прикладные сценарии , работы с инцидентами и улучшения операционных процессов.
- Building Secure and Reliable Systems - связывает надёжность и безопасность с архитектурными решениями, которые уменьшают цену инцидентов.
- Release It! - систематизирует отказовые режимы и защитные меры, которые часто обсуждают в таких интервью.
- Designing Data-Intensive Applications, 2nd Edition - углубляет понимание отказов, консистентности и поиска первопричин в распределённых системах.