今天來細看 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/