Подготовка к интервью

Вопросы на собеседовании в Тинькофф Инвестиции

5 вопросов с собеседований в Тинькофф Инвестиции

5 вопросов 1620 компаний 353 технологии

Что проверяют на интервью

Как устроена подборка

Подборка объединяет вопросы, отмеченные на этапах интервью в Тинькофф Инвестиции. Здесь можно понять структуру технической проверки и заранее повторить связанные темы. В подборке чаще встречаются темы: devops, infrastructure, prometheus.

Каталог

Результаты поиска

Найдено: 5
Теория

Вы используете Terraform для управления облачной инфраструктурой в [облачный провайдер]. Состояние хранится в S3. Оказалось, что два DevOps-инженера одновременно запустили terraform apply и произошёл конфликт в состоянии. Кластер оказался в странном состоянии. Как вы его восстановите и какие процессы введёте, чтобы это не повторилось?

Остановите новые apply, сохраните версии state и сопоставьте фактические ресурсы, конфигурацию и результаты обоих запусков.

Читать ответ
Теория

У вас есть сложная база PostgreSQL с Patroni-кластером. Однажды во время пика нагрузки (15 000 RPS) в одном из приложений начались дедлоки. Откатиться на старую версию схемы нельзя — индекс уже неделю существует в продакшене. Как вы будете интерпретировать логи PostgreSQL, находить проблемный запрос и исправлять проблему без простоя?

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

Читать ответ
Поведенческий

[имя] автоматизировал более 200 метрик в Prometheus, и MTTA снизился с 30 до 5 минут. Как ты избежал alert fatigue? Какой процент срабатываний является настоящими инцидентами и как ты отсекаешь ложные срабатывания на этапе написания правил?

Бороться с alert fatigue нужно через полезность каждого сигнала, а долю настоящих инцидентов считать по фактической истории оповещений.

Читать ответ
System Design

Вы мигрировали инфраструктуру в Kubernetes и развернули Argo CD. Через две недели разработчики начали жаловаться, что не могут быстро откатить изменение, потому что GitOps-модель «слишком медленная». Бизнес требует возможности откатиться за 30 секунд. Как вы архитектурно решите эту проблему, не нарушив GitOps-принцип?

Для быстрого GitOps-отката нужны заранее готовые версии и ускоренный путь изменения желаемого состояния, а не ручное изменение ресурсов в обход Git.

Читать ответ