DevOps i DR: »Man skal erkende, at man ikke kan bruge et år på at teste et værktøj«

Der er brug for fleksibilitet i alle lag, når it-ansatte bag Danmarks største hjemmeside skal arbejde efter DevOps-principper.

I 2018 forventer DR op til 19 millioner requests i minuttet på Danmarks største hjemmeside, dr.dk.

De danske medieforbrugere er hastigt i gang med at skifte analoge kanaler ud med digitale platforme. Og det kræver hurtige og hyppige iterationer at følge med behovet.

»Vi har typisk omkring 50 deployments om ugen på de her produkter,« indleder Mikkel Müller, der er underdirektør i DR Teknologi og medievirksomhedens CIO.

»Det giver en rigtig god case for automatisering og DevOps.«

Læs også: DevOps-ekspert: Udviklere bliver bedre, hvis de selv skal lide under dårlig kode

Beslutningen om at indføre DevOps i mediehuset er stadig ny. I november blev afdelingen skabt med to ansatte. Nu tæller DevOps-holdet fire medarbejdere, og DR rekrutterer stadig.

»Det kræver mange ressourcer at få en automatiseret pipeline op, og det skal man ikke undervurdere. Det har været en udfordring, men vi er kommet godt på vej.«

Oprindeligt forsøgte DR Teknologi at give DevOps rollen til infrastruktur-afdelingen, »men det kom aldrig rigtig i gang«, forklarer Mikkel Müller.

»Vi tog beslutningen om at lave et nyt dedikeret team, fordi vi fandt ud af, at du ikke kan gøre det her samtidig med, at du skal alt muligt andet.«

Kulturbærende

Målet har fra starten været at lave en pipeline, som giver udviklere en effektiv proces hele vejen fra build og test over deployment til drift. Og at sprede en kultur, hvor alle har ansvar for, at hjemmeside, app, streaming, podcast med videre fungerer.

»Traditionelt havde vi udviklingsteams, der gennemførte projekter og udviklede features, hvorefter de blev driftet af driftsafdelingen. Det giver nogle udfordringer, fordi man lever i forskellige verdener i drift og udvikling,« fortæller Mikkel Müller.

Læs også: Agilefall og watergile: Virksomheder går i stå i vadestedet på vej mod agil

»Vi vil gerne have en kultur, hvor alle er fælles om at have fokus på brugeroplevelsen i det digitale produkt. Det kræver, at udviklere også tager ansvar for performance og loadtider og ikke sender det videre til en driftsafdeling.«

Tilgangen kræver en høj grad af samarbejde. Og det kræver, at man kommer væk fra de traditionelle it-siloer, siger Mikkel Müller.

»Der vil altid være snitflader, men infrastruktur, devops og udviklere skal tænke på helheden og respektere hinanden.«

Værktøjer skal kunne smides væk

Til formålet har DevOps-teamet indført en række standardværktøjer, der skal understøtte blandt andet automatisering. De er valgt i tæt samarbejde med de udviklere, der skal bruge dem, understreger Mikkel Müller.

»Vi skal udnytte det pull, der er fra udviklerne, som også sagtens kan se gevinsten i automatiserede tests og continuous deployment,« siger han og fortsætter:

»Frem for at indføre værktøjer top down og trække værktøjer og processer ned over hovedet på udviklerne, så giver man dem de værktøjer, de efterspørger.«

Læs også: Amazons DevOps-strategi: Udviklingshold skal kunne mættes med to pizzaer

Fra DevOps-afdelingen har man lagt vægt på, at det skal være standardværktøjer, der nemt kan skiftes ud, så udviklere hele tiden bruger det rette værktøj til den rette opgave.

»Man skal erkende i den her verden, at man ikke skal bruge et år på at evaluere, om et værktøj er det rigtige. Så er det bedre at prøve noget af og gå på kompromis med den helt specielle funktionalitet, for om et år har du alligevel brug for nogle nye funktioner, fordi behovene har ændret sig, eller værktøjerne har udviklet sig i andre retninger,« forklarer Mikkel Müller.

Skyen først

I det hele taget er fleksibilitet nøglen i DR’s DevOps-strategi. Af samme grund forventer Mikkel Müller, at holdet kommer til at bruge Docker rigtig meget.

»Det er et skridt i retning af, at man gør udviklere bedre i stand til at tage ansvaret, fordi man får færre bindinger mod servermiljøet og samtidig udnytter ressourcer mere effektivt,« siger Mikkel Müller og tiløjer:

»Vi vil ikke have et DevOps-hold, der bliver som en infrastrukturafdeling bare for AWS-tjenester.«

