Ist Ihre Infrastruktur ein Risiko? Hosting, CI/CD und Monitoring bewerten

Zusammenfassung

Die meiste Infrastruktur ist nicht offensichtlich kaputt — sie sammelt stillschweigend Risiko an. Kein Monitoring bedeutet, dass Sie von Ausfällen durch Kunden erfahren. Keine getesteten Backups bedeuten, dass Ihr Disaster-Recovery-Plan Fiktion ist. Unklare CI/CD bedeutet, dass Deployments angsteinflößend sind statt langweilig. Dieser Leitfaden führt Sie durch eine systematische Bewertung Ihres Hostings, CI/CD, Monitorings, Disaster Recoverys und Ihrer Cloud-Kosten — mit einer Entscheidungsmatrix zur Priorisierung.

Voraussetzungen

• Admin-Zugang zu Ihrer Hosting-Umgebung (Cloud-Konsole, Server-SSH)
• Zugang zur CI/CD-Konfiguration (GitHub Actions, GitLab CI, Jenkins, etc.)
• Zugang zu Monitoring-Tools (falls vorhanden)
• Eine Liste aller Produktionsservices und deren Abhängigkeiten
• Cloud-Abrechnungszugang für Kostenanalyse

Schritt 1: Hosting-Bewertung

Ihr Hosting-Setup ist das Fundament. Wenn es falsch ist, ist alles darauf Gebaute instabil.

Hosting-Audit-Checkliste

Infrastruktur-Inventar:
[ ] Alle Produktionsserver/-services sind dokumentiert
[ ] IP-Adressen, Domains und DNS-Einträge sind erfasst
[ ] Server-OS-Versionen sind aktuell (innerhalb des Support-Lifecycles)
[ ] Keine Server laufen mit End-of-Life-Betriebssystemen
[ ] SSH-Zugang nutzt schlüsselbasierte Authentifizierung (keine Passwörter)
[ ] Firewall ist konfiguriert (nur nötige Ports offen)
[ ] TLS/SSL-Zertifikate sind gültig und erneuern sich automatisch

Architektur:
[ ] Single Points of Failure sind identifiziert
[ ] Datenbank hat Replikation oder automatisiertes Backup
[ ] Anwendungsserver können die 2-fache aktuelle Last bewältigen
[ ] Statische Assets werden via CDN ausgeliefert
[ ] Load Balancer ist konfiguriert (bei mehreren App-Servern)
[ ] Health-Check-Endpoints existieren für jeden Service

Server-Ressourcen-Assessment

# Aktuelle Ressourcennutzung prüfen
# CPU-Auslastung (letzte 15 Minuten)
uptime

# Arbeitsspeichernutzung
free -h

# Festplattennutzung
df -h

# Festplatten-I/O
iostat -x 1 5

# Netzwerkverbindungen
ss -tuln

# Laufende Prozesse nach Ressourcenverbrauch
top -bn1 | head -20

# Docker-Ressourcennutzung (falls zutreffend)
docker stats --no-stream

# Kubernetes-Ressourcennutzung (falls zutreffend)
kubectl top nodes
kubectl top pods --all-namespaces

Hosting-Typ-Bewertung

Hosting-Typ     | Gut für                     | Aufpassen bei
----------------+-----------------------------+----------------------------
Shared Hosting  | Marketing-Sites, Blogs      | Keine Skalierung, Nachbarn
VPS (Hetzner,   | Kleine-mittlere Apps, Dev-  | Manuelle Verwaltung, Single
DigitalOcean)   | Umgebungen                  | Region, kein Auto-Scaling
Managed K8s     | Produktions-Workloads,      | Komplexität, Kosten,
(GKE, EKS)      | Microservices               | Lernkurve für kleine Teams
Serverless      | Eventgetrieben, variable    | Cold Starts, Vendor Lock-in,
(Lambda, Cloud  | Last, APIs                  | Debugging schwierig
Functions)      |                             |
PaaS (Vercel,   | Frontend, einfache Backends | Kosten bei Skalierung,
Render, Fly)    |                             | eingeschränkte Kontrolle

