Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SLOのすすめ

5,168 views

Published on

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

Published in: Engineering
  • Follow the link, new dating source: ❤❤❤ http://bit.ly/39mQKz3 ❤❤❤
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Sex in your area is here: ❤❤❤ http://bit.ly/39mQKz3 ❤❤❤
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

SLOのすすめ

  1. 1. SLO のすすめ Takeo Sawada Dropbox, Inc. September 25, 2017
  2. 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 クラスタ
  3. 3. 今日の話題 SRE 本第 II 部 原則 から 4 章: 「サービスレベル目標」 外部に直接面していないような サービスでもサービスレベル目 標を有効に使ってほしい 5 章: 「トイルの撲滅」
  4. 4. サービスレベル目標
  5. 5. サービスレベル目標とは何か 用語: SLI vs SLO vs SLA SLI - Service Level Indicator: 指標 例: リクエストの成功率 SLO - Service Level Objective: 目標 例: 各四半期中の全リクエストの成功率は 99.9%以上です。 SLA - Service Level Agreement: 合意 例: SLO が満たされなかった場合、利用料の 50%を返金します。 サービスレベル目標: あるサービスの信頼性についての数値目標
  6. 6. SLO を定義するメリット どのくらいの信頼性を目指すのかをはっきりさせる コストや開発速度とのトレードオフをしっかりと議論する機 会になる SLO によってサービスのアーキテクチャ、チーム体制、モニ タリングの感度、障害対応などが変わってくる 「高い信頼性」という曖昧な目標から、チームメンバーが共 有する 1 つの数値目標へ エラーバジェットでトレードオフのバランスを取る (SRE 本 3 章) 過剰な要求からチームを守る あらかじめステークホルダーに SLO を共有し合意しておく 達成困難な信頼性目標を要求された時に参照できる 過剰に依存されるのを避ける ユーザに対してあらかじめ「期待できる信頼性」を示しておく 自サービスより高い信頼性が求められるサービスに不適切に 組み込まれるのを避ける
  7. 7. SLO の定義のしかた 1. SLI にするメトリクスを決める 2. 目標を決める 3. Profit!!! サービス、ユーザ、チームなどによるので「正しいやり方」は無い
  8. 8. SLI の選びかた ユーザ体験の満足度への近さ モニタリングの容易さ 安定して収集し分析できるメトリクス シンプルさ SLI はできるだけ少なくする さまざまなカテゴリ 可用性 (Availability) レイテンシー (Latency) 耐久性 (Durability) スループット (Throughput) まずは可用性から始めてみよう
  9. 9. SLI をモニターする ユーザートラフィックを直接計測する エラーの分類:リクエストが失敗した原因がユーザにあるか サービス側にあるかを正しく分類する 全てのリクエストを SLO でカバーすべきか考える (リクエス トの種類、サイズなど) トラフィックパターンに影響を受けやすい プローブ用のトラフィックを生成し計測する (ブラックボッ クスモニタリング) ユーザ環境に近い地点で計測できる 全てのコードパス、リクエストパスを検査するのは大変 ref. SRE 本 6 章 「分散システムのモニタリング」
  10. 10. SLO の定義の色々 例えば “99.9%の Uptime” と言っても... ある期間中の全てのリクエストとエラーを集計したエラー率 が 0.1%以下 ある期間を数分のウィンドウ単位に分割し、99.9%以上の ウィンドウでエラー率が x% 以下 ある期間を数分のウィンドウ単位に分割し、各ウィンドウの エラー率を平均したものが 0.1% 以下 Amazon S3, Google Cloud Storage などがこの形式 サービスの特性、ユーザの期待などに合わせて適切な定義を選ぶ
  11. 11. SLO が達成できなかったら? リリースをフリーズ 障害の多くは変更に付随して発生する 信頼性に関する改善の優先順位を上げる 目標そのものを見直す ref. SRE 本 3 章 3.4 エラーバジェットの活用
  12. 12. Public SLA へ 外部に公開する SLA はプロダクトデザインレベルの選択に なる SRE が技術的な判断や情報を提供しつつ、開発者、PM と議 論する
  13. 13. トイルの撲滅 ref. SRE本5章
  14. 14. トイルとは何か プロダクションサービスを動作させることに関係する作 業で、 手作業で繰り返し行われ、 自動化することが可能であり、 戦術的な価値を持たず、 作業量がサービスの成長に比例する
  15. 15. トイルの例 リリース作業 手作業でのテスト バックアップ作業 データベースのクリーンアップなど VM のセットアップ、追加、削除など アラート、障害対応 0 にするのは難しいものもある
  16. 16. トイルが多すぎると SRE のポジションのキャリア上の魅力が減る 採用が難しくなる SWE への転出 生産性の低下 手作業によるミスの発生 Google では 50%を目標にしている。 ref. SRE 本 5 章 5.4 トイルは常に悪なのか?
  17. 17. トイルの削減: オンコール対応の例 行っている作業を見直し、地道に自動化、改善していくしかない 週に数十以上のページ (アラート) が発生して多大なオンコー ル対応負荷が生じていた (SRE 本 11 章 11.3 バランスの取れ たオンコール) 対応 毎週プロダクションミーティングを開催 (SRE 本 31 章 31.1) その週におきた全てのアラートとその対応をレビュー 重大な障害にはポストモーテムを書き、その後ポストモーテ ムレビューを実施 (SRE 本 15 章) 場当たり的な修正に変えて 根本的な原因の修正。時間のかかるものはプロジェクト化 他チームのバグの積極的な修正依頼 プレイブック (手順書) の強化 不要なアラートの見直し 数ヶ月の取り組みでページ頻度が 1/5 程度に
  18. 18. ありがとうございました。 ご質問、ご感想は Twitter @SawadaTakeo までお気軽に!

×