Постмортемы инцидентов: три продакшен-отказа React под микроскопом

Инцидент 1: цикл рендера, который так и не бросил исключение

Обнаружение. Счётчики длинных задач в RUM выросли в 12 раз после релиза 142; p75 INP роута портфеля ушёл со 180 мс за 2 с; трекер ошибок молчит. Пользователи жаловались на вентиляторы и разряд батареи — каждая открытая вкладка роута выжигала 100% ядра. Ущерб. Шесть часов на полную мощность в ~40 000 открытых вкладок дашборда; INP в полу; порчи данных нет. Корневая причина. Рефакторинг вынес опции отображения в const options = { locale, tz } в теле рендера. Эффект указал её в deps и ставил состояние результатом асинхронной нормализации:

const options = { locale, tz };          // новая идентичность на каждом рендере
useEffect(() => {
  normalize(data, options)               // async — резолвится в следующей задаче
    .then((rows) => setRows(rows));      // setState -> рендер -> новый options -> эффект...
}, [data, options]);

Каждый цикл: рендер собирает свежий options, эффект срабатывает, промис резолвится в следующей задаче, setState планирует рендер — и так вечно. Принципиально: защита React «Maximum update depth exceeded» не сработала: этот счётчик ловит синхронные каскады обновлений — setState прямо в теле эффекта уронил бы всё за 50 итераций, громко и ещё в dev. .then уносил каждый setState в свежую задачу, обнуляя учёт каскада; цикл крутился со скоростью планировщика микрозадач, тихий и вечный. Смягчение. Откат релиза 142; INP восстановился за минуты. Предотвращение. Стабильность deps как правило ревью — deps обязаны быть примитивами или доказуемо стабильными ссылками ([data, locale, tz], а не [data, options]); exhaustive-deps остаётся включённым (он и был включён — он честно перечислил нестабильную dep; не хватало дисциплины стабильности, которую линт проверить не может); и RUM-алерт на число длинных задач по кольцу релиза — сигнал, который инцидент в итоге и поймал.

Инцидент 2: шторм расхождений гидрации

Обнаружение. Трекер ошибок упёрся в rate limit через восемь минут после деплоя: десятки тысяч ошибок гидрации через onRecoverableError. Вторичный сигнал: регрессии CLS и LCP — страницы видимо мигали. Ущерб. Каждый SSR-просмотр в течение 3,5 часов перерисовывался на клиенте с нуля — серверный HTML выброшен, вспышка контента на каждой загрузке, двойная стоимость рендера ровно на тех устройствах, которые меньше всего могли её себе позволить; SEO-снапшоты зафиксировали состояние вспышки. Корневая причина. Деплой добавил в шелл страницы строку «Последнее обновление»: new Date(ts).toLocaleString() — на сервере отрендерено в UTC с серверной локалью, на клиенте пересчитано в таймзоне и локали пользователя. Серверный HTML и первый клиентский рендер расходились в тексте у каждого пользователя вне UTC; React 18 считает расхождение невосстановимым для поддерева и падает в полный клиентский рендер, отчитываясь через onRecoverableError. Паттерн обобщается: любой вход рендера, различающийся через границу — Date.now(), Math.random(), таймзона, локаль, чтения window, фиче-флаги, вычисленные в разное время, — даёт тот же шторм. Смягчение. Реверт; частота расхождений вернулась к базовой. Предложенное не-лечение: suppressHydrationWarning. Он глушит отчёт о диффе для текста одного элемента и велит React оставить серверное значение — он для намеренно расходящегося контента (таймстамп, который вы поправите после маунта), действует на один уровень вглубь и ничего не делает со структурными расхождениями; заклеивать им шторм — значит оставить в UI устаревшие серверные значения, а корневую причину — в строю. Лечение. Рендерить значения как чистую функцию входов, общих для обеих сторон: форматировать даты после маунта в эффекте (приняв осознанный контролируемый плейсхолдер) или явно передавать таймзону/локаль пользователя из запроса, чтобы сервер и клиент вычисляли идентичные строки. Предотвращение. Метрика частоты расхождений гидрации по кольцу релиза, заведённая на onRecoverableError и гейтящая раскат — штормы расхождений имеют форму деплоя, и канарейка ловит их за минуты; плюс e2e-проверка SSR-страниц с таймзоной не-UTC и неанглийской локалью — две строки CI-конфига, навсегда закрывающие этот класс.

Инцидент 3: утечка, ронявшая послеобеденные сессии

Обнаружение. Ни одного алерта. Тикеты поддержки, сходящиеся на «тормозит после обеда» от бэк-офисных пользователей; корреляционный анализ показал, что деградация следует за возрастом сессии, а не временем суток. Краши вкладок («Опаньки…») у пользователей с 8-часовыми сессиями. Ущерб. Ежедневная потеря продуктивности операционной команды примерно три недели до диагноза; куча на момент краша ~1,5 ГБ. Корневая причина. Виджет рыночного фида подписывался в эффекте без cleanup:

useEffect(() => {
  feed.subscribe(handleTick);   // замыкание захватывает rows, filters, props
  // нет return — обработчик никогда не снимается
}, [route]);

Каждое повторное посещение роута добавляло ещё один обработчик в массив слушателей фида; каждый обработчик замыкался на props того рендера, включая массив на 5 000 строк. Эмиттер держал каждое замыкание достижимым, поэтому целые размонтированные деревья компонентов оставались удержанными — GC корректно работал по мусору, который мусором не был. Триаж по снапшотам кучи сделал это читаемым за двадцать минут: три снапшота за час, сортировка по дельте retained-размера — массив слушателей на 14 000 записей, каждая удерживает старый рендер. Смягчение. Хотфикс с cleanup (return () => feed.unsubscribe(handleTick)); рекомендация перезагрузить затронутые вкладки. Предотвращение. Пункт чек-листа ревью про cleanup эффектов — каждый подписывающийся эффект возвращает отписку (двойной прогон StrictMode делает нарушение видимым в dev — ровно для этого он и существует); и длинносессионный синтетический тест: безголовый браузер, ежечасно проигрывающий 4-часовую сессию и ассертящий ограниченный рост кучи — тест, представляющий пользователя, которого ни один 90-секундный лабораторный прогон не моделирует.

Три инцидента как один урок

Выстройте инциденты в ряд — и паттерном окажется колонка обнаружения. Ни один не начался с исключения в приложении: цикл был всплеском длинных задач в RUM, шторм — потоком ошибок из собственного пути восстановления React, утечка — корреляцией тикетов поддержки. Мониторинг, называющий отказные режимы React по именам — длинные задачи по кольцу, частота расхождений гидрации по деплою, рост кучи на час сессии, — и есть то, что отделяет двадцатиминутный диагноз от трёхнедельного. И каждый пункт предотвращения, переживший ревью, был механизмом, а не резолюцией: линт, который остаётся включённым; метрика, гейтящая раскаты; синтетика, проживающая длинную сессию. Пишите постмортем так, чтобы следующая команда могла найти его грепом. Когда пишете собственный — проверьте по правилу: может ли новый инженер прочитать его, найти системный пробел и закрыть пункт предотвращения без единого вопроса коллегам?