Säkra distributionsmetoder

Ibland lever en version inte upp till förväntningarna. Trots att du använder metodtips och skickar alla kvalitetsgrindar finns det ibland problem som resulterar i en produktionsdistribution som orsakar oförutsedda problem för användarna. För att minimera och minimera effekten av dessa problem uppmanas DevOps-team att anta en progressiv exponeringsstrategi som balanserar exponeringen av en viss version med dess beprövade prestanda. När en version visar sig vara i produktion blir den tillgänglig för nivåer av bredare målgrupper tills alla använder den. Teams kan använda säkra distributionsmetoder för att maximera kvaliteten och hastigheten på lanseringar i produktion.

Kontrollera exponering för kunder

DevOps-team kan använda olika metoder för att kontrollera exponeringen av uppdateringar för kunder. Tidigare har A/B-testning varit ett populärt val för team som vill se hur olika versioner av en tjänst eller användargränssnitt presterar mot målmål. A/B-testning är också relativt lätt att använda eftersom ändringarna vanligtvis är mindre och ofta bara jämför olika versioner på den kundriktade gränsen för en tjänst.

Säker distribution via nivåer

I takt med att plattformarna växer tenderar även infrastrukturskalan och målgruppsbehoven att växa. Detta skapar ett behov av en distributionsmodell som balanserar de risker som är kopplade till en ny distribution med fördelarna med de uppdateringar som den lovar. Den allmänna tanken är att en viss version först endast ska exponeras för en liten grupp användare med den högsta risktoleransen. Om versionen sedan fungerar som förväntat kan den exponeras för en bredare grupp användare. Om det inte finns några problem kan processen fortsätta genom bredare grupper av användare eller nivåer tills alla använder den nya versionen. Med moderna plattformar för kontinuerlig leverans , till exempel GitHub Actions och Azure Pipelines, är det tillgängligt för DevOps-team av alla storlekar att skapa en distributionsprocess med nivåer.

Funktionsflaggor

Vissa funktioner måste ibland distribueras som en del av en version, men inte först exponeras för användare. I dessa fall ger funktionsflaggor en lösning där funktioner kan aktiveras via konfigurationsändringar baserat på miljö, nivå eller någon annan specifik distribution.

Användare anmäler sig

På samma sätt som med funktionsflaggor ger användaren möjlighet att begränsa exponeringen. I den här modellen aktiveras en viss funktion i versionen, men aktiveras inte för en användare om de inte specifikt vill ha den. Beslutet om risktolerans avlastas till användarna så att de kan bestämma hur snabbt de vill införa vissa uppdateringar.

Flera metoder används ofta samtidigt. Ett team kan till exempel ha en experimentell funktion avsedd för ett mycket specifikt användningsfall. Eftersom det är riskabelt distribuerar de det till den första nivån så att interna användare kan prova. Men även om funktionerna finns i koden måste någon ange funktionsflaggan för en specifik distribution på nivån så att funktionen exponeras via användargränssnittet. Även då kan funktionsflaggan bara exponera alternativet för en användare att välja att använda den nya funktionen. Alla som inte är på nivån, på den distributionen eller som inte har valt att delta kommer inte att exponeras för funktionen. Även om detta är ett ganska intrikat exempel, tjänar det till att illustrera flexibiliteten och det praktiska i progressiv exponering.

Vanliga problem som teamen ställs inför tidigt

När teamen går mot en mer agil DevOps-övning kan de stöta på problem som överensstämmer med andra som har migrerat bort från traditionella monolitiska leveranser. Team som används för att distribuera en gång med några månaders mellanrum har ett tankesätt som buffrar för stabilisering. De förväntar sig att varje distribution kommer att medföra en betydande förändring i deras tjänst och att det kommer att uppstå oförutsedda problem.

Nyttolaster är för stora

Tjänster som distribueras med några månaders mellanrum fylls vanligtvis med många ändringar. Detta ökar sannolikheten för att det kommer att uppstå omedelbara problem och gör det också svårt att felsöka dessa problem eftersom det finns så mycket nytt. Genom att gå över till mer frekventa leveranser blir skillnaderna i vad som distribueras mindre, vilket möjliggör mer fokuserad testning och enklare felsökning.

Ingen tjänstisolering

Monolitiska system skalas traditionellt genom utjämning av maskinvaran som de distribueras på. Men när något går fel med instansen leder det till problem för alla. En enkel lösning är att lägga till flera instanser så att du kan belastningsutjämningsanvändare. Detta kan dock kräva betydande arkitektoniska överväganden eftersom många äldre system inte är byggda för att vara flera instanser. Dessutom kan betydande duplicerade resurser behöva allokeras för funktioner som kan konsolideras bättre någon annanstans.

När nya funktioner läggs till kan du utforska om en mikrotjänstarkitektur kan hjälpa dig att använda och skala tack vare bättre tjänstisolering.

Manuella steg leder till misstag

När ett team bara distribuerar några gånger per år kanske det inte verkar värt investeringen att automatisera leveranser. Därför hanteras många distributionsprocesser manuellt. Detta kräver en betydande tid och ansträngning och är utsatt för mänskliga fel. Att bara automatisera de vanligaste bygg- och distributionsuppgifterna kan gå långt för att minska förlorad tid och oforcerade fel.

Teams kan också använda infrastrukturen som kod för att få bättre kontroll över distributionsmiljöer. Detta tar bort behovet av att begäranden till driftteamet gör manuella ändringar när nya funktioner eller beroenden introduceras i olika distributionsmiljöer.

