Vad är canary deployment? En praktisk guide för SRE

Canary deployment är en releasemetod där du skickar en ny version till en liten del av produktionstrafiken, jämför den mot versionen som redan körs, och bara breddar utrullningen om siffrorna håller. Vad är canary deployment i praktiken? Det är en deploy med en inbyggd beslutspunkt: ändringen når först 1 till 5 procent av användarna, och en mätning avgör om den fortsätter eller rullas tillbaka.

Resten av guiden går igenom hur det fungerar, var det brukar fallera och vad du bör automatisera.

Det tredje natten-larmet som en canary hade kunnat förvandla till ett Slack-meddelande

En deploy går ut klockan 16.40 en torsdag. Felfrekvensen i checkout-tjänsten stiger från 0,2 procent till 4 procent. Ingen märker det förrän ett supportärende dyker upp två timmar senare, och då har varje användare kört den nya builden. Rollbacken tar 25 minuter eftersom migreringen är halvt applicerad.

Kör du samma ändring som en canary på 5 procent av trafiken blir skadan avgränsad. Ungefär var tjugonde användare ser buggen, jämförelsen mot kontrollgruppen fallerar inom några minuter och pipelinen stannar. Post-mortemen handlar då om vad canaryn fångade, inte om vad den missade.

Namnet kommer från kolgruvorna, där kanariefågeln slutade sjunga innan luften blev dödlig. Din lilla kohort spelar samma roll. Den förhindrar inte den dåliga releasen. Den begränsar vilka som andas in den.

Vad en canary deployment faktiskt gör, steg för steg

Google SRE Workbook definierar canarying som en partiell, tidsbegränsad utrullning av en ändring plus en utvärdering som avgör om utrullningen fortsätter. Delmängden som kör ändringen är canaryn. Resten av flottan är kontrollen. Det spelar roll, eftersom det gör en canary till ett A/B-test på din egen tillförlitlighet, inte till en långsam deploy.

En typisk sekvens ser ut så här:

• Deploya den nya versionen bredvid den stabila, utan trafik än.

• Skicka en liten andel dit. Workbook-exemplet använder 5 procent.

• Håll ett fast fönster. Exemplet använder 30 minuter, medan du jämför canary och kontroll.

• Gå vidare till nästa steg, till exempel 25, 50 och sedan 100 procent, eller avbryt och skicka tillbaka trafiken.

Loopen är enkel. Det svåra är jämförelsesteget, som de flesta team implementerar som att någon tittar på en dashboard.

Canary, blue-green eller rolling: vilken passar din felbild

Dessa tre blandas ihop hela tiden, så här är skillnaden som spelar roll när du väljer.

• Rolling update: ersätter instanser gradvis. Billigt och inbyggt i varje orkestrerare, men ingen jämförelse mot en kontroll och ingen ren trafikuppdelning. Gammal och ny version delar på lasten fram till slutet.

• Blue-green: två fullständiga miljöer, all trafik byts på en gång. Rollbacken är omedelbar, men skadeområdet i ögonblicket för bytet är 100 procent av användarna. Du betalar för dubbel kapacitet.

• Canary: en kontrollerad andel av live-trafiken på den nya versionen, bedömd mot den gamla. Minst skadeområde, högst driftkomplexitet.

Välj blue-green när risken är en trasig deploy som du kan upptäcka med ett smoke-test och rulla tillbaka på sekunder. Välj canary när risken är en subtil regression som bara verklig trafik blottlägger: en p99-latens som långsamt kryper uppåt, ett minnesläckage, en frågeplan som faller över på produktionsdatas form.

Hoppa över canary om tjänsten har mycket låg trafik. Med några hundra requests i timmen ger en skiva på 5 procent en handfull mätpunkter och ingen signal. Workbooken säger det rakt ut: mycket få förfrågningar ger ingen användbar signal för varierade arbetslaster.

Varför din canary på 1 procent troligen ljuger för dig

Här är felet som drabbar team under de första tre månaderna. Canaryn tar 5 procent av trafiken och misslyckas med 20 procent av sina requests. Felfrekvensen för hela tjänsten rör sig från 0,2 till ungefär 1,2 procent. Ditt larmtröskelvärde är 2 procent. Ingenting larmar.

Aggregerad övervakning döljer fel i canaryn. Samma aritmetik finns i SRE Workbooken: en canary som misslyckas med 20 procent av requests på 5 procent av trafiken syns bara som en total felfrekvens på 1 procent. Du måste bryta ned mätetalen per population, canary mot kontroll, annars försvinner signalen i nämnaren.

Tre andra fallgropar är värda att känna till:

• Före- och efterjämförelser. Att jämföra canary-fönstret med föregående timme blandar ihop ändringen med tiden. Trafik på vardagar mot helger kan ensam dränka en verklig regression. Jämför i stället mot en samtidig kontroll.

• Delade beroenden. Om canary och kontroll träffar samma cache eller databas kan en dålig canary försämra båda, och jämförelsen visar ingenting. Kontrollera dina felområden.

• Brusiga mätetal. CPU-användning är en dålig grind. Felkoder och latens följer det användarna känner. Workbooken rekommenderar att rangordna kandidatmätetalen efter hur väl de speglar problem som användaren ser, och att behålla de bästa få, kanske högst ett dussin.

Välj gate-mätetalen och automatisera aborten innan du shippar

Utgå från dina SLI:er. Har du redan en tillgänglighets-SLI och en latens-SLI för tjänsten är det dina två första grindar. En rimlig startuppsättning för en requestdriven tjänst:

• Felfrekvens (5xx) på canary mot kontroll under mätfönstret

• p99-latens på canary mot kontroll

• En mättnadssignal som kan tillskrivas ändringen, till exempel minnesökning per pod

