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

  • パート1:Zendeskサービスの問題がサービスインシデントになるしくみ
  • パート2:Zendeskによるサービスインシデントの管理方法
  • パート3:パブリックZendeskサービスインシデントの監視
  • パート4:解決後の事象分析とレポーティング(この記事)

この記事では、パート4のインシデント対応チームが、サービスインシデントの根本原因分析と修復を含む振り返りを行い、オーナーシップを持つエンジニアリングチームに修復項目を割り当てる方法 について説明します 。

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

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

  • サービスインシデントの振り返り
  • 是正アイテムを割り当てる
  • サービスインシデントを終了する

サービスインシデントの振り返り

Zendeskは、インシデントに関係するすべてのチームメンバーに対して反省訓練を実施し、インシデントの原因、カスタマーに対するインシデントの影響、およびそれを軽減または解決するために講じたアクションを検討し、文書化します。  チームは、特定された根本原因と、事象の再発を防ぐフォローアップアクションを確認します。これは、「サービスインシデントの社内振り返り」と呼ばれます。インシデントの振り返りは、重大度の高いインシデントについてのみ公開で共有されます。 

すべてのZendeskチームに透明性と透明性を確保するために、Zendeskの社内向け振り返りカレンダーが用意されています。このカレンダーを使用して、社内の振り返りミーティングに参加し、サービスインシデントと根本原因に関する詳細な情報を得ることができます。  インシデントの結果はすべてのエンジニアリングチームと共有され、重要なインシデントの結果は、Zendeskの毎週のエンジニアリングミーティングでハイライトされ、レビューされます。

サービスインシデントの振り返りには、主に次の4つのアクティビティがあります。

  1. 事象ドキュメントに含まれる事象の詳細を確認して、関係者を事象に固定し、方向付ける
  2. 事象ドキュメントに含まれる根本原因分析の所見を確認して検証する
  3. Zendeskエンジニアリングチームがサービスインシデントにつながる根本原因に完全に対処するために必要な修復作業を特定し、分類します。すべての是正項目について、過去の参加者の合意が得られた場合
  4. 明確で適切なSLAを定義して、適切なエンジニアリングチームに修正作業を割り当てます。

重大度の高いインシデント分析

重大度の高いインシデントが解決されると、インシデントマネージャは次のような振り返りミーティングをスケジュールします。

  • インシデント対応に参加したすべてのチームメンバー
  • 事象の影響を受けた製品またはサービスのチームのエンジニア
  • 次のようなオーナーシップまたは投資を受けているチーム
    • Zendeskカスタマーサポート
    • 製品チーム
    • 影響を受ける製品、サービス、Supportの領域を所有しているリーダー 

インシデントの再検討会議は、インシデントが解決してから72時間以内に開催するように努めています。この会議は、根本的な原因の複雑さや地域ごとのチームメンバーの対応状況によって開催時期が異なることを理解したうえで開催されます 。

インシデントの振り返りをスケジュールした後、エンジニアリングオーナーは根本原因分析を文書化し、次のカテゴリに基づいてインシデントドキュメントを作成します。

  • 事象の概要
  • カスタマーへの影響
  • 技術説明
  • 根本原因とサービス情報
  • 事象の詳細とタイミング
  • 是正

インシデント ドキュメントは、インシデントの遡及をガイドし、インシデントの原因となった根本的な問題を完全に解決するために特定された修復作業を記録します 。

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


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

重大度の低いインシデント分析

重大度の低いインシデントは、重大度の高いインシデントよりも根本原因と報告のフェーズが低くなります。重大度の低いインシデントについては、正式なインシデント遡及ミーティングは完了しません(ただし、プロダクトエンジニアリングオーナーからリクエストがない限り)。ただし、インシデントドキュメントはプロダクトエンジニアリングオーナーによって作成されます 。 

根本原因を特定し、分類してエンジニアリングチームと共有し、SLAに従って製品エンジニアリングチームのバックログに修正項目を追加します。  重大度の高いインシデントと同様に、Zendeskは重大度の低いインシデントを徹底的に調査した結果、エンジニアリングプロセスの学習と改善に努めています。

重大度3の事象はカスタマーに軽微な影響を与えるため、問題のステータスと特定された修復方法は、Zendeskチケットを通じてZendeskカスタマーサポート経由で事象について連絡した影響を受けるカスタマーと共有されます。 

定義上、重大度4の事象は、カスタマーに直接影響しません。事象発生後の分析はカスタマーには通知されませんが、根本的な原因を特定し、前述のプロセスと手順を使用して社内で修復を行います。

是正アイテムを割り当てる

是正項目を確実に完了させるために、製品エンジニアリングチームは、過去を振り返る中で検証された是正項目を確認し、次のアクションを実行します。

  1. 是正を予防または一般に分類:
     
  • 予防アイテムとは、インシデントの再発を積極的に防止するもの
  • 一般的な項目は、それ自体が予防策であるだけでなく、事象の状況の核心部分を解決する
  • 是正に優先順位を付けて応答SLAを設定します。この演習では、次のアクティビティを実行します。
  • 修正項目に取り組むエンジニアリングチームを特定する
  • 是正項目を、その項目に対応する特定された根本原因にリンクさせます。
  • 担当エンジニアリングチームの作業バックログに是正項目を追加する
  • 是正項目をエンジニアリングSLAレポートに追加してSLA達成を追跡します

