恰逢今天读到了行业大佬对近期频发的公有云故障的思考《你用的公有云都没做过测试》,该文章的核心观点是「公有云是没法测试的」。我其实对这个事情有相反的观点,云服务本身也是软件,软件工程发展至今测试手段是多样和丰富的,而且公有云因为有大规模的生产流量优势,用好金丝雀 / 灰度发布能在新版本全网发布前尽可能揪出从其他测试环节中逃逸的 Bug。
那既然测试是好做的,为什么从结果来看,公有云故障还是那么多呢,结合我在云厂商的工作经历来看,两朵云近两次 IAM 相关的故障背后,大概率还是投入问题。IAM 产品本身不产生直接的营收,在营收至上的公有云厂商里,IAM 团队的处境可想而知。我曾经负责的产品因为在核心的数据链路引入了 IAM 进行鉴权,所以跟 IAM 团队打交道的次数不少,但每次看他们一个小团队支撑着如此重要的业务,也不免胆战心惊。所以,从墨菲定律来看,两个国内头部云厂商都在 IAM 上栽了跟头,也是偶然中的必然了。
AutoMQ 一直秉承云原生上云的理念,我们深度使用云提供的原生能力研发了存算分离的 AutoMQ,相比较 Apache Kafka,我们获得了 10 倍的成本优势,在运维效率、弹性等方面也有质的飞跃。所以,公有云是否能稳定运行,跟我们的业务是息息相关的,所以在此我想谈一些关于公有云故障的思考。IAM 的问题是个例,还是具有普遍性?我们可以看一下云厂商的产品目录,数百个自营产品,再结合云厂商投入的研发人数,我们可以很容易得出一个结论「大量的云产品测试资源的投入是不足的」。所以,AutoMQ 在第一天选择依赖哪些云原生的能力时,就定下了两个原则1,其中之一就是「选择云厂商投入最大、规模最大的云服务」,这类服务成熟度往往是最高的,基本都集中在 IaaS 层,比如计算、存储和网络等相关产品,当然数据库也是云厂商的兵家必争之地。
回到 AutoMQ 上来,我们团队过往的经历让我们深刻意识到测试体系建设的重要性,如果你曾经也在测试资源严重不足的情况下运维着数千个生产节点,你就会理解我们当时的如履薄冰,以及现在要做好 AutoMQ 质量保障这件事情的决心。作为企业级软件服务,完备的测试基础设施的重要性是不言而喻的,至少体现在三个维度:
今天,也趁这次机会,向 AutoMQ 的用户介绍一下我们已经具备的一些测试能力。
AutoMQ 基于 KRaft 版本 Kafka 进行研发的,所以在排除 Zookeeper 模式相关的 E2E 测试用例后,我们通过了剩下 500+ 用例,并会周期性地运行这些测试用例,及时发现 Broken 的情况。
当然,性能测试并不意味着只在版本发布时,或者跟竞品对比的时候去做,更重要的是要维护好性能基线,及时(比如按天)去回归主干的代码,做好性能的对比,能够及时发现某一次 Commit 影响到了性能指标。否则,性能可能就会随着软件的迭代逐渐恶化,甚至很难溯源出在什么时间点性能出现了下滑。当然,性能基线的自动化回归,AutoMQ 当前还没有完全具备,后续有进展后及时同步给大家。
Chaos Testing
如上图所示,图中相邻的两根竖虚线表示一次故障注入的开始和结束,我们可以很容易发现,在上述两个节点的集群中,一个节点出现故障时,流量会持续跌到 0,然后分区会通过故障转移挪动到另一个节点,所以另一个节点出现了持续的流量上涨。在故障结束后,AutoBalancing 组件又会重新调度分区,将流量尽可能调度到比较均衡的状态。
公有云的故障不会结束,每次故障如果能给我们带来一些思考和警示,能激励我们持续性投入到软件质量保障上面,那每一次故障带来的都会是进步。AutoMQ 目前的测试体系每月会消耗数万的云资源,确保软件缺陷能尽可能留在研发环节,避免逃逸到线上。当然,线上故障无法避免,AutoMQ 利用云原生的能力创新性地解决了 Kafka 的诸多问题,能否也用云原生的方式低成本地,在多云多地域的 BYOC 产品形态上,将线上故障的监控、发现和恢复环节管理好,我们在下一篇文章里面讲一讲这方面的实践。最后,既然公有云的故障无法避免,即使 AutoMQ 仅依赖了 IaaS 层云服务,如何在故障发生时进行容灾呢,我们也将在后续的文章里面分享 AutoMQ 如何以云原生的方式应对 ECS 故障、EBS 故障、S3 故障、AZ 级故障的思路和方案。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。