アラートの指針

My Philosophy on Alerting - Google ドキュメント

http://robewaschuk.tumblr.com/post/48822960728/my-philosophy-on-alerting

My Philosophy On Alerting

元 Google "Site Reliability Engineer" で現 Tumblr？ の著者 Rob Ewaschuk による、サービスモニタリングとアラートに関する原則。

• アラートによる呼び出し（page）は以下の要件を具えていなければならない。
  • 緊急のものであること。
  • 重要なものであること。
  • 行動を起こすことが可能であること。
    • 知性が必要なものであること。機械的対応でよいのなら、アラートは無意味。
  • 現実に則したものであること。
• 現在サービスに起こっている・起ころうとしている問題をあらわしていなければいけない。
  • 起ころうとしている、というのは冗長性がなくなった、などの状況。
• ほとんどの問題は以下に分類できているはず（以下に分類できるような問題を扱うべき）:
  • 可用性と基本的な機能
  • レイテンシ
  • 整合性
  • サービスや機能に特有のもの
• 症状（symptom）ベースで問題を把握することで、一貫性を保ち、ロバストに把握することができる。
  • 原因ではなく症状に基いてアラートを投げ、原因はアラートの情報に含めるようにする。
    • ユーザの観点から監視する。データベースが落ちた、などの事情はユーザの知らないこと。
    • また、原因の監視ではユーザに本当には影響がないものを誤ってアラートしてしまうこともある。
• 今すぐでなくてもよいが、早めに対処されたいクリティカルではないアラートをどう扱うか。
  • バグトラッキングシステムに登録する。
  • デイリーレポートを送信するようにする、など。
  • 日々のワークフローに組み込むことが大事で、IRCやメールへの通知だと埋もれてしまう。
• 監視ルールを作ったら、それがどう対処されているか追跡すること。人間が確認して問題ない、としている割合が高かったら何かおかしいかもしれない。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

Webエンジニアが知っておきたいインフラの基本 ~インフラの設計から構成、監視、チューニングまで~