Как оценить навыки DevOps инженеров: методология и рубрика

Ошибка в оценке DevOps

Большинство команд оценивают кандидатов DevOps так же, как инженеров ПО: упражнения по кодированию. Но DevOps — это не в первую очередь кодирование. Это системное мышление, суждение о компромиссах и операционная устойчивость.

Кандидат может написать красивый Terraform и катастрофически провалиться, когда БД звонит в полночь. И наоборот, кандидат с пятнистым кодом может архитектировать систему, которая переживает полный отказ зоны без ручного вмешательства.

Вам нужен другой фреймворк.

Какие навыки DevOps действительно предсказывают производительность

1. Системное мышление и рассуждение о режимах отказа

Могут ли они назвать режимы отказа? Могут ли они проектировать для них упреждающе?

Что оценивать: Дайте им простую архитектуру (веб-приложение, говорящее с RDS) и спросите: "Что здесь ломается? Какой радиус взрыва? Как вы смягчаете?" Не просите их разработать Netflix. Попросите укрепить базовую установку.

Хороший ответ: "RDS — единая точка отказа. Я добавил бы read replicas для failover и connection pool для предотвращения истощения соединений. Само приложение должно быть stateless и loadbalanced. Я добавил бы circuit breaker для БД."

Слабый ответ: "Используй Kubernetes."

2. Операционный прагматизм

Выбирают ли они самое простое решение, которое действительно работает? Или тянутся к самому причудливому инструменту?

Что оценивать: "Вам нужно запустить ежедневное задание резервной копии. У вас два варианта: Kubernetes CronJob или Lambda. Ваша команда не запускает Kubernetes. Обсудите компромиссы."

Хороший ответ: "Lambda проще эксплуатировать, если вы уже не запускаете Kubernetes. Меньше движущихся частей, проще отлаживать, CloudWatch встроен. Компромисс — 15-минутный timeout и latency холодного старта, что не имеет значения для резервной копии. Я бы использовал Lambda."

Слабый ответ: "Всегда используй Kubernetes, потому что это портативнее."

3. Наблюдаемость и отладка

Могут ли они спроектировать мониторинг? Могут ли они отследить проблему от alert до причины?

Что оценивать: Живые интервью по кодированию здесь не применяются. Вместо этого дайте им production alert: "CPU на 80% на вашем Postgres инстансе. Выглядит случайно. Диагностика?" Попросите их рассказать: какие инструменты запроса они использовали бы, что бы они проверили, в каком порядке?

Хороший ответ: "Сначала я проверил бы pg_stat_statements для самых медленных запросов, потом проверил бы, коррелирует ли это с конкретным application эндпоинтом, потом посмотрел бы на статистику индексов, чтобы увидеть, недостаёт ли индекса или он раздут."

4. Суждение об автоматизации

Когда что-то должно быть автоматизировано против ручного?

Что оценивать: "Вы деплоите 20 раз в день, но миграции БД происходят только раз в неделю. Должны ли вы автоматизировать миграции так же, как деплои?"

Хороший ответ: "Нет. Автоматизация снижает когнитивную нагрузку, когда операция частая и низкорисковая. Миграции редкие и высокорисковые — вы хотите, чтобы человек проверил и одобрил перед запуском, и вы хотите dry-run сначала."

Слабый ответ: "Автоматизируй всё."

5. Компромиссы облачной архитектуры

AWS против Azure против GCP — это не про features, а про операции и стоимость.

Что оценивать: Представьте сценарий и спросите для разбора cost-benefit. "Вы строите microservices платформу. Должны ли вы использовать managed Kubernetes (EKS/AKS/GKE) или самоуправляемый?"

В идеале они скажут: "Managed лучше для маленьких-средних команд. Он обрабатывает control plane, обновления и networking за вас. Компромисс — меньше контроля и немного выше стоимость. Самоуправляемый лучше, если у вас есть выделённая команда и специфичные требования к networking."

Структура оценки

Часть 1: Take-home сценарий (2 часа)

Предоставьте диаграмму архитектуры или кодовую базу Terraform с намеренными gaps или проблемами безопасности. Спросите:

• Выявите проблемы
• Предложите исправления с анализом компромиссов
• Набросайте стратегию мониторинга для этой системы

Это асинхронно-дружественно и тестирует знание в масштабе.

Часть 2: Live troubleshooting (45 минут)

Сценарий: Production latency spike. Пройдитесь по тому, как бы вы её отлаживали.

Кандидат говорит; вы слушаете. Вы тестируете:

• Систематичный подход (не угадывание)
• Знание инструментов наблюдаемости
• Приоритизация (где смотреть сначала)
• Коммуникация (могут ли они объяснить свои мысли)

Часть 3: Разговор об архитектуре (30 минут)

Представьте ограничение или требование. "Нам нужно мигрировать 50TB данных в новую БД с нулевым downtime. Какой ваш подход?"

Это тестирует суждение и прагматизм. Нет правильного ответа — вы слушаете рассуждение о радиусе взрыва, планах rollback и операционной сложности.

Рубрика: Фреймворк скоринга

Чего избегать

Не:

• Просите DevOps кандидатов решать проблемы LeetCode. (Они получат высокий балл, но это не предсказывает производительность на работе.)
• Относитесь к DevOps как к "software engineering lite". (Это другой набор навыков.)
• Фокусируйтесь на ширине инструментов. (Знание Kubernetes не предсказывает, могут ли они эксплуатировать что-либо ещё.)
• Игнорируйте живые интервью. (Обсуждение проблемы выявляет их рассуждение.)

Делайте:

• Представьте реалистичные ограничения. (Бюджет лимиты, время в market, размер команды.)
• Тестируйте суждение, не факты. (Могут ли они объяснить, почему Terraform вместо CloudFormation?)
• Записывайте их объяснения. (Асинхронные troubleshooting упражнения не выявляют рассуждение; живые выявляют.)

Найм DevOps в масштабе

Если вы нанимаете 5+ инженеров DevOps, используйте структурированный процесс оценки с этой рубрикой. Создайте шаблон сценариев один раз, переиспользуйте, и сравнивайте результаты по кандидатам. Консистентность улучшает сигнал.

Для более глубоких оценок, специфичных по навыкам, исследуйте AWS vs Azure vs GCP фреймворки тестирования для выявления gap'ов, специфичных облаку.