Real-Time Backend
Chaos Engineering
Сервис упал в пятницу в 18:00. Причина - race condition при network partition, которая не воспроизводится в staging. Netflix решил эту проблему радикально: ломать production каждый день в рабочее время, пока система не научится выживать.
- Netflix Chaos Monkey убивает production EC2-инстансы каждый рабочий день с 2011 года - это привело к созданию Chaos Engineering как дисциплины
- Gremlin показал что 60% компаний находят critical bugs в первые 30 дней chaos engineering - большинство этих багов существовали годами незамеченными
- Amazon ежегодно проводит GameDay - несколько часов управляемого chaos в production, после каждого находят 3-7 серьёзных проблем resilience
Network Partitions: как система ведёт себя при разрыве сети
**Netflix, 2011.** Инженеры намеренно убивали production EC2-инстансы случайным образом в рабочее время. Не в 3 ночи - именно днём, когда команда может быстро реагировать. Это называлось Chaos Monkey. Идея: если система не умеет переживать отказы в контролируемых условиях - она точно упадёт в неконтролируемых.
Network partition - это когда два набора нод не могут общаться друг с другом, но каждый набор работает внутри. Для WebSocket-сервиса это значит: часть пользователей подключена к нодам A-B-C, другая часть к нодам D-E-F, между группами нет связи. Что происходит с групповым чатом?
Gremlin (коммерческий chaos engineering platform) показал: 60% компаний обнаруживают critical bugs в своих системах в первые 30 дней использования chaos engineering. Большинство этих багов существовали годами, но никогда не проявлялись в нормальных условиях.
Почему Netflix запускал Chaos Monkey в рабочее время, а не ночью?
Slow Consumers: когда один клиент тормозит всех
Slow consumer - клиент, который читает сообщения медленнее, чем сервер их отправляет. Буфер отправки заполняется. Если сервер ждёт - блокируется поток, который обслуживает этого клиента. Если на одном потоке 1000 клиентов (Node.js event loop) - один медленный тормозит всех.
Chaos-тест для slow consumers: искусственно задерживаем чтение у тестового клиента на 10 секунд. Проверяем: другие клиенты получают сообщения без задержки, медленный клиент в итоге отключается, память сервера не растёт до OOM.
Discord в 2020 описал в Engineering Blog как медленный Discord overlay (игровой HUD) вызывал memory leak на сервере. Один клиент с включённым overlay накапливал 50MB+ очередь сообщений за час. После добавления MAX_QUEUED_MESSAGES guard - проблема исчезла.
Какое правильное поведение сервера при обнаружении slow consumer?
Node Failures: что теряется при смерти пода
Pod умер. На нём было 50K WebSocket-соединений. Все они рвутся одновременно и идут на reconnect. За 30 секунд 50K клиентов пытаются установить новые соединения на оставшиеся поды. Это thundering herd - стадо слонов врывается в дверь.
Два уровня проблем: **connection** - клиенты reconnect'ятся (решается exponential backoff + jitter) и **state** - что было в памяти мёртвого пода: subscriptions, in-flight сообщения, user presence данные.
Зачем добавляют jitter к exponential backoff при reconnect?
Инструменты: Chaos Monkey, Toxiproxy, Litmus
Chaos engineering - это не случайное ломание всего подряд. Это научный подход: **гипотеза** ("при потере одной ноды p99 latency не превысит 500мс"), **эксперимент** (убиваем ноду), **наблюдение** (метрики), **вывод** (подтверждено или нет).
- **Chaos Monkey** (Netflix OSS) - убивает random EC2/pod в рабочее время. Простейший инструмент, только node failures
- **Toxiproxy** (Shopify) - TCP proxy с настраиваемыми сбоями: latency, jitter, bandwidth limit, connection reset. Идеален для тестирования network conditions
- **Chaos Mesh / Litmus** (K8s-native) - pod kill, network chaos, CPU/memory stress, clock skew, IO errors через CRD
- **Gremlin** (commercial) - управляемый chaos с rollback, шаблонами атак, integration с PagerDuty
Amazon проводит ежегодный GameDay - несколько часов специально организованного chaos в production с командой наготове. После каждого GameDay находят 3-7 серьёзных проблем resilience. AWS называет это "building confidence through failure".
Chaos engineering - это про намеренное ломание всего подряд чтобы проверить что выживет
Chaos engineering - это научный метод: гипотеза -> контролируемый эксперимент -> измерение -> вывод о resilience
Без чёткой гипотезы невозможно понять что именно проверяется и что именно ломается. Настоящий chaos experiment сначала определяет ожидаемое поведение системы, потом проверяет соответствует ли реальность ожиданиям.
Какой правильный подход к проведению chaos эксперимента?
Итоги
- Chaos engineering - это научный метод: гипотеза, эксперимент, метрики, вывод - не случайное ломание
- Slow consumers защищаются ограниченной очередью и отключением при переполнении - иначе memory leak
- Reconnect storm при падении пода гасится exponential backoff + jitter на клиенте
- Toxiproxy и Chaos Mesh позволяют вводить network partitions, latency и CPU stress в контролируемых условиях
Связанные темы
Chaos engineering проверяет resilience механизмы, построенные в других частях системы
- Circuit Breaker — Chaos эксперименты проверяют что circuit breaker действительно срабатывает при нужных условиях
- Distributed Tracing — Трейсы позволяют понять что происходит с запросами во время chaos эксперимента
- Graceful Deployment — Node failure - это частный случай graceful shutdown; reconnect storm - тест для connection draining
- Feature Flags — Feature flags позволяют безопасно включать chaos experiments для части трафика
Вопросы для размышления
- Как определить blast radius для chaos эксперимента - какой процент пользователей может быть затронут при безопасном тесте?
- Что является steady state для WebSocket-сервиса и какие метрики нужно измерять до и после chaos?
- Как организовать автоматический rollback chaos эксперимента если метрики вышли за пределы допустимого?