全面公测｜Grafana服务：一张图表胜过千行指标&日志

对于运维人而言，随着互联网行业野蛮生长逐渐结束，“如何降本提效”、“用数据说话”或已成为当下工作的核心主题。纵观纷繁复杂的日常运维场景，其背后大多有着明晰的导向目标，比如对产品服务质量负责的要求，对资源使用效率提升的要求，对技术成本控制的要求。

为达成上述目标，运维人在聚焦日常运维平台搭建之余，也开始逐渐重视数据建设，以期通过数据驱动运维。我们一定都听过「增长黑客」，但数据驱动运维又是什么？在这里，我们姑且笼统定义为通过对业务目标、运维流程的识别，借助全栈不同数据源的整合，将业务应用和基础设施关联在一起，构建完整数据分析体系，从而精准量化评估运维全过程以及服务质量，最大限度降低服务运行的成本，保障服务运行的安全。

这样的定义听起来似乎跟运维人的日常工作习惯与流程并无二致，那接下来我们具体来聊聊「数据驱动运维」。

01

我们为什么需要数据驱动运维？

Aliware

首先，那下面的几个常见运维场景，运维人一定不意外：

• 缺少跨系统监控的统一视图

企业历史积淀的监控系统较多，既有如云资源监控、网络资源监控、存储资源监控等通用基础监控，也有如业务监控、数据库监控、各种中间件监控等定向监控。这些监控背后数据种类多、格式不统一，且分散在各自系统中。各系统拥有独立的权限管理方式以及数据展现方式，导致在故障发生时，缺少统一的视图汇总各类数据，无法有效辅助运维人员进行故障分析。运维人员无法直观地判断异常指标间的关联关系，需要各个系统不断跳转并反复查看，手工进行数据整合和分析判断。

• 缺少业务视角的指标关联

在故障发生时，往往最先反应在业务指标上，然而业务指标通常缺少与其他各种类型运维监控数据、告警数据关联关系，导致运维人员在故障处理的过程中效率较低。监控工具缺少与业务数据、告警数据和系统关系数据的有效整合，使得故障定位的过程需要多个系统运维人员共同参与分析，很难直接从业务角度来发现监控数据之间的关系。

• 缺少纵深交互的分析能力

系统故障无法完全避免，故障管理的重点是对故障快速响应和恢复服务。通常运维人员在故障定位时，很大程度上依赖运维经验，而监控工具更多是提供单一层面、单一指标的排查方式，无法有效结合应用架构及相关指标进行关联分析。导致在故障定位时存在根因定位不准确、定位不够及时等情况。随着系统复杂度不断增加，系统可用性要求不断提升，监控工具不再单纯是统一的整合和展示，还需要更有效的分析手段，通过关联、下钻等交互方式辅助查找故障根源。

• 缺少针对场景的定制能力

特定行业的业务场景相对较为固定，监控工具缺少针对具体运维场景进行数据整合和展示，以及定制数据关联和分析的功能，使得运维人员在特定场景下的故障处理效率较低。

0