Hvorfor oppetid ikke lenger er nok
Vi har alle hørt det før: systemet må være oppe 99,9 % av tiden. Det er et hellig mål i IT-verdenen. Men la meg stille deg et ulempe-spørsmål: Hva skjer når koden din er så skitten at ingen tør å røre den? Du kan ha perfekt oppetid i dag, men hvis det tar en uke å fikse en liten feil eller legge til en ny funksjon, har du egentlig et problem som ingen dashboard viser.
Dette er kjernen i vedlikeholdbarhet, som er evnen til å endre, oppdatere og vedlikeføre et system effektivt over tid. I mange år ignorerte vi dette. Vi fokuserte på om lyset var på (oppetid) eller om siden lastet raskt (latens). Men nå snur vinden. Organisasjoner innser at pålitelighet handler like mye om fremtidige endringer som om nåværende ytelse.
Service Level Objectives (SLOs) for vedlikeholdbarhet er målsettinger som kvantifiserer hvor enkelt et system kan modifiseres og opprettholdes. Dette er ikke bare teoretisk snakk. Det er en praktisk måte å måle "kvaliteten" på utviklingsprosessen din. Hvis du ikke måler det, kan du ikke forbedre det. Og uten disse målene risikerer du at teknisk gjeld spiser opp budsjettet ditt og bremser veksten.
Hva skal du faktisk måle?
Når vi snakker om tradisjonelle SLOs, tenker vi på ting som responstid eller feilkoder. For vedlikeholdbarhet må vi se på andre tall. Google sitt Site Reliability Engineering (SRE)-team la grunnlaget for dette i sin bok fra 2016, men det tok tid før bransjen begynte å bruke det aktivt på kodekvalitet. I dag vet vi hvilke indikatorer som faktisk betyr noe.
Her er de fire mest kritiske metrikene du bør vurdere:
- Gjennomsnittlig tid til gjenoppretting (MTTR): Hvor lang tid tar det fra en feil oppstår til systemet er stabilt igjen? Et vanlig mål for gode team er under én time. Dette måler ikke bare hurtigheten på fiksen, men også hvor godt dokumentert og forstått systemet er.
- Lead time for funksjoner: Hvor lang tid går det fra ideen om en funksjon til den er live hos kundene? DORA-rapporten fra 2023 viser at elitedrivere leverer flere ganger per dag. Hvis det tar deg to uker, er prosessen din trolig blokkert av dårlig strukturert kode.
- Syklus-tid for pull requests (PR): Fra øyeblikket en utvikler åpner en forespørsel om sammenslåing til den godkjennes og kjøres. Målet bør være under 24 timer. Lang ventetid her indikerer enten manglende kapasitet til code review eller at koden er for kompleks å gjennomgå.
- Teknisk gjeld-ratio: Andelen av arbeidet som går med å betale av gammel gjeld versus å bygge nye ting. En regel tommelfinger er at dette bør holde seg under 5 %. Overstiger du dette, mister du fart.
Merk at disse tallene skiller seg fra oppetid. Oppetid er binær (det virker eller det gjør det ikke). Vedlikeholdbarhet er en kontinuerlig skala. Det er lettere å bli "godt nok" på oppetid, men det krever konstant disiplin å holde vedlikeholdbarheten høy.
| Egenskap | Tradisjonell SLO (f.eks. Oppetid) | Vedlikeholds-SLO |
|---|---|---|
| Hovedfokus | Kundens opplevelse nå | Utviklerens effektivitet fremover |
| Typisk mål | 99,9 % oppetid | < 1 time MTTR |
| Målevindu | 28 dager eller kvartal | 7-14 dager (kortere feedback-syklus) |
| Datakilder | Monitoring-verktøy (f.eks. Datadog, CloudWatch) | CI/CD-pipelines, Git, Incident Management |
| Standardisering | Høy (bransjestandarder eksisterer) | Lav (krever tilpasning til organisasjon) |
Bruken av kortere målevinduer (7-14 dager) er avgjørende. I utvikling skjer ting fort. Hvis du venter på månedlig rapportering for å se at PR-syklusen din har blitt langsom, har du allerede mistet momentum. AWS CloudWatch sin veiledning fra 2024 understreker at integrering av disse metrikker i applikasjonssignaler gir bedre oversikt enn å behandle dem isolert.
Feilbudsjett: Når er "nok" nok?
Her kommer det vanskelige spørsmålet: Hvor streng skal du være? Med oppetid er svaret ofte klart: 99,9 % er standarden for mange tjenester. For vedlikeholdbarhet finnes det ingen universell sannhet. Det som fungerer for en startup med fem utviklere, vil knuse et enterprise-team på 500 personer.
Dette er der konseptet feilbudsjett blir den tillatte mengden med "feil" eller ineffektivitet innenfor en periode. Tenk slik: Hvis målet ditt er at 95 % av deployementene ikke krever hotfix, har du et feilbudsjett på 5 %. Så lenge du holder deg innenfor 5 %, er alt greit. Du trenger ikke panikk. Du trenger bare å tracke det.
En stor utfordring er at mange team velger "vanity metrics" - tall som ser fine ut men ikke betyr noe. Sarah Chen fra AWS advarte i 2023 mot å måle "linjer med kode endret". Det sier ingenting om kvalitet. I stedet bør du måle "prosentandel endringer som ikke krever etterfølgende fikser". Det er en direkte indikator på stabilitet og forståelse av koden.
Calibrering av dette budsjettet krever historisk data. Ett team jeg rådgav brukte seks måneder med data for å finne ut at deres naturlige feilrate var 12 %. De satte derfor et ambisiøst, men realistisk mål på 15 % for første kvartal. Å sette målet for lavt fra start (f.eks. 1 %) fører til frustrasjon og gaming av systemet. Utviklere begynner å skjule feil eller unngå komplekse oppgaver for å beskytte tallene.
Varsler: Hvordan unngå alarmtrøtthet
Du har satt målene. Nå må du vite når du bryter dem. Men her ligger fella: Hvis du sender en Slack-varsel hver gang noen bruker 10 minutter ekstra på en code review, vil teamet ditt slutte å lese meldingene. Dette kalles alarmtrøtthet, og det er døden for ethvert SLO-program.
Løsningen er burn rate alerts, som er varslingsmekanismer basert på hastigheten man forbruker feilbudsjettet. Splunk sin implementasjonsveiledning fra 2024 anbefaler et fler-vindus-tilnærming:
- Kort sikt (6 timer): Varsel hvis du forbrenner budsjettet fortere enn forventet i en veldig kort periode. Dette håndterer akutte kriser, som en feilaktig release som ødelegger CI/CD-pipelinen.
- Lang sikt (72 timer): Varsel hvis trenden over tre dager viser at du vil overskride budsjettet før slutten av målepериоден. Dette håndterer gradvis nedgang i kvalitet, som økende teknisk gjeld.
Det viktigste rådet jeg kan gi er å varsle på symptomer, ikke årsaker. Ikke send en varsel fordi "cyclomatic complexity" er høy i en fil. Send en varsel fordi "frekvensen av rollbacker" har økt. Rollback er et symptom på at noe gikk galt i produksjonen. Høy kompleksitet er bare en teori om hvorfor. Symptom-baserte varsler er handlingsorienterte. Årsak-baserte varsler fører ofte til diskusjoner om hva som egentlig er feil.
En annen taktikk er "cooldown periods". Hvis dere planlegger en stor migrering, forventer dere at vedlikeholdbarhetsmetrikkene vil synke midlertidig. Sett inn en pause på 24-72 timer i varslingssystemet under slike perioder. Dette reduserer støy og lar teamet fokusere på jobben uten å føle at de hele tiden bryter reglene.
Feller du bør unngå
Det er lett å gjøre dette feil. Jeg har sett team straffe seg selv med disse tiltakene. Her er de vanligste feilene:
Optimalisering av syklustid på bekostning av kvalitet. Et SaaS-selskap jeg kjenner innførte et strengt mål på 24 timers PR-syklus. Resultatet? Utviklere presset gjennom dårlig kode for å treffe målet. Antall hendelser i produksjonen steg med 22 %. De målte riktig ting, men ignorerde konteksten. Løsningen var å kople syklustid til en kvalitetsgate: Rask levering er fint, men bare hvis feilraten ikke stiger.
Mangel på alignment mellom business og engineering. Produktledere vil ha funksjoner raskt. Utviklere vil ha ren kode. Hvis SLOene dine kun reflekterer utviklerens komfort, kan du gå glipp av leveringsdatoer. En produktmanager klager ofte: "Vi traff alle SLOene, men kundene er misfornøyde fordi funksjonen var halvferdig." Sørg for at vedlikeholds-SLOene støtter forretningsmål, ikke konkurrerer med dem.
For mange metrikker fra start. AWS anbefaler å starte med maks tre SLIs (Service Level Indicators). Velg de som gir mest smerte. Er det langsomme releases? Start med Lead Time. Er det ustabile releases? Start med Change Failure Rate. Å måle alt samtidig sprer ressursene for tynn. Du får data, men ingen innsikt.
Veien fremover: Integrering og standardisering
Bransjen beveger seg raskt mot mer integrerte løsninger. Tidligere måtte du lime sammen data fra Jira, GitHub, PagerDuty og Prometheus manuelt. I dag tilbyr plattformer som Nobl9 og Blameless dedikerte dashbord for dette. Gartner rapporterte i 2024 at 58 % av store bedrifter nå inkluderer vedlikeholds-metrikker i sine SLO-rammeverk, opp fra 29 % i 2022.
Trenden er tydelig: Vedlikeholdbarhet er ikke lenger en "nice-to-have" for tech-gurunene. Det er en forretningskritisk nøkkel. DORA State of DevOps Report 2023 viste at organisasjoner som tracker disse SLOene er 2,3 ganger sannsynlig å bli klassifisert som "elite performers". Det er ikke tilfeldig. Når du kan levere endringer raskt og trygt, kan du reagere på markedet raskere. Konkurrentene dine sitter fast i sin egen tekniske gjeld.
For fremtiden ser vi også en sterk kobling mellom tekniske metrikker og kundetilfredshet. AWS lanserte nylig muligheten til å korrelere deployments-frekvens med kunde-NPS. Dette beviser poenget Charity Majors gjorde i 2024: Vedlikeholds-SLOer er det manglende ledd mellom engineering-hastighet og system-stabilitet. Uten dem optimaliserer du for i dagens oppetid på bekostning av morgendagens stabilitet.
Start smått. Velg én metrik. Definer et realistisk feilbudsjett basert på historisk data. Sett opp burn-rate varsler. Og viktigst: Bruk dataene til å forbedre prosessen, ikke til å straffe folk. Vedlikeholdbarhet er et lagspill.
Hva er forskjellen mellom en SLO og en SLI for vedlikeholdbarhet?
En SLI (Service Level Indicator) er selve målingen, for eksempel "gjennomsnittlig tid det tar å merge en pull request". En SLO (Service Level Objective) er målet du setter for denne målingen, for eksempel "90 % av pull requests skal merges innen 24 timer". SLI er dataen, SLO er kontrakten.
Hvor ofte bør jeg revidere mine vedlikeholds-SLOer?
Du bør revurdere dem minst kvartalsvis, men justere målevinduet ukentlig eller annenhver uke. Vedlikeholdbarhet endrer seg raskere enn oppetid. Hvis teamet ditt konsekvent treffer målene dine med margin, er målene for lette. Hvis de aldri treffes, er de urealistiske. Juster basert på trendene, ikke bare punktet i tid.
Kan jeg bruke de samme verktøyene for vedlikeholds-SLOer som for oppetid?
Ofte ja, men integrasjonen er annerledes. Tradisjonelle monitoring-verktøy som Datadog eller New Relic er bra for oppetid. For vedlikeholdbarhet trenger du data fra CI/CD-verktøy (som Jenkins, GitLab CI) og versjonskontroll (GitHub, GitLab). Dedikerte SLO-plattformer som Nobl9 eller Blameless hjelper med å aggregere disse kildene i ett dashboard, noe som forenkler arbeidet betraktelig.
Hva er et realistisk feilbudsjett for en nyutviklet applikasjon?
For en helt ny applikasjon kan feilbudsjettet være større, kanskje 15-20 %, fordi systemet ennå ikke er stabilisert. Målet er å redusere dette gradvis. Start med å måle den naturlige feilraten over 2-3 måneder, og sett deretter et mål som er 10-20 % bedre enn baseline. Unngå å kopiere mål fra modne systemer rett fra starten.
Hvordan håndterer jeg motstand fra utviklere som mener dette er micromanagement?
Involvér utviklerne i definisjonsfasen. La dem velge hvilke metrikker som gir mest smerte i hverdagen. Forklar at SLOene er designet for å identifisere prosessproblemer (som lange ventetider for review), ikke for å evaluere enkeltpersoners ytelser. Når teamet ser at SLOene hjelper dem med å få fjernet hindringer, vil motstanden ofte avta.