一、前置
- 云原生给各中小公司工程效率带来了很大的便利，多家云厂商的架构体系不完全相同，在选择云厂商以及业务上云的过程中，整体的集群切换会是一个比较复杂的课题。
- 酷家乐在2022年初进行了一次整体集群切割，实际的切换过程由于前期的认真准备和各项策略的实施取得了符合预期的效果。本文期望给做整体集群切换的质量团队做一个分享。
- 机房切割可能在自有机房和公有云之间的迁移，或者公有云间的迁移。酷家乐碰到的场景是在公有云之间做迁移，文中姑且描述为A云到B云的切换，A云为旧生产集群，B云为新集群。
- 集群迁移涉及到工作面非常多，选出部分关键内容进行分享。
二、目标和背景
三、测试方案和策略
3.1 被测对象的分析
- 常规的项目被测对象为代码，但这次的迁移项目项目的测试对象实际为整个集群。
3.2 被测集群准备
没有环境就无法开展工作，环境集群搭建是整个项目中的基础环节，中间件和运维团队花费了大量的精力，作为质量团队主要是提供策略和要求。
基本原则：
- 屏蔽外网真实流量无法引入，测试过程不能影响真实用户。
- 测试集群尽量模拟线上真实的切换集群，能达到提前验证的目的。
思路：
- 由运维团队搭建真实集群，切换前为准线上集群，我们叫仿真集群，由中间件团队做初步的可用性验证。
- 仿真环境，中间件和存储在B云，与现有生产环境隔离的独立环境，数据和配置从A云全量同步。
- 拨入VPN或者通过独立的虚拟机可以访问仿真集群，仿真集群数据可反复重置，仿真环境的操作不影响实际业务。
3.3 多轮测试计划
随着集群职责的演进产生了不同的测试阶段，事后回顾来看分阶段测试策略非常有必要。
四、典型实践分享
4.1 流量回放实践
4.1.1 背景分析
在时间紧张的情况下，能否有一些技术手段来协助回归测试，首先想到的是流量回放的测试，而实际我们在项目中大量的采用了该方案。
常用的流量回放测试手段对比选型：
4.1.2 动作
最终功能测试环节，核心借助A云生产 to B云生产进行nginx mirror回放测试过程来做回归和性能测试。
环境准备：
- 镜像流量可能会影响生产环境数据，生产服务，如何去避免？
- 仿真和生产网络隔离
- 仿真环境禁写部分存储资源
- B云内调用公网导致的多次调用
- 通过域名黑名单形式禁用
- 仿真环境涉及三方的服务接口支持mock
- 原生产环境A云nginx负载问题
- 新增nginx机器，从6台扩展到12台
- A云B云专线负载问题
- 日常网关流量为3G+，专线带宽扩到10G
A云B云两边数据一致性，在数据重置完成后立刻开始做流量回放
分析流量回放数据：
- 分析网关层报错，根据http code和response返回。
- 分析集群内部dns层网络解析报错，配置错误的域名会导致网络层报错，从而留下错误日志。
- 分析应用的日志报错。
- 通过监控系统查看监控报错，做报错统计。
- 查看数据库内的数据变化。
4.1.3 结果
- 回放取得了比较好的效果，借助mirror回放发现了功能测试未注意到的问题，测试用例未覆盖，实际线上仍有流量。
- 大流量的情况下获取了中间件存储的性能基线数据，可用来做性能性能对比分析。
- 失败率的分析：流量存在报错的漏斗效应：入口流量抵达最终底层服务的只有部分成功，其余会被中间层拦截。
4.2 性能测试实践
集群的性能评估为成功切换提供了重要参考依据，在项目初期就进行性能测试计划和方案的评估。
性能测试的三个阶段：
项目的性能测试流程：
实际借助性能测试，发现了20+的性能问题，包括底层存储配置，已经配置改造缺失等，针对集群迁移的测试中尤其要考虑性能风险。
4.3 延时模拟实践
4.3.1 背景
可灰度是项目发布三板斧之一，能够提前的规避风险，但灰度环境的搭建过程中遇到一个评估难题，在此阶段A云B云需要同时提供服务，只能有一套存储，新集群应用部署在B云，存储和中间件部署在A云，会涉及到跨云访问，跨云访问即便走专线也会产生延迟增加。
问题：
如果将用户流量引入B集群，性能衰减是否客户能够接受，需要进行延时验证，但是如何模拟跨云延时？
解决办法：
借助tc工具进行网卡的延时模拟。
相关文档：tc manpage: https://man7.org/linux/man-pages/man8/tc-u32.8.html
下面命令模拟带有波动性的延迟值（在 90 ~ 110 之间波动）。tc qdisc add dev eth0 root netem delay 100ms 10ms
可针对K8S的Node，也可针对具体的pod，编写脚本后批量执行。
4.3.2 效果
- 搭建模拟环境之后，测试进行了一轮接口RT采集，部分的功能响应时间达到几十秒，不符合预期。
- 优化：将部分底层基础服务换回A云，这部分应用不参加灰度集群, 大幅减少底层接口的DB跨云访问，最终大部分用户端的RT符合预期，在灰度前避免了对用户的影响。
4.4 项目沟通过程实践
4.4.1 高效沟通
- 项目涉及50+的测试，200+的开发，实际的沟通成本非常高。
- 作为测试PM 避免自己成为瓶颈，注意避免1:50的沟通，而是找到接口人建立树状沟通，否则会非常痛苦。
4.4.2 有效沟通
- 发送了信息，但是对方不一定收到，对方收到信息，但是不一定理解。
- TCP握手式的沟通，对重要的信息一定要以此形式。
4.4.3 善用在线化工具
- 搜集信息
在线表单>在线表格>线下表格>IM群里讨论，举例以下为企业微信的表单功能，优于在线表格管理。
企业微信的在线表单：
企业微信的在线表格：
切割过程中的问题搜集线上化，搭建看板，告别群内统计，例如汇总透明进展。
借助技术手段快速的搭建项目中使用小工具，会发现事半功倍。
五、后记
- 切割当天历历在目，在那难忘的两小时内，核心人员屏住呼吸操作变更和观察数据，分秒必争，说惊心动魄也不为过，可能是笔者从业以来经历的最危险项目之一。
- 除了前述的一些技术手段之外，整个项目组的QA小伙伴们也勤奋的进行多轮回归测试，发现了大量集群问题，功能测试的设计和执行仍然发挥了决定性的作用。
- 在重大的项目中，测试PM可发挥的空间和余地是巨大的，如果说整个项目是一艘巨轮，测试PM就是迷雾中的那个灯塔，避免巨轮偏向危险的航道。
- 测试PM要比项目PM更了解这个航道上礁石在哪里，提前识别风险，这基于对业务和系统理解，对风险的敏锐，这也依赖经验，需要从中小项目的锻炼做起。
- 测试PM需要勇敢的针对风险发出信号，也许会有误判，但是万一它是真的，也许会带来严重的后果，保持谨慎和敬畏。
- 测试PM在困难面前需要有强烈信心，突破边界，争取一切可能的支持，动用一切可能的手段来保障质量，你的坚定会打动你的伙伴。
- 如果你在一个质量团队，你一定要尝试担任几次大型项目的测试PM，对于你的个人成长非常有好处！
文章篇幅有限，探讨的内容有限，欢迎大家对感兴趣的内容继续探讨！
作者：神雕，shendiao@qunhemail.com
推荐阅读
公众号：酷家乐技术质量 知乎：酷家乐技术质量
TesterHome：kujiale-qa (酷家乐质量效能)