I kapittel 31 – Don´t Touch That Code, hevder forfatteren at utviklere ikke skal fikse feil i produksjon, og at dette bør forhindres ved at utviklere ikke gis tilgang til noe annet enn utviklingsmiljøet. Nærmere bestemt:

… a developer — even a senior developer — should never have access beyond the development server

og

Under no circumstances — ever, at all — should a developer have access to a production server.

Det er fornuftig at feilretting ikke bør skje direkte i produksjonsmiljøet. Selv har jeg imidlertid aldri opplevd dette, og har ikke intrykk av at dette utgjør et stort problem i de fleste utviklingsprosjekter. Derimot har man mange andre utfordringer, og en del av disse kan løses bedre nettopp ved å la utviklerne ha tilgang.

Feilanalyse

Ved daglig drift kan det oppstå feil eller andre hendelser som man har lyst til å se nærmere på. I slike tilfeller er det viktig å ha gode logger og at utviklerne har rask og enkel tilgang til disse. Dette er enklest å oppnå ved at utviklerne har direkte lesetilgang til loggene. Dersom man har en politikk som ikke tillater dette, ender man gjerne med lange og tidkrevende epostvekslinger mellom utviklings- og driftspersonell for å få tak i loggene det gjelder, noe som er tungvint og irriterende for alle parter – spesielt dersom det er snakk om kritiske feil der tidsfaktoren er viktig.

Monitorering

Loggene kan også benyttes til å gjenskape feilsituasjoner og/eller monitorere feilsituasjoner “live”, noe som kan være en svært effektiv og nyttig fremgangsmåte i gitte situasjoner. Slik oppfølging blir ofte enklere og mer fleksibelt dersom man har bygget applikasjonen slik at logginnstillinger og eventuelle andre parametre kan justeres mens applikasjonen kjører. Slik monitorering og justering er det utviklerne, som kjenner applikasjonen som sin egen bukselomme, som bør gjøre. Hvis utviklerne ikke har live tilgang til miljøet, nekter man seg i praksis et viktig verktøy ved feilsituasjoner.

Administrasjon og støtteverktøy

Ofte kan støttefunksjoner til en applikasjon være nyttige, enten det er operasjoner som er del av daglig drift eller ad-hoc-funksjoner som kan være nyttige ved spesielle situasjoner. Eksempler på dette kan være automatisk monitorering og varsling basert på logg-data eller interaksjon med applikasjonen som f.eks. invalidering av cache eller av-/påslåing av funksjoner på gitte tidspunkt. Mange slike støttefunksjoner kan utføres ved enkle kommandolinjescript. Igjen er det ofte utviklere som er best egnet til å lage slike støttefunksjoner, spesielt av ad-hoc-art, da det er de som best vet hvikle muligheter man har i applikasjonen.

Utrulling

Applikasjonsutrulling er også et område der utviklere kan spille en viktig rolle. Utviklere gjør gjerne utrulling på lokal maskin flere ganger daglig, og kjenner dermed denne fasen bedre enn noen. De er også ofte de som er best skikket til å forenkle, forbedre og automatisere denne prosessen.

Å arbeide for å forbedre kommunikasjon, samarbeid og forståelse mellom utviklings- og driftsorganisasjonene kan være veldig nyttig og givende i mange prosjekter. Nærhet og samarbeid mellom utvikling og drift kan ofte være av avgjørende betydning for smidighet både ved utrulling av applikasjoner og ved oppfølging og overvåkning av daglig drift. DevOps er et uttrykk som er mye i vinden om dagen, og som fokuserer på nettopp dette. Artikkelen DevOps: What It Is, Why It Exists and Why It’s Indispensable gir en fin introduksjon til DevOps.

Utviklere bør altså ikke gjøre bugfixer i form av kodeendringer, omkonfigurering av programvare eller denslags direkte i produksjon. Dersom dette er et problem, bør det kunne forhindres — for eksempel ved noe så enkelt som rettighetsinnstilling på brukerne. Det er naturligvis ikke slik at utviklerne fullstendig skal ta over produksjonsmiljøet, men man gjør seg selv en bjørnetjeneste dersom man ikke benytter seg av den applikasjonsspesifikke ekspertisen utviklerne bestitter — også ved kjøretid i produksjon.

Identifiser situasjoner hvor manuell verifikasjon gjøres i dag

