连续公有云故障引发的思考：如何构建 AutoMQ 高质量的测试基础设施

恰逢今天读到了行业大佬对近期频发的公有云故障的思考《你用的公有云都没做过测试》，该文章的核心观点是「公有云是没法测试的」。我其实对这个事情有相反的观点，云服务本身也是软件，软件工程发展至今测试手段是多样和丰富的，而且公有云因为有大规模的生产流量优势，用好金丝雀 / 灰度发布能在新版本全网发布前尽可能揪出从其他测试环节中逃逸的 Bug。

那既然测试是好做的，为什么从结果来看，公有云故障还是那么多呢，结合我在云厂商的工作经历来看，两朵云近两次 IAM 相关的故障背后，大概率还是投入问题。IAM 产品本身不产生直接的营收，在营收至上的公有云厂商里，IAM 团队的处境可想而知。我曾经负责的产品因为在核心的数据链路引入了 IAM 进行鉴权，所以跟 IAM 团队打交道的次数不少，但每次看他们一个小团队支撑着如此重要的业务，也不免胆战心惊。所以，从墨菲定律来看，两个国内头部云厂商都在 IAM 上栽了跟头，也是偶然中的必然了。

1 选择云厂商投入最大、规模最大的云服务

AutoMQ 一直秉承云原生上云的理念，我们深度使用云提供的原生能力研发了存算分离的 AutoMQ，相比较 Apache Kafka，我们获得了 10 倍的成本优势，在运维效率、弹性等方面也有质的飞跃。所以，公有云是否能稳定运行，跟我们的业务是息息相关的，所以在此我想谈一些关于公有云故障的思考。IAM 的问题是个例，还是具有普遍性？我们可以看一下云厂商的产品目录，数百个自营产品，再结合云厂商投入的研发人数，我们可以很容易得出一个结论「大量的云产品测试资源的投入是不足的」。所以，AutoMQ 在第一天选择依赖哪些云原生的能力时，就定下了两个原则[1]，其中之一就是「选择云厂商投入最大、规模最大的云服务」，这类服务成熟度往往是最高的，基本都集中在 IaaS 层，比如计算、存储和网络等