Plattform und Zuverlässigkeit

SRE und Produktionsreife

Ihr Service geht bald in Produktion oder läuft dort schon, und jemand muss die unbequemen Fragen beantworten. Wie groß ist das Error Budget? Was weckt nachts um drei jemanden auf? Was passiert, wenn eine Zone ausfällt? Wir helfen Ihnen, diese Fragen zu beantworten, bevor es ein Kunde tut.

Was wir tun

Festlegen, was „funktioniert“ bedeutet. Wir wählen die wenigen User Journeys aus, auf die es ankommt, etwa Registrierung, Bezahlung oder das Laden des Dashboards. Dafür setzen wir Service Level Objectives: wie schnell, wie oft erfolgreich, gemessen dort, wo der Nutzer es spürt. Über diese Zahlen diskutiert Ihr Team dann, statt über Meinungen.

Alerts, die etwas bedeuten. Wir reduzieren die Alerts auf die, die eine Auswirkung auf Nutzer anzeigen oder ein Error Budget, das zu schnell schrumpft. Alles andere wird ein Ticket oder landet im Dashboard. Weniger Alarme, und für jeden lohnt es sich aufzustehen.

Auf den schlechten Tag vorbereiten. Wir gehen mit Ihrem Team die Fehlerbilder durch: ein Zonenausfall, eine volle Festplatte, ein fehlerhaftes Deployment, ein abgelaufenes Zertifikat, eine Abhängigkeit, die langsam wird statt auszufallen. Für jedes gibt es einen Erkennungsweg, ein Runbook und, wo möglich, eine automatische Wiederherstellung. Die riskanten Fälle testen wir gezielt.

Incidents sauber führen und daraus lernen. Klare Rollen während eines Incidents, ein fester Rhythmus für Statusupdates und danach ein kurzes Post-Mortem ohne Schuldzuweisung, das mit Verantwortlichen und Terminen endet. Kein Dokument, das niemand liest.

Wie es meistens abläuft

Die meisten Projekte beginnen mit dem zweiwöchigen Production-Readiness-Audit. Wir lesen Ihre Architektur, Dashboards, Alert-Historie und die letzten Incident-Berichte, und wir sprechen mit den Leuten in der On-Call-Bereitschaft. Am Ende steht eine nach Risiko sortierte Maßnahmenliste.

Danach setzen manche Teams die Maßnahmen selbst um, mit ein paar Stunden Beratung im Monat. Andere machen die erste Runde gemeinsam mit uns, meist vier bis acht Wochen, und übernehmen, sobald sich das Team im Betrieb sicher fühlt.

Passt gut, wenn

  • Sie stehen kurz vor dem Launch oder vor dem Vertrag mit einem Kunden, der ein SLA verlangt.
  • Sie hatten gerade einen Incident, den Sie nicht noch einmal erleben wollen.
  • Ihr Team wird so oft alarmiert, dass niemand die Alerts mehr liest.
  • Sie sind über den Punkt hinausgewachsen, an dem eine Person weiß, wie alles funktioniert.

Häufige Fragen

Was ist der Unterschied zwischen SRE und DevOps?
DevOps ist eine Arbeitsweise: Entwicklung und Betrieb tragen gemeinsam die Verantwortung für laufende Software. SRE ist eine konkrete Umsetzung davon, mit messbaren Zielen (SLOs), einem Error Budget, das entscheidet, wann Sie das Tempo drosseln, und Engineering-Arbeit, die manuelle Routinearbeit abbaut. Wir setzen auf SRE-Praktiken, weil Sie dann über Zahlen diskutieren statt über Meinungen.
Brauchen wir ein eigenes SRE-Team?
Unter 50 bis 80 Entwicklern meistens nicht. Die meisten Teams brauchen klare SLOs, vernünftiges Alerting und eine gemeinsame On-Call-Bereitschaft, getragen von den Produktteams selbst. Wir bauen das auf und schulen die Leute, die es danach verantworten.
Mit welchen Monitoring-Tools arbeiten Sie?
Prometheus, Grafana, Google Cloud Monitoring, CloudWatch, Datadog, OpenTelemetry und den meisten anderen gängigen Werkzeugen. Wir verbessern lieber, was bei Ihnen schon läuft, als Sie auf etwas Neues zu migrieren.
Wie lange dauert ein Production-Readiness-Audit?
Zwei Wochen für ein typisches Produkt mit einer Handvoll Services. Sie bekommen einen schriftlichen Bericht mit einer nach Risiko sortierten Maßnahmenliste. Der gehört Ihnen, egal ob wir die Umsetzung übernehmen oder nicht.

Sagen Sie uns, was nicht funktioniert.

Ein paar Sätze reichen. Wir antworten innerhalb eines Werktags, und das erste Gespräch ist kostenlos.