Megbízható munkafolyamat-automatizálás tervezése: hogyan marad megbízható a működésben

A megbízható munkafolyamat-automatizálást a hibalehetőségre tervezik, nem csak a sikeres útra. Egy élesben futó munkafolyamat egyértelmű határral indul, látható állapotban tartja a futásokat, az ismételt futtatást normális eseményként kezeli a meglepetés helyett, korlátok közé szorítja az újrapróbálkozásokat, előre eldönti, mi történik, ha az egyik lépés sikerül és a következő nem, és megfigyelhető nyomot hagy, amelyre a helyreállítás, a felülvizsgálat és a megfelelő emberi kontrollpontok épülhetnek. Az automatizálás akkor megbízható, ha a „mi történik, ha ez meghiúsul?” kérdésre minden lépésnél van egy megtervezett válasz – nem pedig akkor, ha egy indítóeseménytől a műveletig vezető, csak a sikeres utat leíró folyamat éppen működik egy bemutatóban. Azt, hogy egy munkafolyamatot egyáltalán automatizálni kell-e, külön döntés, amelyet a munkafolyamat-automatizálás rangsorolási útmutatója (/resources/mit-automatizaljunk-eloszor) tárgyal; ez a minta azoknak az automatizálásoknak a tervezéséről szól, amelyeket már érdemes megépíteni.

A részleges és függőségi hiba a működés várható állapota, nem pedig szélső eset. Egy olyan munkafolyamatban, amely lépéseket, rendszereket és átadásokat fog át, normális, hogy egy lépés sikerül és a következő nem, hogy egy külső rendszer átmenetileg elérhetetlen, hogy egy üzenet kétszer érkezik meg, vagy hogy egy futtatás olyan állapotban áll meg, amelyet egyetlen lépés sem tud megmagyarázni. A hibalehetőségre való tervezés azt jelenti, hogy ezek a feltételek láthatóvá, megnevezetté és kezelhetővé válnak, még mielőtt bekövetkeznének: milyen állapotban van a futtatás, mi próbálható újra biztonságosan, minek kell emberhez kerülnie, és mit soha ne tegyen meg a rendszer automatikusan. Az az automatizálás, amely a sikeres útból indul ki, nem válik elegánsabbá, amikor hibázik; terv nélkül hibázik.

Egy megbízható munkafolyamat egy olyan határral kezdődik, amely megnevezi, mi van az automatizáláson belül és mi azon kívül. A határ felsorolja a részt vevő rendszereket és azokat a szereplőket, akik velük dolgoznak, az indítóeseményt, amely elindít egy futtatást, azokat a lépéseket, amelyeket a munkafolyamat végrehajt, és a felelősségi határt – ki a munkafolyamat gazdája, ki dönt az egyes döntési pontokon, és ki tartozik elszámolással, ha egy futtatás meghiúsul. A határ megnevezi azt az állapotot is, amelytől a munkafolyamat függ, és amelyet módosíthat. Minden részt vevő rendszer a munkafolyamat szemszögéből meghatározott viselkedésű függőségként kezelendő; ahol magukat a rendszerek közötti kapcsolatokat kell megtervezni – szerződések, tulajdonlás és átadási szemantika –, ott az integrációs és API-stratégia útmutató (/resources/fragmentalt-rendszerek-osszekotese) a témakör. Az explicit határ az, ami megakadályozza, hogy egy munkafolyamat csendben megnőjön, amíg olyan viselkedés tulajdonosává nem válik, amelyet senki sem rendelt hozzá.

Meg kell határozni, mi indít el egy futtatást, és mit dolgozhat fel egy futtatás. Az indítóesemény explicit – esemény, ütemezés, állapotváltozás vagy kézi indítás –, hozzá tartoznak azok a feltételek, amelyek mellett egy futtatás létrejön, és biztosítani kell, hogy ugyanaz a mögöttes esemény ne indítson csendben több különböző futtatást. A bemeneti szerződés megnevezi az elfogadott bemeneteket, azok alakját és korlátait, és meghatározza a hibás, hiányos vagy a megengedett tartományon kívüli bemenetek kezelését: látható módon el kell utasítani vagy kivételútra kell terelni őket, soha nem szabad érvényesként feldolgozni. A szerződés azt is rögzíti, mit jelent egy ismételt indítóesemény ugyanarra a mögöttes munkára – ez közvetlenül ahhoz a kérdéshez vezet, hogyan kezelik a duplikátumokat.

