---
title: "DevOps & Infrastruktur"
description: "Pragmatische Infrastruktur, CI/CD, Observability und On-Call-Setup, dimensioniert für E-Commerce: für einen Produktionsbetrieb ohne nächtliche Eskalationen."
language: "de"
canonical: "https://zapolu.com/de/services/devops/"
---

# 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 dauern 40 Minuten, schlagen still fehl oder brauchen jemanden, „der das Skript kennt“
- Warum der Checkout letzten Donnerstag langsam war, weiß niemand, weil es weder Logs noch Metriken gibt
- Compliance-Fragen (PCI, DSGVO-Audit-Trail) brauchen plötzlich echte 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, deren Einsparungen die
  Kosten des Engagements häufig decken.
- **Incident Response.** Runbooks, ein Alerting ohne Fehlalarme und
  eine Post-mortem-Kultur, die aus einem nächtlichen Vorfall eine
  Korrektur macht, die in der Folgewoche produktiv geht.
- **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.

## Incidents aus unserer Praxis

Eine Auswahl aus Produktionssystemen, die wir über die Jahre
betrieben haben:

- Die Speicher-Dashboards zeigten keine Auffälligkeiten, während die
  Anwendung Speicher verlor: 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 gepinnt, 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 still
  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.

Die Gewohnheit dahinter: Alerts auf Geschäftsinvarianten, etwa „jede
Bestellung erreicht das ERP innerhalb von 15 Minuten“, nicht nur auf
Fehlerraten. Mehrere der Vorfälle oben hat genau so eine Sonde
gefangen, bevor ein Kunde etwas gemerkt hat.

## 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](/de/how-we-work/).