top of page
Untitled design - 2024-01-26T162935.807.png

Kaskadproblem

  • Skribentens bild: Michael Eklöf
    Michael Eklöf
  • 30 jan. 2024
  • 2 min läsning

Vilken är en av mina allra största käpphästar? 

 

Läser om boken Site Reliability Engineering och fastnade som vanligt lite extra på kapitlet om kaskadeffekter, enligt min erfarenhet troligen den vanligaste förekommande orsaken till stora och svårlösta problem, där grundläggande arkitekturella brister blir väldigt tydliga och till synes obetydliga buggar kan få katastrofala konsekvenser!



 Det som karakteriserar dessa typ av problem:


  • Oväntade systemsamband

  • Stor påverkan

  • Svårt att hitta riktig rotorsak

  • Svårt att testa i förväg


 

I många fall beror problemen på att man inte tar aktiva beslut på vilka nedströms anrop som måste funka för att anropet ska kunna leverera ett svar, och hur avvikelser från förväntad beteende hanteras. Man lutar sig ofta på inbyggda standardvärden i ramverk och runtimes utan att tänka på användarupplevelsen.

 

Jag brukar ställa några väldigt förenklade frågor:

'Om det här specifika anropet inte svarar, ska du vänta 30 sekunder, och sedan faila 'fult'? Eller ska du vänta 2-4 sekunder, och ge användaren ett snyggt felmeddelande?'

Eller

'Om den underliggande tjänsten inte har svarat på dina första 1000 anrop, ska du fortsätta att skicka 1000 till, eller backa av?'

 

Ja, det är självklarheter, och det finns mängder av välkända mönster på hur det kan hanteras, men hur ser din logik ut, och har du testat att det faktiskt fungerar som du tänkt?

 

Varje tjänst måste fundera på vilka nedströms beroenden man har, och hur olika typer av oväntade svar ska hanteras.


  • Felkoder (HTTP-felkoder, exceptions osv)

  • Trasiga svar (validera innehåll)

  • Timeoutfel (dvs inga svar alls).

  • Långsamma svar (alla eller en del av svaren från underliggande system var som är korrekta, men ovanligt långsamma)

  • Långsamma fel (vänta x sekunder och sen svara med felkod)

  • Osv…. 


I många fall har man i bästa fall tänkt på de två första, men man har sällan testat och mätt vad som händer i de andra fallen, när 30% av anropen till den underliggande tjänsten tar 20 sekunder istället för 20 millisekunder eller andra typer av intermittenta mönster. 

 

Vad finns det för lösningar? 

Se kommande inlägg nästa vecka för några konkreta exempel och arbetssätt!

Kommentarer


bottom of page