Tekniska fallstudier

Tekniska beslut under verkliga begränsningar.

Det här är verkliga situationer, beskrivna så öppet som ansvaret tillåter. Fokus ligger på problemet, besluten och det operativa läget efteråt.

Utvalda arbeten

Fyra situationer där begränsningarna formade lösningen.

Anonymiserat kundfall

En SRE-driftsmodell för en produktionsplattform som alltid är igång

Situation: En produktionsplattform övergick till dygnet-runt-drift. Stödet måste fungera mellan skift i stället för att bero på enskilda personers minne.
Begränsning / tekniskt problem: Skift, beredskap, överlämning, ägarskap och incidentansvar behövde tydliga gränser, även för SRE.
Vad vi gjorde: Vi definierade skift, beredskap, överlämning, eskalering och beslutanderätt. Kedjan gick från ingenjören på skiftet via beredskap och områdesansvarig till plattformsägaren och CTO.
Resultat: Produktionsdriften kunde beskrivas med roller, tillstånd och processer i stället för personminne eller hjälteinsatser.
Vad det visar: Tillförlitlig drift kräver tydlig befogenhet och överlämning, inte bara skickliga människor.

Relaterad tjänstStabilisering och tillförlitlighet

Anonymiserat kundfall

Analys av en överbelastad produktionsdatabas vid ökad samtidighet

Situation: En produktionsdatabas närmade sig CPU-mättnad. Hälsokontroller misslyckades och flera externa konsumenter påverkades.
Begränsning / tekniskt problem: Återställd tjänst förklarade inte felet. Symtomen behövde skiljas från ökad samtidig belastning och en långsammare kritisk databasväg.
Vad vi gjorde: Efter att tjänsten hade återställts fortsatte vi orsaksanalysen. Omedelbar begränsning av påverkan skildes från korrigerande åtgärder och belägg från antaganden.
Resultat: Incidentrapporten dokumenterade belastningsändringen och databasfynden utan att behandla återställningen som bevis för orsaken.
Vad det visar: Återställning och rotorsaksanalys är olika milstolpar.

Relaterad tjänstStabilisering och tillförlitlighet

Tekniskt fall från Gronnark

Återställning av 17 Git-repositorier efter förlorad administratörsåtkomst

Situation: Administratörsåtkomsten till ett äldre GitHub-konto förlorades och kontot gick inte att återställa. Sjutton repositorier måste säkras före migreringen.
Begränsning / tekniskt problem: En överföring fick inte bli den enda kopian av historik och referenser.
Vad vi gjorde: Vi fångade referenser, historik och träd, skapade git bundles och grenarkiv, registrerade SHA256-manifest och kontrollerade bundles, objektintegritet, rena kloner, undermoduler och LFS-beroenden.
Resultat: Alla 17 repositorier återställdes i en ny organisation. Relevanta referenser verifierades SHA för SHA; den gamla organisationen bevarades som historisk källa.
Vad det visar: Bevara först. Migrera sedan.

Relaterad tjänstInfrastruktur och plattform

Anonymiserat kundfall

Ersätta instabil fjärrsupport för en tandvårdsmottagning

Situation: En mottagning använde ett Windows-baserat verksamhetssystem med lokal databas. Ett konsumentverktyg började bryta supportsessioner.
Begränsning / tekniskt problem: Databasen och interna tjänster kunde inte publiceras på internet bara för enklare fjärrskrivbord.
Vad vi gjorde: Vi utformade anslutningen separat från applikationen: krypterad tunnel, kontrollerad extern ingång och VPN för behöriga ingenjörer innan administrativa protokoll används.
Resultat: Den föreslagna åtkomstmodellen förutsatte att den lokala databasen inte gjordes offentlig och att nätverksinträde blev en uttrycklig kontroll. Den gav en säkrare arkitektur för att ersätta den opålitliga fjärrsupporten.
Vad det visar: Ett fjärrskrivbordssymtom kan vara ett arkitekturproblem för åtkomst.

Relaterad tjänstInfrastruktur och plattform

Fler tekniska fall

Skilda problem med konkreta förändringar i systemet eller driften.

Anonymiserat kundfall

Incidenthantering med tydligt ägarskap

