Мониторинг 700+ Google Таблиц

Google Apps Script убивает скрипт через 6 минут. Без предупреждения, без возможности продлить — просто обрывает выполнение. Когда нужно обработать десяток таблиц, это не проблема. Когда таблиц больше семисот — это становится главным ограничением проекта.

Этот кейс — про то, как мы построили систему мониторинга на платформе, которая для этого не предназначена. И почему клиент был прав, когда настоял именно на Google Apps Script.

Про бизнес

К нам пришла компания из сферы срочного выкупа автомобилей. Агенты работают в нескольких городах, каждый ведёт сделки в Google Таблицах — заявки, осмотры, выкупы, расходы, логистика, выплаты. За годы работы накопилось больше 700 таблиц.

Менять систему учёта клиент не планировал. Команда привыкла к таблицам, процессы выстроены, люди обучены. Переезд в CRM или ERP — это месяцы, деньги и сопротивление сотрудников. Задача была другой: не менять инструмент, а научиться его контролировать.

Что занимало 2.5 часа каждый день

Операционный директор начинал утро с ручного обхода таблиц. Открывал одну за другой, сверял суммы, искал незаполненные поля, проверял, работают ли агенты или простаивают. При 700 таблицах физически можно проверить 40-60 за день — это около 8% от общего числа.

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

На эту проверку уходило 2-2.5 часа ежедневно. Не считая времени на разбор найденных проблем.

Почему нельзя было оставить как есть

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

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

Что мы построили

Система работает как конвейер: каждые 5 минут запускается проверка, которая проходит по всем 700+ таблицам, находит изменения, проверяет данные по правилам и отправляет сводку операционному директору в Telegram. Он открывает телефон утром — и видит не 700 таблиц, а список конкретных проблем, которые требуют внимания.

Звучит просто. Но треть времени разработки ушла не на логику мониторинга, а на борьбу с ограничениями платформы.

Шесть минут и ни секундой больше

Google Apps Script принудительно завершает любой скрипт через 6 минут. Для 700 таблиц этого категорически не хватает. Мы написали менеджер времени выполнения, который работает как чекпоинт-система: за 30 секунд до лимита скрипт сохраняет текущую позицию в хранилище и планирует продолжение через новый триггер. Один полный цикл — это 3-5 последовательных запусков, каждый из которых продолжает с того места, где остановился предыдущий.

Квоты API: 700 таблиц — это 700 обращений

Google Sheets API ограничивает количество операций чтения и записи. При 700 таблицах в эти лимиты упираешься очень быстро. Мы сделали систему кеширования с пакетными операциями: если таблица не изменилась — к ней не обращаемся вообще. Изменения отслеживаем через MD5-хеш содержимого. Нет вебхуков, нет подписки на события — Google Apps Script этого не умеет. Только периодический опрос и сравнение хешей.

Нет очереди задач — построили свою

В Node.js есть Redis, Bull, десятки готовых решений. В Google Apps Script нет ничего. Мы построили собственную очередь задач поверх PropertiesService — это хранилище пар «ключ-значение» с лимитом 500 КБ на ключ и 9 МБ на весь скрипт. Не база данных, но для хранения статусов, приоритетов и времени выполнения задач — достаточно.

Одна проблемная таблица не должна блокировать остальные

API иногда отвечает ошибками 429 (слишком много запросов) или 500 (внутренняя ошибка). Если одна таблица вызывает ошибку и скрипт останавливается — остальные 699 остаются непроверенными. Мы реализовали exponential backoff с circuit breaker: проблемная таблица откладывается на потом, а остальные обрабатываются без задержек.

Ограничения памяти

V8-рантайм в Google Apps Script работает с ограниченной кучей. Загрузить данные из 700 таблиц в память одновременно невозможно — скрипт просто упадёт. Обрабатываем порциями по 20-30 таблиц за проход, сбрасывая промежуточные результаты в сводную таблицу после каждой порции.

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

Было: 2.5 часа ежедневной ручной проверки, покрытие — 40-60 таблиц из 700 (8%).

Стало: 10 минут на просмотр готовой сводки в Telegram, покрытие — все 700+ таблиц каждые 5 минут.

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

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

