Revizijska sledljivost ne sme biti dodana naknadno
Mapa, ki je prispela prepozno
Sejna soba je imela običajne znake institucionalne resnosti: steklene stene, aparat za kavo, ki se je trudil biti tlačna posoda, in mapo z imenom evidence pack na skupnem zaslonu. Sistem v pregledu je bil v živo devet mesecev. Usmerjal je notranje primere, priporočal naslednje korake, nekatere stopnjeval do strokovnjakov, druge pa je tiho zavrnil, ker so tako narekovali konfigurirani pragovi. Nihče v sobi ga med javnim naročilom ni opisal kot visoko tvegan sistem. Bil je orodje za produktivnost, kar organizacije imenujejo infrastrukturo za odločanje, preden kdo vpraša, koga je prizadela.
Revizor je zastavil majhno vprašanje. Za ta primer, katera različica pravilnika je bila aktivna, ko je bilo priporočilo ustvarjeno. Lastnik izdelka je pogledal arhitekta. Arhitekt je pogledal vodjo podatkov. Vodja podatkov je odprl nadzorno ploščo, nato izvoz dnevnikov, nato zahtevek. Razvijalec se je spomnil, da so bile različice pravilnikov ob prvi izdaji shranjene v okoljski spremenljivki, po januarski selitvi pa v podatkovni tabeli. Nekdo je rekel, da je bila sprememba verjetno neškodljiva. To redko stavek, ki revizorja pomiri.
Nič ni bilo zgrajeno s slabim namenom. Ekipa je imela dnevnike, spremljanje, nadzor dostopa, varnostne kopije, zahtevke za incidente in notranji wiki z dovolj stranmi, da bi uničil tiskalnik. Toda dokazi niso bili lastnost sistema. Bili so rekonstrukcija, opravljena naknadno, ki so jo izvedli ljudje, ki so si namestitev še zapomnili. To ni revizijska sled. To je ustno izročilo s časovnimi žigi.
Revizijske sledi ne bi smeli dodajati pozneje, ker je pozneje ravno takrat, ko spomin postane političen. Ljudje so nervozni. Sistem se je spremenil. Dobavitelji so se zamenjali. Nadzorne plošče so bile preoblikovane. Edini inženir, ki je razumel prvotni uvoz podatkov, ima zdaj drug naziv delovnega mesta in o tistem obdobju govori z mirnostjo nekoga, ki je preživel vodovodno nesrečo. Če zapis ni bil ustvarjen, ko se je delo zgodilo, bo poznejša zgodba vedno vsebovala več interpretacije kot dokazov.
Revizijska sled je oblikovna lastnost
Številne ekipe obravnavajo revizijsko sled kot dokumentacijo. Predstavljajo si jo kot niz diagramov, kontrol, odobritev, gumbov za izvoz in izjav o pravilnikih, ki jih je mogoče sestaviti, ko se sistem približa izdaji. To stališče je mamljivo, ker se zdi dokumentacija cenejša od oblikovanja. Projektu omogoča, da se nadaljuje, medtem ko upravljanje vljudno čaka na hodniku s kartoteko. Račun prispe pozneje, z obrestmi.
Revizijska sledljivost je bližje vzdržljivosti kot dokumentaciji. Vzdržljiv sistem ne postane vzdržljiv zato, ker nekdo napiše poročilo, da bi streha verjetno prenesla dež. Streha bodisi odvaja vodo bodisi je ne. Revidiran sistem bodisi ohrani dejstva, potrebna za pregled njegovega delovanja, bodisi jih ne. Dejstva so lahko dolgočasna: različica, vir, časovni žig, akter, pravilo, prag, izjema, odobritev, identifikator modela, predloga poziva, obseg podatkov, stanje hrambe. Dolgočasno je v redu. Most namreč držijo tudi dolgočasni deli. Okrasne svetilke niso del nosilne konstrukcije.
Težavni del je, da je treba revizijska dejstva zajeti na isti ravni, kjer se sprejemajo odločitve. Če delovni proces uporablja pravilo pravilnika, sodi različica pravila v dogodek. Če je izhod modela sprejet v spis primera, sodijo v zapis različica modela, stopnja zaupanja, obseg vira in pravilo sprejema. Če človek preglasi priporočilo, sodi razlog za preglasitev k dejanju, ne v zapisnik sestanka dva tedna pozneje. Sistem ne bi smel zahtevati zgodovinarja, da bi sklepal o tem, kar je stroj že vedel ob izvajanju.
Prav zato revizijska sledljivost ni enaka beleženju. Dnevniki so uporabni, vendar je njihova prva zvestoba običajno operativi. Pojasnjujejo napake, čase, ponovne poskuse, izjeme in zmogljivost. Revizijska sledljivost postavlja drugačen niz vprašanj: katero pooblastilo je bilo uporabljeno, kateri dokazi so bili upoštevani, katero stanje se je spremenilo, kdo ali kaj ga je povzročilo in ali je mogoče zaporedje preveriti brez zaupanja trenutni storitvi. Dnevniki lahko podprejo to delo. Le redko ga opravijo sami.
Prva odločitev je, kaj šteje
Preden je sistem lahko revidiran, se mora organizacija odločiti, kaj šteje kot revizijski dogodek. To zveni administrativno, a tu se začne prava arhitektura. Če je vsak klik dogodek, zapis postane odlagališče. Če so dogodki le končni izidi, zapis postane čarovniški trik. Uporabna sredina je zajemanje trenutkov, ko si pooblastilo, dokazi ali stanje zamenjajo lastnika.
Sprejem primera je tak trenutek. Vstop izvornega dokumenta v obseg je drugi. Priporočilo modela je dogodek, če lahko vpliva na delo. Sprožitev pravilnika je dogodek. Človeška odobritev je dogodek. Zavrnitev, eskalacija, izjema, popravek podatkov, sprememba hrambe, zahteva za izbris in pritožba so vsi kandidati. Bistvo ni ohraniti vsak dih sistema. Bistvo je ohraniti stike, kjer bi poznejši pregledovalec upravičeno vprašal: zakaj se je sistem premaknil od tod do tja.
Ta izbor mora biti izrecen. V nasprotnem primeru ekipa med pregledom odkrije, da je pomemben dogodek živel v senci med dvema komponentama. Čelni del ve, da je uporabnik videl opozorilo. Zaledni del ve, da je primer spremenil stanje. Storitev modela ve, da je vrnila oceno. Mehanizem delovnega procesa ve, da je bila izbrana veja. Noben posamezen zapis ne pove, da so opozorilo, ocena, pravilo in veja pripadali isti odločitvi. Vsak ima del vaze. Miza je še vedno mokra.
Ko je nabor dogodkov imenovan, lahko inženirji načrtujejo pogodbe okoli njega. Vsak dogodek ima lahko obvezna polja. Vsako polje ima lahko lastnika. Vsaka sprememba sheme je lahko različicana. Vsako pravilo hrambe je lahko povezano s pravno in operativno potrebo. To ni papirologija, ki stoji ob strani sistema. Je del meje sistema. Zapis postane proizvod delovnega procesa, ne opravičilo, ki ga delovni proces napiše po kosilu.
Čas ni okras
Revizijsko delo je obsedeno s časom z dobrim razlogom. Odločitev, sprejeta pred spremembo politike, ni enaka odločitvi, sprejeti po njej. Izid modela, ustvarjen pred popravkom podatkov, ni enak izidu, ustvarjenemu po njem. Primer, stopnjevan po roku, je drugačen od primera, stopnjevanega pred rokom. Čas ni metapodatek, posut po dogodkih. Je del pomena dogodka.
Porazdeljeni sistemi naredijo čas nerodnega. Ure se razidejo. Čakalne vrste premeščajo. Ponovitve se zgodijo. Delavci obdelujejo sporočila pozno. Paketi se nalagajo čez noč z opravili, ki so bila leta 2021 poimenovana kot začasna in so zdaj kulturno stalna. Če zasnova revizije predpostavlja eno samo urejeno časovnico, jo bo prvi incident poučil. To izobraževanje se običajno zgodi v preglednici, ki je draga učilnica.
Revizijska zasnova razlikuje med časom dogodka, časom obdelave, časom veljavnosti in časom pregleda, kjer razlika ni pomembna. Čas dogodka pove, kdaj se je stvar zgodila v poslovnem procesu. Čas obdelave pove, kdaj jo je komponenta obravnavala. Čas veljavnosti pove, kdaj je pravilo ali stanje postalo veljavno. Čas pregleda pove, kdaj jo je nekdo pozneje pregledal ali popravil. Te razlike se lahko zdijo sitne, dokler en primer ne prečka polnoči, eno pravilo se ne spremeni ob 09:00 in ena čakalna vrsta se ne prazni počasi, ker je nekdo spremenil velikost gruče delavcev s samozavestjo in brez dokazov.
Enaka skrb velja za identiteto. Akter je lahko oseba, storitev, agent, načrtovano opravilo, pooblaščeni uporabnik ali zunanji sistem. Sistem bi moral povedati, kdo. Ne bi se smel skrivati za skrbnikom uporabnikov, ker tam živi integracijski račun. Ko je pooblastilo preneseno, mora biti prenos viden. Ko storitev deluje samodejno, morata biti vidna lastniška storitev in pravilo. Revizijska sledljivost zahteva poimenovano odgovornost, tudi če ime ni človeško bitje.
Rekonstrukcija ni ponovitev
Ko ekipe revizijsko sledljivost dodajajo pozno, se pogosto zadovoljijo z rekonstrukcijo. Zberejo dnevnike, posnetke podatkovnih baz, vstopnice, sporočila v klepetu in opombe ob izdajah. Zgradijo verjetno časovnico. Včasih je časovnica pravilna. Včasih je zelo urejena fikcija z iskrenimi avtorji. Težava ni v tem, da ljudje lažejo. Težava je v tem, da rekonstrukcija od ljudi zahteva, da zapolnijo vrzeli pod pritiskom, in institucije so izjemno dobre pri tem, da vrzeli izgledajo namerne, ko se začne sestanek višjega vodstva.
Replay je drugačen standard. Replay pomeni, da je sistem ohranil dovolj strukturirane zgodovine, da lahko zaporedje ponovno prehodi. Ne pomeni, da je treba znova klicati prvotni model ali da je mogoče obuditi vsako zunanjo odvisnost. Pomeni, da lahko zapis pokaže, kateri vnos je bil sprejet, katera različica pravil je bila uporabljena, kakšen izhod je bil ustvarjen, katero dejanje je bilo izvedeno in kakšno stanje je nastalo. Pregledovalec bi moral biti sposoben pregledati verigo, ne da bi se zanašal na to, da trenutna aplikacija pripoveduje laskavo zgodbo o svojem mlajšem jazu.
Replay spreminja inženirsko vedenje. Če ekipa ve, da je odločitve mogoče ponovno predvajati, je težje skriti politike v delih kode z imeni, kot je helper2. Težje je pustiti, da pragovi odstopajo, ne da bi se zabeležilo, kdo jih je spremenil. Težje je obravnavati predloge pozivov kot lokalne obrtniške predmete na prenosniku. Replay od vsakega pomembnega dejanja zahteva, da nosi svoj kontekst. To je nadležno na način, kot so nadležni varnostni pasovi: večinoma pred nesrečo.
Replay prav tako omogoča, da upravljanje postane rutina. Namesto čakanja na incident lahko ekipe vzorčijo primere, pregledujejo verige, primerjajo izide med različicami politik in odkrijejo manjkajoče zapise. Revizijska sled postane nekaj, kar organizacija uporablja, ne nekaj, kar ustvari le, ko je prignana v kot. Ta razlika je pomembna. Nadzori, ki se izvajajo le med strahom, imajo navado biti dekorativni.
Stroški dodajanja pozneje
Pozna revidibilnost ima zelo poseben vonj. Diši po novih tabelah z imeni, kot je audit_log_final. Diši po izvozu podatkov, ki ima večino stolpcev, a ne tistih, povezanih z vprašanjem. Diši po svetovalcu, ki vpraša, ali obstaja vir resnice, in dobi ogled petih sistemov. Predvsem pa diši po obratnem inženirstvu namena iz stranskih učinkov.
Neposredni strošek je inženirski čas. Ekipe morajo ugotoviti, kje so se odločitve zgodile, dodati zajem dogodkov, dopolniti zgodovinske zapise, zakrpati vrzeli, dokumentirati predpostavke in zgraditi površine za izvoz. To delo pogosto pristane, ko sistem že nosi uporabnike, incidente, zahteve za funkcije in pričakovanja. Posredni strošek je hujši: zaupanje upada. Če organizacija ne more odgovoriti na osnovna vprašanja o lastnem sistemu, se vsak poznejši odgovor obravnava s sumom, tudi pravilni.
Obstaja tudi oblikovalski strošek. Ko je sistem enkrat zgrajen brez možnosti revizije, se njegove meje morda ne bodo ujemale s potrebami po dokazih. Odločitev je lahko razdeljena med komponente. Stanje se lahko prepiše namesto da bi se dodalo. Razlogi se lahko izračunajo za prikaz, a se ne shranijo. Vhodi modela se lahko preoblikujejo in zavržejo. Človeški posegi lahko živijo v komentarjih. Naknadno uvajanje revizije potem ni več kot dodajanje okna, ampak bolj kot odkritje, da je stena nosilna.
Strošek ni samo tehničen. Pozna revizija ustvarja politične prepire o tem, kaj se je dejansko zgodilo. Ljudje branijo svoje ekipe. Dobavitelji branijo svoje vmesnike. Vodje branijo odločitve o zagonu. Vsi postanejo amaterski filozofi vzročnosti. To je razumljivo in večinoma neuporabno. Dober zapis zmanjša potrebo po resnici, ki temelji na osebnosti. Instituciji omogoči, da razpravlja o politiki in izboljšavah, namesto da se prepira o tem, ali preteklost obstaja.
Dobri zapisi niso gledališče nadzora
Obstaja upravičen strah, da revizija postane nadzor. Nekatere organizacije slišijo zabeleži vse in se obnašajo, kot da si vsako človeško oklevanje zasluži časovni žig. To ni revizija. To je institucionalna tesnoba s shranjevanjem. Dobra zasnova revizije je selektivna, sorazmerna in vezana na pomembne spremembe. Zapisuje pooblastila in stanje, ne zasebnega šuma.
Za zaposlene je razlika pomembna. Operater, ki odobri izjemo, lahko pričakuje, da bo odobritev zabeležena. Ne sme pričakovati, da bo vsak premik kurzorja postal del trajne moralne igre. Specialist, ki preglasi priporočilo modela, mora pustiti kodo razloga in opombo, ko odločitev vpliva na primer. Ne sme biti kaznovan zaradi nestrinjanja z avtomatizacijo, ki je bila že tako negotova. Revizija mora narediti strokovno presojo vidno, ne pa narediti strokovnjake plašne.
Za državljane, stranke, paciente ali študente mora revizija podpirati pravice. Omogočiti mora razlago odločitve, popravek napačnih podatkov, izpodbijanje izida, dokaz izbrisa ali prikaz, da vir ni bil uporabljen. Zapis, ki ščiti samo institucijo, je nepopoln. Revizijska sled ne sme biti enosmerno ogledalo. Če sistem vpliva na ljudi, mora zapis pomagati odgovoriti tudi na njihova upravičena vprašanja.
Tu se srečata minimizacija podatkov in revizija. Odgovor ni, da obdržimo vse za vedno. Odgovor je, da obdržimo prave podatke za pravo obdobje, z jasnim namenom, pravili dostopa ter logiko izbrisa ali hrambe. Redek, dobro strukturiran zapis je pogosto bolj spoštljiv in uporabnejši kot ogromna gmota zajetih izpustov. Gmota se zdi varna, dokler nekdo ne vpraša, kaj je v njej. Potem postane obveznost z iskanjem.
Register tveganj naj se pogovarja s shemo dogodkov
Registri tveganj pogosto živijo v dokumentih upravljanja, sheme dogodkov pa v inženirskih repozitorijih. Ta ločitev je priročna in nevarna. Register tveganj pravi, da obstaja tveganje nepooblaščene eskalacije. Shema dogodkov bi zato morala beležiti, kdo je eskaliral, pod katerim pooblastilom, iz katerega stanja, v katero stanje in ali je bila eskalacija samodejna ali ročna. Če shema teh dejstev ne zajame, je kontrola zgolj želja. Želje so cenejše od kontrol, kar pojasnjuje njihovo priljubljenost.
Enako velja za tveganje modela. Če register pravi, da je treba priporočila z nizko zanesljivostjo pregledati, mora sistem beležiti zanesljivost, prag, zahtevo po pregledu, pregledovalca, izid in razlog za sprostitev ali zavrnitev. Če register pravi, da je obseg virov pomemben, morajo dogodki beležiti obseg virov. Če je hramba tveganje, morajo dogodki beležiti spremembe stanja hrambe. Register tveganj ne sme biti proza, ki lebdi nad programsko opremo. Biti mora niz trditev, ki jih lahko izvajalno okolje pomaga preveriti.
To ne pomeni, da vsaka zahteva upravljanja takoj postane koda. Nekateri nadzori so človeški, pogodbeni ali organizacijski. Toda tudi človeški nadzori potrebujejo dokaze. Ročni pregled lahko še vedno ustvari zapis. Pogodbena obveznost se lahko še vedno preslika v zahtevano potrditev. Postopek dobavitelja je lahko še vedno predstavljen s prejetim dogodkom, podpisanim poročilom ali stanjem manjkajočega dokaza. Bistvo je povezati jezik tveganj z jezikom dokazov, preden sistem začne ustvarjati posledice.
Tiha prednost je boljši pogovor. Inženirji nehajo dojemati upravljanje kot grajo v pozni fazi. Ekipe za upravljanje nehajo dojemati inženirstvo kot festival robnih primerov. Oboji lahko pogledajo isto shemo dogodkov in se vprašajo, ali nosi dejstva, potrebna za obvladovanje tveganja. To je manj glamurozno kot delavnica o strategiji umetne inteligence. Prav tako je manj verjetno, da bo ustvarilo dokument PDF, ki ga nihče ne more uporabiti v praksi.
Sposobnost revizije spremeni pogovor o razvoju
Ko je sposobnost revizije prisotna od začetka, postanejo pregledi načrtovanja konkretnejši. Ekipa se ne sprašuje le, ali funkcija deluje. Sprašuje se, kakšen zapis funkcija pusti. Sprašuje se, kdo lahko pregleda zapis, kako dolgo živi, kaj je mogoče popraviti, česar nikoli ne sme biti prepisano in na katero prihodnje vprašanje bi moral znati odgovoriti. Ta vprašanja izboljšajo funkcijo, ker razkrijejo skrito stanje in nejasno pooblastilo.
Spremeni se tudi nabava. Namesto da bi dobavitelje spraševali, ali podpirajo dnevnike revizije, na kar skoraj vsakdo lahko odgovori z veselim pritrdilom, lahko organizacija zahteva posebne zmožnosti dokazovanja. Ali je mogoče izvoziti različice pravilnikov z vsako odločitvijo. Ali je mogoče vključiti identifikatorje modelov in obsege virov. Ali je mogoče razlikovati človeške preklici od avtomatiziranih dejanj. Ali je mogoče zapise hraniti, izbrisati, podpisati ali ponovno predvajati v skladu z našimi pravili. Ali lahko pregledamo sled brez plačila za junaško pustolovščino strokovnih storitev. Zadnja točka je pogosto tista, kjer postane prostor poučen.
Spremeni se tudi delovanje. Odzivanje na incidente postane manj špekulativno. Ekipa lahko identificira prizadete primere, jih primerja z znanimi različicami pravilnikov, poišče manjkajoče zapise in pokaže pot od signala do ukrepanja. Delo za skladnost postane manj sezonsko. Izboljšanje izdelka postane bolj iskreno, ker ekipa vidi ne le, kaj je sistem naredil, ampak pod katerimi pogoji je to naredil. Sposobnost revizije ni zavora pri dobavi. Je ena od stvari, ki preprečuje, da bi dobava postala prihodnje izkopavanje.
Nič od tega ne naredi sistema popolnega. Revidiran sistem lahko še vedno sprejema slabe odločitve. Še vedno lahko vključuje slabo politiko, uporablja šibke podatke ali pa ga upravljajo ljudje, ki imajo čisto človeški torek. Revidibilnost ne zagotavlja modrosti. Zagotavlja, da ima institucija večjo možnost, da vidi, kaj se je zgodilo, se iz tega uči in dokaže, da si odgovora ni preprosto izmislila naknadno.
Nauk
Osrednja napaka je prepričanje, da revidibilnost sodi na konec, ker se revizije zgodijo na koncu. Ne zgodijo se. Revizije se zgodijo po posledicah, vendar mora revidibilnost obstajati pred posledicami. Zapis se mora roditi skupaj z dejanjem. Dogodek mora nositi svoj kontekst, dokler je kontekst še resničen. Sistem mora ohranjati razliko med dejstvom, sklepanjem, politiko, preglasitvijo in popravkom.
To ni poziv k težkemu procesu okoli vsakega majhnega orodja. To je poziv k sorazmernosti. Bolj ko sistem spreminja pravice, dostop, denar, varnost, upravičenost, delovno obremenitev ali institucionalni spomin, bolj mora puščati strukturirane dokaze. Začnite pri mejah, ki imajo posledice. Poimenujte dogodke. Različice pravil. Ohranite čas in identiteto. Popravke naredite aditivne. Preizkusite predvajanje, preden strah vstopi v prostor.
V tej disciplini je nekaj skoraj komičnega. Prihodnost zaupanja vredne avtomatizacije je manj odvisna od spektakularne inteligence kot od tega, da se spomnimo, katero pravilo se je sprožilo na mokro sredo v februarju. Toda resne institucije so zgrajene na tovrstnem spominu. Sistemom ne zaupajo, ker zvenijo samozavestno. Sistemom zaupajo, ker jih je mogoče pregledati, ko samozavest ni več dovolj.
Zato dodajte dokaze, medtem ko je delo še običajno. Pred zabavo ob zagonu, pred incidentom, pred selitvijo, preden ekipa pozabi, zakaj je bilo to polje neobvezno. Kasneje bo prišlo. Kasneje vedno pride, nosi mapo z imenom dokazni sveženj in vprašanje, ki si zasluži boljši odgovor kot verjetno.