Lyst til å lese mer? Få fri tilgang for kun 235,- i måneden.
Bli Ekstra-abonnent »
Natt til den 15. september hadde Finn.no for første gang på flere år en planlagt nedetid. Den varte i underkant av fem timer. I løpet av denne tiden ble nettmarkedets rundt 850 mikrotjenester flyttet til en helt ny infrastruktur i nettskyen. Da Finn.no ble gjort tilgjengelig igjen etter flyttingen, fungerte det aller meste som før. Samtidig har selskapet fått helt nye tekniske muligheter.
Finn.no har i stor grad blitt kjørt fra det samme datarommet i Oslo de siste 20 årene. Dette forteller Morten Hanshaugen til Digi.no. Han leder infrastrukturavdelingen i Finn.no og er den som i begynnelsen av 2019 tok initiativ til flyttingen.
– Enkelte tror kanskje at Finn bare er en enkel plass med bare to-tre ansatte og en enkel webside, men det er ganske komplekst, sier han. Av selskapets 450 ansatte, jobber rundt 180 på teknologisiden, hvorav mer enn 130 er utviklere.
Mikrotjenester og Kubernetes
Selskapet har de drøyt fem siste årene jobbet mye med hvordan plattformen utvikles, samt hvordan ny kode kan testes, rulles ut og produksjonsettes på trygg og rask måte, uten at utviklerne går i beina på hverandre.
– I denne prosessen har vi innført mikrotjenester, Kubernetes og veldig mye annet. Men vi så at den infrastruktur som skal til for å kjøre et slikt mikrotjenestemiljø, bør se litt annerledes ut enn en typisk trelagsmodell, forteller Hanshaugen. Mikrotjenestene kjøres på noen hundre fysiske og virtuelle server.
– Det utfordrende for oss, var å tilpasse det eksisterende miljøet. Det ble derfor fristende å se om vi kunne finne en leverandør eller et tilbud som er spesialisert for å kjøre denne typen tjenester, fortsetter han.
– Vi har gått fra en situasjon hvor vi hadde ganske mye virtuelle maskiner, hvor det er en slags treghet i hvordan ting kan gjøres når du skal «release», sammenlignet med den mye kjappere itereringen i en Kybernetes-verdenen. De siste årene har vi sakte, men sikkert skalert ned antallet virtuelle maskiner en del, og så har vi skalert opp Kubernetes-delen, slik at den har blitt dominerende, forteller Hanshaugen.
Hengende etter utviklingen i den offentlige skyen
I praksis har datarommet vært en delvis privat sky basert på Openstack, med mulighet til å skalere opp eller ned ved behov. Hanshaugen forteller at selskapet også hadde brukbare metoder og systemer for også for lagring og databaser.
– Vi var et stykke framme allerede i vårt lokale datarom, men vi så at avstanden til det som tilbys i den offentlige skyen blir stadig større. Det ble et stadig større behov for oss å ta del i den utviklingen, uten å måtte drive den selv. Når du driver ditt eget datarom, er du veldig prisgitt dine egne behov og hva som finnes av løsninger. Vi tror at de løsningene som flere enn oss driver fram, fører til bedre løsninger for oss, samt tilgang på god teknologi å bruke, sier Hanshaugen.
Ville opprettholde utviklingstakten
Nicolai Høge er teknologidirektør (CTO) i Finn.no og har ansvaret for teknologien i selskapet.
– I miljøet vårt er kontinuerlig utvikling og kontinuerlig utrulling er ekstremt viktig. Det har vi drevet med siden 2012. Allerede før vi gikk til Kubernetes, hadde vi fått opp farten på dette. I dag ligger vi på mellom 1500 og 2000 deployeringer til produksjon i uken. Det er et tall som vi har vært opptatt av at skulle holde seg minst like bra både under prosjektet og etter at vi har kommet ut i skyen, forteller Høge.
– Finn er jo et vekstselskap, og i de siste årene har trafikken vokst med 10 prosent i året. Vi hadde gjort mye på administrasjonslaget over den fysiske maskinvaren, men i januar 2019 sa Morten at det er på tide å tenke nytt, å slippe å forholde oss til den fysiske infrastrukturen på den samme måten, og å få noen til å ta ansvar for å levere det vi trenger av en plattform. Så ble vi enige på teknologisiden at vi skulle gå for en skyløsning, fortsetter han.
Fant ingen i Norge
Finn.no brukte det meste av våren 2019 på å velge en leverandør, etter først å ha fastsatt hvordan et slik valg skulle gjøres.
– Vi gjorde først en undersøkelse her i Norge av tre-fire lokale tilbydere av datarom. Det vi ser, er at fokuset deres ikke er på «managed» Kubernetes, som var det viktigste punktet for oss. Så vi måtte ut av landet og til de store, internasjonale aktørene for i det hele tatt å finne dette som et tilbud. Det viktigste elementet for oss i infrastrukturen, er en god Kubernetes. Så kommer det andre etterpå. Vi evaluerte fire av de internasjonale skyleverandørene. Basert på erfaringene våre med den første runden med de lokale leverandørene, tenkte vi at det hadde mest for seg å se på de største først, forteller Hanshaugen.
– I alle fall på dette tidspunktet, og antagelig fortsatt, ligger Google Cloud Platform (GCP) med deres GKE (Google Kubernetes Engine, journ. anm) flere år foran når det gjelder både funksjonalitet, stabilitet og mulighet for debugging. For oss er muligheten til å finne ut av feil og å få rettet dem fort, helt avgjørende, fortsetter han, før Høge overtar.
Måtte gi opp de opprinnelige planene
– Vi hadde i utgangspunktet en plan som skulle gi null nedetid. Vi hadde veldig gode KPI-er (Key Performance Index, journ. anm), som jevnlig ble fulgt opp, så vi kunne se hvor mange av tjenestene våre som var klare for å flytte, hvilke utfordringer som gjensto og hva som var farten vår på dette. Så kom korona. Da måtte vi slippe litt fokus på skyflytting og i stedet fokusere på å håndtere økt trafikk. Finn popularitet økte veldig etter utbruddet, så Morten måtte konsentrere seg om å holde ting flytende framfor å se framover. Dette ga fort utslag på skyflyttings-KPI-ene, og det viste seg at vi hang etter skjemaet. Vi så at vi ikke kom til å rekke å gjennomføre på den måten vi hadde tenkt til den datoen vi hadde som mål. Da tok Morten et nytt blikk på planene sine, forteller Høge.
I Finn.no var det på denne tiden blitt lagd det Hanshaugen kaller for en «hybrid cloud»-plattform. Denne ble brukt for å binde sammen datarommet og GCP, slik at teknologene i Finn.no stadig kunne flytte applikasjoner én og én over i GCP, uten at dette påvirket Finn.no på noen måte.
– Det var en litt omfattende jobb å gjøre. Den var teknisk komplisert, og det viste seg at den krever at alt du har av operativsystemer og slikt i det gamle datasenteret, er oppdatert. Hvilket du ikke har lenger, dersom du har drevet på i halvannet år med å forberede å flytte til skyen. For da har du måttet prioritere flyttingen, sier Hanshaugen.
Økt risiko
– Vi måtte egentlig bare «kill your darlings» og avslutte hele dette arbeidet. Vi bestemte oss for at forretningen i Finn måtte ta høyere risiko. Da kom vi opp med en plan om hvordan flytte alt som var nødvendig å flytte – ikke alt i Finn, men ganske mye av det – i løpet av én natt. Denne planen leverte vi til ledergruppen i Finn, for å se om vi kunne få dem til å bli enige om å ta denne risikoen, fortsetter han, før han overlater ordet til Høge.
– Det betydde økt risiko og faktisk nedetid på Finn. Det er et par år siden sist vi bevisst hadde nedetid. Det innebar også mer koordinert og intenst arbeid, hvor mange flere måtte jobbe samtidig mot et felles mål. Dette fikk vi støtte for i ledergruppa i Finn, og prioritet til å gjøre det. Men da ble det tydelig at det nå ville bli mye mer koordinering, mange flere bevegelige biter og mange flere som måtte involveres på tvers av organisasjonen, forteller Høge.
Det store bildet
Derfor fikk Bente Ulvestad, utviklingsdirektør i Finn.no med ansvar for plattform, i oppgave å se på det store bildet.
Hun forteller at beslutningen om å ta alt på én natt, ble tatt i juni, rett før folk gikk i sommerferie.
– Vi bestemte oss for å være ganske ambisiøse, og satte datoen til 15. september, rett og slett for at vi ikke skulle bruke hele høsten på dette. Så tok vi ferie og skulle tenke videre på dette i august, sier Ulvestad.
– Selv hadde jeg ikke vært så veldig tett på skymigrering tidligere, så da august kom og Nicolai spurte om jeg kunne få det totale oversiktsbildet over dette, fikk jeg litt angst. Det var omtrent fire uker før den 15. september, og det var ikke mye tid igjen til å skalere opp en hel organisasjon, som også kom hjem fra ferie. Det var mange teams som hadde fått beskjeden før ferien, men som ikke helt visste hva det innebar for oss, forteller hun.
Etablerte en kjernegruppe
– Jeg sa da til Nicolai at vi trengte en kjernegruppe og å fordele ansvar. I gruppen hadde vi én person med eget ansvar for risiko, som tok rede på hva folk var redde for at kunne gå galt. Vi hadde også en teknisk koordinator som en del av enterprise-arkitekturgruppa vår. Han var i kontakt med veldig mange av de tekniske lederne rundt omkring, for å gå ned i detaljene på ting de satt med. Morten var selvfølgelig med, siden han jobbet med dette prosjektet i lang tid og hadde all den innsikten vi trengte å lene oss på, sier Ulvestad.
– Dessuten hadde vi en egen kommunikasjonsansvarlig som tok seg av intern kommunikasjon med andre avdelinger i Finn, som kundesenter og salgsavdeling, samt med eksterne partnere. For det var ikke bare vi som måtte forberede oss til dette. Vi har ganske mange eksterne partnere, slik som tredjepartsleverandører og de som importerer annonsene sine via importsystemer. Så de måtte få beskjed om at det skulle skje noe stort som de antagelig måtte ta hensyn til, forklarer hun.
Innretting av 40 teams
Ulvestad mener at kjernegruppen var avgjørende for å klare å komme i mål.
– Det var plutselig 40 teams som skulle rettes inn mot en dato som ikke var så langt unna, og mange var usikre på hva de egentlig skulle gjøre. Så dette var det viktigste å få på plass den første uka, slik at vi kom i gang. Vi fant på et system basert på trafikklys, der alle teamene sa om de var røde, gule eller grønne for å kunne nå denne datoen. Da fikk vi veldig mye opp på bordet veldig fort. Risikoanalysen vår viste dessuten at det var en del ting vi måtte ta tak i, forteller hun.
– Men vi fikk jobbet oss ganske effektivt og konkret gjennom mye, og det å ha den tette dialogen med teamene hele veien, gjorde at vi fikk en ganske god følelse. Allerede uken før vi skulle over, fikk vi grønne lys fra alle teamene, som sa at dette skal vi klare. Det har vært utrolig gøy å sitte og se på den progresjonen hvert enkelt team hadde, fra å være veldig usikre på starten, til å ha ganske god oversikt på hva vi skulle gjøre, forteller Ulvestad.
Selv om selve flyttejobben den natten ble gjort på bare 4 timer og 43 minutter, var det på forhånd blitt gjort mye forberedelser, inkludert øving på det som faktisk skulle gjøres. I tillegg ble det sørget for at dataene var tilgjengelige i skyen før flyttingen av mikrotjenestene faktisk skjedde.
Strakk klyngene over til skyen
– Som nevnt holdt vi på i noen måneder med å lage en hybrid sky, altså en plattform for å kunne samkjøre to innsider av Kubernetes-klynger som egentlig ikke kunne se hverandres innsider. Det var teknisk komplekst. Det vi da bestemte oss for, er at det er lettere å strekke tradisjonelle klynger over til skyen, forteller Hanshaugen.
– Vi brukte arbeidsmåter som vi er vant til. Når vi skal ta en databaseklynge og gjøre den litt større, så melder vi inn noen større noder, venter til disse har fått en kopi av dataene sine, og så melder vi ut de gamle. Vi brukte samme metode for å flytte oss selv til skyen. Vi meldte inn noen ekstra noder i alle klyngene våre, men nå sto disse ekstra nodene i GPC. Så sørget vi for at alle dataene våre var føderert over til GCP allerede den dagen vi skulle flytte. Flytteprosessen ble da i grunnen bare å flytte pekeren for hvilken node som var primærnoden i alle klyngene våre. Dette gjorde vi for PostgreSQL, Sybase, Kafka og andre teknologier som vi bruker internt. Dette er i seg selv en mye enklere metode enn å lage det nevnte hybridrammeverket, som egentlig inkluderer Linux-kjerner og andre lavnivå operasjoner, forklarer han.
Har masse data andre steder
Nå er det ikke slik at det var alle deler av Finn.no som skulle flyttes denne natten. Finn.no har en «policloud»-strategi som sier at de skal bruke den skyleverandøren som er best til å svare på de forskjelligebehovene de har, og deler av Finn.no har derfor vært skybasert i lang tid allerede.
– Google Cloud er uten tvil best på Kybernetes med GKE. Datavarehuset vårt fortsetter vi å kjøre i Amazons Redshift. Det er en løsning vi er fornøyde med, og vi ser ikke noe behov for å flytte den bare for å flytte den. Bildene våre ligger et tredje sted. Det er likevel de 850 mikrotjenestene, men tilhørende databaser, som utgjør mesteparten av Finn. Dette kjøres hos Google i dag. I tillegg var mye at maskinlæringen og trackingen vår allerede i Googles nettsky, forteller Høge.
Når Digi.no spør hvor mye data Finn.no består av totalt, sier Høge at dette ikke er så lett å svare på, siden arkitekturen er så distribuert og dataene fordelt hos flere leverandører.
– Den natten flyttet vi 16 terabyte med data. Vi flyttet også 185 databaser og et tilsvarende antall virtuelle maskiner, men veldig mye av dataene til Finn trengte ikke å flytte, sier Hanshaugen.
– Vi flyttet også mange hundre DNS-oppføringer den natten. Dette var én av de mer spennende delene. De puslespillbitene som flyttes, skal helst ligge omtrent likt i forhold til hverandre, også etter at du har flyttet puslespillet, fortsetter han.
Litt svett stemning
Det er Ulvestad som svarer på vårt spørsmål om det var noe som ikke gikk helt som det skulle i løpet av timene flyttingen pågikk. Hun nevner ett tilfelle.
– Vi opplevde at noe kode som var blitt sjekket inn en ukes tid før, ikke var blitt synkronisert riktig, slik at vi ikke hadde fått med oss alt ut. Det var litt svett stemning da vi måtte finne og fikse akkurat dette. Vi brukte bare rundt en halvtime på det, men vi hadde kanskje vært tidligere ferdig om det ikke hadde skjedd, sier hun.
Planlagt på kommandonivå
De tre er tydelige på at planlegging og øvrig var sentralt i suksessen.
– Det vi gjorde, var å lage noe som heter en «runbook». Vi hadde da et dokument som vi hadde lagd og innøvd. Dette dokumentet inneholdt hva som skulle gjøres, kommando for kommando, for å flytte over alle de forskjellige delene av Finn. Det inneholdt også pekere til dashboards – websider med grafer som forteller hvordan ulike ting oppfører seg, og om de har det bra eller ei. Med dette kunne vi både raskt gjøre det som skulle gjøres, og raskt sjekke konsekvensen av det vi gjorde, for deretter å kunne krysse av om vi kunne gå videre til neste punkt, forteller Hanshaugen.
Alle kunne følge med, steg for steg
Ulvestad forteller at det var tatt i brukt et nummersystem à la versjonsnummer i kapittelinndelingen i dokumentet, slik at man kunne snakke om steg «1.3» eller «3.2».
– Hele veien ble det kommunisert hvilket steg vi var på, og da kunne alle som var på vakt den natten vite akkurat hvor vi var. For hvert av hovedstegene hadde vi dessuten gitt «best case»- og «worst case»-estimater. Disse hadde vi satt inn i en tidstabell hvor vi hadde regnet ut når vi skulle begynne på hvert enkelt steg. Da kunne vi hele tiden følge med på om vi lå bra eller dårlig an for å komme opp igjen på morgenkvisten, noe som var målet vårt, forteller Ulvestad.
– Det var mange som satt og var spente og ivrige på å kunne testene tingene sine. Da kunne vi si at de måtte vente så så lenge før de kunne gjøre dette. En tidslinje som viser at du ligger ganske bra an, gjør at pulsen senker underveis. Og det gikk utrolig bra, fortsetter hun.
Stoppet utrullingen av ny kode
Ett av målene for flyttingen, var at den skulle påvirke videreutviklingen av tjenesten så lite som mulig.
– Da vi begynte å nærme oss flyttedatoen, lurte vi på om vi burde ha en «kodefrys» av en kjent tilstand, som vi kunne stoppe, dytte over i skyen og fyre opp igjen. Så ble vi enige om en myk form for kodefrys i 24 timer før vi skiftet over. Ved midnatt døgnet før vi byttet, sa vi at det fra nå av bare er ting som har med migreringen å gjøre, som får lov til å produksjonssettes. Så skiftet vi til skyen, og deretter gikk det 10-12 timer før utviklerne igjen kunne starte å produksjonssette. Dette hadde minimalt med innvirkning på både utviklingen av nye ting og businessen, forteller Høge.
– Selve byttet gikk bra, og ytelsen i ettertid er stort sett bra. Det dukker opp noen småting knyttet til ytelse eller andre ting, men det er såpass lite at det at vi kan fikse det raskt underveis. Allerede fra den morgenen kjører Finn fra første stund vellykket i skyen hos Google. Selv om det går litt opp og ned, går det ytelsesmessig minst like bra som før. Det er litt annerledes å kjøre i skyen fra Finland enn å kjøre fra fysiske maskiner i Oslo, så det er noe vi må gjøre oss litt mer kjent med. Vi har helt andre muligheter nå til skalering og nye måter å jobbe på, og til å designe arkitekturen i Finn på, fortsetter han.
Kunne fjerne flaskehalser
Hanshaugen utdyper litt om dette med ytelse og kapasitet.
– Da vi flyttet over, fjernet vi bevisst et par flaskehalser i infrastrukturen vår. Tidligere begrenset disse trafikken mot Finn når trafikken var som høyest. Nå slipper vi derimot all trafikken gjennom. Dette avdekker jo ytelsesutfordringer andre steder i systemet. Det å sørge for at vi kan håndtere alle typer trafikk uten struping, er ting vi har måttet jobbe med de siste par ukene. I det datarommet vi var, hadde vi ikke muligheten til å gjøre noe med dette, forteller Hanshaugen.
Den første store prøven etter at flyttingen var gjort, skjedde bare noen dager senere. Også det gikk smertefritt.
– Vi har en vaktordning som går når de andre har fri, og vi var veldig spente på søndagen etter flyttingen, for i nitiden på søndagskveldene er det tidspunktet i uka når vi har mest trafikk. Hun som hadde vakt da, meldte at det utrolig nok ikke var noe som skjedde, og at det var nesten kjedelig stille, forteller Ulvestad.
Felles løft fra hjemmekontorene
– Det skal sies at som prosjekt, så var dette et ganske så tøft mål å sette rett før sommeren. Vi hadde jobbet med det i halvannet år, og plutselig sa vi «OK, om en måneds tid skal dette gjøres». Jeg tror det ga et veldig stort fellesløft for organisasjonen i disse tider, hvor vi sammen skulle sørge for at alle teamene kom i mål, sier Høge.
– I praksis er det ingen som har sittet i samme rom underveis her, og vi valgte bevisst å sitte distribuert også denne natten. Det har vært hundre prosent hjemmekontor i Finn i hele koronaperioden, forteller han.
Hanshaugen forteller at under natten til den 15. september deltok alle hans folk i en felles videokonferanse, for lett å kunne snakke om det som skjedde.
– Resten av Finn holdt bare kontakt via en egen Slack-kanal for skyflytting, hvor også vi deltok. Det er lettere å være på flere Slack-kanaler samtidig enn å delta i flere samtidige videokonferanser. Det ville bare ha blitt rot, mener Hanshaugen.
Noen måtte sove
Ulvestad forteller at Finn valgte å behandle gjennomføringen av flyttingen på omtrent samme måte som selskapet gjør med «insidents».
– Vi har et veldig strukturert system for å håndtere hendelser, med forskjellige dedikerte roller og ansvar. Vi var også her veldig tydelige på hvem som skulle gjøre hva, og hvem man skulle høre på. Det at vi også hadde et system for behandlingen av en type kritiske situasjoner underveis, hjalp oss nok mye, sier Ulvestad.
Inkludert i dette er også spørsmålet om hvem som skal være våkne, og ikke minst hvem som skulle sove, slik at de kunne være våkne dersom noe gikk galt.
– Dette var egentlig utfordrende, for alle var jo i supergira på å bidra til at dette skulle gå bra. Men noen må faktisk gå og legge seg, for dersom det ikke hadde gått bra, måtte vi ha rullet forover en gang til, til det gamle datarommet. Det hadde vi en eksplisitt plan for, i tilfellet vi så at vi ikke kom til å greie dette. Vi kunne ikke bare skru av Finn dagen etter, sier Hanshaugen.
– Dette betydde at vi måtte ha noen friske hoder tilgjengelige på morgenkvisten. Det gikk bra, men det var ikke så lett å overtale enkelte til å legge seg og sove, forteller han.
Vitamininnsprøytning
Ulvestad mener at flyttingen var en vitamininnsprøytning for veldig mange i selskapet.
– Det var mange som var litt skeptiske til 15. september, da dette ble kommunisert i august. Men det å se at folk bare bretter opp ermene og setter i gang på denne måten som Finn er gode på, når vi løfter i flokk, det tror jeg var kjærkomment akkurat nå under koronapandemien. Jeg tror mange kjente på at dette var noe de trengte, nå som høsten kommer og vi fortsatt skal være på hjemmekontoret, sier hun.
Hanshaugen legger til at han tror veldig mange i teknologiavdelingen i Finn kjenner hverandre mye bedre nå, enn de gjorde tidligere.
Stolt teknologidirektør
– Jeg er stolt av at vi fikk det til teknisk. Men jeg er også stolt av at vi klarte å holde løftene til selskapet om å minimere påvirkningen på brukere og kunder. Det var av og til at vi måtte ta noen vanskelige valg, og å gå en ekstra mile for at kundene våre skulle oppleve dette så smud som mulig. Det ble riktignok 4-5 timer nedetid, men det var egentlig uunngåelig, sier Høge.
– Suksessfaktoren har vært å planlegge godt og å være villige til å endre på planene når ting endrer seg, slik vi måtte gjøre ved et par viktige punkter underveis her, avslutter han.
Google er selvfølgelig fornøyde med at Finn.no har valgt Google Cloud Platform.
– Vi i Google Cloud er stolte over at Finn.no har valgt oss som deres skyplattform for å sikre vekst og skalering i fremtiden. Sammen har vi skapt et partnerskap for innovasjon og et fundament for en tjeneste som enkelt kan skaleres for millioner av brukere hver eneste uke. Finn.no har et av Nordens ledende kompetansemiljøer innen både drift og utvikling av mikrotjenester, og vi ser frem til å være en del av reisen videre, sier Eva Fors, nordeuropeisk sjef for Googles Cloud-enhet, i en uttalelse.
Kommentarer (0)