Automatizálási hiba: ellenőrzés újrapróbálkozás előtt

Egy automatizálás hibát jelez, és valaki azt javasolja, hogy nyomja meg az „Újrapróbálkozás” gombot. Előtte érdemes egy konkrétabb kérdésre válaszolni: mi hiányzik még? Hiányozhat maga a művelet, annak megerősítése vagy egy későbbi lépés. A teljes folyamat megismétlése ezen helyzetek egyikére alkalmas, de a többit ronthatja.

Egy alapító vagy egy kis csapat számára a vizsgálatnak folytatódnia kell, még akkor is, ha az integrációt beállító személy nincs jelen. Ez az útmutató egy idővonalat és egy adatlapot biztosít a megerősített és az ismeretlen dolgok megkülönböztetésére. A példa fikció: nem ír le Frihet incidenst, és nem használ valós szolgáltatásokat, ügyfeleket vagy hitelesítő adatokat.

A képernyő hibája és a munka állapota

Az időtúllépés azt jelzi, hogy egy várakozás időben történő válasz nélkül ért véget. Önmagában nem teszi lehetővé, hogy megtudjuk, a célhely elmentett-e valamit. Az AWS elmagyarázza ezt a problémát egy olyan kéréssel, amely létrehozhatott volna egy erőforrást, még akkor is, ha a kérelmező nem kapott visszaigazolást. Ennek a bizonytalanságnak a feloldásához azonosítani kell a hatást és annak forrását.

Három állapotban dolgozzon: megerősített hatás, a hatás igazolt hiánya és ismeretlen. A „Nem jelenik meg a képernyőmön” a harmadik kategóriába tartozik, amíg szűrők, más fiók, késve frissülő index vagy még aktív végrehajtás lehetséges. Jegyezze fel azt is, hogy ki és mikor ellenőrizte az állapotot: egy megfigyelésnek van kontextusa, nem örökérvényű.

Egy idővonal, amely megváltoztatja a döntést

Tegyük fel, hogy van egy folyamat, amely egy belső feladatot hoz létre, majd annak hivatkozását egy nyomon követési lapon rögzíti. Minden, ami következik, hipotetikus. Az idők ugyanazt a szimulált órát használják; egy valós vizsgálat során őrizze meg az időzónát és az egyes jelölések forrását.

A következő lépés a nyomon követés dokumentált eljárás szerinti helyreállítása. A „feladat létrehozása” ponttól való újraindítás ismét megérintene valamit, ami már megoldott. Ha az utolsó sor csak annyit mondana, hogy „nem látom a lapon”, akkor is ki kell zárnunk egy késést, egy szűrőt vagy egy aktív folyamatot, mielőtt oda írnánk.

A műveleti hivatkozás stabil marad; a kísérlet azonosítója minden végrehajtással változik. Egy fogadott esemény és egy létrehozott feladat szintén különálló azonosítóval rendelkezik. Őrizze meg a kapcsolataikat, hogy ne tévesszen össze két kísérletet ugyanazon munkára két különálló, érvényes feladattal.

Őrizzen meg egy adatlapot, amelyet más is folytathat

Kezdje azzal, hogy megőrzi a meglévő naplókat, és megakadályozza az új írási műveleteket a folyamathoz tervezett szüneteltetési mechanizmussal. Egy szünet nem vonja vissza a már végrehajtottakat, és nem garantálja a már folyamatban lévő kérések leállítását. Ellenőrizze a várólistát és a függőben lévő újrapróbálkozásokat, mielőtt feltételezné, hogy senki más nem fog cselekedni.

Másolja ezt az adatlapot egy belső, megfelelő hozzáféréssel rendelkező nyilvántartásba. Használjon hivatkozásokat a bizonyítékokra, elkerülve a titkok vagy személyes adatok megosztott dokumentumokba való beillesztését. Minden javítást dátummal kell hozzáadni, a korábbi megfigyelés törlése nélkül.

Incidens: [belső hivatkozás]
Kívánt művelet: [egyetlen konkrét eredmény]
Szolgáltató / fiók / környezet: [a célhely kontextusa]
Művelet / esemény / kísérletek: [azonosítók és kapcsolatok]
Folyamat verziója: [végrehajtott verzió]
Utolsó megerősített lépés: [bizonyíték és időbélyeg időzónával]
Hatás állapota: [igazolt hatás / igazolt hiány / ismeretlen]
Célhely bizonyítéka: [hivatkozás, lekérdezés és láthatósági korlátok]
Még aktív munka: [függőben lévő kérések, várólista és újrapróbálkozások]
Újrapróbálkozási szerződés: [dokumentáció, hatókör és időablak]
Hiányzó adat: [döntéshez szükséges bizonyíték]
Következő lépés: [lekérdezés vagy korlátozott helyreállítás]
Felelős / következő felülvizsgálat: [személy és dátum]
Későbbi eredmény: [új bizonyíték, a korábbi felülírása nélkül]

