數據科學家與DevOps工程師相互協作可以獲得更好的業務成果，但了解他們的不同需求是關鍵。

數據科學家與軟件開發人員有一些共同的實踐和需求。數據科學家和軟件工程師都計劃、構建、編碼、迭代、測試和部署代碼來實現他們的目標。對于軟件開發人員來說，這通常意味著自定義編碼應用程序和微服務;數據科學家實現與數據操作的數據集成，通過分析模型進行預測，并創建儀表板以幫助最終用戶導航結果。  

那些尋求自動化，并與運營工程師開展合作的Devops工程師應該擴大其業務范圍，并向數據科學家提供服務。  

擁有多個數據科學團隊的大型組織可能會投資于Alteryx Analytics、Databricks、Dataiku等數據科學平臺，這些平臺提供了用于開發、測試和部署分析模型的混合工具。這些工具在數據集和分析功能、集成選項、治理、業務用戶工具和部署選項上展開激烈的競爭。  

DevOps對數據科學家的要求與應用程序開發人員不同   并非每個組織都對投資數據科學平臺做好了準備，或者可能只需要基本操作能力的小型數據科學團隊。在這些情況下，最好將DevOps最佳實踐應用于數據科學團隊，而不是選擇和使用平臺。  

為此，許多用于軟件開發團隊的敏捷和開發范例可以應用于數據科學工作流程，并進行一些重大調整。雖然數據科學家的流程與開發人員的工作流程類似，但存在一些重要的區別。  

•數據科學工作需要圍繞數據集、模型和配置進行更多實驗。這不是大多數軟件開發商發布管理實踐遵循的簡單計劃、構建、測試、部署周期。  

•開發和測試模型可能無法使用統一的計算堆棧。一些模型可以使用簡單的Python腳本實現，而其他模型可以使用Apache Spark和其他大數據平臺。  

•即使模型處于開發階段，計算需求也會有很大差異。例如，一位數據科學家想要針對一個大數據集測試一個模型的六個變體，與另一位在一個規模較小數據集測試一個模型的數據科學家相比，需要更多的計算能力和存儲容量。  

•部署到生產中的模型也需要持續維護，但除了更改底層代碼之外，還有更多變量。模型還需要使用更新的數據集進行重新訓練、重新配置操作參數以及調整基礎設施，所有這些都可能觸發新的部署。  

•監控數據管道通常需要更復雜的驗證。知道數據操作過程正在運行，并且模型正在處理數據是不夠的。這些工具一旦投入生產，就必須對吞吐量、錯誤條件、數據源異常以及可能影響下游結果的其他條件進行監控。  

•要想取得成功，數據科學家必須與開發人員、工程師、業務負責人合作，這與在應用程序開發中鞏固開發人員和操作人員之間的協作相比，可能是一項更艱巨的任務。此外，許多數據科學家和團隊可能不會向IT組織報告，因此更難為這些組織制定標準和治理。  

在開始采用DevOps實踐和解決方案之前，支持數據科學家需要了解這些和其他差異。  

從數據科學家的經驗開始   與應用程序開發人員一樣，數據科學家最感興趣的是解決問題，他們非常關注配置工具，但對配置基礎設施的興趣往往更少。與軟件開發人員不同，數據科學家可能沒有相同的經驗和背景來充分配置他們的開發工作流程。這為DevOps工程師提供了一個將數據科學家視為客戶，幫助他們定義需求，以及擁有交付解決方案所有權的機會。  

這可以從數據科學家需要的基礎設施開始。他們是用Python、R還是其他語言編寫代碼?他們使用什么工具(Jupyter、Tableau、Apache Kafka和NLTK)進行分析和建模?他們使用哪些數據庫和云平臺作為數據源，用于存儲經過訓練的數據，以及用于部署模型?  

為此，DevOps工程師可以幫助數據科學家選擇和標準化開發環境。這通常可以在計算設備或虛擬桌面上完成。無論哪種方式，將他們的應用程序和配置鏡像到開發環境是與數據科學家進行合作的重要的第一步。  

在此之后，DevOps工程師應該檢查數據科學家存儲代碼的位置、代碼的版本控制方式，以及代碼如何為部署打包。例如，云主機，一些數據科學家對使用版本控制工具(如Git)相對較新;另一些數據科學家可能使用代碼庫，但沒有實現自動化集成。實現持續集成是DevOps工程師幫助數據科學家的第二個方面，因為它創建了標準，并刪除了測試新算法的一些人工工作。  

需要記住的一點是，歐洲服務器租用，某些SaaS和企業數據平臺可能具有內置版本控制，并且不會自然地與為代碼設計的版本控制系統接口。其中許多平臺都有API來觸發集成和部署或其他可以模仿持續集成(CI)/持續交付(CD)管道的機制。