“如果你不射击，我会被宠坏”
直到最近，人们认为该服务应该可以正常工作。 他们绘制，编造，编写了脚本-一切似乎都不错，您可以将其投放到产品中。
但是竞争对手并没有睡着，所以这场比赛不仅是为了新功能，而且是为了速度。 应用程序的任何冻结或长时间的服务器响应（更不用说第500条的弹出错误）都会破坏服务的印象，并迫使用户离开其他地方。 当然，每个人都遇到了这样的情况：屏幕上显示“内部服务器错误”，而不是购买飞机票，火车票或音乐会的票，而您却对打破显示器感到愤怒。
我是Victor Bodrov，我在Yandex.Money的生产力研究团队工作，我想谈一谈直接在生产中研究生产力有何用处。
每一分钟的停机时间对于公司来说都是灾难性的，尤其是对于那些涉及金融交易的公司而言，例如转账和付款，在商店中付款。 每次吊销款项不仅是金钱损失，而且是声誉损失。 在这种情况下，需要较长的正常运行时间，为此必须密切注意支付系统的脉动并不断监视其所有指标，尤其要注意性能。
为什么要研究？
首先，了解自己的服务性能可以帮助您为新功能的发布，各种促销和销售做准备。 可靠的指示器知识将在适当的时候帮助您迎接新用户的涌入，而不仅仅是带有旋转门的小型闸门，而是敞开的前门和敞开的双臂。
其次，优质服务应随时了解其性能极限，因此应定期进行测量。 如果您经常进行此操作，并保持数据的相关性，那么不要错过服务质量的下降，您可以快速恢复所需的指标。
第三，依靠最新的绩效数据，企业更容易计划服务的发展并选择增长方向。
对于那些第一次对此类问题感到困惑的人，就会出现一个问题：在哪里以及如何衡量生产率？ 通常，将长凳用于此类实验。 在个别公司中，有一个专门的绩效研究机构。 如果有，那就太好了！ 如果它是产品的1比1，那么一切都很好。 但是，通常情况下，要保持与产品完全匹配的架子非常昂贵。 怎么样 事实证明，与产品完全对应的唯一地方是产品本身？
对于许多人来说，直接在产品上测量和验证某些东西的建议听起来很奇怪。 如果一切都精心完成，不要惊慌，不会有任何不好的事情发生。 例如，我们预先计算可能的风险，并确定实验中系统可能遭受的损失。 与此同时，我们计划如何减少危险，并不断监视系统状态。
对产品的研究并不会取消该支架的使用。 它可以进行发布检查和特殊实验，以研究微服务的性能，包括单独或以各种组合的形式。
产品所获得结果的主要和不可否认的优势-它们是所有选项中最诚实的，并且尽可能接近用户流量的实际处理。 无论支架在产品上离产品有多近，它都无法像阿喀琉斯龟一样抓住它。 在研究产品时，您将使用与真实用户相同的数据库，相同的网络，相同的环境。 无需构建任何东西，所有东西都已经构建好并且可以正常运行。
无论分配给他们什么角色，开发人员，测试人员和管理员都将对所有工程师都感兴趣的实验数据。 保证的性能指标也将使企业感兴趣-对于潜在客户而言，它们将是该服务的令人信服的广告。
方案选择和潮流模式
为了安全正确地组织此类实验，必须完成几个强制性步骤。
方案选择
第一步（最重要的一步）是选择要研究的方案。 这可以是单个请求（例如，检查余额），也可以是逻辑复杂的场景，其中每个后续请求都取决于上一个请求的结果（商店中商品的付款，从钱包到钱包的转移）。 我们定期获取系统中存在的所有业务流程的列表。 我们有超过400个这样的流程，根据业务目标，我们将协调方案的优先级。
优先级组应包括哪些方案？
- 预计在不久的将来用户活动将激增的用户。
- 那些由于各种原因不断受到严格限制（不允许您跌破SLA）的公司。
因此，可以形成优先方案池，以定期检查产品。 在我们公司，我们每季度至少对他们进行一次解雇。
根据脚本的逻辑选择一组技术和工具。 在我们的情况下，优先级方案具有分支逻辑。 例如，当通过卡付款时，根据脚本在其自己的分支上进行的检查，将执行各种检查，因此我们使用JMeter来实现它们。 仅对于这种复杂的情况而言，它很方便，因为每个后续请求都取决于前一个请求的结果。 如果您需要拍摄单个请求，那么我建议使用高性能的Phantom 。
为了研究用户方案，可能需要特殊用户，代表他们将提出要求。 如果使用一个用户或少量用户，则可能会遇到数据缓存，这会使结果失真。 用户越多，研究数据越准确。
负载电路
在第二步中，我们选择输入强度馈送电路。
例如，在销售之前，我们确定用户付款的主要方式。 为了调整和跟踪瓶颈，我们对某些类型的付款进行触发。 通常，各种促销过程中的用户活动倾向于一种或另一种情况。 通过检查，您可以清楚地了解他在负载下的行为。
但是企业也可能对整体绩效状况感兴趣。 对于这种情况，您可以按实际用户的使用比例将最受欢迎的业务方案组合起来，然后打开累积负载。 值得考虑的是，在这种情况下，定量评估可能会遇到困难。 您将获得一个数字系列，而不是一个特定的绩效数字，该数字系列又可以根据总体流程中特定场景的比例而有所不同。
强度的供应也可以不同。 我将重点介绍两个最常见的配置文件。 这是具有线性（或逐步）增加的强度供应流量和稳定性测试的测试，其中在稳定的较大强度流量下检查服务的长期运行。 第二种选择需要很长的研究时间，这在战斗环境中并不总是可能的，此外，应该已经知道所提供的强度水平。
X轴-时间，Y轴-负载强度（每秒请求数）
有一个特定的SLA很好，您可以在此基础上通过监视性能，响应时间和监视组件的行为来进行检查。 更为常见的情况是，性能水平未知，您需要确定它。 为此，我们使用第一个选项-在提供的强度增加的情况下进行测量。 我们打开输入流，线性地或逐步地增加它，我们看一下服务的行为。 线性施加的负载可以更准确地跟踪饱和点和击穿点。 我们的文章中对此进行了更详细的描述。 但是，逐步提供的强度结合了很小的稳定性测试，尤其是在步长很长时间的情况下。 不建议立即对输入施加较大的负载流，最好“预热”服务，逐渐增加输入流。
您还可以进行一系列两个实验。 首先用线性施加的负载测量饱和点，然后停止。 您不应该继续将数据流进一步细分，它仍然是产品，而不是立场。 第二个实验是通过选择饱和点附近的几个步骤来查看一个步骤负载下服务的行为。 然后在时间允许的范围内进行稳定性测试，为其选择一个低于饱和点15-20％的负载（如果在饱和之前突然承受了负载，则进行分类）。 攀高是危险的。
时机
接下来，您应该确定实验时间。 对产品进行性能测量的最重要条件之一是对所有实际用户的安全性。 很少有机会停止该服务一段时间以预防并冷静地对其进行轰炸。 通常，在线服务已调整为24/7全天候工作，因此您需要适应该服务的使用方式。
逻辑上，实际用户活动越高，射击可能导致停机和财务损失的风险就越大。 另一方面，用户流量越少，测量误差就越小。 因此，为了最大程度地减少实验的影响，建议在用户活动减少的时期内进行实验。
根据实践显示，我们用户的最低活动时间为早上2点到7点。 当然，每种服务都有其自身的特征和受众，因此我们通过监视用户的行为来确定拍摄时间。 并非总是可以在选定的最佳时期内组织实验。 为了在产品上射击，特别是在其连接的初始阶段，需要加强控制。 这会造成麻烦，因为您的同事也是人，可能并不总是在晚上上班。 这种情况将需要妥协。 您需要选择一个适合所有人的时间，同时满足用户活动量少的条件。
与交易对手的合作困难
如果该服务不仅与内部计算相关联，而且还与第三方服务（交易方）进行交互，则需要选择触发方式：与交易对手一起使用，或者使用服务存根。 自然，如果您打算在交易对手的服务器上射击，则必须首先就一切达成共识。 这将大大增加准备烧成的难度，但会增加结果准确性的准确性。
反之亦然：如果用插头代替交易对手的服务，将会大大简化拍摄准备工作，但结果的诚实性会下降。 应该记住的是，存根应尽可能模仿对手方的行为，而不仅仅是给出200 OK。
交易对手本身是不同的。 有些很容易进行联合检查，而另一些则在许多实例中运行每一步。 确定实验的时间安排也会引起争议。 例如，一些州办公室同意只工作9到18个小时。
检查与安全理事会，财政部门，行政管理人员的联系和协调
在这一部分中，我们将着重于与所有负责人（安全服务，财务部门和系统管理员）的访问和批准。
您需要检查必要的访问权限 。 确保没有任何东西会干扰研究，并在必要时与您的对手和对手进行网络管理员的访问（如果您与他们合作）。 网络管理员将帮助平衡设置。 我们曾经使平衡器从轮询转换为IP哈希。 结果，我们所有的查询都位于由新的平衡算法选择的同一方面。
获得访问权限后，您需要调试并检查最小单位流上的脚本。
下一步是批准 。 首先，请与安全服务联系，以免由于“可疑活动”而中断您的实验。 为了评估安全理事会的所有可能风险，需要详细的解雇计划-其中涉及谁，什么数量和数量。
接下来，您需要与财务和商业部门协调解雇计划。 如果服务与财务活动相关，则需要与财务部门和会计部门进行协调。 任何其他财务活动都可能影响财务报表，甚至导致各种过帐摘要形成中的故障。 应该避免这种情况，因此值得警告同事，他们已经确定了实验的最佳配置。
如果您有一个统计部门来积累有关服务操作的信息，那么您需要与他们协调射击。 事实是，潮流将引起额外的统计波动。 同意他们是否在报告中考虑测试。 如果不是，则决定如何将真实用户的数据与测试用户分开。
在计划时，您还需要与商业部门协调测试的日期和时间，无论他们是否计划在此时间或附近计划任何广告或促销活动。 不要忘记将产品上所有计划内和计划外的活动告知团队负责人。 当然，您需要警告并同意管理员的意见，因为在拍摄过程中可能需要他们的参与。 此外，这是管理员在生产过程中执行的所有操作。 也许只是在您选择时，才计划进行数据中心交换，服务器更换或其他工作。
点火并分析结果
最后，我们讨论了使用监视进行射击。 我们确定在实验过程中要观察的位置，在什么条件下停止，对哪些传感器做出响应？ 在开始拍摄之前，必须“上岸”完成此操作。
有几种原因可以停止。
1）来自监视的信号。 在这种情况下，实验中涉及的功能是否中断或服务的另一端是否发生紧急情况都无关紧要。 您需要停止测试并理解原因，因为服务的平稳运行是主要优先事项之一。
2）随着网络或HTTP错误的增长。 这是紧急情况，需要干预。
3）如果达到饱和，性能将不再增长，但响应时间会增加。 无需等待故障并插入产品。 分析的结果已经存在，您可以安全地停止实验。
实验结束后，您可以了解日志和结果不足，需要在启用调试日志的情况下重复进行实验。 这将使日志和写入磁盘的工作量增加，但是现在您知道了所需的负载级别，这意味着您可以缩短测试时间，而不必进行长时间的测试。
结果分析
最后，仍然需要分析结果并将所获得的数据提供给感兴趣的各方。 您可以在实验过程中开始执行此操作。 我们将Zabbix和Elastic束与Grafana和Kibana一起使用进行分析。 我们监视实验中涉及的所有外部和内部调用的时间特征，监视连接器池，队列和数据库监视器。 从流量生成器的侧面进行指标的在线跟踪-Yandex服务Lunapark（有一个开放的类似物-过载.yandex.net）。
结果的显示方式会因需要者而异。 为了进行开发，管理员和测试人员需要一份详细的报告，其中应包含准确的指标，图形，日志，堆栈跟踪。 对于业务而言，结果和发展预测很重要。 在这种情况下，数字的具体性和重点更好，更直观。 为此，您可以使用交通信号灯的原理。 红色区域不好，迫切需要优化。 黄色-我们注意到指标下降了，您应该注意这一点。 绿色-一切正常，继续。 清晰易懂的研究结果视图将有助于消除有关衡量绩效的重要性和有用性的问题。
成功的研究，并记住用户安全！