usdt漏洞(usdt被盗了能追回吗)

Monzo的技术负责人详细描述了这次故障的具体原因。

由于四个月前就已存在的一个Kubernertes漏洞（https://github.com/kubernetes/kubernetes/issues/47131），英国网上银行初创公司Monzo上周五的服务中断了一个多小时。

据Monzo的工程负责人奥利弗?贝蒂（Oliver Beattie）声称，“由于一连串不幸的事件”，这个漏洞导致整个生产集群瘫痪，著名作家莱蒙尼?斯尼克特（Lemony Snicket）也许会将这起事件取“致命缺陷”（Fatal Flaw）这个标题。

客户们在此期间看到收款延迟、付款失败。 Monzo作为一家基于互联网的银行来运作，客户通过其智能手机应用程序来访问，它提供活期存款账户、预算编制工具和开支警告等服务。

周一，贝蒂公布了分析这起事件的结果（https://community.monzo.com/t/current-account-payments-may-fail-major-outage/26296/95），归咎于Kubernetes及其与相关软件不兼容。

贝蒂解释道，Monzo的架构依赖Kubernetes用于集群编排、分布式数据库etcd以及管理集群路由和负载均衡的软件linkerd。

出现故障前两周，Monzo的平台团队刚将其etc集群升级到了新版本，并将规模从三个节点扩展到了九个节点。没想到这么一来，他们实际上为故障埋下了隐患。周四，一个工程团队为账户持有人部署了一项新功能，但是开始看到问题随之出现，于是相应缩减了服务，以便该服务不在任何副本上运行，但仍作为一项Kubernetes服务而运行。

周五大约14：10（英国标准时间）前后，工程团队对用于处理付款的一项服务进行了更改。这时，客户开始遇到付款失败。两分钟后，恢复了这一更改，但问题依然存在。

到14：18，Monzo的工程师们查明了问题原来出在linkerd上。这个软件没有收到Kubernetes发来的关于新的pod在网络上何处运行的最新消息，因而将请求路由至不再有效的IP地址。

14：26，他们决定重新启动在后台运行的数百个linkerd实例，觉得这么做有望全面解决问题。但是计划落空了，原因是运行集群节点的Kubelet（每个节点上运行的主要“节点代理”）无法从Kubernetes apiserver获取配置数据。

工程师们怀疑另外的问题在影响Kubernetes或etcd，于是重启了三个apiserver进程。到15：13，所有的linkerd pod已重新启动。不过银行应用程序的服务没有收到任何请求。到这个时候，平台完全瘫痪了。

15：27，工程师们注意到：试图读取来自apiserver的服务发现响应时，linkerd将NullPointerException（空指针异常）记入日志。他们意识到之所以无法解析空的响应，正是由于运行的Kubernetes和linkerd的版本彼此不兼容。

为了恢复服务，他们改而使用在该公司的过渡环境（又译登台环境，staging environment）中测试的更新版linkerd。进行了必要的版本升级后，他们认识到：只要删除没有副本的服务，就可以避免试图解析这类服务引起的错误。这让linkerd得以恢复其服务发现，平台开始恢复如初。

贝蒂表示，他的团队“在Kubernetes和etcd客户端发现了一个漏洞，在重新配置集群（就像我们在上一周执行的那种操作）后，这个漏洞会导致请求超时。由于这种超时，服务部署后，linkerd无法从Kubernetes收到关于可以在网络上何处找到它的最新消息。”

他表示，重新启动linkerd实例让问题更复杂化，因为它揭露了特定版本的linkerd和Kubernetes之间的不兼容性。

贝蒂总结道：“我想要对每个人保证，我们非常重视这起事件；这是我们公司有史以来发生的最严重的技术事件之一，我们的目标是经营一家客户可以永远依赖的银行。我们知道我们让大家失望了，对此深表歉意。”

真诚的道歉似乎受到了客户的好评，许多客户对详细披露和解释原委的做法表示了赞赏。