Growth Papers Бесплатный разбор

«Всё работает» и «работа сделана» — разные вещи: 11 дней тишины при зелёном статусе

Александр Смирнов · · 4 мин чтения

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

Ложная тревога будит человека, и её быстро чинят. Ложное «всё в порядке» не будит никого.

Автоматика, которую никто не проверяет глазами

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

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

Что происходило на самом деле

Одна из задач раз в 30 минут отправляла на сервер мой список отложенных дел. Утром бот собирал из него сводку: что просрочено и что пора закрыть. Чтобы не гонять файл зря, задача отправляла его только при изменении: сравнивала «отпечаток» файла с прошлым.

В расписании задаче не хватало одного инструмента, который был у меня под рукой, когда я запускал её вручную. Отпечаток получался пустым. Пустой сравнивался с пустым, совпадал, и задача решала: «ничего не изменилось, отправлять нечего». И завершалась с отметкой «успешно».

За 11 дней, с 26 июля по 6 августа, файл уехал на сервер 4 раза. Все четыре пришлись на дни, когда я правил задачу руками. Остальное время она тихо ничего не делала.

Ошибка при этом записывалась в журнал на каждом запуске, всего 312 раз. Но сторож читал журнал ошибок только тогда, когда задача сообщала о сбое. А она не сообщала.

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

Это был не единичный случай

Рядом нашлось ещё несколько случаев того же рода:

  • Ежемесячное напоминание молчало два месяца. Задача брала ключ бота из настроек по имени, которого там больше не было. В июне и июле она отработала «успешно» и ничего не отправила. Вместе с июньским сообщением потерялась моя заметка.
  • Отчёты оставались на ноутбуке. Несколько задач сохраняли отчёты в общее хранилище и мешали друг другу. Дважды отчёт не доехал, а статус был зелёным: сбой записывался строкой в журнал, а не ошибкой.
  • Предупреждение, на которое никто не реагировал. 11 недель подряд по понедельникам приходило одно и то же предупреждение о мусорных служебных файлах. Счётчик вырос с 6 до 56, чинить никто не шёл. Сигнал был, реакции не было.

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

Что изменили

Главная правка была не в одной задаче, а в стороже. Теперь задача обязана оставить доказательство: свежий файл-результат. Если задача завершилась «успешно», а доказательства нет или оно старое, сторож пишет «работа не доказана». В день правки так подключили 6 задач, к середине сентября так проверялись 10 из 20 фоновых задач.

Через месяц получили урок с обратной стороны. В сентябре сторож 17 часов показывал красное по задаче, которая работала штатно. Доказательством был назначен файл, который обновляется только при изменении списка. Ноутбук два дня стоял выключенным, список не менялся, и через 51 час при пороге в 48 часов сторож поднял тревогу. Автоматическое лечение перезапускало исправную задачу, что было бесполезно.

Критерий переделали: доказательство теперь означает «на сервере лежит актуальная версия файла». Отметка обновляется и после отправки, и после ежечасной сверки, а порог сократился с 48 часов до 6. Заодно в тревогу добавили имя задачи: до этого половина задач приходила под общей подписью, и по сообщению было не понять, что чинить.

Проверили не отметкой «успешно», а сценариями: подменили файл на сервере, и задача сама дослала правильный; убрали доказательство, и тревога пришла. С 6 августа по 14 сентября задача сделала 176 настоящих отправок.

Как проверить у себя

  1. Составьте список автоматики, от которой зависят деньги. Форма на сайте → CRM, учёт звонков, выгрузки в отчёт, уведомления менеджерам.
  2. Для каждого пункта спросите: чем докажете, что работа сделана? Не «система не упала», а «вот заявка в CRM с сегодняшним временем». Если ответ «ну, ошибок же нет», это тот самый зелёный статус без работы.
  3. Раз в месяц отправьте контрольную заявку сами. С сайта, с телефона, в нерабочее время. Проверьте, что она дошла до CRM и что менеджер её увидел.
  4. Сверьте количество на входе и на выходе. Сколько заявок видит счётчик сайта и сколько их в CRM за ту же неделю. Расхождение без объяснения — повод разобраться.
  5. Разберите повторяющиеся предупреждения. Если одно и то же приходит неделями и никто не реагирует, его надо либо починить, либо отключить. И каждая тревога должна говорить, что сломалось и что делать, а не «где-то проблема».

Именно это входит в ежедневный контроль: каждый день проверять, что заявки доходят до CRM, а не только то, что системы включены.

Александр Смирнов руководил маркетингом ресторанов, ивент-площадки, фестиваля и IT-консалтинга. По теме: что входит в ежедневный контроль.

Бесплатный разбор