Was ist canary deployment? Schritte, Gate-Metriken, Fallen

Was ist canary deployment? Es ist eine Release-Methode, bei der Sie eine neue Version an einen kleinen Teil des Produktionsverkehrs ausliefern, sie gegen die bereits laufende Version vergleichen und die Auslieferung nur dann ausweiten, wenn die Zahlen stimmen. Ein Canary-Deployment hat also einen eingebauten Entscheidungspunkt: Die Änderung erreicht zuerst 1 bis 5 Prozent der Nutzer, und eine Metrikprüfung entscheidet, ob sie weiterläuft oder zurückgenommen wird.

Der Rest dieses Leitfadens zeigt, wie das funktioniert, wo es scheitert und was sich automatisieren lässt.

Der Alarm um 3 Uhr nachts, den ein Canary in eine Slack-Nachricht verwandelt hätte

Ein Deployment geht an einem Donnerstag um 16:40 Uhr raus. Die Fehlerrate im Checkout-Service steigt von 0,2 auf 4 Prozent. Niemand bemerkt es, bis zwei Stunden später ein Support-Ticket eintrifft, und dann hat jeder Nutzer bereits den neuen Build. Der Rollback dauert 25 Minuten, weil die Migration halb angewendet ist.

Dieselbe Änderung als Canary auf 5 Prozent des Traffics hält den Schaden begrenzt. Ungefähr jeder 20. Nutzer sieht den Fehler, der Vergleich mit der Kontrollgruppe schlägt innerhalb weniger Minuten fehl, und die Pipeline stoppt. Die Post-Mortem-Analyse würde dann festhalten, was der Canary abgefangen hat, nicht, was er übersehen hat.

Der Name stammt aus dem Bergbau: Ein Kanarienvogel verstummte, bevor die Luft tödlich wurde. Ihre kleine Kohorte übernimmt dieselbe Rolle. Sie verhindert das schlechte Release nicht. Sie begrenzt, wer es einatmet.

Was ein Canary-Deployment Schritt für Schritt tut

Der Google SRE Workbook beschreibt Canarying als eine teilweise, zeitlich begrenzte Auslieferung einer Änderung, kombiniert mit einer Bewertung, die entscheidet, ob der Rollout weiterläuft. Die Teilmenge mit der Änderung ist der Canary, der Rest der Flotte ist die Kontrolle. Diese Sichtweise ist wichtig, denn sie macht aus dem Canary einen A/B-Test für Ihre eigene Zuverlässigkeit und keinen langsamen Deployment-Vorgang.

Ein typischer Ablauf sieht so aus:

• Die neue Version wird neben der stabilen Version bereitgestellt, zunächst ohne Traffic.

• Ein kleiner Prozentsatz (das Beispiel im Workbook nutzt 5 Prozent) wird an sie geleitet.

• Ein festes Zeitfenster (im Beispiel 30 Minuten) wird gehalten, während Sie Canary und Kontrolle vergleichen.

• Der Rollout geht in den nächsten Schritt, etwa 25, dann 50 und dann 100 Prozent, oder er bricht ab und leitet den Traffic zurück.

Die Schleife ist einfach. Der schwierige Teil ist der Vergleichsschritt, den die meisten Teams als "jemand schaut auf das Dashboard" umsetzen.

Canary, Blue-Green oder Rolling: Welches Verfahren zu welchem Fehlerbild passt

Diese drei Verfahren werden ständig verwechselt. Deshalb ist hier die Unterscheidung, auf die es bei der Wahl ankommt.

• Rolling Update: ersetzt Instanzen schrittweise. Günstig und in jedem Orchestrator eingebaut, aber es gibt keinen Vergleich mit einer Kontrollgruppe und keine saubere Traffic-Aufteilung. Alte und neue Version teilen sich die Last, bis der Rollout abgeschlossen ist.

• Blue-Green: zwei vollständige Umgebungen, der gesamte Traffic wird auf einmal umgeschaltet. Der Rollback ist sofort möglich, aber der Wirkungsradius im Moment der Umschaltung umfasst 100 Prozent der Nutzer. Dafür zahlen Sie doppelte Kapazität.

• Canary: ein kontrollierter Anteil des Live-Traffics läuft auf der neuen Version und wird gegen die alte bewertet. Kleinster Wirkungsradius, höchste betriebliche Komplexität.

Wählen Sie Blue-Green, wenn das Risiko ein kaputtes Deployment ist, das ein Smoke-Test erkennt und das sich in Sekunden zurücknehmen lässt. Wählen Sie Canary, wenn das Risiko eine subtile Regression ist, die erst echter Traffic offenlegt: ein steigender p99-Wert bei der Latenz, ein langsames Speicherleck oder ein Abfrageplan, der bei Produktionsdaten zusammenbricht.

