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

  • パート1:Zendeskのサービス問題がサービス事象になるしくみ
  • パート2:Zendeskのサービス事象の管理方法
  • パート3:公開Zendeskサービス事象を監視する
  • パート4:解決後のインシデントの分析とレポート(この記事)

この記事(パート4)では、インシデント対応チームが根本原因の分析とサービスインシデントの改善を含む回送調査を行い、オーナーシップのあるエンジニアリングチームに改善項目を割り当てる方法を学びます。

これらのアクティビティを実行することで、Zendeskカスタマーサポートは事象の詳細と次のステップを影響を受けるお客様と共有できます。

この記事では、次のトピックについて説明します。

  • サービス事象をさかのぼって実施する
  • 改善策の割り当て
  • サービス事象を終了する

サービス事象をさかのぼって実施する

Zendeskは、インシデントに関わるすべてのチームメンバーを対象に、インシデントの原因、顧客へのインシデントの影響、問題の緩和または解決のためにとるべき対応などを検討し、文書化します。  チームは、特定した根本原因と、インシデントの再発を防ぐためのフォローアップアクションを確認します。これは、サービス事象の内部さかのぼって呼ばれます。事象のさかのぼって公開されるのは、重大度の高い事象の場合のみです。 

すべてのZendeskチームの透明性と統合を保証するために、Zendeskの社内回帰カレンダーを使用して、社内の回送会議に参加して、サービスインシデントと根本原因に関する詳細情報を取得できるようにしています。  インシデントの結果はすべてのエンジニアリングチームと共有され、重要なインシデントの結果はハイライトされ、Zendeskの毎週のエンジニアリングミーティングで確認されます。

サービス事象のさかのぼっては、次の4つの主要なアクティビティを行います。

  1. 事象ドキュメントに記載された事象の詳細を確認し、事象への参加者をアンカーし、方位させる
  2. 事象ドキュメントに記載された根本原因分析の結果を確認し、検証する
  3. Zendeskのエンジニアリングチームがサービスインシデントにつながる根本原因に完全に対処するために必要な改善作業を特定し、分類します。すべての改善事項は、さかのぼって参加者が同意して同意するものとします。
  4. 明確かつ適切なSLAを定義した適切なエンジニアリングチームに改善作業を割り当てる

深刻度の高いインシデント分析

深刻度の高いインシデントが解決されると、インシデントマネージャーは以下の内容のミーティングをスケジュールします。

  • インシデント対応に参加したすべてのチームメンバー
  • インシデントによって製品またはサービスが影響を受けたチームのエンジニア
  • 次のような所有権または投資利害関係を持つチーム。
    • Zendeskカスタマーサポート
    • プロダクトチーム
    • 影響を受ける製品、サービス、サポート分野の所有者であるリーダー 

事象解決から72時間以内に事象をさかのぼったミーティングを開催するためにあらゆる努力が行われています。ミーティングのタイミングは、根本原因の複雑さや地域全体のチームメンバーの空き状況に依存することを理解したうえで、行われます。 

インシデントをさかのぼってスケジュールした後、エンジニアリングオーナーは根本原因を分析し、以下のカテゴリに基づいて事象ドキュメントを作成します。

  • 事象の概要
  • 顧客への影響
  • 技術的な説明
  • 原因とサービス情報
  • 事象の詳細とタイミング
  • 改善策

事象ドキュメントは、インシデントを過去にさかのぼって説明し、インシデントの原因となった問題を完全に解決するために特定された改善作業を記録します。 

さらに、根本原因分析という、重大度0~3のインシデントに対して行われた分析フェーズがあります。この分析により、エンジニアリングチームは事象を理解し、文書化することで、問題を完全に修正するために必要な作業を定義することができます。この情報は事象ドキュメントに記載されています。


Zendeskインシデント原因分析プロセス

深刻度の低いインシデントの分析

深刻度「低」のインシデントは、深刻度「高」のインシデントよりも簡易な根本原因とレポートフェーズを経由します。深刻度の低いインシデントについては、(製品エンジニアリングのオーナーから要求されない限り)正式なインシデントを回帰する会議は終了しませんが、製品エンジニアリングのオーナーによって事象ドキュメントが作成されます。  

根本原因が特定され、分類されて、エンジニアリングチームと共有され、改善項目はSLAとともに製品エンジニアリングチームの未解決のチケットに追加されます。  深刻度の高いインシデントと同様に、Zendeskは深刻度の低いインシデントを徹底的に調査した結果、エンジニアリングプロセスの学習と改善を求めています。

深刻度3のインシデントは顧客への影響が小さいため、問題のステータスと特定の改善策は、ZendeskカスタマーサポートにZendeskチケット経由で問い合わせてきた影響を受ける顧客と共有されます。 

深刻度4のインシデントは、定義上、カスタマーに直接的な影響を与えません。インシデント分析の結果はカスタマーに伝えられませんが、前述のプロセスと手順に従って、根本的な原因が特定され、改善方法が社内で提示されます。

改善策の割り当て

改善項目を確実に完了させるために、製品エンジニアリングチームは、検証された改善項目をさかのぼって確認し、以下のアクションを実行します。

  1. 改善策を「予防的」または「一般的」に分類:
  • 予防的項目:インシデントの再発を積極的に防止する項目 です。
  • 一般的な 問題:これ自体を予防するだけでなく、事象の状況の中心となる部分を解決します。
  • 改善に優先順位を付けて、応答SLAを設定します。この演習では、以下のアクティビティを行います。
  • 改善項目の作業を担当するエンジニアリングチームを特定する
  • 改善項目と特定された根本原因をリンクさせて解決する
  • 担当エンジニアリングチームの未解決のチケットに改善項目を追加する
  • 改善項目をエンジニアリングSLAレポートに追加し、SLAの達成を追跡する