Minden futtatásnak meghatározott állapotban kell léteznie, és minden állapotátmenetnek tudatosnak kell lennie. A munkafolyamat-modell megnevezi azokat az állapotokat, amelyeken egy futtatás áthalad – várakozó, folyamatban, jóváhagyásra váró, kivételkezelés alatt, befejezett, meghiúsult, megszakított –, és azt, hogy mi igaz az egyes átmeneteknél. A rejtett működési állapot a megbízhatóság ellensége: az a futtatás, amelynek valódi állapota csak egy beérkező levelek mappájában, egy várakozási sor mélységében vagy valakinek az emlékezetében él, nem üzemeltethető, nem állítható helyre és nem ellenőrizhető. Ha egy állapot nem látható a munkafolyamat-modellben, a munkafolyamat nem vonható felelősségre érte.

Az idempotencia az ismételt alkalmazásról szól, nem az eredmények egyformaságáról. Egy munkafolyamat egy lépése többször is lefuthat – újrapróbálkozás, duplikált indítóesemény, kézi újrafuttatás vagy újra kézbesített üzenet miatt –, és ahol a művelet idempotens viselkedést igényel, ott ez az ismételt alkalmazás nem hozhat létre további, nem szándékolt üzleti hatásokat. A tervezés során meg kell nevezni azokat a lépéseket, amelyek hatásait nem szabad megduplázni – rekord létrehozása, kommunikáció küldése, kifizetés jóváhagyása, készlet csökkentése –, és ezeket a lépéseket úgy kell kialakítani, hogy biztonságosan újra alkalmazhatók legyenek, miután már kifejtették a hatásukat. Azok a lépések, amelyek csak olvassák vagy átalakítják az adatokat, általában nem igényelnek külön kezelést. Ahol egy lépés nem tehető biztonságosan ismételhetővé, ott az őszinte tervezés védelmi ponton vagy emberi határon vezeti át, ahelyett hogy abban bízna, hogy a duplikátumok soha nem érkeznek meg.

Az újrapróbálkozás politika, nem hurok. Meg kell határozni, mely lépések jöhetnek egyáltalán szóba újrapróbálkozásra – az a lépés, amely bármilyen hatás kifejtése előtt hiúsult meg, más eset, mint az a lépés, amelynek hatása bizonytalan –, hány kísérletet tehet egy futtatás, és mennyit vár a munkafolyamat a kísérletek között, ahol a backoff fogalmilag a kísérletek időbeli szétválasztását jelenti, hogy egy hibás függőséget maga a munkafolyamat ne terheljen tovább. Az időkorlátok behatárolják, meddig futhat egy lépés, mielőtt a munkafolyamat meghiúsultként kezeli, és az időkorlát a hibaszerződés része: mit tud a munkafolyamat, és mit kell feltételeznie, amikor a határ elérésre kerül. Bármik legyenek is az értékek, a politikának korlátosnak és láthatónak kell lennie. A korlát nélküli újrapróbálkozási hurok nem reziliencia; olyan üzemzavar, amely önmagát tartja életben.

Feltételezni kell, hogy a futtatások úgy érnek véget, hogy egyes lépések elkészültek, mások nem. Ha egy külső függőség nem érhető el, a munkafolyamat nem állhat meg némán: látható hibaállapota és meghatározott útja van. Ha egy lépés kimenete bizonytalan – a lépés hatással lehetett, még ha nem is erősítette meg –, a munkafolyamat nem találgathat. A fogalmi válaszokat meg kell különböztetni, és tudatosan kell alkalmazni: újrapróbálkozás az átmeneti feltételeknél, ahol az ismétlés biztonságos; kompenzáció ott, ahol egy korábbi hatást vissza kell fordítani vagy semlegesíteni kell, mert egy későbbi lépés nem fejeződhet be; kivételkezelés ott, ahol a hiba meghatározott automatikus utat követ; és emberi megoldás ott, ahol egyik sem biztonságos vagy elegendő. Ha ezeket a válaszokat összekeverik, a részleges hibákból duplikált hatások, felül nem vizsgált hiányosságok és véletlenül született döntések lesznek.

Nem minden lépésnek ugyanaz a szerződése egy munkafolyamatban. A determinisztikus lépéseket – egy szabályt, egy leképezést, egy érvényesítést, egy állapotátmenetet – pontosan és ismételhető elvárások szerint kell kezelni: meghatározott bemenetek, meghatározott kimenetek, meghatározott hibaviselkedés, és nincs dokumentálatlan változékonyság a futtatások között. Ahol a változékonyság elfogadható – egy döntés, amely mérlegeléstől függ, egy értelmezés, amelynek legitim eredménytartománya van, egy kimenet, amelyet használat előtt felülvizsgálnak –, ott a munkafolyamatnak explicit módon be kell határolnia ezt a változékonyságot: meg kell nevezni a lépést változóként, rögzíteni, mi elfogadható és mi nem, és a döntést vagy a felülvizsgálatot oda kell tenni, ahol a következmények megkövetelik. A megbízhatóság abból származik, hogy a kettőt nem keverik össze: ha a változó munkát determinisztikus mércével mérik, hamis bizalom keletkezik, ha pedig a determinisztikus munkát lazán kezelik, csendes eltérés keletkezik. Ez a munkafolyamat-lépésekről szóló mérnöki megkülönböztetés, és attól függetlenül érvényes, hogy ki vagy mi hajtja végre a lépést.

