摘要

  • 8月21日16:15 UTC，Twilio建立第一条事件记录，调查从其平台发往科索沃Dukagjjni网络用户的短信投递失败；约33分钟后出现第二条同名记录，并标为原因已定位。
  • 截至17:54 UTC，第一条记录仍是调查中，第二条仍是已定位，两者都未进入监控或解决状态。公开信息没有给出根因、失败消息比例、错误码、消息类型或预计恢复时间。

短信接口返回受理成功，并不等于收件人已经收到内容。Twilio此次事件发生在这两个状态之间：发送方可能已经把请求交给平台，而后续面向特定目的网络的投递仍然失败。对客户来说，是否重发不能由一张状态页代替判断。

第一条事件对象在16:15:44 UTC创建，唯一更新称，Twilio客户“可能”遇到发往科索沃Dukagjjni网络用户的短信投递失败。Dukagjjni是Twilio在两条原始记录中的拼写；这些来源没有独立确认运营商的法律名称，因此不应自行替换或扩展身份。

第二条对象在32分56秒后创建，标题和影响描述相同，但ID不同。它一开始就称原因已经定位，团队正在解决。17:49 UTC的下一次更新重复了同一实质内容，只把后续通报间隔从一小时改为两小时。Twilio没有说明根因、故障层、缓解方式或恢复时点。

两条记录都把影响标为minor，并关联到处于性能下降状态的SMS, Europe组件。这个组件是供应商的汇总视图，不能被解读为欧洲短信普遍中断。事件正文限定的是从Twilio发往科索沃一个特定名称网络用户的路径，也没有证明科索沃全部短信或该目的网络整体不可用。

公开记录缺少衡量影响所需的分母。Twilio没有公布尝试和失败消息数量、客户数量、发送来源国家、发送方类型、目的号码段、错误码或失败占比。minor只是事件等级，不是可验证的失败率。

真正决定重发的，是单条消息的状态链。Twilio的Messaging文档说明，客户可以通过Message资源和状态回调跟踪外发消息的变化。前提是客户保留Message ID和回调结果，这样才能区分平台已受理、继续处理、最终送达和终止失败。事件页不会替客户完成这笔账。

盲目重发会把可用性问题变成一致性问题。若原消息已经终止失败，重新发起可能是必要动作；若最终状态只是延迟，旧消息随后到达，新消息就会形成重复。验证码可能已经过期，告警重复可能引发两次操作，营销短信重复则会损害信任。重发规则必须同时考虑状态、时效、内容用途和重复成本。

证据截止时，两条事件都没有进入监控或解决。未来Twilio即使宣布解决，也只代表供应商对当前服务状态的结论，不会自动说明受影响期间每条消息是送达、失败、仍延迟还是已被安全替代。客户侧的消息账本仍需逐条收口。

来源