Indhold
- Forberedelse til fiasko
- De næste trin
- Ingen fejl, ingen stress - Din trinvis vejledning til oprettelse af livsændrende software uden at ødelægge dit liv
- Læring og forbedring gennem øvelser
Kilde: pressureUA / iStockphoto
Tag væk:
Moderne systemer skal være i stand til at håndtere kaos for at undgå nedetid. Derfor er det vigtigere end nogensinde at grundigt teste systemer og sikre deres elasticitet.
På trods af vores største indsats for at undgå dem, er IT-hændelser en uundgåelig del af jobbet - og det er kun vanskeligere at prøve at ligge foran den forretningskrævende nedetid. Systemer i dag er tæt koblede og stadig mere komplekse, og med mere bevægelige dele kommer flere muligheder for at gå galt.
Dette er en af grundene til, at flere og flere organisationer henvender sig til mikroservices for øget tilgængelighed af tjenester og bedre modstandsdygtighed over for fiasko. Men selvom dette er gode lokaler til at bryde monolitiske applikationer, kan de også potentielt sammensætte risikoen for fiasko - medmindre de udtrykkeligt er designet med elasticitet i tankerne.
Forberedelse til fiasko
I betragtning af de iboende kaotiske karakter af distribuerede systemer, bør tjenester udvikles ikke kun for at forudse fiasko, men for automatisk at komme sig i tilfælde af fejl. Dette betyder, at der regelmæssigt indføres fejl for at sikre, at dine systemer kan håndtere kaos uden at forstyrre service til slutkunder. Og for at opnå dette har du brug for muligheden for at simulere produktionslignende trafik i testmiljøer.
Selvfølgelig er det en god ide at teste modstandsdygtighed, inden ændringer sker i produktionen. Hvis du ikke gør dette, vil du ikke være i stand til at bekræfte, at dine tjenester kan understøtte både gennemsnitlige og maksimale belastninger. Faktisk er den sikreste indsats at sikre, at dit produkt kan håndtere op til det dobbelte af det maksimale beløb uden at skulle skalere op.
Når det kommer til test af modstandsdygtighed, skal de rigtige værktøjer ikke være for bekymrede over, hvordan anmodninger håndteres, bare for at de har den rigtige effekt til sidst. Husk, at inputtjenesten under visse betingelser ikke kan aflevere en anmodning til resten af systemet, men ikke rapportere fejlen. Du må ikke risikere problemer, der flyver under overvågningsradaren ved at sikre dig, at en ende-til-ende-validering faktisk finder sted. (Se Tekniske svigt for mere: Kan vi leve med dem?)
De næste trin
Efter at have forstået, hvordan tjenester opfører sig under belastning, er det tid til at begynde at introducere fejlhændelserne. Som med al software-test er det bedst at have automatiserede værktøjer, der giver dig mulighed for nemt og hurtigt at gengive scenarier, så du kan koordinere komplekse begivenheder, der har indflydelse på forskellige infrastrukturteknologier. Og ud over muligheden for at verificere rettelser og ændringer til tjenesterne giver dette dig mulighed for at køre tilfældige fiaskoscenarier i ethvert miljø og i en tidsplan.
Meningsfulde fiaskohændelser afhænger i vid udstrækning af layoutet af dine tjenester, og du kan formulere dem ved at stille specifikke spørgsmål, der er relevante for dig. Hvad er for eksempel virkningen for folk, der bruger frontend, når en database bliver utilgængelig i et bestemt tidsrum? Kan disse brugere stadig navigere på webgrænsefladen? Kan de stadig udstede opdateringer til deres information, og vil disse opdateringer blive behandlet korrekt, når databasen igen kan nås?
Hvis du kører flere mikroservices, kan du spørge, om der vil være et globalt driftsstop, hvis en individuel service går ned. Eller hvis du har en kømekanisme til at buffe kommunikationen mellem tjenester, hvad sker der når forbrugertjenesten (eller tjenesterne) holder op med at arbejde? Vil brugere stadig kunne arbejde med din applikation? Og givet en gennemsnitlig belastning, hvor lang tid har du inden køerne løber over og du begynder at miste s?
Ingen fejl, ingen stress - Din trinvis vejledning til oprettelse af livsændrende software uden at ødelægge dit liv
Du kan ikke forbedre dine programmeringsevner, når ingen er interesseret i softwarekvalitet.
Når du har defineret et par centrale spørgsmål om din infrastruktur, kan du derefter begynde at liste forskellige måder at simulere disse fejl på. Det kan være nok til at stoppe en bestemt tjeneste eller en databaseserver. Det kan være en god ide at blokere hovedtråden i en tjeneste for at simulere en dødlås, mens dens container stadig reagerer og kører. Du beslutter muligvis at indføre regler i dit netværk for at blokere trafik mellem bestemte tjenester. I Linux-miljøer kan du bruge værktøjer som 'tc' til at efterligne netværkssituationer som høj latency, tabte, ødelagte eller duplikerede pakker. (Det kan være vigtigt at involvere brugere i testningen. Læs mere i 4 grunde til, at slutbrugere er nødt til at deltage i testning før UAT.)
Læring og forbedring gennem øvelser
Et af de mest værdifulde aspekter ved at skabe fiaskoscenarier er, at de kan udsætte alle de potentielle måder, som systemet kan svigte, og derved skære vejen til selvhelende logik. Dit team vil gennemgå trinene for at gendanne tjenester manuelt - en fantastisk øvelse, forresten, for at bekræfte, at de er i stand til at gøre dette inden for SLA'er. Automatisering af denne gendannelsesproces kan arbejdes på, men i mellemtiden kan du hvile let ved at vide, at dit team har gennemgået processen med at få tjenester tilbage på sporet. Ved at gøre fejlscenarier tilfældige og regelmæssige og ikke afsløre de fulde detaljer om kørslen, kan du også inkludere opdagelse og diagnoser til boret - hvilket jo er en kritisk del af SLA'erne.
I sin kerne tager kaoteknik kompleksiteten af systemet som en given, tester det ved at simulere nye og skøre forhold og observerer, hvordan systemet reagerer. Dette er dataingeniørteams, der er nødt til at redesigne og konfigurere systemet igen for at opnå højere modstandsdygtighed. Der er så mange muligheder for at lære nye og nyttige ting. For eksempel kan du finde tilfælde, hvor tjenester ikke får opdateringer, når downstream-tjenester er ændret, eller områder, hvor overvågning mangler helt. Der mangler ikke spændende måder at gøre dit produkt mere robust og robust på!