5 月 7 日上午，一场大火席卷了位于荷兰阿尔梅勒的 NorthC 数据中心，造成的损失远远超出了建筑物本身。
Vonage 的客户失去了对其一些最关键的面向客户的工作流程（包括身份验证、对外通知和双向消息传递）所依赖的短信基础设施的访问权限，其中许多客户的服务中断了 36 小时以上。
Vonage随后发布了解释。该公司在官方博客中证实，“我们一位合作伙伴的数据中心发生火灾，导致该地点托管的基础设施完全失去连接，影响了我们的一些消息服务。”
这听起来很简单，但在同一次更新中却隐藏着一句应该让企业客户体验领导者深思的话：
“我们已将绝大多数受影响客户的服务重新路由到备用数据中心，并在几个小时内恢复了他们的服务。”
如果将流量重新路由到备用数据中心就能解决问题，为什么部分客户需要超过 36 小时才能完成路由？
对于一个企业赖以提供实时客户沟通的平台而言，为什么一个单一设施就能造成如此大规模的破坏？
Vonage并非孤例，但这并非重点
Vonage 的 SMS API、Messages API 和 Verify API（联络中心和 CX 团队用来验证用户身份、触发通知和管理对外消息的工具）全部失效。
此次事件的影响主要集中在向美国以外地区发送和接收信息的客户，特别是欧洲和中东地区的客户。
与同一事件相关的 Numbers 停用 API 问题一直持续到 5 月 11 日，也就是火灾发生四天后。
Vonage 并非唯一受影响的平台。IBM Cloud 的 AMS03 数据中心也因位于同一北加州的机房而离线。
有报道称，一级支持工单数小时无人回复，而据《The Register》报道，IBM 的状态页面在中断期间完全没有显示任何问题。
此外，乌得勒支大学的网络应用程序和网站也受到影响，公交和电车运营商 Transdev 也报告了运营中断的情况。
单个设施造成的后果规模相当大。
这并非 Vonage 独有的故障。北加州大学的火灾暴露了多家企业云服务提供商同时存在的结构性漏洞。但这并不意味着 Vonage 完全无辜。
当一个平台将自己定位为通信基础设施并推向企业市场时，人们期望该平台的架构中已经融入了弹性。
对于一部分客户而言，在发生故障转移路径明显存在的情况下，36 小时的恢复窗口期是一个合理的问题。
一篇博客文章并非韧性策略
针对此次服务中断，Vonage 通过面向公众的更新进行了沟通，解释了原因并确认了恢复路径。
这比 IBM 在同一事件发生后的最初几个小时所做的要好。但事后发布一篇博客文章，与拥有能够避免发布博客文章必要性的故障转移架构是两回事。
对于客户体验和联络中心领导者而言，真正的关键在于依赖性。
短信在客户旅程中扮演着比许多团队有意识地跟踪的更重要的角色，涵盖了从验证流程到实时服务警报的方方面面。
这种基础设施只有在停止运行时才会显现出来。一旦发生故障，客户体验就会实时且明目张胆地崩溃。
企业现在应该问什么
现在企业候选名单上的每家 CPaaS 供应商都应该被问到的问题并不复杂：
您的短信基础设施托管在哪里？分布在多少个独立的设施中？
你们的故障转移架构是什么样的？它的激活速度如何？
Vonage 自身的复苏表明，这种机制是存在的；问题是为什么它没有更快地发挥作用，也没有惠及所有人。
阿尔梅勒的火灾是无法预料的。对于一个标榜自己是企业级通信基础设施的平台来说，长达36小时的宕机更难解释。
本文来自作者投稿，版权归原作者所有。如需转载，请注明出处：https://www.nxrte.com/zixun/66663.html
