Одна из самых неприятных иллюзий автоматизации — считать систему готовой после того, как она один раз успешно отработала. В Agency мы сознательно проверяли контентный контур иначе: не только обычными regression-тестами, но и последовательностью виртуальных операционных дней, чтобы поймать ошибки календаря, дедлайнов и переходов между периодами.
Результат этой приёмки: 216 из 216 тестов PASS, затем 14 последовательных чистых виртуальных дней, temporal stress без срыва и accepted_diff = 0 при сравнении принятого candidate с production.
Почему обычного «тесты зелёные» было недостаточно
Контентная система работает не одним запросом. У неё есть календарные слоты, очереди, approval, дедлайны, повторные проверки, публикационные окна и смена периода. Ошибка может не проявиться в обычном unit-тесте, но возникнуть на следующий день, в конце месяца или при накоплении очереди.
Поэтому для версии content funnel v2.2 мы разделили проверку на два слоя: regression и temporal acceptance.
Слой 1. Regression: 216 из 216
Сначала executable candidate прошёл полный regression-набор. Все 216/216 тестов завершились успешно. Это было базовым условием допуска к следующему этапу, но не финальным доказательством готовности.
Такой подход соответствует общей логике reliability engineering: тестирование должно повышать уверенность в будущем поведении системы, а не просто подтверждать один удачный запуск. В главе Google SRE — Testing for Reliability отдельно разбирается роль тестов, stress testing и production-like проверки для оценки надёжности.
Слой 2. Четырнадцать виртуальных операционных дней
После regression система последовательно прожила 14 виртуальных дней. В каждом цикле проверялось, что накопленное состояние не ломает следующий день и что правила, которые выглядят корректно в один момент времени, остаются корректными дальше.
Критерий был жёстким: не «большинство дней прошло», а 14 clean ACCEPTED days подряд.
Это важно для автоматизации, которая зависит от времени. Например, сценарий может нормально работать в середине недели, но ошибиться при переходе даты; очередь может корректно обрабатываться при пустом backlog, но начать конфликтовать после нескольких циклов; monthly logic может дать сбой именно на границе периода.
Что дополнительно проверяли temporal stress
В acceptance вошли календарные и временные переходы, включая deadline logic и month rollover. Цель была не воспроизвести любую возможную ситуацию, а проверить те классы ошибок, которые возникают не из-за одной функции, а из-за развития состояния системы во времени.
Temporal stress также завершился ACCEPTED.
Почему promotion в production оказался no-op
После lab acceptance принятый executable candidate сравнили с production. Результат: accepted_diff = 0. То есть версия, которую мы только что приняли в изолированном контуре, byte-for-byte совпадала с тем executable, который уже работал в production.
Это не повод «всё равно что-нибудь задеплоить». Правильный результат — no-op promotion: если accepted candidate и production идентичны, дополнительное изменение не создаёт ценности, а только добавляет риск.
Что этот кейс изменил в нашем подходе к автоматизациям
Для нас приёмка теперь состоит не из одного слова «работает», а из нескольких независимых вопросов:
- проходят ли функциональные и regression-тесты;
- сохраняется ли корректность при развитии состояния во времени;
- проходят ли критические календарные переходы;
- совпадает ли принятая версия с тем, что реально будет работать;
- нужно ли вообще выполнять deployment, если diff отсутствует.
Граница доказательства
216/216 и 14 виртуальных дней не доказывают коммерческий эффект автоматизации. Они не означают рост продаж, экономию конкретной суммы или отсутствие будущих ошибок. Это evidence инженерной приёмки конкретной версии и конкретного класса сценариев.
Тот же принцип мы используем при построении AI-контуров для бизнеса: сначала ограниченный набор прав и сценариев, затем проверка поведения, и только после этого расширение области действий. Подход к таким системам описан на странице AI для управления бизнесом.