Make, automatyzacja wizualna i rozliczenie kredytami

Make, automatyzacja, którą się widzi

Make, wcześniej znany jako Integromat, buduje automatyzacje na płótnie: przeciągasz moduły, łączysz je liniami i widzisz, jak dane płyną przez kolejne kroki. To odróżnia go od narzędzi opartych na liście kroków, gdzie rozgałęzienie jest wpisem w konfiguracji, a nie widoczną gałęzią.

Ta różnica przestaje być kwestią estetyki przy scenariuszu z pięcioma warunkami i trzema ścieżkami. Na liście trzeba go sobie wyobrazić, na mapie po prostu widać, co się dzieje i gdzie dane skręcają.

Scenariusz, moduł i dane

Scenariusz to jedna automatyzacja. Zaczyna się od wyzwalacza, czyli modułu obserwującego zdarzenie, a dalej idą moduły wykonujące działania.

Wyzwalacze dzielą się na dwa rodzaje i ten podział ma wpływ na koszt. Wyzwalacz odpytujący sprawdza źródło co określony czas i zużywa kredyt przy każdym sprawdzeniu, nawet gdy nic się nie zmieniło. Wyzwalacz natychmiastowy czeka na powiadomienie od usługi i zużywa kredyt tylko wtedy, gdy faktycznie coś przyszło.

Wybór wyzwalacza natychmiastowego tam, gdzie jest dostępny, potrafi obniżyć zużycie kilkukrotnie. Scenariusz odpytujący co pięć minut wykonuje niemal dziewięć tysięcy sprawdzeń miesięcznie, z czego większość na pusto.

Dane między modułami przekazujesz przez odwołania do wyjścia poprzednich kroków. Do przekształceń służą funkcje wbudowane, obsługujące tekst, daty, tablice i logikę warunkową, więc proste operacje nie wymagają modułu z kodem.

Kredyty zamiast operacji

Sposób rozliczania zmienił się i to najważniejsza rzecz przy planowaniu budżetu. Wcześniej liczyło się operacje, gdzie każde uruchomienie modułu kosztowało jedną jednostkę. Teraz liczy się kredyty, a różne rodzaje modułów kosztują różnie.

Zwykłe wywołanie modułu kosztuje jeden kredyt. Moduły wykonujące kod, korzystające z modeli językowych albo z funkcji agentowych kosztują więcej, czasem znacznie więcej. To zmienia arytmetykę scenariuszy z elementami sztucznej inteligencji.

Praktyczna konsekwencja: nie da się już oszacować kosztu, licząc moduły w scenariuszu. Trzeba uruchomić go kilka razy i sprawdzić faktyczne zużycie w historii, a potem pomnożyć przez spodziewaną częstotliwość.

Trzy rzeczy obniżają zużycie najbardziej. Pierwsza to filtr umieszczony jak najwcześniej, żeby scenariusz kończył się na drugim module, a nie na dziesiątym. Druga to przetwarzanie wsadowe zamiast osobnego uruchomienia dla każdego elementu. Trzecia to wyzwalacz natychmiastowy zamiast odpytywania.

Obsługa błędów

To obszar, w którym scenariusze produkcyjne różnią się od zabawek, i część najczęściej pomijana. Domyślnie błąd w module zatrzymuje scenariusz, a przy powtarzających się błędach automatyzacja zostaje wyłączona.

Do każdego modułu można dodać ścieżkę obsługi błędu z jednym z kilku zachowań. Ponowienie ma sens przy błędach przejściowych, jak przekroczony limit zapytań. Pominięcie ma sens, gdy pojedynczy nieudany element nie powinien zatrzymywać przetwarzania reszty. Przerwanie z zapisem pozwala wznowić scenariusz po naprawieniu przyczyny.

Wybór zależy od tego, co się dzieje przy błędzie. Jeśli scenariusz wysyła powiadomienia, pominięcie jest w porządku. Jeśli księguje płatności, pominięcie oznacza cichą utratę danych i lepiej zatrzymać całość.

Warto też dodać ścieżkę zapisującą błąd gdzieś, gdzie ktoś to zobaczy: wiadomość na kanale zespołu albo wiersz w arkuszu. Scenariusz wyłączony po cichu w środę zauważa się zwykle w poniedziałek.

Iteratory, agregatory i tablice

Moduł zwracający listę pozycji jest miejscem, w którym najczęściej powstają scenariusze zużywające wielokrotnie więcej kredytów, niż powinny.

Iterator rozbija tablicę na osobne przebiegi, więc moduły za nim wykonują się raz na element. Przy zamówieniu z dwudziestoma pozycjami znaczy to dwadzieścia wywołań każdego kolejnego modułu. Czasem to konieczne, częściej da się tego uniknąć.

Agregator robi rzecz odwrotną: składa wiele przebiegów w jedną strukturę. Typowy wzorzec wygląda tak: iterator rozbija listę, moduł pośredni przetwarza pojedynczy element, agregator składa wynik i dopiero potem następuje jedno wywołanie zapisujące całość.

Ta para pozwala zamienić dwadzieścia zapisów do arkusza na jeden. Różnica w kredytach jest dwudziestokrotna, a wynik ten sam.