Situation: Allvarlighetsgrad, ägare, eskalering och kriterier för avslut var otydliga.
Vad som förändrades: Vi införde allvarlighetsmodell, rollerna Owner och Commander, eskalering, avslutskriterier för incident och efteranalys samt korrigerande åtgärder med ansvariga i en gemensam incidentpost.
Resultat: Återställd produktion var inte längre det enda kravet för att stänga incidenten.

Anonymiserat kundfall

Skilja SRE-ansvar från applikationsansvar

Situation: SRE:s medverkan tolkades alltmer som ett krav att ensamt hitta orsaken till varje applikationsfel.
Vad som förändrades: Vi skilde detektering, konsekvensbedömning, samordning och eskalering från tekniskt ägarskap på komponentnivå.
Resultat: Ansvar kunde läggas där befogenhet och sammanhang fanns. Ansvar utan kontroll är inte ägarskap.

Anonymiserat kundfall

Skiftöverlämning som ett operativt system

Situation: Viktig driftinformation var utspridd mellan Slack, Jira, Confluence och personliga samtal.
Vad som förändrades: Vi standardiserade överlämning av aktiva incidenter, oavslutade ändringar, väntade händelser, risker, öppna uppgifter och ansvariga.
Resultat: Driftsammanfattningen blev en definierad systemförmåga snarare än ett informellt meddelande mellan skift.

Anonymiserat kundfall

Utreda hälsokontrollfel utan att hitta på en orsak

Situation: Kortvariga hälsokontrollfel och anslutningsrelaterade belägg följdes av snabb återhämtning.
Vad som förändrades: Vi dokumenterade observerade fakta, belägg, en möjlig mekanism och det som fortfarande var okänt var för sig.
Resultat: Efteranalysen markerade kunskapsgränsen i stället för att ge en obevisad orsak sken av visshet.

Tekniskt fall från Gronnark

Återuppbygga förtroendet för CI/CD efter repositoriomigrering

Situation: Flytten av repositorier flyttade inte identiteterna och behörigheterna som driftsättning byggde på.
Vad som förändrades: Vi byggde om Actions, egen runner, OIDC och AWS-förtroende, bytte SSH-nyckel och hemlighet och testade isolerat kedjan Actions–runner–AWS–SSH. Tillfällig brandväggsåtkomst togs sedan bort.
Resultat: Förtroendekedjan verifierades hela vägen i stället för att antas utifrån en grön pipeline.

Tekniskt fall från Gronnark

Bygga en isolerad stage-miljö före produktionsändringar

Situation: Webbändringar omfattade nu språk, edge-logik, CloudFront, WAF, geografiska ledtrådar och automatisering.
Vad som förändrades: Vi byggde stage med separat infrastrukturtillstånd, edge-förhandsvisning och egen driftsättningsväg. Flytt till produktion förblev ett separat beslut.
Resultat: Ändringar kunde testas i en driftsatt miljö utan att varje testfel blev en produktionsändring; stage hölls utanför sökindex.

Tekniskt fall från Gronnark

Internationell leverans utan tvingande geografisk omdirigering

Situation: Leverans på flera marknader krävde mer än en lista över länder.
Vad som förändrades: Vi definierade lokala, regionala och internationella profiler för distansarbete, arbete på plats, resor, överlappande arbetstid, fysiska insatser och tjänstetillgänglighet. CloudFront-landet är bara en ledtråd; besökaren väljer.
Resultat: Modellen visar vad som kan övervägas utan att antyda lokalt kontor, permanent närvaro eller tvingad omdirigering.

Tekniskt fall från Gronnark

Byta namn på ett teknikföretag utan att bryta kontinuiteten

Situation: Övergången från Aize.IT till Gronnark berörde domäner, e-post, Workspace, GitHub, DNS, certifikat, automatisering, dokumentation och kundrelationer.
Vad som förändrades: Vi planerade domänövergångar, omdirigeringar, e-postalias och migrering, DNS- och DKIM-ändringar, ett offentligt övergångsmeddelande och gradvisa ändringar av infrastrukturens identitet.
Resultat: Befintliga åtaganden och operativ åtkomst kunde fortsätta genom namnbytet. Teknisk omprofilering är också migrering.

Sekretess och omfattning

Kundfall anonymiseras när avtal eller driftsförhållanden kräver det. Vissa beskriver olika tekniska problem inom ett längre kunduppdrag; de motsvarar inte tolv olika kunder.

Känner du igen situationen?

Berätta vad som händer, vad som måste fortsätta fungera och var osäkerheten börjar.

Diskutera situationen