Hvad er det for en rolle, og har vi virkelig brug for den?
Det kommer lidt an på, hvilken forretning man driver, og hvor meget sindsro, man håber på at have. Med de seneste nedbrud af services hos kendte større it-leverandører, så kunne man ønske sig mere stabilitet.
Her er et bud på en forklaring af, hvilken rolle det er, hvilke fordele den kan bringe, og dermed, hvorfor den kan være vigtig, samt hvordan man kan hjælpe den rolle. Som titlen antyder, så drejer det sig om pålidelighed - sikring af en løsning.
I en softwareudviklingsvirksomhed har vi normalt følgende roller:
- Arkitekter - sikrer det overordnede design og væsentlige beslutninger.
- Udviklere, eller "Dev" - sikrer udviklingen af de applikationer, der er behov for. Sikrer løsningen mod angreb.
- Quality Assurance, "QA" - sikrer kvaliteten af det udviklede. At løsningen rent faktisk løser den rigtige opgave med korrekt udfald.
- User Experience, "UX" - sikrer en god brugeroplevelse for brugere gennem forskellige brugsmønstre. At løsningen giver mening, at næste skridt falder naturligt.
- Operations, "Ops" - sikrer at processer og maskiner kører
Men hvad mere er der så at sikre?
De ovenstående roller sikrer primært et statisk billede af løsningen, men hverdagen er mere dynamisk, hvilket bringer andre udfordringer. For at øge pålideligheden af løsningen under vilkårlige udfordringer.
På den lange bane skal sikres, at brugeroplevelserne er gode også med mange samtidige brugere og med meget data i systemet. Vi skal også have styr på, at det er til mindst mulig gene, hvis dele af systemet går ned eller bliver overbelastet.
Hvis det tager mere end 1 sekund at få et svar fra systemet, så er det en dårlig brugeroplevelse. Hvis det sker hyppigt for en stor andel af brugere, så er der en risiko for, at man mister dem som kunder. Det betyder, at overvågningen af de statistiske elementer for de forskellige brugerrejser kan være kritiske målinger. F.eks. et Service Level Objective (SLO), der siger, at vi vil have 90% af svartiderne ligger under 500ms og max 1% ligger over 2 sekunder.
Hvis vi indgår en kontrakt med 3. part om at have en 99.99% oppetid - hvordan måler vi så det, hvordan sikrer vi os, at vi kan overholde det? Hvordan sikrer vi os i mindelig tid, at vi kan løse problemer før de bliver uoverkommelige?
Er der hyppigt en dårligere brugeroplevelse for mobilbrugere eller fra bestemte destinationer? Hvordan kan vi løfte de opgaver bedst muligt?
Mange af spørgsmålene lyder som noget Application Performance Monitoring (APM) kan give svar på - men hvem løfter de opgaver? Hvem kikker på metrikkerne og får lagt opgaver i backloggen eller bragt frem i lyset?
Blandt de ting, som APM ikke direkte belyser er infrastruktur kritiske udfordringer og fremskrivninger:
- Hvad sker der, hvis vores data stor-fejler?
- Kan det betale sig at udvide med cloud hosting i en anden region? Hvis vi f.eks. har en mindre brugerbase i Sydamerika, og de altid ligger i 3. kvartil af responstider - og vi ønsker at lave et salgsfremstød om en måned i netop den region.
- Hvis vores hovedside bliver udsat for DDoS angreb, hvad sker der så?
Hvordan finder vi de kritiske elementer, og hvordan får vi testet effekten? Dette er nogle af de aspekter en SRE bør tage sig af - naturligvis i samarbejde med både forretningen og udviklingsteams.
Eksperimentér for bedre viden
Man kan selvfølgelig spekulere over tingene, men i IT-verdenen har vi heldigvis ofte en mulighed for at teste tingene - enten i produktion eller på et andet miljø. Nogen siger: "Tillid er godt, kontrol er bedre." Her kan vi faktisk verificere vores tillid til systemet.
Failure Mode and Effects Analysis (FMEA) eller Failure Mode, Effects, and Criticality Analysis (FMECA) er én metode. Man opstiller en hypotese, snakker om et forventeligt resultat, udfører en test og vurderer det faktuelle resultat. Herefter kan man træffe en beslutning om der skal gøres noget og i så tilfælde, hvad der skal gøres.
Når du ved, at dit system er pålideligt - og at den pålidelighed bliver verificeret - så er der mere frihed til at forsøge nye tiltag. Den videnskabelige metode giver os den frihed, at vi nu med sindsro kan udføre de eksperimenter vi har behov for og blive klogere af den skade, der sker i vores kontrollerede miljø under vores udførelse - frem for uventet sker i vores produktionsmiljø, hvor ingen er klar på at gribe nedbruddet.
Forsimplet parallel
Hvis man skal give en forsimplet parallel, så bliver en bil designet, bygget, funktions- og crashtestet før den kommer på markedet. Når bilen er købt og i drift, så bliver den vedligeholdt: Nye viskerblade, brændstof.
Det er netop den særlige vedligeholdelse - dækskift, olieskift, motorkontrol, aircondition efterfyldning, bremseskiver - syn, og eventuel tilbagekaldelse, der ikke er blandt ejerens normale opgaver. Det er dog opgaver, der allerede er kendte og skemalagte for de fleste biler, men hvis du skulle sikre pålidelighed af din bil uden disse skemalagte syn og vedligehold, så ville du sikkert indføre langt flere kontroller og tjek selv. Det er blandt andet dét din SRE sørger for kommer til at ske med IT-forretningen.
Skal - skal ikke?
Hvis I kører efter DevOps principper med en agil tilgang og har et større eller et kritisk set up, så kan SRE være en god proaktiv måde at tilgå stabiliteten for løsningen i dag og for fremtiden.
Hvis man vælger en SRE-rolle, så kan man støtte op om denne med f.eks. et APM-værktøj.
Fordi det ikke alene er et APM, men også giver svar på root causes, den kørende arkitektur - som kan være forskellig fra den designede - Real User Monitoring (RUM), der giver metrikker på brugernes oplevelser, herunder om det er tilfredsstillende, tolerabel eller frustrerende.
Vi kan få analyseret belastningen på tværs af applikationerne, der kører. Det betyder, at hvis der er en dårligere performance i et applikationsflow fordi en fælles databaseserver f.eks. bliver brugt af andre systemer samtidig, så kan vi få et fingerpeg om, at det er dét, der er årsagen og f.eks. ikke den applikation, der performer dårligt.
Vi kan definere SLI, SLO, og SLA, så Dynatrace selv holder øje med vores error budget, og med potentiel AI baseret autoremediation kan vi hurtigt rulle en uheldig release tilbage.
Konklusion
Pålidelighed i software løsninger er afgørende, især i en tid, hvor nedbrud hos større it-leverandører kan have alvorlige konsekvenser. Brugeroplevelsen er central, og selv små forsinkelser eller fejl i systemet kan føre til tab af kunder. Så SRE-rollen er afgørende for at opnå pålidelige og stabile softwareløsninger, især i en verden, hvor forventningerne til systemernes ydeevne er ekstremt høje.
Med SRE og passende værktøjer som APM kan organisationer opretholde systemets pålidelighed, løse problemer proaktivt og eksperimentere med nye tiltag i et kontrolleret miljø. Dette sikrer en fortsat positiv brugeroplevelse og forhindrer uventede nedetid og fejl i produktionen.
Mangler du sparring på hvordan du kommer videre, enten med opgradering af dit nuværende system eller gerne vil bygge et nyt, så kontakt os på +45 61 77 70 70 eller på mail: rasmus.halvor@soprasteria.com