Faste kjøringer, drift og overvåkning

Portalen passer ikke seg selv, men den gjør det meste av arbeidet uten at noen ber om det. 35 jobber holder den i gang. 24 av dem går etter en fast plan, og resten startes av en hendelse, av en annen jobb eller for hånd. 4 av jobbene håndterer interne verktøy og er ikke listet her.

Oversikten under er ikke skrevet inn. Den leses ut av jobbene selv hver gang tallgrunnlaget oppdateres, og en ny jobb som mangler en beskrivelse stopper oppdateringen framfor å bli utelatt i stillhet. Det er hele grunnen til at siden finnes: en liste noen må huske å vedlikeholde, blir feil.

Oversikten dekker jobbene som kjører i kodelagerets egen jobbkjører. Noen faste kjøringer ligger andre steder og står ikke her: datamodellene bygges hver natt av en egen tjeneste for dem, to ukentlige innhentinger kjører inne i datalageret, oppgavene som bygges om natta startes av en planlagt økt hos språkmodell-leverandøren, og kunnskapskartet publiseres av sin egen vertstjeneste ved hver endring. Innstillingene for flere av dem ligger utenfor kodelageret, og det er nettopp der vokterne lenger ned har måttet fylle hull.

Jobbene faller i fem grupper. Rekkefølgen leser som en dag i portalens liv: data inn, innhold ut, kontroll av at det stemmer, dokumentasjon av det som er gjort, og drift av det hele.

Klokkeslettene er norsk vintertid. Om sommeren går jobbene én time senere enn oppgitt - kadensen er poenget, ikke minuttet.

Automatikk dekker det som kan hentes maskinelt. Noe kan ikke det, og det er ærligere å si det enn å late som om alt går av seg selv.

• 101 datasett

  Rapporter og oversikter som bare finnes som tekst eller tabeller ment for lesing. De må hentes, leses og skrives inn. Foreldelsesvakten sier fra når de blir gamle, men den kan ikke oppdatere dem.

• Lenkekontroll

  Eksterne adresser råtner. Dyplenker til rapporter og tabeller kontrolleres periodisk, og brutte lenker byttes ut. Ingen jobb kan avgjøre om en ny adresse peker på det samme dokumentet.

• Publisering av artikler

  Et menneske leser og velger hva som skal ut. Se kapitlet om publiseringskjeden.

• Å sette i gang artikkelskrivingen

  Utkastene skrives bare når noen starter skrivejobben. Oppdragene legges igjen automatisk, men uten det ene trykket blir de liggende.

• Å få endringer i datalageret ut i drift

  Notatbøkene som kjører inne i datalageret, kommer først i drift når noen legger dem ut dit. Ingen jobb gjør det automatisk, og flere innstillinger for jobbene der ligger utenfor kodelageret, der ingenting merker om de endres. Datamodellene er unntaket: de bygges fra kodelageret av sin egen tjeneste.

• Vurdering av nye kilder

  Om en tabell faktisk måler det den ser ut til å måle, er et faglig spørsmål. Feil valg her gir tall som ser riktige ut og er feil.

Med 24 jobber på fast plan er spørsmålet ikke om noe feiler, men når. Det som betyr noe, er at feilen blir oppdaget.

Til sammen finnes 218 automatiske testfiler. Flere av dem er der utelukkende for å hindre at en bestemt feil kan gjøres om igjen - de vokter en regel framfor å teste en beregning.

Når en maskin både henter tallene og formulerer setningene om dem, flytter spørsmålet seg. Det er ikke lenger «er koden riktig», men «ville vi merket det hvis den stille begynte å ta feil». En vokter er en test som finnes for å gjøre én bestemt feil umulig å gjenta. Den kjører ved hver endring, og i tillegg hver morgen etter den daglige datajobben, fordi de automatiske jobbene endrer data uten at noen åpner en endring.

