”Att betjäna 86 miljoner användare – DevOps enligt Netflix” är en artikel tagen ur vår Lean Magazine, utgåva #13 där Katharina Probst intervjuades på frågor om DevOps kopplat till hennes dåvarande roll som Engineering Manager på Netflix.

“Moving into the cloud changes the model Ops is done naturally.” Katharina Probst, Netflix

DevOps enligt Netflix – att erbjuda strömmande innehåll till 86 miljoner tittare världen över utan avbrott eller hack – det är utmaningen som Netflix står inför varje dag i veckan. Detta ställer naturligtvis enorma krav på organisationen, och företaget bjuds ofta in till DevOps-konferenser för att prata om sitt arbete. Men faktum är att knappt någon på Netflix använder termen DevOps. Dess organisation är byggd på konceptet Site Reliability Engineers (SREs) – ett arbetssätt som har mycket gemensamt med DevOps och som ursprungligen utvecklades av Google. Vi fick möjligheten att prata med Katharina Probst, Engineering Manager för API och Mantis på Netflix.

FRÅN WIKIPEDIA:
Site Reliability Engineering
Site Reliability Engineering skapades på Google runt 2003 när Ben Treynor anställdes för att leda ett team av sju mjukvaruutvecklare för att driva en produktionsmiljö. Teamet fick i uppgift att få Googles webbplatser att fungera smidigt, effektivt och mer tillförlitligt.

En site reliability engineer (SRE) kommer idealiskt att spendera upp till 50 % av sin tid med att göra ”ops”-relaterade arbetsuppgifter såsom problemhantering, jour och manuella ingripanden. Eftersom det mjukvarusystem som en SRE övervakar förväntas vara högt automatiserat och självläkande, bör SRE tillbringa den andra 50 % av sin tid på utvecklingsuppgifter såsom nya funktioner, skalning eller automatisering. Den ideala SRE-kandidaten är en kodare som också har operativ och systemkunskap och som gillar att förenkla komplexa uppgifter.

DevOps vs SRE

DevOps omfattar automatisering av manuella uppgifter, kontinuerlig integration och kontinuerlig leverans. Det tillämpas på ett brett spektrum av företag medan SRE kan anses vara en delmängd av DevOps som besitter ytterligare färdigheter. Katharina Probst är Engineering Manager på Netflix där hon har arbetat sedan 2015. Tidigare arbetade hon med mjukvaruutveckling på Google, både som ingenjör och som chef.

Vad är din bakgrund och hur blev du involverad med Netflix?
Jag kommer från en akademisk bakgrund men gick med i hightech-scenen några år efter min doktorsexamen. På Google arbetade jag som ingenjör och chef i flera år, där jag bidrog till olika projekt, från utvecklarverktyg till Gmail och Google Compute Engine. För lite över ett år sedan gick jag med i Netflix, där jag leder API-teamet och ett team för operativa insikter. Det som ursprungligen lockade mig till Netflix (förutom människorna) var möjligheten att arbeta med ett mycket storskaligt system som är extremt kritiskt för verksamheten.

DevOps är inte en term som jag har hört användas frekvent på Google eller på Netflix. Google-modellen för SRE skiljer sig från Netflix-modellen på några betydande sätt. I grund och botten är alla serverteam på Netflix ansvariga för sin egen drift, inklusive 24/7 jour. Dock har flera centraliserade team av ingenjörer byggt fantastiska verktyg för att göra denna modell genomförbar. Till exempel har vi ett CI/CD-verktyg som heter Spinnaker. Spinnaker är också kraftfullt vid körning, inte bara vid distribution, till exempel ger det enkel åtkomst till loggar och möjliggör enkel återställning av kod.

Skulle du kunna ge en sammanfattning av de utmaningar som Netflix måste hantera när de tillhandahåller sina tjänster till världen?
Netflix har nu fler än 86 miljoner användare världen över och körs på fler än 1 000 enhetstyper. Dessutom kör Netflix dussintals A/B-tester. Alla dessa dimensioner ökar kontinuerligt. API:et tillhandahåller en plattform som möjliggör för UI-team att skriva enhetsspecifik serverlogik.

Tanken är att serverlogik som hanterar olika formfaktorer (till exempel iPhone jämfört med 40-tums TV-skärm) eller olika interaktionsmodeller (till exempel mobil jämfört med bärbar dator) har materiella fördelar: utvecklarhastigheten blir högre eftersom teamen kan röra sig snabbt och oberoende, och kundupplevelsen blir bättre eftersom Netflix-upplevelsen anpassas efter deras enhet och interaktionsmodell. Det bör dock inte förbises att denna modell leder till ökad komplexitet. API:et har sett antalet skript som tillhandahålls av enhetsspecifika team öka till mer än 1 000.

Under tiden har Netflix mycket höga förväntningar när det gäller drifttid och tillförlitlighet. API:et i synnerhet är en kritisk komponent i Netflix ekosystem av mikrotjänster: om API:et är nere kan ingen logga in på Netflix, registrera sig, söka, upptäcka eller starta uppspelningar. Med andra ord är Netflix-upplevelsen bruten.

