プロアクティブなアラートを設定し、インシデント応答のためのチームやツール、プロセスを調整

アラートという用語は多くの場合、否定的な意味を有しています: 多くの開発者は、アラートをエラーや失敗、継続的な問題と関連付けていますが、アラートに事前に対応する開発者は、効果的なアラートによりいつチェックしたらよいか分かるため、ダッシュボードを1日中眺めている必要はないことを知っています。

アラートを入念に設定しておけば、システムの健全性を確認できるので、顧客に被害が及ぶ前にパフォーマンス問題に対処できます。さらに、フォーカスされたアラートポリシーを使用すると、アプリケーションのパフォーマンスや環境に被害を与える恐れのある劣化を特定できます。プロアクティブなアラートによりユーザーが報告するインシデントが減少し、チームが問題解決に費やす時間が減り、より多くの時間を製品への重要な変更のディプロイに費やすことができるようになります。

適切なアラートを定義した後、適切なインシデントのオーケストレーションによりチームやツール、プロセスを調整して、ソフトウェアのインシデントや障害に備えます。チームに予測可能なフレームワークとプロセスを提供して、次のことを行うことが目標です:

  • 通信と取り組みの効率を最大化する。

  • ビジネス全体への影響を最低限に抑える。

前提条件

このチュートリアルでは、次のことを行っていると仮定しています:

1. ポリシーの定義

SLOに基づき、必要なアラートポリシーを定義します。

サービスレベル目標(SLO)は、サービスのパフォーマンスを測定する、合意された手段です。SLOでは、指定された量的指標の目標値が規定されます。この目標値はサービスレベルインジケーター(SLI)と呼ばれます。サービスレベルインジケーターの例としては、平均応答時間やレスポンスタイムパーセンタイル、アプリケーションの可用性があります。SLOでは、次のようなSLIのターゲット値を明確にします:

  • 平均応答時間は200ミリ秒未満である必要があります。

  • 要求の95%は、250ミリ秒以内に完了させる必要があります。

  • サービスの可用性は、99.99%である必要があります。

このSLOを論理的にグループ化し、サービスが期待を満たしているかどうかについての全体的なbooleanインジケーターを提供できます(例:「リクエストの95%が250ミリ秒以内に完了し、かつ可用性が99.99%」)。これは、アラートで有用です。

このSLIを主要パフォーマンスインジケーター(KPI)として使用することで、チームと組織はサービスを測定し、顧客の期待を満たしていることを確認できます。サービスで必要な定量的なパフォーマンスメトリックスを分析することで、どのような種類のアラートをそれぞれについて設定すべきかを特定できます。たとえば、ウェブのトランザクションタイムが0.5ミリ秒を超える、またはエラー率が0.20%を超える場合に通知するアラートを設定できます。

ただし、SLOを全てアラートにする必要はありません。堅固なアラート戦略では、SLOをシンプルなセットにして、アクションに結びつくアラートにします。New Relicは多くの場合、最も成熟した顧客は一般に設定しているアラート減らし、アラートで顧客体験でいつ本当に問題が生じているかを示す中心となる一連のメトリックスに重点を置いていることを把握しています。その結果、New Relicの顧客は多くの場合、アラート戦略の一環としてApdexを使用し、アラートをユーザー満足度の低下の兆候に関連付けることがよくあります。

アラート戦略を設計する際は、次の質問を念頭に置いてください:「顧客に影響がない場合、アラートを行うことに意味があるか?」

質問とKPIソリューションの例

アラートを設定する分野の簡単なフレームワークについては、次の質問と、提案されたメトリックスおよびKPIを使用します:

質問 メトリックスとKPI

ビジネスに利用できますか?

New Relic BrowserNew Relic APM は、サイト可用性に対するアラートに利用できます

基礎となるインフラストラクチャはどのようなものですか?

主要ハードウェア、ネットワーク、ストレージコンポーネントに対するKPIを設定します。

アプリケーションの正常性はどうですか?

JVMのパフォーマンス、キューイング、キャッシング、同様の依存関係に対するメトリックスを追跡します。

アプリケーション全体の品質はどうですか?

Apdexのスコアを使用してアプリケーション品質に迅速にアクセスします。

お客様はどうですか?

実際のエンドユーザーメトリックス(BrowserAPM)、合成ユーザー(Synthetics)、Apdexスコアを検討します。

全体のビジネスはどうですか?

