VTB IT部门多次需要处理系统运行中的紧急情况，系统负载成倍增加。 因此，需要开发和测试一个模型来预测关键系统的峰值负载。 为此，该银行的 IT 专家设置了监控、分析数据并学会了自动预测。 我们将在一篇简短的文章中告诉您哪些工具有助于预测负载以及它们是否有助于优化工作。
几乎所有行业都会出现高负载服务的问题，但对于金融行业来说，这些问题至关重要。 在X小时，所有作战单位必须做好准备，因此有必要提前知道可能发生的情况，甚至确定负载跳跃的日期以及哪些系统会遇到负载。 需要处理和预防故障，因此甚至没有讨论实施预测分析系统的必要性。 有必要对基于监测数据的系统进行现代化改造。
膝盖上的分析
薪资项目是万一失败最敏感的项目之一。 这是最容易理解的预测方法，所以我们决定从它开始。 由于高连接性，包括远程银行服务 (RBS) 在内的其他子系统可能会在高峰负载时遇到问题。 例如，对收到款项的短信感到满意的客户开始积极使用它。 负载可能会跳跃一个数量级以上。
第一个预测模型是手动创建的。 我们获取了去年的上传数据，并计算了预计出现最大峰值的日期：例如 1 日、15 日和 25 日，以及该月的最后几天。 该模型需要大量的劳动力成本，并且无法提供准确的预测。 尽管如此，它还是发现了需要添加硬件的瓶颈，并通过与主力客户达成一致，优化了转账流程：为了不一次性发工资，来自不同地区的交易随着时间的推移而被间隔开。 现在，我们将它们分成银行 IT 基础设施可以“咀嚼”而不会失败的部分进行处理。
收到第一个积极结果后，我们开始进行自动化预测。还有十几个关键领域正在等待轮到他们。
综合的方法
VTB 实施了 MicroFocus 的监控系统。 从那里我们收集了用于预测的数据、存储系统和报告系统。 事实上，监控已经就位，剩下的就是添加指标、预测模块并创建新报告。 这一决定得到了外部承包商 Technoserv 的支持，因此实施该项目的主要工作落在了其专家身上，但我们自己构建了模型。 该预测系统是基于Facebook开发的开源产品Prophet制作的。 它易于使用，并且可以轻松与我们安装的集成监控工具和 Vertica 集成。 粗略地说，系统分析负载图并根据傅里叶级数进行推断。 也可以每天添加取自我们模型的某些系数。 无需人工干预即可获取指标，每周自动重新计算一次预测，并将新报告发送给收件人。
这种方法确定了主要的周期性，例如每年、每月、每季度和每周。 工资和预付款的支付、假期、假期和销售——所有这些都会影响系统的调用次数。 例如，事实证明，一些周期相互重叠，系统的主要负载（75%）来自中央联邦区。 法人实体和个人的行为有所不同。 如果“物理学家”的负载相对均匀地分布在一周中的几天（这是很多小交易），那么对于公司来说，99,9%都花在工作时间上，交易可以很短，或者可以在几个小时内处理完毕。分钟甚至几个小时。
根据获得的数据，确定长期趋势。 新系统显示，人们正在集体转向远程银行服务。 每个人都知道这一点，但我们没想到会有这样的规模，一开始也不相信：银行办事处的电话数量正在极快地减少，而远程交易的数量却以完全相同的数量增长。 相应地，系统的负载也在不断增长并将继续增长。 我们现在预测 2020 年 3 月之前的负载。 正常日的预测误差为 10%，高峰日的预测误差为 XNUMX%。 这是一个很好的结果。
陷阱
和往常一样，这并非没有困难。 使用傅里叶级数的外推机制不能很好地跨越零——我们知道法人实体在周末产生很少的交易，但预测模块产生的值远离零。 强行纠正是可以的，但拐杖不是我们的方法。 此外，我们还必须解决从源系统轻松检索数据的问题。 定期收集信息需要大量的计算资源，因此我们使用复制构建快速缓存并从副本接收业务数据。 在这种情况下，主系统上不存在额外负载是一项阻塞要求。
新的挑战
预测高峰这一简单的任务得到了解决：自今年30月以来，该银行没有发生过与超载相关的故障，新的预测系统在其中发挥了重要作用。 是的，事实证明这还不够，现在银行想了解高峰对其来说有多危险。 我们需要使用负载测试中的指标进行预测，对于大约 XNUMX% 的关键系统来说，这已经有效，其余系统正在获取预测。 在下一阶段，我们将不再预测业务事务中的系统负载，而是预测 IT 基础设施方面的负载，即我们将向下一层预测。 此外，我们需要完全自动化收集指标并基于它们构建预测，以免处理下载问题。 这没什么特别的——我们只是根据全球最佳实践交叉监控和负载测试。
来源： habr.com