# GitOps – Git-Driven Deployment

Kurzfassung: Ziel ist, Backup-/Restore-Laufzeiten zu senken, ohne Stabilität zu opfern. Wir identifizieren Bottlenecks (CPU/IO/Netz), stellen Transport-Modi, Slots, Compression/Dedupe passend ein und messen Vor/Nach.

# 1. Zweck & Zielbild

• SLA-konforme Laufzeiten (Backup/Restore), reproduzierbar.
• Ressourcen balanced (kein Proxy/Repo überlastet, kein Netz-Collapse).
• Dokumentierte Tuning-Schritte, rückbaubar.

# 2. Voraussetzungen

• Monitoring der Kernmetriken (Artikel 769/823): Throughput, CPU, IO-Wait, Netz-Latenz/Drops, Ratio.
• Transport-Modi konfigurierbar (SAN/HotAdd/NBD), Repos/Proxies dimensioniert.
• Testfenster für Vor/Nach-Messungen.

# 3. Risiken / Backout

• Zu viele Slots → IO/Netz brechen ein.
• Falscher Transport-Mode → langsamer Pfad.
• Kompression/Dedupe falsch → CPU-Bottleneck oder wenig Einsparung.
• Backout: Auf Baseline zurück (Slots/Compression „Optimal“, Mode Auto), Änderungen einzeln zurückdrehen.

# 4. Umsetzung (Schritte)

1. Baseline erfassen: Dauer, Throughput, Bottleneck im Job-Report.
2. Transport-Mode optimieren: SAN/HotAdd bevorzugen (Artikel 785/810); Fallbacks fixen.
3. Slots/Tasks anpassen: Start konservativ, erhöhen bis knapp vor IO/CPU-Limit.
4. Compression/Dedupe: Level passend zum Workload (Artikel 798/760/761), bei CPU-Engpass senken.
5. Netz/BW: BWLimit/QoS (Artikel 809), MTU prüfen, dedizierte NIC/VLAN.
6. Repo/Storage: Schnelle Disks für Hot-Index/Cache, Fast-Clone nutzen (ReFS/XFS).
7. Iterieren: Änderungen einzeln, Messung, dokumentieren.

# 5. Verify / Tests

• Wiederholung der Test-Jobs nach jeder Änderung, p95 Laufzeit und Throughput vergleichen.
• Restore-Test sicherstellen, dass Tuning die Wiederherstellung nicht verschlechtert.
• Ratio/Resource-Utilization plausibel (keine anhaltende 100 % CPU/IO-Wait).

# 6. Runbooks

• CPU-bound: Kompression runter, mehr Proxies/CPU, Concurrency reduzieren.
• IO-bound: Schnellere Repos, weniger parallele Jobs, Fast-Clone prüfen, Verify verschieben.
• Netz-bound: Pfad/MTU prüfen, BWLimit/QoS, dedizierte NIC, Concurrency senken.
• Bottleneck unklar: Job-Report, Perf-Metriken korrelieren, Schrittweise Änderungen.

# 7. Monitoring / Alerts

• Laufzeit-Drift, Bottleneck-Änderungen, hohe Queue/Wait, Ratio-Drop, Netz-Drops.
• Alerts bei SLA-Verletzung, persistenter Überlast, häufigem Mode-Fallback.

# 8. Governance

• Tuning-Schritte als Change mit Vor/Nach-Messung, rückbaubar.
• Regelmäßiger Performance-Review (quartalsweise) auf Basis echter Daten.
• Dokumentation der gewählten Settings und Gründe pro Workload.

# 9. Links & Quellen

• Artikel 785/810/835 (Proxies), 760/761/798 (Dedupe/Compression), 809 (BW), 823 (Monitoring), Veeam Performance Best Practices.