DevOps-principer är, som vi förstår det, implementerade i Netflix både med en stark kultur och en speciell organisation – kan du beskriva dessa?
Netflix bygger på en kultur av frihet och ansvar. Detta innebär att varje Netflix-anställd har stor frihet, men med frihet följer ansvar. Som ett resultat omfamnar vi en filosofi om att ”driva det du bygger.” Vi har endast några få driftinriktade ingenjörer, ett kärnteam av SREs. Dessutom driver varje teknikteam sina egna tjänster, hanterar sina egna distributioner (och återställningar, om nödvändigt) och är på 24/7 jour för att hantera eventuella produktionsproblem som uppstår. Detta betyder inte att människor arbetar non-stop. Det betyder att vi turas om att vara tillgängliga för ett samtal som kan komma utanför arbetstid. Varje ingenjör tar en veckas ”skift” när det blir deras tur. Att koppla detta tillbaka till frihet och ansvar är enkelt: du har friheten att äga din tjänsts distributioner, men du har ansvaret att se till att din tjänst fungerar korrekt.

Kärn-SRE-teamets roll är att ha en god förståelse för hur vårt ekosystem av mikrotjänster fungerar tillsammans globalt. Generellt sett blir SRE-teamet inte involverat för varje larm som utlöses (till exempel om latenser mellan min tjänst och en annan tjänst ökar). De blir involverade för stora, särskilt kundsynliga problem. I sådana fall är de i frontlinjen tillsammans med ingenjörerna som ansvarar för de individuella tjänsterna, och tillsammans adresserar de problemet. SRE:er har en mer global bild och kommer att förstå bättre vilka framgångsrika strategier för att mildra problemet som kan vara (till exempel återställning, vilka andra team som bör involveras, trafikomdirigering). Varje enskilt team känner sina tjänst(er) bäst och driver sådana saker som rotorsaksanalys och återställningar för sina egna tjänst(er).

Från vad jag förstår är Netflix byggt på en arkitektur baserad på mikrotjänster. Skulle du kunna berätta lite om det?
Netflix kör hundratals tjänster. Vissa är små, vissa kan legitimt inte kallas mikrotjänster. Många team äger mer än en tjänst, men varje tjänst drivs av ett teknikteam. Vi har dussintals, om inte hundratals tjänster som verkligen är mikrotjänster: de löser ett specifikt problem, är välavgränsade och välisolerade, och publicerar ett tydligt API. Detta fungerar väl med vår modell av att ”driva det du bygger.” Team förstår sina egna tjänster, varje tjänst har tydligt definierade gränser och körs och skalas oberoende. Om det inte finns (sällsynta) bakåtkompatibla ändringar i en mikrotjänsts API, kan varje mikrotjänstägare utveckla tjänsten oberoende av andra team, vilket leder till stor utvecklarhastighet för oberoende team.

API:et, för närvarande, är mer komplext än en typisk mikrotjänst. Det består av ett tjänstlager (kod skriven av API-teamet), men det integreras också med många andra tjänster. I synnerhet har API:et dussintals nedströms beroende tjänster som det skickar trafik till. Dessutom laddar och kör API:et server-sidans skript som nämns ovan. Eftersom API:et har vuxit till denna komplexitetsnivå över åren, erkänner vi behovet av att bryta ner det i mindre bitar, av samma anledning som alla företag bryter ner ett stort komplext system i mikrotjänster. En aspekt av detta är en pågående ansträngning att flytta de enhetsspecifika server-sidans skripten ut ur API:et och göra dem till sina egna mikrotjänster.

Vad tror du om framtida utveckling av DevOps i världen och på Netflix?
Många organisationer flyttar idag till molnet, vilket naturligtvis ändrar modellen för hur ops görs. För ett företag i molnet finns det inte längre ett behov av ett specialiserat hårdvaruops-team som ställer in nya servrar, konfigurerar hårdvarulastbalanserare osv. Men vi behöver fortfarande människor som är bra på drift, och ju mer komplex din applikation är, desto mer expertis krävs. Tänk på det: om du har en mycket komplex tjänst med 60 nedströms tjänster, alla som kan uppleva problem, säg, prata med sitt beständighetslager eller få sina instanser att komma upp, allt detta kan påverka din egen tjänst. Om du kör en tunn applikationsserver med få nedströmsberoenden och låg trafik är problemet mycket mindre komplext.

“I can imagine a world where the DevOps model of ‘you operate what you build’ becomes more prevalent.”

När fler företag omfamnar mikrotjänster kan jag föreställa mig en värld där DevOps-modellen av ”du driver vad du bygger” blir mer utbredd. Samtidigt tror jag att för mycket storskaliga, mycket komplexa system kommer djup expertis i drift alltid att krävas. Om det innebär att bygga upp ett team av dedikerade specialister (som SRE:er) eller bygga upp denna expertis i ett team av ingenjörer är en annan fråga, och en som varje organisation, eller delorganisation, måste lista ut för sig själva.

 

Ladda ner Lean Magazine #13 här