Prosaen som beskriver tallene, skal ikke skrives fritt. Tallene regnes ut først, og språkmodellen får dem servert med en instruks om ikke å oppgi noe tall som ikke står der. Det er en instruks, ikke en kontroll: ingen vokter sammenligner i dag tallene i en ferdig tekst med tallene språkmodellen fikk. Det som fanges automatisk, er en tekst uten tall, og en tekst der språkmodellen selv skriver at tallene mangler.

Noe av dette er ferskt, og det er verdt å si høyt. Vokteren over det kuraterte datasettet ble skrevet samme dag som feilen den beskriver ble funnet, og den viste sin egen blindsone i løpet av timer: den sjekker at datasettet er komplett, men den kan ikke oppdage at datahentingen har sluttet å kjøre. Feiler jobben, blir rådataene rett og slett ikke overskrevet. Alt ser riktig ut, fordi alt er som sist. Det er samme stille form som feilen den ble laget for, bare med en annen utløser. Den blindsonen er nå tettet fra to kanter: en jobb-vakt spør datalageret hver morgen om jobbene faktisk har kjørt og lyktes, og melder en jobb som feilet, som ikke har lyktes på over åtte dager, eller som aldri har kjørt, som en egen sak. Foreldelsesvakten sjekker i tillegg at selve hentingene har hatt en vellykket kjøring nylig. Det som fortsatt ikke varsler, er ferskhetsmålingen i verktøyet som bygger datamodellene: den står som en innstilling på et skjermbilde, og et resultat der stopper ingenting, uansett om det er gult eller rødt.

Den vanskeligste lærdommen er likevel en annen: en vokter er verdt nøyaktig så mye som reaksjonen på den. En kontroll som melder fra et sted ingen ser, er pynt. Nettopp det skjedde her: kontrollen meldte «alt i orden» mens et datasett i nesten tre måneder manglet halvparten av tabellene sine, fordi den leste oppskriften og ikke resultatet. Vokterne er derfor flyttet dit de stopper arbeidet, framfor dit de kan overses.

Den vanligste feilen i en statistikkportal er ikke et galt tall. Det er et riktig tall som har blitt gammelt uten at noen sa fra.

Hvert datasett har derfor en forventet takt og en tålegrense. Passeres grensen, åpner en daglig vakt en sak for datafilen. For noen av de manuelt vedlikeholdte datasettene dukker det i tillegg opp et synlig varsel på siden selv, og det blir strengere når grensen er passert med god margin. Det er ubehagelig, og det er meningen: et ubehagelig varsel blir rettet. Datasettene som hentes automatisk, har ikke et slikt varsel. Der blir en feilet henting en sak, og datoen står ved hver graf.

67 datafiler følges på denne måten. Du kan se status for hver enkelt på oppdateringsloggen, og hele endringshistorikken på oppdateringssiden.

Et tall blir gammelt fordi kilden har publisert noe nyere. En tekst blir gammel av en annen grunn: verden har flyttet seg forbi det den påstår. De to krever hver sin sjekk, og bare den første kan avgjøres ved å se på en dato.

En egen gjennomgang leter derfor etter seks ting i sider, artikler og datasett.

Data som har passert tålegrensen, blir en sak per datafil, hver dag. Løfter uten side og temaer som holder seg i nyhetene eller følger hverandre, blir til noen få forslag i uka, lagt fram som en endring et menneske må godta. Alle funnene, også gamle artikler og tekster som lover et nyere år, går i tillegg daglig inn i idébanken som mulige ideer. Utover saken om gamle data blir ingen av dem en sak av seg selv.

Og så det som er selve poenget: gjennomgangen retter ingenting. Den kan finne at en artikkel viser til et år som har passert, men ikke avgjøre om svaret er å oppdatere teksten, endre datoen eller arkivere hele saken. Deteksjonen er automatisk, avgjørelsen er ikke.

Det er samme grense som køen for automatiske kjøringer har, satt to steder av samme grunn: en liste som fyller seg selv med arbeid, er ikke lenger en liste noen eier.