Mreža in pravila, ki tečejo v procesu
Pravilnik ne bi smel biti oddaljeni orakelj
Poslovna pravila so običajno predstavljena kot nekaj preprostega. Stranka je upravičena ali ni. Transakcija uspe ali propade. Ponudba dobi popust. Uporabnik lahko dostopa do vira. Nato pravila rastejo, pojavijo se izjeme, skladnost zahteva dokaze, in nenadoma je preprosto preverjanje postalo storitev pravilnikov, tolmač, predpomnilnik, opravilo usklajevanja in sestanek s ponudnikom. Čudovito. Ponovno smo izumili semafor z naročniškim načrtom.
Lattice izhaja iz manj teatralne ideje: pravilnik bi moral delovati tam, kjer se sprejema odločitev. Trenutna stran Lattice opisuje komponento Apache 2.0 v jeziku Rust, ki pravila vnaprej prevede v binarni artefakt, ki ga je mogoče preslikati v pomnilnik. Vrednotenje je v procesu izveden sprehod po pakiranem drevesu. Artefakt nosi kontrolne vsote. Za ista pravila in iste podatke je opisano, da na podprtih ciljih dajo enak odgovor. Na poti odločitve ni treba, da sedi dodatna storitev. To je uporabna oblika.
To ni proti upravljanju. Ravno nasprotno. Upravljanje oslabi, ko pravila živijo daleč od sistemov, ki jih uporabljajo, in je treba pojasnila pozneje rekonstruirati. Pravilnik, ki je različicen, preveden, opremljen s kontrolnimi vsotami, naložen v procesu in predvajljiv, daje revizorjem nekaj bolj konkretnega kot to, da smo storitev pravilnikov vprašali in je rekla ne. Ta stavek je morda resničen. Ni dovolj.
Prevedite enkrat, nehajte razlagati za vedno
CeVovod strani je jasen: ustvarjanje, prevajanje, pakiranje, vrednotenje. Pravila in omejitve živijo ob izvorni kodi in zgodovini različic. Prevajanje razvrsti omejitve in določi ozadnji reševalnik. Pakiranje ustvari binarni artefakt s kontrolnimi vsotami XXH3-64 nad glavo, vsebino in datoteko. Nalaganje je sistemski klic, ne razčlenjevanje. Vrednotenje se v procesu sprehodi po pakiranem drevesu. To zaporedje je pomembno, ker spremeni delo ob izvajanju v delo ob gradnji.
Tolmači so priročni, dokler ne sedijo na vsaki zahtevi. Oddaljena storitev pravilnikov je priročna, dokler omrežni skok ne postane del proračuna zakasnitve in storitev ne postane še ena stvar, ki je lahko nedosegljiva. JIT je priročen, dokler različni gostitelji, različice ali optimizatorji ne postanejo del pojasnila. Lattice je namenoma manj dramatičen. Pravi, da bi moral pravilnik postati datoteka, ki jo aplikacija lahko preslika in izvede deterministično. Pot zahteve ne bi smela vsakič znova odkrivati pravil.
Stran poroča o merilnih številkah za trenutno pot artefakta, vključno s številko za vroče vrednotenje, hladnim iskanjem po mmap in številkami prepustnosti. Te številke pripadajo strani in njenemu merilnemu okviru, ne mitu, ki bi ga bilo treba kopirati v vsako prihodnjo izdajo. Trajna inženirska poanta je zasnova: pakiran artefakt, vrednotenje lokalno za predpomnilnik, brez razčlenjevalnika na kritični poti, brez dodeljevalnika na kritični poti in brez omrežnega skoka na odločitev.
Enoten API za pravila ne bi smel skrivati resničnosti reševalnikov
Pravila niso vsa enaka. Nekatera so čisto logična preverjanja. Nekatera združujejo logiko z aritmetiko. Nekatera so linearni programi. Nekatera potrebujejo celoštevilske odločitve. Nekatera so omejitve končnih domen. Nekatera so problemi poti ali mehke omejitve. Resen mehanizem pravil ne bi smel vsakega primera siliti skozi eno ključavnico v obliki reševalnika. Pravilo bi moral razvrstiti in ga usmeriti na pravo ozadje.
Stran Lattice združuje SAT, SMT, LP, MIP, CP, A* in MaxSAT pod enotnim pravilnim API-jem. SAT pokriva čiste logične pogoje in funkcijske zastavice. SMT obravnava mešane teorije, kot so logika, aritmetika, polja in bitni vektorji. LP pokriva zvezno optimizacijo. MIP ali ILP obravnava celoštevilske odločitve. CP obravnava končne domene in nelinearne omejitve. A* in MaxSAT pokrivata probleme poti in mehkih omejitev. Ključni produktni stavek je, da klicatelj piše pravila, ne klicev reševalnika.
To je pomembno za vzdržljivost. Če vsaka produktna ekipa piše integracijsko kodo, specifično za reševalnik, postane plast pravilnik zbirka domiselnih lokalnih trikov. Domiselni lokalni triki so dragi pri revizijah, ker se nihče ne spomni, kateri trik je bil domiseln in kateri samo petkov. Razvrščena površina pravil daje ekipam eno mesto za pregled pravila, njegovega razreda ozadja, prevedenega artefakta in odgovora, ki ga je ustvaril.
Zakasnitev je tudi poslovno pravilo
Sistemi za odločanje radi delajo, kot da je zakasnitev tehnična podrobnost. Ni. Če je preverjanje skladnosti na vsaki transakciji, je zakasnitev del izdelka. Če je nadzor dostopa na prehodu, je zakasnitev del varnosti. Če cene tečejo ob izdelavi ponudbe, je zakasnitev del prihodkov. Če se preverjanje goljufij izvaja pred poravnavo, je zakasnitev del tveganja. Počasno pravilo je lahko pravilno in še vedno operativno napačno.
Zato je pomembno vrednotenje v procesu. Trenutna stran Lattice primerja preverjanja v milisekundnem merilu, interpretirana ali oddaljena, s potjo strnjenega artefakta, in izpostavlja stroške omrežnih skokov, stranskih storitev in vrzeli v reviziji. Natančna številka enega merila uspešnosti je manj pomembna od oblike stroškov. Če ena zahteva potrebuje deset preverjanj, stara pot morda še zdrži. Če ena zahteva potrebuje deset tisoč preverjanj, stara pot začne zasedati prostor v proračunu zahteve. Na tej točki pravilo ni več komponenta. Je stvar, na katero uporabniki čakajo.
Operativna korist ni le hitrost. Je manj gibljivih delov. Brez dodatne storitve pravilnikov. Brez omrežne poti, ki jo je treba vzdrževati. Brez ločenega procesa za razčlenjevanje. Brez ločenega predpomnilnika, ki bi ga bilo treba pojasnjevati. Pravilnik je skupaj z aplikacijo, znotraj jurisdikcije in operativne meje, ki jo že nadzirate. To je manj glamurozno kot nadzorna plošča. Je pa tudi manj verjetno, da bo koga zbudilo.
Revizijski odgovor je ponovitev
Ko revizor vpraša, zakaj je bila odločitev zavrnjena, je najslabši odgovor odstavek, rekonstruiran iz spomina. Drugi najslabši odgovor je posnetek zaslona. Uporaben odgovor je: ta različica pravilnika je delovala na teh vhodnih podatkih in ustvarila ta rezultat, tukaj je kontrolna vsota artefakta, tukaj je pravilo, tukaj je ponovitev. Lattice je zgrajen tako, da omogoča tak odgovor.
Stran povezuje Lattice z avtomatiziranimi odločitvami po GDPR, preglednostjo po Aktu EU o umetni inteligenci, operativno odpornostjo po DORA in zagotavljanjem varnosti dobavne verige po NIS2. Te oznake lahko postanejo zgolj marketinški prah, če sistem ne more pokazati ničesar konkretnega. Konkretni del je artefakt. Preveden pravilnik je mogoče poimenovati. Kontrolna vsota lahko zavrne posege. Zabeleženi vhodi lahko ponovijo odločitev. Bitno natančen izhod pomeni, da preklop na rezervni sistem ne bi smel tiho spremeniti odgovora. Delovanje v procesu znotraj nadzorovanih sistemov pomaga preprečiti težavo zunanjih storitev na poti odločanja.
Kje se najprej obnese
Lattice je najbolj smiseln na odločitvenih točkah, ki se pojavljajo pogosto in za katere je pozneje treba imeti dokaze. Preverjanja skladnosti pri transakcijah. Določanje cen in upravičenosti ob ponudbi. Odločitve o dostopu na prehodih. Preverjanje goljufij pred poravnavo. Preverjanja upravičenosti v javnem sektorju. Vrata pri zavarovalniškem prevzemu tveganj. Dovoljenja za notranje delovne procese. To so mesta, kjer zgolj da ali ne ni dovolj. Sistem mora vedeti, katera različica da ali ne se je zgodila.
Prav tako se obnese na mestih, kjer mora ista odločitev ostati enaka na različnih strežnikih. Preklop na rezervni sistem ne sme spremeniti rezultata skladnosti. Regionalna namestitev ne sme razlagati pravila drugače, ker se je različica knjižnice spremenila. Ponovitev revizije ne sme zahtevati, da ista storitev gostovanega ponudnika še vedno obstaja. Pravilnik mora biti dovolj prenosljiv, da deluje tam, kjer ga organizacija nadzoruje, in dovolj natančen, da so stroški zamenjave nizki.
Zato je tudi tu pomembna odprta koda. Pravilni pogon, ki sodeluje pri skladnosti, dostopu, cenah ali goljufijah, ni zgolj dekorativna odvisnost. Je del nadzorne ravnine. Če ga nihče v organizaciji ne more pregledati, zakleniti, preizkusiti in vzdrževati, potem pravilnik v resnici ni njihov. Je najeta avtoriteta.
Kaj pregledati pred uvedbo
Najprej določite odločitvene točke. Ne začnite s selitvijo platforme. Začnite z enim pravilnikom, ki danes povzroča težave. Kako pogosto se izvaja? Kaj varuje? Kdo sprašuje zakaj? Kaj se zgodi, če je storitev nedosegljiva? Kakšni dokazi so na voljo šest mesecev pozneje?
Drugi korak je pregled oblike pravil. Ali so omejitve logične, aritmetične, linearne, celoštevilske, končnodomenske, poti podobne ali mehke? Kateri razred ozadja naj jih obravnava? Če pravilo ne more pojasniti, zakaj se usmeri v določeno družino reševalnikov, je abstrakcija preveč magična.
Tretji korak je pregled discipline artefaktov. Kje je shranjen izvorni pravilnik? Katera izgradnja je ustvarila artefakt? Katera kontrolna vsota je bila naložena? Katera različica aplikacije ga je uporabila? Kateri vhodi so bili zabeleženi? Katera pot ponovitve dokazuje odgovor? Če je odgovor razpršen po treh sistemih in osebi po imenu Jan, pravilnik še ni predmet revizije. Je tradicija.
Nauček
Lattice je zgodba o pravilnem pogonu, a v resnici je zgodba o nadzoru. Prevedite pravilnik pred zahtevo. Zapakirajte ga v artefakt, ki ga aplikacija lahko preslika v pomnilnik. Preverite artefakt pred nalaganjem. Usmerite omejitve v pravo družino reševalnikov. Izvajajte v procesu. Pozneje ponovite z istim vhodom in isto različico pravilnika.
To ni glamurozno. Dobro. Poslovna pravila ne bi smela biti glamurozna. Biti morajo dolgočasna, hitra, natančna in pregledna. Pomembni odločitveni sistemi v podjetju ne bi smeli biti odvisni od oddaljenih orakljev, zank razčlenjevanja in revizijske arheologije. Svoje pravilnike bi morali nositi kot infrastrukturo.
Pravilnik ne bi smel biti oddaljeni orakelj. Moral bi biti nekaj, kar sistem lahko izvaja, poimenuje in ponovi.