CI/CD パフォーマンスの計測と監視
継続的改善は、DevOps の哲学を支える礎の 1 つです。
それは、私たちが構築する製品やサービスから組織の文化やプロセスなど、ソフトウェア開発の全要素に及ぶものです。
継続的改善では、私たちが構築したものやうまく機能しているもの、改善の余地があるものなどに関するフィードバックを収集して分析します。 そうしたインサイトを適用してから、フィードバックを更に収集することにより、変更内容の効果を確認します。必要であれば、引き続き調整を加えて行きます。
CI/CD パイプライン は、ソフトウェアの継続的改善を可能にする上で中心的な役割を果たします。 開発からデプロイまでの時間を短縮することで、変更内容をユーザーにリリースする頻度を高められます。そうすることで、実際の使用からフィードバックを受けられるため、次の優先事項が明らかになります。 同様に、自動化されたテストの各ステージから迅速にフィードバックが提供されるため、簡単にバグの修正を行えるほか、ソフトウェアの品質も管理しやすくなります。
ですが、継続的改善はこれだけではありません。 同じ手法を CI/CD パイプラインそのものに適用することにより、ソフトウェアのビルド、テスト、リリースの各プロセスを洗練できます。そうすることで、製品の改善に使用するフィードバックループが拡大されます。
パイプラインの指標を理解する
「計測できないものは、管理もできない」という言葉があります。
指標は、システムパフォーマンスを改善するのに欠かせないツールです。価値を付加できる領域を特定するのに役立ち、また各改善が生み出すインパクトを測定するためのベースラインを提供してくれます。
CI/CD のパフォーマンスには、スピードと品質の両方が含まれます。変更内容をスピーディにデプロイすることと堅牢で信頼できる製品を提供することに妥協があってはいけません。優れた CI/CD パイプラインがあればこの両方を実現できます。
アクティビティのスピード、ソフトウェアの品質、およびオートメーションを活用している度合を計測し、管理すれば、改善の余地がある領域を特定できます。それから、加えた変更内容にプラスの効果があったのかどうかを確認します。
DevOps のトップレベルパフォーマンス指標
次に紹介する 4 つの指標は、DevOps Research and Assessment (DORA) によってハイレベル指標として指定されているもので、これらはソフトウェア開発のコンテキストにおける組織のパフォーマンスを正確に示します。
You can learn more about the research that informed these choices in the book Accelerate.
リードタイム
リードタイム (タイム・トゥ・デリバリーまたはタイム・トゥ・マーケットとも言われる) は、機能が最初に提案されてからユーザーにリリースされるまでの時間として計測できるものですが、アイディエーションやユーザー調査、プロトタイプの作成に要する時間は大きく変化する傾向にあります。
このため、DORA はコードがデプロイにコミットされる時点から時間の計測を開始するアプローチを取っています。こうすることで、CI/CD パイプラインのスコープ内のステージだけに集中できます。
リードタイムが長くなると、変更されたコードを定期的にユーザーにリリースでおらず、製品を洗練するのに役立つフィードバックを活用できていないことを意味します。 この要因はいくつか挙げられます。
リリースパイプラインに膨大な数の手動テスト、リスクアセスメント、変更内容のレビューボードなど、手動で対応するステップが数多く含まれていると、プロセスを何日も、何週間も長引かせることがあり、頻繁にリリースを行うアドバンテージが損なわれてしまいます。
前者の課題については、テストの自動化に投資すれば対応できる一方で、後者については、関係者とのエンゲージメントを通じて各々のニーズをより効率的に満たせる方法を理解することが必要になります。 また、自動化されたステップが遅かったり、信頼性を欠いたりする場合は、ビルド所要時間の指標を使用すれば最も時間を要するステージを特定できます。
デプロイの頻度
デプロイの頻度は、CI/CD パイプラインを使用して実稼働にデプロイしている頻度を記録します。 デプロイの頻度が高いことは各デプロイにおける変更内容が少ないことを意味するため、この指標は DORA によってバッチサイズのプロキシとして選択されています。
少ない変更内容を頻繁にデプロイすることで、リリースに関連付けられているリスクの発生を軽減できます (組み合わさって予期せぬ結果を引き起こす不確定要素が少ないため)。また、フィードバックもよりスピーディに提供できます。
デプロイの頻度が低いことは、パイプラインへのコミットが定期的に行われていないことを意味する場合があり、タスクが分割されていない、変更内容が大きなリリースに一括でまとめられているなどの理由が考えられます。
ユーザーからの期待に応えるためなど、ビジネス上の理由で変更内容を一括にまとめる必要がある場合は、ステージングサイトへのデプロイ頻度を計測すれば、バッチサイズをモニタリングし、変更内容を毎回少量に抑えることにメリットがあるのかどうかを判断できます。
変更の失敗率
変更の失敗率とは、実稼働にデプロイされる変更内容のうち、サービスの停止、またはロールバックやホットフィックスが必要なバグなど、失敗に終わるものの割合を指します。 この指標の利点は、失敗したデプロイを加えられた変更の量に関連付けて考慮するという点です。
変更の失敗率が低いと、パイプラインのその時点までの各ステージがそれぞれの役割を果たし、実稼働にコードがデプロイされる前にほとんどの不具合を発見できていることを意味するため、パイプラインに自信を持てるでしょう。
平均修復時間
平均修復時間または平均解決時間 (MTTR) は、実稼働の失敗に対処するまでに要する時間を計測するものです。 MTTR では、多くの不確定要素を伴う複雑な環境で一部の失敗が発生することは避けられないと認識されます。 パーフェクトな環境を目指すことよりも (そして、結果的にリリースを遅らせ、頻繁にリリースするメリットを犠牲にするのではなく)、素早く課題に対応することの方が大切なのです。
MTTR を低く保つには、実稼働システムを積極的にモニタリングし、問題の発生に合わせてアラートを発すること、および変更内容をルールバックする能力、またはパイプラインを通じて素早く修正プログラムをデプロイする能力の両方が必要です。
関連する指標に平均検出時間 (MTTD) がありますが、それは変更がデプロイされてから、その変更が原因で起こる問題をモニタリングシステムが検出するまでの時間を計測するものです。 MTTD とビルド所要時間を比較すると、MTTR を短縮するために投資をすることが、このいずれかの領域の改善につながるかどうかを判断できます。
CI と運用指標
こうしたハイレベルな計測の他にも、パイプラインのパフォーマンスに関する理解を深め、プロセスを改善できる可能性がある領域を特定するのに役立つ運用指標が多く存在します。
コードカバレッジ
CI/CD パイプラインにおいて、自動テストはテストカバレッジの大半を提供し、QA エンジニアが探索的テストを実施したり、新しいテストケースを定義したりすることに集中できるようにするものでなければいけません。 ユニットテストは、一番素早く実行できる上に、すかさずフィードバックを提供してくれるため、自動テストで最初に実行される第一層とするべきです。
コードカバレッジは、ほとんどの CI サーバーが提供する指標であり、ユニットテストでカバーされるコードの割合を計算する指標です。 十分なテストカバレッジが維持されていることを確認しながらコードを書けるため、この指標はモニタリングする価値があります。 コードカバレッジが減少傾向にある場合は、フィードバックの第一線となるこの指標の改善に取り組む必要があります。
ビルド所要時間
ビルド所要時間またはビルド時間は、自動化されたパイプラインの様々なステージを完了するのにかかる時間を計測します。 プロセスの各ステージで消費している時間を確認すれば、テストのフィードバックを得たり、デプロイの実用を始動させたりするのを遅らせている可能性がある難点やボトルネックを発見できるので便利です。
テスト合格率
テスト合格率は、特定のビルドで正常に合格したテストケースの割合です。 自動テストが合理的なレベルで行われる限り、各ビルトの品質を示す良い目安となります。 この指標を使用すれば、コードの変更がテストを失敗させている頻度を把握できます。
手動テストを行ったり、実稼働中に問題を発見するよりも、自動テストを行って失敗を見つける方が望ましい一方で、一連の特定の自動テストが普段から失敗している場合は、そうした失敗の根本的な原因を探る価値があるかもしれません。
テスト修正の所要時間
テスト修正の所要時間は、テストの失敗がビルドによって報告されてから、同じテストがその後のテストを合格するまでに要する時間です。 この指標は、パイプラインで特定された問題に対応できるスピードの目安です。
修正までの所要時間が短いことは、パイプラインを最大限に活かしていることを意味します。問題が見つかると同時に対応すれば、(変更内容が未だ頭の中で新鮮に残っているため) より効率的に作業を行えるほか、不安定なコードを土台に別の機能を構築してしまうことを避けられます。
失敗したデプロイ
失敗したデプロイが予定外のダウンタイムを引き起こす場合、そのデプロイはロールバックするか、すぐリリースできるように修正プログラムが必要になります。 失敗したデプロイの回数は、変更の失敗率 (上述) を計算するのに使用されます。
デプロイの合計数のうち、失敗する割合をモニタリングすると、SLA に対するパフォーマンスを評価しやすくなります。
失敗するデプロイの数を 0 (または少数) に抑えることを目標に掲げることは、必ずしも現実的ではなく、むしろチームが確実性を優先するように仕向けてしまいます。 そうすると、複数の変更内容が一まとめにされることでリードタイムが長くなり、またデプロイも規模が大きくなってしまいます。結果、(不確定要素が増えるため) 実稼働中に失敗が起こる可能性が高まり、(確認が必要になる変更内容も増えるため) 修正が困難になります。
欠陥数
失敗とは違い、欠陥数はバックログでバグとして分類されているオープンチケットの数を意味します。 テスティングやステージング、および’実稼働で見つかった問題別に細かく分類することもできます。
コードカバレッジと同様に、欠陥数をモニタリングすると、バグが手に負えなくなっていることを意味する全般的な上昇傾向に対して注意を促すことができるので便利です。 ただし、この指標を目標にすると、チームはチケットを修正することよりも、それを分類することに集中してしまう場合があるので注意が必要です。
デプロイのサイズ
デプロイの頻度 (上述参照) に直結するものですが、デプロイのサイズはビルトまたはリリースに含まれるストーリーポイントの数によって計測されるもので、特定のチーム内のバッチサイズを監視するのに使用できます。
各デプロイを小規模に維持していることは、チームが定期的に責任を果たしていること、そしてそれに伴うすべてのメリットを確保できていることを示します。 ただし、ストーリーの見積りは開発チーム全体で比較できるものではないため、デブロイの全体的なサイズを計測するためにこの指標を使用することはお勧めしません。
まとめ
こうした指標を監視しておけば、CI/CD パイプラインのパフォーマンスの現状、および上昇傾向にあるのか、減少傾向にあるのかについて、理解を深めることができます。
各指標を使用すると、プロセスにおいてより深く注目すべき領域を特定できます。 変更を加えた後は、引き続き関連する指標を監視し、意図した効果が得られたのかどうかを確認すると良いでしょう。
しかし、指標はパフォーマンスの効果的な目安となる一方で、関連する数字を読み取り、特定の指標に着目することにより、どの動作が促進されているのかを検討することが大切です。 目指すのは、数字そのものではなく、むしろパイプラインをスピーディで確実に機能するものとして維持することにより、引き続きユーザーに価値を提供することです。