Заказы из Shopify сами встают в рабочие таблицы склада, формулы и ручные правки целы

Python приводит названия к единому виду

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

Стандартному способу записи не хватало памяти

Первый приёмник был написан на привычном SpreadsheetApp — стандартном способе работать с таблицей из Apps Script. На таблицах такого размера ему постоянно не хватало памяти. Я переписал приёмник на Advanced Sheets Service: теперь он отправляет в Sheets API пакетные запросы и не перебирает ячейки по одной. Приёмник дошёл до 87-й версии: почти каждая новая версия учитывала очередную особенность Google Таблиц.

Вставка в середину таблицы и протяжка формул

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

С подсветкой отмен вышла отдельная история. Правило условного форматирования стояло в таблице, но ни разу не сработало: основной модуль не передавал приёмнику отметку об отмене, и красить было нечего. Масштаб проверили по таблице складского учёта: на 16 478 строк отметки не хватало ровно в одной. Теперь отметка доходит до таблицы, и отменённые заказы действительно подсвечиваются.

Четыре защиты, которые не дают боту испортить работу человека

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

• Запись только поверх формулы. Стоимость доставки пишется только в ячейку с нетронутой исходной формулой. Ячейку, в которую человек вписал значение вручную, бот не трогает.
• Проверка строк перед записью. Если в целевых строках есть хоть что-то, запись отменяется целиком. В журнал и в чат уходит сообщение об отказе с номерами строк, а заказы допишутся при следующем запуске. Поводом стал реальный случай: второй оператор вписал товар в строку без номера заказа, и через 13 минут бот записал туда свой.
• Точка вставки — конец первого сплошного блока строк. Раньше одна съехавшая строка утаскивала вниз каждый следующий заказ. Теперь сдвиг остаётся на месте ошибки.
• Неизвестная команда отклоняется. Раньше неизвестное имя команды попадало в ветку дописывания строк. Из-за опечатки в таблицу как заказы записались бы номера строк, а приёмник ответил бы «успешно». Прежде чем включить эту защиту, я сверил все 19 команд, которые отправляет основной модуль.

Проверка после выпуска заняла три запроса: команда с опечаткой возвращает ошибку, пустое дописывание отвечает «добавлено 0», рабочая команда выполняется как обычно.

Сверка с магазинами только читает таблицу

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

Правила выпадающих списков приходится объединять

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

Восемь таймеров вокруг обмена

Обмен работает без присмотра, поэтому вокруг него настроены задачи по расписанию на таймерах systemd:

• Запись заказов — каждые 30 минут, новые и изменившиеся заказы
• Дневной файл для партнёра — проверка каждые 5 минут, ожидание файла сократилось примерно с 50 минут до 15
• Приём файлов от партнёра по отгрузке — каждые 2 минуты с 7 до 22 по Москве, файлы забираются и из темы группы, и из личной переписки
• Обновление листа с названиями товаров — около 187 успешных сборок в сутки
• Проверка работоспособности — работает ли система и доходят ли записи
• Ежедневная сверка — построчное сравнение таблицы с Shopify
• Ночная резервная копия — снимок таблиц до любых записей следующего дня
• Прогон тестов приёмника — на реальном окружении

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

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

Автоматическое восстановление, которое уступает человеку

Модуль восстановления умел возвращать в таблицу потерянные строки. Но он возвращал и строки, которые человек удалил намеренно. Повторный прогон на реальных снимках таблиц показал 67 таких заказов из 80 возвратов за сутки: в 84% случаев бот спорил с человеком.

Теперь бот ведёт реестр основных номеров заказов, которые уже видел. Реестр собран из 14 ночных снимков, в нём 7696 номеров, и он пополняется при каждой сверке. Перед тем как вернуть строку, бот отличает строку, удалённую человеком, от строки, которую не удалось записать. Если реестр пуст, бот считает, что номера не видел: так даже потерянный файл реестра не отключит восстановление.

Повторный прогон с реестром на тех же данных: 67 возвратов не состоялись бы. Все 13 заказов, которые действительно не записались, были бы восстановлены. Страховка сохранилась полностью, а приоритет отдан решению человека.

Что дала проверка сторожевых скриптов

Сторожевые скрипты имеют смысл, только если проверено, что их сигнал доходит до человека. Проверка дала три находки.

• Сбой одного из двух магазинов незаметно занижал число товаров, которых обещано больше, чем есть на складе, — с 9 до 3. Цифра выглядела хорошей новостью, хотя по ней закупают товар. Товар, заведённый только в упавшем магазине, выпадал из подсчёта целиком.
• Сторож зависших заказов на рабочем компьютере не работал: при запуске по расписанию ему был недоступен ssh-агент с ключами. При этом он писал «источник не отдал заказов, молчу» — теми же словами, какими исправный сторож сообщает, что докладывать не о чем. Запущенный вручную, тот же код нашёл настоящие зависшие заказы возрастом 5 и 11 дней. Проблема ушла после переезда сторожа на сервер.
• Сверка складских таблиц исправно запускалась каждые четыре часа и писала файл, который не открывал ни один человек.

Что показали первые месяцы работы

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

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

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

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

Старая версия кода две недели работала на сервере. У кода, который пишет в рабочие таблицы, не было своей команды выпуска. Код переносили вручную, и версия без одного из исправлений две недели пролежала на сервере незамеченной. Теперь такая команда есть. Она копирует файлы через rsync и ничего не удаляет на сервере: рядом с кодом лежат настройки окружения, суточные файлы и ручные резервные копии. Для кода заведён свой список из 62 файлов, и команда сверяет контрольные суммы каждого.

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

Переход на рабочие таблицы через параллельную запись

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