DevOps & Infrastruktur

Wir entwerfen und betreiben die Infrastruktur hinter E-Commerce-Shops, ohne dafür ein Kubernetes-Cluster einzuführen, das einen Senior SRE in Vollzeit binden würde.

Typische Ausgangslagen

• Ein Shop läuft auf einem einzigen VPS und fällt bei jedem Sale und jedem Kampagnenstart aus
• Deployments sind langsam, schlagen unbemerkt fehl oder hängen an einer Person, die das Skript kennt
• Warum der Checkout letzten Donnerstag langsam war, lässt sich nicht mehr feststellen, weil es weder Logs noch Metriken gibt
• Compliance-Anforderungen (PCI, DSGVO-Audit-Trail) verlangen jetzt dokumentierte Antworten
• Der Gründer oder CTO ist faktisch der On-Call-Engineer und übernimmt jeden Black Friday selbst die Rufbereitschaft

Was wir tun

• Cloud- und Edge-Infrastruktur auf Cloudflare, AWS, GCP, Hetzner oder Bare Metal; wir wählen den Stack, der zur Workload passt.
• CI/CD-Pipelines mit GitHub Actions oder GitLab CI: reproduzierbare Builds, reversible Deployments und Secrets, die nicht im Repo liegen.
• Observability. Logs, Metriken und Traces über Grafana, OpenTelemetry, Sentry oder Cloudflare Logpush. Die Frage „Was ist letzten Dienstag um 14:32 passiert?“ sollten Sie in unter einer Minute beantworten können.
• Performance und Kosten: Edge-Caching, Image-CDN, Autoscaling für Kampagnenspitzen und eine Kosten-Review: wofür Sie tatsächlich zahlen.
• Incident Response. Runbooks, ein Alerting ohne Fehlalarme und Post-mortems, die schriftlich festgehalten und in Korrekturen überführt werden.
• Sicherheits-Baseline: Secrets-Management, Dependency-Scanning, Image-Signing, Network-Policies und die routinemäßigen Patches, die bekannte Exploits aus Ihrem Shop fernhalten.

Im Zweifel wählen wir die einfachste Infrastruktur, die die Anforderungen erfüllt.

Beispielhafte Vorfälle

Eine Auswahl aus den zehn Jahren E-Commerce-Engineering, auf denen diese Praxis steht, anonymisiert:

• Die Speicher-Dashboards zeigten keine Auffälligkeiten, während die Anwendung ein Speicherleck hatte: Der Metrik-Agent beobachtete den Prozessmanager statt der App, die dieser gestartet hatte. Diagnostiziert über den Prozessbaum und eine Analyse des Agent-Quellcodes, behoben mit einem kleinen Init-Wrapper, der zugleich für saubere Shutdowns sorgte.
• Wiederkehrende „Wartungsmodus“-Ausfälle, deren tatsächliche Ursache der Cache-Layer war, dessen Transient-Speicher erschöpft war. Verschärft durch ein automatisch aktualisiertes „stable“-Image-Tag, das die laufende Software fortlaufend unangekündigt austauschte. Versionen festgesetzt, die VCL überarbeitet, und die Hit-Rate stieg von 4 % auf ein tragfähiges Niveau.
• CI-Agents wurden mitten im Job vom OOM-Killer beendet, was unbemerkt die State-Machine der Shop-Indexer einfror und die Bestandsupdates stoppte. Wir haben den Ausfall auf Staging gezielt reproduziert und danach die Cron-Schicht neu gebaut, mit Isolation pro Gruppe und selbstheilenden Resets.
• Der Frontend-Cache eines ganzen Landes ließ sich nicht invalidieren, wegen eines einzigen vertippten Namespace-Worts in der Liste der Purge-Hosts. Live mit manuellen Cache-Bans behoben, dauerhaft dann in der Konfiguration.
• Eine Kundenumgebung wurde versehentlich gelöscht, logische Backups gab es keine. Wir haben sie aus Hypervisor-Snapshots zurückgeholt, per erzwungenem InnoDB-Recovery und über einen Sprung zwischen zwei MySQL-Hauptversionen hinweg.

Das Prinzip dahinter: Alerts für Geschäftsinvarianten, etwa „jede Bestellung erreicht das ERP innerhalb von 15 Minuten“, nicht nur auf Fehlerraten. Eine Überwachung dieser Invariante fängt diese Klasse von Ausfällen ab, während die Fehlerrate noch normal aussieht.

Wie ein Projekt üblicherweise beginnt

Ein großer Teil dieser Arbeit kommt im Rahmen eines anderen Engagements zu uns: ein Audit, das den Engpass bis zum Hosting zurückverfolgt, oder ein Build, der eine Deploy-Pipeline braucht, bevor überhaupt etwas ausgeliefert werden kann. Bei eigenständiger Infrastrukturarbeit beginnen wir mit einer kurzen Bestandsaufnahme: was wo läuft, was es kostet und was unter Last zuerst nachgibt. Die empfohlenen Änderungen halten wir schriftlich fest, zum Festpreis. Der laufende Betrieb erfolgt als monatlicher Retainer mit benannten Stunden, zu den Bedingungen unter So arbeiten wir.