【概要】
本篇是《数智万物下的运维思考》第4章“平台”的第4节“分析平台”第1小节，主要观点有：：
1、在围绕“监管控析”的运维平台有机躯体上，运维数据平台定位为大脑，承担生产环境所有数据和信息汇总、感知、决策、执行、反馈的作用。
2、从日志(splunk日志易elasticsearch)、性能（天旦BPCdynatrace）、监控(zabbix赞同ominibus&优锘&优维)、配置（优维/优锘）、流程（servicenow）、应用运营几类运维数据出发，挖掘对应厂商对运维数据应用场景的观点。
3、运维数据平台考虑以下几个关注：
- 关注数据在运维数字化空间的融合作用。
- 关注提升业务连续性保障、IT交付效率、感知客户体验、产品运营能力的分析能力。
- 关注运维数据治理、运维指标体系的建设。
- 关注运维数据平台在多源、实时、海量的数据汇集能力，与低代码的数据开发，数据开放与输出的平台能力。
- 关注AIOps解决未知问题的数据分析能力。
- 关注数据平台对云原生的平台及应用架构的支撑能力。
- 关注链路、架构关系、业务运营等数据的构建。
- 关注基于数据的事件驱动能力建设
【正文】
一、背景：
在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在安全领域的企业风险管理、安全分析和响应、合规性等方面的分析效果明显，具有开箱即用的易用性。主要包括安全监控、威胁检测、内部威胁、事件调查和取证、SOC自动化、事件响应、合规管理、欺诈检测等。
- 运维/运营：与其他日志工具类似，日志在运维中主要用于实时监控、排障、理解业务，比如在故障应急环节的事中发现中，增加基础设施监控、服务可用性监控、业务监控的日志实时发现能力；在故障应急环节，将日志与监控事件管理（监控事件、ITSM等）整合，来提升故障应急诊断能力，加快恢复效率；在IT服务交付中，将日志与应用软件生命周期（SDLC）整合提升交付效率与质量，比如从日志中获得应用层的链路关系，业务与服务级别的监控，来辅助变更CAB评审。另外，我觉得日志是运维深入了解业务的一个切入点。
- devOps：splunk强调对云原生平台与应用的支持，包括上云迁移、云基础设施、微服务环境监控，服务可用性与性能、Kubernetes平台监控等。
总的来说，从splunk的解决方案看，日志数据的应用重点围绕：
- 提升故障管理：事前的预测，事中的发现、响应、定位、影响分析，事后的复盘；
- 加强性能管理：性能数据挖掘，链路关系发现，性能风险定位；
- 提高协同效率：将日志数据的实时采集、存储、计算、处理、可视化等能力，与现有应急、交付等工作机制结合，将日志数据融入到监管控工具、IAAS、PAAS等平台，提高协同效率；
- 提高安全管理能力。
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年后的交流较少）。
- BPC采用NPM同类解决方案，即将网络层的通讯报文旁路一份，匹配发送与接收的报文，对报文的关键字段进行解码，抽取出“交易量、失败率、响应率、耗时”四个关键指标。基于这个指标模型，向上构建交易链路拓扑关系，向下细化到具体单笔交易请求信息，构建了端到端的业务性能监控与全链路的性能管理。
- 从主要应用场景看。全链路性能管理在应急管理中的事前性能分析，事中监控与故障诊断，事后复盘根因定位四方面有明显的优势，尤其是在当前重要交易系统架构越来越复杂的背景。我个人认为BPC这种针对应急管理的解决方案接下来有如下扩展空间：一是在云原生的容器、微服务，以及业务上下游关系越来越复杂的背景下，结合云原生架构的PAAS平台，推出一些数据类的组件。二是与硬件厂商或主流系统软件（数据库、中间件等）或主流云厂商相结合，形成开箱即用的方案，也许这点对于美帝这种标准化更强的环境优势更加明显。三是性能管理与企业数字化转型的“以客户为中心，重塑用户体验”的价值创造匹配，是赋能运维角色转型的一个切入点。四是抓住信创国产化的浪潮。
- 从数据类型看。BPC使用的是网络旁路报文的数据，这类数据针对的是应用层的通讯数据，我觉得有几个优势：一是补充数据源，原来对于旁路报文数据主要是落在日志，或不持久化，BPC将网络报文实时旁路的方案补充了这个数据空白；二是数据质量较高，巧妙的关联发送与接收报文，形成了交易闭环；三是无侵入，这点对于运维侧推动性能管理优势明显；四是实时且稳定，经验看，网络硬件层面的稳定性明显好于软件层面，性能上BPC在2017年号称是毫码级。
- 对旁路报文数据的二次消费看。天旦在对旁路数据采用积极的数据供应输出态度，与客户的业务应用进行针对性结合，发挥实时、稳定等优势，实现了一些信用卡反欺诈、营销等应用场景。在天旦官网有一个“流芯”的产品，是一个PAAS层的数据输出组件的定位，应该是上面关于数据输出的一个解决方案。
2）dynatrace
dynatrace是APM领域的标杆，长期占据gartner的APM魔力象限的领导者位置。基于dynatrace的应用性能项目大概是2016年，是研发团队牵头做的项目，我当时参与了这个项目的技术选型支持。总体感受是：东西是好东西，功能强大，价格是限制其在国内市场的主要因素。
与NPM相比，主流的APM是侵入式的。侵入式你也要以认为“一切皆有可能”，即只要埋点足够，对用户行为、业务功能、交易、体验可以有更深度、更广泛的洞察能力。从数据分类看，APM的数据可以应用于应急管理、客户体验分析、性能容量评估、业务协同等。
- 在应急管理方面，侵入式的方案可以深入到代码级，对运维来说赋予了定位到代码层面问题的能力。也因为APM是侵入式，他可能比较难像天旦BPC那种有开箱即用的效果。对此，dynatrace作了一些努力，比如他们对主流的开发框架、中间件，以及JVM等在运行时作了代码注入，简化了应用入侵对应用研发带来的成本。我觉得对PAAS平台、数据库，以及行业领域的大厂商（比如银行里的核心、柜面、ESB、呼叫中心、网银、贷款等；券商中的恒生、金证等）、云厂商等标准集成，将更好的向下深入到网络、基础设施，向上深入到代码级的性能问题。
- 在客户体验分析方面，通过对应用性能数据进行建模，结合拨测手段，具有广泛的应用场景，比如围绕客户旅程，分析客户交互行为，客户体验，对终端的客户体验分析建立按渠道、区域、设备、应用程序等性能体验指标，结合客户操作行为数据评估系统功能设计是否合理等。我认为体验分析的效益在数字化转型下值得期待。dynatrace的官网有一个数字化体验管理的产品，提到的一些关键语：“监控、分析并优化您与客户之间的第一次数字化互动”，场景包括：模拟监控、用户行为监控、会话回放、终端渠道监控。
- 在性能容量评估方面，通过对应用性能数据的掌控有助于在IT协作线上建立以数据驱动的跨团队协作模式。为开发、测试及运维团队提供线上真实信息来源，消除孤岛，增进团队配合，持续优化系统性能。
- 在业务运营协同方面，特别业务能看得懂的业务性能数据，可以建立与业务运营的协同，为业务运营提供不同功能使用的数量、频率、性能响应、错误信息、客户行为等运营指标数据，驱动业务提升运营水平，提升运营效能，发现潜在运营风险。
3、监控
1）zabbix
zabbix作为当前使用最为广泛的开源监控解决方案，有强大的社区基础，扩展性好。不过，我对于zabbix主要是测试环境使用，当时整体感觉是：模板很强大，对于监控覆盖面的持续建设是一件好事；资料很多，其他非监控厂商对接案例很多，基于ZABBIX二次开发的厂商很多；丰富的API，扩展性好；数据库有性能问题（据说已解决）；对我来说，界面交互方式不够方便。与上面elasticsearch的开源产品类似，zabbix的官网主要关注性能、功能、扩展性等，对于数据的使用没有提太多。对于zabbix这种监控的性能数据的应用，以下列一下我们团队周光杰对于zabbix的数据应用观点：
- 集中式监控解决方案提供全域的监控指标数据管理。具备对硬件层的网络设备、存储资源、服务器计算资源、操作系统、中间件、数据库、虚拟化、容器，以及应用服务可用性、应用功能等监控数据采集能力，为容量、性能、应急管理、应用运行画像等提供数据基础。
- 在传统集中监控基础上，融合云原生监控。K8S已成为事实上的云原生PAAS平台标准，Prometheus则是K8S应用监控的首选，最新版zabbix已经支持将prometheus运维数据采集通道，未来随着云原生架构演进，关于容器主机、云资源性能、容器状态、集群事件、接口访问调度、日志，以及容器内的业务的监控数据的应用场景，值得期待。
- 丰富的API，打造丰富的协同模式。丰富的API，将为监控管理与其它协同工具打通，实现一个高效的协同模式提供可能性，比如与Jira、企业微信、ITSM、自动化等工具的数据连接，让运维专注运行本身，管理与流程性的标准化大部分工作交由线上化工具实现。
- 基于监控数据的应用是AIOps的主战场。这方面的介绍有很多，可以参见一些AIOps厂商的解决方案，比如必示的这张图：
2）赞同
赞同的集中监控是我用得最多的监控工具，我经历了它从一个业务系统附带监控工具成长为一个通用集中监控解决方案。因为赞同公司采用“产品 服务团队”的模式，对于现场服务团队客户化响应度很高，这个特点很适合有自己想法，希望监控功能能够有如丝顺滑的使用效果（结合团队特点开发功能）的运维团队。关于赞同的解决方案，我之前写过一篇集中监控的文章，文章里面的内容大概是当时对这个解决方案提出的思路，参见此链接《监控体系建设》，下面讲点文章以外的东西：
- 赞同的运维体系围绕“数据运维、智行合一”八个字，其中智（智能化）、行（自动化）、合（数据化）、一（服务化），监控数据重点是在“合（数据化）”。得益于他们对“监管控”落地全家桶式的解决方案，加上围绕运维数据平台中专门打造的运维数据平台、日志、统一事件、可视化工具，从纸面上看，提供了相对齐全的运维数据分析能力。
- 统一的监控性能指标数据。得益于赞同集中监控在OS层及OS层以上的功能、业务监控实现了统一，实现了整个数据中心的监控事件统一，加上围绕监控事件进行了监控事件准确性的持续运营，以及基于生产事件对监控覆盖面的运营，为基于监控数据分析提供了基础。比如年度资源池、定期扩容等涉及的容量分析可以基于OS层的性能指标与监控报警信息；运维应急效能分析可以基于监控事件报警数据进行分析；基于AIOps的应急定位与动态基线，可以基于集中监控的性能与统一监控事件数据；基于CMDB，可以将集中监控指标数据与NPM性能管理、资源层数据等相结合等等。
- 基于业务系统的业务运营指标数据。由于赞同业务系统在银行业中的江湖地位（柜面、网点、ESB、支付、中间业务等占有率较好），理论上这些系统具备吐出业务层级的监控数据，如果能牵起来，你可以认为整个银行运营条线的业务链路管理都可以在一个监控系统中打通，下面是一张在很多年前实现的一个网点终端性能的原型图。如实现这一点，就有了示范效应，基于银行对于厂商的掌控力，进一步丰富其它业务线的业务链路管理是有想象空间的。券商领域的恒生、金证是否具备这个应用方案还得观望他们的开放姿态。
3）从ominibus看监控事件管理
我对ominibus的应用起源于使用IBM Tivoli集中监控解决方案，ominibus是netcool事件管理的商业套件。Omnibus是事件处理中心，可按用户要求定制事件结构，包括事件采集、重复事件压缩、事件丰富关联分析或自动处理。netcool在国内金融企业使用十分广泛，我们当时将ominibus作为集中监控系统的统一事件中心的后台模块。为什么是后台模块呢？可能是因为这个模块太久没有更新了，ominibus操作界面还是远古时代交互速度，采用C/S客户端。不过，你不得不承认国外大厂的商业套件极其稳定，设计方案也很简单有效，比如ominibus就使用数据库触发器就将事件的收敛、丰富、关联规则得以实现。因为对ominibus的学习，让我对统一监控事件管理有了第一步的认识，建议对监控统一事件或报警管理研发的同学可以先来学习一下这个经典软件的解决方案。IBM网站对ominibus的相关介绍不多，下面我摘几个国内厂商对统一事件的解决方案。
- 优锘的MOM（http://www.uinnova.cn/product/tarsier/oic/monitoringandmanagement ）是一个整合优锘可视化、CMDB、架构管理等产品，以及集成其他厂商监管控工具，实现事件集中管理的解决方案。你从优锘的MOM的解决方案中你可以看到几个关于运维数据运用的观点。一是基于事件丰富的数据整合，监控事件与性能的整合外，还包括CMDB、ITSM、自动化等数据。二是与前面提到的ominibus的事件收敛相关能力。三是基于架构管理拓扑数据与优锘领先的可视化能力，为故障诊断赋能。四是将监控性能数据指标化，这点我觉得运维数据平台未来建设重点，事实上数据中台的关键就是指标体系的建设。
- 优维的IT资源监控解决方案（https://www.uwintech.cn/monitor）与优锘的解决方案有一些类似，都是将监控定位为数据运营的解决方案。从与老王的交流情况看，他的观点如下：监控平台是一个数据驱动运营的平台，不能把监控平台做成一个孤立的Monitor系统，而应该是基于数据运营的监控平台。首先，解决数据打通、能力碎片、信息割裂的痛点问题，实现企业所有监控源端工具的性能指标、事件、日志数据整合，形成指标；其次，监控数据指标是对生产运行对象的状态的描述，基于状态描述是一个点，将众多的点整合在一起形成面即是机器画像，以及其它像事件分析、拓扑分析、故障根因分析、容量等运行场景的扩展。
我的使用经验主要是基于赞同集中监控的统一事件管理，当初让赞同实现统一事件管理初衷主要是为了解决OMINIBUS与CMDB消费改造成本高的问题，基本上也是参考OMINIBUS的主要功能实现一遍，4年过去后，赞同这个模块可能也发生了变化。我简单总结一下监控事件中心的数据对于运行数据分析应用的一些观点：
- 基于监控事件管理形成高效的应急处置协同，让运维人员更好的发挥专家经验。将应急管理的事中处理分为异常发现、故障响应、故障诊断、故障恢复四个步骤，监控事件管理是贯穿四个步骤的关键连接。理想情况下，生产故障应该由监控主动发现，并针对故障的自动化或半自动的应急恢复策略。针对这个方向有几个挑战，一是上面这个过程包括了异常发现、故障响应、故障诊断、故障恢复四个步骤，即对监控发现要求就不仅仅是发现异常现象，更重要的是监控需要发现引发异常的源头，才能提供恢复的处置执行策略；二是监控事件对故障的识别率要高，即监控事件的误报率要低，重点涉及到事件的收敛；三是基于监控事件建立高效的协同机制，即能够基于CMDB数据，整合自动化工具、ITSM、协同工具（如IM）、应急预案等工具，让运维人员专注应急恢复；四是复杂的系统架构的应急管理对于上下游链路的可观察性要求很高，事实上一般的故障很多通过“现场经验 已知”的应急方案即可解决，事件管理的亮点应该是对未知故障的辅助决策；五是监控事件与运行对象或服务的运行数据进行整合，让应急人员可以在监控事件管理工具中方便的获得系统实时的运行数据，以便辅助决策，并在应急过程中实时观察运行状况。这五个挑战是监控事件管理建设过程中需要关注的内容。
- 监控事件管理也是AIOps的主战场。目前主流的AIOps解决方案也是在监控事件风暴与准确性、及时性、诊断难三点发力。比如针对事件风暴的动态基线、事件关联收敛、节假日、某些特殊时点等；针对及时性的预测发现，对未知故障或对于非人工阀值的异常发现；针对诊断难的基于事件故障根源分析等。
- 监控事件数据助力事前与事后的管理水平。比如对监控事件数据指标化，针对不同指标反映的问题，可以评估性能、容量、风险等问题；对监控事件数据的分析，提供事后复盘的过程回放，获知客观真实的处理过程与实际业务影响的关联，挖掘一些原来未知的系统与系统之间关联关系，故障处理过程中各团队之间的协同效率等。
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传递的观点：
- CMDB定位运维数据平台的元数据角色。我理解元数据通常是在数据治理领域出现，数据治理中的元数据指描述数据的数据，优维将CMDB定位为运维数据平台的元数据，应该是指描述生产环境基础、应用、拓扑/架构关系对象的属性数据。如果从CMDB的CI（模型）、CI项（属性）、关联关系（架构）在生产环境中具备唯一、关键、可复用的数据特点，我认为CMDB也可以作为主数据来运用。采用数据治理的角度看CMDB，引出了运维数据资产化的问题，即以CMDB为基础，推进运维数据衡量、量化、治理、建模、消费。
- CMDB管理生产环境资源的全生命周期。在数字化转型当下，传统企业的IT效率问题一直是IT团队面临的关键问题，像devOps、敏捷、设计思维等思想主要解决的是跨团队的协同效率问题。站在SDLC（软件全生命周期）角度，运维如何在风险可控的前提下，主动开放出去与研发、测试、产品等团队形成端到端的流程连接，CMDB是一个切入点。即利用CMDB具备的数据采集、自动发现、流程整合、数据加工存储、数据运营、数据消费的技术方案，使IT资源管理具备可观察性与开放性，让运维平台与项目管理、研发管理、测试管理、持续交付等系统关联对接。
- 围绕“应用/业务”是优维将CMDB区别于以往的CMDB解决方案的最大区别。围绕应用/业务角度，恰好说明运维的工程项目要回归IT价值。数字化转型强调的IT价值创造首先是安全可靠、快速交付，才能达到技术引领。从这个角度看，应用配置管理正在为devOps作准备。要达到应用层级的数据，对CMDB的自发现能力、应用交付流程的整合、基于应用配置数据的消费保鲜有更高的要求。另外，随着云基础设施、容器、微服务、分布式等技术架构的演进，将CMDB从传统的主机层向应用层扩展，对应用服务、接口、调用主求、主机、基础设施纵向与横向的链路关系提出了新的挑战。也许，优维的分布式链路追踪方案正在应对这些挑战。
2）优锘CMDB与架构管理
优锘主打物联网与IT运营可视化业务，是一家很有意思的公司，比如他们官网首页中的广告词“数字孪生可视化运营新世界”、“让人们更的发认知和管理数字化新世界”、“创新、智能、人性、众创”、“让万物可视”等，以及他们LOGO的毛毛虫的由来，眼镜猴吉祥物，优锘的“锘”字涵意等都展示着公司的雄心、人文关怀、产品化与专业化等特点。虽然我没有与优锘的运维产品有过实际的落地项目，但他们公司的很多产品都有让我有眼前一亮的感觉。
回到CMDB话题，优锘的CMDB产品经理孔峰写过一篇关于华为CMDB的文章，我猜应该引导了很多人像我这样的CMDB小白认识CMDB。后来，因为一些有趣的机遇，有幸试用过他们CMDB的产品，所以列举一些从产品中发现的一些优锘CMDB与运维数据关系。
- 优锘CMDB是一种水道渠成的产品。优锘的产品化程度比较高，使用做锘的产品你可能都会有使用乐高拼装积木的感觉，要实现拼装需要有关系的纽带，CMDB提供这个关系纽带。另外，作为以可视化为主打的公司，可视化考验中间层的数据建模与上层数据消费能力，随着可视化的演进，很自然的会扩展到最下层的数据层，CMDB是运维领域数据层的中枢，就算没有CMDB产品，解决方案也会有CMDB的模块。所以，看起来优锘的CMDB是从消费侧演进出来的，这从回归CMDB价值创造角度看是极具吸引力的，毕竟CMDB的价值需要从配置消费中产生。
- 对于CMDB产品，该有的数据采集、自动发现、流程整合、数据加工存储、数据运营、数据消费都应该要有，我个人认为优锘的产品亮点在数据运营与数据消费。数据运营是配置数据治理的关键手段，数据消费是CMDB价值创造的关键，这两点CMDB运营过程中最难的环节恰好是这个产品的关注点。
- 在优维CMDB中提到CMDB数据包括：资源配置数据与关系数据。前者是大部CMDB产品关注的配置信息，后者关注资源对象的关系。优锘的架构可视化DMV提供架构可视化管理，我认为不管是部署架构图，还是逻辑架构图，都是由IT资源的点与线组成，这里线即是关系，对应CMDB的关系数据。与优维的分布式关系自发现的解决方案不同，DMV专注关系的灵活、简便配置，以及关系信息的消费使用。至于架构关系自发现好手绘相比好多少，我个人观点是架构关系是IT重要资产，当下手绘架构可以带来的成效可能更快，需要关注的是关系的保鲜。基于DMV带来的启发，我写过一篇关于运维数字地图的文章，见此《IT运营数字地图，连接未来》。
另外，在优锘的产品线上，数据集成与数据处理引擎两个产品应该可以作为运维数据平台的利器。如果运维数据平台可以作为企业数据中台的一个重要组成部分，如何低成本、快速的解决数据集成，落地运维指标体系将是关键。要让运维数据平台能够发挥在客户体验、运营效率方面的作用，快速感知客户、业务、运营等方面的事件，并推动决策执行，将是运维数据平台在企业数字化平台中定位的关键因素。我认为数据集成与数据处理引擎体现出来的事件驱动模式将是一个爆品，尤其是在边缘终端与人机协同的事件驱动应用上的作用，这方面对于优锘在物联网边缘端的应用将是一个有力扩展点。
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。
注：《数智万物下的运维思考》系列的其它内容参见公众号菜单。
