Перенос сценариев на другую платформу: сроки и потери

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

Поэтому вопрос «за сколько мы переедем» имеет числовой ответ, и он неприятный. Парк из 30 сценариев средней компании — это 285 часов работы: 201 час на пересборку, 40 на то, что не переносится в принципе, и 44 на инвентаризацию, параллельный прогон и корректное отключение старой площадки. По ставке 3 500 ₽/час это 997 500 ₽ и около 47 рабочих дней одного инженера.

Ставку здесь берём по верхней границе вилки инженера (2 500–3 500 ₽), и это не наценка за срочность. Переезд начинается не с написания, а с чтения чужой логики: собиравший её человек часто уже не работает в компании, комментариев нет, а половина условий держалась на договорённости, которую никто не записал. Разбор чужого сценария устойчиво занимает больше времени, чем сборка своего с нуля.

Что копируется, что переписывается, что оформляется заново

Слово «перенести» скрывает три операции с разной ценой. Логика копируется взглядом — её структура видна и повторяема. Узлы переписываются: даже одинаковые по смыслу шаги устроены по-разному. А связи с внешним миром вообще не переносятся: их заводят руками у каждого источника, и именно здесь теряют дни, которых не было в плане.

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

Тридцать сценариев: 285 часов и 47 рабочих дней

Считать переезд «в среднем по сценарию» нельзя: разброс внутри парка десятикратный. Простая связка «форма на сайте → строка в таблице → уведомление» собирается за 2–3 часа. Сценарий с ветвлениями, циклом по позициям, вложениями и обращением к трём системам — за 12–16. Поэтому первое действие — разложить парк на три группы, и сделать это должен тот, кто открывал каждый сценарий, а не тот, кто считает по числу строк в счёте.

Сумма выглядит завышенной ровно до момента, когда её сравнивают с альтернативой. Мы отдельно разбирали чем заменить Zapier и Make — там из 34 сценариев инвентаризация вычеркнула 12 как мёртвые, и переносить пришлось 22. Это самый выгодный час всего проекта: каждый сценарий, признанный ненужным до переезда, экономит от 10 500 до 49 000 ₽. Начинайте не с выбора новой площадки, а с аудита существующих сценариев.

Календарь считается отдельно от часов. Шесть продуктивных часов инженера в день — реалистичный потолок, поэтому 285 часов превращаются в 47 рабочих дней, а не в 36. Вдвоём срок сжимается до 7–9 недель, но не вдвое: параллельный прогон длится столько, сколько длится, и его нельзя ускорить, добавив людей. Выбор площадки при этом на срок почти не влияет — сравнение российских вариантов по девяти параметрам мы вынесли в разбор Albato, ApiX-Drive и Nodul.

Параллельный прогон: сверяем три числа, а не ощущения

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

1. 1Число прогонов. Сколько раз запустился старый сценарий и сколько — новый за те же сутки. Расхождение больше 2 % означает, что новый контур получает не все события: чаще всего забыт один из вебхуков или фильтр на входе отсекает лишнее.
2. 2Число созданных записей. Сколько сделок, документов или строк должно было появиться. Здесь ловится самая частая ошибка пересборки — цикл, который на новой площадке отрабатывает на одну итерацию больше или меньше.
3. 3Суммы и количества. Итог по деньгам и по позициям за сутки. Числа расходятся тогда, когда при переписывании узла преобразования потерялось округление, разделитель дробной части или пересчёт валюты.
4. 4Список расхождений с примерами. Не «есть разница в 3 %», а конкретные пять записей с обеих сторон. Без примеров расхождение не чинится, а объясняется — и объяснение всегда находится.

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

Порядок отключения: шесть шагов, из которых пропускают четвёртый

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

1. 1Заморозить правки на старой площадке. С этого дня любое изменение вносится только в новый контур, иначе к моменту переключения два контура снова разойдутся.
2. 2Переключать источники по одному, начиная с самых редких. Так первая ошибка обходится в единицы событий, а не в весь поток. Между переключениями — сутки наблюдения.
3. 3Дождаться, пока отработает очередь отложенных задач старой площадки. Горизонт — до 30 суток. Пока она не пуста, обе платформы живы одновременно, и часть уведомлений уйдёт дважды, если не отключить дубли вручную.
4. 4Выгрузить журналы прогонов за весь доступный период. На массовых тарифах это 7–30 дней, и они исчезают в момент окончания подписки. Это единственное доказательство того, что событие было обработано, — как устроен нормальный журнал обменов, мы разбирали отдельно.
5. 5Отозвать ключи доступа в системах-источниках, а не просто удалить подключение на площадке. Удалённое подключение перестаёт работать; выданный ключ продолжает существовать и остаётся действующим доступом к вашим данным.
6. 6Продержать подписку ещё один расчётный период после полного переключения. Это самая дешёвая страховка проекта: вернуться на выключенную площадку нельзя, а вернуться на оплаченную — можно за час.

Три приёма, которые делают следующий переезд втрое дешевле

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

1. 1
   Своя точка входа для вебхуков

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

2. 2
   Состояние — в своей базе

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

3. 3
   Тяжёлая логика — в отдельном шаге, а не в двадцати узлах

   Сложные сценарии дороги при переезде не из-за объёма, а из-за того, что логика размазана по узлам. Если расчёт вынесен в один вызов собственного сервиса или в один узел-скрипт, конструктор остаётся оркестратором и пересобирается за 5 часов вместо 14. На шести сложных сценариях это 54 часа, и это самый крупный из трёх эффектов. Где проходит эта граница, мы разбирали в материале о границе low-code и разработки.

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

Когда переносить не надо

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

• Площадка работает, а причина переезда — «слышал, что бывает лучше». Разница в цене операции между площадками почти всегда меньше 997 500 ₽, а разница в удобстве не измеряется вовсе. Переезжают от блокировки, от требований по данным или от упершегося потолка, а не от любопытства.
• Парк меньше десяти сценариев и все простые. Тогда переезд стоит 30–50 часов, и считать его отдельным проектом не нужно — он делается попутно с любой другой работой. Вся эта статья написана про парк, который уже стал хозяйством.
• Процессы меняются прямо сейчас. Переносить сценарий, который через два месяца будет переписан из-за смены учётной системы, — это оплатить одну и ту же работу дважды. Сначала дождитесь, пока процесс устоится, потом перевозите.
• Нет человека, который знает, что делает каждый сценарий. Переезд без этого превращается в археологию: инженер восстанавливает смысл чужой логики по обрывкам и переносит вместе с ней все накопленные ошибки. Сначала — аудит и паспорта сценариев, потом переезд. Иначе вы платите 997 500 ₽ за перевозку беспорядка на новый адрес.

Экспорт сценария — это чертёж, а не переезд. Провода к нему не прилагаются.