随着数字化转型在大型金融机构的持续推进，数字化服务的性能和可用性成为企业业务和IT部门最关注的指标。
大型金融机构的IT系统较为复杂，因此对用户体验的要求也相对较高，如何从性能和可用性故障中快速恢复，成为IT运维和开发团队的最重要的责任之一。
MTTR 成为衡量企业IT运维水平的重要指标，简单来说就是从故障出现到恢复的平均时长。
什么是MTTR？
MTTR（Mean Time To recovery）是指平均恢复时间。MTTR主要包括两部分时间：确认异常发生所必需的时间，以及处置修复所需要的时间。
在运维场景下，从异常发生到最终恢复的时间越短，可能造成的业务影响和损失程度就越小。
通常情况下，对比各个阶段的时间长度，MTTK最长，也是最能体现提升效果的阶段。
MTTR 包括：
MTTR = MTTI + MTTK + MTTF + MTTV
一般来说，MTTK 是其中耗时最长的过程。那么，EZSonar 如何帮助运维团队通过缩短 MTTK 来提高故障处理速度？
首先，MTTK 中的“Know”的目标是能够制定出有效的恢复方案，因此至少要能分析出导致当前故障的直接原因。
无论是通过人工分析还是算法自动分析，前提都要有足够的数据，以及在性能上可以支撑这些分析的平台。
平台和数据处理能力是提高MTTR的根基
大型金融机构IT系统复杂、数据量大，每天的流量数据量和日志数据量都是PB级别的，每天产生大量的告警，这些告警能否监控到非常细颗粒的业务数据？并及时、快速地给出具体信息？真正实地的为金融机构解决好精细化告警问题，必须要有一个坚实的大数据平台和数据处理能力。
EZSonar4.2的大数据架构
提供了切实有效的平台和数据基础：
1. EZSonar的流量解码探针可以将每一笔交易的内容字段实现解码，并计算性能指标，这是数据基础。
2. 每一笔的交易都保存在 ElasticSearch + kafka 中，可以根据任意条件对每一笔交易进行实时的搜索和统计计算，其性能支持实现秒级响应，这是数据处理能力基础。
撇开数据处理能力及硬件资源占用，去谈及高效的运维监控，是不太现实的，对用户而言，更是一种不负责任。
EZSonar4.2交易监控系统告警与缩短MTTR
1. 交易监控系统何时告警
在实际应用中，监控到交易异常后会触发告警，通知运维人员进行处置，运维人员根据告警信息进行针对性响应。可见，告警是整个故障修复过程的起点，很显然，起点的位置决定了 MTTR 的大小。
通常，告警都是在故障发生之后触发的，但是一般故障都不是一个孤立的事件，总是从一些小问题开始，逐步严重，最终导致千里之堤，毁于蚁穴。如果能提前发现这些小问题的指征，发出告警及时处置，能够避免随后大故障的发生。
例如，二代支付系统每天都会有不少业务报错，从一段时间的总数来看，报错是比较稳定的，但是如果细粒度监控就可能发现某一种错误码出现的频率越来越高，此时就意味着某些交易环节出现了隐患。
其根本原因是多样的，比如变更了业务处理逻辑，修改了调用关系等。如果不及时进行人为干预，随着业务运行很可能导致某些业务彻底无法工作，带来严重后果和经济损失。
2. 交易监控系统能否为告警应急处置提供信息支持
在告警的应急处置中，往往需要依赖告警信息，如果交易监控能够有更精准的数据和更智能的分析手段，那么对制定有效的应急处置方案将提供极大帮助，让运维人员迅速做出决策，从而最大限度的缩短 MTTK。
例如，第三方支付系统产生交易量突发告警，告警信息中不仅有总交易数量，还把涉及到的支付宝、微信支付、京东支付等渠道分别占据多少比例列出来，帮助管理员更直观地看到突发的具体来源。
网银系统响应时间超长触发告警，告警信息中不仅提供一个平均响应时间的概要信息，而是把网银系统按照每种交易类型、每个交易机构等维度的响应时间都列出来，那么定位问题就非常直观和迅速了。
动态针分割线
因此，在缩短MTTR方面，EZSonar4.2 告警的首要目标——提前故障处理的起点，甚至提前到真正故障发生之前。
EZSonar4.2 将通过以下两个方向的努力，实现上述目标：
1. 更多的告警。
2. 更少的告警。