Vi ønsker eksempelvis å vite om eksterne og interne avhengigheter er på plass, og at det ikke har oppstått åpenbare systemfeil når utvikler setter opp et utviklingsmiljø, ny kode distribueres til et test eller produksjonsmiljø, eller når forvalting kontaktes i forbindelse med systemfeil. Disse tre situasjonene forklares mer deltajert nedenfor.
Oppsett av utviklingsmiljø
Når utviklere setter opp hvert sitt utviklingsmiljø verifiseres det at oppsettet er i orden ved å:

• Kjøre enhetstester, integrasjonstester og akseptansetester
• Manuelt teste hovedfunksjoner i en eller flere applikasjoner/nettsider

Distribusjon av kode til test eller produksjonsmiljø
Når ny kode er distribuert til et miljø, gjør man vanligvis verifisering ved å:

• Manuelt teste hovedfunksjoner i en eller flere applikasjoner/nettsider
• Manuelt teste ny funksjonalitet

Forvaltning
Når det kommer henvendelser om systemfeil til brukerstøtte eller driftsansvarlige, gjøres ofte feilsøking ved å:

• Manuelt teste en eller flere funkjsoner i systemet
• Kontrollere systemloggen

Manuell verifikasjon i situasjonene beskrevet ovenfor er tidkrevende og kan være vanskelige å utføre.

Hvordan gjøre automatisk miljøverifikasjon?

I BEKK har vi god erfaring med å lage skript, nettside og/eller applikasjon som sjekker avhengigheter og funksjoner i et IT-system.

Skript

For å verifisere et miljø i forbindelse med oppsett eller installasjon kan det være bra å lage et skript som returnerer resultat fra verifiseringen uten å vise det visuelt. Skriptet startes helt til slutt etter bygg og deploy er utført. Dersom noe i miljøverifiseringsskriptet feiler, returneres en feilkode, og mer detaljert feilmelding logges. Skriptet bør lese konfigurasjonsfiler til tjenester og konfigurasjonsfil for eventuelle klienter som distribueres, etter distribusjon. Da får vi kontrollert at det ikke er feil i kode som bygger konfigurasjonen under distribusjon til de forskjellige miljøene.

Nettside

Skal man verifisere et kjørende miljø for en internett- eller intranettløsning er det bra å ha en side som kjører forskjellige tester i løsningen, og som viser resultatet visuelt. Adressen til siden gir man til interesserte som har behov for den, som: testteamet, systemadministrator, superbrukere, support og drift. Siden bør tilgangsstyres.

Applikasjon

Hvis systemet har distribuerte klienter anbefaler vi at det distribueres en egen applikasjon for diagnose, eller at det settes opp et menyvalg under hjelp-menyen som starter systemdiagnosen (dersom man har autorisasjon).

Det er essensielt at innstillinger og endepunkter leses fra klientens konfigurasjon. Diagnose-applikasjonen bør kjøre i samme brukerkontekst som den distribuerte klienten.

Hva kan/bør verifiseres på denne måten?

Egentlig er det ingen grenser for hva man kan verifisere på denne måten, men ikke gjør det for avansert. Da blir det vanskelig å vedlikeholde. Miljøverifikasjon skal ikke erstatte systemintegrasjonstester eller akseptansetester.

Verifisering av tjeneste-endepunkt til eksterne og interne tjenester, databasetilkoblingsstrenger og noen basis-operasjoner er tilstrekkelig, og svært nyttig etter vår erfaring.

Noen regler:

• Miljøverifikasjon bør gjøres så enkelt som mulig
• Miljøverifikasjon bør ikke ta lang tid å kjøre (<1 min)
• Vurder å benytte tråder (for å få raskere total responstid)

Start med å få på plass sjekk om én tjeneste svarer, for å komme i gang. Legg til mer etterhvert. Det kan være en god idé å inkludere løsning på kjente feilsituasjoner, slik at feilsøking går fortere.

Hva er dine erfaringer?

Hva er dine erfaringer med verifisering og feilsøking i forbindelse med oppsett og distribusjon av kildekode til ulike miljøer?

Standard informasjon

Standard logginformasjon inkluderer typisk tidspunkt, alvorlighetsgrad, program- og komponentnavn i tillegg til selve meldingen. Et godt loggrammeverk tilbyr tilpasning av både innhold og format av disse parametrene.

Riktig feilhåndtering forutsetter fornuftig kategorisering og identifisering av feilhendelse. Feilkategori og unik feil-ID er en viktig del av kontekstinformasjonen.

Brukernavn

