Page 1 of 1

DevOps Engineer / SRE

DevOps Engineer / SRE — проект по созданию отказоустойчивой production-инфраструктуры

Пожалуйста, отвечайте кратко и конкретно, опираясь на собственный практический опыт.

Нам не нужны определения терминов, пересказ документации или общие рекомендации. Важно указать, что именно делали лично вы, в какой системе, с какими ограничениями, какие решения принимали и к какому результату это привело.

Кандидатов, прошедших анкету, мы попросим устно разобрать отдельные ответы на техническом интервью.

Ориентировочное время заполнения: 15–30 минут.

Контактная информация

ФИО

Город и страна проживания

Основной контакт для связи

Укажите Telegram или WhatsApp

Ссылка на резюме или профессиональный профиль

Можно указать HeadHunter, Habr Career, LinkedIn, GitHub или личный сайт.

Ваш текущий профессиональный профиль

Укажите:

- текущую или последнюю должность; - общий опыт работы в DevOps/SRE;

- размер и тип production-систем, с которыми вы работали; - вашу обычную роль: исполнитель, самостоятельный инженер или технический владелец инфраструктуры; - количество человек в технической команде.

Последняя production-инфраструктура

Опишите последнюю production-инфраструктуру, с которой вы работали лично:

- что делала система; - примерная нагрузка; - количество серверов или кластеров; - используемая база данных; - Redis; - load balancers; - monitoring; - CI/CD; - за какие компоненты отвечали именно вы.

Не перечисляйте весь технологический стек компании. Нас интересует ваша личная зона ответственности.

Реальный production-инцидент

Расскажите об одном production-инциденте, в котором вы лично участвовали.

Укажите:

1. Что первым показало, что возникла проблема? 2. Какой была ваша первая гипотеза? 3. Какая гипотеза оказалась неправильной? 4. Что оказалось реальной причиной? 5. Какие действия выполнили лично вы? 6. Сколько времени заняло восстановление? 7. Были ли потеряны данные? 8. Что изменили после инцидента, чтобы он не повторился?

Database replication и failover

Опишите один проект, где вы лично настраивали или сопровождали replication и failover production-базы данных.

Укажите: - какая использовалась база данных;

- кто был primary и кто replica или standby; - какая использовалась репликация; - как обнаруживался отказ primary; - как происходило переключение; - как приложение получало новый primary; - как контролировался replication lag; - как исключался split-brain; - проводили ли вы failback; - какие фактические RPO и RTO были получены.

Отдельно укажите, что было настроено лично вами, что предоставлял managed provider и что выполняли другие специалисты.

Если вы не реализовывали DB failover лично, укажите это прямо.

Проблемное переключение базы данных

Был ли у вас случай, когда:

- failover не сработал; - replica оказалась неактуальной;

- приложение не переподключилось; - возник split-brain; - failback оказался сложнее failover; - после переключения обнаружились потерянные транзакции?

Опишите один случай либо укажите, что с подобной ситуацией не сталкивались.

Нас интересуют:

- конкретный симптом; - причина; - что было упущено при проектировании; - что вы изменили после этого.

Практическая ситуация по нашему проекту

Есть production-система:

- два backend-сервера; - два load balancer; - managed MySQL без подтверждённого failover; - Redis и WebSocket на одном сервере; - на одном backend-сервере находятся SQLite, Node.js tracking service, локальная база и runtime files; - этот backend-сервер работает нестабильно; - система обрабатывает заказы в реальном времени.

Назовите первые пять действий, которые вы выполните до замены нестабильного сервера

Для каждого действия кратко укажите:

- что проверяете; - какой риск этим закрываете; - какой результат должен быть получен.

Выбор решения Database High Availability

Представьте, что после аудита вы можете выбрать:

1. Managed MySQL HA с автоматическим failover. 2. Самостоятельно настроенные MySQL primary и replica на виртуальных серверах.

