Что это решает
Половина автоматизаций в малой компании выглядит одинаково: взять новую строку из таблицы, положить её в CRM, отправить письмо, продублировать в чат. Писать под это код — значит завести репозиторий, сервер, деплой, мониторинг и человека, который всё перечисленное обслуживает. Make и Zapier снимают всю обвязку: авторизация в сервисах в пару кликов, готовые коннекторы к тысячам приложений, запуск и повторы на их стороне, журнал выполнений в интерфейсе. Связка собирается за вечер человеком без разработчика, и первые месяцы она стоит дешевле часа программиста.
Как устроено
Обе платформы построены на одной схеме: событие-триггер запускает цепочку шагов-действий, между шагами едут данные, поля следующего шага заполняются значениями из предыдущих.
Триггеры: мгновенные и опросные
Мгновенный триггер работает на вебхуке: сервис сам сообщает платформе о событии, цепочка стартует в пределах секунд. Опросный триггер — платформа ходит в сервис по расписанию и ищет новое. Интервал опроса привязан к тарифу: на младших планах пауза заметная, на старших короче. Ошибка проектирования, которая всплывает позже всего: сценарий рассчитан на реакцию «сразу», а под ним опросный триггер, и «сразу» на самом деле означает «когда-нибудь в ближайшие минуты».
Zapier
Единица — Zap: один триггер и последовательность действий. Ветвление делается через Paths, отсев — через Filter, преобразование дат, строк и чисел — через Formatter. Есть шаг с кодом на JavaScript или Python, есть приём и отправка произвольных HTTP-запросов (отдельным премиальным приложением). Тарификация — по задачам: считается каждое выполненное действие; триггеры и отсечённые фильтром прогоны обычно не тарифицируются. Журнал прогонов (Zap history) показывает данные каждого шага, у платных планов есть автоматический перезапуск упавших.
Make
Единица — сценарий: холст с модулями и связями, ближе к схеме, чем к списку. Есть роутеры (несколько веток из одной точки), итераторы (разложить массив на элементы) и агрегаторы (собрать элементы обратно в один пакет) — эта пара закрывает работу с коллекциями, которая в линейной модели даётся тяжело. Обработчики ошибок вешаются на конкретный модуль с выбором поведения: пропустить, прервать, повторить, откатить. Незавершённые прогоны складываются в отдельную очередь и запускаются повторно вручную. Тарификация — по операциям: каждое срабатывание каждого модуля списывает единицу.
Хранение доступов
Подключение к сервису — это OAuth-токен или ключ API, сохранённый на стороне платформы. С этого момента внешний сервис имеет постоянный доступ к почте, диску, CRM и бухгалтерии под правами того, кто нажимал кнопку подключения. Права выдаются один раз и обычно широкие: конкретный коннектор запрашивает весь набор разрешений, а не тот минимум, что нужен сценарию.
Когда коннектора не хватает
У обеих платформ есть универсальный HTTP-модуль: произвольный метод, заголовки, тело, разбор ответа. Через него подключается любой API, у которого нет готового коннектора, — ценой ручной работы с авторизацией и обновлением токена. Как только в сценарии появляется три-четыре таких модуля подряд, экономия относительно собственного кода испаряется.
Полезные сценарии
- Лид с сайта или из рекламного кабинета → карточка в CRM → уведомление ответственному в мессенджер.
- Новый счёт или платёж → строка в таблицу учёта → напоминание бухгалтеру в конце недели.
- Заявка в форме поддержки → тикет в трекере → автоответ клиенту с номером обращения.
- Публикация контента: одна запись в базе → форматирование под каждую площадку → постинг по расписанию.
- Разовая миграция данных между сервисами, где писать скрипт дороже, чем один раз прогнать пакет через готовые коннекторы.
Ограничения
Стоимость растёт нелинейно. Тарификация идёт от количества операций, а не от пользы. Цикл по сотне позиций заказа — это сотня списаний, а не одно. Сценарий, который опрашивает сервис каждые несколько минут и в 95% случаев не находит ничего нового, всё равно тратит операции. Проверять расход надо не в момент сборки, а на реальном объёме через неделю работы.
Логика живёт в чужом интерфейсе. Сценарий нельзя положить в git, посмотреть построчный диф, прогнать тестами и откатить одной командой. Экспорт есть, но это слепок, а не история изменений. Кто менял поле в третьем модуле полгода назад — вопрос без ответа.
Данные уходят за периметр. Через платформу проезжают персональные данные клиентов, содержимое писем и документов. Для российской компании это отдельный юридический вопрос о месте обработки и хранения — решается с юристом до запуска, а не после проверки.
Оплата из России не проходит российской картой. Это упирается либо в зарубежное юрлицо, либо в посредников, либо в отказ от платформы — и решать вопрос приходится в момент, когда десяток боевых сценариев уже работает.
Покрытие российских сервисов выборочное, а глубина готового коннектора часто ограничена базовыми методами. Всё, что за пределами — снова HTTP-модуль руками.
Отладка ограничена журналом. Точки останова нет, пошагового прохода по коду нет; доступны входы и выходы модулей за период хранения истории, который тоже привязан к тарифу.
Лимиты со стороны конечных сервисов никуда не деваются. Пакетная заливка через коннектор упирается в rate limit API и падает — платформа при этом честно спишет операции за каждую неудачную попытку.
Как проверить результат
Пробный прогон в редакторе и боевая работа расходятся чаще, чем кажется: в тесте данные подставляются вручную или берётся последняя запись, а в бою прилетает то, чего в тесте не было — пустое поле, кириллица в идентификаторе, массив вместо строки. Поэтому после включения проверяется первое настоящее событие целиком, по журналу, а не по факту «зелёный статус».
В журнале смотреть надо не итог, а вход и выход каждого шага. Типовая находка: шаг отработал успешно, но в поле уехала пустая строка, потому что источник назвал колонку иначе. Формально всё зелёное, фактически в CRM появились карточки без телефона.
Повтор события проверяет идемпотентность: одно и то же событие прогоняется дважды и в целевой системе должна остаться одна запись. Если появились две — в сценарий добавляется поиск существующего объекта перед созданием.
Расход операций контролируется по счётчику в кабинете на реальной неделе. Резкий рост означает либо цикл там, где его не планировали, либо опросный триггер, который срабатывает вхолостую.
Поведение при ошибке проверяется намеренно: временно ломается доступ к целевому сервису, после чего смотрится, что сделала платформа — повторила, отложила в очередь незавершённых, тихо пропустила событие. Третий вариант означает, что нужен отдельный обработчик ошибок и уведомление.
Уведомления о падениях включаются сразу и адресуются живому человеку, а не общему ящику. Сценарий, который отключился по ошибке авторизации и молчит две недели, обнаруживается по жалобе клиента.
Отдельно проверяется срок жизни подключений: OAuth-токены протухают, и коннектор отваливается через месяцы после настройки. Признак — прогоны с ошибкой авторизации в журнале; лечится переподключением аккаунта и напоминанием в календаре.