タグから見つける

タグから見つける

職種を選択

事業領域を選択

Four Keys 〜自分たちの開発レベルを定量化してイケてる DevOps チームになろう〜

はじめに

この記事タイトルに興味をもって読み始めていただいている方の多くは、ソフトウェアエンジニアとしてチームで開発をしていたり、エンジニアリングマネージャーとしてチームビルディングやマネジメントをされている方なのではないかと思います。

実際、この記事を書いている加藤も、リクルートライフスタイルのデータプラットフォームグループ (以前は CETチーム と呼ばれていました) に所属するデータエンジニアとして、データ活用のための基盤開発・運用を行っている一人です。また、担当している社内データプロダクトのプロダクトマネージャーも兼任しています。

本記事では、自分の所属している DevOps チームを「イケてる DevOps チーム」にするために取り組んだ内容や気づいた点をお伝えしたいと思っています。

目次

「イケてる」DevOps チームってなに？

さて、いきなりですが、「イケてる」DevOps チームといったときに皆さんは何を思い浮かべるでしょうか？「チームで作っているプロダクトやシステムが価値を発揮している」ことが認められれば、イケていると言えそうですね。もしくは「心理的安全性が高い環境が整っていること」だったり「HRT の原則を守っているチーム」のようなメンバーコンディションの側面もありそうです。チームの目的や成熟度などによって、イメージするものは様々かと思います。

実際、チームのパフォーマンスを測る指標は数多く存在します。

例えば、Google re:Work - チーム では、心理的安全性や相互信頼といった観点が重要であるとし、チームの効果性を測る指標をいくつか定義しています。 また、ビジネス貢献額・eNPS などチームを定量的に評価する指標は数多く存在します。

私たちのチームでも eNPS の計測を行ったり、心理的安全性・相互信頼・HRT を大切にしようといったポリシーを定めたりと数多くのチームを良くするための取り組みをしてきました。

そのような取り組みの中で、本記事で紹介するのは 「DevOps チームとしてのパフォーマンス」を評価する 「Four Keys」 と呼ばれる指標です。

Four Keys とは

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

それは、以下の 4 つの指標です。

指標 概要
リードタイム コードが commit されてから本番環境で正常に実行されるまでの時間
デプロイ頻度 コードを本番環境にデプロイまたはエンドユーザーにリリースした頻度
変更失敗率 本番環境に変更を加えた、またはユーザーへのリリースを実施した結果サービスが低下し、その後修正を行う必要が生じた割合
復元時間 サービスインシデントまたは不具合が発生したときにサービスの復元にどれくらいの時間がかかるか

これらの指標は Nicole Forsgren Ph.D 他 『Lean と DevOps の科学』 (インプレス) で言及されている指標で、 和田 卓人 (@t_wada) さんによる 質とスピード（2020春版） / Quality and Speed 2020 Spring Edition - Speaker Deck でも紹介されています。

また、Google Cloud では、「Four Keys」プロジェクトとしてこれらの指標を収集するプロジェクトが公開されています。(本ブログタイトルの Four Keys はこの呼称にちなんでいます)

なぜ Four Keys を選んだのか

後述しますが、以下の 3 点に従って技術の選定から実装まで行いました。

特に、「なるべく世の中基準の指標/定義を使う」を満たせるのが Four Keys の良いところです。

DORA のレポートでは、これらの指標に基づくクラスタ分析でチームを「エリート」「ハイ」「ミディアム」「ロー」の 4 つにグルーピングしています。この基準を使うことで、自分たちのチームが今どのレベルにあるのかをグローバルな基準で評価することができます。

elite Google Cloud で実行されている DevOps 組織の有効性を評価する | Google Cloud Blog より引用

社内の独自指標や独自アンケートを利用すると、社外や世界との比較ができません。また、計測された指標の良し悪しを判断することも場合によっては困難です。世の中基準で定義されてる指標を使うことでこれらの問題を解決し、客観的にチームのパフォーマンスを判断することが出来ます。

自動収集・可視化の仕組みの構築

「イケてる」DevOps チームを目指す第一歩として Four Keys を利用することをチーム内で合意し、自動収集・可視化の仕組みを構築しました。

ここからは、チームで構築した Four Keys の自動収集・可視化の仕組みについて説明していきます。

アーキテクチャ

architecture

アーキテクチャは以下の記事を参考に作成していますが、チームに合わせて改修を行っています

収集・蓄積・加工・可視化 の 4 つのフェーズに分けてそれぞれ説明していきます。

収集: GitHub Webhook

デプロイ頻度・リードタイム計測のための収集