Entscheidung: Wenn Ihr Team < 3 Ingenieure hat und kein dediziertes
DevOps, nutzen Sie PaaS oder Managed Services. Kubernetes ist für
Teams, die es sich leisten können, es zu betreiben.

Schritt 2: CI/CD-Assessment

Deployments sollten langweilig sein. Wenn sie es nicht sind, muss Ihr CI/CD verbessert werden.

CI/CD-Gesundheitscheckliste

Build-Pipeline:
[ ] Jeder Commit löst einen automatisierten Build aus
[ ] Build-Zeit ist unter 10 Minuten (< 5 bevorzugt)
[ ] Build-Fehler werden sofort benachrichtigt (Slack, E-Mail)
[ ] Build-Artefakte sind versioniert und gespeichert
[ ] Build ist reproduzierbar (gleicher Commit = gleiches Artefakt)

Test-Pipeline:
[ ] Unit-Tests laufen bei jedem PR
[ ] Integrationstests laufen bei Merge in Main
[ ] Testabdeckung wird gemessen (Ziel: 70%+ für kritische Pfade)
[ ] Flaky Tests werden verfolgt und behoben (nicht nur wiederholt)
[ ] Security-Scanning läuft automatisch (Dependency-Audit, SAST)

Deployment-Pipeline:
[ ] Deployment auf Staging ist automatisiert bei Merge in Main
[ ] Deployment auf Produktion erfordert explizite Freigabe
[ ] Rollback ist in unter 5 Minuten möglich
[ ] Datenbankmigrationen sind vorwärtskompatibel
[ ] Deployment erstellt einen getaggten Release mit Changelog
[ ] Zero-Downtime-Deployment ist konfiguriert

Umgebungsmanagement:
[ ] Staging-Umgebung spiegelt Produktion
[ ] Umgebungsvariablen werden sicher verwaltet (nicht im Code)
[ ] Secrets-Rotation ist ohne Deployment möglich
[ ] Feature Flags existieren für graduelle Rollouts

CI/CD-Gesundheit messen — DORA-Metriken

Metrik                       | Elite     | Hoch     | Mittel   | Niedrig
-----------------------------+-----------+----------+----------+----------
Deployment-Frequenz          | Mehrmals  | Wöchent- | Monatlich| Monatlich
                             | täglich   | lich     | -wöch.   | -jährlich
Lead Time for Changes        | < 1 Std   | 1 Tag -  | 1 Woche -| 1 Monat -
                             |           | 1 Woche  | 1 Monat  | 6 Monate
Change Failure Rate          | 0-15%     | 16-30%   | 16-30%   | 46-60%
Mean Time to Recovery        | < 1 Std   | < 1 Tag  | < 1 Tag  | 1 Woche -
(MTTR)                       |           |          |          | 1 Monat

Wie messen:
- Deployment-Frequenz: Deployments pro Woche zählen
- Lead Time: Zeit von Commit bis Produktion messen
- Change Failure Rate: (fehlgeschlagene / gesamte Deployments)
- MTTR: Durchschnittliche Zeit von Erkennung bis Behebung

Häufige CI/CD-Anti-Patterns

Anti-Pattern                    | Lösung
--------------------------------+------------------------------------
"Funktioniert auf meinem Rechner"| Docker-basierte Build-Umgebung
Manuelle Deployment-Schritte    | Alles in der Pipeline automatisieren
Keine Staging-Umgebung          | Produktion spiegeln mit gleicher Konfig
Tests laufen nur lokal          | Tests in CI erzwingen, Merge blockieren
Secrets in Code/Config-Dateien  | CI/CD Secret Management nutzen
Kein Rollback-Plan              | Blue-Green oder Rolling Deployment
Build dauert 30+ Minuten        | Parallelisieren, Dependencies cachen
Flaky Tests werden wiederholt   | Flaky Tests tracken, Ursache beheben

