SRE Meetup Tokyo にて発表 https://connpass.com/event/66219/

1. SLO のすすめ
Takeo Sawada
Dropbox, Inc.
September 25, 2017

2. 自己紹介
名前 澤田 武男
Twitter @SawadaTakeo
2013 - 2014 Ads Backend SRE @Google HQ
Display Ads Backend など
2014 - 2017 Source SRE @ Google NY
Piper (Google のプロプライエタリなソースコン
トロールシステム)
Git (Android, Chrome, code.google.com,
Cloud Source Repositories)
ローンチ調整エンジニア (LCE, SRE 本 27 章)
SLO の策定、モニタリング、障害対応、
PRR(SRE 本 32 章) など
2017 - Build SRE @ Dropbox
Changes (内製の CI ツール)
Bazel クラスタ

4. 今日の話題
SRE 本第 II 部 原則 から
4 章: 「サービスレベル目標」
外部に直接面していないような
サービスでもサービスレベル目
標を有効に使ってほしい
5 章: 「トイルの撲滅」

5. サービスレベル目標

6. サービスレベル目標とは何か
用語: SLI vs SLO vs SLA
SLI - Service Level Indicator: 指標
例: リクエストの成功率
SLO - Service Level Objective: 目標
例: 各四半期中の全リクエストの成功率は 99.9%以上です。
SLA - Service Level Agreement: 合意
例: SLO が満たされなかった場合、利用料の 50%を返金します。
サービスレベル目標: あるサービスの信頼性についての数値目標

7. SLO を定義するメリット
どのくらいの信頼性を目指すのかをはっきりさせる
コストや開発速度とのトレードオフをしっかりと議論する機
会になる
SLO によってサービスのアーキテクチャ、チーム体制、モニ
タリングの感度、障害対応などが変わってくる
「高い信頼性」という曖昧な目標から、チームメンバーが共
有する 1 つの数値目標へ
エラーバジェットでトレードオフのバランスを取る (SRE 本
3 章)
過剰な要求からチームを守る
あらかじめステークホルダーに SLO を共有し合意しておく
達成困難な信頼性目標を要求された時に参照できる
過剰に依存されるのを避ける
ユーザに対してあらかじめ「期待できる信頼性」を示しておく
自サービスより高い信頼性が求められるサービスに不適切に
組み込まれるのを避ける

8. SLO の定義のしかた
1. SLI にするメトリクスを決める
2. 目標を決める
3. Profit!!!
サービス、ユーザ、チームなどによるので「正しいやり方」は無い

9. SLI の選びかた
ユーザ体験の満足度への近さ
モニタリングの容易さ
安定して収集し分析できるメトリクス
シンプルさ
SLI はできるだけ少なくする
さまざまなカテゴリ
可用性 (Availability)
レイテンシー (Latency)
耐久性 (Durability)
スループット (Throughput)
まずは可用性から始めてみよう

10. SLI をモニターする
ユーザートラフィックを直接計測する
エラーの分類:リクエストが失敗した原因がユーザにあるか
サービス側にあるかを正しく分類する
全てのリクエストを SLO でカバーすべきか考える (リクエス
トの種類、サイズなど)
トラフィックパターンに影響を受けやすい
プローブ用のトラフィックを生成し計測する (ブラックボッ
クスモニタリング)
ユーザ環境に近い地点で計測できる
全てのコードパス、リクエストパスを検査するのは大変
ref. SRE 本 6 章 「分散システムのモニタリング」

11. SLO の定義の色々
例えば “99.9%の Uptime” と言っても...
ある期間中の全てのリクエストとエラーを集計したエラー率
が 0.1%以下
ある期間を数分のウィンドウ単位に分割し、99.9%以上の
ウィンドウでエラー率が x% 以下
ある期間を数分のウィンドウ単位に分割し、各ウィンドウの
エラー率を平均したものが 0.1% 以下
Amazon S3, Google Cloud Storage などがこの形式
サービスの特性、ユーザの期待などに合わせて適切な定義を選ぶ

12. SLO が達成できなかったら？
リリースをフリーズ
障害の多くは変更に付随して発生する
信頼性に関する改善の優先順位を上げる
目標そのものを見直す
ref. SRE 本 3 章 3.4 エラーバジェットの活用

13. Public SLA へ
外部に公開する SLA はプロダクトデザインレベルの選択に
なる
SRE が技術的な判断や情報を提供しつつ、開発者、PM と議
論する

14. トイルの撲滅
ref. SRE本5章

15. トイルとは何か
プロダクションサービスを動作させることに関係する作
業で、
手作業で繰り返し行われ、
自動化することが可能であり、
戦術的な価値を持たず、
作業量がサービスの成長に比例する

16. トイルの例
リリース作業
手作業でのテスト
バックアップ作業
データベースのクリーンアップなど
VM のセットアップ、追加、削除など
アラート、障害対応
0 にするのは難しいものもある

17. トイルが多すぎると
SRE のポジションのキャリア上の魅力が減る
採用が難しくなる
SWE への転出
生産性の低下
手作業によるミスの発生
Google では 50%を目標にしている。
ref. SRE 本 5 章 5.4 トイルは常に悪なのか？

18. トイルの削減: オンコール対応の例
行っている作業を見直し、地道に自動化、改善していくしかない
週に数十以上のページ (アラート) が発生して多大なオンコー
ル対応負荷が生じていた (SRE 本 11 章 11.3 バランスの取れ
たオンコール)
対応
毎週プロダクションミーティングを開催 (SRE 本 31 章 31.1)
その週におきた全てのアラートとその対応をレビュー
重大な障害にはポストモーテムを書き、その後ポストモーテ
ムレビューを実施 (SRE 本 15 章)
場当たり的な修正に変えて
根本的な原因の修正。時間のかかるものはプロジェクト化
他チームのバグの積極的な修正依頼
プレイブック (手順書) の強化
不要なアラートの見直し
数ヶ月の取り組みでページ頻度が 1/5 程度に

19. ありがとうございました。
ご質問、ご感想は
Twitter @SawadaTakeo
までお気軽に!