Неделя 1. Ключевые проблемы и принципы отказоустойчивости
Особенности распределенных информационных систем:
- Отказоустойчивость & Надежность
- Каскадные сбои
- CAP-теорема (Consistency, Availability, Partition Tolerance)
- Классификация проблем и типы частичных отказов
- SLA (Service Level Agreement)
- SLO (Service Level Objective)
- SLI (Service Level Indicator)
- Что такое «99,9%» доступности и для чего это нужно?
- Понятие целостности и угрозы ее потери
- Идемпотентность
- Split-brain & Failover
- Кворумная запись/чтение
- Разберем:
- что такое WAL и зачем он нужен Postgres
- почему важен replica factor > 1 в Kafka
- Как ЮKassa обрабатывает дубликаты платежей
- GitHub — как все упало на сутки
- AWS us-east-1 — как пострадали сотни онлайн-сервисов по всему миру
- Facebook, Instagram, WhatsApp — как отказ системы обрушил цену акции и привел к потере $6 млрд
- GitLab — как легла БД и удалился пользовательский код
- Случаи из личной практики в production
- понимаешь суть и последствия отказоустойчивости, как свойства системы
- можешь выделить 2 из 3 свойств CAP-теоремы для выбранной системы
- магические девятки в метриках надежности теперь прозрачны и понятны
Функционал работает идеально, и вроде бы всё хорошо. Но что происходит, когда база данных на секунду «ложится»? Или сторонний API начинает отвечать с задержкой в 30 секунд? А если сеть между микросервисами ненадолго пропадает?
В реальном мире такие инциденты неизбежны. И правильная реакция на них — барьер между грейдом middle и senior
Повторная попытка:
- умный retry
- грамотный выбор backoff + jitter
- idempotent requests
- hedging запросов
- timeout, когда дольше уже нельзя
- установка deadline
- cancel propagation при прерывании пути запроса
- circuit breaker для спасения от отказов частей системы
- graceful degradation, когда отказ все же произошел
- fallback по возможности
- внедрим circuit breaker между сервисами
- обеспечим graceful degradation
- применим fallback
- выставим timeout'ы на синхронные вызовы
- реализуем idempotent retry
- Ты на дежурстве, алерты стучатся в дверь, а пользователи недовольны работой системы. Задача — самостоятельно найти инцидент, выбрать нужный паттерн и реализовать его
- умеешь справляться с ошибками и временными сбоями
- глубоко понимаешь суть каждого паттерна и сценария его применения
- умеешь применять это на практике в реальном проекте
Неделя 3. Контроль нагрузки и балансировка
Что делать, если внезапный всплеск трафика, медленный запрос к базе или сбой в соседнем микросервисе роняет прод? В этом модуле учимся делать сервисы стабильными при любой нагрузке
Изоляция ресурсов:
- планирование ресурсов
- подход bulkhead
- процессная изоляция
- физическая изоляция
- глубокое погружение в rate limiting
- single flight как фильтр
- backpressure / load shedding
- клиентская / серверная
- алгоритмы балансировки
- стратегии деплоя и откат
- upstream
- active / passive health checks
- nginx
- настроим балансировку на nginx
- посмотрим на различные алгоритмы балансировки в действии
- применим rate limiter и изучим его вдоль и поперек
- разберем подкапотную магию single flight и применим его как щит
- QA во время стресс-тестов выявил деградацию системы. Найди инцидент, выбери нужный паттерн и реализуй его
- умеешь защищать свои и чужие сервисы в условиях непредусмотренных нагрузок
- понимаешь, как все работает изнутри, и умеешь выделять общие паттерны применения подходов в реальных системах
- разбираешься в подходах к распределению нагрузки
Ты уверен(-а), что твои сообщения доходят? Что заказ не создастся дважды, а платеж не обработается несколько раз?
В этом модуле учимся строить асинхронный отказоустойчивый конвеер — гарантированно доставлять сообщения, легко отрабатывать сбои и бесшовно масштабироваться под нагрузку
Очереди и брокеры сообщений:
- особенности работы с технологиями (Rabbit, Kafka)
- буфферизация и выравнивание нагрузки
- гарантии доставки сообщений
- масштабирование при нагрузке
- распределенные транзакции
- SAGA vs 2PC
- подтверждение от брокера
- умные retry
- идемпотентность
- outbox как лекарство от бед
- offsets и восстановление
- manual vs auto commit
- как обработать дубликаты, будто их нет
- inbox для чайников
- dead letter queue
- как сообщения теряют события без нашего ведома, и как это исправить
- применим outbox pattern
- настроим механизм идемпотентности
- научимся писать DLQ (Dead Letter Queue)
- разберем подходы к реагированию на нештатные ситуации
- понимаешь, на что обращать внимание при проектировании асинхронного взаимодействия
- не теряешь сообщения и умеешь справляться с дубликатами
- умеешь писать паттернами inbox/outbox
- умеешь применять DLQ и работать с ним
- знаешь критически важные метрики и умеешь за нами наблюдать
Добавили кэш, чтобы ускорить систему, а получили лавину запросов к базе в момент его протухания? Пользователи видят устаревшие данные и жалуются? В этом модуле изучаем best practices по использованию кеша
Stale Data (протухшие данные):
- время жизни объектов (ttl)
- активная инвалидация
- событийная инвалидация
- write-thorugh
- управление ttl
- блокировки и версионирование
- Compare and swap (check and set)
- репликация в зоопарке инструментов кеширования
- signle flight
- фоновая актуализация
- soft ttl и мертвые данные
- random ttl & jitter
- многоуровневое кеширование
- проактивное обновление
- лимитирование ресурсов на источник данных
- LRU / LFU / MRU / FIFO / Random
- реализуем кеширование с грамотной стратегией вытеснения
- разберем все проблемы с внедрением кеш-слоя и изучим подходы к их решению
- посмотрим на конфигурацию redis и выберем самые оптимальные параметры
- разберем best practices по эксплуатации кеша
- изучим перечень метрик для мониторинга
- понимаешь, как кеш слой может помочь при высоких нагрузках
- знаешь, какие гарантии отказоустойчивости и проблемы он может принести
- обладаешь необходимыми знаниями для грамотного построения кеш-слоя под любой тип нагрузки системы
Тушишь один инцидент, а на смену приходит следующий. Пользователи видят ошибки раньше, чем срабатывают алерты. Классика
В этом модуле научим систему предупреждать об отказах до удара по пользователю. Узнаешь, как быстро найти и локализовать сбой в синхронных вызовах или в лаге асинхронных очередей, и что делать, когда автоматика уже не справляется
Инциденты для всех:
- централизация разбора нештатных ситуаций
- важность ключевых бизнес метрик
- кто такой координатор?
- при чем тут обслуживание инфраструктуры и почему важно уведомлять о планируемых работах
- что делать, если автоматика не помогла?
- как наказать виновных?
- следим за response time & response codes
- контролируем утилизацию ресурсов
- не забываем про наблюдаемость соседей и внешних инструментов
- важность подробного логгирования
- алерты и их влияние на скорость устранения инцидентов
- метрики обработки топиков (скорость, время, имеющийся лаг на партициях)
- наблюдаемость состояния consumer-групп
- методы борьбы с лагом в неожиданные моменты
- алерты, как средство оперативного реагирования на проблемы с топиками
- ручные манипуляции с оффсетами и консьюмер группами.
- умеешь находить инциденты и отказы и бороться с ними, как это делают в BigTech
- знаешь, на что обращать внимание в первую очередь при возникновении нештатной ситуации
- знаешь, как локализовать отказ при синхронном и асинхронном взаимодействии
- умеешь устранять последствия, инцидент все же произошел