79 статей исчезли с сайта, а сборка каждый раз писала «успешно»

Что произошло

Второй наш сайт три недели жил без сторожа статей: любой файл, пропавший из рабочего дерева, просто переставал открываться у людей. Вместо статьи человек видел сообщение «страница не найдена», а сборка шла чисто, без единого предупреждения. Я узнал об этом 16 сентября, когда разбирал, почему считал ситуацию под контролем.

Как устроены два наших сайта

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

Но у второго сайта 79 отдельных файлов. Там нет единой точки, за которой нужно смотреть. Когда ставили первого сторожа, о втором просто не подумали.

Почему мы ничего не замечали

Сборщик сайта просто пропускал отсутствующий файл. Не останавливался, не ругался — молча собирал то, что есть. В лог шло «Сборка успешна». Человек открывал страницу и видел сообщение «страница не найдена». Сборщик при этом был абсолютно доволен собой.

Это классический тихий сбой: система отчитывается об успехе, потому что сама операция прошла без технической ошибки. Удалить файл — не ошибка. Собрать сайт без него — тоже не ошибка. Никто не описал правило: файл, который существовал вчера в репозитории, обязан существовать сегодня.

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

Что мы сделали

Написали скрипт, который запускается при каждой сборке, до того как сборщик вообще начинает работу. Скрипт сравнивает список статей в рабочем дереве с тем, что было в последнем коммите. Нашёл пропавший адрес статьи — сборка не идёт, скрипт останавливается с ошибкой и печатает имя пропавшей статьи.

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

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

Где защита не работает

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

Мы приняли это как ограничение и компенсируем тем, что проверка запускается при каждой локальной сборке, а контент на хостинг уходит только после неё. Это договорённость внутри рабочего процесса, не техническая блокировка. Если кто-то однажды отправит файлы в обход этой цепочки — сторож не поймает.

Что можно проверить у себя

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

Дальше: возьмите любой контентный файл и переименуйте его временно. Запустите сборку. Если сборка прошла успешно — ваш конвейер не знает об исчезновении контента. Верните файл обратно.

Затем проверьте, откуда сборщик берёт список страниц. Это единственный файл или папка со множеством файлов? Если папка — единой точки для сторожа нет, нужен скрипт, который сравнивает содержимое с эталоном из репозитория.

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

У вас случалось, что сборка прошла без ошибок, страницы перестали открываться, а вы узнали об этом не от системы мониторинга, а от живого человека?