Was DevOps tatsächlich behebt

Die Symptome sind bekannt. Deployments finden am Freitagabend statt, weil dann auf der Website wenig los ist. Niemand weiß genau, wie der Produktionsserver konfiguriert wurde, weil die Person, die ihn eingerichtet hat, das Unternehmen verlassen hat. Die Staging-Umgebung unterscheidet sich von der Produktion auf eine Weise, die erst während eines Vorfalls entdeckt wird. Und wenn um 2 Uhr nachts etwas ausfällt, vergehen die ersten zwanzig Minuten mit der Frage, ob überhaupt etwas kaputt ist.

Nichts davon lässt sich beheben, indem man Entwickler bittet, sorgfältiger zu sein. Es wird behoben, indem man den Deployment-Pfad automatisiert, die Infrastruktur als Code beschreibt, damit sie neu erstellt werden kann, und das System so instrumentiert, dass es Ihnen sagt, was falsch ist, bevor ein Kunde es tut.

Was wir tun

  • CI- und CD-Pipelines mit automatisierten Tests und Rollback per Klick
  • Containerisierung mit Docker, Orchestrierung mit Kubernetes, wo sich die Komplexität lohnt
  • Infrastructure as Code mit Terraform oder Gleichwertigem
  • Cloud-Architektur und Migration auf AWS, Azure und Google Cloud
  • Monitoring, Logging, Tracing und Alarmierung, die einen Menschen erreicht
  • Backup, Disaster Recovery und getestete Wiederherstellungsverfahren
  • Deployments ohne Ausfallzeit sowie Blue-Green- oder Canary-Releases
  • Autoscaling und Lastverteilung
  • Secrets-Management und Zugriffskontrolle
  • Analyse und Optimierung der Cloud-Kosten

Deployments sollten langweilig sein

Das Ziel ist, dass ein Release unspektakulär ist: Ein Merge löst die Pipeline aus, Tests laufen, ein Image wird gebaut, Staging wird aktualisiert, und die Produktion folgt entweder automatisch oder nach einer Freigabe. Ein Rollback ist ein Knopfdruck, keine archäologische Ausgrabung.

Teams, die diesen Zustand erreichen, deployen häufiger und machen seltener etwas kaputt, weil jedes Release klein genug ist, um es zu überblicken. Teams, die monatlich deployen, liefern große, riskante Änderungen aus und verbringen dann die folgende Woche damit herauszufinden, welche davon das Problem verursacht hat.

Cloud-Kosten, ehrlich betrachtet

Die meisten Cloud-Rechnungen, die wir prüfen, enthalten einen erheblichen Anteil reiner Verschwendung: überdimensionierte Instanzen, die beim Start gewählt und nie überprüft wurden, Speicher, den seit zwei Jahren niemand gelesen hat, nicht verbundene Volumes und ungenutzte Load Balancer, Umgebungen, die nachts und am Wochenende weiterlaufen, und Datentransferkosten, die sich nie jemand angesehen hat.

Wir gleichen die Ausgaben mit der tatsächlichen Nutzung ab, dimensionieren gezielt, nutzen Reserved Instances oder Savings Plans, wo die Bindung sicher ist, lassen Nicht-Produktionsumgebungen zeitgesteuert ruhen und richten Budgetwarnungen ein. Es geht nicht darum, alles billig zu betreiben, sondern darum, nicht mehr für Dinge zu zahlen, die Sie nicht nutzen.

Es wissen, bevor Ihre Kunden es merken

Ein Monitoring, das nur Servermetriken meldet, sagt Ihnen, dass die Maschine läuft – nicht, dass der Checkout seit vierzig Minuten fehlschlägt. Wir instrumentieren, was für das Geschäft wirklich zählt: Fehlerraten in zentralen Abläufen, Antwortzeiten in den Perzentilen, die Nutzer spüren, Warteschlangentiefe, fehlgeschlagene Zahlungen und erfolgreiche Transaktionen.

Alarme werden so eingestellt, dass sie etwas bedeuten. Ein Alarm, der jede Nacht auslöst, wird innerhalb einer Woche stummgeschaltet und verpasst dann den echten Vorfall. Wir setzen Schwellenwerte anhand beobachteter Basiswerte, leiten Alarme an diejenigen weiter, die handeln können, und schreiben Runbooks, damit die Reaktion nicht davon abhängt, dass eine bestimmte Person wach ist.