Az emberi bevonódást egy munkafolyamatban a következmények szerint kell kijelölni, nem alapból szétszórni. A jóváhagyás, a kivételkezelés és az eszkaláció oda tartozik, ahol a tévedés költséges vagy visszafordíthatatlan: kifizetés vagy áru jóváhagyása, a vállalat elkötelezése, kétértelmű vagy egymásnak ellentmondó állapot kezelése, vagy olyan művelet végrehajtása, amelyet egyetlen szabály sem tud biztonságosan megítélni. A kivételutak a munkafolyamat-tervezés részei: azok az esetek, amelyek egyetlen szabálynak sem felelnek meg, látható kivételsorba kerülnek, ahol egy ember a munkafolyamat által összegyűjtött kontextussal oldja meg őket, és a megoldás rögzítésre kerül. Ezek a kontrollpontok munkafolyamat-megbízhatósági kontrollok: azért léteznek, mert a munkafolyamat ezen a határon mérlegeléstől függ. Az a munkafolyamat, amely mindent emberekhez továbbít, kézi munka szoftverrel a közepén; az, amelyik semmit sem továbbít, kontroll nélküli automatizálás.

Egy megbízható munkafolyamat megfigyelhető: minden futtatásnál a működés látja, milyen állapotban van, mit tett, mi hiúsult meg, mit próbálnak újra, és mi vár emberre. A megfigyelhetőséget döntésenként tervezik – mely események, állapotváltozások, hibák, újrapróbálkozások és műveletek számítanak a munkafolyamat üzemeltetéséhez és felülvizsgálatához –, nem pedig utólag gyűjtik össze. Az ellenőrizhetőség ugyanezt a nyomot terjeszti ki a döntésekre és műveletekre: mit döntöttek, milyen szabály alapján vagy ki által, és mi lett az eredménye. A nyom az, ami lehetővé teszi a helyreállítást, ami lehetővé teszi egy vitatott futtatás rekonstruálását egy felülvizsgáló számára, és ami az incidens utáni megbeszélést emlékezetből bizonyítékká alakítja.

A helyreállítási utat még azelőtt meg kell tervezni, hogy egy futtatásnak szüksége lenne rá: hogyan folytatódik egy meghiúsult futtatás ismert állapotból, hogyan veszik figyelembe a részeredményeket további hatások nélkül, és hol indítható újra vagy kezdhető újra biztonságosan egy futtatás. Ahol egy automatikus út nem tud továbbmenni, ott fallback létezik – egy meghatározott kézi folytatás, amelyben egy ember a munkafolyamat által összegyűjtött kontextussal veszi át a feladatot, és az átadás rögzítésre kerül. A helyreállítás korlátos javítás, nem univerzális visszagörgetés: egyes hatások nem vonhatók vissza, miután bekövetkeztek, és egyetlen tervezés sem ígérhet mást. A becsületes szerződés a történtek láthatósága, egy biztonságos út előre és az intézkedésről szóló döntés rögzítése.

A munkafolyamatok fejlődnek, és a fejlődés a működés része. A szabályok, lépések, szerződések vagy indítóesemények változásait tudatos, felülvizsgált változásként kell kiadni, azzal a meghatározott képességgel, hogy észlelhető legyen, ha a munkafolyamat másként viselkedik, mint korábban – mert a csendes viselkedésváltozás olyan megbízhatósági hiba, amelyet még nem vettek észre. Az üzemeltetési költség tervezési kényszerfeltétel: minden újrapróbálkozás, várakozási sor, kontrollpont és nyom figyelmet és pénzt igényel a napi működésben, ezért azokat a kontrollokat, amelyeket egy munkafolyamat megtart, azokkal a következményekkel kell indokolni, amelyek ellen védelmet nyújtanak. A megbízhatóság a munkafolyamat-automatizálás architektúra-tulajdonsága, nem pedig egy fázis: a határ, a látható állapot, az idempotencia, a korlátos újrapróbálkozások, a részleges hibák kezelése, a megfigyelés, a helyreállítás és az emberi kontrollpontok hordozzák – a kezdetektől együtt tervezve. Az automatizálás akkor érett éles működésre, ha minden lépésnél van egy megtervezett válasz arra a kérdésre, hogy „mi történik, ha ez meghiúsul?”.