以下は、製品エンジニアリングチームが作業の中で改善に優先順位を付け、計画するタイミングを判断するために使用するグラフです。

Zendesk修復項目の優先度SLA

さかのぼって、Zendeskカスタマーサポートチームが特定した事象、根本原因、および特定の改善策などについて、お客様向けの説明を作成します。これは 事象に関連付けられたヘルプセンターの記事。

サービス提供に関する事象の例 - 引き続き

この事象について、事象の回帰分析がどのように行われたかについて説明します。

インシデントが発生してから4営業日後に、インシデント対応チームとエンジニアが集まり、インシデントのレビューを行い、根本原因を共同で調査し、改善項目を作成または更新しました。すべての改善策は、会議出席者の総意により同意されます。 

インシデントに関わる人々は、過去にさかのぼってインシデントの役割を果たしています。

更新者_参加者.png

この会議で確認および議論された詳細は、以下のとおりです。

領域

例

提供終了までのスケジュール

  • 20:02 UTC - 更新された証明書でホストサービスにデプロイメントされた新しいコンテナバージョン
  • 20:08 UTC - コンテナ接続警告の表示開始
  • 20:37 UTC - サービスが新しいコンテナに接続できないことの最初の証拠:これにより、サービスの遅延/中断が発生します。
  • 20:57 UTC - Zendesk社内サービスがリクエストの処理を停止し、ポッド17でホストされているSupport、GuideおよびTalkアプリケーションでタイムアウトエラーを発生させる
  • 21:02 UTC - クラスタオートスケーラが、アクセスできないサービス用に新しいコンテナの作成を開始します
  • 21:07 UTC - 既存のサービス構成と連携するサービスコンテナのフルプロビジョニングが完了した
  • 21:49 UTC - アクセスできないコンテナのクリーンアップが完了
  • 22:07 UTC - 事象が完全に解決された

根本原因

  • セキュリティ証明書サービスが変更された後、スクリプトでエンコードされた変更を取得するためにコンテナがすべて再構築されたわけではありません。  再展開されなかったコンテナは、正しいセキュリティ証明書プロバイダを参照しておらず、他のZendeskサービスおよびコンテナから信頼されていない。

影響要因

  • 新しいコンテナを作成するときに、新しいセキュリティ証明書プロバイダを適切に参照するために、デプロイメントスクリプトを更新しなかった
  • 新しいコンテナの展開が速すぎて、障害が発生し始めた後に調整できないほど頻繁に発生したため
  • 自動ロールバック機能なし

改善策

  • 新しいコンテナが構築され、展開されるときに、セキュリティ証明書コンプライアンスがどのように評価されるかを変更します。
  • 新しいインスタンスを立ち上げる前に、証明書を確認するためのより堅牢な別の認証方法を追加する
  • 水平方向のインフラストラクチャの導入戦略の文書化
  • アラート発生時のデプロイメントの自動ロールバックを有効にする
  • プラットフォームエンジニアリングがインフラストラクチャコンポーネントをより頻繁に再構築する方法を調査する
  • 重要なインフラストラクチャの分散化と障害対応の強化を行う

エンジニアリングチームが具体的なアクションを生成するための徹底的な分析を行うために、チームメンバー全員からインシデントを精査し、改善のタスクを策定するための情報を提供していただきました。インシデント対応チームによってすべての質問または問題が解決されると、インシデントのさかのぼっての対応が完了したと見なされます。

公開事象の回覧を担当するZendeskカスタマーサポートのリードは、社内の回覧ミーティングの終了時に、何か質問はないか、公開ドキュメントを作成するためにチームから追加の情報が必要かどうかを尋ねられました。これ以上 質問 はなく、 ヘルプセンターを更新してください。

Service Availability VMインシデントのパブリック遡及情報

このインシデントをさかのぼってZendeskの製品とサービスを改善してきた重要な成果として、以下の3つが挙げられます。

  • インシデントの根本原因が特定され、今後の開発ですべてのZendesk製品チームによって検討されます
  • 改善点が特定され、SLAを導入したエンジニアリングチームに割り当てられた
  • このパブリックバックログは、Zendeskカスタマーサポートからヘルプセンターに公開され、チケットを送信した該当カスタマーに送信されたものです。 

サービス事象を終了する

ベストプラクティスとして、Zendeskはお客様とやりとりしているオープンチケットをすべてクローズし、事象に関するすべての情報が適切に文書化され周知されるようにします。

完了したすべてのサービスインシデントは、Zendesk全体で共有される毎週のサービスインシデントのダイジェストレポートにまとめられます。事象の説明、顧客への影響、重要な改善策は、このレポートに含まれています。また、Zendeskのエグゼクティブチームと共有される隔週のオペレーションレビューレポートにも含まれています。

さかのぼって、情報がヘルプセンターに公開され、オープンチケットがさかのぼって情報を更新した時点で、サービス事象の分析およびレポートフェーズは完了したと見なされます。Zendeskカスタマーサポートはこれらのチケットをサービス事象にリンクし、「終了」ステータスになります。 

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

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

Powered by Zendesk