Zum Inhalt springen
Zapolu

DevOps & Infrastruktur

Pragmatische Infrastruktur, CI/CD, Observability und On-Call-Setup, dimensioniert für E-Commerce: für einen Produktionsbetrieb ohne nächtliche Eskalationen.

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.

Verwandte Leistungen