Аудит автоматизации: как я выключил четыре зомби-системы за один день
22 июня 2026 года я почти ничего не построил. Весь день выключал. К вечеру в списке закрытых задач стояли четыре системы: villa-бот врал клиентам про виллы, которыми я уже не управляю, okoshki-парсер молча падал 4 дня, карусельная фабрика сжигала бюджет при нулевом охвате, четвёртая умудрялась включать саму себя через автономный рой агентов. Параллельно пришёл перевод $1000 от Дениса Зинина — за то, что я строю, не за то, что выключаю.
Это статья про аудит автоматизации — не теория, а то, что я делал руками 22 июня. С конкретными системами, конкретными причинами остановки и процессом, который занял 3 часа.
Почему забытая автоматизация опаснее полного отсутствия
Когда автоматизации нет — человек делает всё сам. Медленно, но контролируемо: знает, что говорит, и видит, когда что-то идёт не так.
Когда автоматизация работает — всё хорошо. Система делает рутину быстрее и дешевле человека.
Третий вариант, про который не говорят: автоматизация, которую запустили и забыли. Такая система не засыпает. Она продолжает работать — без надзора, без актуальных данных, часто с устаревшей логикой.
Мёртвая автоматизация — это не «ничего не происходит». Это активное действие в неправильном направлении. Она тратит деньги, отправляет неправильные сообщения, падает молча и накапливает технический долг. Всё это — без вашего ведома.
Почему хуже полного отсутствия? Порождает ложную уверенность. Владелец думает «у меня это автоматизировано», не проверяет — и узнаёт о проблеме от клиента спустя дни или недели. Или не узнаёт вовсе.
В этом смысле «прополка» — навык, который не включают в программы обучения автоматизации. Все учат запускать. Никто не учит останавливать. Ниже — три реальных кейса за один день и процесс, который занял 3 часа.
Особенно коварны системы трёх типов: боты, взаимодействующие с клиентами от вашего имени (риск репутации); cron-задачи без мониторинга (риск операционный — незаметная поломка); и автоматизация с регулярными денежными расходами (риск финансовый — постоянный дренаж). Если у вас есть хотя бы одна система каждого типа — аудит стоит провести прямо сейчас, не откладывая на следующий квартал.
Кейс 1 — Villa AI-продажник: три недели неправды
В начале июня 2026 года я передал управление 16 виллами компании Vsemdom. Осознанное решение: сосредоточиться на клубе и автоматизации, не на операционке вилл.
Передал операционку. Не передал бота.
Мой AI-продажник — система в broadcaster.py, которая отвечала на входящие сообщения о виллах — продолжал работать. 22 июня я зашёл проверить логи и увидел: вчера вечером бот на голубом глазу объяснял клиенту характеристики виллы, которой я больше не управляю. Рассказывал про цены, доступность, «уточните детали у нашего менеджера».
Менеджера нет. Виллы нет. Бот есть.
Параллельно каждое утро мне приходили автоматические «Отчёты отдела продаж Бали Виллы» — дайджесты с «0 новых клиентов». Несколько недель подряд. Отдела нет, отчёт был.
Масштаб потенциального ущерба: за 3 недели с момента передачи Vsemdom бот мог ответить на десятки входящих. Сколько людей ушли с неправильным представлением о ситуации — не знаю. Это и есть главная проблема мёртвой автоматизации: она действует за пределами вашей видимости.
Фикс занял 7 минут: добавил в broadcaster.py гард VILLA_SILENT, который глушит villa-niche при любом входящем. Orange Car Phuket — другой бизнес в том же broadcaster — продолжает работать, не затронут. Хирургия, не ампутация. Ежедневные отчёты выключил отдельно.
Урок: когда меняется бизнес-контекст (передали операционку, закрыли направление, сменили партнёра), нужен явный чеклист «что автоматизировано под это направление». Без него передаёте операционку, но оставляете бота, который продолжает говорить с клиентами от вашего имени.
Хорошая практика при любой крупной бизнес-перемене: перед финальным переходом пройтись по всем активным системам с вопросом «эта система завязана на старый контекст?». У меня этого чеклиста не было — и бот проработал три лишние недели. Теперь он есть. Добавил в личный протокол «что проверить перед передачей направления» — там 12 пунктов, и активные боты теперь в числе первых трёх.
Кейс 2 — Okoshki-парсер: 4 дня тихого падения
Андрей Полушин — владелец медицинской клиники, мой клиент. Я настроил ему бота, который мониторит YClients и присылает уведомление, когда в расписании появляется свободное окно. Типичный use case для небольшой клиники: не нужно держать администратора, который час смотрит на расписание.
22 июня Андрей написал: «что-то давно не приходят окошки». Я предположил проблему с токеном — они иногда протухают. Полез в логи.
Оказалось хуже. Cron-задача падала с ошибкой уже 4 дня. Причина — YClients однажды вернул время в формате «9:00» вместо «09:00». Мой парсер ждал строго двузначный час, встретил однозначный — выбросил исключение. Cron зафиксировал ошибку в логе, никуда не отправил алерт и продолжил запускаться каждые 15 минут с тем же результатом.
4 дня × 24 часа × 4 запуска в час = около 384 попыток выполнения. Каждая — ошибка. Клиент не получил ни одного уведомления о свободных окошках. Новые записи в клинику — тоже.
Фикс парсинга занял 20 минут. Одна строка: hour = time_str.split(':')[0].zfill(2). Алерт в Telegram при крэше cron-задачи — ещё 15 минут. Итого 35 минут работы после 4 дней молчаливого падения.
Главный урок не в парсинге. Фоновые задачи умирают беззвучно. Система не кричит «я сломалась» — она просто перестаёт делать то, для чего создана. Узнаёшь об этом от клиента, не от системы.
Внешние API время от времени меняют форматы ответа без предупреждения. YClients вернул однозначный час — моя система не была к этому готова. Это системная проблема, не исключение: любая интеграция с внешним сервисом потенциально содержит такую точку отказа. Либо вы делаете парсинг defensive по умолчанию, либо у вас есть алертинг, который скажет об отказе в течение часа.
Defensive парсинг — это не параноя, это стандарт. Вместо int(time_str.split(':')[0]) всегда писать int(time_str.split(':')[0].zfill(2)). Вместо прямого обращения к ключу словаря — .get(key, default). Вместо предположения о формате даты — явный dateutil.parser.parse() с fallback. Каждая такая строка — страховка от однозначного часа, лишнего пробела или изменённого поля, которое внешний сервис тихо переименует в следующем обновлении.
После этого случая у каждой cron-задачи в моей системе появился алерт: при трёх последовательных неудачах — сообщение в Telegram. Не email, не лог — Telegram, потому что его я вижу в течение минуты.
Кейс 3 — Карусельная фабрика: нулевой охват, реальные деньги
В Instagram @yuriy_solar 45 000 подписчиков. Звучит неплохо, пока не смотришь в аналитику.
Metricool показал: аудитория — женщины 35–44 лет из России и Казахстана. Люди из прошлых жизней аккаунта — периодов, когда я писал про Бали, образ жизни, виллы. Сейчас пишу про автоматизацию и AI-агентов. Этой аудитории это неинтересно. Органический охват каждого поста — уровень нового аккаунта без истории, не аккаунта с 45 000 подписчиков.
При этом несколько месяцев я держал автоматическую фабрику каруселей: система каждый день брала мой Telegram-пост, разбивала на слайды, генерировала картинки через DALL-E 3 и публиковала в Instagram. Это реальные деньги — API-запросы к DALL-E, серверное время, токены агентов.
Расходы шли каждый день. Охват не менялся месяцами. Ни одной метрики, сигнализирующей «пора разобраться» — система просто молча делала своё дело.
22 июня я выключил фабрику. Но пока выключал, обнаружил: один из Paperclip-агентов нашёл способ включить её обратно самостоятельно. В автономном рое была логика «если карусели выключены — включить через альтернативный маршрут». Это не баг — именно для этого я проектировал систему месяцами: устойчивость к сбоям. Только теперь «сбой» с точки зрения системы — моё сознательное решение выключить.
Закрыл в 6 слоёв: убрал логику реанимации из агентов, добавил явный флаг ig_carousels_disabled в конфиг, прописал его в конституцию системы как «не реанимировать», добавил watchdog, алертящий при попытке включить. Паранойя? Нет — уважение к тому, что система умеет делать сама.
Этот кейс про другое: автоматизация может работать технически корректно, но быть полностью бессмысленной в текущем контексте. 45 000 подписчиков с неправильной демографией — это не актив для нового направления, это балласт. Карусели не решали эту проблему, они просто генерировали затраты в направлении, где ROI стремился к нулю.
Признаки, что автоматизацию пора остановить
После трёх таких кейсов за один день у меня есть рабочий список. Каждый пункт — из реального опыта.
Контекст изменился, система — нет. Villa-бот работал технически корректно. Бизнес изменился. Бот продолжил работать в изменившемся контексте. Любая автоматизация завязана на внешние условия — если условия сдвинулись, система требует ревью.
Никто не заметил бы, если бы упало. Okoshki-парсер упал — клиент заметил через 4 дня. Если за системой никто не следит и никто не ждёт её результата активно — либо система не нужна, либо нужен мониторинг.
Расходы есть, метрика не растёт 4+ недели подряд. Карусельная фабрика генерировала расходы каждый день. Охват не менялся несколько месяцев. Постоянные вложения без изменения целевой метрики — сигнал к пересмотру.
Последний раз проверяли больше 30 дней назад. Любой автоматический процесс, не проверявшийся месяц и более, имеет ненулевую вероятность работать не так, как ожидалось. Внешние API меняют форматы, сервисы добавляют ограничения, бизнес-контекст сдвигается.
Трудно объяснить, что именно делает система прямо сейчас. Если нельзя за 30 секунд сформулировать «эта система делает X, потому что Y» — это сигнал, что система потеряла своё место в общей картине.
Нет алертов при сбое. Если система упала — вы узнаёте от клиента или случайно. Без контуров наблюдения мёртвое не отличается от живого.
Ни один из этих признаков по отдельности не означает «выключить немедленно». Совпадение двух и больше — повод потратить 30 минут на проверку прямо сейчас, не откладывая.
Отдельный класс — системы, которые работают корректно технически, но дают ложное ощущение контроля. Ежедневный «Отчёт отдела продаж Бали Виллы» с «0 новых клиентов» — идеальный пример. Отчёт приходил, я видел его в чате, мозг регистрировал «система работает». При этом отдела нет уже несколько недель. Это не мониторинг — это ритуал, создающий иллюзию контроля. Такие системы особенно важно находить при аудите: они не ломаются, не тратят много денег, но занимают ментальное пространство и маскируют отсутствие реального наблюдения.
Как провести аудит автоматизации за один день
Вот процесс, который работает для малого бизнеса с 1–3 людьми. Без сложных инструментов, за 3–4 часа. Я не использую специализированные платформы аудита — только список, три вопроса и время. Инструменты приходят потом; сначала нужно понять, что вообще работает.
Шаг 1 — Инвентаризация (30 минут)
Возьмите лист бумаги или заметку и выпишите всё, что работает в фоне без вашего участия. Всё: боты в Telegram, cron-задачи, Zapier/n8n потоки, скрипты на сервере, триггеры в CRM, расписания в любых сервисах, автоматические email-рассылки, webhooks.
Не оценивайте — просто выписывайте. Для каждого пункта укажите: что делает, когда запустили, когда последний раз проверяли.
Типичная инвентаризация малого бизнеса с 1–3 людьми даёт 15–40 активных автоматических процессов. Большинство владельцев называют 5–10, потом удивляются остатку. Разрыв между названным и реальным — и есть ваш первый результат аудита: это системы, про которые вы забыли, а они продолжают работать.
Хороший признак того, что инвентаризация нужна прямо сейчас: вы назвали 7 процессов, и при этом у вас есть сервер, который работает 24/7, несколько Telegram-ботов и хотя бы один аккаунт в Zapier или n8n. Математика не сходится.
Шаг 2 — Проверка жизнеспособности (1–1.5 часа)
По каждому пункту из списка — три вопроса:
Работает ли прямо сейчас? Не «должна работать» — проверьте. Зайдите в логи, запустите тестовый запрос, посмотрите последнее выполнение в cron. Okoshki-парсер «должен был работать» по расписанию — лежал 4 дня.
Актуален ли контекст? Изменился ли бизнес, внешний сервис, данные, которые система обрабатывает? Villa-бот работал технически корректно — контекст изменился три недели назад.
Есть ли измеримая польза? Не «наверное помогает» — конкретная метрика за последние 30 дней. Для okoshki-парсера это «количество уведомлений клиенту за неделю». Для карусельной фабрики — охват постов из неё. Его не было.
По результатам каждый пункт получает один из трёх статусов: оставить (работает, актуально, польза есть); решить (работает, но контекст или польза под вопросом); остановить (не работает или контекст ушёл).
Шаг 3 — Остановка и архивация (30–60 минут)
Для пунктов «остановить»: выключите, задокументируйте причину одной строкой и сохраните код/конфиг в архив. Не удаляйте — архивируйте. Через 6 месяцев вспомните «у меня было что-то для X» и найдёте. Удалённое не восстановить.
Для пунктов «решить»: поставьте конкретную дату ревью — «обновить к 2026-07-22». Без даты «обновить потом» превращается в «никогда».
Важный момент: когда вы выключаете систему, проверьте, нет ли у неё зависимых компонентов. Карусельная фабрика оказалась встроена в автономный рой глубже, чем я думал. Перед выключением задайте три вопроса: что ещё знает об этой системе, что от неё зависит, есть ли у неё логика самовосстановления.
С ростом сложности стека этот вопрос становится всё важнее. В простой системе из пяти скриптов зависимости очевидны. В системе с автономными агентами, которые общаются между собой и умеют принимать решения о том, что запускать — выключение одного компонента может иметь неожиданные последствия. Карусельная фабрика это наглядно показала: я выключил front-end системы, но её back-end логика жила в агентах и умела включать её снова. Документируйте зависимости до выключения, не после.
Шаг 4 — Алертинг на то, что остаётся (30 минут)
Для каждой системы из «оставить»: убедитесь, что при сбое приходит алерт. Не email, не лог — что-то видимое в течение часа. Telegram — простой выбор для большинства случаев.
Минимальный алерт для cron-задачи на Python:
import requests, os
def alert(msg):
token = os.environ['TG_BOT_TOKEN']
chat = os.environ['TG_CHAT_ID']
requests.post(
f"https://api.telegram.org/bot{token}/sendMessage",
json={"chat_id": chat, "text": f"Задача упала: {msg}"}
)
try:
run_task()
except Exception as e:
alert(f"okoshki_parser: {e}")
raise20 строк кода, которые спасли бы 4 дня молчаливого падения okoshki-парсера.
Технический долг в автоматизации отличается от технического долга в разработке. В коде технический долг — плохо написанный код, который рано или поздно придётся переписывать. В автоматизации технический долг — это системы, продолжающие работать после того, как их смысл исчез. Он накапливается незаметно: запустили систему под задачу, задача решена, система продолжает работать вхолостую или в ущерб. Через год — 40 процессов, из которых 20 приносят пользу, 15 работают впустую, 5 делают что-то вредное. Вы не знаете, которые именно, потому что никогда не проводили инвентаризацию.
Итог: прополка — это мастерство, не провал
Юрий Солар, основатель Solar OS: «Раньше я думал, что автоматизация — это про то, как всё запустить. Сегодня вижу, что половина мастерства — вовремя заметить и остановить то, что давно пора было остановить».
День 22 июня это подтвердил. Запуск новых систем — инвестиция. Поддержание мёртвых — налог за забывчивость. Причём налог не только финансовый: бот, говорящий неправду клиентам — репутационный налог. Система, падающая молча — операционный налог, который платится каждый день падения.
За один день: villa-бот выключен (VILLA_SILENT гард в broadcaster.py), ежедневный отчёт несуществующего отдела продаж — выключен. Okoshki-парсер починен за 35 минут, алерт добавлен. Карусельная фабрика остановлена, автономный реанимационный маршрут закрыт в 6 слоёв. И параллельно — $1000 от Дениса Зинина за реальную работу по аудиту его серверов Beget. Хороший день, несмотря на то что ни одной новой системы не появилось.
Механик не стыдится того, что провёл день на техобслуживании, а не на гонках. Аудит автоматизации — то же техобслуживание. Я делаю его примерно раз в 2 месяца. Каждый раз нахожу что-то, что пора остановить.
Один из результатов регулярного аудита — понимание, какие системы реально работают на бизнес, а какие просто «были когда-то нужны». В Solar из 40+ автоматических процессов, которые работали в какой-то момент, сейчас активны около 20. Остальные или выключены, или в архиве с датой и причиной. Эта прозрачность сама по себе ценна: когда знаешь точный список работающего, проще принимать решения о новой автоматизации — не «у нас уже много всего», а «вот конкретно что работает, вот что добавляем».
Если хотите провести такой же аудит у себя — в клубе «Solar — внутрянка» выкладываю шаблоны инвентаризации, чек-лист признаков «пора остановить» и скрипты алертинга для cron-задач из своего стека. Там же — разбор того, как устроена система мониторинга 20+ автоматических процессов, которые работают в Solar прямо сейчас. От 2 500 ₽/мес, бери и адаптируй: https://4bos.ru/inside/
По теме автоматизации читайте также: как AI-агент заменил менеджера по продажам в Orange Car Phuket.