概述：**年我们将以无人值守压测为突破方向，增强压测的感知、管控能力。
一、为什么要做？
日服务人次过亿的背景下，同样的故障时间，带来的损失业务难以接受。要解决这个问题，需要我们有下面特点的评估能力：
- 精细化的全面覆盖已有功能；
- 常态化的覆盖各种变更；
- 安全稳定，不会因为评估带来事故；
- 高效，人员投入少，成本低。
这些需求最终就将会从人工压测演练变成智能化的无人值守评估能力。
价值在哪里？
降低人工成本，减少损失：
系统自动判断是否有风险，并可以快速停止，快速止损，比人的反应时间更迅速，观察点更多，反而是更安全的。
精细化管控
全自动化后，可以更大范围，更频繁的自动压测评估，继而对容量的评估更精细化，更可靠。
二、为什么现在要做？
有成熟的经验可借鉴
行业里面，阿里系已经在2020年左右具备了这个能力，有成熟的经验可借鉴。
- 2020QECon-阿里妈妈-李杰-百万级流量无人值守全链路压测实践（https://www.modb.pro/doc/46047）
- 吴骏龙 - 极客时间《容量保障核心技术与实战》专栏作者。(https://time.geekbang.org/column/intro/100078501)
- 阿里云：实现无人值守压测实践（https://help.aliyun.com/document_detail/118258.html）
可借力
无人值守的关键技术是可借力的。
其它团队在风险识别、根因分析方面有相当的经验；而且我们可以跟金融风险团队、金融QA共建这个无人值守的能力。
月度常态化压测已经做了很久
美团金融核心业务团队的月度常态化压测已经做了很久了，从无人值守压测做切入点，能解决前期推广的难题。可以先在压测这里探索智能化、无人值守的经验，然后推广到演练，混沌工程也才能真正的落地。
风险可控
手工随时可以终止，让业务亲自使用，让人放心
我们提供无人值守压测这个能力，如果业务不放心，可以仍然有人参与，并手工终止压测。
有兜底机制
-
在一定监控阈值时，会触发兜底停止压测或演练；
-
兜底机制的再兜住
- 独立部署的无人值守服务，相对比较稳定的服务，很少变化，不会受压测能力的变更影响。
- 规则+机器学习模型并用，机器学习模型是一个辅助，同时有基于规则的兜底。
三、为什么我们做？
-
我们的需求类似应用是不具备的。
压测演练场景下，我们期望更精细化的识别影响范围内的任何波动，而不是只感知到了阈值的报警。
集团的Raptor故障定位能力、Horae-时序数据异常检测系统、雷达Radar都是故障发生后的分析，我们期望未来能做到快达到故障边缘的感知，继而好做控制爆炸半径的混沌工程。目前集团做的是满足不了我们需要的。 -
有需求，有推广基础
我们有压测工具巨浪这个基础，有QA为主牵头的月度常态化压测，同时也有高效评估的需求。
四、如何做？
先做无人值守的压测能力，建设时要考虑这个能力也可以用到无人值守演练上。
无人值守压测，将通过下面三个阶段的建设来完成。
-
增强感知能力：通过引入图数据库，对覆盖范围内的所有服务、接口、容器的波动、突增、异常增速等建设精准感知，自动根因分析的能力；同时记录快照数据，作为智能报表的一部分。 具体来说应做 智能感知模块划分 。
-
增加管控能力：基于观测到的数据，做继续放量或紧急终止的决策和执行。同时这个管控能力需要不受压测工具自身变更的影响，足够健壮。
-
增加置信度：压测时流量更贴近真实，每轮压测前自动评估将使用的流量模型是否合适，并能自主构造更贴近真实的压测流量。
为什么先做感知能力：压测感知能力不影响现有压测能力，可以无缝接入，同时各团队的月度常态化压测又天生有一批最初用户能支持完善这个功能。
我们并不会要求业务上来就做无人值守压测，现阶段，通过做无人值守压测，把对压测的感知能力增强，对压测中各个异常波动都能发现定位出来。然后做辅助管控，人为可以打断智能辅助。这整个过程中，都不会以无人值守作为我们的考核目标，而是作为我们努力的方向。
五、做什么？
按照压测演练事件的时间顺序，我们需要做下面事情：
事前： 压测模型自动化校准
对压测的流量占比，mock设置跟实际高峰期或者要演练的场景做对比，判断出压测模型是否应该调整？
初期可以给出建议；
后期自动产生压测方案、回放数据智能构造。
事中： 小流量探测
通过小流量自动探测，可以自动发现是否符合预期？ mock和各种开关自动打开和关闭。
事中： 流量自适应阶梯上量，风险管控
压测风险管控模块即可主动终止、主动止损、也可以主动放量。
事后： 根因分析，自动产生报告
要分析的，并产生对应报告：
- 当流量是多少时，瓶颈点在哪里？
六、FAQ
Q：为什么做智能感知需要用图数据库？
我们的服务是微服务架构，大量的服务之间关系天生就是图的关系。 通过图数据库可以方便对服务、容器、方法做精细化管控、根因分析。
行业里面做根因分析的很多算法也是基于图数据库的。
集团有成熟的图数据库平台(GDS)，包括金融有好些团队都已经在使用中。
Q：这个能力会影响到谁？谁需要决策是否启动这个项目？
不会影响到业务，只是对做压测和演练的QA和RD有提高人效，增加感知能力的影响。
前期只需要参与方的X2做决策就行，有了产品后，做推广时可以到所有X2。
Q：QA和大数据团队需要做啥？
QA作为最终用户，使用的任何问题都能反馈出来。
作为压测规范的制定者和执行者，一同制定基于规则的风险识别规则。
行业调研：已经做到的阿里系的主R方是QA。
如何智能化识别风险，智能化根因定位都是大数据库团队可以提供支持的。
Q：为什么技术架构主R这事？
需要一个知识广的来R（懂机器学习、懂压测、懂混沌工程）
这项事情是后面做架构全景图的一个前期探索。（强弱依赖判定）
