Datenpunkte, die die Einführung von SRE in der Organisation motivieren

8

Da es keinen dedizierten Stack-Austausch für Site Reliability Engineering gibt, habe ich festgestellt, dass dies einer ist.

Es gibt mehrere großartige Ressourcen, die als Inspiration für Slidedecks zu SRE-Prinzipien dienen können [SRE-Folien].

Ich kann immer noch nicht finden:

  • kurz
  • prägnant
  • Beispiele
  • Motivation der Ausgabenressourcen zur Implementierung von SRE in der Organisation.

Das meiste, was ich in meinem Berufsleben erlebte, waren streng vertrauliche Fälle und Zahlen. Ich bin besorgt, dass die meisten Zahlen, die SREs kennen, "intern" bleiben sollen, um intern in Unternehmen präsentiert zu werden.

Vielleicht kennen Sie jedoch einige Studien (vorzugsweise eine Reihe von) netten Beispielen für Post-Morthems (auch eines nach dem anderen ist gut), aus denen wir starke Argumente wie "nach Einführung des SRE-Modells in die Organisationsgeschwindigkeit von Änderungen, die aus n gewachsen sind" ziehen könnten Pushs pro x freizugeben, mit Erhöhung der Verfügbarkeit um y und Senkung der Kosten um z "(Brainstorming) oder anderen harten Datenpunkten?

[SRE-Folien] - einige Beispiele:

PS Wenn diese Frage umformuliert werden könnte, um besser in die Richtlinien dieser Website zu passen, geben Sie mir bitte einen Kommentarvorschlag und geben Sie mir eine Änderung zur Verbesserung. Ansonsten werde ich andere bessere Plattformen schätzen (zB reddit.com/r/sre hat mich jedoch nicht sonderlich beeindruckt)

sre Grzegorz Wierzowiecki
quelle
3
Das SRE-Handbuch ist eine großartige Lektüre für ein Team, das versucht, SRE-Praktiken umzusetzen.
user9921
1
Chef.io verfügt über eine Reihe von Ressourcen, darunter 4 Webminare zu Devops und Geschwindigkeit, die Sie möglicherweise interessieren: chef.io/resources Einige Kundengeschichten wie Rakuten könnten Ihnen auch einige Einblicke geben. Ich kenne keinen endgültigen Leitfaden für harte Regeln, der dies besagt
Tensibai
Das Buch ACCELERATE (Forsgene, Gene) macht dasselbe für DevOps, aber einige Datenpunkte sind möglicherweise kompatibel, wie ein Service-MTTR (mittlere Zeit für die Wiederherstellung)
Peter Muryshkin

Antworten:

3

Die Arten von Zahlen, nach denen Sie suchen, sind möglicherweise schwer zu finden, da sie sehr unterschiedlich sind (meiner Erfahrung nach variieren sie innerhalb einer Organisation von Service zu Service und von Team zu Team). Das SRE-Arbeitsbuch ist jetzt kostenlos verfügbar und enthält zwei Fallstudien (Kapitel 3), die hilfreich sein könnten. Das SRE eBook von New Relic fasst SRE sehr gut zusammen.

Eine andere Möglichkeit, dies zu erreichen, besteht darin, zu versuchen, das, was Sie heute über Ihren Service wissen, zu verwenden, um eine Risikobewertung zu erstellen und Ausfallzeiten abzuschätzen, die Sie vermeiden können, wenn Sie SRE- und Entwicklerunterstützung haben, um diese Risiken zu beseitigen

Eric Harvieux
quelle
Mit der Zeit habe ich verstanden, dass einige Entscheidungsträger Risiken nicht erkennen werden, nachdem sie eingetreten sind. Daher müssen Sie Risikobewertungen vornehmen und auf Dinge warten, die Sie vorhergesagt haben, oder nach Datenpunkten suchen, z. B. wie viele Unternehmen x & y passiert sind, bei denen keine sre-Praktiken berücksichtigt wurden, und umgekehrt.
Grzegorz Wierzowiecki
1

Ich bin sowohl in DevOps- als auch in Site Reliability Engineering-Organisationen in mehreren Unternehmen tätig. Ich würde sagen, dass SRE den Vorteil hat, weitaus konkreter zu sein als DevOps.

  • DevOps betont Prinzipien und Denkweisen, zum Beispiel die drei Arten von DevOps: Systemdenken, Verstärkung von Rückkopplungsschleifen und eine Kultur des kontinuierlichen Experimentierens und Lernens. DevOps ist eher eine Erweiterung von Agile als ein anderes Betriebsmodell.

  • Site Reliability Engineering betont die spezifischen Ansätze, Metriken und Maßnahmen, die Google (und andere) anwenden, um ein hohes Maß an Serviceverfügbarkeit und Vertrauen in den Kunden zu erreichen. f.ex: Das Verhältnis von Arbeit zu Verbesserungen, quantitativer Risikoanalyse und mathematischen Ansätzen für SLIs und SLOs.

Da SRE DevOps implementiert, ist es etwas unfair, Organisationen zu vergleichen, die das eine tun, das andere jedoch nicht. Daher würde ich vorschlagen, dass der gesamte Inhalt von Accelerate genauso einfach auf Site Reliability Engineering angewendet werden kann, wenn Sie dies tun benötigen Peer-Review-datengesteuerte Analysen, um dort zu beginnen.

Richard Slater
quelle