Endast Ops kan utföra distributioner

Vissa organisationer har principer som kräver att alla distributioner initieras och hanteras av driftpersonalen. Det kan ha funnits goda skäl till det tidigare, men en Agile DevOps-process har stora fördelar när utvecklingsteamet kan initiera och kontrollera distributioner. Moderna plattformar för kontinuerlig leverans ger detaljerad kontroll över vem som kan initiera vilka distributioner och vem som kan komma åt statusloggar och annan diagnostikinformation, så att rätt personer har rätt information så snabbt som möjligt.

Dåliga distributioner fortsätter och kan inte återställas

Ibland går en distribution fel och teamen måste åtgärda det. Men när processer är manuella och åtkomsten till information är långsam och begränsad kan det vara svårt att återställa till en tidigare fungerande distribution. Lyckligtvis finns det olika verktyg och metoder för att minska risken för misslyckade distributioner.

Grundläggande principer

Team som vill införa säkra distributionsmetoder bör ange några grundläggande principer för att stödja arbetet.

Var konsekvent

Samma verktyg som används för att distribuera i produktion bör användas i utvecklings- och testmiljöer. Om det finns problem, till exempel de som ofta uppstår från nya versioner av beroenden eller verktyg, bör de fångas i god tid innan koden är nära att släppas till produktion.

Bry dig om kvalitetssignaler

För många team hamnar i den gemensamma fällan att inte riktigt bry sig om kvalitetssignaler. Med tiden kan de upptäcka att de skriver tester eller tar på sig kvalitetsaktiviteter bara för att ändra en gul varning till ett grönt godkännande. Kvalitetssignaler är verkligen viktiga eftersom de representerar pulsen i ett projekt. De kvalitetssignaler som används för att godkänna distributioner bör spåras hela tiden varje dag.

Distributioner bör kräva noll stilleståndstid

Även om det inte är viktigt att varje tjänst alltid är tillgänglig bör teamen närma sig sina DevOps-leverans- och driftssteg med tankesättet att de kan och bör distribuera nya versioner utan att behöva ta bort dem under någon tid alls. Moderna infrastruktur- och pipelineverktyg är tillräckligt avancerade nu där det är möjligt för praktiskt taget alla team att rikta in sig på 100% drifttid.

Distributioner bör ske under arbetstid

Om ett team arbetar med tankesättet att distributioner kräver noll driftstopp spelar det ingen roll när en distribution pushas. Dessutom blir det fördelaktigt att skicka distributioner under arbetstid, särskilt tidigt på dagen och i början av veckan. Om något går fel bör det spåras tillräckligt tidigt för att kontrollera explosionsradien. Dessutom kommer alla redan att arbeta och fokusera på att åtgärda problem.

Nivåbaserad distribution

Team med mogna DevOps-lanseringsmetoder kan ta sig an nivåbaserad distribution. I den här modellen distribueras nya funktioner först till kunder som är villiga att acceptera den största risken. Allt eftersom distributionen är bevisad utökas målgruppen till att omfatta fler användare tills alla använder den.

En exempelnivåmodell

En typisk nivådistributionsmodell är utformad för att hitta problem så tidigt som möjligt genom noggrann segmentering av användare och infrastruktur. I följande exempel visas hur nivåer används av ett större team på Microsoft.

Tillåt bakningstid

Termen bakningstid avser hur lång tid en distribution tillåts köras innan den expanderas till nästa nivå. Vissa problem kan ta timmar eller längre tid att börja visa symtom, så frisläppningen bör användas under en lämplig tid innan den anses vara klar.

I allmänhet bör en 24-timmarsdag vara tillräckligt med tid för de flesta scenarier för att exponera latenta buggar. Den här perioden bör dock innehålla en period med hög användning, som kräver en hel arbetsdag, för tjänster som når sin topp under kontorstid.

Påskynda snabbkorrigeringar

En liveplatsincident (LSI) inträffar när en bugg har en allvarlig inverkan i produktionen. LSI:er kräver att en snabbkorrigering skapas, vilket är en out-of-band-uppdatering som är utformad för att åtgärda ett problem med hög prioritet.

Om en bugg är Sev 0, den allvarligaste typen av bugg, kan snabbkorrigeringen distribueras direkt till den berörda skalningsenheten så snabbt som möjligt. Även om det är viktigt att korrigeringen inte förvärrar problemet anses buggar av den här allvarlighetsgraden vara så störande att de måste åtgärdas omedelbart.

Buggar som klassificeras som Sev 1 måste distribueras via nivå 0, men kan sedan distribueras till de berörda skalningsenheterna så snart som godkänts.

Snabbkorrigeringar för buggar med lägre allvarlighetsgrad måste distribueras via alla nivåer som planerat.

Viktiga lärdomar

Varje team vill leverera uppdateringar snabbt och med högsta möjliga kvalitet. Med rätt metoder kan leverans vara en produktiv och smärtfri del av DevOps-cykeln.

• Distribuera ofta.
• Håll dig grön under hela sprinten.
• Använd konsekventa distributionsverktyg i utveckling, testning och produktion.
• Använd en plattform för kontinuerlig leverans som tillåter automatisering och auktorisering.
• Följ säkra distributionsmetoder.

Nästa steg

Lär dig hur funktionsflaggor hjälper till att styra exponeringen av nya funktioner för användare.