#feltolerans

[kqrx]

I have a joke about UDP

but you might not get it.

[kqrx]

Avslöja hemligheter utan att avslöja dem

Jag letar efter en bra backuptjänst för personligt bruk. Jag vet inte om jag har hittat den en, men jag ska prova rsync.net i en månad för att se om det är något att ha. På pappret är de helt otroliga, men jag väntar med lovorden tills jag har faktiskt provat dem ett tag. Däremot gör de en grej som fascinerade mig, som jag kan tala om redan nu.

De värnar om sina kunders integritet. De vill helst att ingen ska kunna se deras kunders filer, och de rekommenderar att man krypterar sina filer.

Men om polisen gör en razzia mot dem finns det en risk att polisen läser kundernas filer. Det är hemskt och det vill rsync.net upplysa kunderna om. Problemet är att i USA kan tydligen polisen kräva att rsync.net inte avslöjar att en razzia har skett. rsync.net vill kunna avslöja att en razzia har skett. Hur gör man då?

rsync.net går ut varje vecka med att en razzia inte har skett. De berättar en gång i veckan att de inte har haft något problem med polisen. Om de plötsligt slutar berätta det så vet alla kunder att de har haft problem med polisen och att kundernas filer kan ha blivit lästa av obehöriga.

Men… säger du. Hur vet man om de har slutat skriva såna meddelanden? De kanske bara lägger upp samma meddelande dag ut och dag in. Nej, de har ett trick mot det också. I varje meddelande finns det en eller två rubriker från dagens nyhetsflöde. Samma dag som de skriver ett meddelande tar de nyhetsrubriker från den dagen för att bevisa att meddelandena inte var skrivna i förhand. Så primitivt, men så smart.

Men… fortsätter du säga. Kan inte polisen bara fortsätta skriva meddelandena då? Nej, det kan de inte, för alla meddelanden är kryptografiskt signerade, så det är garanterat rsync.net som har skrivit dem. Och de har garanterat skrivit dem dagen de släpps. Och om de inte släpps så har de råkat ut för problem med polisen.

Enda sättet för polisen att dölja en razzia är om de fysiskt tvingar rsync.net-folket att skriva ett nytt meddelande och ljuga i det, men det kräver ganska mycket mer.

Länk till rsyncs meddelande.

[kqrx]

Erlang

Erlang är ett prorammeringsspråk som har gnagt lite i mitt bakhuvud i några år nu. Det är ett språk som jag vet att jag borde vara bekant med av flera anledningar, men som jag aldrig riktigt har tagit tag i. Rent objektivt, om man frågade mig vad för sorts språk jag tycker om, så skulle man se att Erlang egentligen är ett språk som jag inte tycker om. Men det går inte att förneka att det är ett språk som är värt respekt.

jag började läsa lite Erlang på skoj tidigare i dag, och fastnade något. Nu stötte jag på en passage i texten som jag inte kan undvika att skriva om. Detta är en grov översättning av mig.

Som sådana brukar statiskt typade språk ses som mycket säkrare än de dynamiskt typade. Det kan mycket väl stämma om man jämför med de flesta dynamiska språk, men Erlang håller inte med, och Erlang har definitivt stöd för sin åsikt.

Erlang uppfanns av svenska telekom-företaget Ericsson under 80-talet. När man sysslar med telekom (säljer telefonväxlar och sånt) måste man kunna garantera i princip 100% uptime. Det innebär att alla system måste vara fullt fungerande dygnet runt, alla dagar om året. Om du ska ringa ett jätteviktigt samtal så vill du inte höra att det inte går att ringa för att någon server har kraschat. Det är otänkbart.

Ericsson hade mycket erfarenhet av telekom redan när de gav sig in på att uppfinna Erlang, så de hade koll på en hel del om det här med att hantera fel som uppstår på vägen. En av deras grundtankar när de designade Erlang var att, "Det kommer alltid att uppstå fel. Hur ska vi göra så att de påverkar så lite som möjligt?"

Erlang är byggt för att överleva, för att program aldrig ska krascha. Och de gör inte det heller. Det finns Erlang-baserade system med miljontals kodrader som utlovar 99.9999999% tillgänglighet. Du fattar förmodligen inte hur sjukt mycket det är, men det är helt otroligt i alla fall. Det är samma sak som att på trettiotvå år får systemet vara otillgängligt en enda sekund.

