在这个数据作为市场要素之一的时代，数据已从理念上的资产认同逐步走向实践上的深入行动。单从经济利益上去评定数据的资产化价值，我认为太狭隘，把数据仅仅作为有形物品去交易，价值的发挥未免太过局限。我家那一亩三分地种的红薯，直接拿出去卖是赚不了几个钱，却可以把那几头小猪仔养大，再拿出去卖票子；猪儿还不一定非要拿去卖，自个儿宰了吃，其实也不错啊。
面向业务数据的治理已持续了几十年，DAMA在1988年成立了。运维在最近这10年，借助xOps这一股一股的大风，热度逐年递增，哪里都有Ops的存在。运维的存在感不断增强，业务要创新、要数据治理，运维要智能化，运维数据也就浮出水面，得到越来越多的讨论和探索。
要治理运维数据，首先得重新认识运维数据。从这些年的实践总结和探索研究上来看，我认为运维数据具备以下8大特征，与业务数据相较而言，有比较大的差别。
1 数据种类多
运维为了保障业务的稳定、安全、高效和低成本的持续运行，也是煞费苦心，涉猎众多，运维数据大致包括性能数据、日志数据、配置数据、作业工单数据等等。如果是业务数据，可能类似地这样来划分，比如客户信息、会计记账、客户信息、授信交易等。
2 数据结构异构
数据从自身结构上分类包括结构化数据、半结构化数据和非结构化数据。结构化数据好理解，可大颗粒的认为凡是用关系型数据库存储的都是，在半结构化上如XML、JSON等方面也有，而非结构化的如视频、图片、文档等方面不同行业有所区别，如安平行业，视频及其图片是个重头。
3 存储方式多
正式因为数据结构异构，以及面向的业务场景各有侧重，为了保障数据的高效率交付和使用，对应的会使用不同种类的数据库。运维的数据库和业务的有点不一样，从管控严格度、技术统一性、商务策略、技术栈、团队等方面还会在同一个组织中呈现出五花八门的情况。
4 跨技术栈
运维像个保姆，把业务/应用视为孩子，这些孩子的吃吃喝拉撒都要去呵护。孩子的吃住（数据中心、基础设施、中间件、数据库、负载均衡等）、健康（故障的发现、定界、定位、恢复、回溯）、教育（混沌、高可用、预案、演练等）等都要全方位考虑。运维不得不具备十八般武艺，不管孩子是不是自己的、在哪里，从IPDS各层全覆盖。
5 数据量庞大
运维数据可以说绝大部分都是观测数据，日夜不停、高频产生和采集的性能数据、日志数据和调用链数据，与业务数据相比有过之而无不及。为了监管合规，日志数据来不来就保存个一年半载的，性能数据保存个1个月，肚子都快撑爆了。
6 及时性要求高
运维数据不仅量大，还要求几乎实时。比如监控的数据得及时吧，金融业常常提出x-x-x的目标。如1-3-5，表示1分钟发现故障、3分钟定位、5分钟解决。金融业尤其严格，故障30分钟内未解决的必须上报银监会。为了加快故障解决效率，缩短MTTR，必须全环节优化。
7 价值密度低
运维数据量大、实时，但是大头的观测数据基本上一次性使用的，没有告警那这条数据基本上就可以作废了，中长期保存下来，主要是为了趋势分析、合规审计等。超过一半的运维数据价值发挥，都定格在了时间的刀刃上。好在，运维数据通过数据视角来重新审视和利用，将使得其价值在时间宽度和价值纵深上提高一个层级。
8 行业差异小
谈业务数据治理，往往都是锁定在某些行业，没有那个机构敢说所有行业的业务数据治理他都敢做。所谓隔行如何山，行业的巨大差异都在数据上体现得淋漓尽致。运维数据就不一样了，不管那个行业，大同小异，而金融行业因其体量、复杂度最具有前瞻需求的代表性。
