DevOpsの測定に使用される主要業績評価指標（KPI）は何ですか？

私はこれをサポートするために、DevOps変換プログラム内で適切な行動をとろうとしています。

• 問題とインシデント管理
• 容量管理
• 変更およびリリース管理

明確にするために、これらは運用組織に属していた機能であり、現在はアジャイル/ DevOps組織が所有しています。悪い動作を引き起こす既存のKPIは次のとおりです。

• 根本原因分析までの時間の完了：
  • 不完全なRCAを時間どおりにシステムに取り込むために駆動します。
• テスト実行時間：
  • ビジネス価値に関係なく、長時間実行されるテストを無効にします。
• クラウドサービスの平均使用率：
  • 計算リソースのオーバーコミットを奨励し、結果として応答時間が遅くなります

DevOpsプログラムで適切な行動を促すために使用できる主要業績評価指標は何ですか？

「普遍的な」DevOps KPIはないと思います。たとえば、ビジネスにとって重要なドライバーでない限り、速度は素晴らしいです。Amazonは大規模な小売事業を展開しているため、速度を重視しています。これは、100人のユーザーがいる小さなアプリにとってはそれほど重要ではありません。

これは、あなたのビジネスに関連する最高のKPIをどのように選択するのかという疑問を投げかけます。これは、企業全体に関わる調査と発見のプロセスです。

何を気にしますか？

• 品質
• 信頼性
• 保守性
• 速度
• プロセス改善
• サービスレベル

夜間にビジネス関係者を維持するものは何ですか？今四半期に収益を上げるかどうかは何によって決まりますか？上記のリストには、それらの一部が含まれている場合と含まれていない場合があります。リストを作成し、すべての部門でインセンティブを調整して達成する方法を見つけます。

インセンティブは行動を促進するため、SMARTの目標を共同で決定します。ブレインストーミングされたリストから2つまたは3つの項目を選択し、それぞれの測定/修正フィードバックサイクルを開始します。一度にたくさん選びすぎないでください。2つまたは3つのことに集中することで成功する可能性が高くなります。

DevOpsにはKPIがありません。それは愛のKPIとは何かを尋ねるようなものです。しかし、あなたが言及したもの（問題とインシデント管理、キャパシティ管理、変更とリリース管理）には良いKPIがあり、そのいくつかはDevOpsの背後にある理論に基づいています。

一般に、どのビジネスプロセスでも、顧客から企業を経由して顧客に戻る価値の流れを記述するバリューチェーンマップを作成できます。ループ全体は常に顧客で開始および終了する必要がありますが、サービス組織にとっては、顧客が内部にいる場合もあります。このようなチェーンを介した価値のスループットは、KPIを改ざん防止の方法で設計するための良い方法です。バリューチェーンの個々のリンクでKPIを測定することは、その特定のリンクがプロセスのボトルネックであり、ボトルネックを悪用または拡大しようとする場合にのみ意味があります。

KPIの一般的な問題は、チェーンの途中で開始することです。たとえば、変更とリリースのプロセスは、多くの場合、開発者で始まり、展開で終わります。このプロセスは除外しました：

• 問題があるお客様
• 問題を特定するサポートチーム
• バックログの問題を定義する製品チーム
• お客様の展開をカスタマイズするソリューションチーム
• ソリューションから価値を実現するお客様

問題は、サイクルタイムだけを測定すると、2つの大きな問題が発生する可能性があることです。

1. ボトルネックは、上記の除外された部分のいずれかにあり、顧客は価値を実現しておらず、サイクル時間の速度に比例した収益を実現していません。したがって、エンジニアリングは優れていますが、ビジネスは苦しみます。

2. 顧客との接続が切断されると、リリースサイクルが空になり（変更が行われても価値を生まない）、顧客のニーズに対抗することさえできます。

KPIのもう1つの問題は、顧客との開始時と終了時に、実際に顧客に対する価値を測定できない場合があることです。良い例は、KPIとしての問題およびインシデント対応プロセスとMTTR（平均修復時間）です。問題は誰にも影響しますか？顧客にとっての価値は何ですか？100件のインシデントで3時間という優れたMTTRが得られる可能性があります。しかし、それらの大部分が内部にあり、顧客への影響がまったくないか最小限であり、数分で解決した場合、顧客への影響が大きい大規模なインシデントの処理には3日かかりましたが、ビジネス価値は1日のMTTRを持っている場合よりも低くなります内部のインシデントのほとんどを無視しますが、1時間以内に巨大な顧客影響インシデントに対応しました。

注：内部顧客の場合、サポートチームのビジネスプロセスの場合、導出された値は内部顧客にとっての仕事の価値ではなく、ビジネスプロセスで内部顧客のブロックを解除することで得られる価値です。自分のプロセスのボトルネックとなっているチームのブロックを解除すると、ボトルネックでないチームまたは個人のブロックを解除するよりも高い価値が得られます。このようなサポートチームのすべてのKPIは、ビジネス価値を計算に含める必要があります。

1. 展開頻度
2. 展開の速度
3. 展開成功率
4. 展開に失敗した後のサービスの復旧可能性
   最後に、
5. 実際に測定できないDevOps文化