Мы сократили семь проверок до двух — и автоматизация стала честнее

Мы построили для редакционного контура AES очень старательного надзирателя. Он проверял систему в 08:10, 10:10, 12:10, 13:10, 15:10, 17:10 и 19:10. Каждая контрольная точка могла посмотреть состояние, поправить расписание и протолкнуть работу дальше. На бумаге это выглядело безопасно. На практике система казалась здоровее, чем была на самом деле: надзиратель часто успевал устранить видимый симптом раньше, чем мы сохраняли породивший его сбой.

Поэтому мы убрали пять контрольных точек. Теперь их две: 10:10 и 19:10 по Москве. Между ними workers и durable schedulers работают самостоятельно. Главное изменение даже не в частоте: прежде чем что-либо восстанавливать, каждая проверка обязана записать состояние «как есть». Безопасность при этом не ослабла. Дедупликация, идемпотентность, лимиты каналов, проверка ассетов и публикационные evidence остались. Мы сократили вмешательство, а не контроль.

Зелёный статус тоже может быть испорченным сигналом

У частого надзора есть неочевидный дефект. Worker пропускает handoff, scheduler не срабатывает или генератор кандидатов ничего не возвращает. Следующая проверка замечает пробел и всё чинит. Когда человек открывает систему, финальный статус уже зелёный. Публикация есть, но по истории трудно понять, сделал ли работу сам worker или его спас supervisor. Надёжность и аварийное восстановление склеиваются в одну красивую цифру.

Для автономных систем это принципиально. Если механизм восстановления постоянно стоит рядом с исполнителем, организация не понимает, какой компонент действительно надёжен. Она умеет считать готовые результаты, но теряет атрибуцию причины. Возникает ложная автономность: workflow выглядит самостоятельным, хотя недостающую работу незаметно выполняет надзиратель. Здоровое конечное состояние полезно. Здоровое состояние без причинной истории опасно.

“Не чините систему так, чтобы исчезли доказательства сбоя. Сначала наблюдение, затем сохранённый trace — и только потом восстановление.

Новый контракт: наблюдать, сохранять, восстанавливать

1. Наблюдать внешне значимое состояние: публичные страницы Blog, расписание, зарегистрированные ассеты, лимиты каналов и здоровье workers.
2. Сохранять pre-repair snapshot: время, идентификаторы, статусы и точный список недостающих evidence.
3. Восстанавливать только разрешённый просроченный этап, у которого уже валидны handoff, ассет, safety-гейты и idempotency key.

Этот контракт следует базовому принципу observability: система должна позволять спросить не только «что сломано?», но и «почему?». Google SRE проводит то же различие между симптомом и причиной и предупреждает, что шумные оповещения способны спрятать действительно важные инциденты. OpenTelemetry описывает наблюдаемость как возможность исследовать неизвестные проблемы через связанные сигналы, а не один health indicator. Наш редакционный контур меньше распределённой платформы, но архитектурная задача та же.

Чему научил первый настоящий сбой

Новая частота сразу сделала заметнее неприятный паттерн. Редакционный движок снова и снова предлагал вариации одной темы — архитектура, управление и контроль. При старом ритме очередное восстановление могло бы создать обложку, черновик и подтолкнуть конвейер к публикации. По новому контракту semantic novelty gate остановил кандидата ещё до написания текста и генерации визуала. День остался честно заблокированным, а не косметически завершённым.

Этот блок был полезным. Он показал: нам не нужна ещё одна проверка scheduler. Нам нужна реальная вариативность тем — более строгая сверка с архивом, несколько редакционных линий и retry-политика, которая меняет кандидата, а не перефразирует ту же мысль. Мы исправили именно механизм. В будни теперь приоритет у существенных новостей ИИ, суббота отдана практическим операционным кейсам, а воскресенье — более глубокому взгляду «Архитектора систем».

Что мы убрали — и что сохранили

Фразу «семь проверок стали двумя» легко принять за снижение наблюдаемости. Но дизайн устроен иначе. Workers по-прежнему оставляют состояние, расписание остаётся durable, публичные endpoints, база и записи об ассетах доступны для проверки. Исчезли пять возможностей supervisor менять workflow в течение дня. Наблюдение может быть непрерывным. Вмешательство должно быть редким, явным и записанным. Так телеметрия успевает описать работу исполнителя до того, как надзиратель изменит среду.

• Мы сохранили жёсткие гейты на необратимых границах: публикации нет без проверенного двуязычного текста, уникального зарегистрированного ассета и стабильного idempotency key.
• Мы оставили политику каналов вне recovery-решения: субботняя статья не может незаметно превратиться в Telegram-пост, а выключенный LinkedIn — в блокер.
• Мы добавили negative evidence: ожидаемый результат, который не появился, фиксируется как факт и не стирается следующей успешной попыткой.

Получилась более ясная модель ответственности. Worker отвечает за первую попытку. Scheduler — за время. Supervisor — за диагностику и ограниченное восстановление. Audit trail хранит правду о том, кто в итоге завершил этап. Когда роли смешаны, каждый успех выглядит коллективным, а каждый сбой — неоднозначным. Когда роли разделены, успешный recovery можно признать восстановлением, не выдавая его за безошибочное первичное исполнение.

Контроль — не то же самое, что вмешательство

Вывод не в том, что проверок всегда должно быть меньше. Разрешение измерений должно соответствовать поведению и риску системы. Контур авторизации платежа и ежедневный редакционный workflow не требуют одинаковой частоты опроса. Вывод уже: частота надзора не должна уничтожать диагностическую ценность, а recovery нельзя выдавать за успешное исполнение. Высокочастотная телеметрия нужна там, где она отвечает на конкретный вопрос. Safety-гейты нужны на каждой необратимой границе. Но вмешательство supervisor должно быть осознанным и атрибутируемым.

Для нас двух точек теперь достаточно, чтобы ответить на три вопроса. Выполнил ли автономный worker назначенную работу? Если нет, какого именно evidence не хватает? Может ли разрешённое восстановление завершить этап без дубля и нарушения правил канала? Это полезнее семи возможностей сделать dashboard зелёным. Автоматизация стала заслуживать больше доверия не потому, что перестала ошибаться, а потому, что больше не может скрыть, каким способом добилась результата.