Как мы обновляем числа, когда источник изменился

Источник меняется не одним способом

Чаще всего меняется не число как таковое, а то, что за ним стоит. Производитель творога пересматривает рецептуру, и жирность «5%» на упаковке начинает означать чуть другой состав. Методичка, по которой мы считаем нормы белка, выходит новой редакцией. Мы сами находим у себя рецептуру блюда, которая была не такой массовой, как казалось при написании страницы. Три разных повода, и ни один не похож на опечатку — но в справочнике все три выглядят одинаково: строка чисел, которая перестала быть точной.

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

Дата обновления важнее самой правки

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

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

Тест, который ловит рассогласованность, а не смысл

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

Уведомление в меру, а не по каждому поводу

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

Где живёт регулярная сверка

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

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