Начинаем с инженерного расследования: почему пользователь видит ошибку, где искать источник деградации и как по метрикам отличить частичный отказ от каскадного

Теория:

• архитектура учебного Go-стенда в Kubernetes: gateway, несколько микросервисов, БД, брокер или кэш;
• надежность vs отказоустойчивость, graceful degradation, blast radius, MTBF и MTTR;
• partial failure, cascading failure, transient, permanent и intermittent failures;
• почему сеть ненадежна: timeout, потерянный ответ, частичный успех и отсутствие глобального времени;
• SLI / SLO / SLA: availability, error rate, latency p95/p99, saturation и request rate;
• почему средняя latency обманывает и как читать пользовательскую деградацию по p95/p99.

Практика:

• в k8s-стенде включаем fault-сценарии: сломанный pod, медленный downstream, временно недоступную БД и lag в асинхронной обработке
• работаем с Grafana / Prometheus, kubectl, логами и incident card.

----------------------

Результат:

• умеешь начать расследование: найти симптом, определить пострадавший SLI, оценить радиус поражения и выбрать первую безопасную реакцию

Retry и Circuit Breaker — это база. Но сначала сервис должен правильно стартовать, попадать в балансировку, переживать rolling update и корректно завершать in-flight запросы

Теория:

• pod lifecycle в Kubernetes: старт контейнера, регистрация endpoint, service routing и удаление pod из трафика;
• startupProbe, readinessProbe, livenessProbe: назначение, различия и типичные ошибки;
• почему liveness не должна проверять внешнюю БД, брокер или соседний сервис;
• safe rolling update: maxUnavailable, maxSurge, capacity во время деплоя и rollback;
• SIGTERM, preStop, terminationGracePeriodSeconds, drain in-flight requests и закрытие соединений;
• метрики деплоя: 5xx rate, p95/p99 latency, pod restarts, ready pods, in-flight requests и rollout duration.

Практика:

• запускаем k6;
• выкатываем плохую версию и видим 5xx/timeout в Grafana;
• исправляем probes, graceful shutdown и rolling update;
• повторяем rollout и сравниваем показатели до/после.

----------------------

Результат:

• понимаешь, как доказать метриками, что сервис переживает деплой без пользовательских ошибок и не усиливает инцидент перезапусками

Retry действительно помогают при временных сбоях, но без бюджета, backoff, jitter и идемпотентности они превращаются в усилитель аварии. В этом уроке учимся писать безопасную повторную обработку

Теория:

• когда retry уместен, а когда он только ухудшает ситуацию;
• fixed, linear, exponential backoff и exponential backoff with jitter;
• синхронизация клиентов, retry amplification и восстановление после даунтайма;
• retry budget и retry circuit breaker как ограничители дополнительной нагрузки;
• Idempotency-Key, хранение результата, TTL ключей и защита от повторного списания денег;
• fingerprint / versioning для синхронизации клиента и сервера после потери ответа.

Практика:

• добавляем retry budget и идемпотентность в API создания заказа

----------------------

Результат:

• умеешь писать повторные попытки, которые не создают лавину трафика и не дублируют бизнес-операции

Разбираемся, когда ждать, отменять, размыкать цепь, и как сохранить пользовательский сценарий через деградацию

Теория:

• ail latency, p95/p99 и hedging requests для борьбы со случайными задержками;
• риски hedging: дополнительная нагрузка, отмена дублей, приоритет hedge-запросов;
• connection timeout, request timeout и выбор порогов по latency-метрикам;
• timeout propagation и deadline в цепочке вызовов HTTP/gRPC;
• circuit breaker: состояния closed / open / half-open, сбор статистики, поколения и настройка порогов;
• fallback, cached fallback, stub response, feature flag degradation и частичная функциональность;
• runtime feature flags через etcd: локальный snapshot, watch-обновления, kill switch и безопасный fallback при недоступности config storage.

Практика:

• внедряем timeout propagation, circuit breaker и degraded response между сервисами

----------------------


Результат:

• можешь спроектировать синхронный вызов так, чтобы зависший downstream не забирал всю систему за собой

Защищаем ресурсы до того, как сервис начнет падать: отделяем критичные участки, ограничиваем входящий / исходящий трафик и учимся честно отвечать клиенту при исчерпанной квоте

Теория:

• bulkhead: isolation, limitation, reservation и защита от resource starvation;
• goroutine / worker pool, semaphore, HTTP connection pool и database connection pool;
• process / container bulkhead, sidecar, физическую изоляцию и Kubernetes requests / limits;
• client-side, server-side и distributed rate limiter;
• token bucket, leaky bucket, fixed window и sliding window counter;
• 429, Retry-After, X-RateLimit headers, мониторинг лимитов и риски SPOF в distributed limiter;
• где ставить лимит: приложение, SDK, sidecar, gateway, ingress или балансировщик.

Практика:

• реализуем rate limiter и проверяем его поведение под стресс-нагрузкой

----------------------


Результат:

• умеешь ограничивать blast radius медленной ручки, noisy neighbor и внезапной волны трафика

Когда система уже близка к перегрузке, простой лимит RPS не спасает. Учимся управлять очередями, latency, приоритетами и сознательно отбрасывать лишнее ради выживания ядра

Теория:

• backpressure: buffering, dropping и control как три стратегии работы с избытком данных;
• разницу backpressure в асинхронной и синхронной моделях;
• TCP sliding window, advertised window, zero window, slow start и Vegas TCP как основу мышления;
• load shedding: simple, partitioned и percentage strategies;
• разницу rate limiter и load shedder: квоты против текущего состояния системы;
• выбор лимита через latency, очередь, CPU, errors и закон Литтла;
• адаптивное окно обработки и агрессивное снижение нагрузки при timeout / reject.

Практика:

• внедряем load shedding middleware и наблюдаем пределы сервиса на нагрузке

----------------------


Результат:

• понимаешь, когда лучше отказать части запросов, чем позволить очереди разрушить весь сервис

Разбираемся, где появляется порядок, как масштабируются consumer groups и почему offset является состоянием обработки

Теория:

• Kafka как распределенный лог: brokers, topics, partitions, records и keys;
• порядок сообщений внутри партиции и выбор key для сущности;
• producer: partitioning, acks=0/1/all, min.insync.replicas, retries и enable. idempotence;
• consumer groups, rebalance, current offset, committed offset и current position;
• __consumer_offsets, group coordinator и log compaction;
• auto-commit, manual commit, sync / async commit и их влияние на потери / дубли;
• at-most-once, at-least-once, exactly-once и почему «ровно один раз» требует оговорок.

Практика:

• настраиваем producer / consumer и проверяем сценарии потерь и дублей

----------------------


Результат:

• понимаешь, какие гарантии Kafka дает сама, а какие обязан обеспечить твой код

Разбираемся, как не потерять событие между БД и Kafka, как пережить дубли, что делать с poison messages и когда inbox важнее простой производительности

Теория:

• почему запись в БД и отправка в Kafka не являются одной транзакцией;
• transactional outbox: сущность + событие в одной транзакции и relay-процесс;
• consumer idempotency, message_id, order_id, event_type и created_at;
• consumer group lag, partition skew и причины роста отставания;
• transient, permanent и poison messages;
• retry topics, backoff-цепочки, metadata сообщения, retry amplification и DLQ;
• нарушение порядка при retry topics и inbox-паттерн для контроля обработки.

Практика:

• внедряем outbox, обработку дублей, retry topic, DLQ и inbox

----------------------


Результат:

• умеешь проектировать обработку сообщений так, чтобы дубли и ошибки были штатной ситуацией, а не аварией

Кэш ускоряет систему, но легко начинает отдавать старые данные. Разбираем согласованность, инвалидацию и конкурентные обновления до того, как кэш станет источником инцидентов

Теория:

• почему возникают stale data: batch refresh, partial failures, race condition и async replication;
• TTL-based approach: когда он подходит и где не дает гарантий актуальности;
• cache-aside, write-around, write-through и компромисс latency/consistency;
• синхронную инвалидацию и событийную инвалидацию через broker, invalidator, CDC и outbox;
• lost update и конкурентную модификацию данных в Redis;
• explicit lock, optimistic lock, Redis WATCH/MULTI/EXEC, CAS и version tokens;
• как выбрать подход по уровню конкуренции, цене stale data и профилю записи.

Практика:

• исправляем race condition и строим безопасную инвалидацию

----------------------


Результат:

• можешь выбрать стратегию кэша не только по скорости, но и по допустимой рассинхронизации данных

Урок про обратную сторону кэша: горячие ключи, лавину miss, падение Redis, cross-shard запросы и политики вытеснения, которые могут спасти или добить систему.

Теория:

