Hvordan kan vi forbedre testpraksis i produktionen og infrastrukturtesten?

I de seneste år er der blevet gjort store fremskridt inden for testpraksis, der sigter mod at forbedre pålideligheden og stabiliteten af systemer, især i produktionsmiljøer. En af de vigtigste diskussioner er, hvordan man effektivt tester i produktion uden at gå på kompromis med systemets integritet eller brugeroplevelse. Et af de centrale elementer i denne proces er at forstå de specifikke praksisser, der kan implementeres direkte i produktionsmiljøet i stedet for at bruge separate testmiljøer, som traditionelt har været normen.

For at opretholde denne tillid er det også nødvendigt at forbedre logning og overvågning i produktionen, så korrekt adfærd er synlig under udgivelsen af nye funktioner. Det er ikke nok kun at sikre, at systemerne fungerer korrekt; det er også vigtigt at kunne spore og reagere på fejl i realtid. Overvågning er en uundværlig del af teststrategien, da det giver indsigt i systemets sundhed og hjælper med at identificere eventuelle problemer hurtigt.

Integrationstests er også et område, der kræver opmærksomhed. Ved at implementere ændringer med kontrol over eksponeringen kan du minimere integrationsrisikoen. Dette betyder, at nye funktioner eller opdateringer kan testes gradvist og med minimal påvirkning på den eksisterende infrastruktur.

Et andet vigtigt aspekt af testning i moderne systemer er infrastrukturtesten. Når infrastrukturen bliver kode, kan den drage fordel af de samme automatiserede testværktøjer, som anvendes til produktet. Eksempelvis kan statisk analyse, enhedstest og accepttest alle anvendes på infrastrukturen. Test Kitchen er et populært værktøj til automatiserede tests af konfigurationsstyringskode. Det muliggør automatisering af processen med at oprette test-VM'er, køre konfigurationsstyringsværktøjer på disse VM'er og derefter køre verifikationstests på dem.

Selvom det er muligt at udføre forskellige typer af test mod infrastruktur, er det ikke altid nødvendigt eller nyttigt at gøre det. Som Matt Long pointerer, kan det være svært at enhedsteste infrastrukturkode, da der ofte mangler det nødvendige værktøj, og testene giver måske ikke meget værdi. Test af infrastruktur kan dog være gavnligt i det store billede, især når det gælder validering af, om infrastrukturen er korrekt installeret og konfigureret.

Det er også vigtigt at forstå, at infrastrukturen i dag ofte er mere dynamisk, og derfor skal teststrategier også være fleksible. Hvor det før kunne være tilstrækkeligt at teste i en statisk udviklings- eller testmiljø, kræver den moderne tilgang, at både test og overvågning integreres i produktionsmiljøet selv. Det betyder, at testning og overvågning ikke længere er adskilte aktiviteter, men snarere komplementære praksisser, der begge bidrager til systemets sundhed og stabilitet.

Hvordan Helios, PagerDuty og Fail Friday Skaber Pålidelighed i Produktion

Helios er et open-source software, der stadig er under aktiv udvikling. Som en del af Spotify's teknologi stack er det et centralt element i deres skaleringstrategi, og det har været i produktion siden juli 2014. Helios er designet til at hjælpe med at orkestrere containere, hvilket giver en stabil og automatiseret måde at skalere op eller ned i en produktion, der kræver store mængder af beregningskraft. En af de primære styrker ved systemet, ifølge industry kommentatoren Jonathan Vanian, er den orkestreringstjeneste, der koordinere containerne. Spotify understreger, at de allerede har hundredevis af maskiner i produktion, men der er stadig langt fra grænsen for, hvad den nuværende arkitektur kan håndtere.

Samtidig med at Spotify fortsætter med at bruge Helios til at orkestrere sine containere, har PagerDuty taget en anden tilgang for at sikre sin egen platform. PagerDuty er en vigtig aktør indenfor enterprise-grade incident management, og det har over 8000 kunder på tværs af 80 lande. Selskabet er kendt for deres robuste arkitektur, som inkluderer redundans på tværs af datacentre og cloud-tjenester. Det er en del af deres strategi for at sikre, at ingen alarmer går tabt, og at der altid er flere kommunikationskanaler i drift.

En af de mest interessante praksisser, som PagerDuty anvender for at opnå høj pålidelighed, er deres koncept “Failure Friday”. Dette initiativ handler om at skabe fejl med vilje i produktionsmiljøet, så udviklingsteamet kan teste systemernes robusthed under reelle forhold. Dette er ikke en metode, der er uden risici, men formålet er klart: For at være forberedt på fejlsituationer, er det nødvendigt at teste dem aktivt, så man forhindrer katastrofer i at opstå uventet.

På en praktisk måde kan “Failure Friday” se ud som en serie af forberedelser, der inkluderer at planlægge et møde, informere alle involverede parter, og aktivt deaktivere automatiserede systemer som cron-jobs og konfigurationsstyring, så ændringer ikke rulles tilbage af sig selv. Når systemerne er angrebet, overvåger udviklerne dashboards for at sikre, at alarmerne er relevante, og at de hurtigt kan identificere og løse problemer.

