Revizija se ne smije dodavati naknadno
Mapa koja je stigla prekasno
Soba za sastanke imala je uobičajene znakove institucionalne ozbiljnosti: stakleni zidovi, aparat za kavu koji se iz sve snage pretvarao u posudu pod tlakom i mapa pod nazivom evidence pack na zajedničkom zaslonu. Sustav koji se revidirao bio je u uporabi devet mjeseci. Usmjeravao je interne predmete, predlagao sljedeće korake, neke je prosljeđivao stručnjacima, a druge je tiho odbijao jer su tako nalaženi konfigurirani pragovi. Nitko u prostoriji nije ga tijekom nabave opisao kao visokorizičan sustav. Bio je to alat za produktivnost, što je naziv koji organizacije koriste za infrastrukturu odlučivanja prije nego itko pita koga je zahvatila.
Revizor je postavio malo pitanje. Za ovaj predmet, koja je verzija pravila bila aktivna kada je preporuka izrađena. Vlasnik proizvoda pogledao je arhitekta. Arhitekt je pogledao voditelja podataka. Voditelj podataka otvorio je nadzornu ploču, zatim izvoz zapisa, zatim zahtjev. Programer se sjetio da su verzije pravila tijekom prvog izdanja bile pohranjene u varijabli okruženja, a nakon migracije u siječnju u tablici baze podataka. Netko je rekao da je promjena vjerojatno bezopasna. To rijetko biva rečenica zbog koje se revizor opusti.
Ništa nije izgrađeno s lošom namjerom. Tim je imao zapise, nadzor, kontrolu pristupa, sigurnosne kopije, zapise o incidentima i internu wiki sa dovoljno stranica da uništi pisač. No dokazi nisu bili svojstvo sustava. Bili su vježba rekonstrukcije provedena naknadno, od strane ljudi koji su se još sjećali implementacije. To nije revizijska sljedivost. To je usmena povijest s vremenskim oznakama.
Revizijsku sljedivost ne bi trebalo dodavati kasnije jer je kasnije upravo ono vrijeme kada sjećanje postaje političko. Ljudi su nervozni. Sustav se promijenio. Dobavljači su se izmijenili. Nadzorne ploče su redizajnirane. Jedini inženjer koji je razumio izvorni uvoz podataka sada ima drugi naziv radnog mjesta i o tom razdoblju govori smirenošću nekoga tko je preživio poplavu u vodovodu. Ako zapis nije stvoren kada se posao dogodio, kasnija će priča uvijek sadržavati više tumačenja nego dokaza.
Revizijska sljedivost je svojstvo dizajna
Mnogi timovi revizijsku sljedivost tretiraju kao dokumentaciju. Zamišljaju je kao skup dijagrama, kontrola, odobrenja, gumba za izvoz i izjava o politikama koji se može sastaviti kada se sustav približi izdanju. Ovaj je pogled primamljiv jer dokumentacija djeluje jeftinije od dizajna. Omogućuje projektu da nastavi napredovati dok upravljanje strpljivo čeka u hodniku s prijenosnim računalom. Račun stiže kasnije, s kamatama.
Auditabilnost je bliža trajnosti nego dokumentaciji. Trajan sustav ne postaje trajan zato što netko napiše izvješće da bi krov vjerojatno preživio kišu. Krov ili odvodi vodu ili ne odvodi. Auditabilan sustav ili čuva činjenice potrebne za uvid u svoje ponašanje ili ih ne čuva. Činjenice mogu biti dosadne: verzija, izvor, vremenska oznaka, akter, pravilo, prag, iznimka, odobrenje, identifikator modela, predložak upita, opseg podataka, stanje zadržavanja. Dosadno je u redu. Most također drže dosadni dijelovi. Ukrasne lampe nisu nosivi put.
Teži dio je da se činjenice za reviziju moraju zabilježiti na istoj razini na kojoj se donose odluke. Ako tijek rada koristi pravilo politike, verzija pravila pripada događaju. Ako se izlaz modela prihvaća u spis predmeta, verzija modela, pouzdanost, opseg izvora i pravilo prihvaćanja pripadaju zapisu. Ako čovjek nadjača preporuku, razlog nadjačavanja pripada uz radnju, a ne bilješci sa sastanka dva tjedna kasnije. Sustav ne bi trebao zahtijevati povjesničara da zaključi ono što je stroj već znao u trenutku izvođenja.
Zato auditabilnost nije isto što i zapisivanje. Zapisi su korisni, ali njihova prva odanost obično je operacijama. Oni objašnjavaju kvarove, vremena, ponovne pokušaje, iznimke i performanse. Auditabilnost postavlja drugačiji skup pitanja: koje je ovlasti korišteno, koji su dokazi razmotreni, koje se stanje promijenilo, tko ili što ga je uzrokovalo i može li se slijed provjeriti bez povjerenja u trenutnu uslugu. Zapisi mogu podržati taj rad. Rijetko ga nose sami.
Prva odluka je što se ubraja
Prije nego sustav može biti auditabilan, organizacija mora odlučiti što se ubraja kao događaj za reviziju. Zvuči administrativno, ali tu počinje prava arhitektura. Ako je svaki klik događaj, zapis postaje odlagalište. Ako su samo konačni ishodi događaji, zapis postaje mađioničarski trik. Korisna sredina je zabilježiti trenutke u kojima ovlasti, dokazi ili stanje prelaze iz ruke u ruku.
Prijem predmeta je takav trenutak. Ulazak izvornog dokumenta u opseg je drugi. Preporuka modela jest jedan ako može utjecati na rad. Aktiviranje pravila politike jest jedan. Ljudsko odobrenje jest jedno. Odbijanje, eskalacija, iznimka, ispravak podataka, promjena zadržavanja, zahtjev za brisanje i žalba svi su kandidati. Poanta nije sačuvati svaki dah sustava. Poanta je sačuvati spojeve na kojima bi kasniji recenzent s razlogom pitao: zašto se sustav pomaknuo odavde do tamo.
Taj odabir mora biti izričit. Inače tim tijekom revizije otkrije da je važan događaj živio u sjeni između dviju komponenti. Sučelje zna da je korisnik vidio upozorenje. Pozadina zna da se predmet pomaknuo u stanju. Usluga modela zna da je vratila ocjenu. Motor tijeka rada zna da je grana odabrana. Nijedan zapis ne kaže da su upozorenje, ocjena, pravilo i grana pripadali istoj odluci. Svatko ima komadić vaze. Stol je još mokar.
Kad je skup događaja imenovan, inženjeri mogu dizajnirati ugovore oko njega. Svaki događaj može imati obavezna polja. Svako polje može imati vlasništvo. Svaka promjena sheme može biti verzionirana. Svako pravilo zadržavanja može biti povezano s pravnom i operativnom potrebom. To nije papirologija koja stoji pokraj sustava. To je dio granice sustava. Zapis postaje proizvod tijeka rada, a ne isprika koju tijek rada napiše poslije ručka.
Vrijeme nije ukras
Revizijski se posao s razlogom opsjeda vremenom. Odluka donesena prije promjene politike nije isto što i odluka donesena nakon nje. Izlaz modela proizveden prije ispravka podataka nije isto što i onaj proizveden nakon njega. Predmet eskaliran nakon roka razlikuje se od predmeta eskaliranog prije roka. Vrijeme nije metapodatak posut po događajima. Ono je dio značenja događaja.
Distribuirani sustavi čine vrijeme nezgrapnim. Satovi lutaju. Redovi čekanja mijenjaju poredak. Ponavljanja se događaju. Radnici obrađuju poruke sa zakašnjenjem. Serije se učitavaju preko noći poslovima koji su 2021. nazvani privremenima, a sada su kulturološki trajni. Ako dizajn revizije pretpostavlja jedan uredan vremenski slijed, prvi će ga incident poučiti. To se poučavanje obično događa u proračunskoj tablici, koja je skupa učionica.
Dizajn prilagođen reviziji razlikuje vrijeme događaja, vrijeme obrade, vrijeme važenja i vrijeme pregleda tamo gdje je razlika bitna. Vrijeme događaja govori kada se nešto dogodilo u poslovnom procesu. Vrijeme obrade govori kada je komponenta to obradila. Vrijeme važenja govori kada je pravilo ili stanje postalo valjano. Vrijeme pregleda govori kada je netko kasnije to pregledao ili ispravio. Te razlike mogu djelovati sitničavo sve dok jedan predmet ne prijeđe ponoć, jedno pravilo ne promijeni vrijednost u 09:00 i jedan red čekanja ne počne polako prazniti jer je netko promijenio veličinu grupe radnika sa samopouzdanjem i bez dokaza.
Ista se pažnja odnosi na identitet. Akter može biti osoba, usluga, agent, zakazani posao, delegirani korisnik ili vanjski sustav. Sustav bi trebao reći koji je od toga. Ne bi se smio skrivati iza administratorskog korisnika zato što ondje živi integracijski račun. Kada je ovlast delegirana, delegacija bi trebala biti vidljiva. Kada usluga djeluje automatski, vlasnička usluga i pravilo trebali bi biti vidljivi. Revidibilnost zahtijeva imenovanu odgovornost, čak i kada ime nije ljudsko biće.
Rekonstrukcija nije ponavljanje
Kada timovi revidibilnost dodaju kasno, često se zadovolje rekonstrukcijom. Skupljaju zapise, snimke baza podataka, tikete, poruke u chatu i bilješke o izdanjima. Grade uvjerljiv vremenski slijed. Ponekad je vremenski slijed točan. Ponekad je to vrlo uredna fikcija s iskrenim autorima. Problem nije u tome što ljudi lažu. Problem je u tome što rekonstrukcija od ljudi traži da popune praznine pod pritiskom, a institucije su iznimno dobre u tome da praznine izgledaju namjernima čim počne sastanak višeg rukovodstva.
Replay je drugačiji standard. Replay znači da je sustav zadržao dovoljno strukturirane povijesti da se slijed može ponovno proći. To ne znači da se originalni model mora ponovno pozvati ili da se svaka vanjska ovisnost može uskrsnuti. Znači da zapis može pokazati koji je unos prihvaćen, koja je verzija pravila aktivirana, koji je izlaz proizveden, koja je radnja poduzeta i kakvo je stanje uslijedilo. Recenzent bi trebao moći pregledati lanac bez oslanjanja na trenutnu aplikaciju da ispriča laskavu priču o svojem mlađem ja.
Replay mijenja inženjersko ponašanje. Ako tim zna da se odluke mogu ponovno reproducirati, postaje teže sakriti politiku unutar putanja koda s nazivima poput helper2. Postaje teže dopustiti da pragovi odlutaju bez bilježenja tko ih je promijenio. Postaje teže tretirati predloške upita kao lokalne zanatske predmete na prijenosniku. Replay zahtijeva da svaka značajna radnja nosi svoj vlastiti kontekst. To je iritantno na način na koji su sigurnosni pojasevi iritantni: uglavnom prije sudara.
Replay također omogućuje upravljanju da postane rutina. Umjesto čekanja na incident, timovi mogu uzorkovati slučajeve, pregledavati lance, uspoređivati ishode među verzijama politika i otkrivati nedostajuće zapise. Revizijski trag postaje nešto što organizacija koristi, a ne nešto što proizvodi samo kad je pritisnuta uza zid. Ta razlika je važna. Kontrole koje se provode samo tijekom straha imaju naviku biti dekorativne.
Cijena dodavanja kasnije
Kasna revidibilnost ima vrlo specifičan miris. Miriše na nove tablice s nazivima poput audit_log_final. Miriše na izvoz podataka koji ima većinu stupaca, ali ne i one povezane s pitanjem. Miriše na konzultanta koji pita postoji li izvor istine i dobiva obilazak pet sustava. Miriše, iznad svega, na obrnuto inženjerstvo namjere iz nuspojava.
Izravni trošak je inženjersko vrijeme. Timovi moraju identificirati gdje su se odluke dogodile, dodati snimanje događaja, popuniti povijesne zapise, zakrpati praznine, dokumentirati pretpostavke i izgraditi površine za izvoz. Taj posao često stigne kad sustav već nosi korisnike, incidente, zahtjeve za funkcijama i očekivanja. Neizravni trošak je gori: povjerenje opada. Ako organizacija ne može odgovoriti na osnovna pitanja o vlastitom sustavu, svaki kasniji odgovor tretira se sa sumnjom, čak i oni točni.
Postoji i dizajnerski trošak. Kad se sustav jednom izgradi bez mogućnosti revizije, njegove granice možda neće odgovarati potrebama za dokazima. Odluka može biti razdijeljena na više komponenti. Stanje može biti prepisano umjesto dodano. Razlozi mogu biti izračunati za prikaz, ali ne i pohranjeni. Ulazni podaci modela mogu biti transformirani i odbačeni. Ljudska nadjačavanja mogu živjeti u komentarima. Naknadno uvođenje mogućnosti revizije tada postaje manje poput dodavanja prozora, a više poput otkrića da je zid nosiv.
Trošak nije samo tehnički. Kasno uvođenje mogućnosti revizije stvara političke rasprave o tome što se zapravo dogodilo. Ljudi brane svoje timove. Dobavljači brane svoja sučelja. Menadžeri brane odluke o pokretanju. Svatko postaje amaterski filozof uzročnosti. To je razumljivo i uglavnom beskorisno. Dobar zapis smanjuje potrebu za istinom vođenom osobnošću. Instituciji omogućuje raspravu o politikama i poboljšanjima umjesto rasprave o tome postoji li prošlost.
Dobri zapisi nisu kazalište nadzora
Postoji opravdani strah da mogućnost revizije postane nadzor. Neke organizacije čuju zabilježite sve i ponašaju se kao da svako ljudsko oklijevanje zaslužuje vremensku oznaku. To nije mogućnost revizije. To je institucionalna tjeskoba s pohranom. Dobar dizajn revizije selektivan je, proporcionalan i vezan uz značajne promjene. Bilježi ovlasti i stanje, ne privatnu buku.
Za zaposlenike ta razlika je važna. Operater koji odobrava iznimku trebao bi očekivati da će odobrenje biti zabilježeno. Ne bi trebao očekivati da svaki pokret pokazivača postane dio trajne moralne drame. Stručnjak koji nadjačava preporuku modela trebao bi ostaviti šifru razloga i napomenu kada odluka utječe na slučaj. Ne bi trebao biti kažnjen zbog neslaganja s automatizacijom koja je ionako bila nesigurna. Mogućnost revizije trebala bi učiniti profesionalnu prosudbu vidljivom, a ne učiniti profesionalce plašljivima.
Za građane, kupce, pacijente ili studente mogućnost revizije trebala bi podupirati prava. Trebala bi omogućiti objašnjenje odluke, ispravak loših podataka, osporavanje ishoda, dokaz brisanja ili prikaz da izvor nije korišten. Zapis koji štiti samo instituciju nepotpun je. Revizijski trag ne bi trebao biti jednosmjerno ogledalo. Ako sustav utječe na ljude, zapis bi trebao pomoći i u odgovoru na njihova legitimna pitanja.
Ovdje se susreću minimizacija podataka i mogućnost revizije. Odgovor nije čuvati sve zauvijek. Odgovor je čuvati prave činjenice u pravom razdoblju, s jasnom svrhom, pravilima pristupa i logikom brisanja ili zadržavanja. Rijedak, dobro strukturiran zapis često je i pun poštovanja i korisniji od goleme hrpe prikupljenog otpada. Hrpa daje osjećaj sigurnosti dok netko ne upita što je u njoj. Tada postaje odgovornost s pretragom.
Registar rizika trebao bi razgovarati sa shemom događaja
Registri rizika često žive u dokumentima upravljanja, dok sheme događaja žive u inženjerskim repozitorijima. Ta je odvojenost praktična i opasna. Registar rizika kaže da postoji rizik od neovlaštene eskalacije. Shema događaja stoga bi trebala bilježiti tko je eskalirao, pod kojom ovlasti, iz kojeg stanja, u koje stanje te je li eskalacija bila automatska ili ručna. Ako shema ne bilježi te činjenice, kontrola je tek aspiracija. Aspiracije su jeftinije od kontrola, što objašnjava njihovu popularnost.
Isto vrijedi i za rizik modela. Ako registar kaže da se preporuke s niskom pouzdanošću moraju pregledati, sustav bi trebao bilježiti pouzdanost, prag, zahtjev za pregledom, pregledavatelja, ishod i razlog za izdavanje ili odbijanje. Ako registar kaže da je opseg izvora važan, događaji bi trebali bilježiti opseg izvora. Ako je zadržavanje rizik, događaji bi trebali bilježiti promjene stanja zadržavanja. Registar rizika ne bi trebao biti proza koja lebdi iznad softvera. Trebao bi biti skup tvrdnji koje izvođenje može pomoći provjeriti.
To ne znači da svaki zahtjev upravljanja odmah postaje kod. Neke su kontrole ljudske, ugovorne ili organizacijske. No čak i ljudske kontrole trebaju dokaze. Ručni pregled i dalje može stvoriti zapis. Ugovorna obveza i dalje može biti povezana s potrebnom potvrdom. Proces dobavljača i dalje može biti predstavljen primljenim događajem, potpisanim izvješćem ili stanjem nedostajućeg dokaza. Poanta je povezati jezik rizika s jezikom dokaza prije nego sustav počne proizvoditi posljedice.
Nedvojbena je korist bolji razgovor. Inženjeri prestaju doživljavati upravljanje kao kasno ukoravanje. Timovi za upravljanje prestaju doživljavati inženjerstvo kao festival rubnih slučajeva. Oboje mogu pogledati istu shemu događaja i upitati nosi li činjenice potrebne za upravljanje rizikom. To je manje glamurozno od radionice o strategiji umjetne inteligencije. No također je manje vjerojatno da će proizvesti PDF koji nitko ne može operacionalizirati.
Revizijska sposobnost mijenja razgovor o izgradnji
Kada je revizijska sposobnost prisutna od početka, pregledi dizajna postaju konkretniji. Tim se ne pita samo funkcionira li značajka. Pita kakav zapis značajka ostavlja. Pita tko može pregledati zapis, koliko dugo živi, što se može ispraviti, što se nikada ne smije prepisati i na koje bi buduće pitanje trebao moći odgovoriti. Ta pitanja poboljšavaju značajku jer otkrivaju skriveno stanje i nejasnu ovlast.
Nabava se također mijenja. Umjesto da dobavljače pita podržavaju li zapise revizije, na što gotovo svatko može veselo odgovoriti potvrdno, organizacija može tražiti konkretne mogućnosti dokazivanja. Mogu li se verzije pravila izvesti uz svaku odluku. Mogu li se uključiti identifikatori modela i opsezi izvora. Mogu li se ljudska nadjačavanja razlikovati od automatiziranih radnji. Mogu li se zapisi čuvati, brisati, potpisivati ili reproducirati prema našim pravilima. Možemo li pregledati trag bez plaćanja herojske pustolovine profesionalnih usluga. Posljednja je stavka često ona gdje prostorija postaje poučna.
Operacije se također mijenjaju. Odgovor na incident postaje manje spekulativan. Tim može identificirati pogođene slučajeve, usporediti ih s poznatim verzijama pravila, pronaći nedostajuće zapise i pokazati put od signala do radnje. Rad na usklađenosti postaje manje sezonski. Poboljšanje proizvoda postaje iskrenije jer tim može vidjeti ne samo što je sustav učinio, već i pod kojim uvjetima je to učinio. Revizijska sposobnost nije kočnica isporuci. Ona je jedna od stvari koje sprječavaju da isporuka postane buduće iskapanje.
Ništa od ovoga ne čini sustav savršenim. Sustav koji se može revidirati i dalje može donositi loše odluke. I dalje može ugrađivati loše politike, koristiti slabe podatke ili njime upravljati ljudi koji imaju vrlo ljudski, običan utorak. Revidabilnost ne jamči mudrost. Jamči da institucija ima bolju priliku vidjeti što se dogodilo, učiti iz toga i dokazati da odgovor nije jednostavno izmišljen naknadno.
Pouka
Središnja je pogreška vjerovati da revidabilnost pripada na kraju jer se revizije događaju na kraju. One ne događaju. Revizije se događaju nakon posljedica, ali revidabilnost mora postojati prije posljedica. Zapis se mora roditi zajedno s radnjom. Događaj mora nositi svoj kontekst dok je kontekst još istinit. Sustav mora čuvati razliku između činjenice, zaključka, politike, nadjačavanja i ispravka.
Ovo nije poziv na teške procese oko svakog malog alata. To je poziv na proporcionalnost. Što više sustav mijenja prava, pristup, novac, sigurnost, podobnost, opterećenje ili institucionalno pamćenje, to više mora ostavljati strukturirane dokaze. Počnite s granicama koje imaju posljedice. Imenujte događaje. Verzionirajte pravila. Čuvajte vrijeme i identitet. Učinite ispravke aditivnima. Testirajte ponavljanje prije nego što strah uđe u prostoriju.
U toj disciplini ima nečega gotovo komičnog. Budućnost pouzdane automatizacije manje ovisi o spektakularnoj inteligenciji, a više o pamćenju koje je se pravilo aktiviralo jedne kišne srijede u veljači. Ali ozbiljne institucije izgrađene su na takvoj vrsti pamćenja. One ne vjeruju sustavima jer sustavi zvuče samouvjereno. One vjeruju sustavima jer se sustavi mogu nadzirati kada samouvjerenost više nije dovoljna.
Zato dodajte dokaze dok je posao još običan. Prije proslave lansiranja, prije incidenta, prije migracije, prije nego što tim zaboravi zašto je to polje bilo neobavezno. Kasnije će doći. Kasnije uvijek dođe, noseći mapu pod nazivom paket dokaza i pitanje koje zaslužuje bolji odgovor od vjerojatno.