Оплаченные заказы Shopify → рабочие таблицы склада, без ручного заноса

Нормализация на стороне Python

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

Advanced Sheets Service вместо SpreadsheetApp

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

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

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

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

Четыре предохранителя, которые держат бота в стороне от работы человека

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

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

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

Обратное направление: сверка книги с магазинами — только на чтение

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

Схлопывание перекрывающихся правил валидации

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

Обвязка эксплуатации: восемь таймеров

Обмен работает без присмотра, поэтому вокруг него собран контур эксплуатации на systemd-таймерах:

• Постинг — каждые 30 минут, новые и изменившиеся заказы
• Экспорт файла дня — сетка проверки доведена до 5 минут, ожидание файла сократилось примерно с 50 минут до 15
• Приём входящих файлов от партнёра по отгрузке — каждые 15 минут в окне 7–22 МСК, файлы забираются и из темы группы, и из личной переписки
• Пересборка витрины названий — около 187 успешных сборок в сутки двумя контурами
• Healthcheck — жив ли контур, доезжают ли записи
• Суточная сверка — построчное сравнение книги с Shopify
• Ночной бэкап — снимок книг до любых записей следующего дня
• Прогон тестов приёмника — на реальном окружении

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

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

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

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

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

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

Чего стоила проверка сторожей

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

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

Что показал год эксплуатации

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

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

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

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

Переезд на боевые книги «вторым контуром»

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