Metoden, der benyttes af PagerDuty, kræver en kultur, hvor fejlhåndtering er en naturlig del af arbejdsprocessen, og det er netop dette, som Tim Armandpour, tidligere Vice President for Engineering hos PagerDuty, fremhæver som en vigtig faktor i virksomheds succes. Hans synspunkt er, at ikke alle virksomheder bør bruge præcis den samme fremgangsmåde. For eksempel kan mindre virksomheder vælge at have en dedikeret medarbejdergruppe til at håndtere fejl, mens større organisationer måske har et mere centraliseret setup. Uanset størrelsen på organisationen, handler det om at have en kultur, der er forberedt på at reagere hurtigt og proaktivt i tilfælde af systemfejl. Dette hjælper med at sikre, at systemerne kan håndtere kompleksiteten og den potentielle risiko, der følger med at arbejde med store produktionssystemer, hvor nedetid ikke er en mulighed.

Den vigtigste lære, som både Helios og PagerDuty illustrerer, er nødvendigheden af at integrere pålidelighed i alle aspekter af systemudvikling. Uanset om du orkestrerer containere i en stor skala som Spotify eller håndterer kritiske incidenter som PagerDuty, er det centralt at forberede sig på det uundgåelige. Det betyder ikke kun at opbygge redundans, men også at have en plan for, hvordan man håndterer og lærer af fejl, mens de opstår i produktionen. Dette er kernen i at bygge et system, der ikke kun kan skalere effektivt, men også modstå uforudsete hændelser, og tilpasse sig hurtigt til nye krav.

Desuden er det vigtigt at forstå, at ingen arkitektur er fejlfri, og derfor er det ikke kun nødvendigt at have tekniske løsninger på plads, men også at opbygge et organisatorisk mindset, der værdsætter testning og læring af fejl. Når organisationer implementerer sådanne initiativer, kan de opbygge en kultur af tillid og samarbejde, der gør dem i stand til at håndtere den kompleksitet og de risici, der følger med skalerbare systemer i produktion.

Hvordan kan en DevOps-fejlfilter forbedre softwarekvalitet og teststrategi?

Forestil dig en model for automatisering i et DevOps-miljø. Denne model består af seks lag, som er opdelt i to grupper: de øverste tre lag handler om testning, der udføres i udviklingsmiljøet, mens de nederste tre lag fanger data i produktionen, som kan bruges til at opdage fejl og vurdere produktkvaliteten. De øverste lag omfatter enhedstest, integrationstest og end-to-end test, mens de nederste lag omfatter alarmering, overvågning og logning. Hver af disse lag kan ses som et filter, der fanger fejl på forskellige stadier af deres livscyklus.

Enhedstest er det fineste filter og fanger de mindste fejl, mens integrationstest og overvågning fanger lidt større fejl. End-to-end test og alarmering er bredere og fanger kun de største problemer. Selv med 100 % dækning af enhedstest kan vi ikke forhindre, at alle fejl når de lavere lag. Når vi bevæger os gennem integrationstests, end-to-end tests og til produktionen, ændrer vi både infrastrukturen og systemerne, vi arbejder med, og fejl kan opstå fra uventede kilder udenfor vores egen applikation. Derfor bliver filterets mesh stadig bredere, jo længere vi kommer ned i lagene.

Når vi når produktion, fungerer filteret som et blokfilter. De øverste lag fanger de største problemer, mens de nederste fanger de mindste. På dette tidspunkt opdager vi ikke nye problemer mellem lagene, men graver blot dybere i detaljerne i den produktionsdata, vi har indsamlet. DevOps-filteret hjælper derfor til at åbne op for en bredere diskussion om teststrategi, idet de tests, der implementeres i udviklingsteamet, samt den data, der indsamles i produktionen, udgør selve mesh-strukturen i filteret.

Hvis udviklingsteamet har dårligt testdækningsniveau, vil mesh-strukturen have huller, og fejl kan slippe igennem og blive større problemer. Manglende dækning i enhedstestene betyder, at flere "larver" kan slippe igennem i integrationstestlaget, og så videre. I sådanne tilfælde kan det være en strategisk beslutning at fange en fejl senere i processen. Måske er en bestemt integrationstjeneste ikke mulig at isolere, eller en enhedstest er vanskelig at implementere, hvorfor det besluttes at inkludere den i et senere testværktøj. Det er afgørende at diskutere disse strategiske beslutninger, så der ikke opstår misforståelser.

Når vi taler om automatik i DevOps, skal man ikke kun tænke på funktionelle tests, men også på ikke-funktionelle aspekter som sikkerhed, performance og brugervenlighed. Man kan bruge de samme automatiseringsmekanismer – testautomatisering under udvikling og indsamling af metrikker i produktionen – til at forbedre disse områder.

