Tekniske casestudier
Tekniske beslutninger under reelle begrensninger.
Dette er faktiske situasjoner, beskrevet på et nivå som kan deles på en ansvarlig måte. Vi viser problemet, beslutningene og den operative tilstanden etterpå.
Utvalgte oppdrag
Fire situasjoner der rammene formet den tekniske løsningen.
01Anonymisert kundecase
En SRE-driftsmodell for en produksjonsplattform som alltid er i drift
- Situasjon
- En produksjonsplattform gikk over til kontinuerlig drift. Støtten måtte fungere på tvers av vakter, ikke bygge på enkeltpersoners hukommelse.
- Begrensning / teknisk problem
- Vakter, beredskap, overlevering, eierskap og hendelsesansvar trengte tydelige grenser, også for SRE.
- Hva vi gjorde
- Vi definerte vaktordning, beredskap, overlevering, eskalering og beslutningsrett. Kjeden gikk fra ingeniøren på vakt via beredskap og fagansvarlig til plattformeier og CTO.
- Resultat
- Produksjonsdriften kunne beskrives med roller, tilstand og prosesser fremfor personlig hukommelse og helteinnsats.
- Hva dette viser
- Pålitelig drift krever tydelig myndighet og overlevering, ikke bare dyktige folk.
Relevant tjenesteStabilisering og pålitelighet02Anonymisert kundecase
Analyse av en mettet produksjonsdatabase ved økt samtidighet
- Situasjon
- En produksjonsdatabase nærmet seg full CPU-belastning. Helsesjekker feilet, og flere eksterne forbrukere ble berørt.
- Begrensning / teknisk problem
- Å gjenopprette tjenesten forklarte ikke feilen. Symptomene måtte skilles fra økt samtidig belastning og en tregere kritisk databasebane.
- Hva vi gjorde
- Etter at tjenesten var gjenopprettet, fortsatte vi årsaksanalysen. Midlertidig avbøting ble skilt fra korrigerende tiltak, og bevis fra antakelser.
- Resultat
- Hendelsesrapporten dokumenterte lastendringen og funnene i databasebanen uten å gjøre gjenoppretting til bevis for årsaken.
- Hva dette viser
- Gjenoppretting og rotårsaksanalyse er forskjellige milepæler.
Relevant tjenesteStabilisering og pålitelighet03Teknisk case fra Gronnark
Gjenoppretting av 17 Git-repositorier etter tapt administratortilgang
- Situasjon
- Administratortilgangen til en gammel GitHub-konto gikk tapt, og kontoen kunne ikke gjenopprettes. Sytten repositorier måtte sikres før migrasjon.
- Begrensning / teknisk problem
- En flytting kunne ikke bli eneste kopi av historikk og referanser.
- Hva vi gjorde
- Vi fanget referanser, historikk og trær, laget git bundles og grenarkiver, registrerte SHA256-manifester og kontrollerte bundles, objektintegritet, rene kloner, submoduler og LFS-avhengigheter.
- Resultat
- Alle 17 repositoriene ble gjenopprettet i en ny organisasjon. Relevante referanser ble verifisert SHA for SHA; den gamle organisasjonen ble bevart som historisk kilde.
- Hva dette viser
- Sikre først. Migrer deretter.
Relevant tjenesteInfrastruktur og plattform04Anonymisert kundecase
Erstatning av ustabil fjernstøtte for en tannlegepraksis
- Situasjon
- En tannlegepraksis brukte et Windows-basert journalsystem med lokal database. Et forbrukerverktøy begynte å bryte støttesesjoner.
- Begrensning / teknisk problem
- Databasen og interne tjenester kunne ikke eksponeres mot Internett bare for enklere eksternt skrivebord.
- Hva vi gjorde
- Vi utformet tilkoblingen separat fra applikasjonen: kryptert tunnel, kontrollert ytre inngang og VPN for autoriserte ingeniører før administrative protokoller brukes.
- Resultat
- Den foreslåtte tilgangsmodellen forutsatte at den lokale databasen ikke ble offentlig tilgjengelig og at nettverksinngang ble en uttrykkelig kontroll. Den ga en sikrere arkitektur for å erstatte den ustabile fjernstøtten.
- Hva dette viser
- Et symptom i eksternt skrivebord kan være et problem med tilgangsarkitekturen.
Relevant tjenesteInfrastruktur og plattform
Flere tekniske caser
Ulike problemer med konkrete endringer i systemet eller driften.
05Anonymisert kundecase
Hendelseshåndtering med tydelig eierskap
- Situasjon
- Alvorlighetsgrad, eierskap, eskalering og kriterier for ferdigstillelse var uklare.
- Hva som endret seg
- Vi innførte en alvorlighetsmodell, rollene Owner og Commander, eskalering, ferdigkriterier for hendelse og etteranalyse samt korrigerende tiltak med ansvarlige i én hendelseslogg.
- Resultat
- At produksjonen svarte igjen, var ikke lenger eneste krav for å avslutte hendelsen.
06Anonymisert kundecase
Skille SRE-ansvar fra applikasjonsansvar
- Situasjon
- SRE-deltakelse ble gradvis tolket som at SRE alene skulle finne årsaken til alle applikasjonsfeil.
- Hva som endret seg
- Vi skilte deteksjon, konsekvensvurdering, koordinering og eskalering fra teknisk eierskap til komponenten.
- Resultat
- Ansvar kunne plasseres hos dem som hadde myndighet og kontekst til å handle. Ansvar uten kontroll er ikke eierskap.
07Anonymisert kundecase
Vaktbytte som et operativt system
- Situasjon
- Viktig driftsinformasjon var spredt mellom Slack, Jira, Confluence og samtaler.
- Hva som endret seg
- Vi standardiserte overlevering av aktive hendelser, uferdige endringer, forventede hendelser, risiko, ventende oppgaver og ansvarlige.
- Resultat
- Driftsoppsummeringen ble en definert systemegenskap, ikke en uformell melding mellom vakter.
08Anonymisert kundecase
Undersøke helsesjekkfeil uten å dikte opp årsaken
- Situasjon
- Korte feil i helsesjekker og tilkoblingsrelaterte spor ble fulgt av rask gjenoppretting.
- Hva som endret seg
- Vi dokumenterte observerte fakta, bevis, en mulig mekanisme og det som fortsatt var ukjent hver for seg.
- Resultat
- Etteranalysen viste kunnskapsgrensen presist i stedet for å presentere en uprøvd årsak som sikker.
09Teknisk case fra Gronnark
Gjenoppbygge tillit til CI/CD etter repositoriomigrasjon
- Situasjon
- Flytting av repositorier flyttet ikke identitetene og rettighetene som deployering var avhengig av.
- Hva som endret seg
- Vi bygget opp Actions, selvhostet runner, OIDC og AWS-tillit, byttet SSH-nøkkel og secret og testet isolert kjeden fra Actions via runner og AWS til SSH. Midlertidig brannmurtilgang ble fjernet etterpå.
- Resultat
- Tillitkjeden ble kontrollert ende til ende, ikke antatt ut fra en grønn pipeline.
10Teknisk case fra Gronnark
Bygge et isolert stage-miljø før produksjonen endres
- Situasjon
- Nettstedsendringer omfattet etter hvert språk, edge-logikk, CloudFront, WAF, geografiske hint og automatisering.
- Hva som endret seg
- Vi bygget stage med egen infrastrukturtilstand, edge-forhåndsvisning og egen deployeringsflyt. Produksjonssetting var fortsatt en egen beslutning.
- Resultat
- Endringer kunne testes i et deployert miljø uten at testfeil ble produksjonsendringer; stage ble holdt utenfor søkeindekser.
11Teknisk case fra Gronnark
Internasjonal levering uten tvungen geografisk videresending
- Situasjon
- Levering i flere markeder krevde mer enn en liste over land.
- Hva som endret seg
- Vi definerte Local-, Regional- og International-profiler for fjernarbeid, arbeid på stedet, reiser, overlapp i arbeidstid, fysisk innsats og tjenestetilgjengelighet. CloudFront-landet er bare et hint; brukeren velger.
- Resultat
- Modellen viser hva som kan vurderes uten å antyde lokalt kontor, fast tilstedeværelse eller tvungen videresending.
12Teknisk case fra Gronnark
Endre teknisk merkevare uten å bryte driftskontinuiteten
- Situasjon
- Overgangen fra Aize.IT til Gronnark berørte domener, e-post, Workspace, GitHub, DNS, sertifikater, automatisering, dokumentasjon og kundeforhold.
- Hva som endret seg
- Vi planla domeneflytting, videresendinger, e-postaliaser og migrasjon, DNS- og DKIM-endringer, offentlig overgangstekst og gradvis endring av infrastrukturidentitet.
- Resultat
- Eksisterende forpliktelser og operativ tilgang kunne fortsette gjennom navnebyttet. Teknisk omprofilering er også migrasjon.
Konfidensialitet og omfang
Kundecaser anonymiseres når avtaler eller driftshensyn krever det. Noen beskriver ulike tekniske problemer fra et lengre kundeforhold; de representerer ikke tolv forskjellige kunder.
Kjenner du igjen situasjonen?
Fortell hva som skjer, hva som må fortsette å virke og hvor usikkerheten begynner.
Drøft situasjonen