Der Kunde ist ein Logistikdienst mit mehreren zehntausend Bestellungen täglich, abendlichen Spitzen und Verkaufsaktionen sowie strengen SLAs gegenüber Handelspartnern. Die Infrastruktur war ungeplant gewachsen: verstreute VPS, Konfigurationen direkt auf Servern und manuelle Deployments nach einer Wiki-Anleitung. Jedes Release bedeutete einen nächtlichen Rollout mit Ausfall, jede Spitze ein Risiko, Bestellungen zu verlieren. Anlass für die Zusammenarbeit war ein Vorfall während des vorweihnachtlichen Verkaufs, als die Plattform vier Stunden ausfiel und der Dienst Partner entschädigen musste.
Die Plattform ohne Betriebsunterbrechung auf eine kontrollierbare Infrastruktur umstellen:
Infrastruktur als Code, automatisierte Bereitstellung, Containerisierung und Orchestrierung, Observability und vorhersehbare Wiederherstellung nach Ausfällen. Der Gründer formulierte das Erfolgskriterium so: „Deployment während der Arbeitszeit, ohne Ausfall und ohne jemanden mit SSH-Zugang.“
Wir folgten einer bewährten Reihenfolge: zuerst Container und reproduzierbare Umgebungen, dann die Automatisierung der Bereitstellung und erst danach Orchestrierung mit automatischer Skalierung.
- Wir prüften die Infrastruktur: Karte der Dienste und Abhängigkeiten, Messung des Lastprofils bei Spitzen sowie ein Verzeichnis manueller Abläufe, die am häufigsten zu Störungen führten.
- Wir containerisierten die Dienste: vereinheitlichten den Build, verlagerten Konfigurationen aus dem Code in Umgebungsvariablen und richteten identische Dev-, Stage- und Prod-Umgebungen ein.
- Wir beschrieben die Infrastruktur mit Terraform als Code: Umgebungen werden aus dem Repository bereitgestellt, manuelle Änderungen in der Cloud-Konsole sind untersagt.
- Wir bauten eine GitLab-CI-Pipeline: Tests und Image-Builds laufen automatisch, Stage wird sofort ausgerollt, Prod nach einer Prüfung per Knopfdruck; ein Rollback erfolgt mit einer Aktion.
- Wir migrierten die Plattform zu Kubernetes mit automatischer Skalierung. Bei Abendspitzen und Verkaufsaktionen stehen zusätzliche Instanzen bereit, statt dass Mitarbeitende in hektischen manuellen Einsätzen reagieren müssen.
- Wir richteten Monitoring und Alarmierung ein: Kennzahlen der vier Golden Signals – Latenz, Fehler, Traffic und Auslastung – mit Bereitschaftsdienst und geplanter Eskalation.
- Wir konfigurierten Backups und Disaster Recovery: Wiederherstellungsablauf sowie eine auf Stage geprobte Störung mit Messung der tatsächlichen MTTR.
Der größte Wert des Projekts liegt nicht in den Technologien, sondern in der veränderten Verantwortung: Die Infrastruktur hängt nicht mehr von einer Person mit SSH-Zugang ab. Jedes Deployment ist reproduzierbar, jede Umgebung lässt sich aus Code wiederherstellen, und Störungen sind im Dashboard sichtbar, bevor der erste Kunde schreibt. So werden Ausfälle von Katastrophen zu routinemäßigen Vorfällen mit einem klaren Ablaufplan und messbarer Wiederherstellungszeit.
Der wirtschaftliche Nutzen setzt sich aus drei Teilen zusammen: 32% direkte Einsparungen bei der Infrastruktur durch Autoscaling und den Verzicht auf dauerhaft vorgehaltene Spitzenkapazität; eingesparte Teamstunden, die zuvor für nächtliche Releases benötigt wurden; und vor allem gesicherter Umsatz während Spitzen, die nun ohne Vorfälle ablaufen. Ein großer Handelskettenkunde verlängerte den Vertrag nach der ersten Verkaufsaktion auf der neuen Infrastruktur.
| Kennzahl | Ergebnis |
|---|---|
| Deployment eines Releases | 3–4 Stunden manuell → 15 Minuten automatisch |
| Release-Häufigkeit | 2–3 pro Monat → Fast täglich |
| Verfügbarkeit der Plattform | 97,8% → 99,95% |
| Lastspitzen | Ausfallrisiko → Autoscaling ohne menschliches Eingreifen |
Die Kennzahlen wurden aus den ursprünglichen Fallstudienmaterialien übernommen. Der Zeitraum ist angegeben, sofern er in der Quelle festgehalten wurde.
- Release-Deployment (zuvor 3–4 Stunden manuell)
- 15 Min.
- Plattformverfügbarkeit (zuvor 97,8%)
- 99,95%
- Wiederherstellung nach einem Ausfall (zuvor 2–4 Stunden)
- 20–30 Min.
- Infrastrukturkosten
- −32%
Dargestellt sind die oberen Grenzen der Spannen (4 Stunden, 30 Minuten). Ausfallzeit = 100% − Verfügbarkeit.
- 01Commit
- 02Tests
- 03Image-Build
- 04Stagesofort
- 05Prodper Knopfdruck nach der Prüfung
Entwicklungsmöglichkeiten für den nächsten Infrastrukturzyklus:
- FinOps-Praxis mit Alarmen bei Kostenanomalien und transparenter Kostenzuordnung zu Teams.
- GitOps-Ansatz: Der Produktionszustand ist im Repository beschrieben, Änderungen erfolgen ausschließlich über Pull Requests.
- Multi-Region-Betrieb mit Replikaten kritischer Dienste, um Ausfälle beim Anbieter abzufangen.
Früher bedeutete ein Release: Nacht, Kaffee und ein Gebet. Heute sind es ein Knopfdruck und fünfzehn Minuten. Den ersten Verkauf ohne Vorfälle haben wir mit der ganzen Firma gefeiert.
— Technischer Leiter des Logistikdienstes