Одитируемостта не трябва да се добавя по-късно.
Папката, която пристигна твърде късно
Заседателната зала носеше обичайните белези на институционална сериозност: стъклени стени, кафе машина, която се опитваше да имитира съд под налягане, и папка, наречена evidence pack, на споделения екран. Системата, която се оценяваше, работеше от девет месеца. Тя насочваше вътрешни казуси, препоръчваше следващи действия, прехвърляше някои от тях към специалисти и тихо отхвърляше други, защото така казваха конфигурираните прагове. Никой в залата не я описа като система с висок риск по време на възлагането. Тя беше инструмент за производителност, което е начинът, по който организациите наричат инфраструктурата за вземане на решения, преди някой да попита кого е засегнала.
Одиторът зададе малък въпрос. За този казус коя версия на политиката е била активна, когато е изготвена препоръката. Продуктовият собственик погледна архитекта. Архитектът погледна ръководителя на данните. Ръководителят на данните отвори табло, после експорт на логове, после билет. Един разработчик си спомни, че версиите на политиките са се съхранявали в променлива на средата при първото издание и в таблица в базата данни след миграцията през януари. Някой каза, че промяната вероятно е безвредна. Това рядко е изречението, което успокоява одитор.
Нищо не беше създадено с лоши намерения. Екипът имаше логове, мониторинг, контрол на достъпа, резервни копия, билети за инциденти и вътрешно уики с достатъчно страници, за да повреди принтер. Но доказателствата не бяха свойство на системата. Те бяха реконструкция, извършена след събитието от хора, които все още помнеха внедряването. Това не е одитируемост. Това е устна история с времеви отпечатъци.
Одитируемостта не трябва да се добавя по-късно, защото по-късно е точно моментът, в който паметта е станала политически въпрос. Хората са нервни. Системата се е променила. Доставчиците са се сменили. Таблата са преработени. Единственият инженер, който разбираше първоначалния импорт на данни, сега има друга длъжност и говори за онзи период със спокойствието на човек, оцелял след авария на водопровода. Ако записът не е създаден, когато работата е извършена, по-късният разказ винаги ще съдържа повече интерпретация, отколкото доказателства.
Одитируемостта е свойство на дизайна
Много екипи третират одитируемостта като документация. Представят си я като набор от диаграми, контроли, одобрения, бутони за експорт и декларации за политики, които могат да бъдат сглобени, когато системата е близо до издаване. Този възглед е изкушаващ, защото документацията изглежда по-евтина от дизайна. Той позволява на проекта да продължи напред, докато управлението чака учтиво в коридора с клипборд. Сметката идва по-късно, с лихва.
Проследимостта е по-близо до издръжливостта, отколкото до документацията. Една издръжлива система не става издръжлива, защото някой напише доклад, че покривът вероятно би издържал на дъжд. Покривът или отвежда водата, или не я отвежда. Една проследима система или запазва фактите, необходими за проверка на поведението ѝ, или не ги запазва. Фактите може да са скучни: версия, източник, времеви отпечатък, извършител, правило, праг, изключение, одобрение, идентификатор на модел, шаблон за подкана, обхват на данните, състояние на съхранение. Скучното е добре. Мостът също се държи от скучни части. Декоративните лампи не са част от носещата конструкция.
Трудната част е, че одитните факти трябва да се улавят на същото ниво, на което се вземат решенията. Ако даден работен процес използва правило на политика, версията на правилото принадлежи на събитието. Ако резултат от модел бъде приет в досие на случай, версията на модела, увереността, обхватът на източника и правилото за приемане принадлежат на записа. Ако човек отмени препоръка, причината за отмяната принадлежи до действието, а не в бележка от среща две седмици по-късно. Системата не трябва да изисква историк да прави изводи за това, което машината вече е знаела по време на изпълнение.
Ето защо проследимостта не е същото като регистрирането на събития. Регистрите са полезни, но първата им лоялност обикновено е към операциите. Те обясняват грешки, време, повторни опити, изключения и производителност. Проследимостта задава различен набор от въпроси: какъв орган е използван, какви доказателства са разгледани, какво състояние се е променило, кой или какво го е причинило и може ли последователността да бъде проверена, без да се вярва на текущата услуга. Регистрите може да подкрепят тази работа. Те рядко я поемат сами.
Първото решение е какво се брои
Преди една система да бъде проследима, организацията трябва да реши какво се счита за проследимо събитие. Това звучи административно, но тук започва истинската архитектура. Ако всяко кликване е събитие, записът се превръща в сметище. Ако само крайните резултати са събития, записът се превръща в магически трик. Полезният компромис е да се улавят моментите, в които власт, доказателства или състояние преминават от едни ръце в други.
Приемането на случай е такъв момент. Въвеждането на изходен документ в обхвата е друг. Препоръка от модел е такъв момент, ако може да повлияе на работата. Задействането на правило на политика е такъв. Човешкото одобрение е такъв. Отказ, ескалация, изключение, корекция на данни, промяна на съхранението, искане за изтриване и обжалване са всички кандидати. Въпросът не е да се запази всеки дъх на системата. Въпросът е да се запазят ставите, където по-късен рецензент разумно би попитал: защо системата се е преместила оттук дотам.
Този подбор трябва да бъде изричен. В противен случай екипът открива по време на прегледа, че важното събитие е живяло в сянката между два компонента. Интерфейсът знае, че потребителят е видял предупреждение. Бекендът знае, че случаят е променил състоянието си. Услугата за модели знае, че е върнала резултат. Механизмът за работни процеси знае, че е поет клон. Нито един запис не казва, че предупреждението, резултатът, правилото и клонът са принадлежали на едно и също решение. Всеки има парче от вазата. Масата все още е мокра.
След като наборът от събития е назован, инженерите могат да проектират договори около него. Всяко събитие може да има задължителни полета. Всяко поле може да има собственик. Всяка промяна на схемата може да бъде версионирана. Всяко правило за съхранение може да бъде обвързано с правна и оперативна необходимост. Това не е документация, която стои до системата. Това е част от границата на системата. Записът се превръща в продукт на работния процес, а не в извинение, написано от работния процес след обяд.
Времето не е украшение
Одитната работа е обсебена от времето с основателна причина. Решение, взето преди промяна на политика, не е същото като решение, взето след нея. Резултат от модел, създаден преди корекция на данни, не е същият като резултат, създаден след нея. Казус, ескалиран след краен срок, е различен от казус, ескалиран преди него. Времето не е метаданни, поръсени върху събитията. То е част от смисъла на събитието.
Разпределените системи правят времето неудобно. Часовниците се разминават. Опашките разместват реда. Случват се повторни опити. Работниците обработват съобщения със закъснение. Партидите се зареждат през нощта от задания, наречени временни през 2021 г., които вече са културно постоянни. Ако одитният дизайн предполага една-единствена подредена времева линия, първият инцидент ще го научи. Това обучение обикновено се случва в електронна таблица, която е скъпа класна стая.
Един одитируем дизайн разграничава време на събитието, време на обработка, време на влизане в сила и време на преглед там, където разликата има значение. Времето на събитието казва кога се е случило нещото в бизнес процеса. Времето на обработка казва кога даден компонент го е обработил. Времето на влизане в сила казва кога дадено правило или състояние е станало валидно. Времето на преглед казва кога някой по-късно го е инспектирал или коригирал. Тези разграничения могат да изглеждат дребнави, докато един казус не премине полунощ, едно правило не се промени в 09:00 и една опашка не се източва бавно, защото някой е преоразмерил пула от работници с увереност и без доказателства.
Същата грижа важи и за идентичността. Извършителят може да е човек, услуга, агент, планирано задание, делегиран потребител или външна система. Системата трябва да посочи кой е. Тя не трябва да се крие зад администратор на потребители, защото там живее интеграционният акаунт. Когато властта е делегирана, делегирането трябва да е видимо. Когато услуга действа автоматично, притежаващата услуга и правилото трябва да са видими. Одитируемостта изисква посочена отговорност, дори когато името не е човешко същество.
Реконструкцията не е преиграване
Когато екипите добавят одитируемост късно, те често се задоволяват с реконструкция. Събират логове, моментни снимки на бази данни, тикети, чат съобщения и бележки към версиите. Изграждат правдоподобна времева линия. Понякога времевата линия е вярна. Понякога е много подредена измислица с искрени автори. Проблемът не е, че хората лъжат. Проблемът е, че реконструкцията кара хората да запълват празнини под напрежение, а институциите са изключително добри в това да правят празнините да изглеждат умишлени, след като старша среща е започнала.
Replay е различен стандарт. Replay означава, че системата е запазила достатъчно структурирана история, за да може последователността да бъде премината отново. Това не означава, че оригиналният модел трябва да бъде извикан отново или че всяка външна зависимост може да бъде възстановена. Означава, че записът може да покаже какъв вход е бил приет, коя версия на правилото е задействана, какъв изход е произведен, какво действие е предприето и какво състояние е настъпило. Проверяващият трябва да може да разгледа веригата, без да разчита на текущото приложение да разказва ласкава история за по-младото си аз.
Replay променя инженерното поведение. Ако екипът знае, че решенията могат да бъдат преиграни, става по-трудно да се скрива политика в кодови пътища с имена като helper2. Става по-трудно праговете да се променят без да се записва кой ги е променил. Става по-трудно шаблоните за подкани да се третират като местни занаятчийски обекти на лаптоп. Replay изисква всяко значимо действие да носи собствения си контекст. Това е досадно по начина, по който предпазните колани са досадни: най-вече преди катастрофата.
Replay също позволява управлението да стане рутинно. Вместо да чакат инцидент, екипите могат да вземат извадки от случаи, да разглеждат вериги, да сравняват резултати между версии на политики и да откриват липсващи записи. Одитната следа става нещо, което организацията използва, а не нещо, което произвежда само когато е притисната в ъгъла. Тази разлика има значение. Контролите, които се упражняват само по време на страх, имат навика да бъдат декоративни.
Цената на добавянето му по-късно
Късната одитируемост има много специфична миризма. Мирише на нови таблици с имена като audit_log_final. Мирише на експорт на данни, който има повечето колони, но не и тези, свързани с въпроса. Мирише на консултант, който пита дали има източник на истина и получава обиколка на пет системи. Мирише, преди всичко, на обратно инженерство на намерения от странични ефекти.
Прекият разход е инженерно време. Екипите трябва да идентифицират къде са взети решенията, да добавят записване на събития, да попълват исторически записи, да запълват празнини, да документират предположения и да изградят повърхности за експорт. Тази работа често се появява, когато системата вече носи потребители, инциденти, заявки за функции и очаквания. Непрекият разход е по-лош: доверието намалява. Ако организацията не може да отговори на основни въпроси за собствената си система, всеки по-късен отговор се третира с подозрение, дори и правилните.
Има и цена на дизайна. След като една система е изградена без възможност за одит, нейните граници може да не съвпадат с нуждите от доказателства. Решението може да е разпределено между компоненти. Състоянието може да бъде презаписано, вместо да бъде добавено. Причините може да се изчисляват за показване, но да не се съхраняват. Входните данни на модела може да бъдат трансформирани и изхвърлени. Човешките намеси може да живеят в коментари. Тогава добавянето на възможност за одит наготово става по-малко като поставяне на прозорец и повече като откриването, че стената е носеща.
Цената не е само техническа. Късната възможност за одит създава политически спорове за това какво наистина се е случило. Хората защитават екипите си. Доставчиците защитават интерфейсите си. Мениджърите защитават решенията си за пускане. Всеки става любител философ на причинно-следствените връзки. Това е разбираемо и в по-голямата си част безполезно. Добрият запис намалява нуждата от истина, основана на личности. Той позволява на институцията да спори за политика и подобрение, вместо да спори дали миналото съществува.
Добрите записи не са театър за наблюдение
Съществува основателен страх, че възможността за одит се превръща в наблюдение. Някои организации чуват „записвайте всичко“ и се държат така, сякаш всяко човешко колебание заслужава времеви отпечатък. Това не е възможност за одит. Това е институционална тревожност с добавено съхранение. Добрият одитен дизайн е селективен, пропорционален и обвързан със съществени промени. Той записва власт и състояние, а не личен шум.
За служителите разликата има значение. Оператор, който одобрява изключение, трябва да очаква одобрението да бъде записано. Не трябва да очаква всяко движение на курсора да стане част от постоянна морална драма. Специалист, който отменя препоръка на модел, трябва да остави код за причина и бележка, когато решението засяга даден случай. Не трябва да бъде наказван за несъгласие с автоматизация, която и без това е била несигурна. Възможността за одит трябва да прави професионалната преценка видима, а не да прави професионалистите плахи.
За гражданите, клиентите, пациентите или студентите възможността за одит трябва да подкрепя правата. Тя трябва да прави възможно обясняването на решение, коригирането на лоши данни, оспорването на резултат, доказването на изтриване или показването, че даден източник не е бил използван. Запис, който защитава само институцията, е непълен. Одитната следа не трябва да бъде огледало с еднопосочно виждане. Ако системата засяга хора, записът трябва да помага и за отговори на техните легитимни въпроси.
Тук се срещат минимизирането на данни и възможността за одит. Отговорът не е да се пази всичко завинаги. Отговорът е да се пазят правилните факти за правилния период, с ясна цел, правила за достъп и логика за изтриване или съхранение. Един рядък, добре структуриран запис често е по-уважителен и по-полезен от огромна купчина уловени отпадъчни данни. Купчината изглежда безопасна, докато някой не попита какво има в нея. Тогава тя се превръща в отговорност с търсачка.
Регистърът на рисковете трябва да разговаря със схемата на събитията
Регистрите на рисковете често живеят в документи за управление, докато схемите на събитията живеят в инженерни хранилища. Това разделение е удобно и опасно. Регистърът на рисковете казва, че съществува риск от неоторизирана ескалация. Схемата на събитията следователно трябва да записва кой е ескалирал, по каква власт, от кое състояние, към кое състояние и дали ескалацията е била автоматична или ръчна. Ако схемата не улавя тези факти, контролът е само пожелание. Пожеланията са по-евтини от контролите, което обяснява тяхната популярност.
Същото важи и за риска от модела. Ако регистърът казва, че препоръки с ниска увереност трябва да бъдат преглеждани, системата трябва да записва увереността, прага, изискването за преглед, преглеждащия, резултата и причината за освобождаване или отказ. Ако регистърът казва, че обхватът на източниците има значение, събитията трябва да записват обхвата на източниците. Ако съхранението е риск, събитията трябва да записват промените в състоянието на съхранение. Регистърът на рисковете не трябва да бъде проза, плаваща над софтуера. Той трябва да бъде набор от твърдения, които средата за изпълнение може да помогне да се проверят.
Това не означава, че всяко изискване за управление веднага се превръща в код. Някои контроли са човешки, договорни или организационни. Но дори човешките контроли се нуждаят от доказателства. Ръчната проверка пак може да създаде запис. Договорно задължение пак може да съответства на изисквана декларация. Процес на доставчик пак може да бъде представен чрез получено събитие, подписан доклад или състояние на липсващо доказателство. Смисълът е да свържем езика на риска с езика на доказателствата, преди системата да започне да поражда последици.
Тихата полза е по-добрият разговор. Инженерите престават да възприемат управлението като закъсняла поука. Управленските екипи престават да възприемат инженерството като празник на крайни случаи. И двете страни могат да погледнат една и съща схема на събитията и да попитат дали тя носи фактите, нужни за управление на риска. Това е по-малко бляскаво от семинар за AI стратегия. Също така е по-малко вероятно да доведе до PDF, който никой не може да приложи на практика.
Одитируемостта променя разговора за изграждането
Когато одитируемостта присъства от самото начало, прегледите на дизайна стават по-конкретни. Екипът не пита просто дали дадена функция работи. Той пита какъв запис оставя функцията. Пита кой може да прегледа записа, колко дълго се съхранява, какво може да се коригира, какво никога не трябва да се презаписва и на кой бъдещ въпрос трябва да може да отговори. Тези въпроси подобряват функцията, защото разкриват скрито състояние и неясни правомощия.
Снабдяването също се променя. Вместо да питат доставчиците дали поддържат одитни регистри, на което почти всеки може да отговори с радостно „да“, организацията може да поиска конкретни възможности за доказателства. Могат ли версиите на политиките да се експортират с всяко решение. Могат ли идентификаторите на модели и обхватите на източници да бъдат включени. Могат ли човешките корекции да бъдат разграничени от автоматизираните действия. Могат ли записите да се съхраняват, изтриват, подписват или възпроизвеждат според нашите правила. Можем ли да прегледаме следата, без да плащаме за героично професионално обслужване. Последният въпрос често е мястото, където разговорът става поучителен.
Операциите също се променят. Реакцията при инциденти става по-малко спекулативна. Екип може да идентифицира засегнатите случаи, да ги сравни с известни версии на политики, да открие липсващи записи и да покаже пътя от сигнала до действието. Съответствието става по-малко сезонно. Подобряването на продукта става по-честно, защото екипът вижда не само какво е направила системата, но и при какви условия го е направила. Одитируемостта не е спирачка за доставката. Тя е едно от нещата, които предотвратяват превръщането на доставката в бъдеща археологическа разкопка.
Нищо от това не прави системата съвършена. Една одитируема система все още може да взема лоши решения. Тя все още може да кодира слаба политика, да използва ненадеждни данни или да бъде управлявана от хора, които имат съвсем човешки тежък вторник. Одитируемостта не гарантира мъдрост. Тя гарантира, че институцията има по-добър шанс да види какво се е случило, да се поучи от него и да докаже, че не е просто измислила отговора след факта.
Урокът
Основната грешка е да се вярва, че одитируемостта принадлежи накрая, защото одитите се случват накрая. Те не са така. Одитите се случват след последствията, но одитируемостта трябва да съществува преди последствията. Записът трябва да се роди заедно с действието. Събитието трябва да носи своя контекст, докато контекстът все още е верен. Системата трябва да запазва разликата между факт, извод, политика, превишаване на правомощия и корекция.
Това не е призив за тежки процедури около всеки малък инструмент. Това е призив за пропорционалност. Колкото повече една система променя права, достъп, пари, безопасност, допустимост, натовареност или институционална памет, толкова повече тя трябва да оставя структурирани доказателства. Започнете с границите, които имат значение. Назовете събитията. Версионирайте правилата. Запазвайте времето и самоличността. Правете корекциите адитивни. Тествайте възпроизвеждането, преди страхът да влезе в стаята.
Има нещо почти комично в тази дисциплина. Бъдещето на доверената автоматизация зависи по-малко от зрелищния интелект, отколкото от помненето кое правило е задействано в дъждовна сряда през февруари. Но сериозните институции са изградени върху точно такъв вид памет. Те не се доверяват на системите, защото системите звучат уверено. Те им се доверяват, защото системите могат да бъдат проверени, когато увереността вече не е достатъчна.
Затова добавяйте доказателствата, докато работата е все още обикновена. Преди партито по повод пускането, преди инцидента, преди миграцията, преди екипът да забрави защо това поле е било незадължително. По-късно ще дойде. По-късно винаги идва, носейки папка, наречена пакет с доказателства, и въпрос, който заслужава по-добър отговор от „вероятно“.