Эта глава фокусируется на диагностике инцидентов и reasoning под давлением.
В реальной работе материал помогает проектировать процесс подготовки и карьерных решений: выбирать приоритеты, структурировать сигналы и управлять риском неверной ставки на случайные практики.
Для system design interview глава полезна тем, что дает рабочий язык аргументации: как показывать инженерную зрелость, объяснять компромиссы и защищать решения под ограничением времени.
Практическая польза главы
Декомпозиция инцидента
Разбивайте проблему на плоскости: пользовательский эффект, инфраструктура, данные, релизные изменения.
Дерево гипотез
Стройте приоритизированные гипотезы с явным критерием подтверждения и стоимостью проверки.
Триаж сигналов
Опирайтесь на метрики, логи и трассировки, чтобы отсеивать шум и сокращать время до корня проблемы.
Коммуникация под давлением
Держите прозрачный статус, план действий и риски для стейкхолдеров во время инцидента.
Источник
Troubleshooting Interview
Материал основан на статье и выступлении Alexander Polomodov на DevOps & Techlead Conf 2022.
Troubleshooting Interview — это особый формат технического собеседования, который проверяет способность кандидата диагностировать и устранять проблемы в production-системах. В отличие от System Design, где мы проектируем системы "с нуля", здесь мы работаем с уже существующей системой, которая внезапно "загорелась".
Ключевое отличие от System Design
В System Design Interview на старте есть только требования заказчика, и цель — спроектировать систему, которая не подвержена "возгораниям". В Troubleshooting на старте уже есть боевая система, и цель — потушить внезапно "загоревшуюся" систему.
Зачем нужно Troubleshooting Interview
Для компании
- •Децентрализация обеспечения надёжности — инженеры должны сами уметь обеспечивать надёжность своих систем
- •Быстрый рост штата и переход к кросс-функциональным командам
- •Мультипродуктовая экосистема с нетривиальными интеграциями
Для кандидата
- •Возможность получить опыт работы над инцидентом в условиях, приближённых к реальности
- •Цена ошибки не так велика — можно проверить себя почти в "бою"
- •Обратная связь о том, что стоит подтянуть
Видеозапись
DevOps & Techlead Conf 2022
Запись выступления с демонстрацией формата интервью.
Формат интервью
Легенда
По легенде кандидат и интервьюер работают совместно в SRE-команде. Кандидат исполняет роль Lead, а интервьюер — Junior. Lead уезжает на конференцию, а Junior остаётся дежурить. Во время дежурства происходит инцидент, и Junior "звонит" Lead-у с просьбой помочь распутать ситуацию.
Важно: вопросы и команды должны быть максимально точными и конкретными, так как Junior на сложные вопросы ответить не сможет "в силу своего грейда".
Связанная глава
Подходы к интервью по проектированию
Аналогичный 7-шаговый фреймворк для System Design Interview.
Шаги Troubleshooting Interview
9 этапов от начала до постмортемаОписание регламента
Интервьюер объясняет формат и правила взаимодействия
Обсуждение архитектуры
Интервьюер показывает архитектурную схему и рассказывает про компоненты системы
Вопросы по системе
Кандидат задаёт уточняющие вопросы (часто пропускают этот шаг)
Старт инцидента
Интервьюер сообщает о симптомах — внешних эффектах проблемы
Диагностика
Формулирование гипотез и проведение экспериментов
Workaround решение
Быстрое решение для митигации проблемы у пользователей
Полноценная починка
Устранение проблемы с пониманием алгоритма решения
Root Cause
Понимание почему всё произошло — все элементы пазла собираются
Улучшение системы
Как предотвратить повторение или узнать о проблеме раньше
Описание регламента
Интервьюер объясняет формат и правила взаимодействия
Обсуждение архитектуры
Интервьюер показывает архитектурную схему и рассказывает про компоненты системы
Вопросы по системе
Кандидат задаёт уточняющие вопросы (часто пропускают этот шаг)
Старт инцидента
Интервьюер сообщает о симптомах — внешних эффектах проблемы
Диагностика
Формулирование гипотез и проведение экспериментов
Workaround решение
Быстрое решение для митигации проблемы у пользователей
Полноценная починка
Устранение проблемы с пониманием алгоритма решения
Root Cause
Понимание почему всё произошло — все элементы пазла собираются
Улучшение системы
Как предотвратить повторение или узнать о проблеме раньше
Фундамент
Контейнеризация
K8s и контейнеры задают окружение, где развивается инцидент.
Пример типовой задачи
Контекст системы
- Несколько миллионов клиентов ежедневно
- Два датацентра
- Фронтенд на React + бэкенд на Python/Django
- Оба приложения развёрнуты в K8s
- Postgres для данных, Redis для кэша
Инцидент
Техподдержка сообщает об увеличении обращений клиентов с жалобами на скорость работы сайта и периодически незагружающиеся страницы.
Пример диалога
Критерии оценки кандидата
Кругозор
Широта используемых инструментов и подходов к диагностике
Методичность
Логичность и системность поиска решения, осмысленное отсечение неверных гипотез
Workaround
Скорость нахождения временного решения для митигации проблем у пользователей
Полноценный фикс
Нахождение решения проблемы и формулирование алгоритма его применения
Root Cause
Понимание корневой причины, объясняющей симптомы и почему решение сработало
Улучшения
Предложения по предотвращению повторения или раннему обнаружению
Пример профиля кандидата
Кандидат с неплохим знанием инструментов (Middle), логично шёл по задаче (Middle+), быстро нашёл workaround (Middle), но не докопался до полноценного фикса (Junior), не понял корневую причину (Junior) и предложил косметические улучшения. Интегральная оценка: Junior.
Обычно оценки по разным осям варьируются — редко бывают ярко выраженные уровни по всем критериям.
Troubleshooting vs System Design
Troubleshooting
- →На старте уже есть боевая система
- →Цель: потушить "загоревшуюся" систему
- →Проверяем системность подхода к диагностике
- →Хорошо проходят ребята близкие к инфраструктуре и эксплуатации
System Design
- →На старте только требования заказчика
- →Цель: спроектировать систему без "возгораний"
- →Проверяем системность подхода к проектированию
- →Хорошо проходят ребята близкие к проектированию и разработке
Идеальный SRE должен обладать обоими навыками — не просто тушить пожары, но и системно работать над надёжностью.
Как прокачаться
Troubleshooting
Теория:
- Практики из SRE Book и SRE Workbook
- Building Secure & Reliable Systems
- Изучение инструментов диагностики
Практика:
- Работа в SRE команде над реальными системами
- Разбор публичных postmortems
- Тренировка на задачах по мотивам postmortems
System Design
Теория:
- Принципы проектирования распределённых систем
- Классы систем и границы применимости
Практика:
- Работа архитектором над реальными системами
- Разбор архитектуры крупных систем (Google, Meta)
- Решение архитектурных kata
References
Связанные главы
- Пример Troubleshooting Interview - практический разбор того же формата интервью с пошаговой диагностикой инцидента.
- Подходы к проведению интервью по проектированию - показывает общую структуру интервью и помогает перенести её на troubleshooting-сценарии.
- Оценка интервью и вариация сложности - объясняет логику оценивания и как интервьюер калибрует сложность по ходу диалога.
- Site Reliability Engineering - даёт фундаментальные практики эксплуатации и подходы к работе с продовыми инцидентами.
- The Site Reliability Workbook - добавляет прикладные playbook-паттерны для on-call и инцидент-менеджмента.
- Building Secure and Reliable Systems - связывает эксплуатационные практики с архитектурными решениями по надёжности.
- Release It! - покрывает антипаттерны и resilience-подходы, которые часто всплывают в troubleshooting.
- Designing Data-Intensive Applications - укрепляет понимание отказов, консистентности и корневых причин на уровне data-систем.