この文書は、O’Reilly Japan - 入門 監視　の3章のアラート、オンコール、インシデント管理の個人的なまとめです。

監視の定義と、アラート の位置づけ

  • 監視の定義

    監視とは、あるシステムやそのシステムのコンポーネントの振る舞いや出力WO観察しチェックし続ける行為である。

  • アラートの位置づけ

    アラート は監視という行為を達成する為の1つの方法。

アラート をうまく送ることが難しい理由

  • システムのメトリクスは、変化しやすく、適切な送付の基準を作るのが難しい。
    データポイントによる閾値設定では、誤報が増える。 移動平均による閾値設定では、情報が丸められて重要な情報を見逃すことがある。

  • アラート は人間に送られることが多い。
    人間の注意力には限界があり、監視システムによって注意力が削られていくことになる。

3.1 どうしたらアラート をよくできるか

コンテキストによるアラートの違い

1. 誰かを叩き起こすためのアラート
例) 全サーバーがダウンした。
電話、テキストメッセージ、アラームなどの方法で送付される。

2. 参考情報(FYI)としてのアラート
すぐに対応する必要はないが、来たことを誰かか確認すべきもの。
参考情報(FYI)としてのアラート は単なるメッセージ。
ログ、社内のチャットルームのメッセージ、チケットの自動生成などで通知される。

3.1.1 アラート にメールを使うのをやめよう

アラートの通知方法は以下の3つに集約される。 * すぐに応答かアクションが必要なアラート

  • 注意が必要だがすぐにアクションは必要ないアラート

  • 履歴や診断のために保存しておくアラート

3.1.2 手順書を書こう

runbook=手順書

よい手順書は、以下のような質問に答えるように書かれている

  • これは何のサービスで、何をするものか。

  • 誰が責任者か

  • どんな依存性を持っているか

  • インフラの後世はどのようなものか

  • どんなメトリクスやログを送っていて、それらはどういう意味なのか。

  • どんなアラートが設定されていて、その理由は何なのか。

各アラートには、対象サービスの手順書へのリンクを入れる。

  • 注意点
    手順書がコピーアンドペーストできるくらいにシンプルなコマンドなら修復の手順を自動化して、アラートを完全に削除すべき。

3.1.3 固定の閾値を決めることだけが方法ではない

アラート の基準に固定の敷居値を用いるとうまくいかないケースがある。
例) ディスク使用率 10%以下でアラートを設定。
ディスク使用率が11%から80%に急激に増加したケースを見逃す。

Graphite を使うと、移動平均、信頼区間、標準偏差等の統計情報を適用できる。

3.1.4 アラート を削除し、チューニングしよう

  • アラート の量を減らす方法

    1. 初心にかえる。すべてのアラートが誰かがアクションする必要がある状態か確認する。

    2. 1ヶ月間のアラート の履歴を確認する。各アラートの影響、削除してしまえる閾値の見直しが必要なものがないか確認する。

    3. アラート を完全に削除するために、どんな自動化の仕組みが作れるか検討する。

3.1.5 メンテナンス期間を使う

ほとんどの監視ツールにメンテナンス期間の設定の機能がある。
計画停止時などアラート 送る必要はないので、この機能を有効に使う。

3.1.6 まずは自動復旧を試そう

アラートに対する代表的なアクションが、既知でかつ用意されたドキュメントの手順に沿って対応するだけなら、自動復旧auto-healing を検討する。
標準化された復旧手順をコードとして実装して、人間に通知する代わりに監視システムにそれを実行させる。

3.2 オンコール

直接電話がかかってくる、監視当番のこと。

誤報、わかりにくいアラート、場当たり的な対応に悩まされる。

3.2.1 誤報を修正する

前日送られたすべてのアラートの一覧を作る。
その一覧にひととおり目を通しながら、各アラートは、どのように改善できるか、あるいか削除してしまえないかを検討する。
オンコール担当が毎回これをやれば、最初に始めた時よりも、ずっと正常な状態になっているはず。

3.2.2 無用の場当たり的対応を減らす

監視は何も修復してくれない。
システムの改善に時間を使う必要がある。システム改善に手間をかける習慣を身に着ける。

  • 2つの効果的な戦略
  1. 場当たり的対応をしていない時間は、システムの回復力や安定性に対して取り組むをオンコール担当の役割にする。
  2. 前週のオンコールの際に収集した情報を元に、次の週のスプリント計画やチーム会議の際にシステムの回復性や安定性について取り上げる計画を立てる。

