ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Написать postmortem для cache stampede

1. Цель задачи

Научиться системно анализировать инциденты, вызванные cache stampede (лавинообразное обращение к источнику данных при истечении кэша). Вы научитесь читать Redis-логи и клиентские логи, выявлять корневую причину stampede, предлагать инженерные меры для предотвращения повторения и оформлять структурированный postmortem (посмертный анализ) по стандарту.

Ключевой результат Документ postmortem, который однозначно идентифицирует механизм stampede, содержит таймлайн, найденную root cause и конкретные action items, после выполнения которых инцидент гарантированно не повторяется.

2. Исходные данные

Перед началом необходимо иметь:

Если нет реального инцидента — симулируем:

1. Разверните простой веб-сервис (Flask/FastAPI) с ручкой, которая возвращает данные, закэшированные в Redis (TTL = 30 секунд).
2. Напишите скрипт нагрузки (locust или ab), который одновременно отправляет 100 запросов сразу после истечения кэша.
3. Зафиксируйте состояние: в момент stampede backend перегружен (latency > 5 с, ошибки 5xx).
4. Соберите логи Redis (SLOWLOG GET 100), клиентские логи (вывод утилиты ab или locust), метрики CPU/память.

3. Технологический стек

4. Этапы выполнения

Этап 1: Обнаружение и первичная диагностика (15–30 минут)

Действия

1. Зафиксируйте временные границы инцидента

   • Время начала: когда первый клиент получил 5xx или latency > 1 с.
   • Время окончания: когда метрики вернулись к baseline (или момент вмешательства администратора).
   • Используйте дашборд Grafana: графики redis_hits, redis_misses, backend_latency, error_rate.

2. Соберите первичные данные

   • Сравните метрики за 1 час до и во время инцидента.
   • Определите масштаб: % запросов, затронутых ошибками, рост latency (например, p99 с 50 мс до 5 с).
   • Запишите ключевые значения:

     before:   hit_rate=0.95, p99_latency=55ms
     during:   hit_rate=0.10, p99_latency=4.8s
     

3. Проверьте очевидные триггеры

   • Менялся ли TTL кэша за последние 24 часа? (git log)
   • Были ли релизы backend-сервиса?
   • Были ли изменения в Redis-конфигурации (maxmemory, eviction policy)?

Ожидаемый результат этапа
Заполненный раздел «Обнаружение» в postmortem (время, масштаб, гипотеза: «возможен cache stampede»).

Этап 2: Глубокий анализ (1–2 часа)

Действия

Ключевые вопросы для анализа

1. Было ли резкое падение hit rate одновременно с истечением TTL?
2. Увеличилось ли количество одновременных запросов к backend (miss) в разы?
3. Есть ли в коде логика «lock around regeneration» (например, SET NX)?
4. Повторялся ли паттерн в прошлые недели? (смотреть по графикам)

Действия по поиску root cause

• Откройте Redis slowlog: SLOWLOG GET 100 — ищите команды GET/SET с длительностью > 100 мс.
• По логам клиента найдите таймстемпы, когда несколько потоков одновременно начали запрос к одному и тому же кэш-ключу.
• Проверьте, не было ли в момент stampede переполнения очереди событий в Redis (client output buffer, client list).

Ожидаемый результат этапа
Однозначная root cause: «Cache stampede — отсутствие блокировки при регенерации кэша; после истечения TTL 500 одновременных потоков попытались пересчитать значение, превысив лимит CPU backend-сервиса».

Этап 3: Разработка и внедрение исправления (30–60 минут)

Действия

1. Выберите стратегию

   • Locking (SETNX с TTL на замок) — один поток регенерирует, остальные ждут или получают stale-значение.
   • Soft TTL / stale-while-revalidate — отдаём старое значение, асинхронно обновляем.
   • Probabilistic early recomputation — каждый клиент случайно регенерирует до истечения TTL.

2. Реализуйте прототип исправления (код на Python):

   import redis
   import time
   
   r = redis.Redis()
   LOCK_KEY = "lock:my_data"
   LOCK_TTL = 5  # seconds
   
   def get_or_compute(key, recompute_fn, ttl=30):
       # Пробуем сначала быстрый GET
       value = r.get(key)
       if value is not None:
           return value
   
       # Попытка захватить блокировку
       lock_acquired = r.set(LOCK_KEY, "locked", nx=True, ex=LOCK_TTL)
       if lock_acquired:
           try:
               value = recompute_fn()
               r.setex(key, ttl, value)
               return value
           finally:
               r.delete(LOCK_KEY)
       else:
           # Ждём короткое время или отдаём stale
           time.sleep(0.1)
           value = r.get(key)
           if value is not None:
               return value
           else:
               # Редкий случай – повторяем логику
               return recompute_fn()
   

3. Проверьте на staging

   • Запустите симуляцию stampede с тем же сценарием.
   • Убедитесь, что hit rate стабилен, backend не перегружен, ошибок нет.

4. Примените исправление на production (если не было отката).

