英国的支付行业长期以来一直依赖于由亚马逊网络服务(AWS)和微软Azure等科技巨头运营的“始终存在”的云基础设施,当今年10月双方遭受重大中断时,他们暴露了一个核心漏洞:数字系统的脆弱性,基于超大规模云永远不会失败的假设。 在这篇文章中, 《s》 探讨了这些中断对运营依赖、支付系统风险以及前瞻性企业如何在以云为中心的世界中重新思考弹性所带来的教训。 诺达 Executive Advisor Alex Batlin 2025年秋天的觉醒呼唤 是 AWS 经验丰富 ,由美国东一地区的DNS相关问题引发,仅仅一周后,在 , 微软 Azure 遭受了主要的中断 - 根源原因,原因是其 Azure Front Door (AFD) 全球路由基础设施的错误配置。 20 October 2025 大规模停机 29 October 2025 虽然每个停机只持续了几个小时,但影响在全球范围内在大量服务中受到影响,这些停机不仅影响了Snapchat,Slack或Zoom等常见的全球邮件或社交媒体,还影响了数千家当地英国企业,包括 AWS 停机中断的服务包括Lloyds Bank、Halifax、Scotland Bank和Coinbase。 通过卡付款或访问他们的银行账户。 零售、公共部门和金融服务行业 企业遇到问题 对于许多CTO,停机突出了云依赖背后的隐藏财务暴露,每分钟停机意味着丢失的交易,被抛弃的支票,并侵蚀了消费者信任 - 损失远远超出了IT团队。 为什么英国支付行业如此暴露 少数供应商的高浓度 英国的支付行业高度依赖主要的云服务提供商,但截至2025年,细胞行业数据仍在出现,分析师指出,仅英国的公共部门才授予AWS。 ,显示提供商是多么深入嵌入。 自2016年以来,17亿英镑的合同 更广泛的生态系统表明,当一个主要的超级扩展器失败时,包括银行应用程序,支票和路由系统在内的关键服务变得脆弱。 监管观察 监管机构如金融行为管理局(FCA)和英格兰银行(BoE) 关于云基础设施中的“集中风险”:依靠少数大型云提供商的企业过多构成系统风险。 此前提出的担忧 区块链的教训:一个值得研究的弹性模型 虽然支付行业面临着这些中断,但区块链基础设施提供了教训。几年前,以太坊在其客户端实现中遇到了一个关键的错误。网络幸存下来,因为它运行在多个独立的代码库(Geth,Nethermind,Besu,Erigon等)。 支付公司如何应用这些教训 短期战略 支付服务提供商的直接机会是设计系统,避免供应商锁定,现在比以往任何时候都更可行,但从一开始就需要有意识的架构选择。 Kubernetes 集装箱化 – 基于像 Kubernetes 这样的平台,可在不同云提供商之间运行工作负载。 Cloud-agnostic API – 使用跨提供商工作的工具,而不是直接建立在 AWS Lambda 或 Azure 功能上,这使您能够在多个平台上部署相同的代码。 多云的设计,而不是改装 - 在您围绕一个提供商建立后添加多云功能是昂贵和不切实际的. 在初始架构阶段或计划的技术更新周期中,设计可持续性。 主动部署 - 同时运行在不同提供商之间,而不是主要备份配置,这确保您在生产中始终测试过错的能力。 重要的是要注意,云存储架构的构建和运行比单一供应商解决方案要昂贵得多,但关键付款期间停机时间的成本往往会阻碍这种投资。 长期:重新思考网络依赖 即使你自己的基础设施具有弹性,支付网络本身(SWIFT、Mastercard、Visa)仍然是潜在的单一失败点,这就是区块链基础设施和稳定币成为相关的地方,而不是作为技术偏好,而是作为弹性考虑。 像以太坊这样的公共区块链网络通过全球数以千计的独立验证器运作,没有单一运营商。 当然,银行转账和卡付款仍然占主导地位,并将持续很长一段时间,但随着公司进行多年的技术更新周期,监控受监管的稳定币轨道的发展越来越务实 - 特别是因为欧盟的MiCA和英国的稳定币法规等框架带来了更大的清晰度。 务实的前进之路 2025年10月的中断不会是最后一次,那么支付公司应该采取什么?答案是思维的转变:你不设计“没有失败”,你设计“失败时的连续性”。
