Kodėl sprendimams reikia versijų istorijos
Apeliacija, atkeliavusi šešiais mėnesiais vėliau
Sprendimas atrodė eilinis, kai buvo priimtas. Prašymas dėl išmokų buvo atmestas antradienio rytą, peržiūrėtas atvejo vadybininko iki pietų ir išsiųstas piliečiui su mandagiu paaiškinimu, kuris vis dėlto nepaaiškino pakankamai. Sistema rodė galutinę būseną, datą, darbuotoją ir priežasties kodą. Tai atrodė administracinė procedūra, o taip dažnai slepiasi daug kas svarbaus. Po šešių mėnesių pilietis pateikė apeliaciją. Iki to laiko politika buvo keista du kartus, balų skaičiavimo modelis atnaujintas, pajamų duomenų srautas pataisė vieną lauką, o atvejo vadybininkas persikėlė į kitą komandą. Įrašas vis dar rodė atmesta. Organizacija nebežinojo, kuris atmetimas turimas omenyje.
Visi galėjo matyti rezultatą. Niekas negalėjo atkurti sprendimo. Duomenų bazėje buvo naujausia pareiškėjo profilio versija, o ne ta, kuri buvo naudota tuo metu. Taisyklių variklis turėjo dabartines taisykles, o ne senąją ribą. Modelių registre buvo nurodytas diegtas modelis, tačiau atsako į ankstesnes versijas istorija buvo neišsami. Paaiškinimo šablonas buvo redaguotas. Žmogaus peržiūros pastaboje buvo įrašyta patikrinta, o tai drąsus žodelis būsimam posėdžiui. Audito žurnalas rodė prieigos įvykius, bet nepakankamai konteksto, kad būtų galima suprasti, kodėl rezultatas toks. Apeliacija tapo susitikimu apie institucinę atmintį, o institucinę atmintį atstovavo trys žmonės, skaičiuoklė ir bendras nerimo jausmas.
Štai kodėl sprendimams reikia versijų istorijos. Sprendimas nėra tas pats, kas eilutė su būsena. Tai momentas, kai susitinka duomenys, politika, modelio elgsena, žmogaus sprendimas, darbo eigos būsena, teisės, įrodymai ir pasekmės. Jei šie komponentai nėra versijuojami, organizacija gali parodyti, kad kažkas įvyko, bet ne tai, kas įvyko atskaitomybės prasme. Žurnalai sako, kad durys atsidarė. Versijų istorija sako, koks kambarys buvo už durų, kuris raktas buvo priimtas, kas jį pasuko ir kodėl maršrutas buvo leistas.
Vien žurnalų nepakanka
Žurnalai yra būtini. Jie mums sako, kad įvykis įvyko, kada įvyko ir dažnai kuris veikėjas ar paslauga jį sukūrė. Geri žurnalai yra vertingi. Tačiau vien žurnalai nėra sprendimų istorija. Žurnalo eilutė, teigianti, kad taisyklė įvertinta kaip teisinga, yra silpna, jei taisyklės apibrėžimas pasikeitė. Žurnalas, įrašantis modelio balą 0,71, yra silpnas, jei trūksta modelio versijos, ribos, požymių ir kalibravimo. Žurnalas, įrašantis vartotojas patvirtino, yra silpnas, jei peržiūrėtojas matė kitokius įrodymus nei vėlesnis įrašas. Įvykiai be versijų yra pėdsakai šviežiame sniege po to, kai kažkas pertvarkė pastatą.
Sprendimų istorijai reikia ir įvykio, ir būsenos. Ji turi užfiksuoti arba nurodyti tuo metu svarbią būseną: duomenų momentinę kopiją, šaltinio naujumą, taisyklės versiją, modelio versiją, raginimo versiją, ribą, politikos pagrindą, prieigos teises, eilės būseną, peržiūrėtojo vaizdą, išvestį, pranešimą ir tolesnį veiksmą. Ne visada reikia kopijuoti visą privatų turinį. Nuorodos, maišos, momentinės kopijos ir saugojimo pakopos gali išlaikyti pėdsaką proporcingą. Tačiau sistema turi išsaugoti pakankamai, kad atsakytų į atskaitomybės klausimą: atsižvelgiant į tai, kas buvo žinoma ir leista tada, kodėl įvyko šis sprendimas.
Šis skirtumas svarbus, nes daugelis organizacijų jau turi žurnalus ir mano, kad problema išspręsta. Tada ateina ginčas, ir žurnalai nurodo į sistemas, kurios jau pasikeitė. Politikos įrašas buvo perrašytas. Požymis perskaičiuotas. Indeksas atkurtas. Raginimas redaguotas, nes kažkas pagerino formuluotę. Asmuo pataisė šaltinio duomenis, o tai gerai paslaugai ir baisu rekonstruojant praeitį, jei senoji reikšmė dingo. Dabartis nuolat tvarko kambarį, o praeitis nuolat praranda įrodymus.
Programinė įranga šią pamoką jau išmoko
Programinės įrangos komandos versijuoja kodą, nes niekas nenori aiškintis gamybinio incidento klausinėdamas, kas prisimena ketvirtadienį. Versijų kontrolė parodo, kas pasikeitė, kada, kas tai padarė ir dažnai kodėl. Ji leidžia komandoms palyginti, grąžinti, išsišakoti, peržiūrėti ir susieti pakeitimus su problemomis. Tai nepadarė programinės įrangos tobula. Tai padarė ją mažiau priklausomą nuo pokalbių koridoriuose. Tos pačios pagrindinės disciplinos dabar reikia sprendimams, ypač kai sprendimai priklauso nuo duomenų vamzdynų, taisyklių, dirbtinio intelekto modelių, žmonių darbo eigų ir tiekėjų, kurie keičiasi nepriklausomai.
Analogija naudinga, bet neišsami. Kodo versijavimas daugiausia susijęs su artefaktais, kuriuos kontroliuoja inžinerija. Sprendimų istorija turi aprėpti daugiau pokyčių rūšių. Pareiškėjo pajamų duomenis gali pataisyti išorinis šaltinis. Tinkamumo taisyklė gali pasikeisti įstatymu. Modelį gali atnaujinti platformos komanda. Pranešimą gali pakeisti operacijų skyrius. Vertintojas gali pridėti pastabą. Darbo eiga gali nukreipti atvejį kitaip eilės metu. Tiekėjas gali pakeisti API. Sprendimas yra daugelio versijuojamų pasaulių sankirtoje. Jam reikia istorijos, kuri išliktų, kai visi tie pasauliai tampa nepatogūs.
Ta istorija neturėtų būti milžiniška visko ekrano kopija. Ekrano kopijos ramina, nes atrodo kaip įrodymai, bet dažnai tai tik įrodymų formos tapetai. Sprendimų versijavimui reikia struktūrinių nuorodų: kuri įrašo versija, kuri politikos versija, kuris modelio leidimas, kuris požymių rinkinys, kuris pranešimas, kuris paaiškinimo šablonas, kuris vertintojo vaidmuo, kuris įrodymų rinkinys, kuris pranešimo tekstas. Žmonėms gali reikėti skaitomo vaizdo, bet mašinoms reikia stabilių identifikatorių. Kitaip kiekvienas apskundimas tampa literatūrine senų sąsajos pikselių interpretavimo pratyba.
Taisyklės keičiasi greičiau nei prisiminimai
Politika nėra statiška. Mokesčių ribos keičiasi. Tinkamumo kriterijai keičiasi. Saugos procedūros keičiasi. Klinikinės gairės keičiasi. Paskolų politika keičiasi. Mokyklos paramos taisyklės keičiasi. Sukčiavimo rodikliai keičiasi. Moderavimo standartai keičiasi. Net kai rašytinė taisyklė stabili, interpretacija kinta per gaires, mokymus, precedentus ir įprastą organizacijos atmosferą. Sprendimas, priimtas pagal vieną versiją, pagal kitą gali atrodyti klaidingas. Tai automatiškai nereiškia, kad jis buvo klaidingas tada. Tai reiškia, kad organizacijai reikia galimybės palyginti tada su dabar.
Bei versijų istorijos komandos daro dvi priešingas klaidas. Jos gina senus sprendimus remdamosi dabartinėmis taisyklėmis, o tai nesąžininga nukentėjusiam asmeniui ir paprastai gėdinga dėl detalių. Arba jos smerkia senus sprendimus pagal dabartines vertybes nesuprasdamos tuomet galiojusių apribojimų, o tai gali teikti emocinį pasitenkinimą, bet būti bevertiška praktiškai. Versijų istorija leidžia pamatyti skirtumą. Ji leidžia vertintojui paklausti, ar sprendimas atitiko tuo metu galiojusią taisyklę, ar ta taisyklė buvo teisėta ar tinkama, ir ar vėlesnis pakeitimas turėtų lemti koregavimą ar atšaukimą.
Tai ypač svarbu dirbant su dirbtiniu intelektu, nes politika gali būti išskaidyta po formalias taisykles, raginimus, modelių slenksčius, reitingavimo logiką ir žmogiškąsias gaires. Modelis gali neapimti politikos, bet gali nulemti, kurie atvejai matomi, kaip apibendrinami įrodymai ir kuri parinktis pateikiama pirmiausia. Raginimas gali užkoduoti atsisakymo taisyklę. Slenkstis gali faktiškai nuspręsti, kas gaus peržiūrą. Jei šios dalys nėra versijuojamos kartu, oficiali politika yra tik dalis sprendimo. Likusi dalis yra politika per konfigūraciją, o tai yra tylus būdas valdyti žmones to nepripažįstant.
Duomenų pokyčiai po sprendimo
Duomenys nėra nekintantis liudytojas. Jie taisomi, praturtinami, sujungiami, išvalomi nuo dublikatų, ištrinami, perklasifikuojami, perindeksuojami, o kartais tyliai perrašomi, nes migracijos scenarijus turėjo drąsią akimirką. Sprendimas, priimtas 09:15, naudojo tuo metu turimus duomenis, įskaitant klaidas, trūkstamas reikšmes, pasenusius srautus ir prieigos apribojimus. Jei įrašas vėliau tampa švaresnis, švaresnė versija negali paaiškinti ankstesnio rezultato. Sistemai reikia momentinės kopijos arba nekintamos nuorodos į duomenų būseną, kuri buvo svarbi.
Tai nereiškia, kad reikia amžinai saugoti kiekvieną asmens duomenų detalę. Tai būtų prastas atsakymas, apsirengęs atskaitomybės drabužiu. Sprendimų pėdsakas gali naudoti nuorodas į šaltinio versijas, maišas, užantspauduotas momentines kopijas, lauko lygio kopijas arba įrodymų rinkinius su saugojimo taisyklėmis. Dizainas priklauso nuo pasekmių ir srities. Mažos rizikos rekomendacijai gali pakakti lengvo atsekamumo. Išmokų atsisakymui, medicininei triažai, įdarbinimo sprendimui, drausminei priemonei, paskolos atsisakymui ar saugumo intervencijai reikia stipresnio pėdsako. Esmė yra proporcinga atmintis, o ne kaupimas.
Pataisyti duomenys taip pat kelia antrą klausimą. Ar reikėtų peržiūrėti senus sprendimus. Jei pajamų srautas buvo klaidingas, kurios paraiškos buvo paveiktos. Jei klinikinė taisyklė naudojo pasenusias laboratorijos reikšmes, kurie įspėjimai turėtų būti tikrinami iš naujo. Jei modelio požymis buvo apskaičiuotas iš neteisingo šaltinio, kurie reitingai pasikeitė. Versijų istorija leidžia atšaukti. Be jos organizacija gali žinoti, kad kažkas buvo negerai, bet nežinoti, ką tas negerumas palietė. Tai bloga vieta stovėti, ypač kai kambaryje yra auditorių.
Žmogiškajam sprendimui taip pat reikia istorijos
Egzistuoja guodžiantis mitas, kad žmogaus dalyvavimas išsprendžia versijavimo problemą. Taip nėra. Žmogiškasis sprendimas taip pat turi kontekstą. Peržiūrintysis mato konkretų ekraną, įrodymų rinkinį, eilės spaudimą, gaires, rizikos vėliavėlę, modelio santrauką ir galimų veiksmų rinkinį. Jei šie elementai vėliau pasikeičia, Jane patvirtinta pastaba mums pasako labai nedaug. Ką Jane matė. Kas buvo paslėpta. Ką ji galėjo keisti. Kiek laiko ji turėjo. Ar nesutarimas buvo įmanomas. Ar sąsaja vieną pasirinkimą padarė lengvesnį nei kitą. Žmogaus priežiūra be istorijos tampa parašu ant judančio dokumento.
Žmogiškosios peržiūros versijavimas nėra skirtas kaltinti peržiūrinčiuosius. Jis skirtas apsaugoti ir paveiktą asmenį, ir peržiūrintįjį. Iš atvejo vadybininko neturėtų būti reikalaujama po mėnesių ginti sprendimą iš atminties, kai sistema gali išsaugoti atitinkamą vaizdą. Gydytojas neturėtų turėti rekonstruoti, kuris įspėjimo slenkstis buvo aktyvus. Moderatorius neturėtų turėti aiškinti seno moderavimo veiksmo po to, kai politikos etiketė pasikeitė. Vadovas neturėtų turėti spręsti, ar pakeitimas buvo pagrįstas, nežinodamas tuo metu turimų įrodymų. Atmintis yra naudinga. Ji neturėtų būti audito duomenų bazė.
Istorija turėtų įrašyti peržiūros kontekstą, o ne kiekvieną privačią mintį. Ji gali užfiksuoti pateiktus įrodymus, praleistus įrodymus, priežasčių kodus, galimus veiksmus, pakeitimo pasirinkimą, laiko langą, eilės būseną ir eskalavimo kelią. Ji gali palaikyti naratyvines pastabas, kartu išlaikydama struktūruotus laukus analizei. Ji gali atskirti neskelbtiną turinį nuo patvarių nuorodų. Tikslas yra padaryti sprendimą patikrinamą nepaverčiant žmonių stebėjimo objektais. Ši pusiausvyra yra sudėtinga, todėl ji turi būti sukurta iš anksto, o ne improvizuota atėjus skundui.
Dirbtinis intelektas padidina užmaršties kainą
Dirbtinio intelekto padedami sprendimai padidina trūkstamos istorijos kainą, nes sistema gali keisti elgesį daugiau būdų. Modelio atnaujinimas gali pakeisti reitingavimą. Paieškos indekso perkūrimas gali pakeisti, kurie įrodymai atsiranda. Rašto pakeitimas gali pakeisti, kaip išreiškiamas neapibrėžtumas. Slenksčio koregavimas gali perkelti atvejus iš automatinio patvirtinimo į peržiūrą. Kalibravimo pakeitimas gali reikšti, kad tas pats balas reiškia ką nors kita. Saugos filtras gali blokuoti informaciją, kuri anksčiau buvo rodoma. Kiekvienas pakeitimas gali būti pagrįstas. Kartu jie daro praeitį trapią, nebent versijos yra susietos su sprendimais.
Paaiškinimai yra ypač pažeidžiami. Sugeneruotas paaiškinimas gali skambėti tiksliai, tačiau būti atsietas nuo tikrojo sprendimo kelio. Jei sistema vėliau sugeneruoja paaiškinimą pagal dabartines taisykles ir dabartinius duomenis, ji gali sukurti gražią klaidingą atmintį. Tai blogiau nei joks paaiškinimas, nes skatina pasitikėti rekonstrukcija. Sprendimų istorija turėtų atskirti tuo metu užfiksuotas priežastis nuo vėlesnės analizės. Vėlesnis paaiškinimas gali padėti vertintojui, tačiau jis turi būti pažymėtas kaip vėlesnis. Laikas svarbus. Tai skiria įrodymus nuo komentarų.
Modelio pasitikėjimo įverčiui taip pat reikia istorijos. Rezultatas 0,82 savaime nieko nepaaiškina. Kuris modelis jį pateikė. Pagal kokias požymių reikšmes. Pagal kokią kalibraciją. Su kokiu slenksčiu. Kokiai populiacijai. Ar modelis buvo naudojamas kaip patarimas, rūšiavimas, reitingavimas ar sprendimo įvestis. Ar jį matė žmogus. Ar buvo parodytas neapibrėžtumas. Ar modelis turėjo žinomų trūkumų šiam pogrupiui ar kalbai. Jei šios detalės išnyksta, organizacija išlaiko skaičių, bet praranda prasmę. Skaičiai be konteksto stebėtinai gerai apsimeta faktais.
Apeliacija yra dizaino reikalavimas
Sprendimas, kurio praktiškai negalima apskųsti, nėra tiesiog efektyvus. Jis yra trapus. Apeliacija ne visada reiškia teismą. Tai gali reikšti vartotojo pataisymą, vadovo peržiūrą, paciento klausimą, studento ginčijimąsi, kliento skundą, vidinį incidentą ar reguliuotojo atranką. Esmė ta, kad reikšmingi sprendimai turėtų tikėtis būsimos patikros. Dizainas, skirtas apeliacijai, keičia architektūrą. Sistema turi išsaugoti atitinkamas versijas, atverti jas įgaliotiems vertintojams, palaikyti pataisymus ir susieti ištaisymus su paveiktais vėlesniais veiksmais.
Tai nėra prieš automatizavimą. Tai sąlyga, kuriai esant automatizavimas išlieka teisėtas. Automatizuotos ir dirbtiniu intelektu paremtos sistemos gali užtikrinti apimtį, nuoseklumą ir greitį. Tačiau kai jos veikia žmones, jos taip pat turi palaikyti nesutikimą. Nesutikimui reikia pėdsako. Ne maksimalaus archyvo, ne kiekvieno baito amžinai, bet pakankamai istorijos, kad kas nors kitas, ne tik pirminė sistema, galėtų suprasti ir, jei reikia, pakeisti rezultatą. Priešingu atveju efektyvumas tampa užrakintomis durimis, prie kurių stovi mandagus pokalbio robotas.
Apeliacijos dizainas taip pat gerina įprastą veiklą. Jis padeda palaikymo tarnybai atsakyti į klausimus. Padeda vadovams pastebėti silpnas taisykles. Padeda inžinieriams atkurti incidentus. Padeda politikos komandoms matyti, ar gairės veikia. Padeda auditoriams atrinkti realius atvejus. Padeda organizacijoms ištaisyti sprendimų grupes, kai sugenda vienas komponentas. Sistema, sukurta apeliacijai, paprastai yra sistema, sukurta mokymuisi. Atvirkščiai negarantuojama. Daugelis greičiui sukurtų sistemų išmoksta tik greičiau pamiršti.
Atmintis be kaupimo
Prašyti sprendimų istorijos iš tikrųjų kelia riziką. Organizacijos gali sureaguoti saugodamos viską. Kiekvienas dokumentas, ekrano vaizdas, funkcija, raginimas, žurnalas, įrašas, el. laiškas, eilės elementas ir eksportas saugomas amžinai, nes atskaitomybė skamba svarbiai, o saugykla yra pigi, kol nėra. Tai nėra geras valdymas. Tai skaitmeninis atitikmuo gaisrinės saugos sprendimui, kai kiekvienas koridorius užpildomas dokumentų spintomis. Istorija turi būti proporcinga, struktūruota ir kryptinga.
Tinkama atmintis priklauso nuo pasekmių. Kai kuriems sprendimams reikia visiško atkūrimo: šaltinio momentinės kopijos, taisyklės versijos, modelio versijos, vertintojo rodinio ir pranešimo. Kitiems pakanka maišos kvito, kompaktiško įrodymų rinkinio arba apibendrinto audito tako. Dalis turinio turėtų nustoti galioti, o pats ištrynimo faktas išlikti. Kai kurie neskelbtini laukai turėtų būti nurodomi, bet nekopijuojami. Kai kurie įrodymai turėtų būti užantspauduoti apeliacijai ir neprieinami eiliniams darbuotojams. Kai kurie modelio artefaktai turėtų būti saugomi palyginimui, bet neviešinami plačiai. Versijų istorija nėra pasiteisinimas ignoruoti duomenų mažinimą. Tai vieta, kur duomenų mažinimas tampa tikslesnis.
Būtent todėl saugojimo politika ir sprendimų projektavimas turi eiti kartu. Sprendimo įraše turėtų būti nurodyta, ką reikia saugoti, kodėl, kiek laiko, kas gali juo naudotis, kaip jis padeda apeliacijai ir kaip vėliau jis sunaikinamas arba anonimizuojamas. Įrašas neturėtų būti pelkė. Tai turėtų būti kvitas su pakankamai priedų, įrodančių operaciją. Kvitali yra nuobodūs. Tai ir yra jų stiprybė. Niekas nenori filosofinio ginčo su kvitu, kai buhalteris klausia, kas atsitiko.
Kas pasikeičia, kai egzistuoja istorija
Kai sprendimai turi versijų istoriją, organizacija tampa ramesnė spaudimo akivaizdoje. Ji gali atsakyti į apeliaciją įrodymais. Ji gali atskirti blogą taisyklę nuo blogo taisyklės taikymo. Ji gali nustatyti, kuriems atvejams turėjo įtakos duomenų pataisa ar modelio atnaujinimas. Ji gali parodyti, ar žmogaus priežiūra buvo reali. Ji gali palyginti rezultatus pagal politikos versijas. Ji gali atsisakyti silpnų praktikų neapsimesdama, kad praeities niekada nebuvo. Ji gali tiksliau pripažinti klaidas, o tai yra neįvertinama, nes migloti atsiprašymai retai sutaiso sistemas.
Versijų istorija taip pat keičia vidinę elgseną. Žmonės priima geresnius sprendimus, kai žino, kad jie yra matomi. Politikos komandos rašo aiškesnius leidimų aprašus. Modelių komandos fiksuoja artefaktus. Operacijų komandos pagalvoja prieš redaguodamos šablonus. Produktų komandos aiškinamąjį tekstą laiko sprendimo dalimi, o ne tik komunikacijos puošmena. Vadovams mažiau kyla pagunda spręsti valdymo problemas prietaisų skydeliais, nes pėdsakas turi atlaikyti tikrą klausimą. Organizacija supranta, kad sprendimai nėra akimirka. Jie yra ilgaamžiai objektai, turintys gyvavimo ciklą.
Piliečiui, kuris pateikė pavėluotą apeliaciją, nereikėjo rašinio apie skaitmeninę transformaciją. Jam reikėjo žinoti, kodėl buvo priimtas sprendimas, ar jis priimtas pagal tinkamą taisyklę, ar duomenys buvo teisingi ir ką galima daryti dabar. Tai nėra išskirtinis reikalavimas. Tai pagrindinis orumas, kai esi pavaldus administracinei sistemai. Sprendimams reikia versijų istorijos, nes žmonės gyvena su sprendimais ir tada, kai sistemos pasikeičia. Jei organizacija negali prisiminti kelio, jai derėtų atsargiai teigti, kad tikslas buvo pagrįstas.