Проверка навыков SRE на собеседованиях

В описанном процессе найма после общения с рекрутером следуют секции по системной инженерии, программированию и диагностике. Затем кандидат встречается с подходящей командой. Необходимость проверки troubleshooting связана с ростом продуктов и распределением ответственности за надёжность: инженеры внутри команд должны самостоятельно разбираться в поведении своих систем, а не только передавать проблему центральным специалистам.

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

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

В учебном примере система работает в двух дата-центрах и включает React, Django, Kubernetes, Postgres и Redis. Жалобы пользователей ведут к анализу запросов, ошибок и длительности ответов по подходу RED. Преобладающие ошибки 504 направляют дальнейшую проверку к ожиданию ответа. Статья показывает начало рассуждения, а не предлагает угадывать единственную причину сбоя по одному коду ошибки.

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

System Design начинается с требований к будущей системе, тогда как troubleshooting — с уже работающей системы, в которой случился сбой. Оба навыка полезны SRE, но в описанном найме отдельную дизайн-секцию убрали и решили развивать проектирование у сотрудников. Для обучения предложены работа с реальными системами, разбор публичных постмортемов, архитектурные задачи и изучение инженерных принципов. Решение о составе секций отражает конкретный опыт компании, а не отказ от важности проектирования.