🚨 Надёжность и инцидент-менеджмент

Короткий ответ Capacity planning — это прогнозирование будущей нагрузки и заблаговременное выделение (или заказ) достаточных вычислительных ресурсов, чтобы система не упиралась в лимиты CPU, памяти, диска, сети или пропускной способности базы данных в самый неподходящий момент. Как это работает подробнее на основе исторических трендов роста нагрузки (пользователи, запросы в секунду, объём данных) и известных будущих событий (маркетинговая акция, сезонный пик) оценивают, сколько ресурсов понадобится, и сравнивают с текущими лимитами (квоты облачного провайдера, количество узлов, размер дисков). Пример / кейс Ожидаемое поведение: заранее поданная заявка на увеличение квоты облачного провайдера и нагрузочное тестирование до пикового события предотвращают ситуацию, когда автомасштабирование упирается в лимит квоты прямо во время распродажи. Пример кода Что использовать на практике Практический подход. Capacity planning включает и "железные" ограничения (лимиты API облака на создание инстансов, лид-тайм закупки об

Читать полностьюautoscaling

Короткий ответ Резерв capacity должен учитывать не только прогнозируемый органический рост нагрузки, но и запас для устойчивости к отказам (N+1 или N+2 — способность выдержать потерю одной или нескольких зон/узлов без деградации), время, необходимое на масштабирование (lead time автомасштабирования или закупки), и сезонные/маркетинговые пики, которые не отражены в среднем тренде роста. Как это работает подробнее если вся текущая capacity рассчитана ровно под текущий пик без резерва, то отказ даже одного узла/зоны доступности означает, что оставшиеся ресурсы не смогут обслужить нагрузку, и автомасштабирование может не успеть среагировать достаточно быстро (особенно если новые инстансы требуют время на прогрев/инициализацию). Резерв N+1 означает, что система рассчитана на нормальную работу даже при потере одной единицы резервирования (узла, зоны, инстанса). Пример / кейс Ожидаемое поведение: при отказе одной из трёх зон оставшиеся две зоны (каждая рассчитана на 1500 RPS) покрывают весь трафик 3000 RPS без превы

Читать полностьюcapacity-planning

Короткий ответ Нагрузочное тестирование должно моделировать ожидаемый пиковый профиль трафика (не просто "побольше запросов"), включать плавное нарастание и удержание пика, а критериями готовности служат не просто "держит RPS", а latency по перцентилям, доля ошибок и поведение при частичном отказе зависимостей под той же нагрузкой. Как это работает подробнее сначала оценивают ожидаемый пик (на основе прошлых данных + множителя роста из capacity planning), воспроизводят реалистичный микс запросов (не только GET главной страницы, а реальное распределение эндпоинтов — поиск, добавление в корзину, оплата), и постепенно увеличивают нагрузку, наблюдая за поведением системы, а не только фиксируя "максимальный RPS до падения". Пример / кейс Ожидаемое поведение: если во время теста p99 latency превышает 800 мс уже при 3000 RPS, это сигнал, что система не готова к заявленному пику 5000 RPS, и нужны доработки (масштабирование, оптимизация запросов) до реальной распродажи, а не во время неё. Пример кода Что использовать

Читать полностьюload-testing

Короткий ответ Полные бэкапы 2 ТБ каждые 5 минут нереалистичны; нужна комбинация редких полных бэкапов (например, ежедневных), инкрементальных/дифференциальных бэкапов и непрерывного журналирования транзакций (WAL/binlog) с архивированием, что позволяет сделать point-in-time recovery с точностью до нескольких минут. Как это работает подробнее полный бэкап фиксирует состояние на момент снятия и занимает много времени/места при 2 ТБ; журнал транзакций (write-ahead log) непрерывно записывает каждое изменение и может архивироваться каждые несколько минут или потоково передаваться. Восстановление происходит так: разворачивается последний полный бэкап, затем поверх накатываются инкременты и журнал транзакций до нужной точки времени. Пример / кейс Ожидаемое поведение: `archive_timeout = 300` гарантирует, что даже при низкой нагрузке WAL-файл будет заархивирован не реже чем раз в 5 минут, что совместно с ежедневным полным бэкапом даёт RPO около 5 минут; проверяется через `pg_stat_archiver` и метрику lag архивирования

Читать полностьюbackup

Короткий ответ Нужна многоуровневая политика эскалации с таймаутами подтверждения на каждом уровне (первичный дежурный → резервный дежурный → руководитель команды/следующая команда), автоматическим переходом на следующий уровень при отсутствии подтверждения, и регулярным тестированием самой системы оповещения, а не только документированием схемы. Как это работает подробнее escalation policy определяет цепочку получателей алерта и таймаут на подтверждение (acknowledge) для каждого уровня; если дежурный не подтвердил получение за заданное время (например, 10-15 минут для критичных алертов), система автоматически уведомляет следующий уровень, не дожидаясь, пока кто-то вручную заметит проблему. Пример / кейс Ожидаемое поведение: если первичный дежурный не подтвердил критичный алерт за 10 минут, система автоматически звонит резервному; если и резервный не ответил ещё за 10 минут — эскалирует руководителю с дублирующим каналом связи, гарантируя, что инцидент не останется без внимания дольше 20 минут. Пример кода Чт

Читать полностьюbackup

Короткий ответ Нужно сформулировать конкретную гипотезу об ожидаемом поведении при отказе зависимости, начать эксперимент в тестовой среде или с минимальным blast radius в проде (небольшая доля трафика/инстансов), подготовить мониторинг и немедленный способ остановки эксперимента, и заранее определить критерии успеха/провала. Как это работает подробнее эксперимент моделирует конкретный тип отказа зависимости — не просто "выключить", а реалистичные сценарии: таймаут (зависимость отвечает медленно), ошибки (зависимость отвечает 5xx), полная недоступность (соединение не устанавливается). Для каждого сценария ожидаемое поведение системы может отличаться (например, graceful degradation при таймауте, но полный отказ при недоступности, если fallback не предусмотрен). Пример / кейс Ожидаемое поведение: при инъекции задержки 3с для 5% трафика к auth-service основной сервис должен либо использовать таймаут и fallback (например, разрешить гостевой чекаут), либо корректно показать пользователю ошибку без каскадного паден

Читать полностьюchaos-engineering

Короткий ответ План DR должен включать: заранее реплицированные данные во второй регион с известным RPO, инфраструктуру во втором регионе как код (готовую к развёртыванию или уже развёрнутую в режиме standby), механизм переключения трафика (DNS/балансировщик) и, что важно, регулярно протестированные учения по переключению (DR drill), а не только документ "на бумаге". Как это работает подробнее типичные компоненты — межрегиональная репликация БД (синхронная или асинхронная, в зависимости от допустимого RPO и влияния на latency), инфраструктура во втором регионе через Infrastructure as Code (чтобы развернуть идентичное окружение быстро и предсказуемо), и переключение входящего трафика через изменение DNS-записей или глобального балансировщика с учётом TTL записей (который влияет на реальное RTO). Пример / кейс Ожидаемое поведение: регулярные drill должны либо подтверждать, что реальное время переключения укладывается в целевое RTO, либо выявлять конкретные блокеры (устаревшие секреты, забытые зависимости) до то

Читать полностьюdisaster-recovery

Короткий ответ Hot-резерв — это заранее запущенная и постоянно синхронизированная копия системы, готовая принять трафик почти немедленно; cold-резерв — это инфраструктура или данные, которые нужно развернуть/восстановить при наступлении сбоя, что занимает заметно больше времени. Как это работает подробнее hot-резерв (например, реплика БД в другом регионе с непрерывной репликацией и балансировщиком, готовым переключить трафик) обеспечивает низкое RTO, но стоит дороже, так как ресурсы простаивают в ожидании. Cold-резерв (например, образ инфраструктуры и бэкапы данных, которые разворачиваются по требованию) дешевле, но RTO измеряется часами, а не минутами. Пример / кейс Платёжный сервис использует hot-резерв (реплика БД + активный standby-инстанс в другом регионе), а внутренний аналитический дашборд — cold-резерв (ежедневный бэкап, разворачивается вручную за несколько часов при необходимости). Ожидаемое поведение: при отказе основного региона платёжный сервис переключается на standby за секунды/минуты, тогда как

Читать полностьюbackup

Короткий ответ Однозначно правильного ответа нет: полный freeze снижает риск нового инцидента от релиза именно в критичный момент, но полностью останавливает возможность быстро исправить баг, найденный во время самой кампании, и может маскировать более глубокую проблему — отсутствие уверенности в безопасности собственного процесса релизов; альтернативой может быть не полный freeze, а усиленный процесс (canary, обязательный review, более конкретные критерии) без полной остановки. Как это работает подробнее полный freeze релизов — грубый, но простой и предсказуемый инструмент снижения риска, который легко коммуницировать всей организации ("ничего не трогаем на время кампании"); однако он не отличает безопасные изменения (например, конфигурационный фикс с низким риском) от рискованных (миграция схемы БД), и не даёт механизма для экстренного исправления critical bug, найденного именно во время замороженного периода, кроме как через "экстренное исключение", которое на практике часто становится лазейкой, обесценива

Читать полностьюdata-integrity