Innehåll
- Förbereder sig för misslyckande
- Nästa steg
- Inga buggar, ingen stress - din steg-för-steg-guide för att skapa livsförändrad programvara utan att förstöra ditt liv
- Lärande och förbättring genom övningar
Källa: pressureUA / iStockphoto
Hämtmat:
Moderna system måste kunna hantera kaos för att undvika driftstopp. Det är därför det är viktigare än någonsin att noggrant testa system och säkerställa deras elasticitet.
Trots våra största ansträngningar för att undvika dem, är IT-incidenter en oundviklig del av jobbet - och att försöka ligga före affärseffekterande driftsstopp blir bara svårare. Systemen i dag är tätt kopplade och alltmer komplexa, och med mer rörliga delar kommer fler möjligheter för saker att gå fel.
Detta är en anledning till att fler och fler organisationer vänder sig till mikrotjänster för ökad tillgänglighet av tjänster och bättre motståndskraft mot fel. Men även om det här är fantastiska förutsättningar för att bryta monolitiska applikationer, kan de också potentiellt sammansätta risken för misslyckande - såvida de inte är utformade uttryckligen med tanke på motståndskraft.
Förbereder sig för misslyckande
Med tanke på de distribuerade systemens naturligt kaotiska karaktär bör tjänster utvecklas inte bara för att förutse misslyckande, utan för att automatiskt återhämta sig i händelse av fel. Detta innebär att regelbundet inleda fel för att säkerställa att dina system kan hantera kaos utan att störa servicen för slutkunder. Och för att uppnå detta behöver du förmågan att simulera produktionsliknande trafik i testmiljöer.
Naturligtvis är det en bra idé att testa motståndskraften innan produktionen ändras. Om du inte gör det kommer du inte att kunna verifiera att dina tjänster kan stödja både genomsnittliga och toppbelastningar. I själva verket är det säkraste spelet att se till att din produkt kan hantera upp till dubbelt högsta belopp utan att behöva skala upp.
När det gäller motståndskraftstest bör de rätta verktygen inte vara för bekymrade över hur förfrågningar hanteras, bara för att de har rätt inverkan i slutändan. Kom ihåg att inputtjänsten under vissa förhållanden inte kan lämna in en begäran till resten av systemet men inte rapportera felet. Riskera inte problem som flyger under övervakningsradaren genom att se till att validering från slutet till slut faktiskt sker. (För mer, se tekniska fel: Kan vi leva med dem?)
Nästa steg
Efter att ha förstått hur tjänster beter sig är det dags att börja introducera felhändelserna. Som med alla programvarutestning är det bäst att ha automatiserade verktyg som gör att du enkelt och snabbt kan återge scenarier, så att du kan samordna komplexa händelser som påverkar olika infrastrukturteknologier. Och utöver möjligheten att verifiera korrigeringar och ändringar av tjänsterna, gör detta att du kan köra slumpmässiga felsscenarier i alla miljöer och i ett schema.
Meningsfulla felhändelser beror till stor del på layouten för dina tjänster och du kan formulera dem genom att ställa specifika frågor som är relevanta för dig. Till exempel, vad är effekten för personer som använder front-end när en databas blir ouppnåelig under en viss tid? Kan dessa användare fortfarande navigera på webbgränssnittet? Kan de fortfarande utfärda uppdateringar av sin information, och kommer dessa uppdateringar att behandlas korrekt när databasen återigen kommer att nås?
Om du kör flera mikroservrar kan du fråga om det kommer att bli ett globalt avbrott om någon enskild tjänst kraschar. Eller om du har en kömekanism för att buffra kommunikationen mellan tjänster, vad händer när konsumenttjänsten (eller tjänsterna) slutar fungera? Kommer användare fortfarande att kunna arbeta med din applikation? Och med tanke på en genomsnittlig belastning, hur lång tid har du innan köerna flyter över och du börjar förlora s?
Inga buggar, ingen stress - din steg-för-steg-guide för att skapa livsförändrad programvara utan att förstöra ditt liv
Du kan inte förbättra dina programmeringsfärdigheter när ingen bryr sig om mjukvarukvalitet.
När du har definierat några viktiga frågor om din infrastruktur kan du sedan börja lista olika sätt att simulera dessa fel. Det kan vara tillräckligt för att stoppa en viss tjänst eller en databaseserver. Du kanske vill blockera huvudtråden i en tjänst för att simulera en dödlås, medan behållaren fortfarande svarar och körs. Du kanske beslutar att införa regler i ditt nätverk för att blockera trafik mellan specifika tjänster. I Linux-miljöer kan du använda verktyg som 'tc' för att emulera nätverkssituationer som hög latens, tappade, skadade eller duplicerade paket. (Det kan vara viktigt att involvera användare i testningen. Läs mer i fyra anledningar till att slutanvändare måste delta i tester innan UAT.)
Lärande och förbättring genom övningar
En av de mest värdefulla aspekterna av att skapa felsscenarier är att de kan avslöja alla potentiella sätt som systemet kan misslyckas, och därigenom skära vägen till självhelande logik. Ditt team kommer att gå igenom stegen för att återställa tjänster manuellt - ett bra drill, förresten för att bekräfta att de kan göra detta inom SLA: er. Det går att arbeta med automatisering av denna återställningsprocess, men under tiden kan du vila enkelt och veta att ditt team har gått igenom processen att få tjänster tillbaka på rätt spår. Genom att göra felscenarier slumpmässiga och regelbundna och inte avslöja hela detaljerna om körningen, kan du också inkludera upptäckt och diagnoser för borrningen - vilket trots allt är en kritisk del av SLA: er.
I sin kärna tar kaoteknik systemets komplexitet som en given, testar det genom att simulera nya och galna förhållanden och observerar hur systemet svarar. Det här är datateknikgrupperna som behöver utforma om och konfigurera systemet för att uppnå högre motståndskraft. Det finns så många möjligheter att lära sig nya och användbara saker. Till exempel kan du hitta fall där tjänster inte får uppdateringar när nedströms-tjänster har ändrats, eller områden där övervakning saknas helt. Det saknas spännande sätt att göra din produkt mer robust och robust!