Как я снизил расходы на автоматизацию бизнеса на 30% за один день

Несколько месяцев назад меня разбудили в 5 утра три бота одновременно. Не что-то срочное — просто три плановых уведомления, которые случайно совпали по времени. Я лежал в темноте и думал: это не баг, это архитектурная проблема. К вечеру того же дня расходы на обслуживание всей системы автоматизации упали на 30 процентов. Вот как именно это произошло.

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

Три бота в 5 утра: как выглядит архитектурный долг

Утреннее пробуждение от уведомлений — не редкость для тех, кто управляет автоматизированными системами. Обычно на это реагируют так: отключают уведомления на телефоне. Это неправильная реакция. Правильная — понять, почему система считает, что ночью кому-то нужны эти данные. Каждое ночное уведомление — это либо проблема приоритизации, либо проблема дизайна.

Я открыл ноутбук и за 20 минут составил карту всех точек нотификации. Результат оказался красноречивым: 13 мест, где боты пишут в Telegram-чаты или отправляют уведомления, из них только 1 учитывала время суток. Остальные 12 работали круглосуточно в режиме «случилось — пишем».

Это типичный архитектурный долг. Каждый скрипт писался отдельно, под конкретную задачу, и никто не думал о глобальной политике нотификаций. Первый скрипт появился больше года назад — тогда одна точка нотификации была нормой. К 13-му скрипту точек стало 13, и ни одну не пересматривали. Долг накапливался незаметно, по одной строчке кода за раз.

Важно понимать: эти 12 точек работали правильно с технической точки зрения. Они делали именно то, для чего были написаны. Проблема была не в коде — а в том, что никто не задавал вопрос: а нужно ли это сообщение в 3:47 ночи? Нужно ли будить людей ради информации, которая спокойно подождёт до утра? Когда никто не задаёт этот вопрос — система по умолчанию считает, что нужно.

Аудит 13 точек нотификации: карта за 3 часа

Я открыл список всех скриптов и прошёлся по каждому. Для каждой точки выписал четыре параметра: что именно отправляется, кто получатель (Telegram-чат, личное сообщение, email), нужно ли это немедленно или можно подождать до утра, и какова частота (разовое, периодическое, triggered по событию).

Вот как выглядел итог по категориям после классификации:

• Действительно срочные (нужно действие в ближайший час): 2 точки. Критические алерты — отказ платёжной системы, конфликт бронирования с уже подтверждённым гостем.
• Важные, но терпят до утра: 7 точек. Отчёты о ценах конкурентов, статусы длительных задач, сводки по финансам за день, результаты ночных синхронизаций.
• Чисто информационные: 4 точки. Подтверждения успешных операций, ежедневная статистика, технические логи с пометкой «всё хорошо».

Итог: из 13 точек нотификации по-настоящему срочными были только 2. Остальные 11 могли спокойно ждать до 09:00. Это значило одно: система 11 раз в сутки будила людей без нужды. Умножьте на 7 ночей в неделю — 77 лишних уведомлений в неделю. При 5–6 ночных за ночь это 35–42 прерванных часа сна в команде в месяц. Не считая утренней раздражённости и снижения концентрации на следующий день.

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

Окно тишины: один модуль решает 11 проблем

Решение оказалось простым. Я написал общий модуль — 18 строк Python — который проверяет текущее время и принимает решение: отправить сейчас или поставить в очередь.

Логика такая: если время от 21:00 до 09:00 по местному времени (Бали, UTC+8), сообщение не отправляется — оно записывается в локальный файл-очередь. В 09:00 запускается отдельный cron-job, который читает очередь и отправляет все накопленные сообщения одним пакетом с временны́ми метками оригинальных событий.

Три принципиальных решения в реализации:

• Временны́е метки сохраняются. Каждое сообщение в утреннем пакете показывает, когда именно произошло событие. Команда видит хронологию, а не свалку. «02:31 — финансовый отчёт обновлён. 04:17 — парсер цен завершил работу. 06:44 — синхронизация с OTA прошла успешно.» Это не хуже, чем получать сообщения в реальном времени — это лучше, потому что читаешь всё за 3 минуты вместо того чтобы просыпаться три раза за ночь.
• Критические алерты — исключение. Два типа событий (отказ платёжной системы, ошибка бронирования с подтверждённым гостем) идут мимо очереди — сразу, в любое время суток. Это настраивается через флаг is_urgent=True в вызове функции. Всё остальное — в очередь.
• Один модуль для всего. Не нужно переписывать каждый скрипт. Достаточно заменить вызов send_message() на queue_or_send() в 11 местах. Это заняло 40 минут.

