Resilienz und Deploy-Sicherheit
Übersicht
Dinge werden kaputtgehen. Die Haltung ist nicht „jeden Fehler verhindern“, sondern klein scheitern, schnell erholen und jedes Mal lernen. Zuverlässigkeit ist nicht die Abwesenheit von Fehlern; es ist der begrenzte Schadensradius und die kurze Wiederherstellungszeit, wenn der Fehler kommt.
Deploy-Sicherheit – Jeder Deploy muss umkehrbar und progressiv ausgerollt werden
- Das Artefakt ist unveränderlich und wird befördert, nicht neu gebaut. Ein Image, einmal in CI gebaut und durch seinen Content-Digest identifiziert, durchläuft Preview → Staging → Production unverändert. Ein Wiederaufbau pro Umgebung bedeutet, etwas auszuliefern, das nie getestet wurde.
- Tags sind veränderliche Zeiger; der Digest ist die Identität. Ein Tag kann überschrieben werden und stillschweigend woanders hinzeigen. Ein Content-Digest nicht. Jede Umgebung zeichnet den Digest auf, den sie validiert hat, und Production führt nur einen Digest aus, den eine niedrigere Umgebung validiert hat – daher ist „das exakt getestete Ding“ eine Eigenschaft, die die Pipeline erzwingt, und keine Disziplin, an die sich jemand erinnern muss.
- Eine menschliche Entscheidung geht Production voraus. Für einen Solo-Maintainer ist dies eine bewusste Pause und ein Prüfnachweis, nicht eine Aufgabentrennung. Gib an, um was es sich handelt; übertreibe nicht.
- Die laufende Version wird zur Deployment-Zeit injiziert, nie in das Image eingebacken. Eine als Build-Argument eingebackene Version erzwingt einen Rebuild, um einen Release zu stempeln, und genau dieser Rebuild soll durch Beförderung vermieden werden.
- Wenn die Infrastruktur in einem eigenen Repository lebt, koordiniere mittels Expand/Contract. Die Infrastruktur wird zuerst expandiert (additiv, abwärtskompatibel), die Anwendung nutzt die neue Fähigkeit in einem späteren Deploy, und die Infrastruktur zieht sich zusammen, sobald kein live-Artefakt mehr von der alten Form abhängt – die gleiche Disziplin wie bei einem Schema-Change (siehe
zero-downtime-migrations). Die Invariante: versende niemals ein Anwendungsartefakt, das eine noch nicht live geschaltete Infrastrukturänderung erfordert. Wenn dies eingehalten wird, ist jedes Repository unabhängig umkehrbar, was Rollback handhabbar macht, wenn die beiden nicht synchron sind. - Rolle nur vorwärts, wenn du auch rückwärts rollen kannst. Ein Rollback-Pfad existiert und ist getestet, bevor eine riskante Änderung ausgeliefert wird. „Wie machen wir das rückgängig?“ wird im Plan beantwortet, nicht während des Vorfalls.
- Rollback bedeutet, den vorher guten Digest wieder auszurollen. Dieser Digest ist noch in der Registry und immer noch unveränderlich, daher ist Rollback eine umgekehrte Beförderung – niemals ein Rebuild und niemals ein Rebuild „wie es war“.
- Progressive Exposure. Neue Versionen erreichen die Nutzer schrittweise (health-gated Rollout, Canary wo unterstützt), so dass ein schlechter Release nur einen Bruchteil, nicht alle trifft.
- Schema-Änderungen sind von Code-Deployments entkoppelt und folgen Expand/Contract (siehe
zero-downtime-migrations). Ein Deployment darf niemals eine gleichzeitige destruktive Migration erfordern. - Eine Deploy-Readiness-Checkliste prüft vor Production: Observability vorhanden, Rollback verifiziert, Migrationen expand-sicher, SLOs ungebrochen.
Incident Response – Fehler sind ein Lerninput
- Klassifiziere nach Schweregrad und reagiere angemessen; habe einen bekannten Pfad, um die richtigen Personen einzubeziehen.
- Schuld-freie Postmortems für jeden nutzerwirksamen Vorfall. Geschriebener Zeitstrahl, beitragende Ursachen (systemisch, nicht persönlich), konkrete Maßnahmen. Die Frage ist „was im System hat dies zugelassen“, niemals „wer hat Mist gebaut.“
- Maßnahmen werden nachverfolgt, nicht vergessen – sie fließen in das Future-Considerations-Dokument (siehe
recording-decisions) und werden zu echter Arbeit. - Das Error Budget regiert. Wenn die Zuverlässigkeit aufgebraucht ist, haben Zuverlässigkeitsaufgaben Vorrang vor Features, bis sich das Budget erholt.
Kurzreferenz
| Vor einem riskanten Deploy | Bestätigen |
|---|---|
| Artefakt | Einmal in CI gebaut; per Digest befördert; das gleiche, das Staging validiert hat |
| Gate | Eine menschliche Entscheidung, vor Production aufgezeichnet |
| Rollback | Pfad existiert und ist getestet |
| Exposure | Schrittweise/Canary, nicht alles auf einmal |
| Schema | Expand-sicher, entkoppelt vom Code-Deployment |
| Observability | Kannst du sehen, ob etwas schief geht? |
Wann dies skalieren
Lokale/Pre-Launch-Projekte schreiben diese Regeln jetzt, aktivieren sie ab den ersten echten Nutzern. Die Eigenschaften sind portabel – einmal bauen, befördern was getestet wurde, vor Production entscheiden, Rollback-fähig sein –, aber die Mechanismen nicht: eine Digest-Beförderung ist auf einem Container-Host sinnvoll und für eine statische Seite weitgehend irrelevant, und eine Managed Platform kann Preview-Umgebungen und sofortiges Rollback kostenlos bereitstellen. Benenne den Mechanismus im Deployment-Skill des Projekts; behalte die Eigenschaft hier. Stack-Mechanismen (k8s Probes, Canary, Per-PR-Envs): cloud-delivery-aks.
Vollständige Begründung: Artikel XII der Verfassung, gebündelt in engineering-constitution/references/engineering-constitution.md.