Шардинг тестов и карантин flaky-тестов

Шардинг: превратить 40 серийных минут в total/N

За десять минут ты поймёшь, почему шардинг по числу файлов почти не помогает, как flakiness делает здоровый сьют красным в 95% случаев и что с этим делать вместо добавления ретраев.

У сьюта, который крутится серийно, wall-clock равен его суммарному CPU-времени. Шардинг (разбиение сьюта на параллельные фрагменты) разбивает тесты на N параллельных раннеров — CI-матрицу — так что каждый раннер выполняет лишь подмножество, и wall-clock падает примерно до total / N + overhead. Раннер даёт тебе флаг среза; CI даёт матрицу, которая запускает N копий джобы, каждую со своим индексом среза.

# GitHub Actions: матрица разворачивает одну джобу в N параллельных шардов
jobs:
  test:
    strategy:
      fail-fast: false           # падение одного шарда не должно отменять остальные
      matrix:
        shard: [1, 2, 3, 4, 5, 6, 7, 8]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npx playwright test --shard=${{ matrix.shard }}/8

Каждый шард запускает --shard=i/8, выполняя примерно одну восьмую тестов. Затем финальная джоба мерджит пошардовые отчёты в один результат — у тебя не восемь отдельных вердиктов pass/fail, а один. Механика такая: разворачиваешь по индексу среза, гоняешь подмножество, собираешь частичные отчёты, мерджишь.

Ловушка в том, как раннер выбирает подмножество каждого шарда. Наивное разбиение — по числу файлов или по алфавиту: поделить 600 файлов на 8 групп по 75. Выглядит сбалансированно, но это не так, потому что тесты не равны по длительности: медленные интеграционные тесты кучкуются, один шард наследует большинство из них, и этот шард становится стрэглером (отстающим). Wall-clock ограничен самым медленным шардом, а не средним, так что если шард 3 идёт 18 минут, пока остальные семь финишируют за 6, твой сьют занимает 18 минут, и семь раннеров простаивали. Ты купил параллелизм и получил одну быструю полосу плюс семь пустых.

# Фикс: баланс по ВРЕМЕНИ, а не по числу файлов.
# Записывай длительности тестов из прошлых прогонов, затем разбивай так,
# чтобы каждый шард нёс примерно равное суммарное время (медленные тесты распределяются).
npx playwright test --shard=3/8   # раннер читает данные о времени для балансировки шардов
# Jest: --shard плюс time-aware sequencer; многие CI-инструменты (Knapsack,
# встроенный split) делают то же — передавай длительности из прошлого прогона.

Убывающая отдача: оверхед задаёт пол

Шардинг не бесплатен в расчёте на раннер. Каждый шард платит фиксированную цену старта — checkout, установка зависимостей, прогрев кеша — до того, как выполнит хоть один тест. Назовём этот оверхед c. Wall-clock — это total / N + c. Поднимая N, ты ужимаешь total / N к нулю, но c не двигается, так что за некой точкой ты добавляешь раннеры, каждый из которых тратит на старт больше времени, чем на тесты. Восемь раннеров на 40-минутном сьюте с двухминутным оверхедом дают 5 + 2 = 7 минут; тридцать два раннера дают 1.25 + 2 = 3.25 минуты за вчетверо больше машин — а счёт растёт с N. Правило большого пальца: бери N там, где total / N всё ещё кратно нескольким c. Дальше ты платишь за оверхед, а не за скорость.

Flaky-тесты: математика, которая держит сьют красным

Flaky-тест проходит часть запусков и падает в части на том же коммите — скажем, зелёный в 99% прогонов. Один такой — досада. Теперь масштабируй. Исходы тестов примерно независимы, так что вероятность того, что весь сьют зелёный, — это произведение вероятностей прохождения каждого теста: P(green) = (1 - flake)^N. Подставь 1% flake на 300 тестов: 0.99^300 ≈ 0.05. Сьют зелёный примерно в 5% случаев — он красный в 95% прогонов по причинам, не имеющим отношения к ревьюимому изменению.

Это и есть убийца на масштабе, и урон сначала социальный, потом технический. Когда сьют красный почти всегда на зелёной кодовой базе, разработчики учатся, что красное ничего не значит. Они перестают читать падения, слепо ретраят до зелёного или мерджат на чутьё. И в тот момент, когда красное перестаёт быть сигналом, настоящее падение проскальзывает в шуме — никто не смотрит дважды на ещё одну красную сборку. Сьют стал игровым автоматом.

Детектируй, карантинь, чини — а не слепо ретрай

В сеньорском плейбуке три шага по порядку:

1. Детектируй автоматически. Перепрогони падение один раз на том же коммите. Тест, который падает, а затем проходит без изменения кода, по определению flaky — пометь его и веди flake-rate по тесту со временем. Ретрай здесь — классификатор, а не лекарство: его единственная работа — отличить flaky от реального.
2. Карантинь. Убери известно-flaky тесты с блокирующего пути — гоняй их в отдельной негейтящей полосе, которая всё ещё записывает результаты, так что они перестают валить мердж, пока ты за ними наблюдаешь. Гейт сразу снова начинает что-то значить.
3. Чини корневую причину. У flaky-теста есть баг детерминизма — допущение о тайминге, общий фикстур, неотожиданный промис, зависимость от порядка. Почини это, докажи стабильность, верни тест на гейт.

Вместе эти три шага значат: гейт остаётся доверенным всё время — детект даёт классификатор, карантин даёт немедленное облегчение, а фикс замыкает петлю и тест зарабатывает возврат. Без шага 2 ты просто наблюдаешь, как накапливается flakiness; без шага 3 карантинная полоса растёт и в итоге на неё никто не смотрит.

Антипаттерн — делать глобальный авто-ретрай (retries: 3 на весь сьют) постоянной политикой. Выглядит как фикс, потому что красное уходит, но делает три плохие вещи: прячет flakiness вместо того, чтобы вынести её на починку, замедляет каждую сборку перепрогоном, и — то, что кусается, — маскирует тесты, которые flaky именно потому, что ловят настоящий перемежающийся баг. Ретрай, превращающий красное настоящей гонки в зелёное со второй попытки, выбрасывает ровно тот сигнал, что был нужен. Ретрай хорош как механизм детекции; он яд как постоянная политика гейта.