从产品特性到最佳实践，一场缩短MTTR的运维变革

最近华青融天公众号陆续发表了几篇文章，介绍基于大数据分析平台之上的智能运维产品EZSonar的几个特性：微监控、轻告警、慧分析、快定位、全链路，这些特性对于业务运维领域具有一定的颠覆意义，直指运维工具的设计需求，真正为用户缩短MTTR服务。

这几篇文章发表后获得了很多客户和业内专家的共鸣，这些特性既是产品本身的优势，也是在客户实际使用场景中总结出来的经验，下面是文章列表。

这些高效实用的运维理念和工具，目的是帮助运维人员在工作中可实现“快定位”，有效缩短MTTR。

01快定位：有效缩短MTTR

有些运维工具在最初设计时，缺乏对运维工作的真实理解，造成在使用时只是锦上添花的作用。不出问题的时候只能看看大屏和仪表盘，而一旦出了问题却无法从告警中关联到有效的分析结果和问题定位，运维人员还需要从多个数据源中手动收集信息。

这种运维工具就是一种负担，运维人员整天面对大量告警无所适从。

所以，快定位关注的是：是否“真正帮助运维人员缩短MTTR，提高了运维效率”，我们也将此作为衡量运维产品是否真正有用的目标。

MTTR（Mean Time To Resolve，平均故障恢复时间），从下图MTTR的恢复时间可以看到，问题定位时间MTTK（Mean Time To Know）是影响MTTR的主要因素，而“微监控”、“轻告警”、“慧分析”、“全链路”的目标是“快定位”，帮助用户缩短MTTR。

这是我们总结出来帮助用户提高运维效率的一套方法，并把它们作为产品特性和最佳实践。

为了更好的阐述我们的运维理念，以及如何设计一款优秀的运维产品，我们再来阐释一下“微监控”、“轻告警”、“慧分析”、“全链路”这几个概念，它们分别是如何实现缩短MTTR的目标的。

02 微监控：细节决定成败

业务监控应该与业务目标保持一致。

换句话来说，就是业务关注什么，运维团队就应该监控什么。

如果还是以IP地址+Port端口的粗粒度方式，那就无法掌握纷繁复杂的业务种类中正在发生的瞬息变化。

以银行的核心系统为例，不能再把核心系统当做一个黑盒，而是需要使用核心系统交易中业务特征字段的组合，将核心交易按照交易类型进行分类，每一类作为一个独立的监控节点，让各类交易（如转账、收单、理财、第三方支付等）的性能指标和异常告警在业务路径上一目了然地展示出来，监控节点还可以根据需要进一步细分。

以上图为例，“千里之堤，毁于蚁穴”。通过这种细粒度地刻画监控和告警对象，才能及时发现隐藏在海量交易中的细微问题，而不是让运维人员在监控数据中大海捞针。

随着敏捷开发、DevOps、持续集成持续交付（CI/CD）的推广，对运维团队来说，更多的“小问题”将成为常态。

03 轻告警：处理告警变得举重若轻

监控粒度更细，会增加配置和处理告警的难度和工作量，这是运维团队头痛的问题。

轻告警的目的，就是要减少无效告警、偶发告警和重复告警，拒绝告警噪音，让运维团队更轻松地专注于真正的问题。以下图为例：

运维人员是希望每分钟都收到一个相同的告警？还是更愿意只看到这样一条告警，其中包含告警开始时间、结束时间或告警状态持续中等重要信息呢？

除了告警数量更“轻”（少），告警的配置也需要更“轻”。通过动态基线告警、聚合维度告警、关联函数告警等，实现告警配置的智能化和自适应，将原来多条告警规则变成一条更有效的告警规则，甚至于无需告警规则，将原来多条告警通知变成一条更有用的告警通知。

04 慧分析：不止于会分析

“会”与“慧”，前者代表“能”，后者代表“智能”。

会分析的前提是全量数据，平台的数据采集能力、索引能力、全量数据分析能力和扩展能力是基础。

现阶段，快速的、方便的、交互式的可视化分析手段仍然是运维团队的首选，抛开具体场景去谈自动化根因定位还不太现实。通过对多种数据源（如网络流量与日志数据）的关联分析，不仅可以改变运维人员在多个运维工具之间频繁切换、手工查找等低效率的方式，更能提高定位问题的准确性。

数据量大对有经验的运维人员是一种财富，因为他们知道这些数据中哪些是有用的信息。但对于缺少经验的运维人员，数据量大则可能变成一种负担，因为他们很难判断这些信息中哪个更有价值。

而慧分析，可帮助运维人员过滤掉无用的信息，排除不相关的维度，并且在一些确定的场景下，基于算法和模型给出故障分析的智能推荐，进而告诉运维人员这个告警与哪个因素最相关，或者你只需要关注哪几个问题。

所以，全量数据分析是基础，而与人工智能算法相结合才是实现慧分析的关键。

05 全链路：成为真正的业务路径

很多监控工具都讲全流程、端到端，但只做表面上的业务拓扑图还不够，更需要从业务拓扑中梳理出从业务的发起到后台核心系统，包括与第三方系统的接口等。

而这可能跨越了多个不同应用系统，形成一个完整的链路，来监控用户每一笔操作在一连串的业务节点上的执行状态和结果，让业务路径真正成为“业务”的路径。

以手机银行为例，整个链路上每一个节点的监控指标和告警都与手机银行业务相关，包括手机银行渠道（手机银行Web、手机银行APP、手机银行BP），到ESB，再到核心。

ESB和核心同时会处理着来自于多个渠道的请求，但在手机银行业务路径上运维人员只会关注和监控来自于手机银行的请求与响应。

而且可以按照某一特定的业务特征（如客户账号、交易流水号，甚至手机号）去做单笔交易追踪，或者查询在指定时间范围内每笔交易的执行结果。

最近大家都在谈智能运维（AIOps）, 希望通过大数据和机器学习相结合的方式能够使运维人员的工作变得轻松。

从业务监控入手，融合其他监控数据，不断优化针对各种运维场景的算法和模型，才是构建AIOps平台的有效方法。

我们也正在这个方向上砥砺前行。