Brukernavn for den innloggede brukeren kan med fordel logges. Enkelte applikasjonsservere tilbyr denne funksjonaliteten forutsatt at du benytter de innebygde mekanismene for autentisering og logging. En teknikk man kan benytte i egen kode er å ha brukernavnet på trådkonteksten (for eksempel  en ThreadLocal variabel i Java). Når en feil oppstår henter loggmekanismen brukernavnet fra trådkonteksten og skriver det til loggen. Mange sikkerhetsrammeverk bruker også denne teknikken, det kan derfor hende at brukernavnet allerede ligger klart for bruk.

Støtte for vilkårlig kontekstinformasjon

Når en feil oppstår er det gjerne nyttig å legge til spesifikk informasjon om tilstand og kontekst. Det kan også være behov for å supplere mer informasjon oppover i kall-stacken. Rammeverket bør derfor ha støtte for å legge til vilkårlig kontekstinformasjon, for eksempel som skissert under.

public class AbstractException() {
   ...
   public void leggTilFeilinformasjon(String navn, Object info) {
      feilinformasjon.add(navn, info);
   }
}

Selvbeskrivende objekter

Når man skal logge tilstand for de ulike objektene er det en stor fordel at disse kan beskrive seg selv. Det er feil ansvarsfordeling dersom en feilhåndteringsrutine må pakke ut og formattere kontekstinformasjonen som skal logges. En slik tilnærming vil også sannsynligvis føre til inkonsistens og duplisering.

Java-mekanismen for selvbeskrivende objekter er den velkjente toString()-metoden. Ved å implementere toString() på en god måte vil tilstand kunne logges enkelt og konsistent. I tillegg er det enkelt å lage automatiserte tester for denne funksjonaliteten, og disse kan også fungere som dokumentasjon. Komponenter som Apache ToStringBuilder kan være nyttig for implementasjon av toString().

Stacktrace og uventede feil

God feilhåndtering betyr få stacktrace i loggen. Ideelt sett oppstår behovet for stacktrace kun ved programmeringsfeil; gitt at applikasjonsfeil og systemfeil er riktig håndtert og har tilstrekkelig kontekstinformasjon. Imidlertid, når en uventet feil først oppstår er stacktracen en uvurderlig del av kontekstinformasjonen. Man kan med forlel skille ut disse i en egen logg for utviklere; drift ser ofte på stacktrace som et verdiløst irritasjonsmoment.

Oppsummering

God kontekstinformasjon er en sentral mekanisme for riktig feilhåndtering. Drift og utvikling kan med stor sannsynlighet forstå og gjenskape feilsituasjonen, og dermed også rette feilen raskt. Teknikkene for kontekstinformasjon er enkle å implementere, forutsatt at feilhåndtering er en prioritert og forstått del av prosjektet.

Brukeren

Brukeren av systemet er først og fremst opptatt av at en feil har oppstått, at situasjonen er håndtert og ikke medfører senere problemer. Det er selvfølgelig irriterende og kan være problematisk når feil inntreffer, uansett er det kritisk at situasjonen ser ut til å være under kontroll. Brukeren bryr seg sjelden om årsaken til feilen, men vil gjerne kunne identifisere den spesifikke situasjonen når hun snakker med supportapparatet.

Forretningssiden

Forretningssiden (funksjonelt ansvarlige i utviklingsprosessen) forstår primært funksjonelle feil, og antar ofte at utviklere og leverandører tar seg av andre feiltyper. De ønsker generelt en applikasjon uten kritiske feil, men vil sjelden sørge for at feilhåndtering blir riktig prioritert i utviklingsprosessen.

Kunde/Bestiller

Den som sitter på budsjettet og bestiller applikasjonen har forventninger om en fungerende applikasjon, men har vent seg til at ingen applikasjoner er feilfrie. De er vanligvis ikke tilstrekkelig involvert i prosjektet til å påvirke og vektlegge feilhåndtering. Noen stiller imidlertid med testledere som kan være erfarne nok til å ivareta dette ansvaret og sørge for at unntaks- og feilsituasjoner blir testet.

Drift

Drift vil vite hva de skal gjøre når feil oppstår. På kort sikt er drift kun interessert i å gjøre grep slik at systemet kjører videre og ikke har havnet i en ugyldig tilstand. Selv om årsaken til feilen kan være interessant vil driftpersoner sjelden ha behov for detaljerte beskrivelser. Imidlertid vil de gjerne ha en oversikt over potensielle og kjente feilsituasjoner, kunne gjenkjenne feilkategoriene og kanskje bygge opp en erfaringsbase over tid.

