Automatizace,
která počítá
s chybou.

Z čeho vycházím: U automatizovaného nákupního procesu jsem řešil frontu požadavků, stav jednotlivých úloh, odmítnutí duplicit a ukončení před krokem, který musí potvrdit člověk.

Nejčastější chyba: automatizovat jen šťastnou cestu

Demo obvykle vypadá jednoduše: přijde požadavek, systém provede kroky a vrátí výsledek. V provozu ale do toho vstoupí pomalé API, odhlášená session, změněný formulář nebo výpadek služby.

Proto si před implementací kreslím nejen průchod, ale i stavy, které mohou nastat. Úloha může být čekající, zpracovávaná, dokončená, odmítnutá, opakovaná nebo nejasná. Nejasný stav je důležitý: systém nesmí předstírat úspěch jen proto, že nedostal chybu.

Fronta odděluje požadavek od provedení

Pokud uživatel čeká na celý proces v jednom HTTP požadavku, vznikne křehké řešení. Fronta umožní požadavek přijmout, zpracovat ho samostatně a průběžně ukazovat stav.

• Požadavek dostane vlastní identifikátor.
• Worker si vezme jednu úlohu a zapíše začátek zpracování.
• Každý důležitý krok uloží výsledek nebo důvod selhání.
• Uživatel vidí, zda se čeká, pracuje, opakuje nebo je potřeba zásah.

Fronta musí mít pravidla pro timeout, maximální počet pokusů a způsob, jak se ručně vyřeší úloha, která se opakovaně vrací.

Opakování musí být bezpečné

Retry řeší dočasný problém, ale může vytvořit nový. Pokud první požadavek na straně služby proběhl a odpověď se ztratila, druhý pokus může provést stejnou operaci podruhé.

Proto rozlišuji operace, které lze bezpečně zopakovat, od operací s vedlejším účinkem. Pomáhá idempotency key, evidence provedených kroků, kontrola aktuálního stavu a limity. U plateb nebo nákupů je zkušební běh a ruční potvrzení často důležitější než maximální rychlost.

Co musí být v logu

Log nemá být výpis všeho, co aplikace udělala. Potřebuji z něj zjistit, co se stalo s konkrétní úlohou:

• identifikátor úlohy a čas zahájení,
• typ operace a bezpečný kontext,
• krok, na kterém se proces zastavil,
• typ chyby a počet předchozích pokusů,
• výsledek nebo důvod předání člověku.

Citlivé tokeny, hesla a celé odpovědi externích služeb do logu nepatří. Diagnostika musí pomoci vývojáři, ale nesmí vytvořit další bezpečnostní problém.

Co ukazuji klientovi před předáním

Neukazuji jen zelený průchod. Procházíme i timeout, odmítnutí, duplicitní požadavek a obnovení po přerušení. Pokud je určitý krok citlivý, je součástí návrhu jasné místo pro ruční kontrolu.