The_Site_Reliability_Workbook.ch08a.md

オンコール

• オンコール

  • 緊急対応とその準備
  • SREはよくオンコール対応要員として必要になる
  • SREは必要に応じてインシデントの診断・緩和・修正・エスカレーションをする
  • さらに加えて、緊急でないものについても見ている

• GoogleのSRE

  • オンコール対応
  • インシデント軽減、プロダクション上の問題の修正、運用の自動化
  • 全てのタスクが完全自動化できているわけではない
    • エスカレーションにはオンコール対応エンジニアが必要
  • システムの重要度や開発状況によっては不要
  • 経験上、ほとんどのSREチームはオンコールのシフトを担当している

• この章ではSRE本11章への質問やフィードバックについて扱い、以下のような状況への実践的なアドバイスを提供する

  • 「私たちはGoogleより全然小さくて、リソースもなく多地域展開していないから関係ない」
  • 「開発とDevOpsの両方がオンコール担当している。どうするのが一番良いのか。責務を分けるべきか。」
  • 「オンコール担当は一日に100回以上もオンコール中アラートを受け取っており、多くの通知が無視され、本当の問題が隠されてしまっている。まず何をすべきなのか。」
  • 「オンコール担当の入れ替わりが激しいです。チームの知識のギャップにどのように対処していますか。」
  • 「DevOpsチームをSREとして再編成したいです(*)。SREとDevOps、そして開発者のオンコールでは何が違うのでしょうか。」
    • （↑ DevOpsを実践していない組織の場合、これは危険信号。名前を変えるだけで構造的な問題は変わらない。）

• Googleは大きな企業で、成熟したSRE組織を持っている

  • しかしサイズや成熟度に関係なく、Googleが長年に渡り学んだ多くのことは、あらゆる企業に適用可能
  • オンコールはSRE専用のものではなく、多くの開発チームが直接オンコール担当している。

• この章ではGoogle内とGoogle以外の両方のオンコールについて説明

  • そして、オンコール中アラートの負荷の原因について調べ、負荷を最小限に抑えるための戦略を提案
  • 最後に、オンコールの柔軟性と原動力の2つの例を紹介
    • オンコール設定は理論のみでなく、人間のインセンティブを考慮しないといけない

SRE本の "Being On-Call" の章の要約

• Googleでのオンコールの目標は、重要なサービスに対してカバレッジを提供しつつ、オンコール担当エンジニアの健康を犠牲にしないこと
  • オンコールとプロジェクトの作業とのバランスが重要
  • SREはプロジェクトの作業に対して少なくとも50%費やす
    • つまり、チームは問題に対して戦略的に対処する必要があるプロジェクトに取り組む時間がある
    • チームの編成はプロジェクトの作業の時間を確保するのに十分でなければいけない
  • 1回のオンコール担当につき、最大2件のインシデントを対象としている
    • フォローアップのための時間を確保するため
    • オンコール中アラートの負荷が高すぎる場合は是正する必要あり
    • （インシデント数は「問題」の数として捉える。同一の問題に対して大量のアラートが発生しても1件）
    • （オンコール1回は12時間）
  • 心理的安全性は効果的なオンコールローテーションのために必要不可欠
    • オンコール担当は非常にストレスになる。
    • 一連の手順やエスカレーション方法が完全にサポートされることで楽になる
  • オンコールは通常、ある程度の時間外作業がある
    • その仕事は補償されるべき
    • Googleでは代休や給与での補填をしている
    • 補償制度はオンコールの一部のインセンティブとして提供している
      • お金のためにオンコール担当をたくさん引き受けることがないようにしている

Google内とGoogle以外のオンコール設定の実例

以下のセクションではGoogleとEvernoteでのオンコール設定の実例について説明

Google: 新しいチームの形成

Initial scenario