Az „igazolt hiány” erősebb bizonyítékot igényel, mint egy üres keresés: például egy előzetes, végrehajtás előtti elutasítás, amelyet a célhely dokumentált, az összes többi kísérlet kizárásával. Ha nem tudja igazolni ezt az állapotot, tartsa fenn az „ismeretlen” állapotot.

Az idempotenciakulcs korlátai

Ellenőrizze a szolgáltató szerződését az adott kérésre, fiókra és környezetre vonatkozóan. Egy írási műveletet védő kulcs nem védi automatikusan a későbbi értesítést vagy más szolgáltatást. Nem is adható hozzá visszamenőlegesen egy már kulcs nélkül elküldött kéréshez. Az adatlapnak a vonatkozó dokumentációra kell hivatkoznia, nem csak annyit kell mondania, hogy „van idempotenciánk”.

A Stripe idempotens kérései — API v1 újra felhasználják az első végrehajtás elmentett eredményét, beleértve az 500-as hibákat is. A Stripe összehasonlítja a paramétereket, és legalább 24 óra elteltével törölheti a kulcsokat; egy törölt kulcs újrahasználata újabb kérést indít. Hibaleírásuk figyelmeztet az 500-as hiba utáni lehetséges hatásokra: a kulcs megváltoztatása vagy a lejáratra való várakozás nem bizonyítja, hogy biztonságos egy bizonytalan művelet megismétlése.

Az előző határidő a Stripe-ra vonatkozik. Más célhely esetén jegyezze fel annak saját időablakát, azt az azonosítót, amelyet ismétlődőnek tekint, és a párhuzamos kérések kezelését. Ha egy helyreállítás paraméterek megváltoztatását igényli, azt új döntésnek tekintse, az előző hatások felülvizsgálatával.

Döntés a bizonyítékok alapján, lépésről lépésre

A következő táblázat egy javasolt működési kritérium, nem egy univerzális szolgáltatói politika. Válassza külön a vizsgálatot az adatok módosítására vonatkozó engedélytől.

A visszafordíthatatlan vagy nagy hatású írási műveletekhez a javasolt helyreállítás emberi felülvizsgálata szükséges. Sem egy kulcs, sem egy zöld gomb nem nyújt „pontosan egyszeri” garanciát a teljes útvonalra.

Ellenőrizze azt is, ki fogja újrapróbálni

Előfordulhat, hogy az automatizáló, az API-kliens és a szolgáltató is rendelkezik saját újrapróbálkozásokkal. A Stripe webhookjai esetében a manuális újraküldés nem törli az automatikus újrapróbálkozásokat; ezenkívül az események ismétlődhetnek és sorrenden kívül érkezhetnek. Egy esemény újraküldése sem egyenértékű egy API írási művelet idempotens ismétlésével: ezek különböző mechanizmusok.

Mielőtt bezárná az adatlapot, ellenőrizze a célhely aktuális állapotát, a függőben lévő lépéseket és a később érkező kísérleteket. Határozza meg, ki fogja megfigyelni a következő végrehajtást. Az adatlap bezárása nem egyenlő a munka megoldásával: ha ismeretlen eredmény marad, tartsa nyitva az incidenst felelőssel és felülvizsgálati dátummal.

Ezután felülvizsgálhatja, hogy a folyamat érdemes-e továbbra is automatizálva maradni a a felesleges feladatok elhagyása, automatizálás és delegálás (angolul) kritériumai szerint. Ha Frihet-tel kapcsolódik, használja a fejlesztői dokumentációt és az integrációs katalógust a megfelelő interfész megtalálásához. Őrizze meg ezt az adatlapot a folyamat mellett: a következő személynek képesnek kell lennie megtalálni az utolsó ellenőrzött állapotot anélkül, hogy egy csevegésből újra kellene építenie.

Műszaki források 2026. szeptember 14-én ellenőrizve. Az adatlapok, döntések és DEMO hivatkozások saját didaktikai javaslatok; nem utasítások valós szolgáltatásban történő változtatások végrehajtására.