事象管理パート2：Zendeskによるサービスインシデントの管理方法

これは、Zendeskの事象管理の概要のパート2です。このガイドは以下のトピックで構成されています。

この記事では、パート2として、Zendeskチームが製品内のサービスインシデントに重大度に基づいてどのように対応するかを説明します。Zendeskは、インシデントの根本原因から影響を受けるカスタマーへの全体的な影響まで、インシデントを理解する包括的なアプローチをとり、適切なレベルの詳細情報を伝えます。

この記事では、次のセクションについて説明します。

事象の重大度
インシデント対応チームの構造
インシデントのコミュニケーションスケジュール
重大度の低い事象プロセス

事象の重大度

サービスインシデントの作成時に行われる重要な決定の1つに、インシデントの重大度の割り当てがあります。事象の重大度によって、問題に対処する方法と、影響を受けるカスタマーへの伝達方法が決まります。

Zendeskでは、サービスインシデントをインシデントの特性に基づいて5つの重大度にグループ化するシステムを使用しています。

Zendesk重大度評価システム

エスカレーションパスとチームは、重大度レベルに基づいてインシデントの調査、連絡、修正に取り組んでいます。これにより、各事象に適切なレベルの厳格さが与えられます。以下の図は、インシデントの重大度に基づいて、インシデントの解決中および解決後に発生する主なアクティビティを示しています。

重大度別プロセス

重大度の高いインシデントは厳格な分析と修復のプロセスを経て処理されますが、すべてのインシデントは、重大度に関係なく、リアルタイムの対応と調査のプロセスを経て処理されます。これにより、次のことが実現します。

事象が公開されている場合のZendeskステータスページの更新
根本原因の分析と事象の修正
Zendesk（社内）インシデントレポート

Zendeskサービス可用性インシデントの例

以下に、Zendeskによってインシデントの重大度がどのように設定され、Zendeskチームが社内でどのように対応するかの例を示します。

事象の検出と対応の例

この例では、次のワークフローが表示されます。

Zendeskネットワークオペレーションセンター（ZNOC）は、リクエストによってポッド17のサービスノードに到達できないことを示すシステムアラートを表示したときに問題を確認しました。Zendeskネットワークエンジニアリングチームは、アクセスに関する問題がカスタマーサービスに直接影響していることを確認し、複数のカスタマーのサポート、Guide、Talkサービスが期待どおりに機能していないことをすぐに認識しました。新しいZendeskサービスインシデントが作成されました。
この事象は、最初に作成された時点では2つのお客様に影響することがわかっていましたが、障害の性質上、多くのお客様が問題を経験し、Zendeskカスタマーサポートに問題を提起し始めました。インシデントは、エンジニアリングチームによって重大度1（緊急の対応が必要な優先度の高いインシデント）と指定されました。
インシデント対応オンコールチームは、すぐにページネーションされました。インシデントが作成されてから数分以内に、インシデントマネージャーは情報を収集し、追加のエンジニアリングリソースを組み立てて、サービスインシデントのトラブルシューティングと修正を行いました。

インシデント対応チームの構造

Zendeskには、すべてのインシデントがサービスインシデント管理プロセスを通じて確実に伝達され、保証されたZendeskのリーダーシップの適切なレベルにエスカレーションされるように、専任のグローバルインシデント対応チームがあります。

事象管理のロールと責任

このチーム体制により、Zendeskはテクニカルリソースを使用して事象を徹底的に分析し、Zendeskカスタマーサポートを通じてお客様にリアルタイムでコミュニケーションを取ることができます。

事象のコミュニケーションスケジュール

Zendeskは、インシデントがお客様に適切なタイミングで適切に伝達され、解決されるように努めています。インシデントの詳細の配信については、社内タイムラインを設けています。タイムラインは、インシデントの重大度とサービスインシデント管理のステージに基づきます。

ステージ	応答スケジュール
発表	と呼ばれる事象から15分以内
事象の更新	サービスが復旧するか、新しい情報が利用可能になるまでの30分ごと
イベント分析（重大度 0 および 1 のインシデント）	インシデント解決から48時間以内
根本原因の分析	インシデント解決から72時間以内
パブリックインシデントの遡及	事象解決から96時間以上以内

重大度が 0 ~ 2 のインシデントは、重大度の高いインシデントと見なされます。重大度の高いインシデントが発生した場合、グローバルオンコールインシデントレスポンスチームが24時間年中無休で対応します。チームは次のロールで構成されます。

事象対応チームのロール

グローバルなインシデント対応チームの所在地

オンコールチームがページネーションされると、インシデントが宣言されてから数分以内にインシデント診断が開始されます。SlackチャネルとZoomコールが作成され、応答チームのコミュニケーションがリアルタイムで可能になります。インシデント対応チームがインシデントの優先順位付けと範囲設定を行い、影響を受ける製品やサービスに基づいてオンコールエンジニアリングチームがページネーションされます。

<Zendesk Statusページに公開投稿は、インシデントが作成されてから15分以内に行われ、既知のインシデントについてカスタマーに常に通知されます。それ以降は、新しい情報が利用可能になると、解決されるまで30分ごとに更新されます。問題の内容や新たに特定された情報の量によっては、この頻度は必要に応じて短縮または延長されます。カスタマーは、Zendesk Statusページでアクティブなサービスインシデントを監視できます。このプロセスについては、このガイドのパート3で説明します。

