mars 7, 2025|1:34 e m
Oavsett om ni söker vägledning kring molnmigrering, effektivare IT-drift eller att börja nyttja AI på riktigt – vi finns här för att hjälpa er nå nästa nivå. Fyll i formuläret så kontaktar vi dig för ett första samtal om era behov och mål.
Att skapa moderna applikationer med hjälp av serverlös teknik och managed services innebär att vem som helst kan bygga distribuerade system med hög tillgänglighet utan att behöva oroa sig för den underliggande infrastrukturen. Men allt är inte bara roligt och lekfullt. Detta föredrag som jag höll på AWS re:Invent 2019 med titeln “Performing chaos engineering in a serverless world” förklarar några av utmaningarna med serverless, vanliga svagheter i serverlösa applikationer samt utmaningar med att använda kaosteknik i serverless. Vänligen se videon.
Även om allt började med latensinjektion som i Yan Cuis artiklar, är latens långt ifrån det enda möjliga felet vi kan ha i våra serverlösa applikationer. I “failure-lambda”, “failure-azurefunctions” och “failure-cloudfunctions” finns det nu fem olika “failure modes” att välja mellan:
Tillför latens till den exekverade funktionen, styrd med ett minimalt och maximalt intervall på millisekunder. Detta kan t.ex. användas för att simulera tjänstens latens eller för att testa och hjälpa till att ställa in dina timeout-värden.
Kastar ett undantag i funktionen. Hjälper dig att testa hur din applikation och kod hanterar undantag.
Din funktion kommer att returnera en valfri statuskod, t.ex. 502 eller 404 i stället för den normala 200. Detta ger dig möjlighet att testa vad som händer när det uppstår fel.
Kommer att fylla din temporära disk med filer för att skapa ett fel. Om du använder en disk för att lagra temporära filer kan du testa hur programmet beter sig om disken blir full eller om du inte kan lagra på den.
Blockerar anslutningar till angivna värdar. Används för att simulera att tjänster eller tredje part inte är tillgängliga.
Alla dessa felsökningslägen kan användas tillsammans med en felfrekvens som du ställer in. Standardinställningen är att fel uppstår vid varje anrop, men i verkligheten är det troligt att t.ex. en tredje part inte är tillgänglig vid 50 % av anropen till den värden eller att ett undantag inträffar vid en fjärdedel av anropen. Genom att sätta kursen kan du uppnå detta.
