Lattiat ja säännöt, jotka toimivat prosessissa
Sääntökirjan ei pitäisi olla etäinen oraakkeli
Liiketoimintasäännöt esitellään yleensä yksinkertaisina asioina. Asiakas on kelpoinen tai ei. Tapahtuma menee läpi tai epäonnistuu. Tarjous saa alennuksen. Käyttäjä voi käyttää resurssia. Sitten säännöt kasvavat, poikkeukset ilmestyvät, vaatimustenmukaisuus pyytää todisteita, ja yhtäkkiä yksinkertainen tarkistus on muuttunut käytäntöpalveluksi, tulkiksi, välimuistiksi, täsmäytystyöksi ja toimittajatapaamiseksi. Hienoa. Olemme keksineet liikennevalon uudelleen tilauspohjaisena palveluna.
Lattice lähtee vähemmän teatraalisesta ajatuksesta: sääntökirjan pitäisi toimia siellä, missä päätös tehdään. Nykyinen Lattice-sivu kuvaa Apache 2.0 -lisensoidun Rust-komponentin, joka kääntää säännöt etukäteen muistiavaruuteen sijoitettavaksi binääriartefaktiksi. Arviointi on prosessin sisäinen paketoidun puun läpikäynti. Artefakti sisältää tarkistussummia. Samojen sääntöjen ja samojen tietojen kuvataan tuottavan sama vastaus tuetuilla alustoilla. Päätöksen polulla ei tarvitse olla ylimääräistä palvelua. Tämä on hyödyllinen muoto.
Tämä ei ole hallintoa vastaan. Se on päinvastoin. Hallinto heikkenee, kun säännöt elävät kaukana niitä käyttävistä järjestelmistä ja selitykset on rekonstruoitava jälkikäteen. Sääntökirja, joka on versioitu, käännetty, tarkistussummattu, ladattu prosessiin ja toistettavissa, antaa tilintarkastajille konkreettisempaa kuin kysyimme käytäntöpalvelulta ja se sanoi ei. Tämä lause voi olla totta. Se ei riitä.
Käännä kerran, lopeta tulkitseminen ikuisesti
Sivun prosessi on selkeä: kirjoita, käännä, pakkaa, arvioi. Säännöt ja rajoitteet elävät lähdekoodin ja versiohistorian vieressä. Käännös luokittelee rajoitteet ja kiinnittää ratkaisijan taustajärjestelmän. Pakkaus tuottaa binääriartefaktin, jossa on XXH3-64-tarkistussummat otsikolle, sisällölle ja tiedostolle. Lataaminen on järjestelmäkutsu, ei jäsennys. Arviointi käy paketoidun puun läpi prosessissa. Tämä järjestys on tärkeä, koska se muuttaa suoritusaikaisen työn rakennusaikaiseksi työksi.
Tulkit ovat käteviä, kunnes ne ovat jokaisessa pyynnössä. Etäinen käytäntöpalvelu on kätevä, kunnes verkkohyppy tulee osaksi viivebudjettia ja palvelusta tulee toinen asia, joka voi olla alhaalla. JIT on kätevä, kunnes eri isännät, versiot tai optimoijat tulevat osaksi selitystä. Lattice on tarkoituksella vähemmän dramaattinen. Se sanoo, että sääntökirjasta pitäisi tulla tiedosto, jonka sovellus voi kartoittaa muistiin ja suorittaa deterministisesti. Pyyntöpolun ei pitäisi löytää sääntöjä uudelleen joka kerta.
Sivu raportoi suorituskykylukuja nykyiselle artefaktipolulle, mukaan lukien kuuman arvioinnin luvun, kylmän haun mmapin jälkeen ja läpäisylukuja. Nämä luvut kuuluvat sivulle ja sen suorituskykytestauskontekstiin, eivät myyttiin, joka pitäisi kopioida jokaiseen tulevaan julkaisuun. Kestävä tekninen pointti on suunnittelu: pakattu artefakti, välimuistilokaali arviointi, ei jäsennintä kriittisellä polulla, ei allokaattoria kriittisellä polulla ja ei verkkohyppyä päätöstä kohti.
Yksi sääntö-API ei saisi piilottaa ratkaisijan todellisuutta
Säännöt eivät ole kaikki samanlaisia. Jotkut ovat puhtaita boolean-tarkistuksia. Jotkut yhdistävät logiikkaa ja aritmetiikkaa. Jotkut ovat lineaarisia ohjelmia. Jotkut vaativat kokonaislukupäätöksiä. Jotkut ovat äärellisen alueen rajoitteita. Jotkut ovat polkuongelmia tai pehmeitä rajoitteita. Vakavasti otettavan sääntömoottorin ei pitäisi pakottaa jokaista tapausta yhden ratkaisijan muotoisen avaimenreiän läpi. Sen pitäisi luokitella sääntö ja ohjata se oikeaan taustajärjestelmään.
Lattice-sivu nimeää SAT-, SMT-, LP-, MIP-, CP-, A*- ja MaxSAT-ratkaisijat yhden sääntö-API:n alle. SAT kattaa puhtaat Boolen säännöt ja ominaisuusportit. SMT käsittelee sekoitettuja teorioita, kuten logiikkaa, aritmetiikkaa, taulukoita ja bittivektoreita. LP kattaa jatkuvan optimoinnin. MIP eli ILP käsittelee kokonaislukupäätöksiä. CP käsittelee äärellisiä alueita ja epälineaarisia rajoitteita. A* ja MaxSAT kattavat polku- ja pehmeiden rajoitteiden ongelmat. Tärkein tuotelause on, että kutsuja kirjoittaa sääntöjä, ei ratkaisijakutsu.
Sillä on merkitystä ylläpidettävyyden kannalta. Jos jokainen tuotetiimi kirjoittaa ratkaisijakohtaisia integraatiokoodeja, käytäntökerroksesta tulee kokoelma nokkelia paikallisia temppuja. Nokkelat paikalliset temput ovat kalliita auditoinneissa, koska kukaan ei muista, mikä temppu oli nokkela ja mikä oli vain perjantai. Luokiteltu sääntöpinta antaa tiimeille yhden paikan tarkastella sääntöä, sen taustaluokkaa, käännettyä artefaktia ja tuotettua vastausta.
Viive on myös liiketoimintasääntö
Päätösjärjestelmät tykkäävät teeskennellä, että viive on tekninen jälkiajatus. Se ei ole. Jos vaatimustenmukaisuustarkistus on jokaisessa tapahtumassa, viive on osa tuotetta. Jos pääsynhallinta on yhdyskäytävässä, viive on osa turvallisuutta. Jos hinnoittelu ajetaan tarjoushetkellä, viive on osa liikevaihtoa. Jos petostentorjunta ajetaan ennen selvitystä, viive on osa riskiä. Hidas sääntö voi olla oikea ja silti toiminnallisesti väärä.
Siksi prosessin sisäinen arviointi on tärkeää. Nykyinen Lattice-sivu vertaa millisekuntiluokan tulkattuja tai etäsuoritettuja tarkistuksia pakattuun artefaktipolkuun ja nostaa esiin verkkohyppyjen, sivupalveluiden ja auditointiaukkojen kustannukset. Yhden vertailuarvon tarkka luku on vähemmän tärkeä kuin kustannuksen muoto. Jos yksi pyyntö vaatii kymmenen tarkistusta, vanha polku voi vielä toimia. Jos yksi pyyntö vaatii kymmenentuhatta tarkistusta, vanha polku alkaa viedä tilaa pyyntöbudjetista. Siinä vaiheessa sääntömoottori ei ole enää komponentti. Se on se asia, jota käyttäjät odottavat.
Toiminnallinen hyöty ei ole vain nopeus. Se on vähemmän liikkuvia osia. Ei erillistä käytäntöpalvelua. Ei verkkopolkua pidettävänä kunnossa. Ei erillistä jäsenninprosessia. Ei erillistä välimuistia selitettävänä. Sääntökirja on sovelluksen mukana, sen lainkäyttöalueen ja toiminnallisen rajan sisällä, jota jo hallitset. Se on vähemmän hohdokasta kuin hallintapaneeli. Se on myös vähemmän todennäköisesti herättämässä jotakuta yöllä.
Auditointivastaus on toisto
Kun auditoija kysyy, miksi päätös evättiin, huonoin vastaus on muistista rekonstruoitu kappale. Toiseksi huonoin vastaus on kuvakaappaus. Hyödyllinen vastaus on: tämä sääntökirjan versio ajettiin tällä syötteellä ja tuotti tämän tulosteen, tässä on artefaktin tarkistussumma, tässä on sääntö, tässä on toisto. Lattice on rakennettu tekemään tämä vastaus mahdolliseksi.
Sivu kytkee Lattice-tuotteen GDPR:n automatisoituihin päätöksiin, EU:n tekoälyasetuksen läpinäkyvyysvaatimuksiin, DORA:n toiminnalliseen häiriönsietokykyyn ja NIS2:n toimitusketjun varmuuteen. Näistä tunnisteista voi tulla pelkkää markkinointipölyä, jos järjestelmä ei pysty näyttämään mitään konkreettista. Konkreettinen osuus on artefakti. Käännetty sääntökirja voidaan nimetä. Tarkistussumma voi hylätä peukaloidun sisällön. Kirjatut syötteet voivat toistaa päätöksen. Bittitarkka tulos tarkoittaa, että vikasietojärjestelmä ei saa huomaamatta muuttaa vastausta. Kun prosessi ajetaan hallittujen järjestelmien sisällä, päätöspolulle ei synny ulkoisen palvelun ongelmaa.
Minne se sopii ensin
Lattice on järkevin valinta päätöspisteisiin, joita esiintyy usein ja joista tarvitaan myöhemmin todisteita. Vaatimustenmukaisuustarkistukset tapahtumissa. Hinnoittelu ja kelpoisuus tarjoushetkellä. Pääsypäätökset yhdyskäytävissä. Petostentorjuntaseulonta ennen maksun suorittamista. Julkisen sektorin kelpoisuustarkistukset. Vakuutusten riskinarvioinnin portit. Sisäisten työnkulkujen käyttöoikeudet. Näissä paikoissa pelkkä kyllä tai ei ei riitä. Järjestelmän on tiedettävä, mikä versio kyllä tai ei -vastauksesta tapahtui.
Se sopii myös paikkoihin, joissa saman päätöksen on pysyttävä samana palvelimesta toiseen. Vikasietojärjestelmä ei saa muuttaa vaatimustenmukaisuustulosta. Alueellinen käyttöönotto ei saa tulkita sääntöä eri tavalla siksi, että kirjaston versio on ajautunut erilleen. Auditointitoiston ei pitäisi edellyttää, että sama isännöity toimittajapalvelu on edelleen olemassa. Sääntökirjan on oltava riittävän siirrettävä, jotta se voidaan ajaa siellä, missä organisaatio sitä hallitsee, ja riittävän yksiselitteinen, jotta vaihtamisen kustannukset pysyvät matalina.
Siksi avoimen lähdekoodin merkitys korostuu myös tässä. Sääntömoottori, joka osallistuu vaatimustenmukaisuuteen, pääsynhallintaan, hinnoitteluun tai petostentorjuntaan, ei ole koristeellinen riippuvuus. Se on osa hallintatasoa. Jos kukaan organisaation sisällä ei voi tarkastaa sitä, lukita sen versiota, testata sitä ja ylläpitää sitä, sääntökirja ei todella ole heidän omansa. Se on vuokrattua auktoriteettia.
Mitä tarkistaa ennen käyttöönottoa
Ensimmäiseksi tunnista päätöspisteet. Älä aloita alustamigraatiosta. Aloita yhdestä sääntökirjasta, joka aiheuttaa ongelmia jo tänään. Kuinka usein se ajetaan? Mitä se suojaa? Kuka kysyy miksi? Mitä tapahtuu, jos palvelu on poissa käytöstä? Mitä todisteita on saatavilla kuuden kuukauden kuluttua?
Toiseksi tarkastele sääntöjen muotoa. Ovatko rajoitteet loogisia, aritmeettisia, lineaarisia, kokonaislukupohjaisia, äärellisistä arvoista koostuvia, polkumaisia vai pehmeitä? Minkä taustajärjestelmäluokan vastuulle ne kuuluvat? Jos sääntö ei pysty selittämään, miksi se ohjautuu tietylle ratkaisijaperheelle, abstraktio on liian taianomainen.
Kolmanneksi tarkastele artefaktikuria. Missä lähdesääntöä säilytetään? Mikä rakennus tuotti artefaktin? Mikä tarkistussumma ladattiin? Mikä sovellusversio käytti sitä? Mitkä syötteet kirjattiin? Mikä toistopolku todistaa vastauksen? Jos vastaus on levittäytynyt kolmeen järjestelmään ja erään Jan-nimisen henkilön tietoihin, sääntökirja ei ole vielä auditointikohde. Se on perinne.
Opetus
Lattice on sääntömoottoritarina, mutta oikeastaan se on hallintatarina. Käännä sääntökirja ennen pyyntöä. Pakkaa se artefaktiksi, jonka sovellus voi lukea suoraan muistista. Tarkista artefakti ennen lataamista. Ohjaa rajoitteet oikealle ratkaisijaperheelle. Suorita prosessi järjestelmän sisällä. Toista myöhemmin samalla syötteellä ja samalla sääntökirjaversiolla.
Se ei ole hohdokasta. Hyvä niin. Liiketoimintasääntöjen ei pidäkään olla hohdokkaita. Niiden pitää olla tylsää, nopeaa, yksiselitteistä ja tarkastettavaa. Yrityksen tärkeiden päätösjärjestelmien ei pitäisi olla riippuvaisia etäorakkeleista, jäsentimen silmukoista ja auditointiarkeologiasta. Niiden pitäisi kantaa sääntökirjojaan kuin infrastruktuuria.
Sääntökirja ei saa olla etäorakkelin korvike. Sen on oltava jotain, jonka järjestelmä voi ajaa, nimetä ja toistaa.