Одна скобка остановила публикации на девять дней

Одна скобка остановила публикации на девять дней. Снаружи сайт жил как ни в чём не бывало: старые статьи были на месте, страницы открывались, тревоги не было.

Внутри скрипт каждое утро падал на одной и той же ошибке и тихо складывал её в лог. Никто этот лог не читал, поэтому сбой выглядел как «ну, что-то само не отработало».

Что именно сломалось

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

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

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

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

Как ошибка попала на сервер

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

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

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

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

Почему девять дней никто не замечал

Скрипт запускался каждое утро и каждое утро падал с одной и той же ошибкой. Это важная деталь: сбой был не случайный, не плавающий, не «иногда работает, иногда нет». Он повторялся стабильно, но прятался в лог.

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

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

На деле система просто молча не делала часть своей работы. Это особенно коварно, когда результат виден не сразу. Если у вас ничего не ломается внешне, вы реже проверяете внутренности. А потом обнаруживаете, что тишина стоила вам долгого хвоста без новых материалов.

Узнали свой кабинет?

Если система молчит, это ещё не значит, что она работает. Иногда она просто умеет падать тихо.

Чем опасны системы, которые работают сами

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

Особенно опасно это там, где вы привыкли считать, что «раз настроено, значит, дальше само». Само не значит безопасно. Само не значит наблюдаемо. Само не значит, что вы узнаете о проблеме без отдельного сигнала.

Такая же логика часто ломает и рекламные процессы. Не в смысле кода, а в смысле привычки: один раз настроили, дальше редко проверяют, почему трафик не идёт или заявки не появляются. Об этом я отдельно писал в разборе почему сливается бюджет в Яндекс.Директе. Там суть та же: если систему не держать в поле зрения, она может продолжать работать только формально.

Плохая автоматизация опасна не потому, что она ломается. Она опасна потому, что ломается незаметно. И чем меньше у вас ручных точек контроля, тем дольше вы верите, что всё идёт как надо.

Что теперь проверяется перед выкладкой

После этой истории вывели простое правило: перед выкладкой файл надо прогонять через проверку синтаксиса. Не после, не когда «что-то показалось странным», а до попадания на сервер. Это не лечит всё, но отсекает класс ошибок, которые легко допустить и трудно заметить.

Вторая часть правила не менее важна: падение скрипта должно приходить сообщением, а не молча ложиться в лог. Лог полезен, но только если кто-то реально его читает. Если нет сигнала наружу, вы узнаёте о проблеме слишком поздно.

Здесь полезно разделить контроль на простые вещи. Не пытаться усложнить процесс, а поставить минимум, без которого выкладка вообще не должна проходить.

Если смотреть по-человечески, это не про «идеальную дисциплину», а про защиту от банальной невнимательности. Один раз поставить проверку проще, чем потом разбираться, почему публикации исчезли из расписания почти на полторы недели.

Как сделать, чтобы поломка сама сообщала о себе

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

Для этого не нужен сложный контроль. Нужна понятная точка, где сбой превращается в сообщение. Тогда проблема перестаёт быть «где-то что-то не сработало» и становится конкретным сигналом, который можно обработать.

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

Этот список кажется простым только на бумаге. На деле именно такие вещи чаще всего и экономят нервы. Не потому, что они сложные, а потому, что они ловят самые глупые ошибки, на которых обычно и спотыкаются.

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

Что запомнить и с чего начать

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

Запомнить стоит три вещи. Сначала проверка синтаксиса перед выкладкой. Потом сигнал о падении, который приходит к человеку, а не остаётся в логе. И в конце — привычка не верить в то, что система «сама разберётся», если вы не построили для неё понятный контроль.

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

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