DevOps 指標

測定できないものは改善できないという古い格言は、他のプラクティスと同様に DevOps にも当てはまります。より高品質の製品をより速くリリースするという DevOps の約束を果たすには、チームは多数の指標を収集、分析、測定する必要があります。これらの DevOps 指標から、DevOps チームが開発パイプラインを可視化して制御するために必要な重要なデータが得られます。

DevOps 指標とは

DevOps 指標とはデータ ポイントであり、DevOps ソフトウェア開発パイプラインのパフォーマンスを直接明らかにして、プロセスのボトルネックをすばやく特定して除去するのに役立ちます。これらの指標は、技術的能力とチーム プロセスの両方を追跡するために使用できます。

DevOps の本質は、開発チームと運用チームの境界をぼかして、開発者とシステム管理者のコラボレーションを強化することに重点を置いています。これらの指標によって、DevOps チームはコラボレーション ワークフローを測定して評価し、品質の向上、リリース サイクルの短縮、アプリケーション パフォーマンスの向上など、目標達成の進捗状況を大まかに追跡できます。

4 つの重要な DevOps 指標

DevOps のパフォーマンスを測定するために使用される指標は多数あります。すべての DevOps チームが測定するべき 4 つの主要指標を次に示します。

1. 変更のリード タイム

追跡する重要な DevOps 指標の 1 つは、変更のリード タイムです。サイクル期間 (後述) と混同しないでください。変更のリード タイムは、コード変更がトランク ブランチにコミットされてからデプロイ可能な状態になるまでにかかる時間です。たとえば、コードが必要なすべてのプレリリース テストに合格するまでの時間です。

2. 変更エラー率

変更エラー率とは、本番運用後にホット フィックスまたはその他の修復を必要とするコード変更の割合です。これは、テストで検出されてコードがデプロイされる前に修正されたエラーを測定するものではありません。

3. デプロイ頻度

DevOps の成功を理解するには、新しいコードが本番環境にデプロイされる頻度を把握することが重要です。多くの実践者は、本番運用前のステージング環境にリリースされるコード変更を意味して「デリバリー」という用語を、本番環境にリリースされるコード変更を意味して「デプロイ」という用語を使用しています。

4. 平均復旧時間

平均復旧時間 (MTTR) は、部分的なサービス中断または全体的な障害からの復旧にかかる時間を測定するものです。これは、中断が最近のデプロイの結果であるのか、単独のシステム障害の結果であるのかにかかわらず、追跡するべき重要な指標です。

DevOps 指標を測定、使用、改善する方法

DevOps ライフサイクルの他の要素と同様に、継続的改善の文化が DevOps 指標にも適用されます。開発の各フェーズで迅速なフィードバックを受け取れる環境にあること、そこにフィードバックを実装するスキルと権限が伴うことは、パフォーマンスの高いチームの特長です。DevOps に関する書籍『Accelerate (Lean と DevOps の科学)』では、上記の 4 つのコア指標は、パフォーマンスの高いソフトウェア チームが採用する 24 の機能によって支持されていると言及されています。以下では、これらの機能のほとんど (CI/CD、テストの自動化、小規模バッチにおける作業、監視、継続的な学習) をカバーしていますが、これらのプラクティスを裏付ける研究をより深く掘り下げるには、ぜひ『Accelerate (Lean と DevOps の科学)』をご一読ください。

変更のリード タイム

通常、パフォーマンスの高いチームはリード タイムを時間単位で測定しますが、パフォーマンスが中程度のチームや低いチームは、リード タイムを日単位、週単位、さらには月単位で測定します。

テストの自動化、トランクベース開発、小規模バッチにおける作業は、リード タイムを改善するための重要な要素です。これらのプラクティスに従うことで、開発者は、コミットしたコードの品質に関するフィードバックをすばやく受け取って、欠陥を特定して修正できます。開発者が別々のブランチに存在する大規模な変更に取り組んで、手動テストに頼って品質管理を行っている場合は、ほぼ間違いなくリード タイムが長くなります。

変更エラー率

パフォーマンスの高いチームの変更エラー率は 0 ～ 15% の範囲です。

