今天来细看 DataOps 的原则，尽量会搭配过去实作的经验一起做说明。

1. 持续地满足客户需求

我们最优先的任务是透过及早并持续地交付有价值的分析洞察来满足客户需求，频率可以从数分钟到数个星期。客户就是神，没有客户就没有我们的存在，所以满足客户需求是重要的。再来就是需要「持续」地交付价值，不是透过漫长的前期准备，而是小步快跑、持续交付。

2. 有价值且可用的分析

我们相信主要衡量资料分析成效的指标为：具洞察力的分析被交付的程度，包括正确的资料、顶级可靠的架构与系统。可用的分析并不如想像中容易产生，不只需求面要明确、也需要在资料面、分析面都相互配合才有机会产生。

3. 拥抱变化

竭诚欢迎改变需求，甚至已处开发後期亦然。敏捷流程掌控变更以维护客户的竞争优势。我们相信最有效率、有效、以及最敏捷与客户沟通的方式为面对面的交谈。需求靠文件真的谈不清楚，特别是资料产品的需求往往就算见面谈也不见得清楚，往往需要透过一来一往的沟通和讨论才能逐渐厘清。

4. 这是团队运动

分析团队将具备多重角色、技能、工具以及称号。最近一篇 Reddit 上有人正在讨论资料团队的结构（https://www.reddit.com/r/dataengineering/comments/pr9227/data_teams_structure/)，直接跟 Data 相关的角色就包含了资料工程师、Data Modeler（看起来是做 OLAP Cube 的角色）、资料分析师、资料科学家等，如果在把跨部门的团队涵盖进去的话，也需要将需求端以及 IT 纳入分析团队中一起协作。

5. 每日互动

客户、分析团队与维运必须在专案全程中天天一起工作。承上，在专案过程中往往需要频繁的厘清需求、交换意见、讨论细节，每日互动必不可少。所幸现在协作工具非常方便，可以透过这些协作工具让大家 on the same page。

6. 自组织

我们相信最好的分析洞察、演算法、架构、需求与设计皆来自能自我组织的团队。倒也不是自组织是万能的，但对於资料产品来说，由於牵扯到的角色和技能太多，很难有一个人能从头到尾掌握所有事情和细节。让团队成员参与更多专案细节、并让团队能透过自发性的讨论、组织来讨论需求与决定设计，资料产品才有办法推动的更顺利。

7. 减少英雄主义

对於具备深度及广度的分析洞察需求持续增加，我们相信分析团队应该致力减少英雄主义，并建立永续且可扩张的资料分析团队及流程。的确有少数的英雄能够自己 cover 资料产品生产中的各个阶段，但不管怎样英雄时间有限，没办法应付所有需求，永续和可扩张性是需要一直思考的议题。

8. 回顾

分析团队应该透过来自客户、团队本身、及运作数据的回馈，定期的自我回顾来优化运作效能。作为知识产业的一份子，持续学习、持续成长已经算是义务，可以透过定期回顾（例如 Scrum 的回顾会议）来优化团队效能。

9. 分析即程序码

分析团队使用不同的工具来访问、整合、建模、以及视觉化资料。基本上，这些工具都会产生程序码以及设定档，以此来描述操作资料的动作来交付洞察。很多分析师对於程序码(不管是 SQL 还是 Python 或 R)的维护和版本控管的概念不是很熟悉，常常会发生分析程序一给别人用就跑不出来的状况。为了让分析程序更容易被维护以及使用，需要将分析视为程序码来管理。

10. 编排协作

资料、工具、程序码、环境及分析团队自始至终的编排协作是交付分析的成功关键。当参与的人越多，整体的协作也越重要，不只是程序码的协作，还包含了讨论、规格文件、资料等等层面。

11. 可再制的结果

可再制的结果是必须的，因此我们可将任何事情做版本控管，包括资料、低阶软硬体的设定、程序码、以及在工具链上各工具的设定。分析是一种科学，科学就讲求可以再制的结果，只要资料和程序没有变，就应该会产生出相同的结果。为了达成这个目标，资料产品的各个阶段都需要可以被版控。近几年来资料版本控管的工具也越来越多、越来越成熟，也逐渐成为资料产品管理上必备的工具。

BDT: https://github.com/dbt-labs/dbt

12. 抛弃式的环境

我们相信让分析团队的成员有个容易创建、独立、安全、可抛弃、且与生产环境相同的技术环境，并且将其成本最小化是很重要的。程序从开发到部署之间最大的问题之一就是环境的不一致。很多人会在自己的电脑或环境上装了一堆套件来分析资料，但没办法区分哪个分析专案有用到哪个套件，这会造成之後部署到测试以及正式环境上的潜在问题。

(https://www.docker.com/)

Docker: https://www.docker.com/

13. 精简

我们相信持续关注技术优势及良好的设计有助於敏捷；如精简 ─ 最大化未完成的工作量之技艺 ─ 一样根本。

KISS 法则(https://en.wikipedia.org/wiki/KISS_principle)不管套用在架构、程序、还是分析图表都适用。

14. 分析即生产

分析流程如同精实的生产线。我们相信 DataOps 的根本精神之一为专注於程序思维 ─ 达成持续且有效率的生产分析洞察。在开发资料产品时，即便是分析报表都应该要想着後续如何上线以及维运，才能降低开发与部署之间的落差。

15. 品质为一切

建立好的分析流程应该具备的根本能力为自动(自働化)侦测异常，这些异常包括程序码、设定档、以及资料。并且应该能持续地提供维运人员回馈来避免错误发生(防呆)。承上，资料在分析与验证的过程中会发现有很多资料的细节和领域知识，像是特徵值的值域、每日资料总量、甚至某个期间内资料使用者呈现的特殊行为。这些领域知识都不是其他维运人员甚至其他分析师知道的。不同阶层资料产品的开发者需要定期将自己的观察与发现跟其他人分享，才能确保各个资料产品的品质一致。

16. 监控品质与效能

我们的目标是有效能以及品质的指标，这些指标可以被持续的监控来侦测无预期的变化，并且产生运作数据。

17. 再使用

我们相信生产有效率的分析洞察的根本面向在於避免个人或团队的重复性工作。资料产品开发者常常会陷入严重的重工，像是每个分析师一拿到资料就会做基本的资料观察、检查偏差值、资料趋势等等。如果有一些通用的品质监测报表会多少避免团队的重工。

18. 改进迭代周期

我们应该减少将客户需求转换成分析想法的时间以及负担：在开发中建立它，以可重复的生产流程来发布，最後再重构及再使用该产品。回到第一点，「持续」地满足客户需求，越快跟客户取得回馈，就能加速资料产品的开发，因此减少迭代周期就成了改善的重点。

希望以上的介绍能够让大家对资料产品与 DataOps 结合能有更深刻的概念。

References

https://dataopsmanifesto.org/en/
https://iceberg.apache.org/