我们面临的挑战
阿里的双十一已经成为全球的超级工程了,在这个超级工程中，全链路压测是很重要的一个环节。整个集团层面的全链路压测，涉及到的BU和团队非常多，对于这样一个涉及多个团队协作的事项,如何尽量的减少人员的投入,减少全链路压测的次数，同时又能保证压测能够达到目标，成为一个必须要去突破的问题。
集团的全链路压测主要涉及交易和导购两部分。交易的全链路启动比较早，相关的平台，工具和流程经过几年的沉淀，已经比较成熟,形成了较为稳定的体系。导购的全链路压测，因为导购业务的特殊性，例如入口流量存在较多的不确定性，系统之间的调用错综复杂，加上导购的业务，日常态和大促态差异比较明显等。
以上是经过抽象之后的导购的全链路压测模型，实际的模型，会更复杂，入口的分散，系统之前的互相依赖等，如下图显示。
另外导购的全链路压测2016年才启动，还没能够形成体系。针对这些问题和挑战，2017年，我们通过构建一站式的全链路管理平台。克服了上述的问题，取得了良好的效果。
在2017年导购的全链路压测启动之前，我们先回顾了过去导购全链路压测经历过的问题。
1. 压测的人力消耗已经越来越不可管控，全链路压测导购人力消耗，150人，双十一当天1000人，如何减少人力已经成为迫在眉睫的事情
2. 应用多，入口分散，每次压测都需要调整流量模型，频繁的调整对收口业务的稳定性带来了较大压力
3. 无历史参考数据，换一拨人很多历史经验无法沉淀，造成人力的巨大浪费
4. 上下游流量人肉的收集与管控，导购场景相互之间网状调用，造成长期流量评估的巨大误差
5. 无压测性能过程管控，研发人员一有性能问题***反应就是要机器
针对这些问题，我们构建了一站式的全链路压测平台。以下是平台核心功能,主要包括压测构造、压测执行(偏监控)、分析问题和定位。
压测构造
导购的全链路压测，压测需求的构造，是很重要的一个环节，对压测结果的准确性有很重要的影响，同时也需要不小的工作量。2017年，我们在压测构造方面提供了以下的丰富的能力
(1)数据工厂:提供快速构建压测数据，支持多种类型和灵活的参数构建规则，并实现了压测数据在关联系统之间的共享，降低了压测数据准备的工作量提高了压测数据的准确性
(2). 压测流量模型和需求: 导购的流量存在多单元入口,以及入口流量的不确定性，这对压测需求的构建有一定的影响。2017年，我们通过构建压测流量模型。并以此作为基础，直接一键构建压测需求，并支持压测需求的批量更新，合并，复制，需求内链路压测数据之间的共享等，大大降低了压测需求构建的工作量。
流量模型梳理
近1000个链路场景，系统与系统之间存在互相调用，系统流量之间存在千丝万缕的联系，给核心系统的业务评估带来了巨大的挑战。评估流量模型的时候很容易产生遗漏，也容易产生评估的偏差。OPM可以实时录入线上流量，产生流量调用比例图(如上图所示)，当入口流量确定时，可以协助用户梳理整体流量，为流量的梳理提供帮助
在这个基础上，我们增加了导购全链路压测的全局视角，通过提供以下的能力,达到全链路压测的一体化。
1.任务管控：可以管控导购全链路压测的所有应用链路，包含压测需求、压测链路、流量模型、并提供了全局流量视图。对导购的全链路压测的全貌，可以实时查看。达到对整个压测的可视化
2. 进度和变更管控：通过和ebay的协作，对全链路压测的时间进度，压测变更，等进行管控，使得整个压测的过程，有条不紊的进行。
压测执行时
导购的全链路压测，涉及到的应用比较多，要关注的点比较多，例如入口流量是否正确,各单元的流量比例是否正确，是否有跨单元调用,实际压测流量和预设值是否一致等等。借助现有的监控还满足不了。为此，2017年，我们在压测执行时的全局监控方面进行了一些努力。除去集团监控实现的功能外，OPM还提供了以下的全局视图。
1. 压测大盘：实时展现压测流量，包括入口流量，各单元的流量,压测流量与预估值的实时对比等，可以全局监控导购的流量是否符合预期
2. 全局系统监控大盘：系统指标(cpu、load、网络等)、服务指标(rt、qps、超时等)、上下游调用量等，可以很直观的发现整个全链路中，性能瓶颈在哪个应用上。
3. 运维状态大盘：系统监控、业务监控、预案、限流。
上述的全局视图，除了在压测执行的过程中可以实时查看，OPM也提供了快照的功能,持久化在平台中，可以重新进行分析和查看
分析定位
OPM通过整合集团内的各监控平台，构建了分析定位性能问题的基础，
1. 变更分析：全链路压测性能出现问题时，我们首先想回到压测的那个时刻，了解当时执行了什么变更?推送了什么配置?当时的性能快照是什么?OPM提供实时快照能力，实时记录时间的所有变更，为后续性能的分析提供数据支持。系统变更聚合展示，可以快速定位出性能的变化与系统变化之间的关联。
2. 性能快照：系统性能快找，通过自定义的性能快照采集和生成，方便事后对过去任意时间系统状态进行查询和分析
2017年的新尝试--构建性能基线
2017年，我们针对导购的核心应用，启动了构建性能基线的计划。通过周期性的在隔离环境进行基线压测，及时发现应用的性能问题，尽早发现，尽早解决，避免了性能问题遗留到大促前，大大降低了系统的性能风险。
隔离环境(强调性能基线) 何在白天不干扰线上业务进行常态化的集群压测一直是性能基线的难点，opm提供隔离环境，使线上集群压测能够常态化的进行。
首先系统系统自动化的隔离一堆机器，隔离的环境与线上系统逻辑隔离，压测流量自动引流至隔离环境。当压测结束时，隔离机器自动归还给线上环境，一键恢复
性能基线与趋势： 通过持续的基线压测和基线管理，可以全局查看应用的性能以及变化趋势，并对基线压测过程中发现的问题进行跟踪和解决。使应用的性能瓶颈在日常的基线压测就发现和解决，避免了再大促全链路压测时才发现，降低了系统的风险。
2017年，我们取得的效果
1. 人力成本：从之前多个人协同负责一个系统压测，开始转变成一个人可以慢慢负责一条链路的压测
2. 压测准备时长：从每次压测需要提前几天的准备到随时随刻可以进行全链路压测
3. 不确定性到确定性：下游业务每次评估压测流量从收集信息，靠猜的不确定性到系统给出结果流量的确定性
适用场景
1.适用压测模型：入口分散，有统一收口的压测模型
2. 隔离环境与性能基线：常态化的支撑线上性能压测
3. 复杂系统的流量模型管控：压测链路上千场景的流量模型管控
