SREにおける指標可視化の話

岩崎です。自分はギターを弾くのが趣味なんですが、最近はよく晴れた日に河原で練習したりして楽しんでいます。島岡さんのベースに触発されてというわけではないのですが、音楽は楽しいですね(^^)

さて、今回はCAMPFIRE SREにおける指標の可視化について書きたいと思います。

サービスレベル目標

SREにおいて、サービスレベルの定義は重要です。サービスレベルを指標化し目標を定義することによって初めてエラーバジェットの策定や効果的な改善が可能になります。SLA（サービスレベルアグリーメント）を設定するかはサービスによって異なるでしょうが、SLI（サービスレベル指標）とSLO（サービスレベル目標）はサービスの種類に関わらず設定するべきでしょう。

CAMPFIREではサービスレベル目標に可用性を設定しており、サービスレベル指標にはMackerelのアラートを置いています。アラートの設定はCPUやメモリの使用率といった内部的なメトリクスではなく、HTTPレスポンスコードやレスポンスタイムなど、よりユーザーに近い指標を設定するようにしています。

また可用性とは別にMTTR（平均復旧時間）やMTBF（平均故障間隔）も取っており、障害発生後の復旧時間や障害の発生頻度も計測しています。

エラー数

CAMPFIREではRollbarというエラーモニタリングサービスを使っており、エラー発生時にSlackに通知しているのですが、このRollbarのエラー数を指標として取得し、エラーバジェットを設定〜エラーバジェットを全て消費した場合は積極的にエラーを直すという運用をしています。

本来のGoogle SREであれば、エラー数は可用性と連動しており、エラーバジェットを消費し尽くした場合は新規開発を控えるといった対応を取ると思いますが、今の組織の状況的に開発を控えることは現実的ではないため、あえて少し独自解釈をして運用しています。以下はエラーバジェットを超過した時に通知してくれるbotです。どこかで見たことがありますね。

エラー修正は基本的にアプリケーションエンジニアに対応してもらっており、opsだけでなくdevが普段からエラーについての意識を持つことで、よりバグの少ないシステムを維持することができています。

このあたりは様子を見ながら調整していく予定ですが、今のところうまくいっているように思います。

デプロイ数

前回の記事でも書いたように、デプロイ周りの改善も数値を取って行なっています。具体的には以下のように全体のデプロイ数、プルリクエスト数、一人当たりのデプロイ数、デプロイ時間などを指標として取得しています。

・全体

上の資料は全体の月別デプロイ数ですが、SRE活動を始めた1月と比較して大幅にデプロイ数が向上しているのがわかると思います。もちろん人数が増えているからというのもありますが、人数が増えてもスケールできるようにデプロイ時間の短縮などを行なってきた成果です。

・月詳細（1月）

・月詳細（9月）

月単位で見ていくと、1月は一日の平均デプロイ数が2回程度だったのが、9月では一日だけで11回デプロイしている日もあります。DevOpsの起源とも言われるFlickrのスライドのように、まさに「10 deploys per day」が実現できていることになります。やったぜ🎉

なぜ数値を取る必要があるのか

数値化は一見トイルのように見えるかもしませんが、工夫次第で自動化することは可能です。数ヶ月に渡って改善してきた活動を振り返って、数値を取るという行為には以下のようなメリットがあると思います。

まず、数値を取って可視化することにより、何がボトルネックなのかを把握でき、目に見える形で検証や改善ができること。数値がなければ感覚でPDCAを回すしかありませんが、数値があればデータを元に改善していくことが可能です。

次に、一般的にあまり評価されにくいインフラや運用などの仕事が評価される材料になること。目に見える形で成果が出れば、上の人間に活動の正当性をアピールすることができますし、評価する側にとっても指標があればより評価しやすくなるでしょう。

最後に、ビジネス側やアプリケーション側と共通認識を持って仕事にあたることができること。DevOpsの元々のモチベーションとしてDevとOpsの衝突がありますが、このように数値を取って状況を全員に可視化することで、場合によっては開発を抑え（て可用性を高め）たり、積極的にエラーを発生させ（ることを許容して開発を優先し）たりといった判断が可能になります。結果的にどのような方向に向かうにせよ、このように全体として共通認識を持つことは非常に大切だからです。