Schritt 3: Monitoring-Lücken

Wenn Sie nicht wissen, dass etwas kaputt ist, können Sie es nicht reparieren. Die meisten Teams haben erhebliche Monitoring-Lücken.

Die vier Säulen des Monitorings

Säule           | Was sie Ihnen sagt             | Tools
----------------+--------------------------------+-----------------------
Metriken        | Ist das System gesund?         | Prometheus, Datadog,
                | (CPU, Memory, Requestrate,     | CloudWatch
                | Fehlerrate, Latenz)            |
Logs            | Was ist passiert?              | ELK, Loki, CloudWatch
                | (Anwendungsevents, Fehler,     | Logs
                | Zugriffslogs)                  |
Traces          | Wo ist es langsam?             | Jaeger, Tempo, Datadog
                | (Requestfluss durch Services)  | APM, New Relic
Alerts          | Wann sollten Sie aufwachen?    | PagerDuty, Opsgenie,
                | (Schwellwertüberschreitungen,  | Alertmanager
                | Anomalien, Ausfälle)           |

Monitoring-Checkliste

Infrastruktur-Monitoring:
[ ] CPU-Auslastung pro Server/Container (Alert > 80% anhaltend)
[ ] Memory-Nutzung (Alert > 85%)
[ ] Festplattennutzung (Alert > 80%)
[ ] Netzwerkdurchsatz und -fehler
[ ] SSL-Zertifikat-Ablauf (Alert 30 Tage vorher)
[ ] DNS-Auflösungszeit

Anwendungs-Monitoring:
[ ] Requestrate (Anfragen pro Sekunde)
[ ] Fehlerrate (5xx-Antworten / Gesamtantworten)
[ ] Latenz (p50, p95, p99)
[ ] Apdex-Score oder SLI/SLO-Tracking
[ ] Hintergrund-Job-Queue-Tiefe und Fehlerrate
[ ] Datenbankabfrage-Performance (Slow-Query-Log)

Business-Monitoring:
[ ] Nutzer-Registrierungen / Logins (plötzliche Drops = Problem)
[ ] Zahlungsabwicklung (Fehler, Erfolgsrate)
[ ] Kernfunktions-Nutzung (funktioniert das Kernprodukt?)
[ ] API-Nutzung nach Client (wer konsumiert was?)

Alert-Qualität:
[ ] Jeder Alert hat ein verlinktes Runbook
[ ] Alerts sind handlungsrelevant (nicht nur "CPU ist hoch")
[ ] Alert-Müdigkeit wird gemessen (ignorierte Alerts sind falsch)
[ ] On-Call-Rotation existiert mit Eskalationsrichtlinie

Minimaler Monitoring-Stack

# Für kleine Teams (< 5 Ingenieure), hier anfangen:

1. Uptime-Monitoring: UptimeRobot oder Better Stack (kostenlos)
   - Jede Produktions-URL jede Minute pingen
   - Alert via Slack + SMS

2. Fehlertracking: Sentry (kostenlose Stufe)
   - Fängt unbehandelte Exceptions ab
   - Gruppiert Fehler, zeigt Häufigkeit

3. Log-Aggregation: Loki + Grafana oder Managed Service
   - Logs über alle Services durchsuchen
   - Fehler mit Zeitstempeln korrelieren

4. Infrastruktur-Metriken: Prometheus + Grafana oder Datadog
   - CPU, Memory, Disk, Network
   - Benutzerdefinierte Anwendungsmetriken

Einrichtungszeit: 4-8 Stunden
Kosten: 0-50 EUR/Monat für kleine Deployments

Schritt 4: Disaster Recovery — RTO und RPO

Jedes Unternehmen hat Disaster-Recovery-Bedürfnisse. Die meisten kennen sie nicht, bis es zu spät ist.

Definieren Sie Ihre RTO und RPO

