Wat is canary deployment? Een praktische gids voor SRE's

Wat is canary deployment? Het is een releasetechniek waarbij je een nieuwe versie naar een klein deel van het productieverkeer stuurt, die vergelijkt met de versie die al draait, en de uitrol alleen verder opvoert als de cijfers standhouden. In de praktijk is het een deploy met een ingebouwd beslismoment: de wijziging bereikt eerst 1 tot 5 procent van de gebruikers, en een metriccheck bepaalt of hij doorgaat of wordt teruggedraaid.

Het vervolg van deze gids behandelt hoe het werkt, waar het misgaat en wat je kunt automatiseren.

De pager om 3 uur 's nachts die een canary in een Slack-bericht had kunnen veranderen

Een deploy gaat donderdag om 16:40 de deur uit. Het foutpercentage van de checkout-service stijgt van 0,2 naar 4 procent. Niemand merkt het tot er twee uur later een supportticket binnenkomt, en dan heeft elke gebruiker de nieuwe build al gedraaid. Terugdraaien duurt 25 minuten, omdat de migratie half is doorgevoerd.

Draai dezelfde wijziging als canary op 5 procent van het verkeer, en de schade blijft beperkt. Ongeveer 1 op de 20 gebruikers ziet de bug, de vergelijking met de controlegroep faalt binnen enkele minuten, en de pipeline stopt. De post-mortem vertelt dan wat de canary heeft gevangen, niet wat hij heeft gemist.

De naam komt uit de kolenmijnen, waar een kanarie stopte met zingen voordat de lucht dodelijk werd. Jouw kleine cohort speelt dezelfde rol. Het voorkomt de slechte release niet. Het beperkt wie hem inademt.

Wat een canary deployment precies doet, stap voor stap

De Google SRE Workbook omschrijft een canary als een gedeeltelijke, tijdsbeperkte uitrol van een wijziging, plus een evaluatie die bepaalt of de uitrol doorgaat. De subset die de wijziging draait is de canary. De rest van de vloot is de controle. Dat kader is belangrijk, want het maakt van een canary een A/B-test op je eigen betrouwbaarheid, en geen trage deploy.

Een gebruikelijke volgorde ziet er zo uit:

• Rol de nieuwe versie uit naast de stabiele, zonder dat er al verkeer naartoe gaat.

• Stuur een klein percentage ernaartoe (het voorbeeld van de Workbook gebruikt 5 procent).

• Houd een vast venster aan (hetzelfde voorbeeld gebruikt 30 minuten) terwijl je canary en controle vergelijkt.

• Ga naar de volgende stap, bijvoorbeeld 25, dan 50 en dan 100 procent, of breek af en stuur het verkeer terug.

De lus is eenvoudig. Het moeilijke deel is de vergelijking, en die implementeren de meeste teams als "iemand kijkt naar een dashboard".

Canary, blue-green en rolling: welke past bij jouw faalpatroon

Deze drie worden voortdurend door elkaar gehaald, dus hier het onderscheid dat er bij de keuze toe doet.

• Rolling update: vervangt instanties geleidelijk. Goedkoop en ingebouwd in elke orchestrator, maar er is geen vergelijking met een controle en geen schone verkeersverdeling. Oude en nieuwe versie delen de belasting tot het einde.

• Blue-green: twee volledige omgevingen, en al het verkeer in een keer omschakelen. Terugdraaien is direct, maar de blast radius op het moment van de omschakeling is 100 procent van de gebruikers. Je betaalt voor dubbele capaciteit.

• Canary: een gecontroleerd deel van het live verkeer op de nieuwe versie, beoordeeld tegen de oude. De kleinste blast radius, en de hoogste operationele complexiteit.

Kies blue-green als het risico een kapotte deploy is die je met een smoke test kunt zien en in seconden kunt terugdraaien. Kies canary als het risico een subtiele regressie is die alleen echt verkeer blootlegt: een oplopende p99-latentie, een trage geheugenlek, een queryplan dat faalt op productiedata.

Sla canary over als je service weinig verkeer heeft. Bij enkele honderden verzoeken per uur geeft een plakje van 5 procent je een handvol samples en geen signaal. De Workbook zegt het zonder omwegen: heel weinig queries leveren geen bruikbaar signaal op voor diverse workloads.

