Justin H

まとめ

2024年3月5日19時50分（UTC）から22:06（UTC）まで、一部のTalkのお客様において、コールの発信、受信、転送ができないなど、接続の問題が発生した可能性があります。 

 

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

21:36 UTC | 13:36 (PT)

現在、コールの発信、受信、転送ができないなど、Talkの接続に問題があるとの報告を調査しています。次の更新は15分以内、または追加情報があり次第更新します。

22:06 UTC | 14:06 (PT)

Zendeskのエンジニアは、コールの発信、受信、転送ができないなど、Talkの接続に問題が報告された場合も引き続き調査しています。次回の更新は30分以内、または追加の情報が手元にあるときに行います。

22:32 UTC | 14:32 (PT)

コールの発信、受信、転送ができなくなるTalk関連の問題について、現在も調査中です。次の更新は1時間後または新しい情報があったときに行います。

23:31 UTC | 15:31（PT）

当社のエンジニアが変更をロールバックし、当社側で一部回復する見込みです。今後24時間にわたってパフォーマンスの監視を続け、その時点で最新情報を提供します。

3月6日 - 10:59 UTC | 02:59 (PT)

Talkの機能は完全に復元され、カスタマーからのフィードバックと社内監視によって通常通りに機能することを確認しました。今しばらくお待ちください。この事象は解決されました。

 

事後のメモ

根本原因分析

このインシデントは、米国の一部のカスタマー向けローカルISPの問題が原因であるようです。

解決策

この問題を解決するために、最新のTalkの変更をロールバックしました。しかし、当社の調査では、ISPが停止したことを指摘しており、より正確に影響を受ける時間帯と一致しています。

改善策

1. 発信コールのエラーに関する監視と警告を改善します。
2. プロバイダーと協力して、アラートのしきい値を調整して、同じような状況でより早く通知を受け取ることができます。
3. トラブルシューティングのランブックを改善し、範囲をより正確に評価できるようにする。

 

詳細情報を表示

Zendeskの現在のシステムステータスについては、 システムステータスページを参照してください。事後調査のまとめは、通常、インシデントが終了してから数日後にこちらに投稿されます。この事象についてさらに ご質問がある場合は、ウィジェット内のZBotメッセージング経由でチケットを記録してください。

まとめ

2024年3月5日15時30分（UTC）から18:25（UTC）まで、Metaのサービス停止により、ソーシャルメッセージングチャネルを使用しているすべてのポッドでSunshine Conversationsをご利用のお客様は、サービスが大幅に中断した可能性があります。この障害はWhatsAppを主に発生させ、Facebook MessengerとInstagramにも大きな影響を与え、これらのチャネルからの送信トラフィックに部分的な中断をもたらしました。

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

16:30 UTC | 08:30（PT）
Facebook、Messenger、WhatsApp、Instagramなど、Metaのすべてのソーシャルメッセージングチャネルに影響を与える問題を確認しました。Zendeskのパートナープロバイダーが問題を解決したら、再度更新情報を提供します。

17:51 UTC | 09:51 (PT)
Metaのすべてのソーシャルメッセージングチャネルの使用に影響を与える問題から回復が見られます。今後もパートナープロバイダーと協力し、完全な解決まで状況を監視します。

19:15 UTC | 11:15 (PT)
Metaを使用しているすべてのソーシャルメッセージングチャネルで受信および送信メッセージに遅延を引き起こす問題が解決され、これらのチャネルは現時点では予想どおりメッセージを処理しています。パートナープロバイダーとの協力により、ご迷惑おかけしました。

 

事後のメモ

根本原因分析

このインシデントは、Metaのサービス、特にWhatsApp Cloud APIに影響を与える問題によって発生しました。Metaは正確な根本原因を開示していませんが、Metaはサービスの中断を認識し、サービスの復旧に取り組んでいます。この間、Sunshine Conversationsの監視システムは、影響を受けたチャネルからメッセージを送信しようとすると、頻繁にエラーを検出しました。

