Koel ja reeglistikud, mis töötavad protsessis
Reeglistik ei tohiks olla kaugelt tark
Ärireeglid tutvustatakse tavaliselt kui midagi lihtsat. Klient on abikõlblik või ei ole. Tehing läheb läbi või ebaõnnestub. Pakkumine saab allahindluse. Kasutaja võib ressursile juurde pääseda. Siis reeglid kasvavad, erandid saabuvad, vastavuskontroll küsib tõendeid ja järsku on lihtsast kontrollist saanud poliitikateenus, tõlk, vahemälu, vastavusse viimise töö ja hankija koosolek. Imeline. Oleme leiutanud ümber fooritule tellimusplaaniga.
Lattice lähtub vähem teatraalsest ideest: reeglistik peaks töötama seal, kus otsus tehakse. Praegune Lattice'i leht kirjeldab Apache 2.0 Rust komponenti, mis kompileerib reeglid eelnevalt mälukaardistatavaks binaarartefaktiks. Hindamine on protsessisisene pakitud puu läbimine. Artefakt kannab kontrollsummasid. Samu reegleid ja samu andmeid kirjeldatakse kui tootvaid sama vastuse toetatud sihtmärkidel. Ükski lisateenus ei pea otsuse teele jääma. See on kasulik kuju.
See ei ole valitsemise vastane. See on vastupidi. Valitsemine nõrgeneb, kui reeglid elavad kaugel süsteemidest, mis neid kasutavad, ja selgitusi tuleb hiljem rekonstrueerida. Reeglistik, mis on versioonitud, kompileeritud, kontrollsummaga, protsessis laaditud ja taasesitatav, annab audiitoritele midagi konkreetsemat kui me küsisime poliitikateenuselt ja see ütles ei. See lause võib olla tõsi. Sellest ei piisa.
Kompileeri üks kord, lõpeta igavene tõlgendamine
Lehe torustik on selge: kirjuta, kompileeri, paki, hinda. Reeglid ja piirangud elavad lähtekoodi ja versiooniajaloo kõrval. Kompileerimine klassifitseerib piirangud ja kinnistab lahendaja taustsüsteemi. Pakkimine toodab binaarartefakti XXH3-64 kontrollsummadega päise, sisu ja faili üle. Laadimine on süsteemikutse, mitte parsimine. Hindamine käib protsessisisese pakitud puu läbimisega. See järjestus on oluline, sest see muudab käitusaja töö ehitusaja tööks.
Tõlgid on mugavad, kuni nad istuvad igal päringul. Kaugel asuv poliitikateenus on mugav, kuni võrguühenduse hüpe muutub latentsuseelarve osaks ja teenus muutub veel üheks asjaks, mis võib maas olla. JIT on mugav, kuni erinevad hostid, versioonid või optimeerijad muutuvad selgituse osaks. Lattice on tahtlikult vähem dramaatiline. See ütleb, et reeglistik peaks muutuma failiks, mille rakendus saab kaardistada ja deterministlikult täita. Päringurada ei tohiks reegleid iga kord uuesti avastada.
Leht teatab praeguse artefaktiraja võrdlusnumbrid, sealhulgas kuuma hindamise numbri, külma otsingu pärast mmap'i ja läbilaskevõime arvud. Need numbrid kuuluvad lehele ja selle võrdluskontekstile, mitte müüdile, mida tuleks igasse tulevasse väljalaskesse kopeerida. Püsiv inseneritarkuse punkt on disain: pakitud artefakt, vahemälulähedane hindamine, parsimise puudumine kuumal rajal, mälueraldamise puudumine kuumal rajal ja võrguhüppe puudumine otsuse kohta.
Ühtne reegli API ei tohiks varjata lahendaja tegelikkust
Reeglid ei ole kõik ühesugused. Mõned on puhtad tõeväärtuskontrollid. Mõned ühendavad loogika aritmeetikaga. Mõned on lineaarsed programmid. Mõned vajavad täisarvulisi otsuseid. Mõned on lõpliku domeeni piirangud. Mõned on teeülesanded või pehmed piirangud. Tõsine reeglimootor ei tohiks sundida iga juhtumit läbi ühe lahendajakujulise võtmeaugu. See peaks reegli klassifitseerima ja suunama selle õigesse taustsüsteemi.
Lattice'i leht koondab SAT, SMT, LP, MIP, CP, A* ja MaxSAT ühe reegli API alla. SAT hõlmab puhtaid Boole'i reegleid ja funktsioonilippe. SMT tegeleb segateooriatega, nagu loogika, aritmeetika, massiivid ja bitivektorid. LP katab pidevat optimeerimist. MIP ehk ILP tegeleb täisarvuliste otsustega. CP tegeleb lõplike domeenide ja mittelineaarsete piirangutega. A* ja MaxSAT katavad tee- ja pehmete piirangute probleeme. Oluline tootelause on see, et kutsuja kirjutab reegleid, mitte lahendaja kutseid.
See on hooldatavuse seisukohast oluline. Kui iga tootemeeskond kirjutab lahendajapõhist integratsioonikoodi, muutub poliitikakiht kogumiks nutikaid kohalikke nippe. Nutikad kohalikud nipid on auditites kallid, sest keegi ei mäleta, milline nipp oli nutikas ja milline lihtsalt reede. Klassifitseeritud reeglipind annab meeskondadele ühe koha, kus vaadata reeglit, selle taustaklassi, kompileeritud artefakti ja loodud vastust.
Latentsus on samuti ärireegel
Otsustussüsteemid armastavad teeselda, et latentsus on tehniline järelmõte. See ei ole. Kui vastavuskontroll on igal tehingul, on latentsus osa tootest. Kui juurdepääsukontroll on lüüsis, on latentsus osa turbest. Kui hinnastamine toimub pakkumise ajal, on latentsus osa tulust. Kui pettuse tuvastamine toimub enne arveldust, on latentsus osa riskist. Aeglane reegel võib olla õige ja siiski operatiivselt vale.
Seetõttu on protsessisisene hindamine oluline. Praegune Lattice'i leht vastandab millisekundilise skaala tõlgendatud või kaugkontrollid pakitud artefakti teega ning toob välja võrguhüpete, kõrvalteenuste ja auditi lünkade kulud. Täpne arv ühe võrdlusnäitaja puhul on vähem oluline kui kulude kuju. Kui üks päring vajab kümmet kontrolli, võib vana tee vastu pidada. Kui üks päring vajab kümmet tuhat kontrolli, hakkab vana tee päringueelarvest üüri võtma. Sel hetkel pole reeglimootor enam komponent. See on asi, mida kasutajad ootavad.
Operatiivne kasu pole ainult kiirus. See on vähem liikuvaid osi. Pole eraldi poliitikateenust. Pole võrguteed, mida tervena hoida. Pole eraldi parseriprotsessi. Pole eraldi vahemälu, mida selgitada. Reeglistik asub rakenduse juures, jurisdiktsiooni ja operatiivse piiri sees, mida te juba kontrollite. See on vähem glamuurne kui juhtpaneel. See on ka vähem tõenäoline, et kedagi üles äratab.
Auditi vastus on taasesitus
Kui audiitor küsib, miks otsus keelati, on halvim vastus mälust rekonstrueeritud lõik. Teine halvim vastus on ekraanipilt. Kasulik vastus on: see reeglistiku versioon töötas selle sisendiga ja andis selle väljundi, siin on artefakti kontrollsumma, siin on reegel, siin on taasesitus. Lattice on ehitatud selle vastuse võimalikuks tegemise ümber.
Leht seob Lattice’i GDPR-automaatotsustega, ELi AI-määruse läbipaistvusega, DORA tegevuskindlusega ja NIS2 tarneahela kindlustusega. Need sildid võivad jääda vaid brošüüritolmuks, kui süsteem ei suuda midagi konkreetset näidata. Konkreetne osa on artefakt. Koostatud reeglistikule saab nime anda. Kontrollsumma suudab rikkumise tagasi lükata. Logitud sisendite abil saab otsuse taasesitada. Bititäpne väljund tähendab, et tõrkekindel üleminek ei tohiks vaikselt vastust muuta. Protsessisiseselt kontrollitud süsteemides töötamine aitab vältida välise teenuse probleemi otsustusrajal.
Kuhu see kõigepealt sobib
Lattice on kõige mõttekam otsustuspunktides, mis toimuvad sageli ja vajavad hiljem tõendusmaterjali. Vastavuskontrollid tehingutes. Hinnakujundus ja sobivus pakkumise ajal. Juurdepääsuotsused lüüsides. Pettuste sõelumine enne arveldamist. Avaliku sektori sobivuskontrollid. Kindlustuse riskihindamise väravad. Sisevoo õigused. Need on kohad, kus jah või ei ei piisa. Süsteem peab teadma, milline versioon jah-st või ei-st juhtus.
See sobib ka kohtadesse, kus sama otsus peab püsima sama eri serverite vahel. Tõrkekindel üleminek ei tohiks muuta vastavustulemust. Piirkondlik juurutamine ei tohiks tõlgendada reeglit erinevalt seetõttu, et teegiversioon on triivinud. Audititaasesitus ei tohiks vajada sama majutatud müüjateenuse edasist olemasolu. Reeglistik peaks olema piisavalt kaasaskantav, et see töötaks seal, kus organisatsioon seda kontrollib, ja piisavalt selge, et vahetuskulud püsiksid madalad.
Sellepärast on avatud lähtekood ka siin oluline. Reeglimootor, mis osaleb vastavuses, juurdepääsus, hinnakujunduses või pettuste tuvastamises, ei ole dekoratiivne sõltuvus. See on osa juhtimistasandist. Kui keegi organisatsiooni sees ei saa seda kontrollida, kinnistada, testida ja hoida, siis pole reeglistik tegelikult nende oma. See on renditud autoriteet.
Mida enne kasutuselevõttu üle vaadata
Esiteks tuvastage otsustuspunktid. Ärge alustage platvormimigratsiooniga. Alustage ühe reeglistikuga, mis täna haiget teeb. Kui tihti see töötab? Mida see kaitseb? Kes küsib, miks? Mis juhtub, kui teenus on maas? Milline tõendusmaterjal on saadaval kuus kuud hiljem?
Teiseks vaadake üle reegli kuju. Kas piirangud on tõeväärtuslikud, aritmeetilised, lineaarsed, täisarvulised, lõpliku domeeniga, rajasarnased või pehmed? Milline taustaklass peaks neid omama? Kui reegel ei suuda selgitada, miks see suunatakse lahendajaperekonda, on abstraktsioon liiga maagiline.
Kolmandaks vaadake üle artefaktidistsipliin. Kus on lähtereegel salvestatud? Milline build tootis artefakti? Milline kontrollsumma laaditi? Milline rakenduseversioon seda kasutas? Millised sisendid logiti? Milline taasesitusrada tõestab vastust? Kui vastus on laiali kolme süsteemi ja ühe Jani-nimelise inimese vahel, pole reeglistik veel auditobjekt. See on traditsioon.
Õppetund
Lattice on reeglimootori lugu, kuid tegelikult on see kontrolli lugu. Koostage reeglistik enne päringut. Pakkige see artefakti, mida rakendus saab mälendada. Kontrollige artefakti enne laadimist. Suunake piirangud õigesse lahendajaperekonda. Hinnake protsessisiseselt. Taasesitage hiljem sama sisendi ja sama reeglistiku versiooniga.
See pole glamuurne. Hea. Ärireeglid ei peaks olema glamuursed. Need peaksid olema igavad, kiired, selged ja ülevaadatavad. Ettevõtte olulised otsustussüsteemid ei tohiks sõltuda kaugematest oraaklitest, parseritsüklitest ja auditiarheoloogiast. Need peaksid kandma oma reeglistikke nagu infrastruktuuri.
Reeglistik ei tohiks olla kaugoraakel. See peaks olema midagi, mida süsteem suudab käitada, nimetada ja taasesitada.