私の所属するチームでは、GitHub Enterprise Server を利用しており、テスト・リリースのための CI/CD 環境を構築・運用しています。

データ基盤は GKE 上にいくつかのマイクロサービスによって構築されており、多くのリポジトリで Pull Request で 開発環境 (dev)、master merge で 検品環境 (stg)、tag/release で本番環境 (prd) へのリリースというフローをとっています。(GitOps を採用している一部リポジトリは、環境ごとのブランチへの Push がリリースとなっています。)

また、作業開始時にはまず Pull Request を作成してから作業をすすめるというチーム内ルールが有ります。

そのため、特定のリポジトリに対する GitHub イベントを収集することでリードタイム・デプロイ頻度は容易に算出することが出来ます。

変更失敗率・復元時間計測のための収集

変更失敗率・復元時間に関する指標は、IssueEvent を利用します。

チームでは、インシデントが発生した場合 Slack Channel と Issue の作成を行い、対応と管理を進める運用を行っています。

インシデントを管理するツールとして、Datadog の機能として提供されている インシデント管理 というものもあります。 チームのシステム監視には Datadog を利用しており、こちらも選択肢として検討しました。しかし、以下の理由でチームでは Issue でインシデントを管理しています。

  • 特定のメトリクスに紐付かないインシデント（ユーザー管理のシステムの障害やセキュリティインシデントなど）も記録したい
  • 開発に関わる情報を GitHub に集約することで、情報の分散を防ぎたい

データの収集方法ですが、インシデント発生時に作成する Issue Template の情報をパースすることで、変更失敗率や復元時間を計測するための情報を収集しています。

実際に、利用しているテンプレートの一部を紹介します。

Title Description
障害名称 障害の概要を１行で
障害レベル 内部で定められている障害レベルを記載
障害サービス どのマイクロサービス・インフラで障害が起きたか記載
環境 dev/stg/prd
(指標計算には本番環境のみ利用するが、復元が長引きそうな場合はどの環境であっても Issue を作成するルールのため環境という項目が存在する)
障害原因 障害のきっかけとなった PR のリンクを貼る (この情報を利用して変更失敗率を計算する )
障害発生時刻 yyyy-mm-dd hh:mm (ここから下の情報を利用して復元時間を計算する)
障害検知時刻 yyyy-mm-dd hh:mm
サービス復元時刻 yyyy-mm-dd hh:mm
恒久対応完了 yyyy-mm-dd hh:mm

IssueEvent は opened, edited, deleted, closed, reopened, labeled などのイベントに対して発火します。チームでは IssueEvent の最終更新時の情報を正として 加工: Changes/Deployments/Incidents テーブルの作成 を行っていますが、ここはチームの運用ルール等で柔軟に変更が可能だと思います。

大事なのは、きちんとテンプレートを用意して、プログラム上でパースが容易な形で情報を送ることです。

Webhook Server の設定

Four Keys の 4 つのメトリクスをすべて GitHub Event から計測できるように定義しました。あとは、GitHub > Org > Settings > Hooks から Webhook サーバの設定を行い、収集を開始するだけです。

Webhook 設定用サーバは Go で記述し GKE 上にデプロイしています（GKE 上にデプロイしている理由は、開発運用しているデータ基盤が既に GKE 上に構築されているためです。データ基盤の詳細は過去のテックブログも御覧ください。）

Webhook の設定で取得するデータと google/go-github における references は以下のとおりです

GitHub Event Go Struct
Branch or tag creation PushEvent
(Refs field で tag を判断)
Issues IssueEvent
Pull requests PullRequestEvent
Pushes PushEvent
(Refs field で branch を判断)
Releases ReleaseEvent

指定されたイベントから必要な情報をサーバ内で抽出し、構造化ログを出力します。

出力された構造化ログは BigQuery Logging Sink によって蓄積されます。

蓄積: BigQuery Logging Sink

GCP には Cloud Logging のログを BigQuery にエクスポートする機能があります

先程の構造化ログをフィルタする条件でログシンクを作成することでデータが BigQuery に蓄積されます。（個人的に、GCP の中でもかなりお気に入りの機能です） また、こちらの機能は Terraform も対応しています

GitHub - GoogleCloudPlatform/fourkeys では、複数のイベントを Pub/Sub 経由で BigQuery に蓄積していますが、Logging Sink でも蓄積は可能ですし、管理するコンポーネントも減るので個人的にはこの構成で満足しています。

加工: Changes/Deployments/Incidents テーブルの作成

取得したイベントをもとに各種 Four Keys のメトリクスを計算するためのテーブルを作成します。

google-extract-table エリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud Blog より引用

