組織へのSREの導入を促進するデータポイント

サイト信頼性エンジニアリング専用のstackexchangeがないため、これは1つに近いことがわかりました。

SREの原則についてのスライドデッキのインスピレーションとして使用する優れたリソースがいくつかあります[SREスライド]。

まだ見つかりません：

• ショート
• 簡潔な
• 例
• 組織にSREを実装するための支出リソースの動機付け。

私の職業生活で経験したことのほとんどは、機密性の高い事件と数でした。私は、SREが知っているほとんどの数値が、企業内で提示されるために「内部」のままであることを懸念しています。

ただし、いくつかの調査（できれば一連の）死後のすばらしい例（1つずつでも良い）を知っている可能性があるため、「nから成長した変更の組織速度にSREモデルを導入した後」などの強力な議論を行うことができます。 xあたりのmのリリースプッシュに、yによる可用性の向上とz "（ブレーンストーミング）または他のハードデータポイントによるコストの削減を伴いますか？

[SREスライド]-いくつかの例：

• サイトの信頼性エンジニアリング：ITSM Academy、Inc.によるエンタープライズ導入ストーリー（ITSM Academyウェビナー）
• Squareのプラットフォームエンジニア、Grier JohnsonによるSRE From Scratch
• GOTO 2017•Googleでのサイト信頼性エンジニアリング•Christof Leng

PSこの質問を、このサイトのガイドラインによりよく適合するように言い換えることができる場合は、コメントで提案を提供し、改善のための変更を提供してください。それ以外の場合は、他の優れたプラットフォームに感謝します（ただし、reddit.com / r / sreは私に大きな印象を与えませんでした）

探している数値の種類は、非常に変動するため、見つけにくい場合があります（1つの組織内でも、私の経験では、サービスごと、チームごとに異なります）。SREワークブックが無料で利用できるようになり、役立つ2つのケーススタディ（第3章）が含まれています。また、New RelicのSRE eBookは、SREを簡潔に要約するのに非常に優れています。

これに取り組む別の方法は、今日のサービスについて知っていることを使用してリスク評価を作成し、SREと開発者のサポートがこれらのリスクを排除する場合に防止できるダウンタイムを見積もることです。

私は複数の企業のDevOpsとサイト信頼性エンジニアリングの両方の組織で活動しています。SREにはDevOpsよりもはるかに具体的であるという利点があります。

• DevOpsは、たとえばDevOpsの3つの方法であるシステム思考、フィードバックループの増幅、継続的な実験と学習の文化など、原則と考え方を強調しています。DevOpsは、異なるオペレーティングモデルよりもアジャイルの拡張機能です。

• サイト信頼性エンジニアリングは、Google（およびその他）が高レベルのサービスの可用性と顧客への信頼を実現するために適用する特定のアプローチ、測定基準、および測定を強調します。f.ex：改善に対する労苦の比率、定量的リスク分析、SLIおよびSLOへの数学的アプローチ。

SREはDevOpsを実装しているため、一方を実行し、もう一方を実行しない組織を比較するのは少し不公平です。そのため、実際にAccelerateのすべてのコンテンツをサイト信頼性エンジニアリングに簡単に適用できることをお勧めします。そこから開始するには、ピアレビューされたデータ駆動型分析が必要です。