• Ett affärsnära mätetal, till exempel slutförda köp i kassan, om du kan isolera det per kohort

Trösklar är där team förlorar veckor. Sätter du dem för snävt avbryts varje canary på brus, och ingenjörer lär sig att överköra grinden. Sätter du dem för löst går en dålig build igenom. Se över dem enligt schema. En grind som aldrig avbrutit något på sex månader är antingen perfekt eller dekorativ, och du bör ta reda på vilket.

Håll också aggregeringsintervallet för mätetalen kortare än eller lika med canary-fönstret. En rollup på 10 minuter över en canary på 5 minuter gör allt grumligt.

Manuell canary-analys skalar illa. Vid tio deploys om dagen sitter ingen och stirrar på en dashboard i 30 minuter varje gång, så grinden blir tyst ett "såg bra ut". Mönstret som håller är en automatisk domare: definiera SLO:n, definiera jämförelsen, och låt en kontroller avbryta och rulla tillbaka när canaryn bränner felbudget snabbare än kontrollen.

Det är problemet som upstreamapis AI Pilot riktar sig mot. Den läser SLO-signalen under utrullningen och utlöser en automatisk rollback när felfrekvensen passerar tröskeln du har satt. Den mäter felfrekvens och latens mot den stabila kohorten, inget mer mystiskt än så. Har du redan Argo Rollouts-analysmallar med en bra Prometheus-fråga har du i stort sett samma förmåga, och du bör säga det till den som säljer dig magi. Där en hostad pilot förtjänar sin plats är över heterogena stackar, där varje team annars skulle underhålla egna analysmallar.

Ett vanligt felmönster: team automatiserar steget framåt men aldrig steget bakåt. En pipeline som bara vet hur den går framåt är ett transportband.

En canary i konfig: så ser stegen ut i Argo Rollouts

På Kubernetes uttrycker Argo Rollouts canary-specen sekvensen som en lista med steg. Här är en kondenserad version i den form dokumentationen beskriver:

strategy:
  canary:
    steps:
      - setWeight: 5
      - pause: { duration: 30m }
      - analysis:
          templates:
            - templateName: error-rate-vs-baseline
      - setWeight: 25
      - pause: { duration: 30m }
      - setWeight: 50
      - pause: {}

Två detaljer från dokumentationen förtjänar uppmärksamhet. Utan trafikrouter approximeras vikten med antalet pods, på bästa möjliga sätt: 10 repliker på 10 procent innebär en canary-pod och nio stabila. Det är replikmatematik, inte requestmatematik. Och en pause: {} utan duration väntar tills någon kör kubectl argo rollouts promote, vilket är en mänsklig grind som du kanske eller kanske inte vill ha.

Om analyssteget fallerar avbryts utrullningen. Det är den delen du ska investera i.

Feature flags och jämförelsedata: den andra halvan av en säker canary

Infrastruktur-canaries delar trafik per instans eller pod. Flaggbaserade canaries delar per användare, konto eller valfritt attribut du kan rikta mot. De två besvarar olika frågor. Den första frågar om den nya builden är frisk. Den andra frågar om det nya beteendet är acceptabelt, och låter dig stänga av det utan en ny deploy.

För flaggdrivna utrullningar spelar verktygen roll. LaunchDarkly har de mest mogna målgruppsreglerna och den mest utvecklade granskningsloggen, och vinner på bredd i ekosystemet. Prissättningen på enterprise-nivå är det vanliga klagomålet bland plattformsledare.

Statsig paketerar experimentering tillsammans med flaggor, vilket passar team som vill ha mätbaserade beslut på samma plattform. Det passar sämre om du bara behöver en nödbrytare.

Den ärliga avvägningen: en flaggplattform ger dig procentuella utrullningar, men de flesta läser inte dina SLO:er av sig själva. Någon måste fortfarande koppla mätetalet till beslutet.

Oavsett vad som styr utrullningen kommer domen från din telemetri. Varje mätetal behöver en version- eller kohortetikett, och din backend måste kunna fråga på den utan en fördröjning på 10 minuter.

Datadog gör detta väl med taggbaserade uppdelningar, och deployment tracking korrelerar releaser med felspikar. Kostnaden vid hög kardinalitet är det du bör modellera innan du taggar allt.

Grafana med Prometheus fungerar om du redan kör det och etiketterar mätetal per rollout-revision. Du får full kontroll, och du äger underhållet.

Vad du mäter för att veta att canary-processen fungerar, och var du startar

En canary-process har egna mätetal. Följ dessa under ett kvartal:

• Canary-abortfrekvens: andelen canaries som stoppas av grinden. Noll betyder att grinden är blind. Över 20 till 30 procent beror oftast på instabila trösklar eller dålig testning före merge.

• Tid till upptäckt på canary: minuter från första felaktiga request till avbrottet. Det här är din verkliga MTTD för releaser.

• Läckta regressioner: incidenter som spåras till en release som passerade canaryn. Varje sådan bör ändra en grind.

• Medeltid till revert: från beslutet om avbrott till att 100 procent av trafiken ligger på den stabila versionen.

Kör bara en canary i taget per tjänst. Workbooken rekommenderar det starkt, och skälet är praktiskt: två överlappande ändringar gör det omöjligt att avgöra vilken som skadade dig.

Välj en stateless tjänst med tillräckligt med trafik för att ge en signal inom 15 minuter. Lägg till en versionsetikett på dess felmätetal och latensmätetal. Skriv en enda jämförelsefråga, canary mot kontroll. Kör en canary på 5 procent med manuell promote, och notera vad du hade fångat i de tre senaste incidenterna.

Ställ sedan den obekväma frågan: om canaryn hade fallerat klockan 02.00, skulle något ha stoppat den utan att en människa var vaken?