Warto też pamiętać o module wyszukującym, który zwraca wiele wyników bez iteratora. Jeśli potrzebujesz tylko pierwszego dopasowania, ustawienie limitu na jeden oszczędza kolejne przebiegi całej dalszej części scenariusza.

Testowanie i wdrażanie zmian

Scenariusz podpięty do prawdziwych danych przy pierwszym błędzie wyśle wiadomość do prawdziwego klienta. Kilka nawyków ogranicza to ryzyko.

Pierwszy to uruchamianie pojedyncze podczas budowy. Przycisk jednorazowego uruchomienia wykonuje scenariusz raz i pokazuje dane wchodzące i wychodzące z każdego modułu, więc widzisz, co faktycznie poszło dalej, zanim włączysz harmonogram.

Drugi to podmiana odbiorcy na czas testów. Adres testowy zamiast prawdziwego, kanał testowy zamiast produkcyjnego, arkusz testowy zamiast bazy. Zajmuje minutę, a oszczędza tłumaczenia się z wiadomości wysłanej przez pomyłkę.

Trzeci to klonowanie scenariusza przed większą zmianą. Kopia pozwala wrócić do wersji działającej, bo platforma nie daje historii zmian w takiej postaci, do jakiej przyzwyczaja kontrola wersji w kodzie.

Czwarty to przegląd historii uruchomień po wdrożeniu. Zapis pokazuje dane każdego przebiegu, więc dzień po włączeniu warto sprawdzić kilka losowych przebiegów zamiast czekać na zgłoszenie.

Agenci i moduły z modelem

Platforma dołożyła warstwę agentową, gdzie zamiast opisywać każdy krok, opisujesz cel i dostępne narzędzia, a model decyduje o kolejności. Do tego dochodzi widok pokazujący całą automatyzację w organizacji.

Rozsądne podejście polega na rozdzieleniu ról. Kroki, które muszą wykonać się dokładnie tak samo za każdym razem, zostawiasz jako zwykłe moduły. Model wpinasz tam, gdzie potrzebna jest ocena treści: klasyfikacja zgłoszenia, streszczenie, wydobycie danych z tekstu.

Odwrotna kolejność, czyli powierzenie modelowi decyzji o kolejności operacji na danych produkcyjnych, jest kusząca i ryzykowna. Automatyzacja ma być przewidywalna, a agent z dostępem do zapisu potrafi zaskoczyć.

Warto sprawdzić status funkcji przed oparciem na niej procesu. Część możliwości agentowych jest udostępniana w wersji otwartej próby, mimo że materiały marketingowe przedstawiają je jako gotowe.

Ceny

Ceny podane wyżej dotyczą rozliczenia rocznego z podstawową pulą kredytów. Zwiększenie puli podnosi stawkę, więc realny koszt zależy bardziej od zużycia niż od wybranego poziomu.

Warto zauważyć jedną rzecz, której z samej tabeli nie widać: wszystkie trzy plany płatne startują z tą samą pulą dziesięciu tysięcy kredytów. Różnią się wyłącznie funkcjami, więc przejście z planu Core na Pro nie da Ci ani jednego kredytu więcej. Jeśli brakuje Ci wolumenu, a nie zmiennych czy obsługi błędów, podnieś pulę na tańszym planie zamiast zmieniać poziom. Rozliczenie roczne obniża przy tym stawkę o kilkanaście procent wobec miesięcznego.

Najczęstsza pułapka polega na wybraniu planu najtańszego i przekroczeniu puli w połowie miesiąca. Dokupienie kredytów w trakcie wypada drożej niż wyższy plan od początku, więc po pierwszym miesiącu pracy warto policzyć rzeczywiste zużycie i dopasować poziom.

Druga rzecz to częstotliwość uruchamiania. Plany niższe ograniczają, jak często scenariusz może się uruchomić, co przy potrzebie reakcji w minutę wymusza wyższy poziom niezależnie od liczby kredytów.

Bezpieczeństwo i dostęp

Automatyzacja z natury ma dostęp do wielu systemów naraz, więc jedno konto potrafi sięgać do poczty, bazy klientów i systemu płatności jednocześnie. To wygodne i warte przemyślenia.

Połączenia do usług zewnętrznych trzymaj jako połączenia, nie jako klucze wpisane w pola modułów. Klucz w polu tekstowym zostaje w konfiguracji i w historii uruchomień, więc widzi go każda osoba mająca dostęp do scenariusza.

Uprawnienia po stronie usług docelowych warto ograniczyć do minimum. Konto techniczne z prawem odczytu wystarcza do scenariusza raportującego, a nadanie mu pełnych uprawnień oznacza, że pomyłka w konfiguracji może skasować dane.

Osobną sprawą jest to, kto może edytować scenariusze produkcyjne. Przy pracy zespołowej scenariusz zmieniony przez jedną osobę działa natychmiast dla wszystkich, bez przeglądu i bez możliwości cofnięcia. Ustalenie, które scenariusze są krytyczne i wymagają uzgodnienia, jest tańsze niż wyjaśnianie, dlaczego przestały działać.