Срок разработки составил 25 дней в 4 этапа. Стоимость — 120 000 рублей, плюс 15 000 рублей в месяц на поддержку. При зарплате операционного директора и стоимости потерь от задержек в контроле система окупилась примерно за два месяца.

Чего мы не скрываем

Google Apps Script — не серверная платформа. Мы это понимали с самого начала. Треть времени разработки ушла не на бизнес-логику, а на обход ограничений: лимит 6 минут, квоты API, отсутствие вебхуков, ограничения памяти. На Node.js с нормальной базой данных и очередью задач это было бы проще. Но клиент остаётся в экосистеме Google — и для него это было принципиально.

При росте до 1500+ таблиц потребуется оптимизация или миграция. Текущая архитектура выдерживает 700-800 таблиц с запасом. Но PropertiesService — не база данных, а MD5-опрос — не вебхуки. При удвоении нагрузки, возможно, придётся выносить часть логики за пределы GAS.

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

PropertiesService — это 500 КБ на ключ и 9 МБ на скрипт. Хватает, но впритык. Данные приходится ротировать и сжимать. Это не то хранилище, в котором хочется держать состояние системы — но другого в GAS нет.

Технический стек

Компонент	Технология
Платформа	Google Apps Script (V8 runtime)
Данные	Google Sheets API, SpreadsheetApp
Хранение состояния	PropertiesService (9 МБ лимит)
Отслеживание изменений	MD5-хеширование содержимого таблиц
Очередь задач	Собственная реализация поверх PropertiesService
Уведомления	Telegram Bot API
Устойчивость	Exponential backoff, circuit breaker
Watchdog	Отдельный GAS-скрипт, мониторит основной

Архитектура системы

Система состоит из трёх компонентов: основной скрипт мониторинга, сводная таблица с результатами и watchdog-скрипт.

Основной скрипт запускается по time-based триггеру каждые 5 минут. Менеджер времени выполнения отслеживает оставшееся время и за 30 секунд до 6-минутного лимита GAS сохраняет позицию в PropertiesService и создаёт триггер для продолжения. Один полный цикл обработки 700+ таблиц — это 3-5 последовательных запусков.

Очередь задач реализована как JSON-структура в PropertiesService: массив ID таблиц с приоритетами, статусами и временем последней проверки. Таблицы с ошибками получают пониженный приоритет (circuit breaker) и проверяются реже, чтобы не блокировать остальные.

Обработка идёт порциями по 20-30 таблиц за проход. Для каждой порции: чтение MD5-хеша из кеша → сравнение с текущим → при изменении — чтение данных, валидация по правилам, запись результатов в сводную таблицу. После каждой порции — сброс промежуточных данных для экономии памяти.

Частые вопросы

Можно ли мониторить сразу несколько Google Таблиц одним скриптом?

Да. Google Apps Script позволяет обращаться к любой таблице по ID через SpreadsheetApp.openById(). В нашем случае один скрипт централизованно обрабатывает 700+ файлов. Ключевое ограничение — не количество таблиц, а время выполнения и квоты API.

Как обойти лимит 6 минут в Google Apps Script?

Скрипт отслеживает оставшееся время и за 30 секунд до лимита сохраняет текущую позицию. Затем через time-based триггер запускается новый экземпляр, который продолжает с сохранённой точки. Один полный цикл обработки разбивается на 3–5 последовательных запусков.

Сколько стоит такая автоматизация?

Зависит от количества таблиц, правил проверки и требований к уведомлениям. В описанном проекте разработка заняла 25 дней и стоила 120 000 ₽. Поддержка — 15 000 ₽ в месяц. Окупаемость — около двух месяцев.

Результат в цифрах

Было	Стало
2.5 часа ручной проверки каждый день	10 минут на просмотр сводки в Telegram
Покрытие 8% таблиц (40-60 из 700)	100% таблиц каждые 5 минут
Расхождения обнаруживались через 2-3 дня	Обнаружение в тот же день
912 часов в год на ручной контроль	0 часов — система работает сама

Окупаемость: ~2 месяца при стоимости разработки 120 000 руб.