• 数年前、マウンテンビューのGoogleのSREのサラは新しいSREチームを立ち上げた

  • 3ヶ月以内にオンコールをしなければならなかった
    • Google SREチームの大部分は3〜9ヶ月以内の人がオンコールできる準備が整っているとは考えない
  • マウンテンビューの新しいSREチームは、Google Appsの3つのサービスをサポートすることになっていた
    • 以前はワシントン州カークランドのSREチームがサポートしていた
    • カークランドのチームにはペアになるロンドンのSREチームがあった
      • （GoogleのSREでは異なるタイムゾーンでペアになる）
      • ロンドンのチームはマウンテンビューとともに引き続きサポートを担当
      • プロダクト開発チームは分散した

• マウンテンビューのチームはすぐに7人を集めた

  • サラ - SREテックリード
  • マイク - 他のSREチーム経験者
  • 製品開発チームからSREに転向したエンジニア
  • 4人の「ヌーグラー」

• マウンテンビューのSREは比較的若いレベルのチーム

  • それにも関わらずサービスの質やプロジェクトの進捗速度を落とさずことなく担当できた
  • さらにサービスの改善も行った
    • マシンのコストを40%カット、カナリアリリースによる自動化
    • 99.98%の可用性目標（1Q辺り約26分以内のダウンタイム）での信頼性の高いサービス提供
  • このSREチームはどうやって達成したのか
    • 初心者向けプロジェクト、メンタリング、トレーニング

トレーニング ロードマップ

• SREチームの新メンバーは担当サービスについてあまり知らなかった

  • サラとマイクはGoogleのプロダクション環境やSREに詳しかった
  • 4人のヌーグラーの社内オリエンテーション後、サラとマイクは20個程度の重要エリアのチェックリストを作成した
    • プロダクションジョブの管理方法
    • デバッグ情報の理解
    • クラスタからトラフィックを排除する方法
    • まずいソフトウェアコードのロールバック方法
    • 望ましくないトラフィックのブロックやレートリミット方法
    • 追加キャパシティの引き上げ方法
    • モニタリングシステムの使用方法（アラートやダッシュボード）
    • アーキテクチャ、様々なコンポーネント、サービスの依存関係の説明
  • ヌーグラーはこれらの情報のいくつかを、自分自身で理解していった
    • 既存ドキュメント、コードラボ（ガイド付きのハンズオンコーディング チュートリアル）、初心者向けプロジェクト
    • ヌーグラーの初心者向けプロジェクトに関する特定のトピックについてチームメンバーが学んだ際、即興の情報共有セッションを他のメンバーへ行っていた
    • 一般的なデバッグや軽減処理に関するラボセッションを開催し、記憶と能力に自信をつけていった

• チェックリストに加えて、ディープダイブセッションを行った

  • モニタリングコンソールを見て、実行中ジョブを特定し、最近のオンコール中アラートのデバッグをやってみる
  • サラとマイクは、サービスに詳しくなるために、エンジニアは何年ものサービス固有知識を必要しないと説明した

• チームの立ち上げ中、様々な人に関わった

  • サラとマイクは他のSREチームや開発者に会い、彼らから学んだ
  • カークランドとロンドンのチームとはビデオ会議を行い、メールをやりとりし、IRCでチャットをしていた
  • さらにプロダクトチームの週次会議に参加し、日次のオンコール引き継ぎやエラーレポートを読み、既存のサービスドキュメントを閲覧していた
  • カークランドのSREが会議や質問に答えるために来てくれた
  • ロンドンのSREは災害シナリオをまとめ、GoogleのDRトレーニングの週に実行した
    • SRE本 第33章を参照

• "Wheel of Misfortune" 練習トレーニングを通じてオンコール演習をした

  • 最近のインシデントのロールプレイを行い、プロダクション上の問題のデバッグを練習
  • 疑似プロダクションの障害を解決する方法を提案してもらう
  • 全チームメンバーがセッションのリーダーとなるようにローテーションしながら続けた
  • 将来参照するときのために記録した

• オンコールエンジニアの責任に関するガイドラインのレビュー

  • 例:
    • 担当を開始する前に、前回の担当者からの引き継ぎ資料を読む
    • オンコールエンジニアは、まず第一にユーザーへの影響を最小限にする
      • その後、問題が完全に解決されていることを確認する
    • 担当終了時に、次の担当者に引き継ぎのメールを送る
  • ガイドラインはエスカレーションする場合についてと、大きなインシデントにおけるエラーレポートの書き方を明記した

