艾辉：大家下午好！下面我要分享的是关于服务稳定性保障建设内容。有点紧张，因为刚刚收到几个线上服务告警短信，生怕线上服务挂了。
艾辉
简短的做一下自我介绍，2012年入行，起初在中科曙光做云计算、云存储产品的测试开发工作，2015年转型移动互联网，加入美丽说负责跨端电商产品的质量保障。之后加入了百度外卖，主要负责用户产品及新零售产品的质量保障，一直专注在质量保障和工程效率方向。
Topic演讲分五块内容，外卖技术架构演进、稳定性挑战与问题、稳定性的风险模型、稳定性保障五板斧、稳定性保障的心得。
首先来看外卖业务全景。围绕流量入口有外卖主站，包括外卖APP、地图、百度糯米和阿拉丁等等，业务系统主要是检索系统、交易系统、营销系统、商业系统，以及核心的物流配送。分析这些核心业务系统，不难看出外卖业务是麻雀虽小五脏俱全，复杂度很高。个人认为O2O外卖的业务架构与电商的业务架构有很多相似之处。
我们再看了解外面架构的演进，外卖在2015年左右的时候，存储设计相对简单，这个阶段架构设计主要是大干快上，野蛮生长，堆机器解决性能问题。到2016年以后，业务迅速发展，简单粗暴的方式不能很好解决服务稳定性问题。因此我们做了很多的业务拆分重构，比如说核心交易系统，营销运营系统等等。底层的数据存储也在做相应的拆库拆表，以及各种中间件、组件、公共平台服务支持。这是精耕细作，拆分重构，抽象分层的演进过程，只为保障好服务稳定性，打造产品用户体验。
其实伴随业务发展和架构演进过程，我们遇到的挑战和问题很多。提几个小问题，外卖业务好像特别简单？没有什么技术含量？其实不是，为什么？外卖业务在每个午晚高峰都存在类双11的秒杀场景，峰值集中（中午 12:00-13:00，晚上18:00-19:00）,高并发交易。并且相对传统电商而言，外卖服务的时效性要求更高，30分钟。比如我们在淘宝、京东上下单，隔天派送体验挺好，但如果中午12点在饿了么平台点外卖下单，下午2点送到，用户肯定无法接受，所以时效性要求特别高。这种大流量、高并发且时效性要求极高的业务场景，对服务的稳定性挑战特别大。如果中午12：00-13:00 线上核心服务挂了，基本当天的业务单量要掉二分之一左右。从服务链路交互图，我们不难看出服务链路长、依赖复杂，从商户菜品浏览加车->下单->支付->商家接单->骑士配送->已送达->用户评价->结算。完整交易链路涉及的系统服务很多。其实面对这种复杂的业务场景，在过去服务迭代过程中，线上发生的故障一点不少。列举几个例子，7.5 Redis服务器出口带宽打满导致业务异常，1.4公有云Passport服务异常导致登陆校验异常，12.22脚本逻辑错误导致MQ堵塞无法消费，3.21线上Bug导致无法享受商户优惠等。在高峰时期关键业务影响如果大于5分钟，小于等于10分钟，即导致P4严重事故，对关键业务定义每个公司不一样，大多数是参考核心功能，业务场景链路和数据等的影响。
我们看一下整个故障原因的分布，直观可以看到，基础设施占比相对比较高，其次就是第三方服务和流程规范不严谨导致的故障，举个例子，美团在去年下半年出现过较大故障，侧面了解到是中间件MQ问题导致的故障，由此可见基础设施的质量及稳定性对线上服务稳定性保障尤其重要。流程不规范不严谨导致的故障，比如：高峰期更新重要配置上线，离线包组件配置线下域名直接带上线等。代码逻辑是核心，基础设施稳定性很重要，第三方服务依赖的监控和预案要完备，不能说第三方服务挂了，线上服务就挂了。流程规范不用说了，只要是人主要参与的事情，存在流程不规范的问题，时间长了就会导致比较大的故障。
一直在基于服务稳定性建设的做各种事情，主要是提升服务SLA（服务等级协议），主要关注系统可用性和订单可用性，对于MTTR（平均无故障时间）做到快速恢复，对于MTBF（平均失效间隔）做到柔性可用。再一起看看稳定性风险模型，正如《架构即未来》这本书所说，即使是中度复杂程度的系统，要想确保软件无缺陷，在数学上也不可能的。换句话说，我们是无法保证我们的软件系统没有Bug的。测试是为了发现更多的风险，从而降低风险发生的概率。架构设计要考虑到风险发生时如何降低对客户和交易的影响范围。监控是为了缩短风险发现的时间。运维则是保障了风险的快速解决。那些稳定性风险类型有哪些呢，架构设计风险、编码风险、安全风险，测试设计风险，监控风险、安全风险、运维风险。
可以简单看一下架构风险这块，主要归类：重复交互、循环交互、冗余交互、负载不均衡、超时不合理、重试不合理、缓存穿透、脏缓存、不均衡的并发交互、不合理的强弱依赖、架构融合，以及重复的DB连接、慢查询。编码风险主要包括不仔细阅读撰写使用文档，不注意编译器的告警提示，新加变量不考虑初始化，忽视片量的生存期依赖，函数接口升级不考虑参数，返回值的兼容性等等。编码风险是稳定风险的最根本源头。测试风险主要几点：不标准环境、不严格准入、不关注异常、不关注日志、不测试上线回滚、不考虑性能、不考虑安全、上线和测试文件不一致、不考虑线上线下隔离、不考虑上线后的流量、不关注监控告警。
稳定性保障的五板斧，稳定性建设常见的动作，如：监控报警、数据一致性、服务隔离、限流、熔断等等。有哪五板斧呢？主要做调用链分析、服务压测、故障演练等。关于调用链分析平台架构，调用链是指由同一个事件驱动的、各个环节生成的交互日志复原的、完整访问调用关系。线上日志是1%抽样的。主要调用逻辑，pids采集任务，采集日志数据到kafka,每5min采集1次，日志数据存储到hbase, traceid（id + 时间戳）存储到redis队列，从redis队列中pop，消费，es展示调用链日志。通过调用链监控会发现一些重复交互，不合理的超时等问题，调用链分析，主要是做耦合、依赖和代码方面分析，深度挖掘系统潜在的风险。
我们看一下监控体系，测试能做的事很多，侧重功能业务的监控，比如服务可用性，页面元素，接口语义，还有数据一致性及流程业务监控。开发主要做基础服务、通用服务、依赖服务、业务日志监控，运维主要是进程监控、日志监控、资源监控、流量监控、网络连通性、网络带宽异常。
关于降级预案，例如商品、商户召回降级，保证数据的时效性，还有用户入口的降级。当发生流量陡增及网络抖动导致运营入口服务异常，我们就关闭线上大牌、分类等入口。再聊聊线上服务的压测，为什么要做压测呢？大部分交易型业务，服务链路较长，调用关系复杂，线上线下环境差异大，第三方服务依赖多，无法精准评估。近几年行业里很多公司在做全链路压测，基于全链路压测做各种压测平台开发。其实这并不只是开发一个压测平台就能实现全链路压测，会涉及业务层的大量改造，以及中间件的适配。如何保证数据不影响线上数据库，一般通过影子库来隔离。整个压测设计需要考虑流量模型，即不同接口调用的流量配比。具体压测实施，主要涉及分析被压测对象设计原理、性能压测场景设计等步骤。
接下来聊聊外卖压测平台的实践，目前这个压测平台已经业务落地应用了。平台架构是很典型的分布式模式Controller-Agent。我们主要做前后端重构、协议扩展、业务定制、Dashboard、监控打通、丰富功能等开发优化。大家可能常常听到用户画像，我想说，故障也有故障的画像。主要分几个层次，四应用层、数据层、运行时、中间件、系统层，还有存储和网络。应用层主要是环境错误、监控错误，依赖异常等等。在存储网络这块，比如说网卡打满了，网络抖动，这是很常见的场景。还有DNS故障，网卡满，不可写，不可读等等。故障演练有一些场景方案，我们一般是围绕单机故障，集群故障和机房故障，单机故障单机服务单个模块，从CPU高压，宕机和磁盘抖动，丢包，网络超时等。集群故障，如：DB无响应、DB连接满、超时、MQ消息堆积等。机房故障，主要有网络设备断网、断电等。对于故障演练，有相关的工具策略，如：Chaos Monkey、Udestroy，Failover。我们主要使用Chaos Monkey方案做网络故障模拟，延迟、丢包。服务重定向，端口转发。资源限制，Cgroup，资源限制。基于故障演练的应用，建立基于SLA的故障体系，做稳定性建设的评估，形成故障管理的验证闭环，针对这些方面开展闭环工作。
最后，我聊一下关于稳定性保障的心得，故障发生前预案演练，故障发生中止损优先，故障发生后复盘优化。当故障发生时止损优先，故障发生前我们需要做好预案的整理，服务架构梳理，线上压测，容量评估，故障演练，监控分析。故障发生中，故障定位，包括数据流、应用、后端，网络，故障处理，通报、预案、紧急处理，止损优先，重启、回滚上线、切流量。故障发生后做故障通告，复盘总结，优化ToDo（如：服务重构，监控补充，性能压测，专项技术等）。
这就是我今天分享的全部内容，大家有什么问题可以提问，谢谢大家！
提问1：你好，刚才讲到监控这块，监控的体系到底是由测试部门主导还是运维部门主导？
艾辉：大部分公司是由公司运维部门整体梳理监控，但是研发和测试也需要做盘点，对业务的监控其实测试可以做很多，开发主要做核心业务链路的数据监控，偏业务层面测试理解比较深刻的，他们是相互互补的。
提问2：我想问一下，现在很多测试工具平台是由一个专门的工具开发团队开发的，还是单独由业务测试、运维单独的团队完成的？
艾辉：都可以。是这样，一些大公司内部有工程效率和基础架构团队，他们可能会做一些基础、公共的工具平台。但偏业务型的工具平台技术，比如做核心订单故障预案演练，这个故障演练一般由业务开发及测试一起来做，因为他们对业务更熟悉。如果没有工程效率及基础架构团队的话，业务团队有能力是可以做公共工具平台开发的，这类技术事务是可以提升测试对服务架构的理解。
提问3：测试工具平台，本身也是软件，一般在企业里怎么样保证测试工具平台的稳定性和质量？
艾辉：首先开发同事自身需要保证测试工具的质量，如果开发了一个框架，这个框架肯定要经得住业务测试同学的应用，要经得住他们的考验。还有一点，我们做一些测试平台，大部分是帮助业务做质量和效率稳定性保证提升，我们对业务的侵入比较小，比如Trace平台线上1%日志的接入，就是避免对线上服务稳定性造成较大影响。
本文来自：2018中国首届云测试峰会，举办方：Testin 云测
Testin，让应用更有价值：www.testin.cn
关注公众号“Testin”，了解更多测试行业动态和测试知识。
网友评论