Какой вариант вы предварительно выбрали бы для нашего проекта?

Укажите:

- три основных аргумента; - главный недостаток выбранного варианта;

- при каком условии вы изменили бы решение; - что обязательно проверили бы до production migration.

Проверка DB failover

Назовите конкретные шаги controlled failover test, после которого вы готовы сказать владельцу бизнеса:

«Переключение базы действительно работает».

Обязательно укажите:

- что отключается или имитируется; - какие метрики вы наблюдаете; - какие данные создаёте непосредственно перед отказом; - какие business flows проверяете после переключения; - как определяете фактический RPO; - как определяете фактический RTO; - что проверяете перед завершением теста.

Redis

Опишите самый сложный реальный случай, связанный с Redis, с которым вы работали.

Например: - исчерпание памяти;

- неправильная eviction policy; - потеря очередей; - проблема persistence; - Sentinel failover; - sessions; - locks; - большое количество reconnect; - Redis использовался для нескольких критических функций.

Укажите:

- симптом; - причину; - ваши действия; - итоговое решение.

Если сложных случаев не было, опишите реальную конфигурацию Redis, которую вы лично поддерживали.

Monitoring и alerts

Назовите пять alerts, которые вы настроили бы в первую очередь для нашей системы.

Для каждого укажите:

- конкретный сигнал или метрику; - условие срабатывания; - уровень Critical, High или Warning; - первое действие инженера после получения alert.

Не перечисляйте только общие категории вроде «CPU, память, база». Нужны конкретные условия.

Ошибка в monitoring

Приведите пример alert, который вы когда-то настроили неправильно или который создавал слишком много ложных срабатываний.

Укажите:

- что контролировал alert; - почему он оказался неэффективным; - как вы изменили правило; - по какому признаку поняли, что новая настройка работает лучше.

Deployment и rollback

Опишите последний deployment pipeline, который вы создавали или существенно меняли лично.

Укажите: - откуда запускался deployment;

- какие проверки выполнялись до production; - как обновлялись несколько backend nodes; - как node выводился из traffic; - как перезапускались workers; - как выполнялись database migrations; - какие smoke tests запускались; - что являлось условием rollback; - как выглядел реальный rollback.

Документация и передача системы

Приведите пример runbook, который вы писали для другого инженера.

Укажите:

- для какого инцидента он предназначался; - кто должен был им пользоваться; - какие опасные действия вы отдельно запретили; - проверял ли другой человек runbook без вашей помощи; - что пришлось изменить после практической проверки.

При наличии можно приложить обезличенный фрагмент документа.

Границы самостоятельности

Какие части нашего проекта вы готовы выполнить самостоятельно и принять за них техническую ответственность?

Отдельно укажите, где вам потребуется:

- review технического контролёра; - участие backend lead; - консультация DBA или другого узкого специалиста; - изменение кода приложения; - дополнительный бюджет на managed services.

План первых двух недель

Какой конкретный результат вы планировали бы показать после первых двух недель полной работы над проектом?

Укажите:

- что будет проверено; - какие решения будут приняты; - какие изменения уже могут быть внедрены; - какие production-изменения вы пока не стали бы выполнять; - какой документ или демонстрацию получит команда.

Английский язык

Наш backend lead находится в Индии. Часть рабочих встреч, технических обсуждений и переписки будет проходить на английском языке.

Укажите:

- ваш уровень английского языка; - насколько комфортно вам участвовать в устных технических обсуждениях на английском; - можете ли вы самостоятельно объяснять архитектурные решения, риски, причины incidents и план миграции; - готовы ли вы проводить демонстрации и knowledge transfer на английском; - можете ли вы готовить техническую документацию и runbooks на английском языке; - использовали ли вы английский язык в реальной международной команде.

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

Доступность и формат работы

Укажите:

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

Кандидатов, прошедших первичный отбор, мы попросим на интервью:

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

Конфиденциальные данные предыдущих работодателей предоставлять не требуется.