以下のグラフは、製品エンジニアリングチームが、作業の進捗に合わせて修正の優先順位付けと計画を行うときに使用します。

 

Zendesk是正項目優先度SLA

この振り返りに出席したZendeskカスタマーサポートチームは、インシデント、根本原因、および特定された修復について、カスタマー向けの説明を作成します。これはヘルプセンターの「サービス通知」セクションに投稿されます。

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

このインシデントについて、インシデントの振り返りはどのように行われましたか。

インシデントが発生してから4営業日後、インシデント対応チームとエンジニアが集まり、インシデントのレビュー、根本原因に関する協力、修正項目の作成または更新を行いました。すべての是正項目は、会議出席者の合意によって合意されます。

インシデントの関係者それぞれが、インシデントの振り返りに役割を果たしました。

Retrospective_Attendees.png

この会議で検討および議論された内容は次のとおりです。

領域 例
提供終了までのスケジュール
  • 20:02 UTC - 更新された証明書でサービスをホストするためにデプロイされた新しいコンテナバージョン
  • 20:08 UTC - コンテナの接続に関する警告が表示され始める
  • 20:37 UTC - サービスが新しいコンテナに接続できず、サービスの遅延/中断を引き起こす最初の兆候
  • 20:57 UTC - Zendesk社内サービスがリクエストの処理を停止し、ポッド17でホストされているサポート、Guide、Talkアプリケーションでタイムアウト エラーが発生する
  • 21:02 UTC - Cluster autoscalerは、到達できないサービスのための新しいコンテナの作成を開始します
  • 21:07 UTC - 既存のサービス構成で動作するサービスコンテナの完全なプロビジョニングが完了している
  • 21:49 UTC - 到達不能コンテナのクリーンアップが完了しました
  • 22:07 UTC - 事象は完全に解決されました
根本原因
  • セキュリティ証明書サービスが変更された後、スクリプトにエンコードされた変更を反映するために、コンテナがすべて再構築されるわけではありません。  再デプロイされなかったコンテナは、正しいセキュリティ証明書プロバイダを参照しておらず、他のZendeskサービスとコンテナから信頼されていません
影響要因
  • 新しいコンテナを作成するときに、新しいセキュリティ証明書プロバイダを適切に参照するようにデプロイメントスクリプトを更新しなかった
  • 新しいコンテナを迅速かつ広範に導入しすぎたため、障害発生後に調整できなかった
  • 自動ロールバック機能なし
是正
  • 新しいコンテナが構築および展開されたときにセキュリティ証明書のコンプライアンスを評価する方法を変更する
  • 新しいインスタンスを起動する前に、別のより堅牢な証明書確認方法を追加する
  • 水平方向に拡張されたインフラストラクチャの導入戦略を文書化する
  • アラートが発生した場合にデプロイメントの自動ロールバックを有効にする
  • プラットフォームエンジニアリングでインフラストラクチャコンポーネントをより頻繁に再構築する方法を調査する
  • 重要なインフラストラクチャの分散化とフォールトトレランスの強化

エンジニアリングチームのために具体的なアクションを生成するための徹底的な分析を行うために、すべてのチームメンバーがインシデントをカウントし、修正タスクを開発するための情報を提供しました。インシデント対応チームによってすべての質問または問題が処理されると、インシデントの振り返りは完了したと見なされます。

一般公開のインシデントの振り返りを担当するZendeskカスタマーサポートリードは、社内向け振り返りミーティングの最後に、公開ドキュメントを作成するために質問があるか、チームからの追加情報が必要かどうかを尋ねられました。彼女はそれ以上質問することはなく、ヘルプセンターの「 サービス通知」セクションに以下の過去の情報を追加しました。

Service Availability VMインシデントのパブリックRetrospective Information

今回の事象の振り返りでは、Zendeskの製品とサービスを向上させた3つの重要な成果がありました。

  • 事象の根本原因が特定され、今後の開発ですべてのZendesk製品チームで検討される
  • 是正箇所を特定し、SLAでエンジニアリングチームに割り当てた
  • 一般公開の回顧展は、Zendeskカスタマーサポートからヘルプセンターに公開され、チケットを送信した影響を受けるお客様に送信されたものです。 

サービスインシデントを終了する

ベストプラクティスとして、Zendeskはカスタマーとのオープンチケットをすべて終了して、事象に関するすべての情報が適切に文書化され、伝達されるようにします。

完了したすべてのサービスインシデントは、週1回のサービスインシデントダイジェストレポートにまとめられ、Zendesk全体で広く共有されます。事象の説明、顧客への影響、重要な改善事項は、このレポートに含まれ、Zendeskの経営陣と共有される隔週のオペレーションレビューレポートにも含まれています。

遡及情報がヘルプセンターに公開され、オープンチケットがその遡及の結果で更新されると、サービスインシデントの分析とレポートのフェーズが完了したと見なされます。Zendeskカスタマーサポートは、これらのチケットをサービスインシデントにリンクし、「終了」とマークします 。

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

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

Powered by Zendesk