RTO (Recovery Time Objective): Wie lange kann Ihr Service ausfallen?
RPO (Recovery Point Objective): Wie viele Daten können Sie sich leisten zu verlieren?

Beispielszenarien:

E-Commerce-Plattform:
  RTO: 1 Stunde (jede Stunde Ausfall = entgangener Umsatz)
  RPO: 0 (null Datenverlust bei Bestellungen)
  → Erfordert: Hot Standby, Echtzeit-Replikation, automatisches Failover

Internes Wissenssystem:
  RTO: 24 Stunden (Team kann einen Tag ohne arbeiten)
  RPO: 24 Stunden (einen Tag Bearbeitungen verlieren ist akzeptabel)
  → Erfordert: Tägliche Backups, dokumentiertes Restore-Verfahren

SaaS-Produkt:
  RTO: 4 Stunden (SLA-Verpflichtung)
  RPO: 1 Stunde (stündliche Backups oder WAL-Shipping)
  → Erfordert: Automatisierte Backups, getestetes Restore, Standby-Infra

Disaster-Recovery-Audit

Backups:
[ ] Automatisierte Backups existieren für alle Datenbanken
[ ] Backup-Frequenz entspricht RPO-Anforderung
[ ] Backups werden offsite gespeichert (andere Region/Anbieter)
[ ] Backup-Verschlüsselung ist aktiviert
[ ] Backup-Restore wurde in den letzten 90 Tagen getestet
[ ] Restore-Zeit ist dokumentiert und innerhalb der RTO

Failover:
[ ] Failover-Verfahren ist dokumentiert
[ ] Failover wurde getestet (nicht nur dokumentiert)
[ ] DNS-TTL ist niedrig genug für schnelles Failover (300s oder weniger)
[ ] Anwendung kann in einer anderen Region/Zone laufen
[ ] Datenbank-Replikation ist konfiguriert und überwacht

Kommunikation:
[ ] Incident-Response-Team ist definiert
[ ] Kommunikationskanäle existieren (nicht abhängig von der ausfallenden Infra)
[ ] Statusseite läuft auf separater Infrastruktur
[ ] Kundenbenachrichtigungs-Vorlage ist vorbereitet

Testen Sie Ihre Backups

# PostgreSQL Backup-Test
# 1. Backup erstellen
pg_dump -Fc mydb > /backup/mydb_$(date +%Y%m%d).dump

# 2. In Test-Datenbank wiederherstellen
createdb mydb_restore_test
pg_restore -d mydb_restore_test /backup/mydb_latest.dump

# 3. Datenintegrität verifizieren
psql mydb_restore_test -c "SELECT count(*) FROM users;"
psql mydb_restore_test -c "SELECT count(*) FROM orders;"

# 4. Zahlen mit Produktion vergleichen
# Wenn sie übereinstimmen, funktioniert Ihr Backup.

# 5. Aufräumen
dropdb mydb_restore_test

# Diesen Test monatlich einplanen. In den Kalender eintragen.

Schritt 5: Cloud-Kostenoptimierung

Cloud-Rechnungen wachsen still. Wenn jemand endlich hinschaut, zahlen Sie 2-5x mehr als nötig.

Schnelle Kosten-Gewinne

Prüfpunkt                       | Typische Ersparnis | Aufwand
---------------------------------+--------------------+--------
Überprovisionierte VMs anpassen  | 20-40%             | Niedrig
Ungenutzte Ressourcen löschen    | 5-15%              | Niedrig
(ungenutzte Volumes, alte        |                    |
Snapshots, idle Load Balancer)   |                    |
Reserved/Committed Use Rabatte   | 30-60%             | Mittel
nuten                            |                    |
Dev/Staging nachts/WE stoppen    | 40-70% auf Dev     | Niedrig
Auf ARM-Instanzen wechseln       | 20-30%             | Mittel
(Graviton, Ampere)               |                    |
Datenübertragung optimieren      | 10-30%             | Mittel
(CDN, Komprimierung, Caching)    |                    |
Log-Storage-Kosten prüfen        | 10-50%             | Niedrig
(Aufbewahrungsrichtlinien)       |                    |