解決策

障害の解決はMetaの復旧作業に完全に依存していました。Sunshine Conversationsは状況を注意深く監視し、利用可能になったときにカスタマーに最新情報を提供しました。Metaがサービスの復旧を発表した後、Sunshine Conversationsは、アウトバウンドトラフィックが通常のレベルに再開し、ソーシャルメッセージングチャネルを通じてメッセージが正常に配信されていることを確認しました。

改善策

1. 送信トラフィックの健全性の監視を改善します。
2. メインのサポートポータルが利用できない場合に備えて、Metaの代替コミュニケーションチャネルを含めるために、インシデント対応計画を確認し更新します。

 

詳細情報を表示

Zendeskの現在のシステムステータスについては、 システムステータスページを参照してください。事後調査のまとめは、通常、インシデントが終了してから数日後にこちらに投稿されます。この事象についてさらに ご質問がある場合は、ウィジェット内のZBotメッセージング経由でチケットを記録してください。

まとめ

事後のメモ

根本原因分析

このインシデントは、イベント処理サービスがメタデータ内でnull値を持つWebhookイベントを解析しようとしたときにエラーを生成した、エスケープエラーによって発生しました。

解決策

この問題を解決するために、メタデータオブジェクトのnull値を受け付けられるようにコードロジックが更新されました。  Zendeskは状況の監視を続け、この変更後、ポッド26のエラーが発生していないことをログで確認しました。

改善策

1. メタデータオブジェクトでnull値を受け入れるように、Sunshine Conversationsのパブリックドキュメントを更新する [予定]
2. このようなエラーに監視アラートを追加する [完了]

詳細情報を表示

Zendeskの現在のシステムステータスについては、 システムステータスページを参照してください。事後調査のまとめは、通常、インシデントが終了してから数日後にこちらに投稿されます。この事象についてさらに ご質問がある場合は、ウィジェット内のZBotメッセージング経由でチケットを記録してください。

まとめ

2023年11月28日13時14分（UTC）から17:14（UTC）まで、複数のポッドでZendesk Talkのお客様においてTalk/電話のアイコンが表示されなくなり、一部のお客様においてExploreのレポートに多数の未対応コールが表示されています。 

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

事後のメモ

根本原因分析

このインシデントは、テストプロセスでは表示されなかったエスケープバグを含むソフトウェア修正が原因で発生しました。  この修正には、音声アクティビティの読み込み時に常に利用できなかった変数が含まれていたため、読み込み時にクラッシュが発生し、エージェントがサードパーティアプリをインストールしているシナリオではコールアイコンが表示されませんでした。

解決策

この問題を解決するために、以前のソフトウェアバージョンへのロールバックを実行し、リカバリの確認を行いました。

改善策

1. サードパーティアプリが存在する場合に、コールアイコンの読み込みを確認するテストシナリオを追加します。 [予定]
2. 「音声アクティビティに失敗した場合にモニターとアラートを追加する」 [予定]

詳細情報を表示

Zendeskの現在のシステムステータスについては、 システムステータスページを参照してください。事後調査のまとめは、通常、インシデントが終了してから数日後にこちらに投稿されます。この事象についてさらに ご質問がある場合は、ウィジェット内のZBotメッセージング経由でチケットを記録してください。

まとめ

2023年11月16日18時02分（UTC）から20:00（UTC）まで、ポッド13、17、19、23、28、29の一部のSupportのお客様は、インバウンドメールの受信に遅延または完全に停止することが発生しました。メールが送信されてからGoogleの管理サービス経由でZendeskでチケットが作成されるまでの遅延時間は、15分～60分でした。

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

18:53 UTC | 10:53（PT）
Zendeskでは、ポッド28および29で受信メールが処理されないというレポートを調査しています。すぐに追加の情報を提供します。