グローバルなオンコールインシデント対応チームに加えて、Zendeskはリーダーシップ通知とエスカレーションのプロセスを確立しています。重大度の高いインシデントが特定の基準に当てはまる場合、次のレベルの対応である危機管理を有効にします。

Zendeskサービス可用性インシデントの例（続き）

たとえば、サービス可用性インシデントの使用を続けると、Zendeskのインシデント管理プロセスにおけるインシデント対応は次のように進行します。

サービス可用性インシデント対応タイムライン

例に示すように、Zendeskインシデントポータルでインシデントが作成されると、一連の自動アクションが実行されます。

事象対応オンコールチームが事象に対応するためにページネーションされました

インシデントSlackチャネルが自動的に作成され、インシデント対応オンコールチームが専用Slackチャネルに追加されました。

Zoomコールが自動的に開始され、すべての回答者が参加するようにSlackチャンネルに投稿されました

事象を文書化し、進捗状況をZendesk社内で共有するためのイベント概要ドキュメントが自動的に作成された

Zoomコールでは、インシデントマネージャーは最初の重大度を検証し、問題の範囲と影響を確認しました。

ポッド17の複数のコンテナノードはアクセスできず、サポート、Guide、Talk製品などの依存サービスでは使用できないことがすぐに判明しました。特に、あるノードタイプには、他のポッドで使用可能なレプリカがありませんでした。その結果、これらの製品は複数のカスタマーに対して応答しなくなります。

ZNOCは、適切なネットワークエンジニアリングチームをZoomコールに呼び出し、カスタマーへのサービスとAPIアクセスの復旧に関する当面の問題の解決方法の調査を開始しました。エッジエンジニアリングのSMEもコールに参加しました。5分以内に修正が特定され、展開されたので、影響を受けたノードは再びAPIコールとサービスにアクセスできるようになりました。

Zendeskカスタマーサポートがカスタマーレポートを追跡するために問題チケットを作成しました。このチケットはインシデントSlackチャンネルに追加され、新しいレポートが届いたときにすばやく追加できるようになりました。

調査が継続されている間に、インシデントエスカレーションマネージャは、インシデント作成から12分後にZendesk Statusページの最初のパブリックアップデートを作成し、公開しました。

Zendeskシステムステータスページの最初のサービス可用性インシデント投稿

チームがインシデントを調査している間に、届いたカスタマーレポートはインシデントに関連する主要な問題チケットにリンクされていました。これにより、インシデント対応チームは、影響を受けるすべてのお客様がパブリック通知を行う際に、更新を送信できるようになりました。

ネットワークエンジニアリングチームは、証明書の生成方法と使用方法の変更をインシデントの責任として判断し、影響を受けたお客様に対してサービスを復旧するために次の措置を講じました。

非アクティブな到達不能ノード

証明書が正しく参照された新しいサービスノードが作成されました

新しいサービスノードがサービスとAPIコールからアクセスできることを確認

インバウンドトラフィックを監視し、インバウンドリクエストが適切に処理されていることを確認

事象の進行とともに、さらに2つのパブリックアップデートが行われました。事象作成後1～14分、事象作成後63分。公開されたコミュニケーション履歴および公開されたインシデントの遡及情報は、インシデントのサービス通知ページにあります。

例に示すように、重大度の高いインシデントは厳格なプロセスを経て根本原因が特定され、製品エンジニアリングチームがインシデントの原因となった根本的な問題を修正するための修復項目が作成されます。この分析は、インシデントの遡及中に行われ、「解決後インシデント分析」セクションで詳しく説明します。

重大度の低い事象プロセス

重大度が低いサービスインシデント（レベル3~4）は、少数のお客様に影響を与え、それらのお客様がZendesk製品のビジネスクリティカルな機能を使用することを妨げるものではないため、重大度は低くなります。これらの事象は上記のガイドラインに従って対処されますが、パブリックチャネルには投稿されません。

重大度 3 のインシデントは、重大度 0 ~ 2 のインシデントとほぼ同じ方法で処理されます。ビジネスへの影響が軽減されるため、予想応答時間が長くなる。オンコールチームのページは表示されませんが、これらのインシデントは、サポートする製品エンジニアリングチームに関連付けられた特定の ZendeskインシデントSlackチャネルを通じて処理され、チームは重大度の高いインシデントと同じくらい迅速に対応する傾向があります。重大度3のインシデントのほとんどは、パブリックコミュニケーションチャネルを使用しません。代わりに、Zendeskカスタマーサポートチームは、特定のアクションが特定の顧客サブセットから必要な場合に、プロアクティブな通知を使用して顧客に連絡します。

重大度4の事象は、カスタマーのZendeskサービスの利用には直接影響しませんが、対処されない場合には影響する可能性があります。これらの事象は、潜在的な問題に対するプロアクティブな対応として作成されます。製品エンジニアリングチームは、重大度3のプロセスと同じ方法で作業します。

詳細

以上で、「Zendeskのインシデント管理の概要」のパート2「Zendeskによるサービスインシデントの管理方法」は終わりです。

さらに詳しく知りたい場合は、このガイドの次のパートに進んでください。パート3：パブリックZendeskサービスインシデントの監視。

翻訳に関する免責事項：この記事は、お客様の利便性のために自動翻訳ソフトウェアによって翻訳されたものです。Zendeskでは、翻訳の正確さを期すために相応の努力を払っておりますが、翻訳の正確性については保証いたしません。

翻訳された記事の内容の正確性に関して疑問が生じた場合は、正式版である英語の記事を参照してください。