要約
- 一部利用者は8月1日13時10分から14時15分（UTC）、RealtimeKitのソケット遅延と会議参加失敗を経験した。
- 本文上の顧客影響は65分である。
- Cloudflareは問題を特定・緩和し、全サービスを復旧した後も監視を続けたとする。
- 唯一の更新は14時44分30.468秒に作成され、記載終了から29分30.468秒後だった。
- メタデータの作成・解決は13時10分30秒で、14時15分までという本文と一致しない。
- 原因、地域、利用者母数、ソケット指標、参加失敗率、緩和内容、予防策はない。
会議の入口で止まった
ソケットはリアルタイムアプリの状態を調整する信号路として使われる。接続が遅い、または成立しなければ、利用者は招待や待機状態から会議へ移れない。
ただし、既に始まっていた会議、音声、映像、録画まで失敗したとは書かれていない。確認できるのは参加経路であり、通信全体の停止ではない。
遅延と失敗の関係は推測にとどまる
ソケット確立が遅れた後にタイムアウトし、信号処理未完了で参加に失敗する可能性はある。だがCloudflareはプロトコル、閾値、コード、故障領域を示していない。
再試行や代替輸送の成否も不明だ。遅延した接続のうち、どれだけが失敗へ進んだかは計算できない。
「一部」は全体を否定するが数量ではない
全利用者への一般化は避けられる。一方、テナント、個人、地域、試行、再試行の数はない。minorにも母数は含まれない。
小さな設定群と広い断続障害の双方が同じ表現に収まる。可用性率を求める材料はない。
公開時刻は正面から矛盾する
本文は13時10分から14時15分、フィールドは作成・解決とも13時10分30秒である。開始直後の値を65分間の終了としても使うことはできない。
どちらかを黙って修正すべきではない。双方がCloudflareの一次記録であり、説明が出るまで不一致を残す必要がある。
一つの事後更新に全段階が入った
14時44分30.468秒の更新は、特定、緩和、全復旧、監視を一度に伝えた。影響中の調査や回復の段階は公開ページに残っていない。
別の通知があった可能性はあるが、この記録は示さない。顧客は復旧の途中点を知ることができなかった。
参加とメディアを分けて検証する
13時10分から14時15分の参加要求、ソケット時間、コード、再試行、セッションIDを確認し、既存会議は別に調べるべきだ。
参加失敗は漏えい、消失、録画破損を意味しない。再試行成功も、時間固定の会議への影響を消すわけではない。
事後報告は時計から直す必要がある
時刻矛盾、信号コンポーネント、利用者・参加数、遅延・エラー分布、緩和、既存会議の隔離を説明すべきだ。
現時点でCloudflareは一部利用者に65分の遅延と参加失敗があったと報告した。メタデータは期間を表せず、原因と規模は非公表である。
