こんにちは。奥村です。
2020年6月頃から私の所属するチームが主導となり、各サービス・プロダクトでSLOを決めていくプロジェクトに取り組んでいます。
今回のブログでは、SLOを決めるにあたって登場する要素に名前を付けたのでそちらを紹介します。
私達の組織ではこうしました、という例を示せればと思います。
チーム紹介
サービスの非機能系の改善を図る事でサービス・開発のアジリティを高めるのを目的として活動しております。
特定のシステムを開発・運用しているチームに所属しているわけでは無く、横断的に複数のシステムに協力しています。 また、アジリティを上げる事を目的としておりますので、GitLab Serverの運用やSaaSの契約など、開発によるエンジニアリング以外も行っております。
ざっと以下の様な事を行っております。
- システムのCI/CD導入・導入支援
- Infrastructure as Code導入・導入支援
- サービスの監視・モニタリング改善
- サーバーのインベントリ情報のデータソース管理
- GitLab Server運用
- Tableau Server運用
- 各種SaaS契約
- クラウド移行支援
- SLO策定推進
過去にこんな記事も書きましたので興味あれば御覧ください。
SLOを策定するに至った経緯
以前に、私達のチームで「SRE本読書会」を行っていました。
内容としては
- O'Reilly Japan - SRE サイトリライアビリティエンジニアリング を各メンバーが事前に読む
- 各メンバーが感想、議論したいことを共有する
- 議論する
- アクションを生み出す
です。
読書会の議論を通して、『SLO決めたいよね〜』という気持ちが私達のチーム内で高まっていました。
ちょうどその時、日々プロダクトチームと協力していく中で、「何から改善するべきか？」「どの程度やるべきか？」「どのようにして効果を計測するのか？」が度々議題として挙がっていました。
定量的な指標であるSLOを採用するにはちょうど良いということで、SLOの説明会などを開催し組織的に策定していく事になりました。
言葉の定義
下記の書籍やドキュメントを参考にし、言葉を定義していきました。
| 言葉 |
説明 | 補足 |
|---|---|---|
| ワークメトリクス | 有用な出力を測定することで、システムのトップレベルのヘルスを示すもの
など |
Datadogが提供している資料 で使われていた言葉をそのまま使っている。 ブラックボックスメトリクスとSRE本には記載されているようなもの |
| リソースメトリクス | システムのリソースを示すメトリクス
|
|
| イベント | 個別かつ不定期に発生する事象だが、システムの動作の変化を把握するための重要なコンテキストを提供するもの
|
左記のような『イベント』を管理することで、どのタイミングでパフォーマンスが低下したか等を計測することが出来る アプリとインフラの実態以外の操作や事象を指す |
| SLI | Service Level Indicator（サービスレベル指標） サービスの健全性を表す指標 SLIはワークメトリクスから決める。 SLI:ワークメトリクス = 1:n SLOを決めないSLIもある。 |
ワークメトリクスを計算や統合してSLIを作成することもあるし、ワークメトリクスが直接SLIになる事もある。 SLIが複数という状況は定義に合わないので、SLOを増やす事を検討する必要がある。 SLIに昇格しなかったものはワークメトリクスと呼び続ける。 |
| SLO | Service Level Objective（サービスレベル目標） SLIの目標値 SLIとSLIの目標値のセット |
SLO：SLI：ワークメトリクス = 1:1:n |
| エラーバジェット | SLOを策定した結果導かれる、発生しても良いエラーの量 SLOで決めた目標値と現在のメトリクスの値の差分 エラーバジェットを使い切ると新機能のリリースをとめる。 |
エラーバジェットがなくなった場合は新機能のリリースを止める必要がある。 リリースを止める範囲はSLOを策定している範囲。一般的にはサービス・プロダクト単位になる。 さらなる新機能リリースによってエラーの発生率が増え、SLOを下回り続ける事を避けるために新機能のリリースを止める必要がある。 |
エラーバジェットについて発生した議論
言葉の定義とは別に、「エラーバジェットを使い切ったときは何をするべきか？」という事に関して議論がありました。
議論の主たる内容は、
- 「エラーバジェットを使い切ったら新機能のリリースを止めるべき」
- 「エラーバジェットを使い切ったときの対応はチームに毎に判断するべき」
上記のどちらの意見で今後プロジェクトを進めるか？というものでした。
私は「エラーバジェットを使い切ったときの対応はチームに毎に判断するべき」という意見を持っていまいた。
これは私が「エラーバジェット = エラーの予算」という、そのままの意味で言葉を認識して意見を出した事によります。
最終的にSRE本に「新機能のリリースを止めるべき」という事が記載されているかつ、広くその意味が使われていることから、「エラーバジェットを使い切ったら新機能のリリースを止めるべき」という決定になりました。
これにより「エラーバジェット」という言葉も定義できました。
SLIとSLOが決まったからといってエラーバジェットの運用を行えるか不安に思っています。
SLO策定後の最初の方は、さまざま理由により「エラーバジェットが無くなっても新機能のリリースを止める事はできない」ということが発生する懸念をしています。
そこで意見として出たのが、
- エラーバジェットが枯渇する前にSLIの数値を改善する努力をする。そのために、内部的な2段階のSLOを決めておく。
- エラーバジェットの運用を行わず、SLOを「改善タスクの割合を増やす判断をするための指標」にする。
などが出ています。
実際のところまだSLOが明確に決まったチームが無いので、対策については書けませんがいずれ、ブログで公開できるかと思われます。
まとめ
何かしらのプロジェクトを他のチーム・組織と進めていく上で、共通認識の多さがプロジェクトの進捗に大きく影響すると思います。
比較的簡単に共通認識を増やせる「言葉の定義」はやったほうが良いと感じてます。
最後までご覧いただきありがとうございました。
