当系统负载增加很多倍时，VTB IT部门不得不多次处理系统中的紧急情况。 因此，有必要开发和测试可预测关键系统上的峰值负载的模型。 为此，该银行的IT专家设置了监视程序，分析了数据并了解了如何使预测自动化。 我们将在一篇简短的文章中介绍哪些工具有助于预测负载，以及是否有可能借助它们来优化工作。
高负荷服务的问题几乎在所有部门中都出现，但它们对于金融部门而言至关重要。 在第X个小时，所有战斗部队都必须准备就绪，因此有必要提前知道会发生什么，甚至确定负荷会在哪一天跳起来，以及哪些系统会遇到。 需要对失败进行斗争并加以预防，因此甚至没有讨论实现预测分析系统的需求。 有必要根据监视数据升级系统。
膝盖分析
工资项目是发生故障时最敏感的项目之一。 对于预测而言，这是最容易理解的，因此我们决定从它开始。 由于在高峰负载时具有高连接性，其他子系统（包括远程银行服务（RBS））可能会遇到问题。 例如，对SMS收到付款感到高兴的客户开始积极使用它们。 负载可能会跳动一个数量级以上。
第一个预测模型是手动创建的。 我们取了去年的卸货量，并计算了预计在哪几天达到最高高峰：例如，在1月，15日和25日以及该月的最后几天。 该模型需要认真的工作，没有给出准确的预测。 尽管如此，她还是确定了必须添加硬件的瓶颈，并通过与主客户达成协议来优化汇款流程：为了一目了然地提供薪水，来自不同地区的交易会及时分散。 现在，我们对银行的IT基础架构可以毫无故障地咀嚼的部分进行处理。
在收到第一个积极成果后，我们转向了预测自动化，还有更多关键部分正在等待轮到我们。
综合方法
在VTB，他们介绍了MicroFocus监视系统。 从那里，我们进行了预测数据收集，存储系统和报告系统。 实际上，已经进行了监视，仅需添加指标，预测模块并创建新报告。 该决定由外部承包商Technoserv进行支持，因此该项目的主要工作是由其专家进行的，但是我们是自己构建模型的。 预测系统是基于Prophet制作的-该开源产品是在Facebook上开发的。 它易于使用，并且易于与我们全面的监视和Vertica工具集成。 粗略地说，系统会分析负荷计划，并基于傅立叶级数对其进行推断。 也可以按天添加某些系数，取自我们的模型。 无需人工干预即可获取指标，每周一次自动重新计算预测，然后将新报告发送给接收者。
这种方法揭示了主要周期，例如，每年，每月，每季度和每周。 工资和预付款，休假期间，节假日和销售的付款-所有这些都会影响系统的呼叫次数。 事实证明，例如，某些周期相互重叠，中央联邦区将系统的主要负载（75％）分配给系统。 法人和个人的行为有所不同。 如果“物理学家”的工作量在一周中的每一天相对均匀地分布着（这是很多小笔交易），那么公司占工作时间的99.9％，此外，交易可能会很短，并且可以在几分钟甚至几小时内完成。
根据获得的数据，确定长期趋势。 新系统表明，人们大量选择了RB。 这是众所周知的，但是我们没有想到会有如此之大的规模，最初我们并不相信它们：打给银行办公室的电话数量迅速减少，而距离交易的数量却增长了完全相同的数量。 因此，系统上的负载也在增加，并将继续增加。 现在我们预测到2020年2月的负载。 可以预测正常天的错误率为3％，高峰日的错误为10％。 这是一个很好的结果。
陷阱
和往常一样，有一些困难。 使用傅立叶级数的推断机制很难达到零-我们知道周末法人实体很少产生交易，但是预测模块产生的值远非零。 可以用力纠正它们，但是拐杖不是我们的方法。 此外，有必要解决从源系统轻松收集数据的问题。 常规的信息收集需要大量的计算资源，因此我们使用复制建立了快速缓存，我们已经从副本中获取业务数据。 在这种情况下，主系统上没有额外的负载是一个阻塞要求。
新挑战
解决了预测峰值的前额任务：自今年5月以来，没有因超载而引起的银行故障，而新的预测系统在其中发挥了重要作用。 是的，这还远远不够，现在银行想了解高峰期的危险性。 我们需要使用负载测试中的指标来进行预测，对于大约30％的已经运行的关键系统，其余的都在获取预测的过程中。 在下一阶段，我们将预测系统负载不是在业务交易中，而是在IT基础架构方面，也就是说，我们将在下一层进行预测。 另外，我们需要完全自动化指标的收集并基于它们建立预测，以免进行卸载。 这没有什么特别的-我们只是按照最佳实践交叉监控和进行压力测试。