Как автоматизировать процесс без кода

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

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

Опишите процесс на бумаге

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

Разберитесь, за что с вас берут деньги

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

Соберите минимальную версию, потом расширяйте

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

Обработайте сбои — именно в них вся разница

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

Держите единый источник истины

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

Сделайте её наблюдаемой прежде, чем на неё опираться

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

Понимайте, когда остановиться

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