Stufe 3 – Produktionsreife
Ziel: Stabiler, kontrollierter Betrieb geschäftskritischer Systeme.
Stufe 3 markiert den Übergang von „wir liefern Features“ zu „wir betreiben ein verlässliches Produkt“.
Hier verursachen Ausfälle reale Kosten – finanziell, reputativ oder operativ.
Stabilität ist kein Nebeneffekt mehr, sondern ein explizites Ziel.
Abgrenzung
| Stufe 2 | Stufe 3 | Stufe 4 | |
|---|---|---|---|
| Monitoring | Basis | SLO-basiert | Compliance-getrieben |
| Releases | automatisiert | kontrolliert + Rollout-Strategie | auditierbar |
| Incident-Prozess | implizit | definiert + trainiert | formalisiert |
| Security | Basis-Scans | Threat Model light | formale Risikoanalyse |
Stufe 3 ist die erste Stufe mit operativer Verantwortung auf Systemebene.
Typische Einsatzfälle
- Kernprodukt mit SLA / SLO
- Plattform für mehrere Teams oder Geschäftsbereiche
- Systeme mit regelmäßigen Releases (wöchentlich/täglich)
- Ausfälle verursachen direkte Geschäftskosten
Kontextbedingungen
| Faktor | Erwartung |
|---|---|
| Lebensdauer | ≥ 1 Jahr |
| Risiko | Signifikant |
| Releases | Häufig |
| Betrieb | Monitoring + On-Call |
| SLOs | Definiert und gemessen |
Anforderungen
- Automatisierte Tests für alle kritischen Flows
- Kontrollierte Release-Strategie (Feature Flags, Rollback)
- Definierte SLOs
- Aktives Monitoring & Alerting
- Dokumentierter Incident-Prozess
Teststrategie (Richtwerte)
- Unit: 70–85 % auf kritischen Modulen
- Integration: ≥ 50 % der relevanten Schnittstellen
- E2E: Alle geschäftskritischen Flows automatisiert
- Testkatalog dokumentiert
Coverage ist sekundär – kritische Pfade sind maßgeblich.
Minimale Gates
- Unit + Integration + E2E für kritische Pfade
- Feature Flags für risikominimierte Releases
- Rollback innerhalb definierter Zeit getestet
- SLOs definiert, gemessen und sichtbar
- Monitoring + Alerts + On-Call etabliert
- Incident-Prozess dokumentiert
- Threat Model (light) vorhanden
- SBOM / Dependency Scan im Pipeline-Gate
Stufe 3 erfordert aktive Betriebsfähigkeit, nicht nur gute Entwicklung.
Praktiken
- Testpyramide mit klaren Kernpfaden
- Canary- oder Blue-Green-Deployments
- Runbooks für Kernprozesse
- Strukturierte Logs + Tracing
- Regelmäßige Post-Mortems (blameless)
Rollen
On-Call-Verantwortung muss klar geregelt sein.
Akzeptierte Risiken
- Nicht jeder Fehler ist vorhersehbar
- Komplexität steigt und muss aktiv gemanagt werden
- Höherer Prozessaufwand als in Stufe 2
Wirtschaftlicher Kontext
Stufe 3 reduziert:
- Ungeplante Ausfallzeiten
- Eskalationen
- Vertrauensverlust
- Unkontrollierte Release-Risiken
Der Mehraufwand ist wirtschaftlich sinnvoll, wenn Ausfälle reale Geschäftskosten verursachen.