ポイント: 継続的デリバリーメトリクスは、DevOpsにおけるパフォーマンスを評価し、ソフトウェア開発とデリバリーを向上させます。ビルド品質やCIパイプライン内のセキュリティ統合などの重要なメトリクスに重点を置いています。
- 主要なパフォーマンス指標には、生産までのリードタイムとソフトウェアビルドの品質が含まれます。
- リスク軽減のためには、CIパイプラインの早い段階でのセキュリティ統合が不可欠です。
DevOpsアプローチは、ソフトウェア開発ライフサイクル（SDLC）の速度、品質、パフォーマンスを最適化することを目的として導入されました。このアプローチは、以下のベストプラクティスに依存しています：
- ソフトウェアエンジニアリング
- 組織文化
- ビジネス運営
- エンドユーザーとのインタラクション
DevOps組織では、これらのフレームワークガイドラインは、開発者、ITオペレーション、QA、情報セキュリティ、および他のチームが共通の目標に向かって共同で作業する中で採用されます。これにより、高品質のソフトウェアをリリースすることができます。では、DevOpsチームはこれらの目標を達成するためにどのようにパフォーマンスを評価するのでしょうか？この記事では、DevOpsにおける継続的デリバリーのパフォーマンスを評価するために使用されるいくつかの一般的なメトリクスを見ていきます。
重要な問題
効率的な継続的デリバリーサイクルを管理する最初のステップは、最も重要で影響力のあるリスクを排除することです。これらのリスクには、IT環境の基盤となるネットワークや技術の脆弱性が含まれており、これらは市場にリリースされる前にソフトウェアやデータ資産を危険にさらす可能性があります。例として挙げられるKPIは以下の通りです：
- すべてのアプリとサービスにおける重大な脆弱性の数
- ネットワーク侵入の試み
- 不正なトラフィックの使用またはデータ転送の試み
- 失敗したセキュリティテストの数
- 合格したセキュリティ監査の割合
継続的インテグレーション（CI）のパイプライン内にセキュリティを統合することは、しばしば困難であり、迅速なCDサイクルを追求する開発者にとっては歓迎されないことが多いです。そのため、セキュリティはSDLCの早い段階から構築されなければなりません。
効率性と生産までの時間
開発チームの主な目標は、最も機能的なソフトウェアビルドを短いCDサイクル内でリリースできるようにすることです。ITオペレーションの目標は、インフラストラクチャリソースが常に利用可能で、プロセスのコスト効率を最大限にするために最適に消費されることを保証することです。開発と運用は、以下のKPIを見て、継続的デリバリーサイクルのパフォーマンスを理解することができます：
- コードブランチの数。これは、進行中の機能コンポーネントの数を指します。不要なコンポーネントは、開発の負担とセキュリティリスクを増加させます。
- 生産までのリードタイム/サイクルタイム。新しいビルドを実装、テスト、提供するのにかかる時間。このKPIは、リスク、技術的負債、監視メトリクス、及びチーム、バージョン、SDLCの成熟度に影響を与える他の依存関係など、いくつかの変数に依存します。
- 価値までの時間（TTV）。TTVは、全体のCDサイクルではなくリリースプロセスを評価します。これは、コードを書く時間とリリースする時間の間の時間を指します。言い換えれば、新しいソフトウェアビルドからエンドユーザーがどれだけ早く価値を得るかに焦点を当てています。
- チームの定着率。組織文化を評価するためのソフトメトリクスとして使用され、チームの定着率は、従業員がCDサイクルの目標ペースで働くことを楽しんでいるかどうかを示すことができます。従業員がDevOpsチームで過ごす平均的な時間が答えとなるかもしれません。
ビルドの品質と運用
インフラのパフォーマンスは、DevOpsチームの最優先事項の1つです。ソフトウェアビルドがテストまたは本番環境にデプロイされると、そのインフラの各ノードに大量のログメトリクスが残されます。この情報は以下の目的に役立ちます：
- 基盤となるインフラの健康状態を理解する
- アプリケーションを最適化する
- 潜在的なセキュリティの抜け穴を特定する
これらの目標を達成するために役立つメトリクスには以下が含まれます：
インフラ利用率
一部のノードは過剰に割り当てられていますか？特定の期間において、どのノードが重大なエラーを示していますか？ネットワーク全体のすべてのノード、サーバー、仮想マシン、および他のハードウェアや仮想化コンポーネントにわたるインフラ利用率を分析することで、すべてのソフトウェアビルドバージョンにおける真のパフォーマンスを理解することができます。
生産のダウンタイムとMTTR
サービスレベルアグリーメント（SLA）メトリクスは、CDサイクルの可用性、パフォーマンス、応答に関するものであり、アプリケーションサービスに対して指定され、適用されるべきです。継続的なフィードバックと改善は、継続的デリバリーサイクルの成熟度を向上させるために使用されることができます。
エラー数/エラー率
これは、新しいビルドにおけるバグや生産問題を特定するために使用できます。これらのエラーは、原因を徹底的に評価しなければならず、さまざまな要因に依存する可能性があります。
テスト統計
テストの数、CDパイプラインとテストの完全性、テストカバレッジは、ソフトウェアビルドの品質やテストプロセスの効率性を理解するのに役立ちます。
チケット処理時間
効果的なチケット解決は、エンドユーザーが直面している特定の問題を解決するだけでなく、問題の根本原因を理解することに主に焦点を当てています。たとえば、大量の反復的なチケットは、技術、アプリパフォーマンス、またはSDLCプロセスの制御に関連する特定の再発問題に関する洞察を提供します。
継続的デリバリーには測定が必要
DevOps組織は、エンジニアリング原則として継続的デリバリーの実践を採用しています。継続的プロセス内で高品質のソフトウェアビルドを提供するには、組織が以下を行う必要があります：
- ベースラインメトリクスを確立する
- DevOpsとアジャイルの方法論を採用する
- データから得られる洞察を活用して繰り返す
最終的に、改善は、継続的デリバリーメトリクスに基づいてSDLCワークフローやインフラおよび運用の変更に見られる具体的な変化を通じて観察されます。
関連する読み物
DevOpsガイド
- DevOpsとは？包括的な紹介
- DevOpsの簡潔な歴史
- DevOpsアーキテクチャの紹介
- DevOpsにおける自動化：なぜ自動化するのか、そしてどのように自動化するのか
- CI/CDとは？継続的インテグレーションと継続的デリバリーの説明
- Jenkinsを使用してCI/CDパイプラインを構築する方法
- CI/CDパイプラインを最適化するためのDevOpsメトリクス
- 継続的デリバリーメトリクス
- 継続的インテグレーションから継続的デプロイメントへの進行は進行なのか - それともそうではないのか？
- 継続的インテグレーション（CI）、デリバリー（CD）、およびデプロイメントの違い
- DevOpsにおけるソースとバージョン管理
- 継続的テストとは何か？
- テスト自動化フレームワーク：究極のガイド
- DevOpsにおけるリリース管理
- 説明：DevOpsにおける監視とテレメトリー
- DevOpsにおけるアプリケーションパフォーマンス管理
- SDLCにおけるDevOpsオーケストレーション
- データベースDevOpsの紹介
- DevOpsにおけるマイクロサービスの役割
- DevOpsにおける仮想化の役割
- コンテナとDevOps：コンテナがDevOpsデリバリーパイプラインにどのように適合するか
- コンテナパイプラインとは何か？
- DevOpsツールチェーンとは何か？
- DevOpsのためのコンテナとコードの管理
- DevOpsにおけるアジャイルの役割
- DevOpsにおけるクラウドの役割
- FinDevOpsとは何か？
- 2022年のDevOpsトレンド
- DevOpsの価値と原則
- DevOpsメトリクスとKPI
- 小規模、中規模、大規模組織向けのDevOpsアドバイス
- DevOpsチーム構造
- 今日読むべきDevOpsに関するトップの本
- 『The Phoenix Project: DevOps For Everyone』の書評
- DevOpsインフルエンサー：Twitterでフォローすべき11人のDevOps専門家
- GitHub、GitLab、Bitbucket、Azure DevOps：何が違うのか？
- ベストプラクティス：Kubernetes用のアプリケーションをアーキテクトする方法
- DevOpsにおける構成管理
- DevOpsのブランチ戦略の説明
- DevOpsの職務タイトル、役割、責任
- DevOpsにおけるテスト：概念、ベストプラクティスなど
- 2022年のDevOps認証ガイド
- Kubernetesオペレーターパターンとは？
これらの投稿は私自身のものであり、必ずしもBMCの立場、戦略、または意見を表すものではありません。