Один инженер пересобрал CI-сервис Anthropic за три недели

Удвоение ядер продержалось 70 дней, шардирование 29, ежедневные перезапуски меньше суток. В инженерном блоге Claude объясняют почему: за полгода число CI-задач в Anthropic выросло в 25 раз, и сервис, выбирающий тесты для каждого пулл-реквеста, перестал справляться.

Коротко

• Сервис, который решает, какие тесты гонять на каждом пулл-реквесте, в Anthropic переписали с нуля: работу сделал один инженер за три недели, год назад на неё ушёл бы примерно квартал.
• Инженеры Anthropic выпускают в восемь раз больше кода за квартал, чем в 2021–2025 годах, 80% пишет Claude, число тестов выросло в десять раз, а инженеров добавилось немного.
• Распределённая схема дороже в эксплуатации, зато её проще масштабировать и профилировать, чем прежний синглтон, который в марте упирался в лимит памяти к середине дня.

Если вы не следили: многие команды до сих пор гоняют все тесты на каждое изменение, и до какого-то размера это работает, а дальше CI-гейт становится долгим, дорогим и недоверенным. Выбор тестов, по данным Minware, вырос из исследований 1990-х годов об оптимизации регрессионного тестирования и давно продаётся как отдельный продукт. В Anthropic собрали детерминированный сервис, который по истории прогонов и связности пакетов решает, какие тесты запускать: людям проще отсеивать чужие падения, а агенту нужен точный набор валидных тестов для самопроверки.

Первая заплатка продержалась 70 дней, третья меньше суток

В октябре прошлого года сервис начал сыпаться, дежурных дёргали два дня подряд. Первое решение было простым: удвоили число ядер. В Anthropic сразу понимали, что это ненадолго, но владельца у сервиса, по сути, не было, а у CI-команды хватало задач поважнее.

Дальше автор завёл долгую сессию во внутренней версии Claude Tag, которая следила за сервисом: как только отставание listener переваливало за 50 000 задач, Claude писал ему и продолжал прежний разговор. Claude регулярно предлагал переписать всё целиком, но раз за разом сходились на очередной заплатке.

В феврале взялись за параллелизацию: упорядочивать результаты одному писателю нужно было не глобально, а по пакетам, поэтому состояние каждого пакета вынесли в отдельный шард со своим воркером; код написал Claude. Хватило на 29 дней.

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

Почему отставание listener на 20 минут ломает выбор тестов

Сервис держится на двух частях. Listener записывает результаты тестов с каждого прогона CI, selector читает эту историю и решает, какие тесты гонять на очередном пулл-реквесте. Когда CI-задачи идут по несколько штук в секунду, listener начинает отставать от очереди, и selector работает по устаревшим данным.

Двадцать минут отставания, по описанию Anthropic, превращаются в десятки тысяч неприменённых обновлений. Плохой мёрж роняет тест у всех, и люди заводят лишние расследования; зафлакавшая зависимость блокирует мёржи; новый или починенный тест не запускается, пока listener не догонит.

Разнести нагрузку на несколько машин мешала сама схема: историю по каждому тесту вёл единственный писатель в памяти. Представьте магазин, где касса одна, потому что список покупок всех клиентов ведётся в общей тетради: очередь растёт, а вторую кассу открыть нечем.

Состояние вынесли в хранилище в памяти, и воркеры стали взаимозаменяемыми

В итоге сервису дали базу, точнее хранилище в памяти. Любой воркер listener берёт любой результат, дописывает его в журнал и идёт дальше, ничего не удерживая. Отдельный небольшой процесс раз в несколько секунд сворачивает журнал в историю по каждому тесту, а selector быстро достаёт нужный кусок.

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

Работа заняла три недели у одного инженера; год назад, по оценке Anthropic, ушло бы около квартала. Подгонку параметров, размер журнала и число воркеров, Claude сделал в основном сам, и с тех пор сервис держится стабильно.

Совет из поста: закладывайте 25x нагрузки на два квартала вперёд

Автор пишет, что сейчас строил бы всё иначе. Число CI-задач растёт экспоненциально: агентов на инженера становится больше, одобрение пулл-реквестов ускоряется, а Claude предпочитает мелкие и дробные пулл-реквесты, из-за чего задач в день только прибавляется.

Меняется и суточный профиль: агенты пушат ночью и в выходные, поэтому нижняя планка активности поднялась, но всплески никуда не делись, потому что заметную часть пулл-реквестов по-прежнему ведут и одобряют люди.

Отсюда рекомендации: строите вы сами или покупаете, считайте, что через два квартала нагрузка будет в 25 раз выше; в версии v0 можно закладывать 10–20x от видимого масштаба, если бюджет терпит. Плюс держать состояние вне процесса, сверять, что задач на входе столько же, сколько на выходе, и не оставлять критичный сервис одним инстансом.

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

Что будет со следующим 25x

Даты следующего рубежа в посте нет, как и оценки, надолго ли хватит запаса новой схемы: сказано лишь, что после переключения и подгонки сервис держится стабильно. Автор ожидает, что горизонтально масштабируемый выбор тестов станет отраслевым стандартом, раз команды с агентами плодят и пулл-реквесты, и тесты. Когда похожие цифры появятся у кого-то кроме Anthropic, пока неизвестно.