Czemu automatyzacja psuje się w piątek o 17

Automatyzacja nie psuje się w poniedziałek rano, kiedy wszyscy patrzą. Psuje się w piątek po południu, w noc przed świętem albo w środku sezonu, bo wtedy ruch jest największy, a ludzie najmniej uważni. Teza tego wpisu: o jakości integracji nie świadczy to, jak działa, gdy wszystko idzie dobrze, tylko to, co robi, gdy coś pójdzie źle. A coś zawsze idzie źle.

Trzy rzeczy, które się psują zawsze

1. Drugi system chwilowo nie odpowiada. Program księgowy ma przerwę techniczną, kurier aktualizuje API, serwer jest przeciążony. To nie jest awaria Twojego sklepu, ale to Ty tracisz zamówienie.
2. Dane są inne, niż zakładał twórca integracji. Pole z numerem telefonu zawiera litery, adres nie ma kodu pocztowego, produkt został usunięty z magazynu.
3. Ta sama wiadomość przychodzi dwa razy. Systemy nie są pewne, czy dostarczyły powiadomienie, więc wysyłają je ponownie. Bez ochrony wychodzą dwie faktury za jedno zamówienie.

Webhook: powiadomienie zamiast pytania

Webhook to sposób, w jaki system mówi drugiemu „coś się wydarzyło”. Kiedy klient zapłaci, operator płatności wysyła wiadomość do sklepu. To lepsze niż odpytywanie co minutę, ale ma wadę: jeśli w tej chwili nikt nie słucha, wiadomość przepada. Dlatego sam webhook nie wystarcza.

Kolejka: bufor, który nie gubi

Dobra integracja nie wykonuje pracy w chwili, gdy dostanie wiadomość. Zapisuje zadanie w kolejce i dopiero wtedy je realizuje. Jeśli drugi system nie odpowiada, zadanie zostaje w kolejce i próbuje się jeszcze raz po kilku minutach, potem po godzinie. Dzięki temu chwilowa awaria kogoś trzeciego nie zamienia się w utracone zamówienie.

Idempotencja, czyli „raz, a dobrze”

To brzydkie słowo oznacza prostą rzecz: wykonanie tej samej operacji dwa razy daje taki sam skutek jak raz. W praktyce integracja zapamiętuje identyfikator zamówienia i przy drugim zgłoszeniu mówi „to już zrobiłem”. Bez tego powtórzona wiadomość to podwójna faktura, podwójna rezerwacja albo dwie paczki.

Co zobaczy człowiek, gdy coś się nie uda

Najgroźniejsze są błędy ciche. Dlatego dobry przepływ ma trzy elementy:

• Log: zapis każdego zdarzenia i wyniku, żeby dało się odtworzyć, co się stało z konkretnym zamówieniem.
• Alarm: powiadomienie dla osoby, która wie, co zrobić, wysłane od razu, a nie w raporcie po tygodniu.
• Ekran wyjątków: lista zadań, które się nie wykonały, z powodem i przyciskiem „spróbuj ponownie”.

Checklista przed uruchomieniem

1. Co się stanie, jeśli drugi system nie odpowie przez godzinę?
2. Co się stanie, jeśli dostanie to samo zamówienie dwa razy?
3. Co zobaczy człowiek, jeśli dane są niepoprawne?
4. Kto dostaje alarm i czy jest dostępny w weekend?
5. Czy wiemy, jak ręcznie dokończyć zamówienie w razie problemu?

Jeśli na któreś pytanie odpowiedź brzmi „nie wiem”, integracja jeszcze nie jest gotowa.

Oś czasu jednego piątkowego popołudnia

Zobaczmy, jak ta sama awaria wygląda w dwóch wersjach integracji. Przykład ilustracyjny: o 16:50 program do faktur ma krótką przerwę techniczną trwającą 40 minut. W tym czasie wpływa 25 zamówień.

Integracja bez kolejki i bez alarmów.

• 16:50: pierwsze zamówienie próbuje wystawić fakturę, dostaje błąd. Zamówienie jest zapisane w sklepie, faktury brak.
• 17:30: program działa, ale nic nie ponawia prób.
• Poniedziałek: księgowa zauważa, że brakuje 25 faktur. Trzeba je ustalić ręcznie, część klientów już się upomniała.

Integracja z kolejką, ponawianiem i alarmem.

• 16:50: zadania wystawienia faktur trafiają do kolejki i czekają.
• 16:55, 17:05, 17:25: system ponawia próbę, za każdym razem po dłuższej przerwie.
• 17:32: program wraca do pracy, kolejka wykonuje wszystkie 25 zadań w kilka minut.
• 17:35: osoba odpowiedzialna dostaje krótką informację: „przerwa u dostawcy faktur, 25 zadań wykonanych, 0 błędów”.

Różnica nie polega na technologii, tylko na tym, czy ktoś pomyślał o dniu, w którym coś pójdzie nie tak.

Minimalny zestaw obsługi błędów

Jeśli budujesz lub zlecasz integrację, poproś o te cztery rzeczy:

1. Kolejkę zadań z ponawianiem i rosnącymi odstępami między próbami.
2. Limit prób i „kolejkę martwych zadań”: miejsce, gdzie trafiają zadania, których nie udało się wykonać mimo ponowień.
3. Powiadomienie (e-mail lub komunikator) z krótkim opisem, nie z wydrukiem technicznym.
4. Ekran z listą problemów i przyciskiem „spróbuj ponownie”, dostępny dla osoby nietechnicznej.

Test, który warto wykonać raz w kwartale

Wyłącz na chwilę (w środowisku testowym) jeden z połączonych systemów i złóż kilka zamówień. Sprawdź, czy kolejka zadziała, czy alarm dotrze i czy po przywróceniu wszystko się domknie. Integracja, która nigdy nie była testowana w awarii, jest nieprzetestowana.

Podsumowanie

Różnica między integracją, która działa w demonstracji, a taką, której można zaufać w sezonie, to kolejki, ponawianie, ochrona przed duplikatami i widoczne błędy. Zaprojektowanie ich zajmuje część czasu, ale to właśnie ta część chroni Cię w piątek o 17. Poprzednio w cyklu: czy program księgowy da się zintegrować ze sklepem. Chcesz zbudować integrację, której można zaufać? Zobacz aplikacje i integracje.