Single Point of Failure

Single Point of Failure, ofta förkortat SPOF, är en komponent, funktion, förbindelse eller beroendepunkt som ensam kan orsaka att ett helt system eller en kritisk funktion slutar fungera.

I kommunikationssystem kan en Single Point of Failure exempelvis vara en ensam internetförbindelse, en central server, en basstation, en switch, ett teknikrum, en strömmatning eller en molntjänst som flera andra funktioner är beroende av.

Om denna enda punkt slutar fungera finns ingen alternativ väg, reservfunktion eller fungerande rutin som kan ta över. Resultatet blir att hela eller delar av verksamheten tappar funktion.

Exempel på vanliga Single Points of Failure är:

  • en ensam fiberförbindelse till en anläggning
  • en router eller switch som all trafik passerar genom
  • en central server utan reservmiljö
  • ett teknikrum utan alternativ placering
  • en basstation utan överlappande täckning
  • ett kommunikationssystem som kräver internet för all funktion
  • en molntjänst utan lokal fallback
  • en strömmatning utan UPS eller reservkraft
  • en operatörslösning utan alternativ bärare eller roaming

En Single Point of Failure är inte alltid uppenbar. Ibland finns flera system på ytan, men de delar samma bakomliggande beroende, exempelvis samma elmatning, samma nätförbindelse, samma servermiljö eller samma leverantör. Det medför att även ett till synes litet fel kan få stora konsekvenser.

Failover i praktiken

Målet med failover är ofta att användaren inte ska märka avbrottet, eller åtminstone att påverkan ska bli så liten som möjligt. Men i praktiken beror resultatet på hur systemet är utformat.

Vid vissa typer av failover kan pågående sessioner fortsätta utan avbrott. I andra fall kan användaren märka en kort fördröjning, behöva återansluta eller tappa vissa funktioner tillfälligt. Den nya förbindelsen kanske inte heller har samma kapacitet och vissa tjänster behöver därför prioriteras och andra begränsas.

När failover utformas bör man inte bara fråga om systemet kan växla till en reserv, utan också hur växlingen sker och vad som händer efteråt.

  • Vilka fel ska utlösa failover?
  • Hur snabbt ska växlingen ske?
  • Sker växlingen automatiskt eller krävs manuellt beslut?
  • Påverkas pågående samtal, sessioner eller dataöverföringar?
  • Har reservvägen tillräcklig kapacitet?
  • Ska viss trafik prioriteras i reservläget?
  • Hur återgår systemet till normalläge när felet är åtgärdat?
  • Testas failover regelbundet under realistiska förhållanden?

En failover-lösning är bara tillförlitlig om den är dokumenterad, övervakad, testad och anpassad till verksamhetens faktiska krav.

Hur identifierar man en Single Point of Failure?

Single Points of Failure identifieras ofta genom riskanalys, systemgenomgång eller kontinuitetsplanering.

Viktiga frågor är:

  • Vilka funktioner måste alltid fungera?
  • Vilka komponenter är dessa funktioner beroende av?
  • Finns alternativa vägar om en komponent fallerar?
  • Delar huvud- och reservsystem samma ström, nät, lokal eller leverantör?
  • Vad händer om internetanslutningen försvinner?
  • Vad händer om en central server eller molntjänst blir otillgänglig?
  • Vad händer om teknikrummet inte går att använda?
  • Finns rutiner om automatiska system inte fungerar?

En användbar metod är att följa hela kedjan från användare till tjänst: terminal, radio- eller nätaccess, transportnät, core/system, applikation, strömförsörjning, driftmiljö och användarrutiner.

Hur minskar man risken?

Risken för Single Points of Failure kan minskas genom att bygga bort eller begränsa beroendet av enskilda punkter.

Redundans
Införa reservvägar, extra kapacitet eller alternativa system.

Diversitet
Säkerställa att reservlösningar skiljer sig i teknik, väg, placering eller beroenden.

Separation
Placera kritiska komponenter, förbindelser och kraftmatningar fysiskt åtskilda.

Failover
Låta system automatiskt växla till reservresurs vid fel.

Fallback
Definiera alternativa arbetssätt när full funktion inte kan upprätthållas.

Övervakning
Upptäcka fel i tid och agera innan de påverkar verksamheten.

Test och övning
verifiera att reservlösningar och rutiner fungerar i praktiken.

Målet är inte alltid att eliminera alla möjliga felkällor. Målet är att se till att ett enskilt fel inte leder till ett oacceptabelt avbrott.