アプリケーション内のキートランザクションに注目し、アプリケーションとビジネスパフォーマンス間の相関関係を説明するために結果を期待するビジネスの成果と結びつけます。

2. 固有のアラートの設定

パフォーマンス、正確性、スループット、可用性、および依存関係に固有のアラートの設定

New Relicを使用して、インストゥルメントされたアプリケーションやエンドユーザー体験、インフラストラクチャ、データベースなどで、アラートを設定できます。New Relicは、サイトの可用性が低下、またはエラー発生率がSLOで定義の許容水準を上回った場合、アラートを行います。警告閾値を設定し、深刻度が危険に近づいているがまだ通知を発信する段階にない問題を監視します。

いつアラートでチームに通知を行うかの閾値の設定は困難な場合があります。閾値が厳しすぎるとアラート慣れが生じ、緩すぎると顧客の満足度が低下します。

ベースラインアラートヲ使用して、過去のパフォーマンスに基づきアラートの閾値を動的に設定できます。ベースラインを使用して、アラートを適切な閾値に微調整します。たとえば、APMのアラートでは、ウェブのトランザクションタイムが、割り当てられた長さの時間について過去の実績から乖離すると、インシデント対応チームにアラートを通知できます。

devops向けのプロアクティブなベースラインアラート
alerts.newrelic.com > (アラートポリシーを選択) > (アラート条件を選択) > Define thresholds

これと同じ種類のアラートをBrowserで設定し、パフォーマンスを次善に最適化できます。次の例では、スループットの警告と違反の両方を設定しています:

プロアクティブなベースラインアラート - Browserの閾値
alerts.newrelic.com > (アラートポリシーを選択) > (アラート条件を選択) > Define thresholds

使用期間の短いアーキテクチャで実行する小さな独立したサービスを開発する際には、環境はより複雑なものとなります。外れ値の可視化は、発生する可能性の高いパフォーマンス問題の理解で重要なツールとなります。外れ値がある場合に自動的に警告を行うようアラートを設定してください。これにより、ホストやロードバランサー、アプリの動作の異常を示すことができます。

たとえば、ロードバランサーは、5つの異なるサーバー間のウェブトラフィックを分割します。あるサーバーのトラフィックが他のサーバーより大幅に増加または減少したら通知を送信するよう、NRQLクエリに基づきアラートを設定できます。

チャートの例は次のとおりです:

outlier-alert.png

NRQLクエリのサンプルは次のとおりです:

SELECT average(cpuPercent) FROM SystemSample WHERE apmApplicationNames = 'MY-APP-NAME' FACET hostname

静的なベースラインアラートと外れ値のアラートを設定しました。これにより、エコシステムを包括的に認識できます。

アラートの最適化の詳細については、New Relic Alertsドキュメントを参照してください。

3. グループの特定

アラートやブロードキャスト方法の設定、最初の対応者のチームダッシュボードへの割り当てを行うには、グループを特定します。

適切なブロードキャスト方法を使用しないでアラートを送信すると、脆弱性は改善されません。アラート戦略には、アプリケーションまたはアーキテクチャで問題が発生した場合に適切なチームに通知されるように通知チャネルを含める必要があります。New Relicには多くの通知インテグレーションがありますが、最初は単純なものを使用し、後で複雑なものを追加するようにしてください

アラートは最初にグループチャットチャネルに(たとえばSlackPagerDutyを使用して)送信することをお勧めします。アラートをリアルタイムで数週間にわたり評価して、どのアラートが重要または問題のある問題を示しているかを理解します。こうしたアラートは、誰かを目覚めさせる根拠となる種類のものです。

推奨事項:各チームダッシュボードについて、次のことを確認します:

  • 監視するアプリケーションと機能の健全性について責任を負う所有者がいる。

  • アラート条件の注視と解決に誰が責任を有するかについて、曖昧な点がない。

本ポリシーは、規模や構成、文化に応じて、組織間で異なります。

たとえば、一部のチームでは、事実上の機能やアプリケーションの所有権に基づき、ダッシュボードとアラートの割り当てを行いたいと考えています。他のチームは、オンコールローテーション(多くの場合呼び出し任務と呼ばれます)を採用することを望んでいます。オンコールローテーションでは、指定されたチームメンバーがすべての第一線のインシデント対応を扱い、事前に決められたインシデント閾値に基づき解決するか責任を委譲します。

4. 閾値の決定