Eksplorativ testning er et andet aspekt, der spiller en vigtig rolle i DevOps-strategien, selvom det ofte får mindre opmærksomhed i et miljø, der fokuserer på hurtig levering. Eksplorativ testning finder ofte sted både før koden merges til hovedrepositoryet og efter, når brugerne interagerer med applikationen. Dette betyder, at mulighederne for at udføre eksplorativ testning i et automatiseret pipeline-miljø er begrænsede. Hvordan tester man eksplorativt med den tid, man har til rådighed, og hvad er det nødvendige detaljeringsniveau?

Det er her, at ideen om en "testpendul" kommer ind. Forestil dig et pendul i ro – det repræsenterer din testtilgang. På venstre side af pendulet tester du for grundigt, mens du på højre side tester for overfladisk. Når du starter på et nyt projekt, er din testtilgang ofte relativt overfladisk, men efterhånden som din erfaring øges, vil din testning blive mere detaljeret. Dog er det vigtigt at holde øje med, hvornår pendulet når sin yderste position i begge retninger – når du har testet for meget eller for lidt, så du kan justere din tilgang derefter.

En god indikator for testningens effektivitet er antal opdagede fejl: Hvis du ikke finder mange fejl, men kunderne rapporterer problemer i produktionen, er din testning måske for overfladisk. Omvendt, hvis du hæver mange fejl, men ingen bliver rettet, eller kunderne rapporterer nul problemer, kan din testning være for dyb. Et andet indikator er feedback fra teamet og ledelsen. Hvis dit team kontinuerligt udvider omfanget af dine tests, kan det være et tegn på, at du ikke har testet nok. På den anden side, hvis dit team reducerer omfanget, kan det være en opfordring til at evaluere, hvordan du bruger din testtid mere effektivt.

Endtext

Hvordan samarbejde på tværs af udviklingsdiscipliner kan forbedre DevOps-kulturen

Et eksempel på dette er Etsy-programmet, som er delt op i tre dele: forberedende hjemmearbejde, en fysisk klasse og derefter praktisk anvendelse. Denne struktur giver en god måde at udvide forståelsen mellem forskellige teammedlemmer og opfordrer til krydsfunktionelt samarbejde. På samme måde som når en udvikler roterer ind i support, kan det at invitere folk fra andre discipliner ind i udviklingen skabe empati og fremme samarbejdet på tværs af team. Det bliver en praktisk måde at udvide forbindelserne mellem forskellige arbejdsområder på og understøtte et mere sammenhængende arbejdsmiljø.

En metode til at fremme dette samarbejde på tværs af discipliner er gennem kode-dojos. Et dojo, i softwareudviklingssammenhæng, refererer til et lærings- og træningsmiljø, hvor deltagerne kan øve deres udviklingsfærdigheder sammen. Det kan inkludere udviklere, testere, designere eller personer fra andre områder, som arbejder tættere sammen om et fælles mål. I et dojo-scenario arbejdes der typisk på en konkret opgave eller problemstilling, som deltagerne samarbejder om at løse, ofte ved hjælp af parprogrammering og peer-feedback. Under en dojo-session vil der være en "sensei" – en facilitator – som styrer sessionen uden at give direkte løsninger, men i stedet hjælper deltagerne med at finde deres egne løsninger. Dette fremmer en følelse af kollektiv problemløsning og kan afsløre mange interessante dynamikker i gruppen.

At facilitere et dojo kan være en udfordring, især når man ser på de forskellige personligheder og samarbejdsstile i teamet. Det er en øvelse i at observere og guide uden at dominere, hvilket hjælper deltagerne med at udvikle både deres tekniske færdigheder og deres sociale interaktioner. Dojos fungerer ikke kun som et træningsværktøj, men også som en metode til at bryde ned barrierer mellem disciplinerne og skabe et miljø, hvor vidensdeling er i centrum.

Det er også vigtigt at forstå, hvordan samarbejde på tværs af discipliner påvirker organisationens struktur. Conway's Lov beskriver, hvordan en organisations struktur ofte afspejler den måde, kommunikationen foregår på internt. Det betyder, at organisationens måde at samarbejde på vil direkte påvirke den måde, systemer bliver designet og udviklet på. Hvis et udviklingsteam kun arbejder tæt sammen med én del af organisationen, såsom systemadministratorer og forandringsledere, men ikke har forbindelse til callcenteret eller analytikerne, vil de muligvis udvikle software, der er teknisk korrekt, men som ikke opfylder kundernes faktiske behov. Et mere tværfagligt samarbejde, der inkluderer feedback fra kundeservice og analytikere, kan gøre det muligt for udviklingsteamet at skabe løsninger, der er bedre tilpasset brugernes behov og ønsker.

At integrere feedback fra forskellige afdelinger som analyse, support og drift giver mulighed for at udvikle software, der ikke kun fungerer teknisk, men som også er mere relevante og brugervenlige for slutbrugerne. Når udviklingsteamet ikke arbejder isoleret, men i tæt samarbejde med dem, der arbejder direkte med kunderne eller overvåger systemets præstationer i drift, vil de kunne reagere hurtigt på problemer og ændringer i realtid. Dette skaber et mere fleksibelt, responsivt og effektivt arbejdsflow, som kan føre til bedre produkter og en højere tilfredshed blandt både medarbejdere og kunder.