После деплоя следующая ночь прошла в тишине. Утром в 09:01 пришёл пакет из 8 накопленных уведомлений. Команда прочитала всё за 3 минуты и закрыла нужные задачи. Производительность не упала — она выросла, потому что люди выспались и начали день без стресса от прерванного сна.

Через неделю после внедрения я спросил команду: замечаете разницу? Ответ был однозначным: да. Дело не только в самих уведомлениях — дело в ощущении, что система тебя уважает. Что она понимает: не всё требует немедленного внимания. Это мелочь психологически, но для команды, которая работает с автоматизацией каждый день — важная вещь.

Аудит подписок: три счёта там, где нужен один

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

Паттерн 1: параллельные аккаунты одного сервиса. Три скрипта использовали отдельные аккаунты одного и того же сервиса для агрегации данных. Каждый аккаунт — отдельная ежемесячная плата. Причина возникновения простая: скрипты писались независимо в разное время, и каждый раз автор регистрировал новый аккаунт, не зная о существующих. Решение: перенести все три скрипта на один аккаунт с единым API-ключом. Технически — 15 минут правки конфигов. Результат: минус два ежемесячных платежа.

Паттерн 2: платный инструмент вместо бесплатного аналога. Один из скриптов использовал платный сервис для задачи, которую можно было решить бесплатно через API другого инструмента, уже установленного в системе. Я переписал вызов на встроенный метод. Платную подписку отменил. Функциональность осталась идентичной.

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

Итого за аудит подписок: сэкономлено 4 ежемесячных платежа. В процентах от общих расходов на инфраструктуру — около 22 процентов. Вместе с оптимизацией нотификаций (меньше API-запросов ночью, меньше нагрузки на LLM в нерабочие часы) суммарная экономия вышла на уровень 28–30 процентов от базового уровня расходов.

Итог дня: 23 задачи, 30% экономии, ноль найма

К концу того же дня я закрыл 23 задачи по разным направлениям: управление виллами, обновление контента, инфраструктурные правки, финансовая сверка, обработка входящих запросов. Это стало возможным потому, что AI-агенты работают параллельно и не требуют моего участия в каждом действии. Пока я занимался аудитом нотификаций, агенты параллельно вели входящие лиды, обновляли цены на OTA-платформах, готовили утренние отчёты.

Итоговые результаты одного рабочего дня:

• Расходы на инфраструктуру автоматизации: минус 30 процентов
• Ночные уведомления команде: с 5–6 до нуля
• Технический долг по нотификациям: закрыт полностью
• Потери функциональности: нет
• Новых сотрудников для реализации: ноль
• Отключённых инструментов: ноль

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

Как провести собственный аудит за один рабочий день

Если у вас есть хотя бы 5–7 автоматизированных скриптов или ботов, вероятность найти похожие неэффективности высокая. Вот последовательность, которая у меня сработала:

Шаг 1 — Карта нотификаций (1–2 часа). Выпишите все точки, где ваши скрипты что-то отправляют: Telegram, WhatsApp, email, Slack. Для каждой точки: что отправляется, когда (расписание или триггер по событию), кто получатель, нужно ли это немедленно — или это просто «фоновый шум», который можно собрать в утренний пакет.

Шаг 2 — Классификация по срочности (30 минут). Разделите на три категории: срочное (нужно действие в ближайший час), важное (нужно к утру), информационное (можно читать когда удобно). Скорее всего, обнаружите, что в категорию «срочное» попадёт 10–20 процентов всех уведомлений.

Шаг 3 — Внедрение буфера (2–3 часа разработки). Напишите единый модуль очереди. Простейшая реализация: функция с двумя режимами — отправить сейчас или записать в очередь. Cron-job в 09:00 читает файл и отправляет пакет. Весь модуль — 20–30 строк кода.

Шаг 4 — Аудит подписок (1 час). Выгрузите все активные платёжные обязательства по автоматизации. Для каждой подписки: какие скрипты используют этот сервис? Нет ли дублей? Можно ли заменить бесплатным аналогом или перевести на уже оплаченный инструмент? Ответы на эти четыре вопроса обычно дают 15–25 процентов экономии.

Шаг 5 — Деплой и наблюдение (30 минут + несколько дней). Задеплоить изменения, запустить следующую ночь в режиме наблюдения. Проверить утром: все уведомления пришли? Срочные события не потерялись? Если да — система работает правильно.

