Eine API zu launchen ist ein bewusster Akt, keine Hoffnung. Go-Live-Readiness bedeutet, dass du weißt, was funktioniert, was fehlt und welche Risiken du akzeptierst. Dieser abschließende Teil der Serie führt alle Themen zusammen und gibt dir eine klare Entscheidungsgrundlage für den Launch.
Zielbild
Nach diesem Artikel kannst du:
- Go-Live-Kriterien in Must/Should/Nice kategorisieren
- Eine fundierte Go/No-Go-Entscheidung treffen
- Akzeptierte Risiken dokumentieren und kommunizieren
- Den Launch strukturiert durchführen
Kernfragen
- Welche Must/Should/Nice-Kriterien sind erfüllt?
- Welche Risiken akzeptieren wir bewusst?
- Wie sieht der Launch-Prozess aus?
Die drei Kategorien
Nicht alles muss perfekt sein. Aber manches muss fertig sein.
🔴 MUST-HAVE (Blocker)
Ohne diese Kriterien KEIN Go-Live.
- Security-relevant
- Compliance-relevant
- Core-Funktionalität
🟡 SHOULD-HAVE (Risiko)
Fehlen erhöht Risiko, aber Launch möglich.
- Operational Excellence
- Skalierbarkeit
- Dokumentiertes Risiko + Mitigationsplan
🟢 NICE-TO-HAVE (Backlog)
Wünschenswert, aber kein Launch-Kriterium.
- Developer Experience
- Convenience Features
- Ins Backlog für Post-Launch
Must-Have: Die Blocker
Diese Kriterien sind nicht verhandelbar. Jedes einzelne muss erfüllt sein.
1. API-Spezifikation
| Kriterium | Prüfung | Teil |
|---|---|---|
| OpenAPI vollständig | Alle Endpoints dokumentiert | 3 |
| Schema-Validierung in CI | Automatische Prüfung bei jedem PR | 19 |
| Beispiele vorhanden | Request/Response für jeden Endpoint | 18 |
| Error-Responses dokumentiert | Alle möglichen Fehlercodes | 8 |
# CI Gate: OpenAPI Validation
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Validate OpenAPI
run: |
npx @redocly/cli lint openapi/api.yaml
git show origin/main:openapi/api.yaml > /tmp/openapi-main.yaml
npx oasdiff breaking /tmp/openapi-main.yaml openapi/api.yaml
2. Authentifizierung & Autorisierung
| Kriterium | Prüfung | Teil |
|---|---|---|
| AuthN implementiert | Login, Token-Refresh, Logout | 9 |
| AuthZ für alle Endpoints | Kein Endpoint ohne Berechtigung | 10 |
| Policy Tests | Automatisierte Tests für alle Rollen | 10 |
| Token-Expiry konfiguriert | Access < 15 Min, Refresh < 7 Tage | 9 |
// Beispiel: AuthZ Policy Test
describe('Authorization Policies', () => {
it.each([
['admin', 'DELETE /users/:id', true],
['user', 'DELETE /users/:id', false],
['user', 'GET /users/me', true],
['anonymous', 'GET /users/me', false],
])('%s can %s: %s', async (role, action, allowed) => {
const [method, path] = action.split(' ');
const response = await request(app)
[method.toLowerCase()](path)
.set('Authorization', `Bearer ${tokens[role]}`);
if (allowed) {
expect(response.status).not.toBe(403);
} else {
expect(response.status).toBe(403);
}
});
});
3. Resilience & Limits
| Kriterium | Prüfung | Teil |
|---|---|---|
| Rate Limiting aktiv | Limits definiert und getestet | 13 |
| Timeouts konfiguriert | Server, DB, Downstream | 14 |
| Retries mit Backoff | Exponential Backoff + Jitter | 14 |
| Circuit Breaker | Für kritische Downstreams | 14 |
4. Observability
| Kriterium | Prüfung | Teil |
|---|---|---|
| Structured Logging | JSON-Format, Log-Schema | 16 |
| Request/Trace IDs | Durchgängige Korrelation | 16 |
| Metriken exportiert | Rate, Latency, Errors | 16 |
| Audit Logs | Sicherheitsrelevante Aktionen | 16 |
// Minimale Observability-Prüfung
describe('Observability', () => {
it('should return correlation headers', async () => {
const response = await request(app)
.get('/health/ready')
.set('traceparent', '00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01');
expect(response.headers['x-request-id']).toBeDefined();
if (response.headers['traceparent']) {
expect(response.headers['traceparent']).toMatch(/^00-/);
}
});
it('should expose metrics endpoint', async () => {
const response = await request(app).get('/metrics');
expect(response.status).toBe(200);
expect(response.text).toContain('http_requests_total');
expect(response.text).toContain('http_request_duration_seconds');
});
});
5. Operations & Support
| Kriterium | Prüfung | Teil |
|---|---|---|
| Health Endpoints | /health/live, /health/ready | 20 |
| Runbooks erstellt | Mindestens für P1-Szenarien | 20 |
| On-Call definiert | Erreichbarkeit, Eskalation | 20 |
| Rollback getestet | Prozess dokumentiert und geübt | 20 |
6. Security
| Kriterium | Prüfung | Teil |
|---|---|---|
| TLS enforced | HTTPS only, HSTS | 11 |
| OWASP Top 10 geprüft | Review oder Scan | 12 |
| Input Validation | Alle Inputs validiert | 8 |
| Security Headers | CSP, X-Content-Type-Options | 12 |
| Secrets Management | Keine Secrets im Code | 20 |
7. Datenschutz & Compliance
| Kriterium | Prüfung | Teil |
|---|---|---|
| Data Minimization | Nur notwendige Daten | 21 |
| Retention Policies | Fristen definiert | 21 |
| DSGVO-Endpoints | Export, Löschung möglich | 21 |
| PII in Logs maskiert | Automatische Redaktion | 21 |
Should-Have: Die Risiken
Diese Kriterien erhöhen die Betriebsqualität. Fehlen sie, ist ein Launch möglich, aber das Risiko muss dokumentiert sein.
Operational Excellence
| Kriterium | Risiko ohne | Mitigation |
|---|---|---|
| Dashboards | Probleme spät erkannt | Manuelle Log-Analyse |
| Alerts | Keine proaktive Warnung | Häufigeres Monitoring |
| Lasttest | Unbekannte Limits | Conservative Limits |
| Chaos Tests | Unbekannte Failure Modes | Erhöhte Wachsamkeit |
API-Qualität
| Kriterium | Risiko ohne | Mitigation |
|---|---|---|
| Idempotency Keys | Duplikate bei Retries | Dokumentation für Clients |
| Caching Headers | Höhere Last | Mehr Replicas |
| Versioning Policy | Unklare Erwartungen | Kommunikation |
| Deprecation Policy | Breaking Changes unklar | Changelog |
Dokumentation
| Kriterium | Risiko ohne | Mitigation |
|---|---|---|
| API Changelog | Änderungen unklar | Release Notes |
| Getting Started | Langsames Onboarding | Support |
| Error Catalog | Unklare Fehlerbehebung | Support |
Nice-to-Have: Das Backlog
Diese Kriterien sind wünschenswert, aber kein Launch-Hindernis.
| Kriterium | Benefit | Priorität Post-Launch |
|---|---|---|
| SDK/Client Libraries | Schnellere Integration | Hoch |
| API Explorer/Sandbox | Self-Service Testing | Mittel |
| Postman Collection | Developer Convenience | Mittel |
| Multi-Language Examples | Breitere Audience | Niedrig |
| Webhooks | Async Integration | Nach Bedarf |
Risiko-Register
Jedes akzeptierte Risiko muss dokumentiert sein.
Template
Vorlage für einen Risiko-Eintrag:
Titel: Risiko: <Kurzbeschreibung>
Details:
- Kategorie: Should-Have / Technical Debt
- Auswirkung: Was kann passieren?
- Wahrscheinlichkeit: Hoch / Mittel / Niedrig
- Betroffene: Wer ist betroffen?
Entscheidung
- Akzeptiert von: Name, Rolle
- Datum: Datum
- Begründung: Warum akzeptieren wir das Risiko?
Mitigation
- Sofort: Was tun wir jetzt?
- Geplant: Wann beheben wir es? (Ticket-Link)
Monitoring
- Indikator: Woran erkennen wir, dass das Risiko eintritt?
- Eskalation: Was tun wir dann?
Beispiel: Fehlender Lasttest
Risiko: Kein Lasttest vor Go-Live
Details
- Kategorie: Should-Have
- Auswirkung: Unbekannte Performance-Limits, mögliche Überlastung bei Traffic-Spike
- Wahrscheinlichkeit: Mittel (Launch-Traffic schwer vorhersagbar)
- Betroffene: Alle API-Consumer
Entscheidung (Beispiel)
- Akzeptiert von: Tech Lead, Product Owner
- Datum: 2026-01-20
- Begründung: Launch-Deadline, initiale User-Zahl gering
Mitigation (Beispiel)
- Sofort: Conservative Rate Limits (100 RPS), erhöhtes Monitoring
- Geplant: Lasttest in Woche 2 nach Launch (JIRA-123)
Monitoring (Beispiel)
- Indikator: Latency p99 > 500ms, Error Rate > 1%
- Eskalation: Auto-Scaling aktivieren, ggf. temporäre Limits verschärfen
Go/No-Go Entscheidung
Der Launch ist eine bewusste Entscheidung, keine Hoffnung.
Entscheidungsmatrix
Go-Live Meeting Agenda
Go-Live Decision Meeting
Teilnehmer
- Tech Lead (Pflicht)
- Product Owner (Pflicht)
- Security (bei Public API)
- Operations/SRE (Pflicht)
Agenda (30 Min)
- Must-Have Review (10 Min)
- Checkliste durchgehen
- Jeder Punkt: ✅ oder ❌
- Bei ❌: Blocker-Diskussion
- Should-Have & Risiken (10 Min)
- Fehlende Should-Haves
- Risiko-Register Review
- Akzeptanz-Entscheidung
- Launch-Plan (5 Min)
- Zeitpunkt
- Rollout-Strategie (Big Bang vs. Staged)
- Kommunikation
- Entscheidung (5 Min)
- GO / NO-GO / CONDITIONAL GO
- Dokumentation der Entscheidung
- Nächste Schritte
Launch-Prozess
Ein strukturierter Launch minimiert Risiken.
Launch-Phasen
Launch-Day Checklist
T-1 (Tag vor Launch)
- [ ] Finale Deployment in Production
- [ ] Smoke Tests bestanden
- [ ] Monitoring-Dashboards bereit
- [ ] On-Call-Rotation bestätigt
- [ ] Rollback-Plan reviewed
- [ ] Status-Page vorbereitet
T-0 (Launch)
- [ ] Dokumentation live geschaltet
- [ ] API-Keys aktiviert
- [ ] Announcement gesendet
- [ ] Social Media / Blog Post
- [ ] Support-Team informiert
T-0 + 1h
- [ ] Error Rate < 1%?
- [ ] Latency im SLO?
- [ ] Keine Security Alerts?
- [ ] Erste Requests von externen Clients?
T-0 + 4h
- [ ] Metriken stabil?
- [ ] Support-Tickets reviewed
- [ ] Feedback gesammelt
T+1 (Tag nach Launch)
- [ ] Post-Launch Review
- [ ] Offene Issues priorisiert
- [ ] Lessons Learned dokumentiert
Rollback-Trigger
Automatisch (Alerting)
- Error Rate > 5% für > 5 Min
- Latency p99 > 2× SLO für > 5 Min
- Security Alert (Critical)
Manuell (On-Call Entscheidung)
- Data Corruption vermutet
- Kritische Bugs gemeldet
- Stakeholder-Eskalation
Rollback-Zeit: < 5 Minuten
Post-Launch
Der Launch ist nicht das Ende, sondern der Anfang.
Erste Woche
| Tag | Fokus | Aktivitäten |
|---|---|---|
| +1 | Stabilität | Metriken, Support-Tickets, Hotfixes |
| +2 | Feedback | User-Feedback sammeln, Priorisieren |
| +3 | Dokumentation | FAQ ergänzen, Fehlendes nachliefern |
| +4 | Optimierung | Performance-Tuning, Limits anpassen |
| +5 | Review | Retrospektive, Lessons Learned |
Metriken für Launch-Erfolg
Technical Health
- Availability: > 99.5%
- Error Rate: < 1%
- Latency p99: < SLO
Adoption
- API Keys issued
- Unique Clients / Day
- Requests / Day
Developer Experience
- Time to First Request
- Support Tickets / Client
- Documentation Page Views
Business Impact
- Integrations completed
- Revenue (falls monetarisiert)
Regeln und Anti-Patterns
Do
- Must-Haves sind nicht verhandelbar: Kein Launch ohne Security und Compliance
- Risiken dokumentieren: Was fehlt, warum, und wie mitigiert
- Staged Rollout: Intern → Beta → Public
- Hypercare einplanen: Erste Woche ist kritisch
- Launch feiern: Team-Leistung anerkennen
Don't
- Wir fixen das nach Launch: Nur für Should-Haves mit dokumentiertem Risiko
- Big Bang ohne Fallback: Immer Rollback-Plan haben
- Launch am Freitag: Nie vor dem Wochenende
- Ohne Monitoring launchen: Blind fliegen ist gefährlich
- Ohne Support-Bereitschaft: Wer antwortet auf Fragen?
Artefakt: Go-Live-Checklist
# Go-Live Checklist: [API Name]
**Version**: 1.0
**Geplanter Launch**: [Datum]
**Entscheidung**: [ ] GO / [ ] NO-GO / [ ] CONDITIONAL
## Must-Have (Alle erforderlich)
### API-Spezifikation
- [ ] OpenAPI vollständig dokumentiert
- [ ] Schema-Validierung in CI aktiv
- [ ] Beispiele für alle Endpoints
- [ ] Error-Responses dokumentiert
### Security & Auth
- [ ] AuthN implementiert und getestet
- [ ] AuthZ für alle Endpoints
- [ ] TLS enforced (HTTPS only)
- [ ] OWASP Top 10 Review
- [ ] Security Headers konfiguriert
- [ ] Secrets in Vault/Manager
### Resilience
- [ ] Rate Limiting aktiv
- [ ] Timeouts konfiguriert
- [ ] Retries mit Backoff
- [ ] Circuit Breaker (kritische Deps)
### Observability
- [ ] Structured Logging (JSON)
- [ ] Request/Trace IDs
- [ ] Metriken exportiert
- [ ] Audit Logs aktiv
### Operations
- [ ] Health Endpoints (/live, /ready)
- [ ] Runbooks für P1-Szenarien
- [ ] On-Call definiert
- [ ] Rollback getestet
### Datenschutz
- [ ] Data Minimization geprüft
- [ ] Retention Policies definiert
- [ ] DSGVO-Endpoints (Export/Delete)
- [ ] PII in Logs maskiert
## Should-Have (Risiko dokumentiert)
- [ ] Dashboards und Alerts
- [ ] Lasttest gegen SLOs
- [ ] Idempotency Keys
- [ ] Caching Headers
- [ ] Versioning Policy
- [ ] Deprecation Policy
- [ ] API Changelog
### Fehlende Should-Haves → Risiko-Register
| Item | Risiko-ID | Akzeptiert von |
|------|-----------|----------------|
| | | |
## Nice-to-Have (Backlog)
- [ ] SDK/Client Libraries
- [ ] API Explorer/Sandbox
- [ ] Postman Collection
- [ ] Webhooks
## Launch-Details
### Rollout-Strategie
- [ ] Big Bang
- [ ] Staged: Internal → Beta → Public
### Zeitplan
- Internal: [Datum]
- Beta: [Datum]
- Public: [Datum]
### Kommunikation
- [ ] Announcement vorbereitet
- [ ] Dokumentation URL: ___
- [ ] Support-Kanal: ___
## Sign-Off
| Rolle | Name | Datum | Unterschrift |
|---------------|------|-------|--------------|
| Tech Lead | | | |
| Product Owner | | | |
| Security | | | |
| Operations | | | |
## Entscheidung
**Datum**: ___
**Status**: [ ] GO / [ ] NO-GO / [ ] CONDITIONAL
**Bedingungen (falls CONDITIONAL)**:
-
-
**Nächste Schritte**:
-
-
Checkliste
Für die Go/No-Go-Entscheidung
- [ ] Alle Must-Haves als erfüllt abgehakt
- [ ] Fehlende Should-Haves im Risiko-Register
- [ ] Risiken von Stakeholdern akzeptiert
- [ ] Launch-Plan erstellt
- [ ] Rollback-Prozess klar
Für den Launch-Tag
- [ ] Monitoring-Dashboards offen
- [ ] On-Call erreichbar
- [ ] Rollback-Kommandos bereit
- [ ] Kommunikationskanäle besetzt
- [ ] Stakeholder informiert
Für die Hypercare-Phase
- [ ] Tägliche Check-ins geplant
- [ ] Feedback-Sammlung aktiv
- [ ] Schnelle Hotfix-Pipeline
- [ ] Kapazität für Support
Fazit: Die Serie im Überblick
In 22 Teilen haben wir den kompletten Lebenszyklus einer API durchlaufen:
| Teil | Thema | Kernaussage |
|---|---|---|
| 1 | Einstieg | APIs sind Produkte, nicht nur Technik |
| 2 | Ziele & Scope | Verstehe das Problem vor der Lösung |
| 3 | Stil & Prinzipien | Konsistenz schlägt Perfektion |
| 4 | Ressourcen | Denke in Ressourcen, nicht in Funktionen |
| 5 | HTTP-Semantik | Nutze HTTP wie vorgesehen |
| 6 | Request/Response | Klare Strukturen, keine Überraschungen |
| 7 | Pagination | Große Datenmengen handhabbar machen |
| 8 | Fehlerbehandlung | Fehler sind Teil der API |
| 9 | Authentifizierung | Wer bist du? |
| 10 | Autorisierung | Was darfst du? |
| 11 | Transport | Sichere Verbindungen |
| 12 | OWASP | Bekannte Risiken vermeiden |
| 13 | Rate Limiting | Ressourcen fair verteilen |
| 14 | Resilience | Ausfälle einplanen |
| 15 | Caching | Performance durch Wiederverwendung |
| 16 | Observability | Sehen, was passiert |
| 17 | Versionierung | Änderungen managen |
| 18 | Dokumentation | Nutzbar machen |
| 19 | Testing | Qualität sichern |
| 20 | Betrieb | Zuverlässig laufen |
| 21 | Datenschutz | Daten respektieren |
| 22 | Go-Live | Bewusst launchen |
Die wichtigste Erkenntnis: Eine gute API entsteht nicht durch Zufall, sondern durch bewusste Entscheidungen in jeder Phase – vom ersten Design bis zum Go-Live und darüber hinaus.
Dies ist Teil 22 und der Abschluss der Serie API-Design. Alle Teile findest du in der Serie: API-Design.