• オンコールのプレイブック（定石集）を読み、更新した

  • 自動アラートへの対応方法に関する上位レベルの手順
  • アラートの重要度と影響、手順を説明
    • デバッグ方法や影響緩和方法、解決方法
  • SREではアラートが作成されるたびに、対応するプレイブック項目が作成される
    • これによって、ストレス、平均復旧時間（MTTR）、ヒューマンエラーのリスクを軽減する

• 2ヶ月後、サラとマイクはカークランドSREチームのオンコール担当をシャドーイングした

  • 3ヶ月後には、メインのオンコール担当となり、カークランドSREが予備担当となった
    • こうすることで、必要な場合にカークランドSREにエスカレーションすることが簡単にできた
  • 次に、ヌーグラーは現地のSREをシャドーイングし、ローテーションに参加した

• 優れたドキュメントと様々な戦略はチームの堅実な基盤形成と迅速な成長を助けた

• チームの集合的な知識に基づいていることで、心理的安全性がある

  • エスカレートしてもそのエンジニアは有能なエンジニアとみなされていた

後記

• チューリッヒの新しいチームが同サービスを担当することになった
  • ロンドンのSREチームの代わり
  • この2回目の移行はマウンテンビューのチームのときと基本的なアプローチは一緒
  • マウンテンビューチームのドキュメント等はチューリッヒチームの立ち上げに役立った
  • さらなる改良
    • 1人追加する場合にはもう少しライトなアプローチが必要
    • サービスのアーキテクチャのダイアグラムの作成、
    • 半分独立して行える基礎トレーニングチェックリスト、
      • ストレージ層、キャパシティ増加、HTTPルーティング方法の記述見直し

プレイブックのメンテナンス

• プレイブックの内容はすぐに古くなる
  • 毎日リリースがある環境では、毎日アップデートが必要かもしれない
  • 優れたドキュメントを書くのは難しい
  • どのようにメンテナンスしていくのか
• 項目を一般的なものにすれば変化は遅くなる、という説
  • 例: 訓練されたオンコールエンジニアが、読み上げ、「RPCエラーの増加」の項目が一つしかない場合 （?）
• ステップバイステップのプレイブックが人によるばらつきを小さくしMTTRを下げる、という説
• 議論になりやすいトピック
  • 何にも同意できない場合は、少なくともプレイブックに記述すべき構造化された詳細の最小を決める
    • プレイブックがこれらの詳細以外の情報を多く含んだ際に注意する
  • プレイブックの代わりになるべく自動化する

Evernote: Finding Our Feet in the Cloud

オンプレ環境からクラウドへの移行

• オンコールのプロセスについて再設計はしていなかったが、必要になった
  • 2016年12月以前はオンプレ環境上でモノリスなアプリが稼働していた
    • ネットワーク/サーバーはそれ専用の設計をしており、制約が多く、柔軟性に欠けていた
    • GCPが解決策となった
  • 本番環境全体をGCPに移行するという大きなハードル
    • 移行まで70日しかない
    • 数千のサーバー、3.5PBのデータ
    • 苦労の末移行できた
  • システム自体は移行できたが、それに対応できていない
    • 新しい環境での監視、アラート、問題への対応方法

オンコールポリシーとプロセスの調整

• クラウド化でスケールは可能になった

  • オンコールのポリシーとプロセスはそれに対応できていない
  • オンプレ時代
    • 規模的にほぼ全てのコンポーネントが冗長化されており安定
    • 上記前提でアラートも作られていて、VMやスイッチの異常でパケットロスが起こったりするケース
  • クラウド環境化ではもっと包括的な監視方法が必要

• 第一の原則からオンコール通知の見直し

• 明示的なSLOとしてそれらの原則を書き出し

• アラートで重要なことを明確化し、無駄なことを監視システムから除外できた