Warto też przejrzeć, jakie dane przechodzą przez platformę. Historia uruchomień przechowuje treść przetwarzanych rekordów, więc przy danych osobowych trzeba sprawdzić okres retencji i to, czy odpowiada wymogom obowiązującym w Twojej organizacji.

Make kontra alternatywy

Wybór między pierwszymi trzema wierszami zależy od trzech rzeczy: czy potrzebujesz rozgałęzień, ile wywołań miesięcznie i czy dane mogą wyjść na zewnątrz. Przy prostym połączeniu dwóch usług prostota drugiego wiersza wygrywa, przy scenariuszu z pięcioma warunkami wygrywa pierwszy, a przy wymogu lokalności trzeci.

Ostatni wiersz warto rozważyć, gdy automatyzacja staje się centralnym elementem procesu. Scenariusz z trzydziestoma modułami i rozbudowaną obsługą błędów to już oprogramowanie, tyle że pisane w interfejsie graficznym i bez testów.

Między pierwszym a ostatnim wierszem leży jeszcze Pipedream, gdzie pojedynczym krokiem jest zwykły kod w Node.js, Pythonie, Go albo Bashu, uruchamiany w chmurze bez własnego serwera, a rachunek idzie za czas obliczeń, nie za liczbę kroków. Dostajesz kontrolę bliską własnemu kodowi bez utrzymywania infrastruktury, płacąc za to tym, że przepływu nie poprawi już osoba nietechniczna.

Sensowna granica przebiega tam, gdzie kończy się łączenie gotowych usług, a zaczyna logika biznesowa. Przeniesienie danych z formularza do bazy i wysłanie powiadomienia to zadanie dla automatyzacji. Naliczanie rabatów według reguł zmieniających się co kwartał to zadanie dla kodu, choćby dlatego, że można je przetestować przed wdrożeniem.

Typowe błędy

Pierwszy to filtr umieszczony na końcu scenariusza. Wszystkie moduły przed nim zużywają kredyty, także dla danych, które i tak zostaną odrzucone.

Drugi to wyzwalacz odpytujący tam, gdzie dostępny jest natychmiastowy. Sprawdzanie co pięć minut przez cały miesiąc to tysiące uruchomień, z których większość niczego nie znajduje.

Trzeci to brak obsługi błędów. Scenariusz zatrzymany po trzech nieudanych próbach zostaje wyłączony i nikt tego nie zauważa, dopóki ktoś nie zapyta, dlaczego dane przestały spływać.

Czwarty to trzymanie kluczy w polach tekstowych zamiast w połączeniach. Klucz wpisany wprost w moduł jest widoczny dla każdego, kto ma dostęp do scenariusza, i zostaje w historii uruchomień.

Piąty to jeden wielki scenariusz zamiast kilku mniejszych. Trzydzieści modułów w jednym przepływie utrudnia diagnozę, a błąd w jednej gałęzi zatrzymuje wszystko.

Szósty to brak środowiska testowego. Scenariusz podpięty od razu do danych produkcyjnych przy pierwszym błędzie wysyła wiadomości do prawdziwych klientów albo modyfikuje prawdziwe rekordy.

FAQ

Czym Make różni się od Zapiera?

Make buduje automatyzacje na wizualnej mapie z widocznymi rozgałęzieniami, co ułatwia scenariusze z wieloma warunkami. Zapier ma więcej gotowych integracji i prostszy model liniowy, lepszy przy łączeniu dwóch usług. Przy dużym wolumenie Make wypada zwykle taniej.

Ile kosztuje Make?

Plan darmowy obejmuje około tysiąca kredytów miesięcznie. Plany płatne zaczynają się od dziewięciu dolarów przy rozliczeniu rocznym i rosną wraz z pulą kredytów. Realny koszt zależy od zużycia, więc po pierwszym miesiącu warto sprawdzić historię uruchomień i dopasować poziom.

Czym są kredyty?

To jednostka rozliczeniowa, która zastąpiła wcześniejsze operacje. Zwykłe wywołanie modułu kosztuje jeden kredyt, a moduły z kodem, modelami językowymi i funkcjami agentowymi kosztują więcej. Dlatego kosztu nie da się oszacować, licząc same moduły, i trzeba sprawdzić faktyczne zużycie.

Czy Make nadaje się do procesów krytycznych?

Tak, pod warunkiem obsługi błędów i powiadamiania o zatrzymaniu. Bez ścieżek obsługi błędów scenariusz zostaje wyłączony po serii niepowodzeń i nikt tego nie zauważy. Przy procesach dotykających pieniędzy warto też przemyśleć, czy pominięcie nieudanego elementu jest dopuszczalne.

Kiedy lepiej napisać własny kod?

Gdy logika jest złożona, wymaga testów albo gdy scenariusz urósł do kilkudziesięciu modułów. Automatyzacja tej wielkości jest już oprogramowaniem, tylko bez kontroli wersji i bez testów, więc przeniesienie jej do repozytorium bywa tańsze w utrzymaniu.

Dokumentacja stoi w centrum pomocy Make, a szczegóły rozliczenia opisuje wpis o zmianach w planach.