Auf einen Canary sollten Sie verzichten, wenn Ihr Service sehr wenig Traffic hat. Bei einigen hundert Requests pro Stunde liefert ein 5-Prozent-Anteil eine Handvoll Stichproben und kein Signal. Das Workbook sagt es direkt: Sehr wenige Anfragen liefern kein nützliches Signal für vielfältige Lastmuster.

Warum Ihr 1-Prozent-Canary Sie wahrscheinlich belügt

Hier ist der Fehler, der Teams in den ersten drei Monaten trifft. Der Canary bekommt 5 Prozent des Traffics und scheitert bei 20 Prozent seiner Requests. Die Fehlerrate des gesamten Services steigt von 0,2 auf etwa 1,2 Prozent. Ihr Alarmschwellenwert liegt bei 2 Prozent. Es feuert nichts.

Aggregiertes Monitoring verbirgt Canary-Fehler. Dieselbe Rechnung findet sich im SRE Workbook: Ein Canary, der bei 20 Prozent der Requests auf 5 Prozent des Traffics scheitert, zeigt nur eine Gesamtfehlerrate von 1 Prozent. Sie müssen die Metriken pro Population aufschlüsseln, Canary gegen Kontrolle, sonst verschwindet das Signal im Nenner.

Drei weitere Fallen lohnen sich zu kennen:

• Vorher-nachher-Vergleiche. Der Vergleich des Canary-Fensters mit der vorherigen Stunde vermischt die Änderung mit der Zeit. Schon der Unterschied zwischen Werktag und Wochenende kann eine echte Regression überdecken. Vergleichen Sie stattdessen mit einer gleichzeitig laufenden Kontrolle.

• Gemeinsame Abhängigkeiten. Greifen Canary und Kontrolle auf denselben Cache oder dieselbe Datenbank zu, kann ein fehlerhafter Canary beide verschlechtern, und der Vergleich zeigt nichts. Prüfen Sie Ihre Fehlerdomänen.

• Verrauschte Metriken. Die CPU-Auslastung ist ein schlechtes Gate. Fehlercodes und Latenz bilden ab, was Nutzer spüren. Das Workbook empfiehlt, Kandidatenmetriken danach zu ordnen, wie gut sie nutzersichtbare Probleme abbilden, und nur die besten wenigen zu behalten, höchstens etwa ein Dutzend.

Gate-Metriken festlegen, bevor Sie ausliefern

Starten Sie bei Ihren SLIs. Haben Sie für den Service bereits einen Verfügbarkeits-SLI und einen Latenz-SLI, sind das Ihre ersten beiden Gates. Ein sinnvoller Startsatz für einen requestgetriebenen Service:

• Fehlerrate (5xx) bei Canary gegenüber Kontrolle, über das Beobachtungsfenster

• p99-Latenz bei Canary gegenüber Kontrolle

• Ein Sättigungssignal, das der Änderung zuzuordnen ist, etwa das Wachstum des Speichers pro Pod

• Eine geschäftsnahe Metrik, zum Beispiel der Abschluss eines Checkouts, sofern Sie sie pro Kohorte isolieren können

Schwellenwerte kosten Teams am meisten Zeit. Setzen Sie sie zu eng, bricht jeder Canary wegen Rauschen ab, und Ingenieure lernen, das Gate zu überstimmen. Setzen Sie sie zu locker, rutscht ein schlechter Build durch. Überprüfen Sie sie regelmäßig. Ein Gate, das seit sechs Monaten nichts abgebrochen hat, ist entweder perfekt oder wirkungslos, und Sie sollten herausfinden, welches von beiden zutrifft.

Halten Sie außerdem das Aggregationsintervall der Metriken nicht länger als das Canary-Fenster. Ein 10-Minuten-Rollup bei einem 5-Minuten-Canary verschmiert alles.

Ein Canary als Konfiguration: So sehen die Schritte in Argo Rollouts aus

Auf Kubernetes drückt die Canary-Spezifikation von Argo Rollouts die Abfolge als Liste von Schritten aus. Hier eine verkürzte Fassung in der Form, die die Dokumentation beschreibt:

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

Zwei Details aus der Dokumentation verdienen Aufmerksamkeit. Ohne Traffic-Router wird das Gewicht grob über die Pod-Anzahl angenähert: 10 Replicas bei 10 Prozent ergeben einen Canary-Pod und neun stabile Pods. Das ist Replica-Mathematik, nicht Request-Mathematik. Und ein pause: {} ohne Dauer wartet unbegrenzt, bis jemand kubectl argo rollouts promote ausführt. Das ist ein menschliches Gate, das Sie wollen oder nicht.

Scheitert der Analyse-Schritt, bricht der Rollout ab. Genau dort lohnt sich die Investition.

Feature Flags, Vergleichsdaten und die automatische Abbruchentscheidung

Infrastruktur-Canaries teilen den Traffic nach Instanz oder Pod. Flag-basierte Canaries teilen nach Nutzer, Konto oder jedem Attribut, das sich gezielt ansteuern lässt. Beide beantworten unterschiedliche Fragen. Der erste fragt, ob der neue Build gesund ist. Der zweite fragt, ob das neue Verhalten akzeptabel ist, und lässt sich ohne Neuausrollung abschalten.

