Постмортемы инцидентов: утечка, зависание, лавина рестартов — и ремесло blameless-разбора

Утечка: RSS растёт 40 МБ/ч, OOMKill каждые ~30 часов

Обнаружение пришло поздно и не с того сигнала: с графика числа рестартов, а не с алерта по памяти. Паттерн, называющий класс бага: RSS растёт линейно с трафиком, без плато, до лимита контейнера. Линейный-с-трафиком рост означает накопление живых ссылок на каждый запрос — фрагментация выходит на плато, мусор собирается; вечно растёт только то, что достижимо.

Корневая причина: @lru_cache(maxsize=None) на функции прайсинга, в чьи аргументы входил кортеж фильтров запроса. Почти уникальные ключи на запрос — кеш почти никогда не попадал, только рос. Воркер живёт неделями; ничто не вытесняет; gc бессилен, потому что каждая запись сильно ссылается по дизайну. Инструмент доказательства — tracemalloc: снапшоты в двух точках времени, diff по строкам:

import tracemalloc
tracemalloc.start(25)                  # хранить 25 кадров на аллокацию

snap1 = tracemalloc.take_snapshot()    # час 1 — триггер через админ-эндпоинт
# ... проходят часы ...
snap2 = tracemalloc.take_snapshot()    # час 5
for stat in snap2.compare_to(snap1, "lineno")[:5]:
    print(stat)
# pricing/cache.py:41: size=2.9 GiB (+2.7 GiB), count=38M (+36M)
#   словарь lru_cache — ключ (user_id, query, tuple(filters))

Смягчение против предотвращения: рециклинг max_requests останавливает OOMKill-ы уже сегодня — честно подписанный костыль. Предотвращение структурно: ограниченные кеши (maxsize= число, которое вы можете защитить, или TTL-кеш там, где допустима несвежесть), алерт RSS-на-воркер, срабатывающий на тренд (40 МБ/ч в течение 3 часов), а не на обрыв, и правило ревью: maxsize=None плюс ключи формы запроса не проходит никогда.

Зависание: все async-воркеры заморожены, CPU около нуля

Обнаружение: p99 уходит вертикально, каждый запрос таймаутится, и контринтуитивный сигнал — CPU около нуля. Крутящийся цикл жёг бы CPU; замороженный — припаркован в сисколле. Инструмент, превращающий это из спекуляции в улику, — py-spy dump: он подключается к живому pid без рестарта и без инструментирования:

$ py-spy dump --pid 1
Thread 0x7F4A (active): "MainThread"
    recv (ssl.py:1233)
    ...
    get (requests/api.py:73)
    fetch_rates (helpers/fx.py:12)      # тремя слоями хелперов ниже
    convert (handlers/checkout.py:88)   # async def — но блокируется прямо здесь

Корневая причина: синхронный requests.get вкрался в async-обработчик за тремя слоями хелперов — автор fetch_rates ни разу не видел async def в своём файле. Цикл кооперативен и однопоточен: блокирующий сисколл никогда не уступает планировщику, поэтому каждая корутина этого воркера — сотни в полёте — ждёт вместе с ним (правило мостов python/11, теперь в виде аварии). Каждый воркер, задевший этот путь, замерзает так же; флот умирает воркер за воркером по мере того, как трафик находит маршрут.

Предотвращение: lint/import-правило, запрещающее синхронные HTTP-клиенты (requests, голый urllib3) в async-модулях — закреплённое в CI, а не в памяти ревьюеров; запасной выход await asyncio.to_thread(...) там, где синхронная библиотека неизбежна; async-нативный клиент (httpx) как дефолт; и нагрузочный тест, дёргающий медленный upstream, потому что на p50 этот баг невидим.

Лавина рестартов: здоровый бинарь, полный отказ

Цепочка причины: релиз добавил двухминутную загрузку ML-модели на старте. Liveness-проба — initialDelaySeconds: 30 — начинала падать до конца загрузки; Kubernetes убивал под посреди загрузки; замена начинала ту же двухминутную загрузку; снова убита. CrashLoopBackOff (состояние Kubernetes, когда под перезапускается снова и снова с экспоненциальной выдержкой) по всему флоту — от бинаря без единого бага. У обнаружения сигнатура, которую стоит запомнить: циклы рестартов с чистыми логами — ни трейсбека, ни ошибки: процесс убили, он не падал, — плюс события отказов проб в kubectl describe.

Предотвращение: startup-проба — liveness приостановлена, пока она не пройдёт; она существует ровно для медленно стартующих приложений; ленивая или фоновая загрузка модели с выключенным readiness до прогрева (трафик ждёт, никто не умирает); и бюджет времени старта, проверяемый в CI — тест, валящий сборку, когда старт переходит N секунд, потому что регрессии времени загрузки приходят тихо, по одной зависимости за раз.

Ремесло: как пишется постмортем

У трёх инцидентов общий скелет, и скелет — это и есть ремесло. Таймлайн с таймстемпами — когда началось, когда обнаружили, когда смягчили; разрыв обнаружения (шесть недель у утечки) — сам по себе вывод. Blameless — не вежливость, а качество данных: инженер, переключивший флаг, расскажет, как всё было, только если документ нельзя использовать против него. Пять «почему», нацеленных на систему: не «почему инженер добавил lru_cache», а «почему наше ревью, наши алерты и наши лимиты все вместе позволили неограниченному росту уехать в прод и работать шесть недель». Action items — это изменения кода или конфига с владельцами и сроками: заведённый алерт, добавленная проба, влитое lint-правило. «Быть внимательнее» не встречается ни в одном компетентном постмортеме; если человеческая оплошность вызывает отказ — система уже была сломана.