Märk väl att den tillgängligheten som utlovas inkluderar planerade uppdateringar, nätverksfel, hårdvarukraschar och liknande. Alla sorts otillgängligheter ska rymmas under en sekund var trettioandra år. Det är vad Erlang kan utlova.

Författaren skojar inte när hen skriver att Erlang har stöd för sin åsikt om feltoleranta system. Tvärt om, meningen blev nästan till en underdrift med komisk effekt. Om Erlang väljer att uttala sig om feltolerans så ska man banne mig lyssna.

(För övrigt är Erlang ett väldigt mysigt språk. Jag borde inte tycka om det men jag känner någon slags mystisk attraktion till det ändå.)

[kqrx]

Feltolerans i Erlang

Tänk dig att du jobbar som programmerare för en bank. En dag kallar din chef in dig och dina kollegor till möte, och ni får veta att ni ska skriva programvara för bankens servrar. Det viktigaste kravet chefen har är att programvaran får aldrig sluta fungera. Med de orden lämnar chefen rummet.

Du och dina kolleger börjar genast diskutera. Vad menade han med att den aldrig får sluta fungera? Måste den vara tillgänglig 98% av tiden? 99.9% av tiden?

Ni blir inte kloka så du sticker ut huvudet ur konferensrummet och ropar på chefen som är på väg bort, "Hur stor tillgänglighet menar du?"

Chefen svarar, utan att vända sig om, "Sikta på 100%. Jag kan acceptera 99.9994% om ni inte lyckas med mer."

Du och dina kollegor är konfunderade över hur ni ska lösa det problemet. Hur får man ett program som har så hög tillgänglighet? Kim föreslår, "Vi kan vara snabba på att rätta till buggar när de dyker upp. Vi hoppas att de inte blir så många eller svåra, så lägger vi ut patchar hela tiden som fixar de som finns."

Du tycker att det låter som en tveksam idé. Kim har en bakgrund som projektledare och är van vid att handskas med människor, så hen föreslår en lösning som handlar om att hantera människors jobb. Men kommer vi att kunna fixa buggarna så snabbt?

Alex har en annan idé. Hen tycker att det är för sent om en bugg dyker upp. Då har ni redan tappat värdefull tid. Alex tänker, "Om vi är riktigt noga och ser till att skriva felfri mjukvara, så slipper vi problemet med buggar helt."

Kim ändrar sig och tycker bättre om Alex idé. Du är fortfarande tveksam. Du har erfarenhet av programmering och du vet att du aldrig har lyckats skriva ett program som är buggfritt. Det går inte. Alex idé är fin i tanken men funkar inte.

Så hur gör man?

När man programmerar i Erlang har man en speciell approach mot att hantera fel. Erlang-programmerare brukar säga, "Låt den krascha."

Det är just vad man gör i Erlang. Man koncentrerar sig på de fall där programmet ska fungera, och för alla andra fall låter man programmet krascha. På det sättet kan man behålla fokus på det viktiga, vad programmet gör, istället för att lägga en massa tid på sånt som programmet ändå inte är tänkt att göra. Det är jätteskönt att programmera på det sättet.

Det kan låta motsägelsefullt till en början, att ett program med hög tillgänglighet ska få krascha. När man jobbar med Erlang hanterar man det genom att dela upp programmet i flera processer, som håller koll på varandra. Om en process har kraschat så meddelar den sig till en annan process som har som uppgift att starta om den kraschade.

Alex' förslag och Erlang-metoden illustrerar en viktig skillnad mellan två ord: Felfri och feltolerant.

Ett felfritt (eller ibland felsäkert) program är ett program som inte har några fel. Vi vet att såna inte existerar. Att säga att ett program är felfritt är bara fånigt. Det går inte att bevisa att ett program är felfritt.

Ett feltolerant program däremot kan ha hur många fel som helst, men det klarar av att hantera de flesta, och låtsas som om de aldrig har hänt.

Skriv feltoleranta program, inte felsäkra sådana.

[kqrx]

The first step is fully admitting that the code you write is riddled with errors.

John Carmack (Static Code Analysis, 24 dec 2011)