DevOps 測定: 障害の予兆通知

障害の予兆通知とは、障害が発生してシステムから通知を受ける前に、あるいはアプリケーションやサービスの障害について顧客から通知を受ける前に、モニタリング対象の値が既知の障害しきい値に近づいたときに通知を行うことです。このアプローチを使用すると、問題が深刻化したり、ユーザーに影響を与える前に問題を特定し、解決できる可能性があります。2014 DevOps Research and Assessment(DORA)(PDF)の調査で、積極的なモニタリングがソフトウェア配信パフォーマンスの重要な予測因子であることが明らかとなりました。DORA の調査によると、予兆通知を使用しているチームは、問題を迅速に診断して解決できます。一方、内部モニタリングでなく、主にネットワーク オペレーション センター(NOC)などの運用チーム外の情報源から(さらに悪い場合は顧客から)障害が報告される場合、パフォーマンスが低下します。

障害の予兆通知を実装する方法

アラートルールを使用する。特定のアラートルールを使用して障害通知を生成します。アラートルールでは、アラートが生成される条件とそのアラートの通知チャネルを定義します。

しきい値を使用する。アラートルールでは、モニタリングする指標に問題発生の目安となるしきい値を定める必要があります。モニタリングしきい値により、アラートルールがトリガーされ、指標レベルがしきい値を超えた時点で通知が生成されます。

しきい値を慎重に選択する。しきい値が実際に問題を予測したときにのみアラートが生成されるようにしきい値を選択します。任意の値を選択すべきではありません。通常、ユーザーに影響を与える値のレベルを特定し、その値を超える前に一定の割合でアラート通知をトリガーする必要があります。

たとえば、ページの平均応答時間がしきい値の 20% 以内で、20% になるとユーザーがイライラしてサポートに電話し始めることがわかっている場合、その値でアラート通知がトリガーされるように選択できます。

事後分析を行う。インシデントの後に事後分析を行う場合、どのインジケーターであればインシデントを予測できたかを見極め、その後はそうしたインジケーターをモニタリングします。

通知戦略を立てる。通知によりアクションが求められない場合や、毎回同じアクションが求められる場合は、レスポンスを自動化する必要があります。また、イベントに関する通知の量も考慮する必要があります。イベント中に大量の通知が発せられると、有用ではなく邪魔になる可能性があります。アラームがあまりに多いと、ユーザーはアラームに反応しなくなり、アラームへの対応に遅れたり、アラームを見落としたりすることがあります(「アラート疲れ」と称される問題)。通知を定期的に確認し、対処できない通知を削除します。

障害通知を改善する方法

システムで障害が発生した場合に、Network Operations Center(NOC)やお客様に影響が及ぶ前に、早期に主要チームに通知されるようアラートを設定します。戦術は次のとおりです。

  • ロギングとモニタリング システムのアラートを適切なレベルに構成する。
  • 問題を解決できるスタッフやチームに通知されるようアラートを設定する。
  • しきい値による警告のベスト プラクティスに基づいて、システムの状態を積極的にモニタリングする。
  • 変更の警告率に基づいて、システムの状態を積極的にモニタリングする。
  • 関連するアラートのみが発生し、アラートが多すぎないようにする。どのアラートが無関係であるかをよく調べる。無関係なアラートを無効にし、関連が確認できたモニタリング アラートだけを再びオンにする。アラートをすべて無効にすることはおすすめできません。

障害通知の判定方法

プロアクティブ モニタリングは容易に実現できます。把握すべき要素は次のとおりです。

  1. ロギング システムおよびモニタリング システムからの障害アラートを取得および使用する程度。
  2. しきい値による警告を使用して、システムの正常性を事前にモニタリングする程度。
  3. 変更率の警告を使用して、システムの健全性を予防的にモニタリングする程度。

システムのさまざまな要素を把握するには、2 つ以上の方法で指標をモニタリングする必要があります。たとえば、指標のしきい値を定めて、所定の期間に指標がその値を上回るまたは下回るとアラートがトリガーされるようにします。また、指標の変化率についてもしきい値を定めて、指標値の変化率が予想よりも高い、または低い場合にアラートがトリガーされるようにします。

次のステップ