アラートとインシデント対応

DevOpsでは、モニタリングによって何が起きているかを把握できます。しかし、見るだけでは十分ではありません。何か問題が起きたときに、それを知る必要があります。

アラートとは、特定の条件が満たされたときに発生する通知で、潜在的な問題を示します。システムの警報ベルのようなものだと考えてください。

効果的なアラートは、受動的なモニタリングを能動的な問題解決へと変えます。次の目的に不可欠です。

• 早期検出: ユーザーに影響が及ぶ前に問題を発見します。
• 迅速な解決: 適切なチームにすぐ通知します。
• 障害の防止: 小さな問題が深刻化する前に対処します。

アラートが発生すると、多くの場合インシデントを示しています。インシデントとは、サービスの計画外の中断、またはサービス品質の低下です。

たとえば、サーバーのクラッシュ、データベースの応答停止、アプリケーションのエラー率急増などがあります。

アラートは、さまざまなメトリクスやログに基づいて設定します。一般的なトリガーは次のとおりです。

• しきい値: CPU使用率が5分間90%を超える。
• エラー率: HTTP 500エラーがリクエストの1%を超える。
• 可用性: サービスが応答を返さない。
• ログパターン: 特定のエラーメッセージがログに現れる。

すべてのアラートの緊急度が同じとは限りません。対応の優先順位を付けるため、重大度で分類します。

• Critical: サービスが停止している、または大幅に性能が低下している状態です。直ちに対応する必要があります。
• Warning: 問題が発生しつつあり、早急な注意が必要な状態です。
• Information: 緊急性のないイベントで、認識しておくことだけが目的です。

アラートが発生したら、適切な担当者に届ける必要があります。一般的な通知チャネルには次のようなものがあります。

• メール: 緊急度の低い警告や情報アラートに使用します。
• チャット（Slackなど）: チーム内での情報共有や、共同での原因調査に適しています。
• SMS／電話: 直ちに対応が必要な重大なアラートに使用します。PagerDutyなどのオンコールツール経由で送ることが多いです。

インシデント対応とは、インシデントに対処して解決するための体系的なプロセスです。一般的な流れは次のとおりです。

1. 検出: アラートが発生します。
2. トリアージ: 重大度と影響を評価します。
3. 診断: 根本原因を特定します。
4. 解決: 問題を修正します。
5. 復旧: サービスを完全な機能に戻します。
6. ポストモーテム: インシデントから学びます。

ランブックとは、一般的なインシデントを解決する手順を詳しくまとめたガイドです。次の点で重要です。

• 一貫性: インシデントに一貫した方法で対応できます。
• 迅速性: 診断と解決にかかる時間を短縮できます。
• 知識の移転: 新しいチームメンバーが効果的に対応できるようになります。

インシデントの解決後には、インシデント後レビュー（またはポストモーテム）を実施することが重要です。これは責任追及を目的とせず、次の点に焦点を当てた分析です。

• 何が起きたのか。
• なぜ起きたのか。
• 何をすれば防げたのか。
• 再発を防ぐために、どのような対策を取れるのか。

目的は責任を追及することではなく、継続的に改善することです。

インシデント対応におけるランブックの主な目的を最もよく説明しているものは、次のうちどれですか。

特定の条件によって発生し、システムの警報として機能するアラートについて学びました。また、さまざまな重大度レベルと通知チャネルについても確認しました。

インシデント対応の流れを理解し、ランブックを活用することが、問題に効率的に対処する鍵となります。最後に、インシデント後レビューによって継続的な学習とシステムの改善を進められます。