ソフトウェアアーキテクチャメトリクスを読む（その1）
今回から、積み本になっていたオライリーの「ソフトウェアアーキテクチャメトリクス」を読んでいきたいと思います。
定義と計測
「Lean とDevOps の科学」のソフトウェアデリバリーに対する、メンタルモデルから4つのキーメトリクスが生まれた。
このメンタルモデルが、この本の土台となるらしい。
デプロイの頻度
パイプラインを経由してくる（特定の時間内の）変更の数。
コードや設定、それらを組み合わせた「デプロイメントユニット」が含まれる。
変更のリードタイム
コードや設定の変更がパイプラインを経由して最後まで到達する時間。
「デプロイの頻度」と「変更のリードタイム」のメトリクスを通して、開発のスループットを計測する。
原書の中で、リーンの文脈におけるサイクルタイムやリードタイムとは混同しないように注意書きされている。
コードを書く時間や、それ以前の作業を含めないこと。
変更時の障害率
パイプラインを経由して出てきた変更が、サービスに障害を引き起こす割合。
サービス復旧時間
サービスに障害が発生した場合、復旧するまでにかかる時間。
「変更時の障害率」と「サービス復旧時間」のメトリクスを通して、サービスの安定性を計測する。
これら4つのメトリクスすべてに注目してバランスをとる。
メンタルモデルのリファクタリング
これらのキーメトリクスはメンタルモデルなので、実際に自分たちの状況に合わせて定義する必要がある。
メトリクスが4つあるので、計測する箇所も4つ必要になる。
- コミットタイムスタンプ
- デプロイタイムスタンプ
- 障害が発生したときのタイムスタンプ
- 障害が解決済みとしてマークされたときのタイムスタンプ
コミットタイムスタンプ
ベストプラクティスとしては、開発者が変更を完了しコミットした時点。
ブランチ上で変更を長期間保持している可能性があるので注意が必要。
デプロイタイムスタンプ
パイプラインが完了した時点。
デプロイ完了後の手動テストも範囲に入れてもいいが、それはチーム次第。
この2つのタイムスタンプがあれば、パイプラインの総実行時間を算出できる。
パイプラインが複数あったり、複雑な場合は計測も複雑になるが、ユーザのサービス利用に影響を
与えるデプロイのビルドだけを集計する。
失敗した場合のデータは集計に含めないこと。
障害の監視
障害の監視は難しい。
障害が発生していても、誰も気づかないなら、障害が発生していたと言えるかが問題になる。
筆者は、障害を「サービスの利用者が、自分が行おうとしていた作業を完了できないとき」
と定義しているらしい。
この定義には主観的な判断が含まれるが、それは問題ない。
自分が納得のいく定義を決めて、それに誠実に従うこと。
これが定義できると、障害をチケットとして作成し、このチケットの作成と終了のタイムスタンプを記録する。
記録と算出
これらのデータからメトリクスを算出するが、最初は手動で問題がない。
デプロイの頻度
特定の期間内に成功したデプロイの総数。
筆者は1日が期間として効果的だと感じているらしい。
デプロイがない日はゼロとして、1日単位で記録して合計する。
メトリクスの報告として使う値は、1ヶ月間のような長い期間での平均にする。（期間が短いと変動が大きすぎるらしい）
変更のリードタイム
この値は変動する可能性があるので、日ごとに平均を出す。
メトリクスの報告として使う値は、1ヶ月間のすべての計測値の平均にする。（日ごとの平均値だけでなく、計測値も記録しておくこと）
変更時の障害率
特定の期間のデプロイ数に対して、障害が発生したデプロイ数の割合。
障害が発生したデプロイ数は、解決済みの障害チケットから出す。
メトリクスの報告として使う値は、1ヶ月間の解決した障害数を、同じ期間のデプロイ数で割る。
サービス復旧時間
障害チケットが作成されてから閉じられるまでの時間。
筆者は、4ヶ月間で発生したすべての障害解決時間を取得しているらしい。
メトリクスの報告として使う値は、それらの平均にする。
これらのメトリクスの算出に使うデータは、すべてオープンに取得する。
そのためにも、キーメトリクスの監視をチームに勧める。
算出されたメトリクスともとのデータ、算出のロジックも公開すること。
メトリクスの定義もデータと一緒に公開しておくと、チームの透明性が上がり、キーメトリクスに対する理解が高まる。
今回の感想
リポジトリが複数あったり、パイプラインが複雑だとメトリクスを収集するのが大変です。
モノレポを検討したり、パイプラインを統合することも検討しないといけないと思いました。
障害のチケットに関しても、リポジトリが別れていると、それぞれにIssueを発行することになるので計測が難しくなりそうです。
ベストプラクティスは提示されているが、基本的には自分たちのチームに合ったやり方を考える必要があると感じました。
この記事を書いた人
- 事業開発部 web application engineer
-
2008年にアーティスへ入社。
システムエンジニアとして、SI案件のシステム開発に携わる。
その後、事業開発部の立ち上げから自社サービスの開発、保守をメインに従事。
ドメイン駆動設計（DDD）を中心にドメインを重視しながら、保守可能なソフトウェア開発を探求している。
この執筆者の最新記事
関連記事
関連する記事はありません
最新記事
FOLLOW US
最新の情報をお届けします
- facebookでフォロー
- Twitterでフォロー
- Feedlyでフォロー