リード タイムの短縮を実現するプラクティス (テストの自動化、トランクベース開発、小規模バッチでの作業) は、変更エラー率の低下にも関連しています。これらのすべてのプラクティスに従うことで、欠陥の特定と修復がはるかに容易になります。

変更エラー率の追跡と報告は、バグの特定と修正のためだけでなく、新しいコード リリースがセキュリティ要件を満たしていることを確認するためにも重要です。

デプロイ頻度

パフォーマンスの高いチームはオンデマンドで変更をデプロイして、1 日に何度も繰り返すこともよくあります。パフォーマンスの低いチームは、多くの場合は、週に 1 回または月に 1 回のデプロイが限界です。

オンデマンドでデプロイするには、前のいくつかのセクションで言及した自動テストおよびフィードバック メカニズムを組み込んで、人間の介入の必要性を最小限に抑える自動デプロイ パイプラインが必要です。

平均復旧時間

パフォーマンスの高いチームはシステム障害から迅速に復旧 (通常は 1 時間未満) する一方で、パフォーマンスの低いチームは障害からの復旧に最長で 1 週間かかる場合があります。

障害から迅速に復旧できるかどうかは、障害の発生を迅速に特定して、修正をデプロイしたり、障害の原因になった変更をロールバックしたりする能力によって決まります。これは通常、システム ヘルスを継続的に監視して、障害発生時に運用スタッフに警告することによって行います。運用スタッフは、インシデントを解決するために必要なプロセス、ツール、権限を持っている必要があります。

MTTR では、平均故障間隔 (MTBF) に焦点を当てるという従来の慣習からシフトすることに重点を置いています。これは、最新のアプリケーションでは複雑さが増して、それに伴って障害予測値が上昇したことを反映しています。また、継続的な学習と改善の実践を強化します。障害を回避するためにデプロイが「完璧」になるまで待つ (したがって、古い MTBF スコアボードをリセットする) のではなく、チームはデプロイ作業を何度も繰り返します。MTTR では「完璧な」MTBF レコードを台無しにしたことを非難するのではなく、チームがアップストリームのプロセスとツールを改善できるように、誰も責めることなくふりかえりを実施することが奨励されています。

その他の関連指標

もう 1 つの関連指標にサイクル期間があります。これは、リリースの準備が整うまでチームが対象アイテムに費やす作業時間のことです。開発の世界では、開発者がコミットしてから本番環境にデプロイされるまでの時間を指します。DevOps のこの主要指標は、プロジェクト リードやエンジニアリング マネージャーが開発パイプラインで何がうまくいっているかを的確に理解するのに役立ちます。結果として、関係者や顧客の期待に沿った作業を行って、チームの迅速なリリースを約束できます。

サイクル期間レポートによって、プロジェクト リードは開発パイプラインのベースラインを確立できます。これは、将来のプロセスを評価するために使用できます。チームがサイクル期間に対して最適化を図ると、通常、開発者の進行中の作業が減って、非効率的なワークフローが少なくなります。

リーン プロダクト マネジメントでは、バリュー ストリーム マッピングに重点を置いています。これは、製品または機能のコンセプトからデリバリーまでの流れを視覚化したものです。DevOps 指標は効果的なバリュー ストリーム マッピングと管理のための重要なデータ ポイントの多くを提供しますが、真のエンドツーエンドな評価を行うためには、他のビジネス指標と製品指標によって補強する必要があります。たとえば、スプリント バーンダウン チャートは見積と計画の各プロセスの有効性に関するインサイトを提供するのに対して、ネット プロモーター スコアは最終成果物が顧客のニーズを満たしているかどうかを示します。

結論

継続的な改善は、DevOps を実践するチームの中核的な信条です。変更のリード タイム、変更エラー率、デプロイ頻度、MTTR から全体的なパフォーマンスを測定して追跡できると、チームはベロシティを加速させて品質を向上させられます。

アトラシアンの Open DevOps では、チームにとってソフトウェアの開発と運用に必要となるものがすべて提供されます。チームは、大手ベンダーや Marketplace アプリとの統合によって、DevOps ツールチェーンを自由に構築できます。今すぐ試してみましょう。