【概要】
本篇是《数智万物下的运维思考》第4章“平台”的第4节“分析平台”第1小节,主要观点有::
1、在围绕“监管控析”的运维平台有机躯体上,运维数据平台定位为大脑,承担生产环境所有数据和信息汇总、感知、决策、执行、反馈的作用。
2、从日志(splunk\日志易\elasticsearch)、性能(天旦BPC\dynatrace)、监控(zabbix\赞同\ominibus&优锘&优维)、配置(优维/优锘)、流程(servicenow)、应用运营几类运维数据出发,挖掘对应厂商对运维数据应用场景的观点。
3、运维数据平台考虑以下几个关注:
【正文】
一、背景:
在2016年做运维平台化规划时,画过一个图(请见文章链接),将运维平台化“监管控”分别类比人体的眼、神经&循环系统、手,上层的场景可视化类比人的脸,运维数据平台是人的脑。在这样一个运维平台系统的有机躯体上,运维数据平台定位生产运行所有数据和信息汇总、感知、决策、执行、反馈的平台。
差不多5年过去,数字化己成主流思路,运维数据也有了一些可借鉴的理念、应用场景、解决思路。
理念方面,早期的APM/NPM专注性能数据的运行分析,集中监控提出的统一报警与统一性能指标的异常及容量分析,后面从APM演进的ITOA提出全面的IT运营分析,再到现在的dataOps、AIOps(AIOps也有基于算法的运维、智能运维、无人值守运维等解读)则更强调算法。
应用场景方面,主要围绕在故障处理环节的报警收敛与异常定位、基于一般性的监控资源指标数据提供的容量管理、基于运行数据的风险预测、基于性能数据的性能管理。
解决思路方面,大概有三种:
1、基于特定场景的数据分析应用:这种方案以运维痛点为切入点,针对特定的场景选择特定的数据,在解决方案上强调数据质量与算法。这种方式,在选择场景时需平衡成本与收益关系,理清项目收益是解决痛点还是技术创新,根据具体问题选择技术方案,因为有很多运营分析场景并不需要高大上的算法与海量数据。我个人认为,算法与海量数据计算的运用适合探索对未知问题的解决效率上。
2、“监管控析”分别管理数据,在上面建立一层汇集层。比如监控负责存储监控性能与事件数据,日志平台负责存储日志数据,CMDB存储配置数据,ITSM存储流程数据等。这种方式,通常是先有工具的功能使用,再有运维数据分析需求。而在开发运维数据分析时,因为源端数据太多、格式不统一导致开发效率低下,需要引入统一的数据汇集与加工处理能力,提高数据开发的效率。
3、统一的运维大数据平台。这种思路通常拿一套大数据架构,日志用ELK或ELG,实时数据分析用fink,监控数据放influxDB等时序数据库,消费中间件用KAFKA……
上述思路我个人觉得没有好坏,需要根据实际情况进行选择。虽然同业中运维数据平台鲜有特别成功的案例,但有几个方向是大家认可的,比如:实时、多源的数据汇集;基于规则引擎、代低码开发的数据开发;异构、海量、实时的数据治理;灵活可配置的算法模型;全域的运维指标体系;数据驱动的应用场景;以关键交付链融合数据、工具、流程;开放的数据服务目录;灵活的数据可视化等。
本篇,主要是找一些有意思的厂商,看看他们对于运维数据的理解,毕竟厂商在专业领域知识的广度与深度都是强于我们用户的,对他们观点的学习有助于我们重新思考有哪些数据,数据能带来什么价值、应该如何获得价值几个问题,帮助我们建立一个更具扩展性的运维数据平台。由于时间有限,厂商的观点主要从项目经历、交流、官网摘录方式,取一些我感兴趣的、与运维数据相关信息,会存在一些我个人认知不足导致的片面理解,如有不对欢迎各位指正讨论。在厂商选择上,我打算从日志、性能、监控、配置、流程、应用系统几类进行小结。
二、他山之石
1、日志
1)splunk
认识splunk,大概在2012年为了提升网上银行系统日志查询处置效率与加强研发查询日志的权限控制,我用splunk做了一个应用系统故障定位项目。总体看,splunk产品一流,但成本很高,随着新版网银日志大幅增大原来的项目模式无法持续下去,后来这个项目反倒在安全团队发挥了重要作用。下面看看splunk对于运维数据分析的一些观点。
splunk提出的关键思想是:Data-to-Everything,即将数据应用于每个问题、决策和行动,用平台消除数据和行动之间障碍。从应用场景看,splunk主要从以下三个方面进行发力:
总的来说,从splunk的解决方案看,日志数据的应用重点围绕:
2)日志易
第一次接触日志易是2016年,选日志易大概基于这几个目的:满足监管要求的日志存储;支持故障及问题排查过程中的日志检索;满足海量日志的性能要求;平衡人力、时间、稳定性、资金成本等。
日志易提出的关键思路:智能日志中心,处理一切机器数据,为企业提供全面业务驱动力。从应用场景看,主要从以下5点发力:
总的来说日志易与splunk是对标的,功能内容与splunk差不多,不过站在当前国情下,日志易与splunk比有信创的明显优势,与ELK比又有人力成本与时间成本的优势。在上面提到日志易强调的5点应用场景上,我认为业务分析是一个亮点,尤其在当前数字化转型价值创造角度,围绕客户体验优化将是运维数据分析的一个方向。日志易对业务分析的理解主要从数据源角度,认为日志作为非结构化数据的一个主要来源,是对现有结构化数据的有力补充,与传统的业务分析数据形成互补,并提出了四点:
3)ELK
对ELK的接触是2017年,因为ELK开源,不涉及项目预算,可以基本0成本的使用。近两年来,随着elastic的上市,以及elastic对中国市场的重视,你可以明显感受到elasticsearch更新频率的加快,市场宣传活动增加,国内代理商增加,当下elasticsearch己成为日志、搜索等技术方案的主流选择方案。可以预测,随着elasticsearch的发展,解决方案的易用性、性能调优将快速提升,商用版本在平台管理、权限等功能将及时得到补齐。对于用户来说,随着国内基于elasticsearch的服务商或产品公司的加入,原来的人力成本、时间成本问题也有望得到较好的解决。
在应用场景上,elasticsearch更强调分布式的搜索和分析引擎,非结构化数据的集中存储,数据分析,数据可视化的基础能力,以及这些能力与企业其它的技术平台的整合能力,在运维数据应用上的观点提出得不多。
2、性能
1)天旦BPC
大概在2015年与天旦做了性能管理项目,与同期POC中其他同类产品相比,天旦在实施周期、已解码范围、产出成效、产品可靠性、实时性能五方面明显高一档次。从目前金融行业运维侧推动的性能管理解决方案的高占有率,也能说明天旦BPC的综合优势。下面的内容不涉及BPC功能,主要看看天旦对于旁路报文数据应用场景的观点(确切的说是2017年以前的观点,17年后的交流较少)。
2)dynatrace
dynatrace是APM领域的标杆,长期占据gartner的APM魔力象限的领导者位置。基于dynatrace的应用性能项目大概是2016年,是研发团队牵头做的项目,我当时参与了这个项目的技术选型支持。总体感受是:东西是好东西,功能强大,价格是限制其在国内市场的主要因素。
与NPM相比,主流的APM是侵入式的。侵入式你也要以认为“一切皆有可能”,即只要埋点足够,对用户行为、业务功能、交易、体验可以有更深度、更广泛的洞察能力。从数据分类看,APM的数据可以应用于应急管理、客户体验分析、性能容量评估、业务协同等。
3、监控
1)zabbix
zabbix作为当前使用最为广泛的开源监控解决方案,有强大的社区基础,扩展性好。不过,我对于zabbix主要是测试环境使用,当时整体感觉是:模板很强大,对于监控覆盖面的持续建设是一件好事;资料很多,其他非监控厂商对接案例很多,基于ZABBIX二次开发的厂商很多;丰富的API,扩展性好;数据库有性能问题(据说已解决);对我来说,界面交互方式不够方便。与上面elasticsearch的开源产品类似,zabbix的官网主要关注性能、功能、扩展性等,对于数据的使用没有提太多。对于zabbix这种监控的性能数据的应用,以下列一下我们团队周光杰对于zabbix的数据应用观点:
2)赞同
赞同的集中监控是我用得最多的监控工具,我经历了它从一个业务系统附带监控工具成长为一个通用集中监控解决方案。因为赞同公司采用“产品+服务团队”的模式,对于现场服务团队客户化响应度很高,这个特点很适合有自己想法,希望监控功能能够有如丝顺滑的使用效果(结合团队特点开发功能)的运维团队。关于赞同的解决方案,我之前写过一篇集中监控的文章,文章里面的内容大概是当时对这个解决方案提出的思路,参见此链接《监控体系建设》,下面讲点文章以外的东西:
3)从ominibus看监控事件管理
我对ominibus的应用起源于使用IBM Tivoli集中监控解决方案,ominibus是netcool事件管理的商业套件。Omnibus是事件处理中心,可按用户要求定制事件结构,包括事件采集、重复事件压缩、事件丰富关联分析或自动处理。netcool在国内金融企业使用十分广泛,我们当时将ominibus作为集中监控系统的统一事件中心的后台模块。为什么是后台模块呢?可能是因为这个模块太久没有更新了,ominibus操作界面还是远古时代交互速度,采用C/S客户端。不过,你不得不承认国外大厂的商业套件极其稳定,设计方案也很简单有效,比如ominibus就使用数据库触发器就将事件的收敛、丰富、关联规则得以实现。因为对ominibus的学习,让我对统一监控事件管理有了第一步的认识,建议对监控统一事件或报警管理研发的同学可以先来学习一下这个经典软件的解决方案。IBM网站对ominibus的相关介绍不多,下面我摘几个国内厂商对统一事件的解决方案。
我的使用经验主要是基于赞同集中监控的统一事件管理,当初让赞同实现统一事件管理初衷主要是为了解决OMINIBUS与CMDB消费改造成本高的问题,基本上也是参考OMINIBUS的主要功能实现一遍,4年过去后,赞同这个模块可能也发生了变化。我简单总结一下监控事件中心的数据对于运行数据分析应用的一些观点:
4)其它
原计划还要多写两点关于datadog、Prometheus的内容,datadog主要是针对监控性能数据采集后的指标化的解决方案,Prometheus是对于云原生平台的监控。担心我观察到的信息不完整,这里先列出两个官网地址:
datadog:https://www.datadoghq.com/product/platform/dashboards/
prometheus:https://prometheus.io/
4、配置管理
1)优维CMDB
国内的运维平台相关氛围大概是从2015年左右开始兴起,再往之前国内的运维领域的企业服务厂商主要以BIG4为主(IBM、BMC、HP、CA)。我的印象中,优维的老王、云霁的智锦、高效运维的萧帮主、还有腾讯的党总、梁总几位大佬是这股运维平台化氛围兴起的几个布道者。对我影响比较大的是老王刚“出道”时那份几百页的《老王的互联网运维理论与实践》,封面如下,相信还会有人记得这份PPT。
上面这份PPT里包括很多运维平台化相关思考与实践,而老王创建的优维对外输出解决方案的开山之作就是devOps与CMDB。单从金融行业看,优维的CMDB在市场案例占比,以及行业内的CMDB厂商的知名度都比较高。在美帝老big4渐渐退出国内软件类企业服务市场舞台,国内运维软件大量涌现但品牌影响力不强的背景下,优维CMDB的这种品牌知名度尤其难得。以下我大概从数据角度看优维CMDB传递的观点:
2)优锘CMDB与架构管理
优锘主打物联网与IT运营可视化业务,是一家很有意思的公司,比如他们官网首页中的广告词“数字孪生可视化运营新世界”、“让人们更的发认知和管理数字化新世界”、“创新、智能、人性、众创”、“让万物可视”等,以及他们LOGO的毛毛虫的由来,眼镜猴吉祥物,优锘的“锘”字涵意等都展示着公司的雄心、人文关怀、产品化与专业化等特点。虽然我没有与优锘的运维产品有过实际的落地项目,但他们公司的很多产品都有让我有眼前一亮的感觉。
回到CMDB话题,优锘的CMDB产品经理孔峰写过一篇关于华为CMDB的文章,我猜应该引导了很多人像我这样的CMDB小白认识CMDB。后来,因为一些有趣的机遇,有幸试用过他们CMDB的产品,所以列举一些从产品中发现的一些优锘CMDB与运维数据关系。
另外,在优锘的产品线上,数据集成与数据处理引擎两个产品应该可以作为运维数据平台的利器。如果运维数据平台可以作为企业数据中台的一个重要组成部分,如何低成本、快速的解决数据集成,落地运维指标体系将是关键。要让运维数据平台能够发挥在客户体验、运营效率方面的作用,快速感知客户、业务、运营等方面的事件,并推动决策执行,将是运维数据平台在企业数字化平台中定位的关键因素。我认为数据集成与数据处理引擎体现出来的事件驱动模式将是一个爆品,尤其是在边缘终端与人机协同的事件驱动应用上的作用,这方面对于优锘在物联网边缘端的应用将是一个有力扩展点。
5、流程
servicenow
servicenow的ITSM产品是行业老大。在运维“监管控析”的工具中,相对的监控、自动化操作等则主要面向物(硬件与软件)与事(规程或流程),ITSM主要是面向人与事。人和事,通常会关注到提升协同效率、控制IT风险、提升服务质量与交付效率三点。servicenow的一些理解在我另一篇文章有介绍,详见:《半个京东市值的servicenow》。这里补充一点关于数据整合的观点。
我们经常看到的ITSM是作为一个独立的流程或服务系统,ITSM向外开放创建、变更工单/服务的接口,servicenow给我的感觉是all in one,即用流程整合协同工作所需的数据与工具,将人、事、物关联在一起。这种区别可能是前者让你感觉是一个流程管理系统,后者是服务管理系统,前者关注过程留痕,后者关注服务质量。以事件管理与变更管理为例,在事件管理中,你所看到的不仅是事件工单的登记,还包括服务台、一线值班人员解决事件所需的各类协同类、故障影响、监控事件、知识库、突发事件管理、性能看板等;在变更管理中,除了变更审批流程,还提供变更成功分数、关联CAB评审会议、变更积压看板、变更影响分析、与devOps关联的自动化变更审核等。这应该得益于,saas产品形态、servicenow全家桶式的解决方案,以及数据的互联互通。不管是itsm的“管”整合“监、控、析”,让“管”被“监”或“控”或“析”来整合,我觉得最终是要抓住运维或IT的软件交付、服务交付、资源交付、项目交付等交付价值链,利用数据将“监管控析”关联在一起,形成场景。
其实,关于servicenow这种ALL IN ONE的感受,或优锘那种乐高拼装的感觉,采用的思路都是一站式、互联互通的思路,我们甲方在运维平台化建设过程中也需要重点关注这个平台化整合的解决方案涉及的技术扩展性。
6、业务运营
此处的业务运营指的是业务运行过程中沉淀下来的数据,比如数据库、内存、报文、日志中留下的交易、客户体验等信息,这方面数据的直接价值最大,但标准化程度最难。从厂商看,性能管理的APM、BPM可以作为一种通用型的解决方案,而在日志、数据库层面的业务运营则更需要甲方同学进行深度挖掘,这应该是SRE或BRE的一个重点方向。
通过对上述厂商观点的分析,我觉得在运维数据平台建设方面重视几个关注:
1、关注数据在运维数字化空间的融合作用。
2、关注提升业务连续性保障、IT交付效率、感知客户体验、产品运营能力的分析能力。
3、关注运维数据治理、运维指标体系的建设。
4、关注运维数据平台在多源、实时、海量的数据汇集能力,与低代码的数据开发,数据开放与输出的平台能力。
5、关注AIOps解决未知问题的数据分析能力。
6、关注数据平台对云原生的平台及应用架构的支撑能力。
7、关注链路、架构关系、业务运营等数据的构建。
8、关注基于数据的事件驱动能力建设。
end。
注:《数智万物下的运维思考》系列的其它内容参见公众号菜单。