dropprod — interview_prep
interviewer@yandex:~$ describe --experience highload
Расскажите про опыт работы с нагруженными системами...
you@localhost:~$ recall --project distributed-system
Error: No real production experience found
Solution: Run `dropprod --start` to fix this

Получи опыт бигтеха
до того, как туда попадёшь

Симулятор инфраструктуры крупных компаний. Роняй прод, чини инциденты, учись на ошибках — а потом расскажи об этом на собесе.

Начать в Telegram
Знакомая ситуация?

Почему мидлы застревают на пути в бигтех

[ERR_NO_EXP]

Теория без практики

Читал про CAP-теорему, eventual consistency и SAGA. Но никогда не дебажил race condition между 15 микросервисами в проде.

[ERR_NO_SCALE]

Нет опыта с нагрузкой

Твой самый нагруженный сервис обрабатывает 100 RPS. А на собесе спрашивают про 100K RPS и шардирование.

[ERR_NO_INCIDENTS]

Не было серьёзных инцидентов

Тебя спрашивают "расскажите про сложный баг" — а у тебя максимум NullPointerException в логах.

[ERR_REJECTED]

Отказы после system design

Алгоритмы решаешь, а на этапе проектирования систем — "недостаточно глубины в распределённых системах".

Решение

Песочница, где можно всё сломать

01

Полноценная инфраструктура

Kubernetes, Kafka, PostgreSQL, Redis, балансировщики — всё как в настоящем бигтехе. Не схемы на доске, а живая система, которую можно пощупать и сломать.

02

Реальные инциденты

Сценарии из жизни: DC-1, split-brain, каскадные отказы, deadlock'и на проде. То, про что спрашивают на собесах — и чего не получить в обычной компании.

03

Учись на ошибках

Сделал DROP TABLE без WHERE? Отлично, теперь ты знаешь каково это. В DropProd последствия — только опыт и понимание, как не повторить в реальности.

Что внутри

Примеры сценариев

INCIDENT

Каскадный отказ при пике нагрузки

Чёрная пятница, нагрузка x10. Один сервис начал таймаутить, потянул за собой остальные. Найди причину и восстанови систему.

DEBUG

Потерянные сообщения в очереди

Клиенты жалуются, что заказы "теряются". Метрики в норме, логи чистые. Проблема в конкурентном доступе к партициям Kafka.

REFACTOR

Легаси-монолит под нагрузкой

Сервис на 50K строк без тестов. Нужно выделить критичный функционал в отдельный микросервис без даунтайма.

DESIGN

Миграция на новую схему данных

100M записей, нулевой даунтайм, обратная совместимость. Спроектируй и выполни миграцию.

Автор

Кто за этим стоит

>_

15+ лет в бэкенд-разработке

Senior/Lead в крупнейших tech-компаниях России

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

Авито Ozon Mindbox
Для кого

Подойдёт ли тебе DropProd

✓ Подойдёт

  • Мидл или сеньор с 2-6 годами опыта
  • Хочешь в Яндекс, VK, Тинькофф, Авито или аналогичные компании
  • Понимаешь теорию, но не хватает практики с highload
  • Заваливал system design на собесах
  • Работаешь в небольшой компании без сложной инфраструктуры

✗ Не подойдёт

  • Только начинаешь программировать
  • Нужно подтянуть алгоритмы и структуры данных
  • Ищешь базовый курс по бэкенду
  • Уже работаешь в бигтехе 3+ года
Попробуй свои силы

Разбери реальный постмортем прямо сейчас

Получи фидбек от виртуального CTO (на базе опыта из Авито/Ozon) на свои action items

💡 Это учебный кейс из реальной практики

POST-2024-12-15: Payment Service Outage

📅 15 декабря 2024 🔴 Severity: P1 ⏱ Downtime: 47 минут 💸 Loss: ~$84,000

Timeline

14:23

Deploy payment-service v2.8.1 (новая версия с оптимизацией DB queries)

14:35

Алерт: Payment success rate упал с 99.8% до 12%. PagerDuty P1

14:52

Root cause найден: connection pool exhaustion (max 50 → 380 pending)

15:10

Rollback на v2.8.0. Recovery завершён через 8 минут

Root Cause

В новой версии добавили N+1 query в hot path. При нагрузке 1200 RPS каждый запрос открывал 15 дополнительных подключений к PostgreSQL. Connection pool (лимит 50) исчерпался за 3 секунды.

47 min
Downtime
$84K
Revenue Loss
~15,000
Affected Users
100%
Error Rate Peak

Какие action items бы ты предложил?

Напиши конкретные действия для предотвращения подобных инцидентов

Критерии хороших action items:
  • Привязаны к конкретному сбою/причине инцидента, а не к «вообще улучшить».
  • Описывают конкретное изменение в системе, процессе или конфигурации.
  • Есть понятный Definition of Done (DoD), который легко проверить.
  • Снижают риск повторения и/или время обнаружения/восстановления.
0 / 10+ символов
0 / 10+ символов
0 / 10+ символов

Готов уронить свой первый прод?

Начни с бесплатного демо-сценария в Telegram. Сломай что-нибудь — это полезно.

Попробовать бесплатно