Utviklere

Utviklere vil vite alt:

• Hva var årsaken til feilen?
• På hvilken server skjedde den?
• Når oppsto situasjonen?
• Hvilken tilstand hadde brukeren og applikasjonen?
• Hva var kontekst i feilsituasjonen?
• Kan den gjenskapes?

Ettersom utviklere ofte står for feilhåndteringen vil utviklerbehovene prege implementasjonen. Dette resulterer gjerne i detaljerte feilmeldinger i alle sammenhenger; i brukergrensesnittet, loggfiler og konsoller.

Tilpasning til brukernes behov

For bedre feilhåndtering må man i større grad skille mellom ulike brukergrupper og deres behov. Her er noen mulige tilnærminger:

• Utviklingsprosjektet må ta hovedansvaret for feilhåndteringen. All erfaring tilsier at man ikke kan forvente at forretningssiden eller bestiller vil sørge for at behovene beskrives og prioriteres. Dersom kunden ikke har en erfaren testleder bør prosjektene selv bekle denne rollen.
• Unngå detaljerte feilbeskrivelser i brukergrensesnittet, men oppgi gjerne en unik feil-ID slik at det er mulig å finne tilbake til den spesifikke feilen.
• Involver drift i hele utviklingsprosjektet slik at de kan bidra til kravstilling og kommunisere sine behov på lik linje med funksjonelle krav.
• Sørg for konsistent feilkategorisering som drift kan bruke for å kjenne igjen feil.
• Bruk gjerne forskjellige logger for drift og feilretting. Drift har i utgangspunktet ikke behov for de detaljerte feilbeskrivelsene som man har i forvaltning.
• Sørg for å legge til kontekstinformasjon i feilsituasjoner.

Når man feilsøker kan man skille mellom to ulike behov:

• Feilkategori beskriver hvilken feil som har oppstått. Den kategoriserer hendelser av samme type, og brukes for å forstå hva som har skjedd.
• Identifisering av feilhendelsen forteller hva som har skjedd til en bestemt tid i en spesifikk sammenheng. Typisk er dette nyttig for å finne ut hva som har skjedd når man feilsøker en bestemt feilsituasjon meldt av en bruker.

Feilkategorisering

Feilkategorisering har flere alternative tilnærminger:

• Hver feilkategori representeres med en egen Exception. Java SE APIet er et eksempel på denne tilnærmingen. Dette resulterer typisk i mange Exception-klasser  definert på ulike steder i pakkestrukturen. Tilnærmingen kan derfor kalles distribuert.
• Et fåtall sentrale Exception-klasser definerer feiltypene (gjerne Applikasjonsfeil, Systemfeil og Programmeringsfeil). For hver feiltype defineres en ID som feiltypen bærer med seg (typisk en Enum spesifisert i constructor). Denne tilnærmingen kan ses på som sentralisert.
• Kombinasjoner av disse, for eksempel et fåtall sentrale Exception-klasser med distribuerte subklasser.

Sentralisert feilhierarki

Uavhengig av tilnærming er hensikten å gjenkjenne feilen og forstå hvorfor den oppstår. En driftsperson vil kanskje lage en erfaringsbase for kjente feilkategorier. En utvikler som skal feilrette har også god nytte av god feilkategorisering for å finne årsaken.

Min erfaring er at applikasjoner lykkes best med en sentralisert tilnærming, der man definerer feilkategoriene som en felles Enum. Rammeverk (f.eks. Java SE API og Spring Framework) velger gjerne en distribuert tilnærming; ettersom dette ikke er applikasjoner har man ikke det samme behovet for sentral oversikt over feilkategoriene.

Enum Kategori { INGEN_PENGER, FEIL_ROLLE, UTESTENGT };
...
 
public class AbstractException() {
   public AbstractException(Kategori kategori, ...) {
      ...
   }
}

Kategorisereing av feil ved hjelp av Enum

Identifisering av feilhendelse

For å finne ut av en spesifikk feil ønsker man å identifisere den unike hendelsen som forårsaket feilen. Typisk er dette en situasjon der en bruker melder en feil eller når man feilsøker en hendelse som andre har rapportert tidligere. Å kunne identifisere denne ene feilen i en stor loggfil er gull verdt. Dette krever at hver enkelt feil blir logget med en unik ID.

