事象管理パート2：Zendeskのサービス事象の管理方法

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

パート2形式のこの記事では、Zendeskの分析やサービスインシデントについて、Zendeskチームはサービスインシデントに深刻度に基づいて対応することで、Zendeskは、根本的な原因から影響を受けるお客様への総合的な影響まで含め、インシデントを理解するために包括的なアプローチをとり、適切な詳細情報を提供します。

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

事象の重大度
インシデント対応チームの構成
事象のコミュニケーションタイムライン
深刻度「低」のインシデントプロセス

事象の重大度

サービスインシデントが作成される際の重要な決定事項の1つは、インシデントの重大度を割り当てることです。インシデントの重大度によって、Zendeskのどのチームが問題に対処する方法か、また対象となるお客様にどのように伝えるかが決まります。

Zendeskでは、サービスインシデントを事象の特徴に基づいて5つの深刻度レベルにグループ化するシステムを使用しています。

Zendesk深刻度評価システム

緊急度に基づいて、さまざまなエスカレーションパスとチームがインシデントの調査、コミュニケーション、修正を行います。これにより、各事象に適切なレベルの厳格さが適用されます。以下の図は、インシデントの深刻度に基づいたインシデントの発生中またはクリア後に発生する主なアクティビティを示しています。

深刻度別プロセス

深刻度の高いインシデントは厳格な分析と改善活動を経ますが、すべてのインシデントは、深刻度レベルに関係なく、リアルタイムの対応と調査のプロセスを経ます。この場合、次の情報が生成されます。

事象がパブリックになった場合のZendesk Statusページの更新
根本原因の分析と事象の改善
Zendesk（内部）インシデントレポート

Zendeskサービスアベイラビリティに関するインシデントの例

以下に、Zendeskによる事象の深刻度の設定と、Zendeskチームによる社内対応の例を示します。

インシデントの発見と対応の例

この例では、次のワークフローを実行します。

Zendeskネットワークオペレーションセンター（ZNOC）が特定した問題システムアラートにより、ポッド17内のサービスノードにリクエストが到達できないことが示されました。Zendeskネットワークエンジニアリングチームは、アクセスの問題がカスタマーサービスに直接影響していることを確認し、複数のカスタマーのSupport、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内の複数のコンテナノードがアクセスできないものであり、Support、Guide、およびTalk製品を含む依存サービスでは使用できないことが迅速に判断されました。ある特定のノードタイプに、他のポッド内に利用可能なレプリカがありませんでした。これにより、これらの製品が最終的に複数のカスタマーに対して応答しなくなります。

ZNOCは、適切なネットワークエンジニアリングチームにZoomコールを転送し、顧客のサービスとAPIアクセスを復旧させるという当面の問題の解決方法の調査を開始しました。エッジエンジニアリングのSMEもページにアクセスし、通話に参加しました。5分以内に修正が特定され、デプロイされたため、影響したノードがAPIコールとサービスに再びアクセスできるようになりました。

Zendeskカスタマーサポートは、カスタマーからの報告を追跡するために問題チケットを作成しました。このチケットは事象Slackチャンネルに追加されたもので、新しいレポートが届いたときにすぐに追加できるようにしています。

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

Zendeskシステムステータスページでの最初のサービス提供に関するインシデント投稿

チームがインシデントを調査している間に、カスタマーから寄せられたレポートは、インシデントに関連付けられた主要な問題チケットにリンクされていました。これにより、インシデント対応チームは、カスタマーが公開通知を行ったときに、影響を受けるすべてのカスタマーに更新情報を送信することができました。

ネットワークエンジニアリングチームは、証明書の生成方法と使用方法の変更が事象の原因であると判断し、影響を受けた顧客のサービスを復旧させるために次のアクションを実行しました。

非アクティブ化されたアクセス可能なノード

適切に参照された証明書を持つ新しいサービスノードを作成した

新しいサービスノードがサービスおよびAPIコールを通じてアクセス可能であることを確認した

インバウンドリクエストが適切に処理されるようになった、インバウンドトラフィックの監視

インシデントの進展として、さらに2つのパブリック更新が行われました。1つは事象の作成から14分後、もう1つは事象の作成から63分後です。公開されたやりとりの履歴と、公開された事象のさかのぼって情報が、「サービス通知」ページに表示されます。事象です。

この例に示すように、深刻度の高いインシデントは厳格なプロセスを経て根本的な原因を特定し、事象の原因となった根本的な問題を修正するために製品エンジニアリングチームに対して改善項目を作成します。この分析は、インシデントの遡及期間に行われたもので、「解決済みに設定するための事象の分析」セクションに進みます。

深刻度「低」のインシデントプロセス

深刻度の低いサービスインシデント（レベル3から4）は、少数の顧客に影響するため、重要性が低下し、Zendesk製品のビジネスクリティカルな機能の使用を妨げるものではないため。これらのインシデントは上記のガイドラインに従って対処されますが、パブリックチャネルには投稿されません。

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

深刻度4のインシデントは、お客様によるZendeskサービスの利用に直接影響しませんが、対処されない場合、影響する可能性があります。これらのインシデントは、潜在的な問題に対するプロアクティブな応答として作成されます。製品エンジニアリングチームは、深刻度3のプロセスと同じように取り組みます。

詳細

これで、Zendeskの事象管理の概要のパート2「Zendeskによるサービス事象の管理方法」を完了します。

詳細については、このガイドの次のパートに進んでください。パート3：公開Zendeskサービス事象を監視する」でツリーベースの最大権限を有効にします。

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

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