Waarom je canary met 1 procent waarschijnlijk liegt

Dit is de fout die teams in de eerste drie maanden treft. De canary krijgt 5 procent van het verkeer en faalt op 20 procent van zijn verzoeken. Het foutpercentage van de hele service stijgt van 0,2 naar ongeveer 1,2 procent. Je alertdrempel staat op 2 procent. Er gaat niets af.

Aggregatiemonitoring verbergt falende canaries. Dezelfde rekensom staat in de SRE Workbook: een canary die op 5 procent van het verkeer 20 procent van zijn verzoeken laat falen, toont een wereldwijd foutpercentage van slechts 1 procent. Je moet metrics splitsen per populatie, canary tegenover controle, anders verdwijnt het signaal in de noemer.

Drie andere valkuilen om te kennen:

• Voor-en-na-vergelijkingen. Het vergelijken van het canaryvenster met het vorige uur vermengt de wijziging met de tijd. Het verschil tussen werkdag en weekend kan alleen al een echte regressie overspoelen. Vergelijk liever met een gelijktijdige controle.

• Gedeelde afhankelijkheden. Als canary en controle dezelfde cache of database raken, kan een slechte canary beide vertragen, en dan laat de vergelijking niets zien. Controleer je foutdomeinen.

• Ruisige metrics. CPU-gebruik is een slechte poort. Foutcodes en latentie volgen wat gebruikers voelen. De Workbook adviseert kandidaat-metrics te rangschikken op hoe goed ze gebruikersproblemen weerspiegelen, en alleen de beste paar te houden, hooguit een dozijn.

Kies de poortmetrics voordat je uitrolt, niet tijdens het incident

Begin bij je SLI's. Heb je al een beschikbaarheids-SLI en een latentie-SLI voor de service, dan zijn dat je eerste twee poorten. Een redelijke startset voor een request-gedreven service:

• Foutpercentage (5xx) bij canary tegenover controle, over het observatievenster

• p99-latentie bij canary tegenover controle

• Een saturatiesignaal dat aan de wijziging toe te schrijven is, zoals geheugengroei per pod

• Eén metric dicht bij het bedrijf, bijvoorbeeld afgeronde checkouts, als je die per cohort kunt isoleren

Drempels zijn waar teams weken verliezen. Stel ze te strak in, en elke canary breekt af op ruis, waardoor ingenieurs leren de poort te overschrijven. Stel ze te los in, en een slechte build glipt erdoorheen. Herzie ze volgens schema. Een poort die in zes maanden niets heeft afgebroken, is ofwel perfect ofwel decoratief, en je moet uitzoeken welke van de twee.

Houd ook het aggregatie-interval niet langer dan het canaryvenster. Een rollup van 10 minuten op een canary van 5 minuten vertroebelt alles.

Een canary in config: hoe de stappen eruitzien in Argo Rollouts

Op Kubernetes drukt de canary-spec van Argo Rollouts de volgorde uit als een lijst met stappen. Hier een ingekorte versie in de vorm die de documentatie beschrijft:

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

Twee details uit de documentatie verdienen aandacht. Zonder verkeersrouter wordt het gewicht benaderd met het aantal pods, op basis van best effort: 10 replicas op 10 procent betekent één canary-pod en negen stabiele. Dat is replicawiskunde, geen verzoekwiskunde. En een pause: {} zonder duur wacht oneindig tot iemand kubectl argo rollouts promote uitvoert, een menselijke poort die je misschien wel of niet wilt.

Als de analysestap faalt, wordt de uitrol afgebroken. Daar moet je in investeren.

Feature flags en telemetrie: de andere helft van een veilige canary

Infrastructuur-canaries splitsen verkeer per instantie of pod. Flag-gebaseerde canaries splitsen per gebruiker, account of elk ander kenmerk dat je kunt targeten. Ze beantwoorden verschillende vragen. De eerste vraagt of de nieuwe build gezond is. De tweede vraagt of het nieuwe gedrag acceptabel is, en laat je het uitzetten zonder herdeploy.

