DevOpsのROIを測定する方法は何ですか？

DevOpsは複雑で、文化やプロセスなどの多くの非決定論的な側面を伴います。
DevOpsイニシアチブの成功を測定するいくつかの方法は何ですか？
彼らが行った投資が実際のドルを返す（または節約する）ことをどのようにビジネスに証明しますか？

いい質問です！私たちのほとんどは、DevOpsプラクティスへの投資が無数の理由で非常に価値のある追求であることを知っています。ただし、収益への影響だけでDevOpsを正当化することはあまりありません。

注：これは意見の多い質問であり、私の答えも同様に意見があります。

Tensibaiは、適切な指標を見つけることを賢明に提案し、市場投入までの時間を例として使用しました。これは素晴らしい全体像のアプローチです。

別のアプローチとして、Beanカウンターでの私の経験では、全体像を知る必要はなく、必ずしも知る必要はありません。財政責任の証拠が必要なだけです。彼らは正しい方向のトレンドを見たいと思っています。

いくつかの財政的な勝利があります：

• クラウドで自動スケーリングを活用して節約されたサーバーコストを計算する
• 収入を生み出すサイトの場合、ダウンタイムの分あたりのコストを推定し、MTTIとMTTRの改善を示します
• 繰り返しますが、収入を生み出すサイトでは、過去のインシデントに基づいて高可用性アーキテクチャを活用することで節約できる分あたりのコストを見積もります
• ビルドとデプロイのパイプラインを改善した場合は、既に追跡された障害に起因する本番環境でのリグレッションとエラーを削減したことを示します
• 開発者のテスト環境、または開発者のラップトップのツールと構成を改善した場合は、コミット履歴を見て、新しいエンジニアが参加してすぐに最初の貢献をしているかどうかを確認してください
• Gitlabが最近行ったように、クラウドとオンプレミスの完全なコスト比較を実行して、インフラストラクチャの支出を正当化します（別名、節約！）

あなたがお金に敏感であることと、いくつかの明確な勝利があることを示すだけで十分な場合がよくあります。私は確かにいくつかの明白な例を逃しました。以下にコメントを追加してください。

DevOpsパイプラインの主要なメトリックは、サイクルタイム（リードタイムとも呼ばれます）です。これは、変更（またはアイデアの開始まで追跡する変更要求）にかかる時間です。私が知っているこの概念の最良の例は、「Goal」という本からのものです。

展開頻度も役立ちます。DevOpsパイプラインでは展開を頻繁に行う必要があります。魔法のような「1日は良い、2日は悪い」という測定値はありません。これには、プロジェクトの意味のある歴史的背景が必要です。

展開サイズ：開発者が作業を測定します（ユーザーストーリー、ストーリーポイント、クワトロなど）。繰り返しますが、絶対値ではなく、時間の経過に伴う傾向を確認する必要があります。

頻度とサイズの間には、伝えるべき物語があります。私たちのリリースはより頻繁ではなく、より大きくなっていますか？どうして？それらはより小さく、より頻繁になっていますか？繰り返しますが、なぜですか？

頻度/サイズの傾向が良いかどうかを説明するために、失敗した展開の割合も必要になります。これら3つのメトリックの「理由」を明らかにすることで、プロジェクトの健全性について多くのことがわかります。

私の個人的なお気に入りは、バニティメトリックですが、簡単な展開の時間です。サイト全体を再展開する価値のある最小のものを見つけた場合...おそらくCEOの名前のタイプミス...パニック電話から展開されたサイトにどれくらい早く行くことができますか？私は「虚栄心」と言います。なぜなら、それは実際には上記の他の指標が議論するものを超えた予測ではないが、価値が好きなときに気分が良くなるからです。

監視に入ると、「Uptime」などの包括的なものから、要求/応答サイクルでカスタムHTMLの再生成に費やされる時間などの非常に低レベルのものまで、追跡できるさまざまなものがあります...ただし、DevOpsカルチャを確立するためのものではありません。

これらは直接ドルに結びついていません...そうすることは、このようなフォーラムで私が提供できる以上にあなたの組織についてのより多くの知識を必要とします。しかし、それらはその質問に答えるためのBEGINへの鍵です。作業を非イベントとして定期的に本番環境にリリースできることがわかったら、以前にどれだけの労力を費やしていたかを確認できます。「The Goal」という本が教えているように（製造パイプラインについて-関連）、ローカルでの最適化はお金を節約しているように見えますが、最終的には在庫に縛られた価値を生み出します（未展開の機能）。

このアドバイスに加えて、過去数年間のState Of DevOps Reportをご覧ください。これには、エミュレートできる実際のプロジェクトに関する測定値がいっぱいです。

船長：市場投入までの時間とリリースの欠陥を減らすことによって。

この1つのライナーを拡張するために、通常の落とし穴は、参照なしで組織を変更することです。

文化や組織の変化に従事することは、この新しい方法をトレーニングして人々に紹介するためのいくらかの費用を意味します。これは文化的変化の投資の一部です。

ROIを測定するには、最初に改善する必要のある関連するメトリックを見つける必要があります（費用がかかる、費用がかかる、または利益の損失の原因を理解する）。これは、市場投入までの時間の短縮、各リリース後のパッチの削減、製品内での顧客エンゲージメントの向上につながります。関連するメトリックは、製品に大きく依存します。

ROIの測定（トレーニング費用をカバーする速さ）は、実際にそれらのメトリックの進化を提示できることを意味するため、変更を行う前に、それらのメトリックを定義し、客観的な方法で測定する必要があります。
真の進化を見せたら、トレーニング費用をカバーして以前よりも収益性が向上した方法で何かを改善したかどうかを確認できます。

通常の落とし穴は、メトリックを定義する前に変更を行うことで、実際のデータではなく感情でROIを評価することです。

生産性は測定基準となる場合がありますが、その測定は通常客観的な方法で行うのが非常に困難であり、この種の研究の第一級測定基準ではありません。

ここでゲームに遅れたが、私はチャイムだと思った。

あなたが測定していないものを管理することはできないので、初心者向けに、devopsがインシデント対応のために追跡すべき主要な指標を以下に示します。

• アップタイム％：利用可能な時間の合計％= [合計時間-ダウンタイム] / [合計時間]
• MTTR：解決までの平均時間= [ダウンタイム] / [＃件のインシデント]
• MTTA：確認までの平均時間= [確認までの合計時間] / [インシデントの数]
• MTBF：平均故障間隔 = [合計時間-ダウンタイム] / [インシデントの数]

これらのメトリックは、操作の高レベルのヘルスチェックを提供し、さらに掘り下げる必要がある場所を特定するのに役立ちます。

このトピックの詳細については、こちらのホワイトボードアニメーションをご覧ください。

メトリックスがわかったら、ダウンタイムのコストと比較することができます。そこからチームのROIの構築を開始し、継続的な改善のための定量的なメトリックを設定できます。