Lattice un noteikumu grāmatas, kas darbojas procesā
Noteikumu grāmata nedrīkst būt attāls orākuls
Biznesa noteikumi parasti tiek ieviesti kā kaut kas vienkāršs. Klients ir vai nav tiesīgs. Darījums iziet vai neiziet. Piedāvājumam tiek piemērota atlaide. Lietotājs var piekļūt resursam. Tad noteikumi aug, parādās izņēmumi, atbilstība pieprasa pierādījumus, un pēkšņi vienkāršā pārbaude ir kļuvusi par politikas pakalpojumu, interpretētāju, kešatmiņu, saskaņošanas darbu un piegādātāja sapulci. Brīnišķīgi. Mēs esam izgudrojuši no jauna luksoforu ar abonēšanas plānu.
Lattice sākas ar mazāk teatrālu ideju: noteikumu grāmatai jādarbojas tur, kur tiek pieņemts lēmums. Pašreizējā Lattice lapa apraksta Apache 2.0 Rust komponenti, kas iepriekš kompilē noteikumus atmiņā kartējamā binārā artefaktā. Novērtēšana ir procesa iekšēja iepakota koka pārvietošanās. Artefaktam ir kontrolsummas. Tie paši noteikumi un tie paši dati tiek aprakstīti kā sniedzoši vienu un to pašu atbildi atbalstītajos mērķos. Lēmuma ceļā nav jāatrodas papildu pakalpojumam. Tā ir lietderīgā forma.
Tas nav pret pārvaldību. Tas ir pretējais. Pārvaldība kļūst vājāka, ja noteikumi dzīvo tālu no sistēmām, kas tos izmanto, un skaidrojumi ir jārekonstruē vēlāk. Noteikumu grāmata, kas ir versēta, kompilēta, ar kontrolsummām, ielādēta procesā un atkārtojama, dod auditoriem kaut ko konkrētāku nekā mēs prasījām politikas pakalpojumam un tas teica nē. Šis teikums var būt patiess. Ar to nepietiek.
Kompilē vienreiz, pārtrauc interpretēt uz visiem laikiem
Lapas cauruļvads ir skaidrs: autors, kompilēšana, iepakošana, novērtēšana. Noteikumi un ierobežojumi dzīvo blakus avotam un versiju vēsturei. Kompilēšana klasificē ierobežojumus un piesprauž risinātāja aizmugursistēmu. Iepakošana rada bināru artefaktu ar XXH3-64 kontrolsummām virs galvenes, satura un faila. Ielāde ir sistēmas izsaukums, nevis parsēšana. Novērtēšana pārvietojas pa iepakoto koku procesa iekšienē. Šī secība ir svarīga, jo tā pārvērš izpildlaika darbu par būvēšanas laika darbu.
Interpretētāji ir ērti, līdz tie atrodas uz katra pieprasījuma. Attālais politikas pakalpojums ir ērts, līdz tīkla lēciens kļūst par latentuma budžeta daļu un pakalpojums kļūst par vēl vienu lietu, kas var būt nedarbīga. JIT ir ērts, līdz dažādi resursdatori, versijas vai optimizētāji kļūst par skaidrojuma daļu. Lattice apzināti ir mazāk dramatisks. Tas saka, ka noteikumu grāmatai jākļūst par failu, ko lietotne var kartēt un izpildīt deterministiski. Pieprasījuma ceļam nevajadzētu katru reizi no jauna atklāt noteikumus.
Lapa ziņo etalona skaitļus pašreizējam artefakta ceļam, ieskaitot karstās novērtēšanas skaitli, auksto uzmeklēšanu pēc mmap un caurlaidspējas skaitļus. Šie skaitļi pieder lapai un tās etalona kontekstam, nevis mītam, kas būtu jākopē katrā nākotnes laidienā. Noturīgais inženierijas punkts ir dizains: iepakots artefakts, kešatmiņai tuvu novērtēšana, bez parsētāja karstajā ceļā, bez piešķīrēja karstajā ceļā un bez tīkla lēciena katram lēmumam.
Vienots noteikumu API nedrīkst slēpt risinātāja realitāti
Noteikumi nav visi vienādi. Daži ir tīri būla pārbaudes. Daži apvieno loģiku ar aritmētiku. Daži ir lineāras programmas. Dažiem nepieciešami veselu skaitļu lēmumi. Daži ir ierobežotu domēnu ierobežojumi. Daži ir ceļa problēmas vai mīksti ierobežojumi. Nopietns noteikumu dzinējs nedrīkst piespiest katru gadījumu caur vienu risinātāja formas atslēgas caurumu. Tam vajadzētu klasificēt noteikumu un novirzīt to uz pareizo aizmugursistēmu.
Lattice lapas nosaukums SAT, SMT, LP, MIP, CP, A* un MaxSAT apvieno zem viena noteikumu API. SAT aptver tīri Būla noteikumus un funkciju slēdžus. SMT apstrādā jauktas teorijas, piemēram, loģiku, aritmētiku, masīvus un bitu vektorus. LP aptver nepārtrauktu optimizāciju. MIP jeb ILP apstrādā veselu skaitļu lēmumus. CP apstrādā ierobežotas kopas un nelineārus ierobežojumus. A* un MaxSAT aptver ceļa un mīksto ierobežojumu problēmas. Svarīgais produkta teikums ir tas, ka izsaucējs raksta noteikumus, nevis risinātāja izsaukumus.
Tam ir nozīme uzturēšanā. Ja katra produkta komanda raksta risinātājam specifisku integrācijas kodu, politikas slānis kļūst par gudru lokālu triku kolekciju. Gudri lokāli triki ir dārgi auditā, jo neviens neatceras, kurš triks bija gudrs un kurš bija tikai piektdienas steigā. Klasificēta noteikumu virsma dod komandām vienu vietu, kur pārbaudīt noteikumu, tā aizmugures klasi, apkopoto artefaktu un iegūto atbildi.
Latence arī ir biznesa noteikums
Lēmumu sistēmām patīk izlikties, ka latence ir tehniska pēcdoma. Tā nav. Ja atbilstības pārbaude ir uz katras transakcijas, latence ir daļa no produkta. Ja piekļuves kontrole atrodas vārtos, latence ir daļa no drošības. Ja cenu noteikšana notiek piedāvājuma laikā, latence ir daļa no ieņēmumiem. Ja krāpšanas pārbaude notiek pirms norēķinu, latence ir daļa no riska. Lēns noteikums var būt pareizs un tomēr operacionāli nepareizs.
Tāpēc procesa iekšējā novērtēšana ir svarīga. Pašreizējā Lattice lapa pretstata milisekundes mēroga interpretētās vai attālās pārbaudes ar apkopoto artefaktu ceļu, un tā norāda uz tīkla lēcienu, sānu pakalpojumu un audita nepilnību izmaksām. Precīzs skaitlis vienam etalonam ir mazāk svarīgs nekā izmaksu forma. Ja vienam pieprasījumam vajag desmit pārbaudes, iespējams, vecais ceļš izdzīvo. Ja vienam pieprasījumam vajag desmit tūkstošus pārbaužu, vecais ceļš sāk aizņemt vietu pieprasījuma budžetā. Tajā brīdī noteikumu dzinējs vairs nav sastāvdaļa. Tas ir tas, ko lietotāji gaida.
Operacionālais ieguvums nav tikai ātrums. Tas ir mazāk kustīgu daļu. Nav papildu politikas pakalpojuma. Nav tīkla ceļa, kas jāuztur veselīgs. Nav atsevišķa parsētāja procesa. Nav atsevišķas kešatmiņas, kas jāizskaidro. Noteikumu grāmata atrodas kopā ar lietojumprogrammu, jūsu jau kontrolētajā jurisdikcijā un operacionālajā robežā. Tas ir mazāk krāšņi nekā informācijas panelis. Tas arī mazāk pamodinās kādu naktī.
Audita atbilde ir atkārtojums
Kad auditors jautā, kāpēc lēmums tika noraidīts, sliktākā atbilde ir no atmiņas rekonstruēta rindkopa. Otra sliktākā atbilde ir ekrānuzņēmums. Noderīgā atbilde ir: šī noteikumu grāmatas versija tika izpildīta ar šo ievadi un radīja šo izvadi, šeit ir artefakta kontrolsumma, šeit ir noteikums, šeit ir atkārtojums. Lattice ir veidota, lai padarītu šo atbildi iespējamu.
Lapa saista Lattice ar GDPR automatizētiem lēmumiem, ES AI akta pārredzamību, DORA darbības noturību un NIS2 piegādes ķēdes nodrošinājumu. Šie marķējumi var kļūt par tukšu solījumu, ja sistēma nevar uzrādīt neko konkrētu. Konkrētā daļa ir artefakts. Apkopotu noteikumu grāmatu var nosaukt. Kontrolsumma var noraidīt manipulācijas. Reģistrētus ievaddatus var atkārtoti izspēlēt lēmuma pieņemšanā. Bitu līmeņa identiska izvade nozīmē, ka pārslēgšanās uz rezerves sistēmu nedrīkst klusi mainīt atbildi. Darbība procesa iekšienē kontrolētās sistēmās palīdz izvairīties no ārēja pakalpojuma problēmas lēmuma ceļā.
Kur tas vispirms der
Lattice visvairāk jēgas ir lēmumu punktos, kas notiek bieži un kuriem vēlāk nepieciešami pierādījumi. Atbilstības pārbaudes darījumiem. Cenu noteikšana un atbilstība citēšanas brīdī. Piekļuves lēmumi vārtos. Krāpšanas pārbaude pirms norēķinu veikšanas. Publiskā sektora atbilstības pārbaudes. Apdrošināšanas parakstīšanas vārti. Iekšējo darbplūsmu atļaujas. Šīs ir vietas, kur ar jā vai nē nepietiek. Sistēmai ir jāzina, kura jā vai nē versija notika.
Tas der arī vietām, kur vienam un tam pašam lēmumam ir jāpaliek nemainīgam starp serveriem. Pārslēgšanās uz rezerves sistēmu nedrīkst mainīt atbilstības rezultātu. Reģionālā izvietošana nedrīkst interpretēt noteikumu atšķirīgi tāpēc, ka bibliotēkas versija ir novirzījusies. Revīzijas atkārtošanai nevajadzētu prasīt, lai tas pats mitinātais pārdevēja pakalpojums joprojām pastāvētu. Noteikumu grāmatai jābūt pietiekami pārnesamai, lai tā darbotos tur, kur organizācija to kontrolē, un pietiekami skaidrai, lai pārejas izmaksas paliktu zemas.
Tāpēc atvērtais kods šeit arī ir svarīgs. Noteikumu dzinējs, kas piedalās atbilstībā, piekļuvē, cenu noteikšanā vai krāpšanas atklāšanā, nav dekoratīva atkarība. Tā ir kontroles plaknes daļa. Ja neviens organizācijas iekšienē to nevar pārbaudīt, fiksēt, testēt un uzturēt, tad noteikumu grāmata īsti nav viņu. Tā ir īrēta autoritāte.
Kas jāpārskata pirms tā ieviešanas
Pirmkārt, identificējiet lēmumu punktus. Nesāciet ar platformas migrāciju. Sāciet ar vienu noteikumu grāmatu, kas šodien rada problēmas. Cik bieži tā darbojas? Ko tā aizsargā? Kurš jautā, kāpēc? Kas notiek, ja pakalpojums ir pieejams? Kādi pierādījumi ir pieejami pēc sešiem mēnešiem?
Otrkārt, pārskatiet noteikumu formu. Vai ierobežojumi ir Būla, aritmētiski, lineāri, veselu skaitļu, ierobežota domēna, ceļam līdzīgi vai mīksti? Kurai aizmugursistēmas klasei tie būtu jāpārvalda? Ja noteikums nevar izskaidrot, kāpēc tas tiek novirzīts uz risinātāju saimi, abstrakcija ir pārāk maģiska.
Treškārt, pārskatiet artefakta disciplīnu. Kur tiek glabāts avota noteikums? Kurš būvējums radīja artefaktu? Kura kontrolsumma tika ielādēta? Kura lietojumprogrammas versija to izmantoja? Kuri ievaddati tika reģistrēti? Kurš atkārtošanas ceļš pierāda atbildi? Ja atbilde ir izkliedēta pa trim sistēmām un cilvēku vārdā Jānis, noteikumu grāmata vēl nav revīzijas objekts. Tā ir tradīcija.
Mācība
Lattice ir noteikumu dzinēja stāsts, bet patiesībā tas ir kontroles stāsts. Apkopojiet noteikumu grāmatu pirms pieprasījuma. Iepakojiet to artefaktā, ko lietojumprogramma var kartēt atmiņā. Pārbaudiet artefaktu pirms ielādēšanas. Novirziet ierobežojumus uz pareizo risinātāju saimi. Novērtējiet procesa iekšienē. Atkārtojiet vēlāk ar tiem pašiem ievaddatiem un to pašu noteikumu grāmatas versiju.
Tas nav glamūrīgi. Labi. Biznesa noteikumiem nevajadzētu būt glamūrīgiem. Tiem jābūt garlaicīgiem, ātriem, skaidriem un pārskatāmiem. Svarīgām lēmumu sistēmām uzņēmumā nevajadzētu būt atkarīgām no attāliem orākliem, parseru cilpām un revīzijas arheoloģijas. Tām būtu jānēsā savas noteikumu grāmatas kā infrastruktūra.
Noteikumu grāmatai nevajadzētu būt attālam orākulim. Tai jābūt kaut kam, ko sistēma var palaist, nosaukt un atkārtoti izspēlēt.