Kostentransparenz-Checkliste

[ ] Resource-Tagging wird durchgesetzt (Team, Projekt, Umgebung)
[ ] Monatliche Kostenberichte werden vom Engineering geprüft
[ ] Kosten pro Service/Team werden verfolgt
[ ] Budget-Alerts sind konfiguriert (50%, 80%, 100% des Budgets)
[ ] Ungenutzte Ressourcen werden monatlich identifiziert
[ ] Kostenanomalien-Erkennung ist aktiviert (plötzliche Spitzen)

Kostenvergleich "Richtiges Tool"

# Beispiel: 4-Core, 16GB App-Server betreiben

AWS EC2 (On-Demand, eu-central-1, t3.xlarge):
  $0,1664/Stunde × 730 Stunden = ~$121/Monat

AWS EC2 (1-Jahr Reserved, ohne Vorauszahlung):
  $0,105/Stunde × 730 Stunden = ~$77/Monat (36% Ersparnis)

Hetzner Cloud (CX41):
  ~15 EUR/Monat (88% Ersparnis vs AWS On-Demand)

Hetzner Dedicated (AX41-NVMe):
  ~44 EUR/Monat (64% Ersparnis, Bare-Metal-Performance)

Frage: Braucht Ihr Workload AWS-spezifische Services
(RDS, SQS, Lambda)? Wenn nicht, kann ein europäischer VPS-Anbieter
das gleiche Ergebnis zu 70-90% weniger Kosten liefern.

Schritt 6: Infrastruktur-Entscheidungsmatrix

Nach dem Assessment priorisieren Sie, was zu beheben ist. Nicht alles ist gleich dringend.

Risikobewertungsmatrix

Für jeden Befund bewerten:

Auswirkung (1-5):
  1 = Kosmetisch / geringfügige Unannehmlichkeit
  2 = Beeinträchtigte Erfahrung für einige Nutzer
  3 = Serviceunterbrechung für einige Nutzer
  4 = Vollständiger Serviceausfall
  5 = Datenverlust oder Sicherheitsvorfall

Wahrscheinlichkeit (1-5):
  1 = Sehr unwahrscheinlich (einmal in 5+ Jahren)
  2 = Unwahrscheinlich (einmal pro Jahr)
  3 = Möglich (einmal pro Quartal)
  4 = Wahrscheinlich (einmal pro Monat)
  5 = Fast sicher (wöchentlich oder öfter)

Risiko-Score = Auswirkung × Wahrscheinlichkeit

Priorität:
  20-25: Kritisch — diese Woche beheben
  12-19: Hoch — diesen Monat beheben
   6-11: Mittel — für nächstes Quartal planen
   1-5:  Niedrig — Backlog

Beispiel-Assessment-Ergebnis

Befund                           | Ausw. | Wahrsch. | Risiko | Priorität
---------------------------------+-------+----------+--------+----------
Kein getesteter Backup-Restore   |   5   |    3     |   15   | Hoch
Kein Monitoring oder Alerting    |   4   |    4     |   16   | Hoch
SSH Passwort-Auth aktiviert      |   5   |    2     |   10   | Mittel
Keine Staging-Umgebung           |   3   |    4     |   12   | Hoch
Manuelle Deployments             |   3   |    4     |   12   | Hoch
Überprovisionierte Cloud-Res.    |   1   |    5     |    5   | Niedrig
Keine Log-Aggregation            |   2   |    4     |    8   | Mittel
SSL-Zertifikat erneuert nicht    |   4   |    3     |   12   | Hoch
Kein Incident-Response-Plan      |   4   |    2     |    8   | Mittel
Dev-Umgebung nutzt Prod-Daten    |   5   |    3     |   15   | Hoch

Problembehandlung & Hinweise

"Wir haben keine Zeit, alles zu beheben"

