エリート DevOps チームであることを Four Keys プロジェクトで確認する

※この投稿は米国時間 2020 年 9 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。 

DevOps Research and Assessment（DORA）チームが実施した 6 年間の研究から、ソフトウェア開発チームのパフォーマンスを示す 4 つの指標が確立されました。

• デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度

• 変更のリードタイム - commit から本番環境稼働までの所要時間

• 変更障害率 - デプロイが原因で本番環境で障害が発生する割合（%）

• サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間

 概要レベルでは、デプロイの頻度と変更のリード時間は速度の指標であり、変更障害率とサービス復元時間は安定性の指標です。チームはこれらの値を測定し、継続的に改善を繰り返すことで、ビジネス成果を大幅に向上させることができます。たとえば DORA はこれらの指標を使ってチームをそのパフォーマンスに応じてエリート、高、中、低に分類し、エリートチームが組織のパフォーマンス目標を達成または超える可能性は 2 倍であるとの調査結果を得ました。¹

これらの指標をベースラインとした組織のパフォーマンス分析は、運用の効率と効果を改善するための優れた手法です。それではどのように始めればよいでしょうか？最初はデータの収集です。これらの指標を生成し、チームに適用できるようにするため、Four Keys オープンソース プロジェクトが作成されました。このプロジェクトでは、GitHub または GitLab リポジトリから Google Cloud サービス、そして Google データポータルへのデータ取り込みパイプラインが、自動的にセットアップされます。その後データが集約、コンパイルされ、主な指標が表示されるダッシュボードに取り込まれます。ダッシュボードでは、時間の経過に伴う進行状況を確認できます。

Four Keys プロジェクトを利用できるように、デフォルトのソースからのデータ収集と DORA 指標の表示を容易にするためのセットアップ スクリプトをリポジトリに用意しました。プロジェクトへの協力、または各自のチームのユースケースに合わせたプロジェクトのカスタマイズに興味があるユーザーを対象に、3 つの主要コンポーネント（パイプライン、指標、ダッシュボード）について以下で説明します。

Four Keys パイプライン

Four Keys パイプラインは、DevOps データを収集して DORA 指標に変換する ETL パイプラインです。

ただし DORA 指標を収集する際の課題の一つとして、デプロイ、変更、インシデントの各データが通常それぞれ異なるシステムに分散しているという問題があります。これは、組織の全チームを見渡した場合はもちろん、ある 1 つのチームを取り上げてみた場合にも当てはまります。このようなさまざまなソースと、今後使用するソースからデータを収集するオープンソース ツールを開発するには、どうしたらよいでしょうか？

Four Keys ではこの問題に対する解決策として、さまざまなソースからの入力を処理できるように拡張可能な汎用パイプラインを作成しました。HTTP リクエストを出力できるツールやシステムであれば、Four Keys パイプラインに統合できます。Four Keys パイプラインは Webhook でイベントを受信し、BigQuery に取り込みます。

Four Keys パイプラインでは既知のデータソースが適切に解析され、変更、インシデント、デプロイに分類されます。たとえば GitHub への commit は変更スクリプトによりピックアップされ、Cloud Build によるデプロイはデプロイとして、「incident」ラベルが付いた GitHub 上の課題はインシデントとしてそれぞれ分類されます。追加された新しいデータソースが、既存のクエリでは適切に分類されない場合、デベロッパーは SQL スクリプトを編集してそのデータソースを分類し直すことができます。

データの抽出と変換

元データがデータ ウェアハウスに格納されている場合は、抽出と変換という 2 つの課題があります。ビジネスの柔軟性に対して最適化するため、これらのプロセスはいずれも SQL を使って処理されます。Four Keys は BigQuery のスケジュールされたクエリを使用して、元イベント テーブルからダウンストリーム テーブルを作成します。

Four Keys では、`WHERE` フィルタを使用してイベントが変更、デプロイ、インシデントに分類され、`SELECT` ステートメントを使用してデータが正規化および変換されます。変更、デプロイ、インシデントの正確な定義は、チームのビジネス要件に応じて異なります。このため、柔軟な方法でイベントを追加または除外できることが重要です。

Four Keys は WHERE フィルタを使用して events_raw テーブルから該当する行のみを抽出し、SELECT ステートメントを使用して JSON の対応するフィールドを commit ID にマップします。BigQuery でデータ変換を行うメリットの一つに、データを編集または再分類する際にパイプラインを再実行する必要がないことがあります。JSON_EXTRACT_SCALAR 関数を使用することにより、SQL 自体で JSON データを解析して操作することができます。また、BigQuery では SQL を記述する際にカスタム JavaScript 関数を使用することもできます。

指標の計算

このセクションでは、DORA 指標をシステムレベルの計算に変換する方法を説明します。DORA チームによる独自の研究では、システムデータを収集するのではなく、実際の作業者を対象に調査を行い、以下のように指標をパフォーマンス レベルに分類しました。

