uber

Fire lektioner fra Uber

Steffen Grarup og Kåre Kjelstrøm, hhv. Senior Engineering Manager og Senior Software Engineer hos Uber, forklarer hvordan det er at arbejde i en verden, hvor ny software bliver udrullet i løbet af dage, hvor systemet aldrig går ned og hvor fejl bliver rettet, mens det kører. En flerstrenget strategi, som fx sundhedsvæsenet kan lære noget af.

Der er masser af data og algoritmer involveret, når køredelingstjenesten Uber koordinerer mere end én million rejsende i mere end 50 lande og 200 byer. Processen hedder agil drift og er kendetegnende for “bleeding-edge”-firmaer som Uber og Twitter. Når Netflix eksempelvis går ned, så giver det et kort glimt på skærmen og kører derefter videre. Man lægger ikke mærke til det. Det samme gælder for Uber. Systemet kører 24/7, 365 dage om året.

1. Udnyt data-flowet og de historiske data

Ifølge Steffen Grarup ligger den gennemsnitlige ankomsttid på fire minutter og prisen 20-40 procent under gennemsnittet.

– Vi bygger i praksis en “realtime on-demand logistik” platform. Vi har over en million connected devices fordelt på 50 lande. Nytårsnat kl. 12 sad der eksempelvis over 100.000 kunder i en Uber-bil verden over. Det giver rigtig meget dataflow, forklarer Steffen Grarup.

Det giver også et virkelig interessant evalueringsproblem, når man skal finde den nærmeste bil i realtid. Hvis en GPS bare plotter bilen ind på et kort, så er det ikke ret pænt, da det kan se ud som om at bilen kører ind i et hus.

En anden udfordring er, at man skal gætte, hvordan bilen kommer til at holde tæt på kunderne. Her får chaufførerne et kort, der bygger på, hvor kunderne historisk har været.

– Så der sker en masse beregninger, hvor vi arbejder med de her historiske data for at møde efterspørgslen. Fordi jo større efterspørgsel des mere stiger prisen, forklarer han.

2. Lav softwaren simpel og del den op i små bidder

Hvad gør man, når man ikke kan slukke systemet? Der er altid trafik og aldrig et godt tidspunkt. Heller ikke kl. fire om morgenen. Det giver nogle helt andre designprincipper og meget korte deadlines.

– Det betyder, at vi udvikler og sætter i produktion hele tiden. Det gør, at man skal tænke på en helt ny måde. Man er nødt til at dele nye features og ny kode op i små bidder. Det betyder, at vi foretrækker at lave ændringer i softwaren, så simpel som mulig. Det er en forandring at arbejde på den her måde. Men det er også befriende at vide, at softwaren bliver brugt.

En af principperne hos Uber hedder: “You built it – you drive it”. Det betyder, at hvert team har end-to-end ansvar for en ny komponent, fra design til udvikling til test til drift.

– Den skal man lige sluge, når man starter hos Uber, fordi det betyder, at man ikke bare smider noget kode over en mur og går hjem og holder weekend. Det betyder, at jeg har sovet mindre i 2014, end jeg har gjort i mange år. Men det betyder også, at tingene fungerer meget hurtigt. På en halv dag kan man sætte kode i produktion, og det er en fornøjelse.

3. Gå ud fra at tingene går galt

En anden ting er, at de hos Uber antager, at alting fejler. Folk laver fejl og servere går ned. Der sker overraskende fejl, og det betyder, at man skal designe efter det. På afdelingen i Aarhus har man for eksempel syv store skærme, der monitorerer, laver statistik og grafer.

– Hvis tingene afviger fra et kendt mønster, kommer der en alarm. Hvis alle brugerne forsvinder i Sverige, er det nok fordi at en mobil operatør er gået ned. Det vigtigste er, at kunderne kommer frem, så hvis der er noget, der er galt, har vi et backend-system, som vi manuelt kan gå ind og tjekke og fejlrette efterfølgende, forklarer Steffen Grarup.

4. Kort tid fra idé til realisering

Der kommer mange idéer til nye features – både fra brugere, chauffører og udviklere. Der arbejder omkring 400 udviklere globalt, og ofte er der ikke mere end ti udviklere per komponent. Simpelthen, fordi det er hurtigere med færre. Hvis man har en idé, laver man bare et kort dokument på det, og så kommer det altid tilbage med mange kommentarer.

Det kan være svært for en GPS at finde ud af om afgangsterminalen i en lufthavn ligger på første eller anden etage. Derfor har de fx lavet en feature, der hjælper med at finde vej, baseret på metadata, der beskriver den specifikke lufthavn.

– Vi har masser af problemer, som skal ud i morgen. Derfor bygger vi tingene, så de kan skaleres op med det samme. Det kan godt være en udfordring, når vi har tusindvis af servere. Derfor var noget af det første, vi lavede, da vi startede op i Aarhus, et system, der kan udrulle softwaren på alle servere. Det gør det nemt at håndtere store mængder data på tværs af servere, og det gør det uhyggelig nemt at tilføje ændringer.

Læs mere