• 低レベルではなく高レベルの測定に注力する

  • 低レベルの例: MySQLのInnDBの行ロック待ち
  • 障害中での実際のユーザーの不満に対してフォーカスできた
  • 一時的な問題に対して時間をかけすぎることが少なくなった
    • 睡眠時間、効率性、仕事の満足度の向上

モニタリングとメトリクスの再構築

• オンコールローテション

  • スモールチームでプロダクションインフラや他のインフラを担当
  • 週次交代、24時間365日 円滑な引き継ぎ、朝のデイリースタンドアップでのインシデントレビュー
  • チームが小さく、責任範囲が広い
    • プロセスの負担を軽くする
    • アラート/トリアージ/修復/分析 のループをなるべく早く終わらせることにフォーカス
      • シンプルで効果的なSLAを維持することで、ノイズを少なく保つこと
      • 監視システムのイベントは以下の3のカテゴリに分類

• カテゴリ:

  • P1: 緊急
    • すぐに対応可能
    • オンコール担当へ通知
    • 障害の除去
    • SLOへの影響
  • P2: 次の営業日での対応
    • 基本的にはユーザーに直接影響していないか、とても限定的
    • チームへのメール、イベントストリームへの通知
  • P3: 情報のみ
    • ダッシュボードへの集約された情報、メール通知等
    • キャパシティ関連の情報を含む

• P1、P2イベントにはインシデントのチケットが添付

  • 明白なタスク
    • 重要度分類、対応方法、SLOへの影響、発生回数、詳細エラー情報へのリンク

• P1の場合、オンコール担当はユーザーへの影響度を評価する

  • 重大度は1〜3までのレベル
  • 重大度1 インシデント (Sev1)
    • 基準を維持し、一貫したエスカレーションの決定ができるようにする
    • エスカレーション後は、インシデントチームを作り、インシデント管理プロセスを開始する
      • インシデント責任者がオンコール通知され、書記とコミュニケーションリーダーを選び、コミュニケーションチャンネルを開く
      • インシデント解決後、自動レビューをし、結果を社内に広く共有する
  • 重大度2, 3 インシデント (Sev2, 3)
    • オンコール対応者はインシデントのライフサイクルを扱う
    • インシデントレビュー用の簡易エラー情報を含む

• プロセスの軽量化の利点

  • オンコール担当を明示的に解放可能できる
    • オンコール担当はすぐにフォローアップ活動ができる
    • インシデントレビューの完了後に、ツールやプロセスの差異を特定できる
  • 毎回のオンコールで、定期的な改善と柔軟性のサイクルを行い、急激な変化に対応できる
  • 目標は、すべてのオンコールを前のオンコールより改善すること

パーフォマンストラッキング

• 毎月、サービスレビューミーティングを実施
  • パフォーマンスデータの共有
  • 誰でも参加可能
  • 前月のレビューとディスカッション
  • オンコール対応の負荷も確認している
    • チームの健康
    • オンコール通知のバジェットを超えた場合の是正措置
  • 2つの目的
    • SLOの重要性を全社に広める
    • サービスとチームの健全性を維持する責任を持った、技術組織であり続けること

CREとの関わり

• Google CREチームとの連携
  • SLOという観点から目標を表現することで連携しやすくなる
  • CREと現実的で測定可能なSLOかどうか確認する
    • CREもオンコール通知を受ける
    • EvernoteはSLO影響が高いイベントへの対応
  • Google社員がいることでトリアージがしやすかった
    • クラウドで抽象化されている層での根本原因を突き止めるのは困難
    • ブラックボックス部分への推測がしやすかった
  • MTTRの削減
    • ユーザーが一番気にする重要な部分

自己永続的なサイクルの維持

• チームとしてどのようにビジネスを進めていくか考える時間ができた
  • マイクロサービス プラットフォームの改善
  • リリース可能基準の確立
    • オンコール再構築時に従った多くの基準が含まれている
    • 初めてオンコール対応をする際に有用
  • オンコール改善のサイクルを継続していく