Ожидаемый результат этапа
Инцидент устранён, метрики вернулись к baseline, код исправления закоммичен в репозиторий.

Этап 4: Написание postmortem (1–2 часа)

Структура postmortem (обязательные разделы):

# POSTMORTEM: Cache Stampede in [Service Name]

## Информация об инциденте
- ID инцидента PM-YYYY-MM-DD-099
- Дата и время 2025-03-16 14:30 UTC
- Длительность 18 минут
- [[Вики/severity|Severity]] P1 (высокое влияние на пользователей)
- Автор [Имя]

## Executive Summary
[2-3 предложения: что произошло, какое влияние, что сделали]

## Влияние на пользователей
- Затронуто X% запросов (p99 latency вырос с 55 мс до 4.8 с)
- Уровень ошибок: 12% запросов вернули 5xx
- Жалобы пользователей: зафиксированы в канале #support

## Таймлайн инцидента
| Время (UTC) | Событие |
|-------------|---------|
| 14:30 | Baseline: hit rate 0.95, p99 latency 55ms |
| 14:31 | Redis miss rate резко вырос до 0.9 |
| 14:32 | Backend CPU 100%, начались ошибки 5xx |
| 14:35 | Команда оповещена (PagerDuty) |
| 14:40 | Обнаружен cache stampede, начат откат TTL |
| 14:45 | Включён флаг «stale-while-revalidate» |
| 14:48 | Метрики восстановлены |

## Root Cause
Cache stampede, вызванный отсутствием блокировки при регенерации кэша. TTL был уменьшен с 300 до 30 секунд предыдущим релизом. При истечении ~10 ключей одновременно более 500 concurrent запросов устремились в backend.

## Action Items
| # | Действие | Ответственный | Статус |
|---|----------|---------------|--------|
| 1 | Добавить SETNX блокировку в метод get_or_compute | [dev] | Done |
| 2 | Настроить мониторинг на резкий рост redis miss rate | [ops] | In progress |
| 3 | Обновить runbook по cache stampede | [SRE] | Pending |
| 4 | Установить TTL для всех ключей не менее 60 с (кроме горячих) | [dev] | Pending |

## Уроки
- Всегда проверять влияние изменения TTL под нагрузкой.
- Автоматические блокировки должны быть реализованы до деплоя.

Ожидаемый результат этапа
Готовый markdown-файл postmortem, удовлетворяющий всем обязательным разделам.

Этап 5: Проверка и доработка postmortem (30 минут)

Действия

1. Вычитайте документ на предмет:

   • Все ли факты подтверждены логами и метриками?
   • Не пропущен ли шаг в таймлайне?
   • Action items измеримы (deadline, owner)?

2. Убедитесь, что action item #1 (блокировка) прошёл QA — протестирован под нагрузкой, не внёс регрессий.

3. Проверьте, что postmortem добавлен в базу знаний (Git, Obsidian).

Ожидаемый результат этапа
Финальная версия postmortem, готовая к ревью команды.

5. Критерии приемки (Definition of Done)

• Postmortem содержит все обязательные разделы: Executive Summary, Timeline, Root Cause, Impact, Action Items, Lessons Learned.
• Root Cause однозначно идентифицирована (cache stampede) и подтверждена логами (Redis slowlog, клиентские таймстемпы).
• В документе приведены графики метрик (hit rate, latency, CPU) до, во время и после инцидента.
• Таймлайн полный (от нормальной работы до восстановления).
• Каждый action item имеет ответственного и установленный дедлайн.
• Исправление (блокировка или stale-while-revalidate) реализовано в коде и проверено под нагрузкой на staging.
• Метрики после фикса стабильны: hit rate > 0.9, p99 latency < 100 мс под той же нагрузкой.
• Документ выложен в базу знаний и доступен всей команде.

6. Ожидаемый результат

1. Основной артефакт Файл postmortem-cache-stampede-2025-03-16.md в Markdown со структурой, описанной в Этапе 4.
2. Дополнительно (опционально):
   • График метрик (скриншот Grafana или PNG), приложенный к postmortem.
   • Pull Request с кодом исправления (блокировка) в репозиторий сервиса.
   • Runbook для реагирования на cache stampede.

7. Возможные сложности и их решение

8. Бюджет времени (оценка)

Примечание Для первого раза рекомендуется заложить 6 часов, включая время на симуляцию инцидента (если нет реального).

9. Связанные вопросы из базы знаний

10. Чек-лист самопроверки

• Я проверил, что все технические термины (cache stampede, SETNX, TTL) объяснены или использованы корректно.
• Я удостоверился, что в postmortem есть реальные численные метрики (hit rate, latency, error rate), а не только качественные описания.
• Я перепроверил, что action items измеримы и имеют ответственных.
• Я сравнил итоговый документ с примерами postmortem из базы знаний (например, вопрос 522).
• Я убедился, что код исправления протестирован под нагрузкой и не вносит регрессий для других кэш-ключей.