アラート条件のインシデント閾値の決定

各アプリケーションについて:

  1. インシデントと正式に見なされるものの閾値を特定します。

  2. 閾値基準の各セットが状況に依存していることを確認します。

  3. インシデント評価と既知の改善手順をランブックに記入します。

  4. アラートポリシーの条件と閾値を定義する際、ランブックへのリンクを含めます。

一例として、一部のアラート条件は、トラフィックの少ない期間は無視できますが、ピーク時間中は積極的な改善が必要です。

5. 通知チャネルの設定

アラートに監査可能な通知チャネルがあることを確認

重要なインシデントが発生している間は、コミュニケーションが容易に利用可能で高度に可視化されたチャンネルで行われるようにしてください。インシデントコミュニケーション専用のグループチャットルームは、通常優れた選択肢です。これにより、すべてのステークホルダーが会話に参加したり、会話を観察したりできます。また、事後分析のための通知、重要な決定、および行動の順序が記録されます。

New Relic Alertsで使用可能な通知チャネルを使用します。たとえば、Slackで通知チャネルを設定するには:

  1. 組織がNew RelicのSlackとのインテグレーション要件を完了していることを確認します。

  2. Slackアプリで、アプリの左上にあるドロップダウンを選択し、Customize Slack(Slackをカスタマイズ)を選択します。

  3. Configure apps(アプリを設定)をクリックします。

  4. アプリのインテグレーションのリストから、New Relicを選択します。

  5. New Relic Alertsの説明を拡張し、ステップに従いNew Relicから通知を設定します。

6. 解決を自動化

トリアージと解決ステップを自動化

シンプルまたは反復可能なインシデント対応タスクの自動化は、効率を高め、インシデントの影響を最小化します。適切な自動化を導入することで、障害のあるアプリケーションコンポーネントを、通知が発行された後ではなくアラートの閾値に達した時点ですぐに無効化または分離できます。

たとえば、デジタルメディア企業のアプリケーションを管理するチームは、システムにエラーがある場合にウェブサイトからコメント機能を削除できることを望んでいます。この場合、次のことを行えます:

  1. エンドポイントを、記事でのコメント投稿に関連付けられたUIコンポーネントを有効化または無効化する機能フラグを切り替えるフロントエンドウェブアプリケーションに追加する。

  2. コメント作成サービスで保持されたエラー率で設定された閾値で、アラートポリシーを作成する。

  3. POSTリクエストを送信するwebhook通知チャネルを、このエンドポイントおよび標準のチーム通知チャネルに割り当てる。

このシナリオでは、コメント作成システムのエラーによりwebhookが起動し、ウェブサイトからコメント作成UIを削除します。ユーザーは以後も、コメント作成サービスが生成するエラーを目にすることなく、サイトの中心的機能を使用できます。アプリケーションは、安定しているが劣化した状態を維持し、チームはユーザーがサイトにアクセスしないようにするプレッシャーなしに復旧に注力できます。

Webhookを使用して、ZendeskのようなREST APIのあるチケット作成システムで問題と実行項目を作成することもできます。New Relic Alertsを使用して、webhook通知チャネルを作成し、webhookペイロードを必要に応じてカスタマイズします。

New Relicはまた、一般的なチケット作成システムのためのインテグレーションも提供します。このインテグレーションを使用し、New Relic APMからチケットを提出できます。

7. レビューを作成

事後検証プロセスを作成

インシデントが解決された後、主要な利害関係者と参加者はインシデントの正確かつ完全なドキュメンテーションを入手しなければなりません。

過去のドキュメンテーションに際しては、少なくとも以下の内容を記載することをお勧めします:

  • 根本原因の分析

  • 修正手順とその結果の年表と要約、およびそれらが成功したかどうか

  • ユーザー体験と財務上の損失の観点から見たビジネスへの影響の測定結果(可能な場合)

  • 再発を防ぐためのシステムまたは機能の改善に関する推奨事項

  • プロセスとコミュニケーションの改善に関する推奨事項

事後検証レポートを、共有ドライブフォルダやwikiなどの、見やすく検索可能なリポジトリに保存します。文化的に、このプロセスでは、罰を与えたり叱責するのではなく、建設的な学習と改善に重点を置くことが不可欠です。

事後検証レポートの例

事後検証レポートの簡単な例は次のとおりです:

事後検証 コメント

日付

2018年03月01日

要旨

