lasciva blog

開発して得た知見やwebビジネスのストック

SRE Meetup Tokyo

インフラ meetup

SRE Meetup Tokyo @ Google JP オフィス 20170925

こちらに参加してきたまとめです。

connpass.com

発表内容

  1. モニタリング結果に騙されるな
  2. SLOのすすめ
  3. Managing Risk with Error Budgets

1.モニタリング結果に騙されるな

by @tsekine

元ネタ

The Many Ways Your Monitoring Is Lying To You

時系列ベースのモニタリング
  • モニタリングは2種類
    • white box monitoring
    • black box monitoring
  • サーバが自分で収集
  • モニタリングサーバはなるべく生の情報を取る
  • そのあとにデータを加工する
欠落したデータ
  • 全体のリクエストは変わらないが、1分あたりの平均は変わってしまう
  • 平均の変化は必ずしも実際にそいとはk切らない
粒度(モニタリング問題)
  • スケールすると、無駄にデータとってたら無駄に
どこで監視するか
  • clientとserver間でネットワークに障害があった場合
    • クライアントとサーバをモニタリングからは見れても無理な場合もある
    • black box monitoringも必要になる
複数のデータソース
  • 時系列を揃える
グラフ
  • y軸の設定に騙されない

2.SLOのすすめ

by @SawadaTakeo

Single repositry

  • SREの原則
    • 4章 サービスレベル目標
    • 5章 トイルの領域
SLOとは
  • あるサービスの信頼性についての数値目標
  • メリット
    • 信頼性を明確にする
      • コストや開発速度とのトレードオフをしっかりと議論する機会になる
        • サービスのアーキテクチャ、チーム体制、モニタリングの感度、障害対応などが変わってくる
        • 曖昧な目標から、チームメンバーが共有する一つの目標に
        • エラーバジェットでトレードオフのバランスを取る
      • 過剰な要求からチームを守る
        • 予めのステークホルダーにSLOを共有し合意しておく
        • 達成困難な信頼性目標を要求されたときに参照できる
      • 過剰に依存されるのを避ける
        • ユーザにたいして予め「期待できる信頼性」を示しておく
        • 自サービスより他界信頼性が求められるサービスに不適切に組み込まれるのを防ぐ
SLOの定義のしかた
  1. SLIにするメトリクスを決める
  2. 目標を決める
具体的な決め方
  • SLIの選び方
    • ユーザ体験の満足度への近さ
    • モニタリングの容易さ
      • 安定して収集し分析できるメトリクス
    • シンプルさ
      • SLIはできるだけ少なくする
    • 様々なカテゴリ
    • まずは可用性から始めてみよう
      • 一度に全部は大変
  • SLIをモニターする
    • ユーザトラフィックを直接計測する
      • エラーの分類：ユーザかサービス側なのかを正しく分類する
      • 全てのリクエストをSLOでカバーすべきかを考える（リクエストの種類、サイズなど）
      • トラフィックパターンに影響を受けやすい
    • プローブ用のトラフィックを生成し計測する（ブラックボックスモニタリング）
      • ユーザ環境に近い地点で計測できる
      • 全てのコードパス、リクエストパスを検査するのは大変
  • SLOの定義の色々
    • 99.9%のUptimeといっても
      • ある期間の全てのリクエストとエラー
      • ある期間を数分のウインドウに分割し、各ウインドウのエラー率を平均したもの
  • SLOを達成できなかったら？
    • リリースをフリーズ
      • 障害の多くは変更に付随して発生する
    • 信頼性に関する改善の優先順位を上げる
    • 目標そのものを見直す
  • Public SLAへ
    • 外部に公開するSLAはプロダクトデザインレベルの選択になる
    • SREが技術的な判断や情報を提供しつつ、開発者、PMと議論する
トイル

  • トイルとは

    • プロダクションサービスを動作させることに関係する作業で、
    • 手作業で行うつまらないルーチンてきなもの

  • トイルの例

    • リリース作業
    • 手作業のテスト
    • バックアップ作業
    • データベースのクリーンアップ
    • VMのセットアップ、追加、削除
    • アラート、障害対応
  • トイルが多すぎると
    • SREのポジションのキャリア上の魅力が減る
      • 採用が困難に
      • SWEへの転出
    • 生産性の低下
    • 手作業によるミスの発生
    • Googleは50％を目標に
  • トイルの削減：　オンコール対応の例
    • 行っている作業を見直し、地道に自動化、改善していくしかない
      • 週に数十以上アラートが発生して、多大なオンコール対応負荷が生じていた
      • 対応
        • 毎週プロダクションミーティングを開催
        • その週におきた全てのアラートをその対応をレビュー
        • 重大な障害にはポストモーテムを書き、その後ポストモーテムレビューを実施
        • 場当たり的な修正を変えて
          • 根本原因の修正
          • 他チームのバグの積極的な修正依頼
          • プレイバック（手順書）の強化
          • 不要なアラートの見直し
      • 数ヶ月の取り組みで1/5程度に

3.Managing Risk with Error Budgets

エラーバジェットによるリスク管理

by Paul Newson

One of the most important concepts in the SRE philosophy is the Error Budget. This talk will discuss how an error budget can help you delight your customers by managing risk in a principled way, striking the right balance between risk and velocity, while keeping your development and operations teams healthy.

開発の目的
  • 開発の目的
    • 新しい機能を提供する
  • SREの目的
    • 信頼性
  • 会社の目的
    • 新しい機能を確実に提供する
  • SLOを明確に定義する必要がある
    • 同じ目標
    • SLI:提供されるサービスレベルの特定の側面について注意深く定義された尺度
      • 種類
      • SLI集約
        • 時間
        • スペース（サーバ、ゾーン、地域、グローバル）
        • リクエストタイプ（GET,POST）
        • 顧客
        • 平均値または分布
    • SLO:SLIで測定されるサービスレベルの目標値または目標値範囲
    • SLOの例
      • 99.99%の可用性
      • 過去90日
      • スライディングウインドウ
      • 可用性の定義
      • ex. 可用性は、99.9％の成功率、正しいGETリクエスト、５分の期間、地域別
    • SLA: SLOの達成に関する規定を含むユーザとの契約
エラーバジェット
  • 定義：error budget = 1 - uptime
  • エラーバジェット管理
    • この機能をデプロイすべきか
    • 変更をどのようなスピードでデプロイすべきか
    • 冗長性をもっと高めるべきか
    • テストを追加実装すべきか
    • 機能を開発すべきか、信頼性を高めるべきか