アラート
監視の中でも特にうまくやる必要がある重要な部分。
アラートの種類
- 誰かをたたき起こすためのアラート
- 緊急な対応が求められ、システムがダウンしているもしくはしているもの
- 電話、テキストメッセージ、アラームなど様々な方法がある
- 参考情報としてのアラート
- すぐに対応する必要はないが来たことは確認すべきもの
- ジョブの失敗など
後者が前者と関連している場合はある。
より良いアラートの仕組みを作る方法
- アラートにメールを使うのをやめる
- 手順書を書く
- 固定の閾値を決めることだけが方法ではない
- アラートを削除し、チューニングする
- メンテナンス期間を使う
- まず、自動復旧を試す
大事だと思ったところをピックアップします。
アラートにメールを使うのをやめる
メールは誰かをたたき起こすものでもないし、そのために使おうと思うべきではない。
その代わりにそれぞれのアラートの使い道を考える。使い道は下記の3つ
- すぐに応答かアクションが必要なアラート -> SMS,PagerDutyなどのページャに送る
- 注意が必要だがすぐにアクションはいらないアラート -> 社内のチャットなど
- 履歴や診断のために保存しておくアラート -> ログファイル
手順書を書く
手順書はアラートが来た時に素早く自分たちが対処できるようにするもの。
複雑になったシステムは誰しも知っているわけではなく、知識を広める良い方法になる
良い手順書は特定のサービスについて以下のような質問に答えるように書かれていること
- これは何のサービスで何をするものか
- 誰が責任者か
- どんな依存性を持っているか
- インフラ構成はどのようなものか
- どんなメトリクスやログを送っていて、それらはどういう意味なのか
- どんなアラートが設定されていて、その理由は何なのか
書くアラートには対象サービスの手順書のリンクを入れる。
ただし、アラートに対応する手順がコピーアンドペーストできるくらいなら問題解決を自動化してアラートをなくす方向にするべきである。
アラートを削除し、チューニングする
アラートの見直しに関する項目です。
多すぎるアラートはストレスになり、だんだんと監視システムを信用しなくなっていき、最終的には無視されるようになってしまう。そうなってしまう前にアラートを減らすいくつかの方法は下記の3つ
- 初心に戻り、すべてのアラートは誰かがアクションする必要がある状態か
- 1か月間のアラート履歴を見て、どんなアラートがあり・どんなアクションをしたか・各アラートの影響はどうだったか・削除してしまえるアラートはないか・閾値を変更できるか・内容を正確にできないか
- アラートを完全に削除するために、どんな自動化の仕組みを作れるか
少しの取り組みで、アラートのノイズを大きく減らせる
オンコール
オンコールとは何か問題が起こったときに呼び出しに答えられるようにしている担当のこと。
この後の章にもでてくる設計をちゃんと行えば減りそうな事象なのでまずはそっちを詳しく書こうと思っているのと組織的に柔軟にできることが少ないので、詳しくは割愛します。
インシデント管理
ITILから来た概念で定義としては
「予定していないITサービスの中断、または、ITサービス品質の低下 - ITIL 2011」
インシデント管理のプロセスとしては以下のようなものがある
- インシデントの認識
- インシデントのロギング
- インシデントの分類
- インシデントの優先順位付け
- 初期診断
- 必要に応じたレベル2サポートへのエスカレーション
- インシデントの解決
- インシデントのクローズ
- インシデント発生中におけるユーザコミュニティとのコミュニケーション
ITILでは定義しているがこのプロセスを採用しつつもシンプルにすると…
- インシデントの認識(監視が問題を認識)
- インシデントの記録(インシデントに対して監視の仕組みが自動でチケット作成)
- インシデントの診断、分類、解決、クローズ（オンコール担当がトラブルシュート、問題を修正し、チケットんコメントや情報を添えて解決済みとする）
- 必要に応じて問題発生中にコミュニケーションをとる
- インシデント解決後、回復力を高めるために改善策を考える
振り返り
シンプルにしたプロセスの「5. インシデント解決後、回復力を高めるために改善策を考える」で
インシデントに関する議論の場を常に設けるべきである。
利害関係のあるすべての組織から人を集め、何が問題で、なぜ発生して、再発防止にはチームでどう対応していくか議論する。
そこでよくない習慣・文化として「誰かを非難するという文化」
ミスした人が罰せられたり問題を隠さざるを得ないような状況では内部に潜む法等の問題を改善することはできない