Für flag-gesteuerte Rollouts zählt das Werkzeug. LaunchDarkly hat die ausgereiftesten Targeting-Regeln und den ausführlichsten Audit-Trail und liegt bei der Breite des Ökosystems vorn. Die Preise im Enterprise-Umfang sind der häufigste Kritikpunkt bei Platform-Verantwortlichen.

Statsig bündelt Experimente mit Flags. Das passt zu Teams, die metrikbasierte Bewertungen auf derselben Plattform wollen. Für einen reinen Notschalter ist es weniger geeignet.

Die ehrliche Abwägung: Eine Flag-Plattform bietet prozentuale Rollouts, liest aber die meisten SLOs nicht von selbst aus. Jemand muss die Metrik trotzdem an die Entscheidung anschließen.

Was auch immer den Rollout steuert, das Urteil kommt aus Ihrer Telemetrie. Jede Metrik braucht also ein Versions- oder Kohortenlabel, und Ihr Backend muss danach abfragen können, ohne 10 Minuten Verzögerung.

Datadog kann das mit tag-basierten Aufschlüsselungen gut, und das Deployment-Tracking korreliert Releases mit Fehlerspitzen. Die Kosten bei hoher Kardinalität sollten Sie durchrechnen, bevor Sie alles taggen.

Grafana mit Prometheus funktioniert, wenn Sie es bereits betreiben und Metriken nach Rollout-Revision labeln. Sie erhalten volle Kontrolle, tragen aber auch die Wartung selbst.

Manuelle Canary-Analysen skalieren schlecht. Bei zehn Deployments am Tag starrt niemand 30 Minuten lang auf ein Dashboard, und das Gate wird stillschweigend zu "sah gut aus". Das bewährte Muster ist ein automatisierter Richter: Sie definieren das SLO und den Vergleich, und ein Controller bricht ab und setzt zurück, sobald der Canary sein Fehlerbudget schneller verbraucht als die Kontrolle.

Genau dieses Problem adressiert der AI Pilot von upstreamapi: Er liest das SLO-Signal während des Rollouts und löst einen automatischen Rollback aus, sobald die Fehlerrate die von Ihnen gesetzte Schwelle überschreitet. Er misst Fehlerrate und Latenz gegen die stabile Kohorte, mehr nicht. Wenn Sie bereits Argo-Rollouts-Analyse-Templates mit einer guten Prometheus-Abfrage betreiben, haben Sie einen Großteil derselben Fähigkeit. Sagen Sie das jedem, der Ihnen Magie verkaufen will. Ein gehostetes Pilot-Tool lohnt sich vor allem über heterogene Stacks hinweg, wo jedes Team sonst eigene Analyse-Templates pflegen müsste.

Ein häufiges Fehlermuster: Teams automatisieren den Promote-Schritt und nie den Abbruch. Eine Pipeline, die nur vorwärts weiß, ist ein Förderband.

Wie Sie erkennen, ob Ihr Canary-Prozess funktioniert, und wo Sie diese Woche anfangen

Ein Canary-Programm hat eigene Metriken. Verfolgen Sie diese über ein Quartal:

• Canary-Abbruchrate: Anteil der Canaries, die das Gate stoppt. Null bedeutet, dass das Gate blind ist. Über 20 bis 30 Prozent deuten meist auf instabile Schwellenwerte oder schwaches Testen vor dem Merge hin.

• Erkennungszeit am Canary: Minuten vom ersten fehlerhaften Request bis zum Abbruch. Das ist Ihre echte MTTD für Releases.

• Durchgerutschte Regressionen: Vorfälle, die auf ein Release zurückgehen, das den Canary bestanden hat. Jeder davon sollte ein Gate verändern.

• Mittlere Zeit bis zum Zurücksetzen: von der Abbruchentscheidung bis zu 100 Prozent Traffic auf der stabilen Version.

Führen Sie pro Service nur einen Canary gleichzeitig aus. Das Workbook rät dringend dazu, und der Grund ist praktisch: Zwei sich überlappende Änderungen machen die Zuordnung unmöglich, und Sie wissen nicht, welche Ihnen geschadet hat.

Wählen Sie diese Woche einen zustandslosen Service mit genug Traffic, um in 15 Minuten ein Signal zu liefern. Fügen Sie seinen Fehler- und Latenzmetriken ein Versionslabel hinzu. Schreiben Sie eine einzige Vergleichsabfrage, Canary gegen Kontrolle. Fahren Sie einen 5-Prozent-Canary mit manuellem Promote, und notieren Sie, was er in den letzten drei Vorfällen abgefangen hätte.

Dann stellen Sie die unbequeme Frage: Wenn der Canary um 02:00 Uhr gescheitert wäre, hätte dann irgendetwas ihn gestoppt, ohne dass ein Mensch wach ist?