Архитектурный полигон: инциденты на живом стенде
Практикум трека: не «ещё одна теория», а стенд, который ломается по команде.
Один docker compose up поднимает OrderFlow — API на Go, PostgreSQL с репликой,
PgBouncer, Redis, ClickHouse, Kafka с Debezium, Prometheus, Alertmanager и
Grafana. Дальше каждый модуль — один класс отказов: make fail-N воспроизводит
инцидент, вы находите причину по метрикам и планам запросов, make fix-N
устраняет её, make check-N машинно подтверждает, что система вернулась в SLO.
Зачем это нужно. Теорию по паттернам, брокерам, кэшу и наблюдаемости вы уже прошли в arch v2, pg-clickhouse и go-concurrency. Но навык дежурного — найти и починить под давлением — тренируется только на сломанной системе, где есть логи, метрики и чужая нагрузка. Полигон даёт именно это, не трогая прод.
Формат. Каждый модуль — паспорт инцидента: симптом → метрики → гипотезы → инструменты → решение → защита (что добавить, чтобы не повторилось). Теории — минимум, только про диагностику и регламент; глубина — по ссылкам на модули arch v2, pg-clickhouse, mq-track и go-concurrency.
Что нужно. Docker с Compose v2, ~4 ГБ свободной памяти и свободные порты (8088, 5434/5435, 6432, 6381, 8124, 9094, 9092, 9093, 3001). Go на хосте не нужен — нагрузчик и сервисы живут в контейнерах.
Темп: ~12–16 часов: по 1.5–2 ч на модуль, восьмой — итоговый на 2–3 ч.
Маршрут
| Модуль | Инцидент | Что отрабатываем |
|---|---|---|
| 1. PostgreSQL под нагрузкой | p99 листинга вырос в 10 раз | планы запросов, индексы, пул |
| 2. Лаг реплики | клиент не видит свой заказ | read-your-writes, маршрутизация |
| 3. Пайплайн PG → ClickHouse | дашборд отстаёт и врёт | слот, Debezium, sink, сверка |
| 4. Консьюмеры Kafka | лаг группы растёт при живом API | prefetch, пул воркеров, ack |
| 5. Кэш-шторм | горячий ключ истёк — БД получила залп | cache-aside, singleflight, TTL |
| 6. Алерты | «узнали от клиента, а не от алерта» | золотые сигналы, правило на симптом |
| 7. Отказ зависимости | партнёр повис — API тонет | circuit breaker, bulkhead, деградация |
| 8. «Чёрная пятница» | несколько отказов одновременно | приоритизация, чек-лист дежурного |
Сценарии 1–7 независимы, восьмой собирает их вместе. Стенд восстанавливается
make reset — данные и тома удаляются, следующий make up даёт чистую систему.
Результат курса: вы умеете за минуты сузить инцидент до одного слоя (БД, реплика, пайплайн, кэш, зависимость), читать план запроса и метрики как источник гипотез, чинить причину, а не симптом, и оставлять защиту, которая не даст инциденту повториться.