Решетка и правилници, които работят в процеса
Правилникът не трябва да бъде отдалечен оракул
Бизнес правилата обикновено се въвеждат като нещо просто. Клиентът отговаря на условията или не. Транзакцията минава или не. Офертата получава отстъпка. Потребителят може да получи достъп до ресурс. След това правилата растат, появяват се изключенията, съответствието изисква доказателства, и изведнъж простата проверка се е превърнала в услуга за политики, интерпретатор, кеш, задача за съпоставяне и среща с доставчик. Чудесно. Преоткрихме светофар с абонаментен план.
Lattice започва от по-малко театрална идея: правилникът трябва да работи там, където се взема решението. Текущата страница на Lattice описва Apache 2.0 Rust компонент, който компилира правилата предварително в двоичен артефакт, подходящ за memory-mapping. Оценяването е обхождане на опаковано дърво в процеса. Артефактът носи контролни суми. Едни и същи правила и едни и същи данни са описани като даващи един и същ отговор на поддържаните платформи. Не е необходим допълнителен сервиз по пътя на решението. Това е полезната форма.
Това не е против управлението. Точно обратното е. Управлението отслабва, когато правилата живеят далеч от системите, които ги използват, и обясненията трябва да се реконструират по-късно. Правилник, който е версиониран, компилиран, с контролни суми, зареден в процеса и възпроизводим, дава на одиторите нещо по-конкретно от „помолихме услугата за политики и тя каза не“. Това изречение може да е вярно. Не е достатъчно.
Компилирайте веднъж, спрете да интерпретирате завинаги
Пайплайнът на страницата е ясен: създаване, компилиране, опаковане, оценяване. Правилата и ограниченията живеят до изходния код и историята на версиите. Компилацията класифицира ограниченията и закрепва backend решавателя. Опаковането произвежда двоичен артефакт с XXH3-64 контролни суми върху заглавката, съдържанието и файла. Зареждането е системно извикване, а не разбор. Оценяването обхожда опакованото дърво в процеса. Тази последователност е важна, защото превръща работата по време на изпълнение в работа по време на изграждане.
Интерпретаторите са удобни, докато не се озоват на всяка заявка. Отдалечената услуга за политики е удобна, докато мрежовият скок не стане част от бюджета за латентност и услугата не се превърне в нещо друго, което може да е недостъпно. JIT е удобен, докато различните хостове, версии или оптимизатори не станат част от обяснението. Lattice умишлено е по-малко драматичен. Той казва, че правилникът трябва да се превърне във файл, който приложението може да картографира и изпълнява детерминистично. Пътят на заявката не трябва да преоткрива правилата всеки път.
Страницата съобщава бенчмарк числа за текущия път на артефакта, включително число за горещо оценяване, студено търсене след mmap и данни за пропускателната способност. Тези числа принадлежат на страницата и нейния бенчмарк контекст, а не на мит, който трябва да се копира във всяко бъдещо издание. Трайната инженерна точка е дизайнът: опакован артефакт, оценяване с локален кеш, без парсер на критичния път, без алокатор на критичния път и без мрежов скок за всяко решение.
Единен API за правила не трябва да скрива реалността на решавателя
Правилата не са еднакви. Някои са чисто булеви проверки. Някои съчетават логика с аритметика. Някои са линейни програми. Някои изискват целочислени решения. Някои са ограничения с крайна област. Някои са проблеми с пътища или меки ограничения. Сериозният двигател за правила не трябва да прокарва всеки случай през една ключалка с формата на решавател. Той трябва да класифицира правилото и да го насочи към правилния backend.
Страницата Lattice представя SAT, SMT, LP, MIP, CP, A* и MaxSAT под единен API за правила. SAT покрива чисто булеви правила и функционални флагове. SMT обработва смесени теории като логика, аритметика, масиви и битвектори. LP покрива непрекъсната оптимизация. MIP или ILP обработва целочислени решения. CP обработва крайни домейни и нелинейни ограничения. A* и MaxSAT покриват проблеми с пътища и меки ограничения. Важното продуктово изречение е, че извикващият пише правила, а не извиквания към решаващи програми.
Това е от значение за поддръжката. Ако всеки продуктов екип пише специфичен интеграционен код за решаващи програми, слоят на политиките се превръща в колекция от умни локални трикове. Умните локални трикове са скъпи при одити, защото никой не помни кой трик е бил умен и кой просто е бил направен в петък. Класифицираната повърхност на правилата дава на екипите едно място, където да проверят правилото, неговия клас на бекенда, компилирания артефакт и отговора, който е произвел.
Латентността също е бизнес правило
Системите за вземане на решения обичат да се преструват, че латентността е технически детайл. Не е. Ако проверка за съответствие стои на всяка транзакция, латентността е част от продукта. Ако контролът на достъпа стои на шлюз, латентността е част от сигурността. Ако ценообразуването се изпълнява по време на оферта, латентността е част от приходите. Ако проверката за измами се изпълнява преди сетълмент, латентността е част от риска. Едно бавно правило може да е правилно и въпреки това да е оперативно грешно.
Ето защо оценката в процеса е от значение. Текущата страница Lattice противопоставя проверките в милисекунден мащаб, интерпретирани или отдалечени, с пътя на опакования артефакт и посочва цената на мрежовите скокове, страничните услуги и пропуските в одита. Точният номер за един бенчмарк е по-малко важен от формата на разходите. Ако една заявка изисква десет проверки, може би старият път оцелява. Ако една заявка изисква десет хиляди проверки, старият път започва да заема място в бюджета на заявката. В този момент машината за правила вече не е компонент. Тя е нещото, за което потребителите чакат.
Оперативната полза не е само скоростта. Тя е по-малко движещи се части. Без допълнителна услуга за политики. Без мрежов път, който да поддържате здрав. Без отделен процес за парсване. Без отделен кеш, който да обяснявате. Книгата с правила стои заедно с приложението, в рамките на юрисдикцията и оперативната граница, които вече контролирате. Това е по-малко бляскаво от табло. Също така е по-малко вероятно да събуди някого.
Отговорът на одита е повторното изпълнение
Когато одитор попита защо дадено решение е било отказано, най-лошият отговор е параграф, реконструиран от паметта. Вторият най-лош отговор е екранна снимка. Полезният отговор е: тази версия на книгата с правила е изпълнена върху този вход и е произвела този изход, ето контролната сума на артефакта, ето правилото, ето повторното изпълнение. Lattice е изградена около това да направи този отговор възможен.
Страницата свързва Lattice с автоматизираните решения по GDPR, прозрачността по Закона за ИИ на ЕС, оперативната устойчивост по DORA и осигуряването на веригата за доставки по NIS2. Тези етикети могат да се превърнат в празни приказки, ако системата не може да покаже нищо конкретно. Конкретното е артефактът. Компилираният правилник може да бъде именуван. Контролната сума може да отхвърли манипулация. Записаните входни данни могат да възпроизведат решението. Побитово идентичният изход означава, че превключването при отказ не трябва тихо да променя отговора. Работата в процес вътре в контролирани системи помага да се избегне проблемът с външната услуга по пътя на решението.
Къде е най-подходящо първо
Lattice има най-голям смисъл при точките на вземане на решения, които се случват често и изискват доказателства по-късно. Проверки за съответствие при транзакции. Ценообразуване и допустимост по време на оферта. Решения за достъп при шлюзове. Скрининг за измами преди сетълмент. Проверки за допустимост в публичния сектор. Етапи за подписване на застраховки. Разрешения за вътрешни работни процеси. Това са места, където „да“ или „не“ не е достатъчно. Системата трябва да знае коя версия на „да“ или „не“ се е случила.
Подходящо е и за места, където едно и също решение трябва да остане същото на различни сървъри. Превключването при отказ не трябва да променя резултата от проверката за съответствие. Регионалното разполагане не трябва да тълкува правило по различен начин, защото версията на библиотека се е променила. Възпроизвеждането за одит не трябва да зависи от това дали същата хостинг услуга на доставчика все още съществува. Правилникът трябва да е достатъчно преносим, за да работи там, където организацията го контролира, и достатъчно изричен, за да поддържа ниски разходите за преминаване.
Ето защо отвореният код е важен и тук. Механизмът за правила, който участва в съответствието, достъпа, ценообразуването или измамите, не е декоративна зависимост. Той е част от контролната равнина. Ако никой вътре в организацията не може да го инспектира, да го фиксира, да го тества и да го поддържа, тогава правилникът не е наистина техен. Той е наета власт.
Какво да прегледате, преди да го приемете
Първо, идентифицирайте точките на вземане на решения. Не започвайте с миграция на платформа. Започнете с един правилник, който ви създава проблеми днес. Колко често се изпълнява? Какво защитава? Кой пита защо? Какво се случва, ако услугата е недостъпна? Какви доказателства са налични шест месеца по-късно?
Второ, прегледайте формата на правилата. Ограниченията булеви ли са, аритметични, линейни, целочислени, с крайна област, подобни на пътеки или меки? Кой клас от бекенда трябва да ги управлява? Ако правилото не може да обясни защо се насочва към определено семейство от решаващи механизми, абстракцията е твърде магическа.
Трето, прегледайте дисциплината около артефактите. Къде се съхранява изходният правилник? Коя компилация е създала артефакта? Коя контролна сума е заредена? Коя версия на приложението го е използвала? Кои входни данни са записани? Кой път за възпроизвеждане доказва отговора? Ако отговорът е разпръснат в три системи и при човек на име Ян, правилникът все още не е обект за одит. Той е традиция.
Урокът
Lattice е история за механизъм за правила, но всъщност е история за контрол. Компилирайте правилника преди заявката. Опаковайте го в артефакт, който приложението може да зареди в паметта. Проверете артефакта, преди да го заредите. Насочвайте ограниченията към правилното семейство от решаващи механизми. Изпълнявайте в процес. Възпроизвеждайте по-късно със същите входни данни и същата версия на правилника.
Това не е бляскаво. Добре. Бизнес правилата не трябва да са бляскави. Те трябва да са скучни, бързи, изрични и проверими. Важните системи за вземане на решения в една компания не трябва да зависят от отдалечени оракули, цикли в парсери и одитна археология. Те трябва да носят своите правилници като инфраструктура.
Правилникът не трябва да е отдалечен оракул. Той трябва да е нещо, което системата може да изпълнява, именува и възпроизвежда.