Тихая утечка: почему это важнее, чем кажется

Расходы на инфраструктуру автоматизации — это тихая утечка. В отличие от зарплаты сотрудника, которая видна в каждом отчёте, подписки на 15–50 USD в месяц не привлекают внимания. За год они накапливаются в несколько тысяч долларов — и продолжают расти по умолчанию. Никто не напоминает: «у тебя три ненужных подписки». Они просто списываются каждый месяц.

Тот же принцип применим к вычислительным расходам. Каждый API-запрос к LLM стоит денег. Если скрипт делает 1000 запросов в день, из которых 600 — к одним и тем же данным, которые не меняются — это 600 лишних запросов. Кэширование решает это за несколько часов разработки и снижает LLM-расходы на 40–60 процентов в типовом сценарии.

Есть ещё один аспект, о котором редко говорят: стоимость внимания. Каждое уведомление — это не только секунда времени на прочтение. Это прерывание контекста. 6 ночных уведомлений прерывают сон, и на следующий день первые 2–3 часа работы проходят в режиме «разгона» вместо полноценной концентрации. Для команды из 3 человек это 6–9 часов потерянной продуктивности в день после активной ночи уведомлений. Это дороже, чем любая подписка.

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

Если вы управляете системой из 10 и более скриптов и ни разу не делали такого аудита — отложите один рабочий день. Вероятность найти 20–30 процентов лишних расходов очень высокая. А заодно выспитесь нормально.

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

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

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

Хорошая новость: большинство из описанных улучшений не требуют больших технических навыков. Модуль тишины из 20 строк кода, список подписок в таблице, квартальный чек-лист на час — этого достаточно для поддержания системы в хорошей форме на протяжении многих месяцев. Главное — выделить время и сделать это хотя бы один раз. После первого аудита последующие становятся значительно быстрее: база уже чистая, нужно только следить за новыми добавлениями.

О том, как строить систему агентов с нуля и не накапливать технический долг с первого дня, подробнее в статье Автоматизация бизнеса с нуля: с чего начать. А о том, что происходит, когда агенты работают годами без аудита — в разборе Кладбище тихих поломок.

Что конкретно изменилось: метрики до и после

Через месяц после внедрения я собрал данные, чтобы понять реальный эффект. Вот что получилось в цифрах:

По нотификациям: до аудита — в среднем 5,8 уведомлений в ночное время (с 21:00 до 09:00) ежедневно. После — 0 плановых ночных уведомлений, только экстренные (2–3 в месяц). Утренние пакеты в среднем: 7–9 сообщений, время на прочтение 3–4 минуты.

По расходам: базовая строка расходов на инфраструктуру — 100 процентов (взял за базу). После оптимизации подписок: 78 процентов. Дополнительная экономия от снижения ночной нагрузки на API: ещё минус 3–5 процентов. Итого: 73–75 процентов от прежнего уровня, то есть снижение на 25–27 процентов за первый месяц. К третьему месяцу, после дополнительного кэширования запросов к LLM, вышел на 70 процентов — ровно 30-процентная экономия от старта.

По качеству работы команды: это сложно измерить строгими метриками, но субъективно — первые 2–3 часа рабочего дня стали заметно продуктивнее. Больше не было «режима разгона» после прерванного сна. Команда начинала работать с нормальной концентрацией, а не с ощущением что надо сначала проснуться.

Квартальный ритм: как не допустить повторного накопления долга

Разово почистить систему — это хорошо. Но технический долг накапливается постоянно. Каждые 2–3 месяца в систему добавляется новый скрипт, новая интеграция, новая точка нотификации. Если не проводить регулярных ревизий — через год проблема вернётся в том же или большем объёме.

Я ввёл квартальный аудит — раз в три месяца, один рабочий день. Чек-лист стандартный:

• Пройтись по всем точкам нотификации: добавились новые? Изменился режим работы? Все ли по-прежнему классифицированы правильно?
• Проверить список подписок: не появились новые дубли? Не осталось забытых аккаунтов?
• Проверить топ-5 скриптов по количеству API-вызовов: нет ли аномального роста?
• Сравнить расходы этого квартала с предыдущим: если рост более 15 процентов — понять причину.

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

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

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

Автоматизация бизнеса — это не продукт, который купил и забыл. Это живая система, которая требует ухода. Аудит раз в квартал — минимальный ритм для поддержания здоровья системы. При правильной культуре и документации он занимает не полный день, а 2–3 часа и становится рутиной, а не чрезвычайной мерой.