Szövetszerkezet és szabálykönyvek, amelyek a folyamatban futnak
A szabálykönyv ne legyen távoli orákulum
Az üzleti szabályokat általában egyszerű dolgokként mutatják be. Egy ügyfél jogosult vagy nem. Egy tranzakció átmegy vagy elbukik. Egy árajánlat kedvezményt kap. Egy felhasználó hozzáférhet egy erőforráshoz. Aztán a szabályok nőnek, jönnek a kivételek, a megfelelés bizonyítékot kér, és hirtelen az egyszerű ellenőrzésből szolgáltatási házirend, értelmező, gyorsítótár, egyeztetési feladat és beszállítói megbeszélés lesz. Csodálatos. Feltaláltuk újra a jelzőlámpát előfizetéses csomaggal.
A Lattice kevésbé teátrális ötletből indul: a szabálykönyv ott fusson, ahol a döntés születik. A jelenlegi Lattice-oldal egy Apache 2.0-s Rust-összetevőt ír le, amely a szabályokat előre lefordítja egy memóriába képezhető bináris artefaktummá. A kiértékelés egy folyamaton belüli, tömörített fa bejárása. Az artefaktum ellenőrzőösszegeket hordoz. Ugyanazok a szabályok és ugyanazok az adatok a támogatott célokon ugyanazt az eredményt adják. Nem kell külön szolgáltatásnak a döntés útjába állnia. Ez a hasznos forma.
Ez nem az irányítás ellen szól. Éppen ellenkezőleg. Az irányítás gyengébbé válik, ha a szabályok messze élnek az őket használó rendszerektől, és a magyarázatokat később kell rekonstruálni. Egy olyan szabálykönyv, amely verziózott, lefordított, ellenőrzőösszeggel ellátott, folyamaton belül betöltött és visszajátszható, konkrétabb dolgot ad az ellenőröknek, mint hogy megkérdeztük a szolgáltatási házirendet, és azt mondta, nem. Ez a mondat lehet, hogy igaz. De ez nem elég.
Fordíts egyszer, és soha többé ne értelmezz
Az oldal folyamata világos: szerzői, fordítás, csomagolás, kiértékelés. A szabályok és korlátok a forráskód és a verziótörténet mellett élnek. A fordítás osztályozza a korlátokat, és rögzíti a megoldó hátterét. A csomagolás egy bináris artefaktumot hoz létre XXH3-64 ellenőrzőösszegekkel a fejléc, a tartalom és a fájl felett. A betöltés rendszerhívás, nem elemzés. A kiértékelés a tömörített fát járja be a folyamaton belül. Ez a sorrend azért fontos, mert a futásidejű munkát fordítási idejű munkává alakítja.
Az értelmezők kényelmesek, amíg minden kérésre rá nem ülnek. A távoli szolgáltatási házirend kényelmes, amíg a hálózati ugrás a késleltetési költségvetés részévé nem válik, és a szolgáltatás egy újabb dolog lesz, ami leállhat. Egy JIT kényelmes, amíg a különböző hosztok, verziók vagy optimalizálók a magyarázat részévé nem válnak. A Lattice szándékosan kevésbé drámai. Azt mondja, a szabálykönyvnek olyan fájllá kell válnia, amelyet az alkalmazás leképezhet és determinisztikusan végrehajthat. A kérés útjának nem szabad minden alkalommal újra felfedeznie a szabályokat.
Az oldal benchmark-számokat közöl a jelenlegi artefaktum-útvonalról, beleértve a forró kiértékelési számot, a hideg keresést mmap után, és az átviteli adatokat. Ezek a számok az oldalhoz és annak benchmark-kontextusához tartoznak, nem pedig egy mítoszhoz, amelyet minden jövőbeli kiadásba át kell másolni. A tartós mérnöki szempont a tervezés: tömörített artefaktum, gyorsítótár-helyi kiértékelés, nincs elemző a kritikus úton, nincs foglaló a kritikus úton, és nincs hálózati ugrás döntésenként.
Egyetlen szabály-API ne rejtse el a megoldó valóságát
A szabályok nem mind egyformák. Némelyik tiszta logikai ellenőrzés. Némelyik logikát kombinál aritmetikával. Némelyik lineáris program. Némelyik egész értékű döntéseket igényel. Némelyik véges tartományú korlát. Némelyik útvonal-probléma vagy lágy korlát. Egy komoly szabálymotornak nem szabad minden esetet egyetlen megoldó alakú kulcslyukon átnyomnia. Osztályoznia kell a szabályt, és a megfelelő háttérrendszerhez kell irányítania.
A Lattice oldal a SAT, SMT, LP, MIP, CP, A* és MaxSAT megoldókat egyetlen szabály-API alá rendezi. A SAT a tiszta logikai szabályokat és funkciókapcsolókat fedi le. Az SMT a vegyes elméleteket kezeli, például a logikát, az aritmetikát, a tömböket és a bitvektorokat. Az LP a folytonos optimalizálást fedi le. A MIP vagy ILP az egészértékű döntéseket kezeli. A CP a véges tartományokat és a nemlineáris feltételeket kezeli. Az A* és a MaxSAT az útvonal- és a lágy feltételes problémákat fedi le. A termék szempontjából a lényeges mondat az, hogy a hívó szabályokat ír, nem pedig megoldóhívásokat.
Ez a karbantarthatóság szempontjából fontos. Ha minden termékcsapat megoldóspecifikus integrációs kódot ír, a szabályzati réteg a helyi trükkök gyűjteményévé válik. A helyi trükkök drágák az auditokban, mert senki sem emlékszik arra, hogy melyik trükk volt okos, és melyik volt csak pénteki ötlet. Egy osztályozott szabályfelület egyetlen helyet ad a csapatoknak, ahol megvizsgálhatják a szabályt, a háttér-osztályát, a lefordított artefaktumot és az általa előállított választ.
A késleltetés is üzleti szabály
A döntési rendszerek szeretik úgy beállítani a késleltetést, mintha az csak technikai utógondolat lenne. Pedig nem az. Ha egy megfelelőségi ellenőrzés minden tranzakción ül, a késleltetés a termék része. Ha a hozzáférés-vezérlés egy átjárónál van, a késleltetés a biztonság része. Ha az árazás az árajánlat elkészítésekor fut, a késleltetés a bevétel része. Ha a csalásszűrés a kiegyenlítés előtt fut, a késleltetés a kockázat része. Egy lassú szabály lehet helyes, és mégis működésileg hibás.
Ezért fontos a folyamaton belüli kiértékelés. A jelenlegi Lattice oldal a ezredmásodperces értelmezett vagy távoli ellenőrzéseket állítja szembe a becsomagolt artefaktum útvonalával, és rámutat a hálózati ugrások, a sidecar szolgáltatások és az audit hézagok költségére. Egy benchmark pontos száma kevésbé fontos, mint a költség szerkezete. Ha egy kéréshez tíz ellenőrzés kell, a régi útvonal talán még működik. Ha egy kéréshez tízezer ellenőrzés kell, a régi útvonal elkezd bérleti díjat fizetni a kérés költségvetéséből. Ekkor a szabálymotor már nem egy összetevő. Hanem az, amire a felhasználók várnak.
A működési előny nem csak a sebesség. Hanem a kevesebb mozgó alkatrész. Nincs külön szabályzati szolgáltatás. Nincs hálózati útvonal, amit egészségesen kell tartani. Nincs külön elemző folyamat. Nincs külön gyorsítótár, amit meg kell magyarázni. A szabálykönyv az alkalmazással együtt él, abban a joghatóságban és működési határon belül, amelyet már amúgy is ellenőrzöl. Ez kevésbé látványos, mint egy irányítópult. De kevésbé is valószínű, hogy éjszaka felébreszt valakit.
Az audit válasza a visszajátszás
Amikor egy auditor azt kérdezi, miért utasítottak el egy döntést, a legrosszabb válasz egy emlékezetből rekonstruált bekezdés. A második legrosszabb válasz egy képernyőkép. A hasznos válasz ez: ez a szabálykönyv-verzió ezen a bemeneten futott, és ezt a kimenetet állította elő, itt van az artefaktum ellenőrzőösszege, itt a szabály, itt a visszajátszás. A Lattice arra épül, hogy ezt a választ lehetővé tegye.
Az oldal a Lattice-et a GDPR szerinti automatizált döntéshozatalhoz, az EU AI Act átláthatósági követelményeihez, a DORA működési rezilienciájához és a NIS2 ellátási lánc biztosítékaihoz köti. Ezek a címkék könnyen üres szlogenekké válhatnak, ha a rendszer nem tud konkrétumot felmutatni. A konkrétum maga az artefaktum. Egy lefordított szabálykönyvet meg lehet nevezni. Egy ellenőrzőösszeg képes jelezni a manipulációt. A naplózott bemenetekkel visszajátszható a döntés. A bitpontos kimenet azt jelenti, hogy a feladatátvétel nem változtathatja meg csendben egy választ. A folyamaton belüli futtatás az ellenőrzött rendszerekben segít elkerülni a külső szolgáltatás problémáját a döntési útvonalon.
Hol illik a legjobban
A Lattice olyan döntési pontokon a leghasznosabb, amelyek gyakran előfordulnak, és később bizonyítékra van szükségük. Megfelelőségi ellenőrzések tranzakciókon. Árazás és jogosultság az árajánlatkéréskor. Hozzáférési döntések átjárókon. Csalásszűrés az elszámolás előtt. Közszférabeli jogosultsági ellenőrzések. Biztosítási kockázatelbírálási kapuk. Belső munkafolyamat-jogosultságok. Ezek olyan helyek, ahol az igen vagy nem nem elég. A rendszernek tudnia kell, hogy az igen vagy nem melyik változata történt.
Olyan helyekre is illik, ahol ugyanannak a döntésnek ugyanannak kell maradnia a kiszolgálók között. A feladatátvétel nem változtathatja meg a megfelelőségi eredményt. Egy regionális telepítés nem értelmezheti másképp egy szabályt, mert egy könyvtár verziója eltér. Az audit-visszajátszáshoz nem kell, hogy ugyanaz a hosztolt szállítói szolgáltatás továbbra is létezzen. A szabálykönyvnek elég hordozhatónak kell lennie ahhoz, hogy ott fusson, ahol a szervezet ellenőrzi, és elég egyértelműnek ahhoz, hogy a váltás költsége alacsony maradjon.
Ezért számít itt a nyílt forráskód is. Egy szabálymotor, amely megfelelőségben, hozzáférésben, árazásban vagy csalásban vesz részt, nem dekoratív függőség. A vezérlési sík része. Ha a szervezeten belül senki sem tudja megvizsgálni, rögzíteni, tesztelni és karbantartani, akkor a szabálykönyv nem igazán az övék. Ez bérelt felhatalmazás.
Mit érdemes áttekinteni az átvétel előtt
Először is azonosítsa a döntési pontokat. Ne platform-migrációval kezdje. Kezdje egy olyan szabálykönyvvel, amely ma gondot okoz. Milyen gyakran fut? Mit véd? Ki kérdezi meg, hogy miért? Mi történik, ha a szolgáltatás leáll? Milyen bizonyíték áll rendelkezésre hat hónappal később?
Másodszor, vizsgálja felül a szabályok alakját. A kényszerek logikaiak, aritmetikaiak, lineárisak, egészértékűek, véges tartományúak, útvonalszerűek vagy lágyak? Melyik backend-osztálynak kellene kezelnie őket? Ha egy szabály nem tudja megmagyarázni, miért irányít egy megoldócsaládhoz, az absztrakció túl misztikus.
Harmadszor, vizsgálja felül az artefaktumfegyelmet. Hol tárolják a forrásszabályt? Melyik build hozta létre az artefaktumot? Melyik ellenőrzőösszeget töltötték be? Melyik alkalmazásverzió használta? Melyik bemeneteket naplózták? Melyik visszajátszási útvonal igazolja a választ? Ha a válasz három rendszeren és egy Jan nevű személyen oszlik el, a szabálykönyv még nem auditobjektum. Ez egy hagyomány.
A tanulság
A Lattice egy szabálymotor-történet, de valójában egy kontrolltörténet. Fordítsa le a szabálykönyvet a kérés előtt. Csomagolja olyan artefaktumba, amelyet az alkalmazás memóriába tud képezni. Ellenőrizze az artefaktumot a betöltés előtt. Irányítsa a kényszereket a megfelelő megoldócsaládhoz. Értékeljen a folyamaton belül. Játssza vissza később ugyanazzal a bemenettel és a szabálykönyv ugyanazon verziójával.
Ez nem látványos. Jó is. Az üzleti szabályoknak nem szabad látványosnak lenniük. Unalmasnak, gyorsnak, egyértelműnek és felülvizsgálhatónak kell lenniük. Egy vállalat fontos döntési rendszerei nem függhetnek távoli orákulumoktól, elemzői hurkoktól és audit-régészetektől. Úgy kell hordozniuk a szabálykönyveiket, mint az infrastruktúrát.
A szabálykönyv nem lehet távoli orákulum. Olyasminek kell lennie, amit a rendszer futtatni, megnevezni és visszajátszani tud.