Google Cloud の例と同じく、収集した GitHub Event 情報を加工しテーブルを作成する方針をとっています。

Webhook は Org に対して設定しているので、リリースやインシデントに関係ないイベントも収集しています。従って、この加工フェーズでシステムに関係ないイベントの除外を行ったり、リポジトリのブランチ戦略ごとにデプロイの抽出ルールを変更したりしています。

また、前述した IssueEvent のデータをもとに、どのリリース/Pull Request が障害を引き起こしたか紐付ける処理も行います。

可視化: データポータル

テーブルさえ作成してしまえば、あとは可視化をするのみです。

私たちのチームでは データポータル を利用していますが、他の BI ツールでも可視化は可能です。

dashboard

ダッシュボードのレイアウトは GitHub - GoogleCloudPlatform/fourkeys を参考にしています。

チーム独自に追加したボードとして、どのマイクロサービスの変更がリリースされたかをチームで把握するためのグラフと、インシデント一覧の表を追加しました。

dashboard-sample

結果発表: 私たちはイケているチームだったのか

さて、気になる結果ですが、ブログ執筆時点でのチームの状況は以下のようになりました！

指標 エリート/ハイ/ミディアム/ロー
リードタイム ハイ
デプロイ頻度 エリート
変更失敗率 エリート
復元時間 ハイ/ミディアム
(同一基準のため)

ということで、リードタイム・復元時間の 2 項目がエリートに届いていないという結果でした。

この結果をチームで振り返り、すべての指標をエリートにするための改善案を日々推進しています。

取り組みを通じてチームで意識するようになったこと

Four Keys の一連の取り組みを通じて、チーム内ルールや働き方も同時に見直されるようになってきました。その中でもチームとして以下の 3 つが重要だとして認識をすり合わせました。

  • 推測するな、計測せよ
  • なるべく世の中基準の指標/定義を使う
  • 自動化できるものは自動化する

推測するな、計測せよ

ソフトウェアエンジニアの方は一度は聞いたことのある言葉かと思います。

物事を改善しようとするとき、今の状態の把握から目標設定に至るまで、計測できていないと改善のための経験学習サイクルを回すことができません。

これはチームの改善でも同様です。

ソフトウェアパフォーマンスのような計測しやすいものだけでなく、チーム自体のパフォーマンスに対しても徹底し、継続的な改善を行っていくことが大事です。

なるべく世の中基準の指標/定義を使う

記事前半でも言及しましたが、チーム内でしか使えない定義/指標だと外との比較が出来ず、結果として自分たちのチームやシステムがどのくらい優れているのかを判断することが出来ません。

そのため、なるべく世の中基準な定義/指標を使うことを第一にしました。

しかし、それでもチームにうまくあわない指標だったり、どうしても元の定義から変更したい状況が発生します。 その場合はなぜ変更したかを Pull Request を通じてきちんと議論を残すような運用をしています。

（チームでは、仕様・アーキテクチャ図・Working Agreement などはすべてドキュメント用リポジトリで管理し、Pull Request がメンバー内で承認されてからドキュメントに反映するフローをとっています。）

自動化できるものは自動化する

自動化の目的の 1 つは、その取り組みを継続させる・スケールさせることです。

この Four Keys の計測も同じく、長期的に計測し、分析・改善を行う必要のある指標です。従って、自動化する仕組みを初期から検討していました。

しかし、自動化が難しい取り組みもあります。

automation xkcd: Automation より引用

この図は B. Beyer 他『サイトリライアビリティワークブック――SREの実践方法』（オライリー・ジャパン）: p97 でも言及されていた自動化に関する考え方の 1 つです。

先程説明したとおり、チームでは Four Keys 以外の指標も計測を始めていますが、全てを自動化しているわけではありません。

図の下のパターンのような、自動化に対するメリットに見合わないものは手動計測をするといったように、手動で計測するか自動化するかをきちんと見積もりを元に判断するようになりました。

終わりに

最後まで読んでいただきありがとうございました。

Four Keys の計測を通じて、チームの現状と「イケてる DevOps チーム」になるための目標を再認識するとともに、目標達成のための働き方や業務フローを見直すきっかけとなりました。

この記事の内容が、読んでいただけた方々の所属するチームのパフォーマンスについて話すきっかけとなっていただけたら幸いです。

一緒に働きませんか？

弊社では、事業を加速させるデータプロダクトの開発を始めとする様々な職種のエンジニアを募集しています。 興味のある方は以下の採用ページからご応募頂いたり、私の Twitter (@ko_da_k) にご連絡をいただければと思います。

参考一覧