Atlassian Cloud への移行に関する 10 の誤解を正す

無料のホワイトペーパーで学ぶ Atlassian Cloud の利点

詳細を確認

CI/CD パイプラインのボトルネックを特定して解消するための 10 の重要指標

2020-05-07 (Thu)  •  By 伊藤  •  活用のヒント  •  DevOps

今回の記事は、ゴーツーグループ ブログ英語版「Ten Key Metrics That Help Identify and Fix Bottlenecks in Your CI/CD Pipeline 」の弊社翻訳版です。原文と差異がある場合は、原文の内容が優先されます。

はじめに

DevOps 構想を成功に導く秘訣は、「実装、測定、改善」です。特に継続的インテグレーション (CI) および継続的デリバリー/デプロイメント (CD) においては、注視すべき DevOps 指標が何かを理解し、ボトルネックを特定して解消することが重要です。このブログ記事では、組織が CI/CD パイプラインを高速化するために追跡すべき重要指標について取り上げます。これにより、どこから始めたらよいか、および自分の組織にとってどの指標が重要なのかを判断する材料としていただきたいと思います。

継続的インテグレーション (CD) および継続的デリバリー (CD) の指標の種類

DevOps の主な目標は、時間、品質、スピードという 3 つの側面が中心となっています。前述の要素に基づいて、指標を以下のようにまとめることができます。

時間ベースの指標

DevOps の主な目的の 1 つは、時間を節約してコードを可能な限り素早く顧客へ届けることです。そのため、CI/CD の取り組みの評価は、関連する作業それぞれにかかる時間を測定することが主な作業になります。組織がよく利用する時間ベースの指標は以下のとおりです。

市場化までの時間 (TTM)

TTM とは、機能のコンセプト考案から製品化までの時間を指します。CI/CD の取り組みにより、機能を顧客に届けるまでの時間は格段に短縮されます。従来のソフトウェア配信において社内ソフトウェア リリースにかかる時間は 3 ~ 6 か月ほどですが、継続的デリバリーでは毎週、または毎日でもリリースを複数回行えます。

このため、顧客への機能のリリースにかかる時間を注視し、継続的インテグレーションおよび継続的デリバリーの原理が TTM の短縮に貢献しているかどうかを見極めることが重要です。改善が見られない場合、利用している技術、開発者の作業負荷、機能の複雑さ、またはプロセス自体に問題がある可能性があります。CI/CD パイプラインのスピードアップを図るために、問題がどこにあるかを振り返り、修正する必要があります。

不具合解決時間

不具合解決時間 (または不具合の存続期間) は、コードの配信または展開後に挙げられた問題を解決するまでに要する時間を指します。不具合の解決にかかる時間は、顧客解約率に大きな影響を与えます。問題の解決にかかる時間が長いほど、顧客解約率は高くなります。そのため、DevOps を実践しているにもかかわらず不具合解決時間が長い場合は、早急に特定して修正する必要のあるプロセスのずれがあると考えられます。

コード フリーズから配信までの時間

チームでコード フリーズした時点からコード配信までの期間を表します。継続的インテグレーションはこの期間を短縮します。短縮されない場合は、その理由を特定して希望どおりの結果となるようやり方を微調整する必要があります。

展開時間

CI/CD 手法では多くが自動化されるため、コード展開はボタン 1 つで行われます。展開に 1 時間程度かかっている場合、プロセスは非常に非効率な状態にあります。この指標を監視することで、パイプラインの速度の妨げとなっているボトルネックを取り除き、展開頻度を上げることができます。

品質指標

品質指標の追跡は、常に DevOps の最も重要な側面です。自分のペースでコードの配信を行うとしても、コードの品質を損なうことは最も避けたいことです。そのため、品質の状態に目を光らせることは極めて重要です。組織が注視すべき品質指標には以下のものがあります。

テスト合格率

テスト合格率を確認することで、合格したテスト ケースの割合に基づいて製品の品質を明確に把握することができます。この数値は、実行したテスト ケースの合計数で合格したテスト ケースの数を割ることで算出できます。また、この指標は自動テストがどの程度良好に行われているか、およびどのぐらいの頻度でコードの変更がテストを中断させているかを計ることができます。継続的インテグレーションおよび継続的デリバリーは自動テストなしでは成しえませんが、正しく行っているかを確認する必要があります。

バグの数

バグだらけのコードを素早く配信しても顧客に届くバグの数が増えるだけであり、後で複雑な問題が発生する原因となるため、この指標は継続的デプロイメントでは非常に重要になります。そのため、バグの数を定期的に監視し、バグが急増した場合はその根本的な原因を調査する必要があります。バグだらけのコードがシステムに存在すると、いかに DevOps に取り組んでも良い結果は生まれません。

不具合エスケープ率

不具合エスケープ率は実稼働前のテスティングと実稼働環境で見つかった不具合の割合の対比を示します。実稼働環境で発見された不具合がどの程度あるかを調べることは、ソフトウェア リリースの品質全体を測る良い方法です。

実稼働環境で見つかる問題が多すぎる場合、自動テストや QA が正しく行われていないことが分かります。そのため、テスト作業を改善してスムーズに事が進むようにする必要があります。不具合エスケープ率はチームのパフォーマンスを絶えず評価する優れた指標です。

自動化指標

DevOps は自動化に依存するところが大きいため、展開プロセスに関して言えば、自動化がもたらす影響を理解することが重要です。自動化作業を数値化しつつ、改善の余地があるかどうかを測るための指標を以下に示します。

パイプラインごとの展開の規模

展開の規模 (またはバッチ サイズ) とは、月ごとまたはアプリケーションごとにリリースされた機能リクエストやバグ修正などのストーリー ポイントの数です。この数値はアプリケーションの種類とチームの作業速度に左右されますが、これまでの CI/CD の取り組みが生み出した結果を垣間見ることができるため、注視すべき重要な指標と言えます。

展開の頻度

展開の頻度は、製品またはプロジェクトの開発プロセス中のスループットがどうであったかを示す重要な指標です。Amazon や Netflix といった会社は毎日何千回もコードを展開しており、DevOps が適切に行われていることが分かります。皆さんの組織ではどうでしょうか?これはパイプラインの効率化のために知っておくべき指標です。

失敗した展開

コードを展開するたびに顧客から苦情を受けていますか?展開を行うことでダウンタイムが頻発していますか?これに当てはまる場合、この数値がビジネスにとって不可欠な指標になります。

展開のロールバックはできれば避けたいことですが、展開後に障害が頻発する場合は、素早くロールバックして業務の継続性を妨げないようにする必要があります。特に、顧客対応の業務では頻繁な障害の発生はあってはならないことです。そのため、平均故障間隔 (MTTF) を改善するために失敗した展開を追跡することが重要です。

まとめ

これらは DevOps の世界で頻繁に使用される重要指標の一部にすぎません。DevOps のエキスパートが勧める指標は他にも多数あります。結局のところ、組織にとって最も重要な指標は業務、組織、個々のニーズ、および改善したいと思っている事項によって左右されます。どんなケースにも通用する万能な手法というものはありません。

そのため、定期的にデータを収集し、そのデータを活用して組織を正しい方向に導くことが重要です。ただし、組織にとってさほど重要ではないデータ ポイントにこだわらないようにする必要があります。ビジネスの状態を正確に把握するために、最も重要なデータに注視するようにします。

DevOps の取り組みを成功させるために今すぐ実行できることを詳細にまとめたホワイト ペーパーは、こちらから ダウンロード できます。

  Previous Next  

関連記事