En teknikk som fungerer bra nok i de fleste sammenhenger er å bruke tidspunktet feilen oppstår (i millisekunder) som ID. Denne IDen vises i feilsammenheng og skrives samtidig til feilloggen. Sannsynligheten for at to eller flere feil oppstår i samme millisekund er tilstede, men denne teknikken vil uansett begrense utvalget til et minimum. Funksjonaliteten for å lagre IDen implementeres i Exception-superklassen.

public class AbstractException() {
   private final long uid;
   public AbstractException(...) {
      uid = System.currentTimeMillis(); // skrives til loggen
   }
}

Eksempel på identifisering av Exception-instans med timestamp.

Oppsummering

God feilhåndtering forutsetter riktig kategorisering av feil i tillegg til støtte for å identifisere hver enkelt feilhendelse. Som alltid krever dette at man har et bevisst og målrettet forhold til feilhåndtering gjennom hele prosjektløpet. Det er fullt mulig å unngå at feilkategorisering og idendifisering av feilhendelse blir klattet på mot slutten av et prosjekt; å involvere driftpersoner som kravstillere på lik linje med annen funksjonalitet er en god start. God kontekstinformasjon i en feilsituasjon er også viktig, dette blir et eget tema i denne serien.

• Applikasjonsfeil
• Systemfeil
• Programmeringsfeil

Applikasjonsfeil skyldes at funksjonelle forutsetninger ikke er tilfredsstilt. I praksis er dette gjerne ugyldig eller feilformatert input som for kort fødselsnummer, e-postadresse uten @, dobbeltføring av betaling eller en kunde som har utilstrekkelig bonusnivå for å utføre en handling. Applikasjonsfeil kan sies å være forventet og skal håndteres på lik linje med andre krav. Det kan være krevende å forutse alle slike feilsituasjoner. Erfaringsmessig har forretningsfolk god oversikt over de vanligste funksjonelle problemene, mens teknikere er flinke til å tenke på grenseverdier og inkonsistens. En iterativ tilnærming med teknikker som test-drevet utvikling, brukerhistorier og BDD vil avsløre de fleste applikasjonsfeilene. I utgangspunktet skal det ikke være nødvendig å feilrette og rulle ut en ny versjon av applikasjonen for denne typen feil. For å håndtere applikasjonsfeilene som allikevel slipper ut i produksjon er det viktig med hyppig utrulling slik at man kan fange opp disse etterhvert som man får praktisk erfaring med systemet.

Systemfeil skyldes feil i applikasjonens omgivelser eller infrastruktur. Typisk er dette en disk som går full, et nettverk som blir utilgjengelig eller en server blir overbelastet. Slike feil er også til en viss grad forventet; de opptrer sjelden, kan være vanskelig å forutse, men i praksis er det gjerne rimelig enkelt å teste slike feilsituasjoner. Ved systemfeil kan det gi mening å kjøre fail-over om mulig, alternativt vente en stund for deretter å prøve operasjonen på nytt; denne type feilhåndtering tilbys gjerne av meldingssystemer. Feilretting og ny utrulling skal ikke være nødvendig for denne feiltypen.

Programmeringsfeil skyldes at utviklere ikke har gjort jobben sin. De oppstår når applikasjonen ikke klarer å håndtere uventede hendelser på på robust vis. Typiske eksempler på dette (i en Java-applikasjon) er når systemet spyr ut feil av typen NullPointerException, NoSuchElementException og IndexOutOfBoundsException. Godt håndtverk med teknikker som TDD og automatisert testing, parprogrammering og kodegjennomgang er effektive tilnærminger for å minimere denne typen feil. Når en programmeringsfeil oppstår krever det en feilretting og påfølgende utrulling av ny versjon.

Tabellen under gir en oversikt over feiltypene og om de bør fanges og håndteres i applikasjonen, om det er mulig å vente litt og prøve operasjonen på nytt samt om den krever feilretting og utrulling av ny versjon:

Dårlig feilhåndtering er dessverre alt for utbredt i vår industri. Antall stacktrace i loggen er en indikator på hvilken kvalitet applikasjonen har; applikasjonsfeil og systemfeil skal være håndtert mens programmeringsfeil skal være luket ut i utviklingsprosessen. Et bevisst forhold til feiltyper og hvordan de bør håndteres er et godt utgangspunkt for å lykkes på dette området. Riktig feilhåndtering krever imidlertid målrettet innsats gjennom hele utviklingsløpet.