作者：陈荣耀阿里云全球技术服务团队
数字化时代，企业希望借助数字化的技术能力来提升企业的经营能力，从最终业务目标上来看，一般分三类：
1.增加收入：基于经营数据的智能分析来提升产品竞争力，更快速的产出产品创新；
2.降低成本：通过对资源的盘点分析，性能的优化，降低资源成本，通过企业内建立管理制度和标准，降低人力管理成本；
3.减少损失：一种是基于数字的反馈，不断的优化用户体验，减少客户流失，另一种是通过采集全域的数据并加以分析，降低生产链路的故障风险。
为了帮助企业实现这些业务目标，衍生出了许多新技术，云厂商往往也会向客户介绍各种高精尖技术和解决方案。但现实是，很多企业在数字化转型的过程中会感觉到效果并不明显，或者说企业并没有“用好数”，这里面的问题点在哪？个人觉得有以下几个主要挑战：
做数字化转型，首先需要组织层面启动数据驱动的文化建设，并明确定义出可数字度量的业务目标。企业的业务决策需要依赖于数字，需要不断提升组织中人员的数字素养，需要让组织中的各类人员具备基础的大数据知识、数据分析知识、统计知识，具备通过数据向其他人传达信息的能力。
企业中围绕数据有很多的角色，各个角色之间存在较大的知识鸿沟。比如对于数据科学家，他们擅长从数据中挖掘价值、创建模型，但将模型投入生产的经验往往不足，比如代码的版本控制、测试、文档等等，缺少端到端的技能来生产数据产品并获得反馈，而对于数据工程师，他们比较擅长数据管道的搭建，但对于数据如何被使用，如何产出最终的业务价值往往不太清晰，因此在数据工程师和数据科学家之间往往会出现一些分歧。
企业想要“用好数”只制定长期的战略并依赖于产品的技术能力是远远不够的，亟需一种战术指导思想，指导企业如何围绕数据链路，从全局的视角去保障数字化战略的落地，提升组织的数字素养，打破技术和知识的鸿沟，优化数据架构，保障数据服务的连续性。
业界各厂商对于DataOps有着不同的理解：
IBM：IBM将DataOps定义为DataOps是人员、流程和技术的有机结合，用于快速向数据公民提供可信的高质量数据。
Gartner：DataOps是一种协作性的数据管理实践，专注于改善整个组织的数据管理者和消费者之间的沟通、整合和数据流的自动化。
DataOpsisanagileandcollaborativedatamanagementpracticefocusedonimprovingthecommunication,integration,automation,observabilityandoperationsofdataflowsbetweendatamanagersanddataconsumers.Thegoalisoperationalexcellenceindatadelivery.
Wikipedia：DataOps是一套实践、流程和技术，它将综合的、面向流程的数据观点与敏捷软件工程中的自动化和方法相结合，以提高质量、速度和协作，促进数据分析领域的持续改进文化。
中国信通院：数据研发运营一体化（DataOps）是一种面向数据全生命周期，以价值最大化为目标的最佳实践。聚焦于协同从数据需求输入到交付物输出的全过程。明确研发运营目的，细化实施步骤，在价值运营、系统工具、组织模式、安全风险管理的支撑下，实现数据研发运营的一体化、敏捷化、精益化、自动化、智能化、价值显性化理念。
DataOps业界目前尚缺少统一的、细化的定义和实践，本文将结合个人近期的学习，谈下个人的看法。希望可以抛砖引玉，让大家对DataOps有个初步认识。
首先DataOps的Ops是很容易被混淆的一个概念：
错误：Ops在当前语境下并不是运维的意思也不是操作的意思，DataOps在当前语境下不是指基于数据挖掘和分析后去运维业务系统或PAAS平台。
正确：Ops指的是运营，DataOps指的是对数据的运营，即如何让数据为业务发挥更大的价值。
DataOps的目标个人觉得可以这样定义：更快速的交付更高质量数据
具体来说：
建设组织文化：重视数据文化的建设，为企业定制如何用数的组织设计建议，帮助企业明确数据战略的业务目标，提供提升组织人员数字素养的培训课程。
填补技术鸿沟：聚焦数据的流向，而不是单项技术或组织功能，定义出完整的数据技术大图，提供各个数据模块的咨询服务，横向去连接各个数据产品和服务，为企业制定最优的“用好数”技术方案，填补技术鸿沟。
填补知识鸿沟：基于数据技术大图，明确定义出组织内各个数据角色需要的知识地图，提供数据链路上各类数据标准和规章制度的建议，为组织培养“T”形人才，填补人员的知识鸿沟。对于数据科学家而言，可以更直观了解到数据管道是如何搭建的，如何自助取数，对于数据工程师，可以更清晰了解数据的用途，这对于他们如何优化数据管道，如何讲清楚管道价值有较大的帮助，也能让工程师和科学家之间互相理解，提升组织协同效率。对于企业管理者而言，高效的数据流有利于更快发掘数据的业务价值。
保障数据连续性：提供如何保障数据生产链路，提升研发效率，降低数据风险的标准，实践和技术方案。宣扬系统性思维（精益思维和敏捷协作），从全局优化整体系统，定制适合的数据产品研发策略。
从目标来看，DataOps是一个很大范畴的理念，技术只是其中一部分，核心是帮助企业围绕“用好数”，聚焦数据链路，构建完整的组织和数据能力。
DataOps的概念本身是从DevOps借鉴过来的，最核心的差异点就是面向的对象不同，DevOps的理念是为了更快的交付软件，而DataOps的理念是为了更快的交付数据。
DevOps改变了软件部署的速度和规模，使得代码可以随时处于可以发布到生产中的状态，为了实现这个目标，DevOps定义了一系列宣言和价值观，业界也沉淀了大量的敏捷能力，比如CI/CD的研运能力、敏捷框架、度量体系、自动化测试等能力。和软件开发一样，数据类的产品也是需要对业务的变化进行快速的反馈，因此DataOps的概念也被提出来。
DevOps面向的角色主要是软件的研发、测试、运维等角色，DataOps面向的角色在前者之上还有数据分析师、数据科学家、数据开发、BI分析师等等，涉及的部门更多，技术栈更多，组织间协同的成本也更高，从这个角度来看，DataOps面临的挑战更大。
有些企业把DataOps笼统的定义为数据域的CI/CD能力或是数据管道（数据集成/ETL/ELT等等），我觉得是不准确的，就像DevOps并不是只定义一个CI/CD能力一样，DevOps核心还是敏捷的开发理念，技术是服务于理念的，是一种上下的支撑关系。同理，DataOps在数据域技术能力之上，更需要的是如何指导组织“用好数”的方法/标准/制度/实践等等。
1.个人与互动重于流程与工具：强调团队间的协作，提倡面对面的沟通，这点和敏捷宣言一致。
2.可用的分析重于详尽的文件：提倡分析即代码，这意味着需要有较好的版本管理，CI/CD，可重用环境等能力，这对数据的基建要求还是很高的。
3.与客户合作重于合约协商：希望和客户建立一个合作关系，而不仅仅只是雇佣关系，DataOps的落地强依赖客户组织的协同，对数据链路持续性的优化，和客户之间其实是一种能力互补。个人觉得未来数据域的合同条款，商务流程也可能会发生变化。
4.实验、迭代以及回应重于大量的前期设计：借鉴了软件MVP版本迭代的模式，引入敏捷的思想进行数据研发。
5.跨部门的营运所有权重于独立的责任：传统企业内数据是一个个的孤岛，每个部门掌管自己的那一部分数据权限，DataOps的核心在于让数据更快的流动，因此提倡在保障安全的前提下，通过流程和机制的优化让数据的权限控制更加灵活。
宣言共有18条，对原则进行了一定程度的拆分细化，感兴趣可以看下。
企业为了加快软件的研发效率往往会有DevOps架构师这样的角色，但当前还没有明确定义DataOps架构师这样的角色，个人觉得DataOps架构师需要具备以下能力：
1.精通DevOps理论；
2.精通DataOps理论；
3.熟练掌握各类数据产品，某几个数据领域需要有较深入的研究，T型人才；
4.对数据流有较深入研究，具备敏捷和精益的思维，具备从全局优化数据链路的技术沉淀；
5.可以帮助企业制定数据战略，明确业务目标，有一定行业经验，有帮助多个企业落地DataOps的实践经验。
可以看到，除了技术能力，DataOps重视制度、规范、标准的制定，重视技术的培训，重视数据链路上不同环节之间数据的互通，交互的联动等等，从全局的视角去提升数据的使用效率，即更快速的交付更高质量数据。
前文介绍了DataOps的理念，要解决的问题和目标，本章重点聚焦在前文提到的DataOps数据技术大图。
强调：数据技术能力并非DataOps的全部，它是支撑DataOps理念的重要组成部分
无论是填补技术鸿沟还是知识鸿沟，最关键的一点是需要聚焦数据链路，定义出最核心的数据能力，将零散的数据能力整合连接在一起，业界有很多组织或个人整理了一些数据链路的架构图，筛选了两个：
在上文一些前辈的基础上，我们对DataOps数据能力做了一些细化，尝试更清楚的定义出数据链路里核心的技术能力，希望可以更好的将我们自研的以及业界一些好用的数据工具有序组合在一起，建立索引，便于企业或个人更快速的找到并学习自己需要的技术能力。
围绕中间最核心的数据流向，整体分成三个部分：数据研发（图中上半部分），数据管理（图中下半部分），数据应用（图中右侧）：
1.数据研发：取好数
数据研发聚焦数据的开发者，对这类角色而言，我认为最重要的痛点是如何高效的获取数据。
在一个项目中往往最头疼的就是如何清洗和搬迁数据，数据进入大数据平台后如何降低建模成本，如何更低成本的拿到自己想要的数据。因此我们将整个研发流程分成数据集成、数据建模、数据开发三个大类，每个大类中又定义了各自的核心能力。
2.数据管理：管好数
一提到CI/CD大家肯定都会想到DevOps：代码版本管理、流水线打包、发布管理等等，其实在数据研发管理的领域也是需要类似的CI/CD能力的，比如我们的内部的数据产品研发时就遇到过以下问题：
版本升级时遇到工作流不适配：新旧工作流中table_id、column_id的拼接规则不一致。
有时候表模型不适配，导致导入任务、加工任务、导出任务失败。公共层、应用层因为字段缺失或者字段类型对不上而报错。
而这类问题往往都是出在研发管理上：
1.代码版本缺乏控制：
a.DDL版本依托于人工上传git管理，但很多时候都维护在本地。无法做到在开发工具上传。
b.DDL版本收版后，因为临时业务需求或者前期探查不全面等问题，需要临时增加一些新的字段、修改字段类型，修改DDL后(繁杂且琐碎)，往往会忘记同步到文档和Git仓库。
2.工作流版本缺乏控制：
a.目前是只有一套最新版本的开发环境工作流，区分不出旧版本工作流。
b.加工逻辑变动频繁。
3.烟囱式开发：大量重复的计算加工，无法设置变量，写函数等。
3.数据应用：用好数
这块的产品比较多，差异性较大，业务价值的出口也是集中在这块，往往也需要结合行业属性进行定开，将数据域技术和行业经验结合才能比较好的落地，本文暂不展开。
3.2数据能力实践：ModernDataStack
在我们内部之前也做了类似的尝试，不过没有这么高大上的名称，我们制定了一些工具的建设标准，可将我们沉淀的工具结合业务场景打包输出去解决一线的问题，工具之间可以互相集成：
主要分成两个应用场景：
数据产品：面向外部客户售卖，将工具能力集成到产品中，降低产品的研发成本，通过产品的打磨，也提升了工具的成熟度。
我们作为研发团队支撑了阿里云GTS内大部分数据域项目的交付，包含数据上云、数据库、大数据、数据中台等等，过程中沉淀了大量工具，为了方便工具的管理和使用，我们建立了“星轨工具中心”进行工具的统一纳管，但工具功能比较零散，总是处于补业务窟窿的状态，显得“东一榔头西一棒”，缺少主线将工具能力串联在一起，技术缺少“牵引”，这在过去给我们带来很多困扰。
在不断的摸索中，我们发现，我们沉淀的工具大部分都是围绕数据链路，去弥补产研和项目需求的GAP，去帮助用户更高效的使用我们数据域的云产品，这和DataOps提倡的聚焦数据链路，从全局提效很匹配。另一方面，我们过去更偏向于建设单点技术能力解决问题，缺少理论的支撑，而DataOps在理论和实践层给了我们很多启发，让我们从全局角度去思考如何构建技术深度，建立行业影响力，如何将技术更好地和业务场景结合，提供整套的解决方案，思考方式从解决问题转向从业务角度去定义清楚问题和度量标准，帮助客户更快地获得高质量的数据，为企业构建更Modern的数据架构。