本稿は JCB Advent Calendar 2023 の12月18日の記事です。
はじめに
DXテックG SRE チームの小柳津です。
SRE チームは JCB Digital Enablement Platform (JDEP) 上で稼働しているアプリケーションチームに対し「より生産性の高い、ハイパフォーマンスなチームを目指す」ための支援を実施しています。
そこで SRE チームではチームのパフォーマンスを評価する Four Keys と呼ばれる指標を取得するよう取り組みましたのでご紹介します。
Four Keys とは
DevOps Research and Assesment (DORA) チームにより提唱された、開発チームのパフォーマンスを示す以下の4つの指標を指します。
| 定義 | |
|---|---|
| デプロイの頻度 | 組織による正常な本番環境へのリリースの頻度 |
| 変更のリードタイム | commit から本番環境稼働までの所要時間 |
| 変更障害率 | デプロイが原因で本番環境で障害が発生する割合（%） |
| サービス復元時間（MTTR） | 組織が本番環境での障害から回復するのにかかる時間 |
取得した指標をもとに DORA チームは以下の通りパフォーマンスレベルを分類しています。
| Elite | High | Medium | Low | |
|---|---|---|---|---|
| デプロイ頻度 | オンデマンド（日に何度も） | 1日に1度 ~ 週に1度 | 週に1度 ~ 月に1度 | 月に1度 ~ 半年に1度 |
| 変更のリードタイム | 1日未満 | 1 日 ~ 1 週間 | 1 週間 ~ 1 ヶ月 | 1 ヶ月 ~ 半年 |
| 変更障害率 | 5% | 10% | 15％ | 64% |
| サービス復元時間（MTTR） | 1時間未満 | 1 日未満 | 1 日 ~ 1 週間 | 1 週間 ~ 1 ヶ月 |
エリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud Blog より抜粋
JDEP における指標の定義
JDEP ではソース管理を GitLab で、インシデント管理を PagerDuty で行っているため、指標もそれらから取得します。
| 情報ソース | 取得するイベント | 取得方法 | |
|---|---|---|---|
| デプロイ頻度 | GitLab | GitLab Releaseをデプロイとして扱う | GitLab Releaseの数をカウント |
| 変更のリードタイム | GitLab | 同上 | featureブランチの最初のコミットの時間から、GitLab Releaseを作成した時間 |
| 変更障害率 | PagerDuty | リリース起因の障害を障害情報として扱う | リリース起因のPagerDutyインシデントに固定フラグをつけたものが対象。 固定フラグのついたインシデントの数 / リリース回数（％）で取得する。 |
| サービス復元時間（MTTR） | PagerDuty | 同上 | リリース起因のインシデントの発生からクローズするまでにかかる時間（hour） |
指標取得のための機構
アーキテクチャは DORA チームが提供している OSS dora-team/fourkeys を利用し、下図のように JDEP 用に改修・構築しています。
JDEP は Google Cloud を採用しており、提供されている OSS も Google Cloud を想定したものであったため導入しやすいことも Four Keys を採用した理由のひとつです。
指標取得までの流れ
上記のアーキテクチャを利用してどのように4つの指標を取得しているでしょうか。
流れを説明していきます。
- 各リソースからイベントを Webhook で取得
あらかじめ Webhook のヘッダーにトークンを含めておく。 - GitLab や PagerDuty からの Webhook を受け付ける LB を経由
Cloud Armor を利用し LoadBalancer で受け付ける通信を制限する。 - "Event Hundler" と呼ばれる CloudRun が取得元リソースを判定
ここで項番1にてヘッダーに含めていたトークンと SecretManager に保持しているトークンを照らし合わせ取得元が正しいか検証する。 - Pub/Sub を経由して送られたデータを BigQuery に登録できるよう CloudRun が変換
- BigQuery に登録されたデータを Grafana で可視化
JDEP では OSS で提供されている Grafana を利用しています。
JDEP のパフォーマンスレベルは？
執筆時点ではアプリケーションチームに展開する活動をしており、プレ導入として SRE チームも含まれる Platform チーム（※）のみ適用している状態です。
（※）チーム体制については 長沼の記事 を参照ください。
ここまでご紹介したので、Grafana を使用した Four Keys ダッシュボードをお見せします。
幸いなことに Platform 起因による障害は発生していないためサービス復元時間（MTTR） の計測はできていませんが、デプロイ頻度と変更リードタイムについては指標の推移が確認できます。
中央のパネルは DORA チームの評価の定義に基づいた Platform チームのパフォーマンスレベルです。いずれもレベル High の評価となっています。
おわりに
このように Four Keys を用いることで各開発チームの評価、改善すべき項目について可視化されるため、チームの活動を振り返り改善を促すいい機会にすべく SRE チームは活動を続けています。
全チームへの展開が進み、JDEP としてパフォーマンスレベルが取得できた際はパフォーマンスレベルの改善活動とともにご紹介したいと思います。
最後になりますが、JCB では我々と一緒に働きたいという人材を募集しています。
詳しい募集要項等については採用ページをご覧下さい。
本文および図表中では、「™」、「®」を明記しておりません。
記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です。