午後1時45分頃から午後2時30分頃まで、ユーザーはカートに品目を追加できなかった。これにより、インシデント期間中にチェックアウトができなかった。

根本原因

製品の詳細ページでCSSルールが変更され、これにより「カートに追加」ボタンが実質的に無効になったと判断した。

時系列

  • 1:50PM: 5分間で10件未満の正常なチェックアウトによりアラートが起動。Aliceに割り当て。

  • 1:55PM: eコマースチームのダッシュボードを見直した後、Aliceは、Bobによるディプロイの直後に閾値を超えたと判断。AliceはBobにインシデントを通知。

  • 2:00PM: AliceとBobはトラブルシューティングを開始。本番環境での問題再現に成功。

  • 2:20PM: Bobは、製品の詳細ページでCSSルールが変更したことで「カートに追加」ボタンが無効になったと判断。Bobはホットフィックスをディプロイ。

  • 2:30PM: 機能が回復し、インシデントが解決。

影響

インシデントの間、チェックアウトが完了しなかった。この期間の木曜日の通常の売上は30,000ドル。

推奨事項

当面、New Relic Syntheticsの実装を協議中。チェックアウトプロセスでSyntheticによるチェックがあれば、この問題は直ちに検出されたであろう。フロントエンドのウェブアプリで、より徹底的なユニットテストも実行すべきである。

8. 微調整プロセス

アラートと閾値の微調整

New Relicを使用してアプリケーションとインフラストラクチャのパフォーマンスを最適化し、パフォーマンスの向上に合わせてNew Relic Alertsのポリシー条件を厳しくしていくことができます。

新しいコードや、一定期間にわたってパフォーマンスに悪影響を与える可能性のある変更を展開する際には、これらの短期的な変更ができるように閾値の条件を緩和してください。一例として、当社では、事前に確立したベースラインと閾値を使用して、年次イベントや主要な発表など影響の大きな期間中に効率を高めることを推奨しています。微調整により、ニーズに柔軟に対応して効率を高め、通知チャネルを拡大できます。

以前お知らせしたように、当社では、通知を最初に確立する際にまずグループチャットを行うことを推奨しています。統合するその他のツールを特定した後、通知チャネルを設定しそのまま続けます。xMattersやPagerDutyのようなツールは一般的なインテグレーションを提供しますが、Webhookなどの簡単な方法も忘れないでください。アラートのスキームを継続的に改善することが目標です。

必ずアラートをチェックし、定期的にアラートが行われており、顧客満足のメトリックスと現在も関連していることを確認してください。New Relicプラットフォームを使用して、最も一般的なポリシー条件や違反について、アラートやインシデント中心のダッシュボードを作成します。

事前のベースラインアラート - ダッシュボード
insights.newrelic.com > All dashboards > (選択したダッシュボード)の順に移動します

New Relicクエリ言語InsightsクエリAPIを使用して、ダッシュボードを作成します。詳細な説明については、アラートデータのInsightsへの送信をご覧ください。

上記のダッシュボードは、次のNRQLクエリを使用して作成されました。アラートダッシュボードについて、必要に応じて再度作成することが推奨されます。

  • 条件別のインシデント:

    SELECT count(*) FROM ALERT_NAME WHERE current_state = 'open' FACET condition_name SINCE 1 week ago
    
  • ポリシー別のインシデント:

    SELECT count(*) FROM ALERT_NAME where current_state = 'open' FACET policy_name SINCE 60 MINUTES AGO TIMESERIES
  • 期間中のアラートの傾向:

    SELECT count(*) FROM ALERT_NAME WHERE current_state IS NOT NULL FACET policy_name SINCE 1 week ago TIMESERIES
  • インシデントの詳細:

    SELECT timestamp, incident_id, policy_name, condition_name, details, severity FROM ALERT_NAME SINCE 1 week ago LIMIT 40

このデータを可視化することで、使用しているアラートと閾値を絞り込むために他のユーザーと共有できるリソースが得られます。

専門家のヒント

アプリケーションやインフラストラクチャメトリックスのインストゥルメントや測定に加え、成熟したDevOps組織は多くの場合、インシデント対応プロセスの効率を測定し最適化します。たとえば、webhookを使用してアラートイベントをNew Relic Insightsに送信できます。これにより、New Relic Alertsデータでチームのダッシュボードを補完できます。

その他のヘルプ

さらに支援が必要な場合は、これらのサポートと学習リソースを確認してください: