Four Keysって何？
Four Keysを計測しようとなった背景については前の記事をご覧いただければと思いますが、Four Keysについて引用しておきます。
Four KeysとはDevOps Research and Assessment（DORA）チームが実施した 6 年間の研究から確立された、ソフトウェア開発チームのパフォーマンスを示す 4 つの指標です。
・デプロイ頻度
・変更のリードタイム
・変更障害率
・サービス復元時間
（前回の記事より引用）
計測するまでの流れ
Four Keysの計測ができるようになるまで、以下の流れで進めていきました。
それぞれ詳しく見ていきたいと思います。
- まず各指標の定義を決める
- データ収集の方法を決める
- データ収集のシステム構築
- ダッシュボード化
まず各指標の定義を決める
Four Keysでは4つの指標が示されていますが、具体的な定義についてはウエディングパークに合う形にしたいと思い、定義の認識を揃えるところから始めました。事前に各自で指標の理解を深め、自分なりに定義を考えて持ち寄ってから一つに絞っていきました。
＜Four Keysについて情報をインプット＞
＜自分なりに良いと思った定義を持ち寄ってディスカッション＞
決めた定義は以下の通りです。
| リードタイム | featureブランチのfirst commit時間〜masterにマージされた時間 ※土日祝除く |
| デプロイ頻度 | masterにマージされた回数 ※リポジトリごとそれぞれカウント ※SQL実行も1回とみなす |
| 平均修復時間 | 障害発見から復旧までの平均時間 |
| 変更失敗率 | 施策数に対する障害発生率 ※エンジニア施策もチケットに起こして対応する ※簡単なテキスト文言修正なども含める ※過去の案件は過去の障害率を更新する |
定義を決める際に気をつけたのは、今の開発フローを変えずにできるかどうか。開発環境を改善するための取り組みなので、計測をするために負担が増えてしまっては元も子もないからです。結果として、新しい作業をほとんど増やすことなく全ての指標を集計できる形になりました。
データ収集の方法を決める
手動で集めることももちろんできましたが、今回はAWSのOpenSearchを使ってデータ保存と可視化をすることにしました。OpenSearchを選んだ背景は以下の通りです。
- 今後負担を増やさずに運用できる
- 必要なデータさえ入れておけば、可視化の形は後からいくらでも変更できる
- 他の部署にも簡単に横展開できる
- この施策も技術挑戦にしてしまう←ここ重要
データ収集のシステム構築
コミットデータをGitHubとGitLabから送信するバッチと、不具合報告データをスプレッドシートから送信するGASを作成しました。
ほとんどマスクしてしまっていますが、1行が1施策データ・1報告データのように保存されます。
Hotfixを考慮する必要があることや、本番環境にマージされるPRに複数の案件が混ざる場合に各案件のfirst commitを取得する必要がある部分で苦戦しました。
ダッシュボード化
OpenSearchではVisualizeページで様々な可視化方法が選択できます。今回は主にVertical BarとTSVBを使用して可視化しました。
