登月计划基建出海质量保障
一、前言
随着国际化业务的不断发展，给原有国际化架构下的业务稳定性带来了极大的挑战，故障频频发生，国际化基础架构结合业务做了自上而下的重构。登月计划项目由此而来，跨团队相互积极配合推动，尽管过程中存在各种问题和教训，顶着稳定性目标压力，登月计划仍然可以有序的推进完成。
本文主要阐述整个登月计划基建出海质量保障相关的方法沉淀、稳定性实践和基于故障的反思，希望能对未来不同基础设施出海提供一些参考和借鉴。
二、第一阶段：支持监控告警（临时方案）
国际化istio架构一直处于无人维护的状态，业务几近裸奔。国内熟悉的监控告警、微服务治理、变更流程规范等常规套路均不适用。对国际化业务来说，当前最重要紧急的是能够感知当前线上环境存在的问题然后有的放矢及时应急。监控团队针对istio架构出临时解决方案，待后期微服务从istio架构完全改造成现有的微服务架构后，即可正常的使用现有的监控体系。因此阶段一是一个临时过渡的阶段。
2.1 监控支持istio架构
作为测试同学，对监控支持istio架构简单做了一些了解。目前国内的监控类别主要包括基础metrics数据、faros埋点数据、调用链数据和日志数据，国际化服务主要支持metrics和简易版的调用链。
基础监控告警建设（metrics）
istio体系内置了几个监控指标（见下图），同时也解释了为什么后面支持的基础性指标相对于国内的数量少了很多
有了指标数据，监控即可通过prometheus采集和分析数据
建立监控阈值，通过监控事件关联和触发告警，推送给相应的业务同学
分布式追踪系统jaeger（调用链）
istio sidecar 支持 jaeger client 采集
jaeger server 聚合处理trace数据
jaeger ui 展示调用链数据
2.2 监控支持的基础指标
这是一个从0到1的过程，当然相比较国内的稳定性指标还是相去甚远，但是至此，国际化业务终于有可持续维护的监控告警能力了！由于韩国集群的istio版本和其他集群的版本不同，因此这里采用了2套不同的监控模板分别覆盖。
2.3 质量保证实践
告警攻坚战 - 持续整改
接入监控告警前期，每天接到百来个P0\P1告警（包括重复告警），告警单从数量上看，估计真是让每一个研发测试都提心吊胆、如履薄冰，很崩溃。。。前期也不知道这个告警信息是否有效，具体问题是什么，应该怎么解决。那么就和业务团队一一确认，必须解决国际化监控报警。到现在国际化业务P0\P1告警基本是个位数，国际化团队整个推进过程从2月初到4月中旬，历时3个月左右。
规范告警处理流程 - 有序应对
从最初收到告警直接往群里丢到现在建立规范的国际化值班流程，告警的处理流程正在逐步规范化和流程化。明确告警处理人员、规范告警处理流程、提升研发测试对告警的敬畏心，有助于更有效和及时的解决问题。针对一类明确的告警，问题排查往往有套路可循。但是有些告警可能并非本服务造成的，往往需要对业务逻辑有比较深刻的理解。相反，也能够通过问题排查慢慢提高对自身服务的认识和解决问题的能力。
监控告警的解法如下：
明确告警类型，业务告警类型主要分为3类
响应时长异常：一般是业务复杂度较高导致的，针对这类异常可以优化业务逻辑，实在无法优化的可以调整监控告警的阈值
错误率异常：这类告警一般是必须要修复的，4XX和5XX必然已经影响到业务逻辑了
网络或者中间件异常：这类告警一般是国际化网络环境或者中间件在istio环境不适配引起的，由运维团队和中间件团队针对性处理
针对当前的监控告警，测试同学根据类型牵头梳理，配合研发同学明确优先级，问题处理owner及修复时间
三、第二阶段：规范变更流程
这里的数据主要指数据库、redis、系统及业务配置，最终国际化业务对上述3种数据的变更全部通过审批完成。变更管控的重要性这里就不再赘述了，有太多血和泪的教训。
3.1 国际化业务接入配置中心
改造前说明 - configmap
configmap是k8s天然的配置中心，k8s将各种需要的配置信息定义为容器的环境变量（图一）。业务应用从环境变量中获取各种系统配置和业务配置（图二）。
使用configmap主要存在的问题是没有变更管控流程，权限对所有研发开放，变更内容没有二次确认。对于系统级别的配置，一旦改错就是高P故障。其他可见的锦上添花的功能，比如现有配置中心的热更新，系统配置和业务配置隔离等。
3.2 质量保证实践（划重点）
线下主要问题
问题1：应用连不上配置中心server，导致应用无法拉取到应用的配置项
解法：istio sidecar没启动完成https://imroc.io/learning-kubernetes/kep/sidecar-containers.html，加大配置中心 client的连接超时时间和重试次数，同时支持pull fast fail兜底
问题2：部分应用的配置中心client日志不打印，如果配置中心有异常情况，业务应用无法获取告警，相当于裸奔
解法：排查后发现这些服务的classpath里没有log4j2的依赖，中间件对logback的日志框架有点问题，目前是开启log.disable=true暂时解决
问题3：istio场景下配置中心client的watch请求（长轮询30s）504问题
测试重点
实际上这里分为2个阶段，并不是一下子从configmap迁移到现有配置中心，中间经历了configmap – > helm配置（可以理解为现在发布系统的环境变量配置） →现有的配置中心的过程。上面说了配置分为系统配置和业务配置，系统配置在发布系统，业务配置在配置中心，没毛病。针对配置数据迁移做了自动化的校验支持国际化测试保障，用于验证梳理以后的配置数据是否遗漏，这一点很重要。
配置迁移校验测试
对于接入配置中心后的微服务在istio架构下的可靠性测试，实际上这一点在项目初期是被遗漏的，这才会出现上面说到的问题1，在内网的测试环境，没有打开istio sidecar开关，导致内外网的环境不同。特别是涉及基础架构的变更，必须确认测试环境、测试内容和预期是否一致。这里的可靠性主要是指在服务istio架构下，微服务是否会存在连接数问题（当前国内存在问题）及网络引起的延时。问题一连接数问题由于国际化的服务体量远不及国内，主要是观测istio下的影响。问题二网络延时可能会影响应用的启动时间和热更新的及时性，这个主要取决专线网络情况。
服务在istio架构下的可靠性测试
四、第三阶段：统一部署流程
4.1 helm发布
国际化服务和国内的服务架构不同，导致国际化的服务不能直接使用发布系统，评估以后采用helm（k8s下的yum）的部署方式，尽量让部署方式不发生重大的变化。待阶段四所有的微服务改造完成后，即可正常的使用现有发布系统的部署功能。这里的工作主要包括以下几个方面：
发布系统开发功能支持helm的部署方式
发布系统支持通用的配置模板
国际化服务应用部署迁移到发布系统
国际化服务改造通用的配置模板
4.2 质量保证实践
测试重点
配置模板数据校验
配置模板数据是指应用启动时用到的系统和业务参数，如环境相关的定义信息k8s集群、k8s namespace等，现在需要将这些信息迁移到发布系统 helm配置中。如何保证模板数据的一致性非常重要。测试可以分为2步，第一是元数据的一致性校验（可以通过自动化脚本搞定），第二是根据配置信息梳理精准测试范围。
应用平滑迁移 可以想象，当应用通过发布系统发布后，会出现新老服务并存的情况。那么，第一次应用发布和回滚方案就显得特别重要了。根据最小变更发布&可灰度可回滚的原则（变更基本遵循这个原则），以x-service发布为例：
踩的坑
2021.03.31 韩国集群XX服务被删除问题：
这个线上故障要是放在白天就是妥妥的P0，幸运的是这波操作是在晚上并且跟踪处理了这个告警。这个故障本质还是没有流程，包括变更流程管控以及平台对变更流程的强管理。特别是对于删除的操作，务必是需要double甚至tripartite check。
2021.03.09 改方案名称为乱码问题：
由于镜像变更导致的乱码，确实是没有被评估到的，毕竟这个镜像在国内已经被广发使用，相对成熟。对于国际化以后的测试建议是重点测试多语言及时区。
1.首先确保本次发布只有发布系统接入相关的变更（没有前端依赖）
2.发布单个集群，发布后新老服务pod并存，业务验证没有问题后，销毁老pod
3.经过充分灰度后发布另外2个集群
五、第四阶段：全面接入微服务体系
5.1 改造目标
接入微服务体系，可以通过微服务体系及相关平台进行服务治理 接入发布系统，可以通过发布系统发布改造以后的微服务 接入监控系统，可以通过监控系统查看海外集群的监控告警信息
5.2 质量保证实践
白盒测试
1.代码commit review
2.配置 review
3.监控观测
可灰度可回滚
开关先行：
1.路由切换
2.客户端调用方式切换
3.日志打印切换
发布-回滚协调：
自动化测试
几百个接口的调用方式变更，毫无疑问风险非常高，基础侧需要在业务同学测试之前，交付一个可测试的版本：
1.网关注册的接口实现自动化校验，主要校验接口差异和接口规范性
2.业务核心接口自动化测试
六、跨区域跨团队协作
明确目标
明确落实
定期追踪
互帮排障
风险暴露
推荐阅读
公众号：酷家乐技术质量 知乎：酷家乐技术质量
TesterHome：kujiale-qa (酷家乐质量效能)