18:57 UTC |午前10時57分（PT）
ポッド13、19、23、28、29のカスタマーの受信メール処理に遅延を引き起こす問題を確認しました。現在、当社のチームが調査を行っており、詳細なアップデートが利用可能になり次第、お知らせいたします。

19:33 UTC | 11:33 (PT)
Zendeskのチームは、ポッド13、17、19、23、28、29で受信メールの処理が遅延する問題について、引き続き調査を行っています。Zendeskは、影響の軽減に熱心に取り組んでおり、できるだけ早く新しい情報を提供させていただきます。

19:54 UTC |午前11時54分（PT）
ポッド13、17、19、23、28、29で受信メール処理に遅延を発生させる問題については、改善が見られます。当社のチームは、完全な復旧を確保するために引き続き監視を続けます。 

21:14 UTC | 13:14 (PT)
ポッド13、17、19、23、28、29のカスタマーに対して受信メールの遅延を発生させる問題を解決し、現時点では受信メールは予想どおりに処理されています。調査中、ご迷惑おかけしました。

 

事後のメモ

根本原因分析

この事象は、Mail FetcherサービスでGmailとの接続に問題が発生したために発生しました。これにより、Supportで受信メール処理が中断され、Gmailの 302 Moving レスポンスが、ライブネスト検証によってエラーと解釈され、コンテナオーケストレーションアプリに、ポッドが健全でないことを示しました。これにより、オーケストレーターはポッドを置き換え、関連するコンテナでメール処理を停止し、受信メールの遅延または停止を発生させました。

解決策

この問題を解決するために、Gmailがこれらの健全性チェックのブロックを停止した後に受信メールトラフィックを復元しました。これにより、Supportの受信メールがポッドの作成を完了し、メールの処理を再開できるようになりました。その後、受信メールのキューに大量のメールが到達し、トラフィックが通常通りに流れ始めました。

改善策

1. メール健全性チェックの既存の実装ツールを改善します。 
2. 追加のアラートを作成します。 
3. 特定のアプリケーションに修正コード行を追加します。

 

詳細情報を表示

Zendeskの現在のシステムステータスについては、 システムステータスページを参照してください。事後調査のまとめは、通常、インシデントが終了してから数日後にこちらに投稿されます。この事象についてさらに ご質問がある場合は、ウィジェット内のZBotメッセージング経由でチケットを記録してください。

Hey shelley,

I suspect that this could be achieved using a custom attribute to filter out tickets with singular engagements. 

Hello Oanh Chau, 

You should be able to make a report like this in the Support: Tickets Dataset. The screenshot below is a bare bones idea of what metrics and attributes you would need to use: 

The Test Tag Inclusion metric I have here uses the following formula to display only solved tickets with the tags you specify: 

IF (([Ticket status - Unsorted] = "Solved" OR [Ticket status - Unsorted] = "Closed")) 
AND (INCLUDES_ANY([Ticket tags], "your_tag_here"))
THEN [Ticket ID]
ENDIF

You would need to make two custom metrics for your Large and Super Large tags, so they will show as separate columns in your report. 

Hey Bobby Koch, 

The backlog snapshots occur at midnight daily. To view the most current totals for outstanding tickets, we recommend using the Tickets dataset. 

Hey Joel Sandi, 

To answer your first question, you should be able to report on ticket information with an Explore Report using the Guide: Knowledge Capture dataset. There is a set of attributes categorized as "ticket" that allow you to look closer at ticket data from the Knowledge Capture App. 

As for your second question, the articles linked per ticket metric, as well as all the metrics under the "Knowledge Capture" Dashboard tab, are meant to gauge performance metrics of the Knowledge Capture application, primarily. From a business value perspective, the articles linked per ticket metric could show pain points for your staff in your Knowledge Base. I would assume that ideally, you would want this number to be as close to 1 as possible (1 article for each ticket). 

Hey Jacqui, 

Are you using bookmarks to capture the desired time range in this dashboard?