在大數(shù)據(jù)時代，規(guī)范地進行數(shù)據(jù)資產(chǎn)管理已成為推動互聯(lián)網(wǎng)、大數(shù)據(jù)、人工智能和實體經(jīng)濟深度融合的必要條件。貼近業(yè)務(wù)屬性、兼顧研發(fā)各階段要點的研發(fā)規(guī)范，可以切實提高研發(fā)效率，保障數(shù)據(jù)研發(fā)工作有條不紊地運作。而不完善的研發(fā)流程，會降低研發(fā)效率，增加成本與風險。

數(shù)據(jù)中臺數(shù)據(jù)開發(fā)規(guī)范旨在為廣大數(shù)據(jù)研發(fā)者、管理者提供規(guī)范化的開研發(fā)流程指導方法，目的是簡化、規(guī)范日常的數(shù)據(jù)中臺管理和開發(fā)工作，提高工作效率，減少無效與冗余工作，賦能企業(yè)、政府更強大的數(shù)據(jù)掌控力來應(yīng)對海量增長的業(yè)務(wù)數(shù)據(jù)，從而釋放更多人力與財力專注于業(yè)務(wù)創(chuàng)新。

01? 數(shù)據(jù)開發(fā)流程?

鑒于對日常數(shù)據(jù)中臺開發(fā)工作的總結(jié)與歸納，將數(shù)據(jù)中臺開發(fā)流程抽象為如下幾點： 需求階段：數(shù)據(jù)產(chǎn)品經(jīng)理應(yīng)如何應(yīng)對不斷變化的業(yè)務(wù)需求。 設(shè)計階段：數(shù)據(jù)產(chǎn)品經(jīng)理、數(shù)據(jù)開發(fā)者應(yīng)如何綜合性能、成本、效率、質(zhì)量等因素，更好地組織與存儲數(shù)據(jù)。 開發(fā)階段：數(shù)據(jù)研發(fā)者如何高效、規(guī)范地進行編碼工作。 測試階段：測試人員應(yīng)如何準確地暴露代碼問題與項目風險，提升產(chǎn)出質(zhì)量。 發(fā)布階段：如何將具備發(fā)布條件的程序平穩(wěn)地發(fā)布到線上穩(wěn)定產(chǎn)出。 運維階段：運維人員應(yīng)如何保障數(shù)據(jù)產(chǎn)出的時效性和穩(wěn)定性。 具體開發(fā)流程 需求：與運營產(chǎn)品討論需求。業(yè)務(wù)方把需求提交到JIRA，并且和產(chǎn)品溝通過。 PRD評審：產(chǎn)品評審PRD文檔。 技術(shù)方案討論：最好是負責人先溝通一個初級的方案，然后找大家一起討論（可能比直接頭腦風暴效率搞，根據(jù)負責人的經(jīng)驗來討論）；然后找大家一起討論。 技術(shù)設(shè)計評審：設(shè)計評審叫上測試。 設(shè)計評審的原則：評審會議應(yīng)該是設(shè)計方案大家基本認同的前提下，做方案的文檔。 設(shè)計接口：重點準確描述輸入和輸出。 設(shè)計字段：根據(jù)需求定義字段，并確定字段指標和獲取來源，建立數(shù)據(jù)字典。 開發(fā)：開分支，寫代碼。做好測試case的建立，然后自測。 代碼review：叫上測試和一個其他開發(fā)同學，給出review的結(jié)果。目的是讓其他同學幫忙review其中的邏輯。 提測：給出提測報告，包括羅列測試點。 上線：提前告知運維，提前申請機器資源，根據(jù)業(yè)務(wù)預(yù)估好CPU、存儲、帶寬等資源。 文檔：開發(fā)完成后，文檔記錄一下流程以及提供數(shù)據(jù)表字段說明，方便重構(gòu)。

? 02 數(shù)據(jù)需求流程 各個角色職責這個流程針對的是項目是開發(fā)，在項目立項的開始，就需要明確各個角色的職責，而且需要和多個角色進行配合。作為數(shù)據(jù)開發(fā)人員，需要協(xié)調(diào)和各個角色之間的交互： 需要和產(chǎn)品評估該需求的合理性，現(xiàn)有技術(shù)棧能否支持該需求，例如：公司想要做個實時數(shù)據(jù)大盤，如果沒有實時數(shù)倉的架構(gòu)，是沒法完成這塊需求。一旦確定開發(fā)，需要協(xié)調(diào)資源，包含開發(fā)資源、設(shè)備資源等等。 需要和業(yè)務(wù)方、產(chǎn)品方評估數(shù)據(jù)可行性，數(shù)據(jù)開發(fā)的數(shù)據(jù)源并不是憑空出現(xiàn)的，需要和業(yè)務(wù)方明確已有數(shù)據(jù)能否支撐需求開發(fā)，如果缺少數(shù)據(jù)，則需要另行規(guī)劃缺失數(shù)據(jù)的抽取方案。 需要自己評估技術(shù)可行性，數(shù)據(jù)開發(fā)可能涉及到數(shù)據(jù)傳輸、數(shù)據(jù)同步、ETL、實時開發(fā)、離線開發(fā)等等，要評估從數(shù)據(jù)源獲取到數(shù)據(jù)展現(xiàn)一套流程的可行性，例如：數(shù)據(jù)源如果為多個地方產(chǎn)出，可能需要從binlong獲取、Kafka讀取、業(yè)務(wù)庫同步、HDFS讀取等等，數(shù)據(jù)輸出也可能到各個地方，例如：mysql、hive、ES、Kafka、redis等等多個存儲，需要在開發(fā)之前確定整套數(shù)據(jù)的流程。 需要確定是否滿足安全與合規(guī)要求，對于一些敏感數(shù)據(jù)如何處理，是一個很重要的組成部分，作為數(shù)據(jù)開發(fā)人員，可能接觸的數(shù)據(jù)比較多，但是哪些數(shù)據(jù)可以展現(xiàn)、哪些數(shù)據(jù)脫敏后可以展現(xiàn)、哪些數(shù)據(jù)不能落地等等，而且在數(shù)據(jù)流轉(zhuǎn)過程中，也要關(guān)注數(shù)據(jù)的安全性，能否落地、能否轉(zhuǎn)存等等。