Voor flag-gedreven uitrollen telt de tooling. LaunchDarkly heeft de meest volwassen targetingregels en audittrail, en wint op ecosysteembreedte. De prijs op enterpriseschaal is de gebruikelijke klacht van platformleads.

Statsig bundelt experimenten met flags, wat past bij teams die op hetzelfde platform op metrics willen oordelen. Minder geschikt als je alleen een kill switch nodig hebt.

De eerlijke afweging: een flagplatform geeft je percentage-uitrollen, maar de meeste lezen je SLO's niet zelfstandig. Iemand moet de metric alsnog aan de beslissing koppelen.

Wat de uitrol ook aanstuurt, het oordeel komt uit je telemetrie. Elke metric heeft dus een versie- of cohortlabel nodig, en je backend moet erop kunnen bevragen zonder een vertraging van 10 minuten.

Datadog doet dit goed met taggebaseerde uitsplitsingen, en de deploymenttracking koppelt releases aan foutpieken. De kosten bij hoge cardinaliteit zijn het eerste wat je moet doorrekenen voordat je alles taggt.

Grafana met Prometheus werkt als je het al draait en metrics labelt per rolloutrevisie. Je houdt volledige controle, maar het onderhoud draag je zelf.

Het afbreken automatiseren: waar het idee van de AI-pilot vandaan komt

Handmatige canary-analyse schaalt slecht. Bij tien deploys per dag staart niemand 30 minuten per keer naar een dashboard, en dus wordt de poort stilletjes "zag er goed uit". Het patroon dat standhoudt is een geautomatiseerde beoordelaar: definieer de SLO, definieer de vergelijking, en laat een controller de canary afbreken en terugdraaien wanneer die sneller foutbudget verbrandt dan de controle.

Dat is het probleem waarop de AI Pilot van upstreamapi mikt. Die leest het SLO-signaal tijdens de uitrol en start een automatische rollback zodra het foutpercentage de drempel overschrijdt die je hebt ingesteld. Hij meet foutpercentage en latentie ten opzichte van de stabiele cohort, meer niet, en niets mystieks. Als je al Argo Rollouts-analysetemplates met een goede Prometheus-query draait, heb je grotendeels dezelfde mogelijkheid, en dat mag je gerust zeggen tegen iedereen die je magie verkoopt. Waar een gehoste pilot zijn plek verdient, is bij heterogene stacks, waar elk team anders zijn eigen analysetemplates zou moeten onderhouden.

Een veelvoorkomend faalpatroon: teams automatiseren de promote-stap en nooit de abort. Een pipeline die alleen vooruit weet te gaan, is een transportband.

Wat je moet meten om te weten dat je canaryproces werkt

Een canaryprogramma heeft zijn eigen metrics. Volg deze over een kwartaal:

• Canary-abortpercentage: het aandeel canaries dat door de poort wordt gestopt. Nul betekent dat de poort blind is. Boven de 20 tot 30 procent wijst meestal op wankele drempels of zwakke pre-merge-tests.

• Detectietijd op de canary: minuten van het eerste slechte verzoek tot de abort. Dit is je echte MTTD voor releases.

• Ontsnapte regressies: incidenten die herleid worden tot een release die de canary had doorstaan. Elk ervan zou een poort moeten veranderen.

• Gemiddelde tijd tot terugdraaien: van het abortbesluit tot 100 procent van het verkeer op de stabiele versie.

Draai per service maar één canary tegelijk. De Workbook raadt dat sterk aan, en de reden is praktisch: twee overlappende wijzigingen maken toerekening onmogelijk, en dan weet je niet welke van de twee je pijn heeft gedaan.

Waar je deze week begint

Kies één stateloze service met genoeg verkeer om binnen 15 minuten een signaal te geven. Voeg een versielabel toe aan de fout- en latentiemetrics. Schrijf één vergelijkingsquery, canary tegenover controle. Draai een canary van 5 procent met een handmatige promote, en noteer wat je had gevangen in de laatste drie incidenten.

Stel jezelf dan de ongemakkelijke vraag: als de canary om 02:00 was gefaald, had dan iets hem gestopt zonder dat er een mens wakker was?