The Delivery Hero Reliability Manifesto (Übersetzung)

Die einzelnen Inhalte sind alle so beeindruckend, dass ich sie nicht leicht zusammenfassen kann; ich liste nur einige Punkte auf, die mich am meisten angesprochen haben.

• Das Manifesto nicht verletzen, sondern Diskussionen führen, um die Regeln zu ändern und das Manifesto weiterzuentwickeln.
• Alle Services müssen einschließlich ihrer Abhängigkeiten in Architekturdiagrammen dokumentiert werden, und die Architektur muss reviewt werden.
• Datenproduzenten müssen auch die von ihnen erzeugten Daten dokumentieren.
• Auch Deployments am Freitag müssen stabil funktionieren.
• Abwehrlogik für Fehlersituationen implementieren (Timeout, Retry, Circuit Breaker, Fallback, Throttling, Idempotenz usw.).
• Dashboards erstellen und überwachen, die den Servicezustand sichtbar machen (Requests pro Minute, Fehlerrate, Serverantwortzeit, Business-Metriken).
• Methoden zur Analyse und Reproduktion von Issues als Runbook dokumentieren und mit Alerts verknüpfen, um die Wiederherstellungszeit zu minimieren.
• Wenn Probleme auftreten, die Ärmel hochkrempeln und bei der Lösung helfen.
• Alle textbasierten Gespräche stets in dem Verständnis führen, dass die andere Seite gute Absichten hat.
• Eine teamweise Security-Score-Tabelle erstellen und veröffentlichen, damit sicherheitsbezogene Aktionen in die Teamleistung einfließen.
• Je mehr Bestellungen im System eingehen, desto geringer sollten die Kosten pro Bestellung sein. Ideal wäre es, wenn die Kosten pro Bestellung pro Quartal um 10 % sinken.
• Lead Time (von Entwicklungsbeginn bis zum Deployment in Produktion), Deployment-Frequenz, Wiederherstellungszeit und Fehlerrate während der Wiederherstellungszeit überwachen.

Es gibt darüber hinaus noch viel mehr Inhalt; beim Lesen fragt man sich unweigerlich, wie viele Menschen wohl dazu beigetragen haben, so etwas zu erschaffen ... Es ist wirklich ein Text, der Ehrfurcht auslöst.