• thundering herd и single flight как «склейка» одинаковых запросов;
• soft TTL, hard TTL, фоновые обновления и graceful cache fallback;
• negative cache: какие ошибки можно кэшировать, а какие опасно;
• cache avalanche, random TTL, jitter и proactive warmup;
• L1/L2 cache, горячие ключи и Redis sharding/hash slots;
• cross-DC и cross-shard latency, топологию Redis Cluster и локальность данных;
• noeviction, allkeys-lru, volatile-lru, allkeys-lfu, random, volatile-ttl и Redis-метрики.

Практика:

• реализуем single flight, jitter, multi-level cache и мониторинг hit / miss

----------------------


Результат:

• умеешь проектировать кэш-слой, который снижает нагрузку на источник, а не становится новым SPOF

Собираем наблюдаемость для диагностики и принятия решений: какие SLI выбрать, как связать SLO с бизнесом и какие алерты действительно будят инженера по делу

Теория:

• observability vs monitoring: метрики, логи, трейсы;
• SLI, SLO, SLA, error budget, burn rate и связь надежности с бизнес-операциями;
• Golden Signals, RED и USE для HTTP API / Go-сервисов / БД / Kafka / Redis и Kubernetes workload;
• Service Overview dashboard: RPS, 2xx / 4xx / 5xx, p50 / p95 / p99 latency, in-flight requests и dependency latency;
• Business SLO dashboard: успешные операции, failed operations, SLO compliance и error budget remaining;
• Kubernetes и Async dashboards: ready replicas, restarts, OOMKilled, rollout duration, Kafka lag, produce/consume rate и DLQ;
• runtime config dashboard: состояние feature flags из etcd, включенные деградации, время последнего изменения и влияние на SLO;
• хорошие и плохие алерты: actionable alerts, alert fatigue, runbook link и маршрутизация по владельцам.

Практика:

• собираем в Grafana все необходимые дашборды
• настраиваем HighErrorRate, HighLatency, ErrorBudgetBurn, NoReadyPods, RestartLoop, KafkaConsumerLagGrowing и DependencyLatencyHigh в Prometheus и Alertmanager

----------------------


Результат:

• можешь собрать минимальный production-grade набор дашбордов и алертов, которые помогают чинить инциденты

Практическая игра-симмуляция с упавшим продом. Система деградирует, алерты срабатывают. Мы — расследуем и принимаем решения

Теория:

• incident lifecycle: detect, triage, mitigate, rollback / degrade, close, postmortem;
• роли на инциденте: Incident Commander, Tech Lead, Scribe, Communications и владелец сервиса;
• severity levels, user impact, первые 5 минут, war room и правила коммуникации;
• safe delivery: canary, blue / green, feature flags на etcd, health-based rollout и rollback strategy;
• GameDay-сценарии: bad release, dependency degradation, Kafka lag incident и ошибка rollout capacity;
• инструменты: kubectl rollout status, kubectl rollout undo, kubectl describe, kubectl logs, k9s, stern, Grafana, Alertmanager и k6;
• runbook и blameless postmortem: timeline, root cause, what went well / wrong, action items и владельцы задач.

Практика:

• выкатываем плохую версию под нагрузкой
• ловим алерт
• анализируем дашборды
• включаем kill switch / degraded mode через etcd
• выбираем rollback / scale / cordon
• фиксируем timeline и собираем incident report + runbook

----------------------


Результат:

• проходишь полный цикл аварии: от первого алерта и оценки user impact до mitigation, rollback и postmortem

Если темы из программы для тебя новые или хочется освежить знания — you are welcome

В любой IT-компании без исключения либо отказывает какой-то сервис, либо падает вся система. Даже в BigTech

В командах с десятками или сотнями разработчиков каждый имеет свой уровень, и каждый допускает ошибки в коде. Любой инцидент начинается с этого. Рано или поздно он происходит, и с этим сталкивается любой Junior или Middle. Вопрос только в том, когда именно это случится

Даже если ты только начинаешь писать на Go, и тебя эта проблема не коснулась — с ростом грейда и ответственности ты с этим столкнешься. И блок-фактор твоего роста — умение строить отказоустойчивые системы и «тушить пожары» без помощи старших коллег.

Когда ты самостоятелен (-на), к тебе больше доверия, тебя сильнее ценят, и тебя готовы повышать. Особенно, когда один и тот же сервис постоянно падает, а ты наконец-то починил (-а) его раз и навсегда