需要和測試同學同步數(shù)據(jù)處理邏輯，并將一些邏輯的SQL進行文檔化，方便測試同學進行單元測試，在交付測試之前，需要對代碼進行自測，以便保障流入到測試執(zhí)行環(huán)節(jié)的代碼達到一定的質(zhì)量標準。同時最好能讓代碼通過配置在不同環(huán)境進行切換，方便測試同學在測試環(huán)境、預(yù)發(fā)環(huán)境進行測試，測試通過后同一套代碼能夠直接上線。

03 日常數(shù)據(jù)支撐?

除了項目式的開發(fā)外，數(shù)據(jù)開發(fā)人員大部分情況下都會面對產(chǎn)品提出來的一些臨時性的數(shù)據(jù)需求，例如拉去一下近半年的銷售情況、用戶訪問情況等等，這部分數(shù)據(jù)支撐不需要后端配合、可能也不需要進行測試，而是在已明確的數(shù)據(jù)指標的基礎(chǔ)上，定期或者不定期的提供一個數(shù)據(jù)報表。這部分的數(shù)據(jù)開發(fā)模式相對來說比較簡單和快速，但是也需要明確：明確數(shù)據(jù)需求模板、常規(guī)需求申請單等等，提供需求單的目的是避免長時間的溝通，特別是已經(jīng)有的數(shù)據(jù)指標，只需要讓產(chǎn)品提供一份詳細的數(shù)據(jù)需求單，按照需求單的模版進行提供數(shù)據(jù)即可。模版如下： 指標需求中通常會涉及到下表中的約定項，如果需要自定義約定項，可以在自定義格式列進行填寫。明確需求的指標含義，和所需求的字段明細、統(tǒng)計周期、開發(fā)周期等。

04 注意事項

需求評審完成后，如果發(fā)生需求變更或者迭代，一定需要提供迭代/變更的需求申請單，或者提供JIRA，避免需求不可追溯。 對于一些重要指標的定義，就算文檔中寫了，也要和產(chǎn)品進行確定，例如產(chǎn)品需要近半年的所有銷量，那么要明確這個銷量是否包含退款、是按照成交時間還是付款時間來計算等等。避免數(shù)據(jù)指標不匹配，導致二次開發(fā)。 開發(fā)過程中，文檔要規(guī)范，先設(shè)計在開發(fā)，而且在做系統(tǒng)建設(shè)的時候，要有全局視野，不局限某一個點，并不是發(fā)布完成了，就算結(jié)束，代碼開發(fā)完成只是第一步，后續(xù)的文檔建設(shè)、代碼復盤、數(shù)據(jù)監(jiān)控、數(shù)據(jù)告警、穩(wěn)定性等等，都需要在開始規(guī)劃好。 及時反饋，在開發(fā)過程，不論進行到哪個階段，項目期間每天都需要和前后端同步一下進度，避免延期的風險。 故障處理，在程序上下后，可能會因為客觀或者代碼的原因出現(xiàn)一些BUG，不同的故障處理方案不同，但是注意復盤和故障記錄，避免下次出現(xiàn)相同的BUG。 故障等級定義：P0?：

1.全局問題，影響所有用戶，例如系統(tǒng)必現(xiàn)崩潰，主要功能不可用，嚴重影響用戶正常交易。2.涉及到用戶資金損失的問題。解決時間：2小時內(nèi)。反饋時間：0.5小時。反饋方式：comments自動郵件方式+即時通信：例如QQ\微信\釘釘\電話 P1：1.全局問題，影響所有用戶，例如系統(tǒng)次要功能不可用，系統(tǒng)偶現(xiàn)崩潰且崩潰率超過50%。

2.局部問題，影響超過20%的用戶，例如系統(tǒng)主要功能不可用，系統(tǒng)必現(xiàn)崩潰。解決時間：待定不過夜。反饋時間：1小時。反饋方式：comments自動郵件方式+即時通信：例如QQ\微信\釘釘\電話 P2：1.局部問題，影響用戶10%-20%，例如系統(tǒng)次要功能不可用，或者系統(tǒng)某一個邏輯不可用，系統(tǒng)崩潰率20-50%。解決時間：待定48小時。反饋方式：comments自動郵件方式。 P3：1.局部問題，影響用戶10%以下，例如系統(tǒng)次要功能不可用，系統(tǒng)部分邏輯不正常，僅在某一單一機型或單一用戶出現(xiàn)的問題。解決時間：待定下個版本發(fā)布。反饋方式：下個版本的需求計劃中體現(xiàn)。 P4：1.系統(tǒng)文本錯誤，系統(tǒng)樣式錯誤，系統(tǒng)交互友好性等不影響用戶正常使用的功能。（包含全局性質(zhì)）解決時間：下個版本上線時。反饋方式：下個版本的需求計劃中體現(xiàn)。 注意：P0\P1級別問題在規(guī)定時間內(nèi)無法解決的，需要該問題的研發(fā)同學在問題comments內(nèi)說明無法在規(guī)定時間內(nèi)解決的合理的解釋，并告知該問題具體的解決時間點同時郵件說明。