ただし、コンピュータに尋ねるよりも、実際の作業者にデプロイの頻度を尋ねる方がはるかに簡単です。DevOps マネージャーに対し、デプロイをどの程度の頻度（毎日、毎週、毎月など）で実行していたかを尋ねると、マネージャーは通常、自分の組織がどのカテゴリに分類されるかを直感で把握します。ただし同じ情報をコンピュータから取得する場合は、定義を非常に明確にし、自分で価値判断を下す必要があります。

次に、指標の定義と計算における細かな意味を説明します。

デプロイの頻度

「組織による正常な本番環境へのリリースの頻度。」

デプロイの頻度は、必要なテーブルが 1 つだけであるため、最も収集しやすい指標です。ただし頻度に関する分類は、計算が難しい要素の一つです。毎日のデプロイ ボリュームの表示や、週単位のデプロイ平均回数の収集であれば簡単で単純ですが、この指標はデプロイのボリュームではなく頻度です。

Four Keys のスクリプトでデプロイの頻度が Daily（毎日）バケットに分類されるのは、1 週間のうち正常なデプロイが 1 回以上行われた日数の中央値が 3 日以上である場合です。わかりやすく言い換えると、「毎日デプロイする」というカテゴリに分類されるようにするには、ほぼすべての営業日にデプロイを実行する必要があります。同様に、ほとんどの週にデプロイを行う場合は Weekly（毎週）、ほとんどの月にデプロイを行う場合は Monthly（毎月）に分類されます。

次に、本番環境へのデプロイの成功の条件を検討する必要があります。トラフィックの 5% のみに適用されるデプロイを含めるべきでしょうか？80% の場合はどうでしょうか？最終的には、これはチームの個々のビジネス要件に応じて異なります。デフォルトでは、ダッシュボードにはすべてのレベルのトラフィックへの成功したデプロイが含まれますが、プロジェクトの SQL スクリプトを編集してこのしきい値を調整できます。

変更のリードタイム

「commit から本番環境稼働までの所要時間」

変更のリードタイムの指標には、commit の発生時点とデプロイの実行時点という 2 つの重要なデータが必要です。つまり、すべてのデプロイで、デプロイに含まれるすべての変更のリストを維持する必要があります。これは、commit への SHA マッピングとトリガーを使うと簡単です。デプロイ テーブルの変更のリストを使用して、変更テーブルに再び結合してタイムスタンプを取得し、リード時間の中央値を計算できます。

変更障害率

「デプロイが原因で本番環境で障害が発生する割合（%）」

変更障害率は、試行されたデプロイの数と、本番環境で障害が発生する原因となったデプロイの数という 2 つの数値に基づいて決まります。この数値を取得するため、Four Keys は合計デプロイ回数を必要とします。この数値はデプロイ テーブルから簡単に取得でき、インシデントにリンクされます。インシデントは、バグまたは GitHub インシデントのラベル、フォームからスプレッドシートへのパイプライン、課題管理システムなどから取得されます。唯一の要件は、デプロイの ID が含まれていることです。これにより、2 つのテーブルを結合できます。

サービス復元時間

「組織が本番環境での障害から回復するのにかかる時間」

サービス復元時間を測定するには、インシデントが作成された時点とインシデントが解決された時点を確認しておく必要があります。また、インシデントが作成された時点と、デプロイによりそのインシデントが解決された時点も確認しておく必要があります。変更障害率と同様に、このデータはインシデントを管理するさまざまなシステムから取得されます。

ダッシュボード

データがすべて BigQuery で集約、処理された後は、Four Keys ダッシュボードで可視化することができます。Four Keys セットアップ スクリプトはデータポータル コネクタを使用します。これにより、データを Four Keys ダッシュボード テンプレートに接続できます。ダッシュボードは、DORA の 4 つの主な指標に関する研究に基づく大まかな分類を示し、最近のパフォーマンスに関する実行ログを表示するように設計されています。これによりデベロッパー チームは早い段階でパフォーマンスの低下を把握でき、この低下を緩和する措置をとることができます。あるいはパフォーマンスが低い場合、バケットが更新される前に、チームが低下の兆候を早期に確認できます。

準備ができたら

Four Keys プロジェクトをご覧になり、お試しください。セットアップ スクリプトを実行すると、アーキテクチャがセットアップされプロジェクトと統合されます。フィードバックや投稿をお待ちしております。

DevOps の手法を適用してソフトウェア デリバリーのパフォーマンスを改善する方法については、cloud.google.com/devops をご覧ください。全体が Google Cloud 上でホストされているアプリケーションの DORA 指標収集に関するフォローアップ投稿も予定しております。

^{1. 2019 年 Accelerate State of DevOps: エリート パフォーマンス、生産性、スケーリング}

-デベロッパー プログラム エンジニア Dina Graves Portman