3.2.3 上手にオンコールローテーションを組む

  • １週ごとに、4人でローテーションする。
  • カレンダーの週に合わせるのではなく、出勤日にオンコールのローテーションを始めるとオンコールの引き継ぎができる。
  • 引き継ぎで、注意を要する進行中の出来事や、その週に気づいたパターンなどについて議論する。
  • オンコール担当が相談できるエスカレーションパスは設けるべきだが、あくまでオンコール担当が対応する。

オンコール担当について

  • オンコールのバックアップ担当について
    ほとんどの場合、必要ない、仮に4人のチームだと、月に2回担当が回ってくることになる。

  • オンコールローテーションの組み方
    インシデントの発生回数で、決める。
    多くのインシデントを処理しなければならない場合ほど、間隔をあけるべき。

  • ソフトウェアエンジニアもオンコールローテションに入れるべき
    ソフトウェアエンジニアリングにおける丸投げを避ける。
    ソフトウェアエンジニアと、運用エンジニアを一緒にすることで、お互いの共感が強まる。

ツールにより、オンコールの仕組みを補強する

ツールは、エスカレーションパスやスケジュールの構築や運用をやりやすくする。

オンコールに対する補償

  1. オンコールシフト直後に、有給休暇を1日取らせる。
  2. オンコールシフトごとに手当を支払う。

3.3 インシデント管理

インシデントは ITIL で定義されている

ITILのプロセスを採用しつつも、やりすぎにならないようにシンプルにする

  1. インシデントの認識 (監視が問題を認識)
  2. インシデントの記録 (インシデントに対して監視の仕組みが自動でチケットを作成)
  3. インシデントの診断、分類、解決、クローズ（オンコール担当がトラブルシュートし、問題を修正し、チケットにコメントや情報を添えて解決済みとする）
  4. 必要に応じて問題発生中にコミュニケーションを取る
  5. インシデント解決後、回復力を高めるための改善策を考える

インシデント対応の社内標準を作る価値

  • インシデントのログが残り、一貫性を持って追跡調査できる。
  • ユーザー、経営者、顧客が透明性を持って情報を受け取り、何が起こっているのか知れる。
  • チームがアプリケーションとインフラにどんなパターンで問題があるか、どこで問題が起きやすいかを知れる。

サービス停止を伴うインシデント

明確に定義された役割が重要になる。

  • スクライブ (書記)
  • 現場指揮館 (決断する人)
  • コミュニケーション調整役
  • SME (subject matter expert)

役割のアンチパターン

チームや会社での上下関係に、インシデント対応の際も従ってしまう。
チームマネージャが現場指揮官にはならず、コミュニケーション調整役として動くとうまくいく。

3.4 振り返り

  • インシデントが発生した場合、インシデントに関する議論の場を設けるべき。
  • サービス停止などの重大なインシデントに対して、振り返りが重要。
  • 避難する文化があると、ふりかえりの効果が薄れる。本当の問題を改善できない。

感想

全体的に刺さるところが多かったです。思ったことを記載します。

Runbook

  • 当たり前のことが書かれていますが、上記の記載がなくて、トラブルが発生することが多々あり、刺さりました。
  • Contextとしてチーム外から見た場合の視点が抜けていくように思います。

オンコールシフト

ここでのオンコールは、夜間監視も含まれるように感じました。
日中での監視のみを担当するのはアプリケーション開発チーム、夜間監視はSREチームに別れるケースもあるかと思います。

監視担当のローテーションから日々の改善までの流れ

監視担当のエンジニアならば、無意識にやっていることかと思いますが、明文化 による標準化は重要に思いました。
引き継ぎをする等は、個人的に漠然とやるになっており、業務でももう少し文章化を進めたいです。
誤報を修正、自動復旧による監視自体の削除についても、

役割のアンチパターン

思いあたるところがありすぎます。

ツールにより、オンコールの仕組みを補強する

ツール自体が、ベストプラクティスに乗っ取っているため、導入はしなくても考え方を知ることは有用に思いました。

以上です。

コメント

カテゴリー

最近の投稿