Müssen Sie nicht. Nutzen Sie die Risikomatrix, um sich auf Befunde mit hoher Auswirkung und hoher Wahrscheinlichkeit zu konzentrieren. Die Top-3-Befunde zu beheben eliminiert meist 80% des Risikos. Planen Sie den Rest als Teil der regulären Engineering-Arbeit — eine Infrastrukturverbesserung pro Sprint.

"Unsere Cloud-Rechnung ist zu hoch, aber wir können nicht migrieren"

Starten Sie mit den Quick Wins: Instanzen richtig dimensionieren, ungenutzte Ressourcen löschen, Dev-Umgebungen zeitgesteuert stoppen. Das erfordert keine Architekturänderungen und spart typisch 20-40%. Dann evaluieren Sie Reserved Instances oder Committed-Use-Rabatte für stabile Workloads.

"Wir wissen nicht, was wir betreiben"

Das ist Befund #1. Erstellen Sie ein Inventar: jeder Server, jeder Service, jede Domain, jede Datenbank. Nutzen Sie Cloud-Console-Tags, Terraform-State oder selbst eine Tabellenkalkulation. Sie können nicht bewerten, was Sie nicht sehen. Planen Sie 2-4 Stunden für das initiale Inventar ein.

"Management sieht Infrastruktur nicht als Priorität"

Übersetzen Sie Befunde in Geschäftssprache. "Keine getesteten Backups" wird zu "Wir könnten alle Kundendaten ohne Wiederherstellungsmöglichkeit verlieren." "Kein Monitoring" wird zu "Wir erfahren von Ausfällen, wenn Kunden sich auf Twitter beschweren." "Manuelle Deployments" wird zu "Jedes Release birgt das Risiko menschlicher Fehler, die Ausfallzeit verursachen." Die Risikomatrix quantifiziert die geschäftliche Auswirkung.

Prävention & Best Practices

Vierteljährliche Infrastruktur-Reviews

Führen Sie dieses Assessment alle 90 Tage durch. Setzen Sie eine Kalendererinnerung. Infrastruktur verschlechtert sich leise — Festplatten füllen sich, Zertifikate laufen ab, Abhängigkeiten werden verwundbar, Kosten treiben nach oben. Ein vierteljährliches 2-Stunden-Review fängt Probleme ab, bevor sie Incidents werden.

Infrastructure as Code

Jedes Stück Infrastruktur sollte in Code definiert sein (Terraform, Pulumi, CloudFormation). Manuelle Änderungen in Cloud-Konsolen sind unsichtbar, undokumentiert und nicht reproduzierbar. Wenn es nicht im Code ist, existiert es im Disaster Recovery nicht.

Runbooks für alles

Für jeden Service in Produktion schreiben Sie ein Runbook: wie deployen, wie rollbacken, wie aus Backup wiederherstellen, wie häufige Probleme debuggen, wen kontaktieren. Das Runbook sollte von jemandem nutzbar sein, der den Service noch nie gesehen hat — denn um 3 Uhr morgens könnte das die Person sein, die Bereitschaft hat.

Kosten-Reviews als Engineering-Praxis

Integrieren Sie Cloud-Kosten in Sprint Reviews. Machen Sie Kosten für das Team sichtbar. Wenn Ingenieure die Rechnung sehen, treffen sie andere Architekturentscheidungen. Ein monatliches 15-minütiges Kosten-Review verhindert die jährliche Überraschung "Warum ist unsere AWS-Rechnung 50.000 EUR?".

Game Days

Einmal pro Quartal simulieren Sie einen Ausfall. Schalten Sie einen Server ab, beschädigen Sie eine Datenbank (im Staging), lösen Sie Failover aus. Das ist der einzige Weg zu wissen, ob Ihr Disaster Recovery tatsächlich funktioniert. Netflix nennt das Chaos Engineering. Sie brauchen nicht Netflix' Skalierung, um davon zu profitieren — ein einfacher "Was passiert, wenn dieser Server stirbt"-Test ist bereits wertvoll.