Dr.dk nåede i november sidste år op på over tre millioner unikke brugere og er set over sidste år Danmarks største hjemmeside målt på brugere og sidevisninger, viser tal fra Danske Medier. Fordi kapacitetsbehovet svinger meget, er store dele af dr.dk på vej i skyen.

Læs også: Rekord: 406.000 brugere streamede nytårs-tv fra DR under Yousee-nedbrud

»Hvis der er valg, en EM-finale eller noget andet stort, kan vi have ekstremt mange brugere i forhold til en almindelig eftermiddag. Der giver det mening med et setup, hvor man kan skalere og betale for det, man bruger,« fortæller CIO'en.

DR anvender desuden en række eksterne udviklingspartnere, der skal kunne udvikle, teste og deploye på samme platform, som DR bruger.

»Det kan nemt give udfordringer med et traditionelt setup,« siger Mikkel Müller.

Cloud-first-strategien betyder også, at DevOps-holdet får endnu en opgave i form af kapacitetstyring:

»Det er så nemt at lave nye instanser, og hvis man ikke har fokus på at få dem lukket igen, så kan det blive dyrt.«

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (9)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jesper Hansen

DR er så endnu en i rækken der smider en udviklere ind i et team, kalder det "DevOps", og så er de pludselig gode til operations. Forsøget med at lægge det i infrastruktur teamet, viser også meget godt at man ikke forstår begrebet.

DRs jobannoncer viser det også meget godt. "Vi søger en DevOps udvikler"... wat?

  • 7
  • 1
Mads H. Danquah

Jeg tænker der er mange idéer til hvad "DevOps" skal forbedre i DR, men mon ikke de store er

  • Det manuelle arbejde i udvikling, test og drift skal reduceres så man kan rulle ting ud hurtigere med højere kvalitet
  • Ansvaret for at tinge bliver udviklet og bliver ved med at virke skal bredes mere ud

Den første ligger lige til højrebenet for et automatiserings-team. Man kan lave workshops med de teams skal hjælpes hvor man konfigurer værktøjer og man kan hive konsulenter ind til de helt skumle hjørner af AWS. I det hele taget kan man nu om dage få lavet noget rigtig lækker automatisering.

Men - automatiseringen er altså de 20 (meget shiny) procent "DevOps" - de resterende 80% ligger i alle barrierer der er opbygget af personlige konflikter, siloer opbygget af kamp om budgetter, ar fra alle de gange hvor drift skulle holde dårligt kodede stumper i luften under højt load osv osv. Med andre ord, alt det nitty-gritty hvor man skal få folk til at arbejde sammen om at lave noget, og derefter i fælleskab have ansvar for hele produktet.

Jeg synes det er lidt svært at læse ud af artiklen hvordan det her DevOps team reelt skal få udbredt den slags samarbejde, og hvis de tanker allerede er på plads kunne det være super spændende at høre mere om dem.

Hvis de ikke er på plads kunne det være spændende at høre om hvordan de kommer det :)

Og som et ps jeg kan varmt anbefale at alle der vil have en let spiselig indføring i problemerne DevOps omhandler (hvis man spørger nogen af dem der startede det hele that is) læser/hører "The Phoenix Project"

  • 4
  • 0
Allan Ebdrup

Dels for at stille sig op og fortælle om deres DevOps indsats. Jo mere vi deler med hinanden, jo mere kan vi lære.
Og Dels for at drifte et site med 19 millioner requests i minuttet, uden de store hiccups. 👍

  • 4
  • 0
Jesper Frimann

@Mads H. Danquah

Ja. :)
Det handler nemlig i høj grad om mennesker, og om hvordan man enabler dem til at udføre deres arbejde bedste muligt, i samarbejde med de mennesker de er afhængige af.

Og det er bekymrende når man opretter en separat afdeling til DevOps... det er jo IMHO lidt i modstrid med hele ideen.

// Jesper

  • 0
  • 0
Allan S. Hansen
  • 2
  • 0
HW Jensen

Lang tid siden jeg har læst noget så fornuftigt. Herinde på V2 hører vi jo fra alle dem der har de rigtige meninger og ved bedre, tilsyneladende uden nogensinde selv at have fået en blodtud eller to. Godt at høre at der er nogen der lærer af deres erfaringer, og fortæller om det uden skønmaleri. Jeg køber at det måske ville være endnu mindre siloagtigt at udviklerne selv var involveret i devops rollen så der simpelthen ikke var en devops afdeling. Men hvem ved, de sidder måske i det samme kontor eller et eller andet. At infrastruktur er lidt for sig selv er vel OK, det er jo trods alt et lidt andet perspektiv når platformen er så tung som jeg gætter på den er i DR.

  • 3
  • 0
Log ind eller Opret konto for at kommentere