您现在的位置是:网站首页> 内容页

分布式程序如何进行线上灰度自动化验收?

  • 亚搏官方网站
  • 2019-07-09
  • 205人已阅读
简介前言前面在如何负责一个项目的质量保证工作一文中,笔者将质量保障划分为三个阶段,研发质量,上线质量和线上质量。其中针对上线流程,特别提到灰度阶段,QA应该提供相应的验收机制。今天来具体说

前言

前面在如何负责一个项目的质量保证工作一文中,笔者将质量保障划分为三个阶段,研发质量,上线质量和线上质量。其中针对上线流程,特别提到灰度阶段,QA应该提供相应的验收机制。今天来具体说说,针对分布式程序如何打造一个方便好用的灰度验收工具。

我们知道,绝大多数分布式程序天然的支持灰度迭代,通过有序的, 分批次的迭代上线,能够有效的控制故障规模,起到发布中验收的效果。但即使这样,如果基础设施不够完善,还是没办法做到无损灰度的。出了问题,实际仍然是有用户感知,只不过范围较小而已。

线上发布,多数是SRE运维同学操作,他们很有可能不清楚业务细节,比较欠缺验收手段。多数情况下,发布部署的同学主要依靠查看日志和监控告警手段来验收发布。但其实这样非常的被动, 如果是监控告警触发报障,情况可能还好,运维同学会很快感知,快速止损。但如果是客户报障,一来一去时间上就会很长,如果稍微影响的客户多些,就是一例事故。

举个极端例子,比如一个面向用户的接口,因为bug导致用户正常请求在特定场合会返回4xx。如果带着这种bug去灰度,很有可能监控告警层面不会感知,因为4xx在HTTP协议中属于客户端问题,运维同学一般会排除此类code的告警。而客户遇到此类问题,也有可能会首先怀疑自己的行为是否正确,所以到爆发时,影响面可能就比较大。

然而针对这种用户场景的测试,QA是有验收手段的。在实际业务迭代中,QA一般都会产出自动化测试,所以就可以通过这些自动化用例,单独对灰度的实例进行验收,确保发布符合预期。

然而理想很丰满,现实却骨感。实际上多数自动化测试用例并不是那么方便的,去交付别人去使用。它有其复杂性,比如:

服务端的产品,测试框架多数是基于配置文件来适配不同的测试环境,不同的测试账号。日记月累下,测试配置有可能会比较复杂。而让不懂这块的人去改这些配置,心智成本较高。测试框架为满足多样性的需求,会越做越复杂,比如golang领域的ginkgo,功能很丰富,支持并发的跑用例,focus or skip的组合,递归遍历等,对不熟悉的使用者来讲会造成困扰。QA的测试用例可能包含多种层次类型,比如集成,e2e,或者破坏性的。而破坏性的用例,必须确保不能在线上执行,这点很重要。测试数据如何方便的快捷准备,也是需要考量的.

除了测试用例本身的复杂性之外,还需要考虑用例的更新机制,以及分发机制。

所以若想将测试用例交付部署人员来使用,必须解决其易用性,安全性问题,降低使用者的心智负担。

Interface for Tests Execution

一个可行的方案就是构建一个interface程序,专门用于运行测试用例,将所有的复杂性问题都封装起来,做到对使用者友好:

比如可以内置所有配置到二进制程序中,并能让使用者方便的选择使用范围还要能提供简单方式,其使用者指定灰度服务的IP地址,做到针对性测试一键准备测试数据,最好让使用者无感知固定使用姿势,不给使用者犯错的机会工具要有清晰的help文档,随用随学

至于分发问题,就可以将程序托管在公有云存储上,通过shell脚本,一键下载。这种方案会极大的降低使用者的心智负担,对测试服务的推广非常有益。

kubernetes test infra中的Kubetest也是这种思想的的典型代表。

Test as a Service

业界,大家一直在探寻QA的转型之路,不管是左移还是右移,或者是工程效率层面,测试服务的输出都是其中非常有价值的topic。笔者认为,QA不光要拥有业务质量的全局视角,还要能发现业务痛点,然后围绕质量方向,打造高价值产品或平台,以此来输出质量保障服务。测试不在于人,而在于服务。测试服务不是测试同学的玩物,应该是围绕解决如何保证业务质量的难题。同时,单个人,或者单个组织来做质量保证必有其局限性,质量全员建设才是王道。

提供这种灰度验收的工具,其实也是对QA的测试用例提出了更高要求,只有持续保障其稳定,高效,才能不断产生价值。

Contact me ?

Email: jinsdu@outlook.com

Blog: http://www.cnblogs.com/jinsdu/

Github: https://github.com/CarlJi

文章评论

Top