要約

  • Twilioは8月21日16時15分UTC、コソボのDukagjjniネットワーク加入者へのSMS配信失敗を調査する記録を作成した。約33分後、同じ題名の別記録を作り、原因を特定済みとした。
  • 17時54分UTCの証拠確定時点で、先の記録は調査中、後の記録は原因特定済みのまま。いずれも監視または解決には移っておらず、原因、失敗率、エラーコード、メッセージ種別、復旧見込みは示されていない。

障害後に確認すべき最小単位は、国でもコンポーネントでもなく、一つのMessage IDである。Twilioの今回の公表は特定の宛先経路で配信失敗が起き得ることを示すが、どの送信が受理され、どの送信が最終的に届いたかまでは示さない。

最初のインシデントは16時15分44秒UTCに作成された。更新は1件だけで、TwilioからコソボのDukagjjniネットワーク加入者へのSMS配信失敗を顧客が経験している可能性がある、とする。DukagjjniはTwilioの原文表記であり、この資料だけから別の正式事業者名へ置き換えることはできない。

二つ目は32分56秒後に作られた。題名と影響文は同じだが、IDは異なる。こちらは原因を特定し、解決作業中だとした。17時49分UTCの更新でも内容は変わらず、次回更新予定だけが1時間後から2時間後へ延びた。根本原因、故障した層、対処内容、復旧予定は非公開である。

両記録のimpactはminorで、SMS, Europeコンポーネントは性能低下となっている。しかしこれは欧州全域のSMS障害を意味しない。本文が示すのはTwilioからコソボの一つの名称付きネットワーク加入者へ向かう経路である。コソボ向け全SMSや当該ネットワーク全体の停止を示す証拠もない。

規模も測れない。試行総数、失敗数、顧客数、送信元の国、送信者種別、宛先番号範囲、エラーコードは公表されていない。minorはTwilioの分類であって、失敗率の測定値ではない。また同名の二つの記録が同じ原因を持つのか、一方が他方を引き継いだのかも説明されていない。

運用側では、送信要求の受理時にMessage IDを保存し、その後の状態変化を追う必要がある。TwilioのMessaging文書は、Messageリソースとステータスコールバックによる外向きメッセージの追跡を説明している。これを使えば、プラットフォームが要求を受けたことと、宛先への最終配信または終端失敗を分けられる。ただし今回、各顧客がその設定をしていた証拠はない。

復旧試験では、障害中に送った既知のMessage IDを残したまま、新しいテスト送信を別に行う。新規送信の成功は現在の経路を確認するが、古い送信の結末は確定しない。逆に、古い送信が遅れて到着する可能性を無視して同じ内容を再送すれば、二重通知や二重処理が生じ得る。

証拠確定時、どちらの記録も未解決だった。今後resolvedになればTwilioの判断は更新される。それでも、障害時間帯の全Message IDが配信、失敗、遅延または安全な代替のどれに収束したかは、顧客側で確認しなければならない。

情報源