巷で話題の「開発チームのパフォーマンスの可視化のための"Four Keys"」について調べたメモです。
!!!(言い訳＆注意）夜間の勢いで走り書きしたものですので、参照したブログの内容と、私自身の雑なコメントが入り混じったものになっています。下手に参考にせず原典を参照してください!!!
参照先
- エリート DevOps チームであることを Four Keys プロジェクトで確認する
なお、上記の原典のブログは"2020-09-23"に公開されていますが、First Commitは"2020-07-09"でしたので、いづれにしろここ2年ほどで広まってきたものだと考えて良さそうです。*1
概要
DORAと呼ばれる権威あるDevOpsの研究組織が6年の歳月をかけて研究した結果生み出された、ソフトウェア開発チームのパフォーマンスを示すたった4つの指標とのこと。
この指標が示すのは、ソフトウェア開発チームのパフォーマンス
つまり、ソフトウェア開発のパフォーマンスを計測したくなければ特にいらないもの。
つまり（2回目）、今の状況だとソフトウェア開発のパフォーマンスが見えてない or 不足を感じているということ。*2
これらを可視化し『改善を繰り返すことでパフォーマンスおよびビジネス成果を大幅に向上できる」らしいです。
DORAによるとパフォーマンスに応じて以下の分類が存在します。
- エリート
- 高
- 中
- 低
この分類の中で”エリート”は”低”の2倍のパフォーマンスを発揮する可能性があるとDORAの調査結果は示している。*3
4つのKey
- デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度
- 変更のリードタイム - commitから本番環境稼働までの所要時間
- 変更障害率 - デプロイが原因で本番環境で障害が発生する割合（％）
- サービス復元時間 - 組織が本番環境で障害から回復するのにかかる時間
分類
- 速度の指標
- デプロイの頻度
- 変更のリードタイム
- 安定性の指標
- 変更障害率
- サービス復元時間
始め方
- データの収集
- Four Keys OSSプロジェクトがあるのでこれを活用しても良い
- https://github.com/GoogleCloudPlatform/fourkeys
- Star数は2022-06-20時点で 983 であり、少なくも無いが広く普及しているとも言えない
- GCPにしか対応しておらず、AWSをメインで使うケースで利用が簡単では無い
"Four Keys パイプライン"と"データの抽出と変換"はゆるくスルー
ドキュメントには以下のようにあります。
Four Keys パイプラインは、DevOps データを収集して DORA 指標に変換する ETL パイプラインです。
大変興味深いがこれは完全にGCPを想定しており、データストアとしてはBigQueryとなっている。しかし私がメインで使うのはAWSであるため概要の理解にとどめて流し読みしました。
次の"データの抽出と変換"についても以下の説明があるとおりGCP前提のため軽く流しました。
Four Keys は BigQuery のスケジュールされたクエリを使用して、元イベント テーブルからダウンストリーム テーブルを作成します。
指標の計算
このセクションは興味深いです。一般的な指標、特にGoogle社が関係するようなケースは漏れなくシステム的な取得を行うべしと考えていましたが、ドキュメントには人間へのヒアリングを行ったとありました。これはGoogleが行ったわけではなくDORAの研究チームによるものが大きいようです。
DORA チームによる独自の研究では、システムデータを収集するのではなく、実際の作業者を対象に調査を行い、以下のように指標をパフォーマンス レベルに分類しました。
ここで立派な表が提示されますが、そのまま引用するのも躊躇われるため雑な翻訳版を記します。
| ソフトウェアデリバリーの性能指標 | エリート | 高 | 中 | 低 |
|---|---|---|---|---|
| デプロイ頻度 メインサービスのデプロイがコードからお客様に届ける頻度 |
随時 | 1日から1週間以内 | 1週間から1ヶ月以内 | 1ヶ月から半年以内 |
| 変更のリードタイム | 1日未満 | 2日から1週間以内 | 1週間から1ヶ月以内 | 1ヶ月から半年以内 |
| 変更障害率 | 0-15% | 0-15% | 0-15% | 46-60% |
| サービス復元時間 | 1時間未満 | 1日未満 | 1日未満 | 1週間から1ヶ月以内 |
各指標の深掘り
デプロイの頻度
- 最も収集しやすい
- 計算が難しい
- ボリュムーではなく頻度であることに注意
- 営業日換算。正常デプロイが1回以上行われた日数の中央値が3以上なら毎日と言える
- デプロイの成功条件については？
- ビジネス要件によって異なる
変更のリードタイム
- ２つの重要なデータが必要
- commitoの発生時点
- デプロイの実行時点
- commitのSHAマッピングとトリガーを使うと簡単
変更障害率
障害＝インシデント
- 2つの数値に基づいて決まる
- 施行されたデプロイの数
- 本番環境でインシデントが発生する原因となったデプロイの数
- インシデントの件数は以下のようなものから取得する
- GitHubのIssueのバグや、インシデントのラベル
- フォームからスプレッドシートへのパイプライン
- 課題管理システム
- 唯一の条件は、デプロイのIDが含まれていること
- これによってデプロイとインシデントの紐付けができる
- つまりデプロイには必ずIDが必須である
サービス復元時間
- 以下の確認が必要
- インシデントが作成された時点
- インシデントが解決された時点
- これ手作業でのフォローだと取得大変そう（Slackのログからとって手動入力しかないのでは）
- より詳細には
- インシデントが作成された時点
- デプロイによりそのインシデントが解決された時点
- 変更障害率と同様に、データはさまざまなインシデントを管理するシステムから収集される
可視化
データが集約と処理をした後は"Four Keysダッシュボード"で可視化をします。 これによって開発者チームは早い段階でパフォーマンスの定価を把握でき、これを緩和するための対応を取れるそうです。
所感
概要は難しいものではありませんでした。ただしこれをちゃんと取得して可視化するまでの道のりは簡単では無い印象でした。 特に以下のような点は大きく歴史を重ねてきたシステムと運用の中で取得してくのは大変でしょう...
- ”デプロイID”と”インシデント”の紐付けが
- デプロイ方法が複数あり、IDをそもそも付与しづらい
- インシデント報告者が複数部署にまたがるため、デプロイIDを調べる方法の提供が困難かもしれない
- インシデントの収集
- インシデント報告先が複数あり、かつ部署ごとに権限制御などもある可能性
