數(shù)據(jù)開發(fā)流程及規(guī)范
一、背景
在大數(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ā)效率，增加成本與風(fēng)險。
數(shù)據(jù)研發(fā)規(guī)范旨在為廣大數(shù)據(jù)研發(fā)者、管理者提供規(guī)范化的研發(fā)流程指導(dǎo)方法，目的是簡化、規(guī)范日常工作流程，提高工作效率，減少無效與冗余工作，賦能企業(yè)、政府更強大的數(shù)據(jù)掌控力來應(yīng)對海量增長的業(yè)務(wù)數(shù)據(jù)，從而釋放更多人力與財力專注于業(yè)務(wù)創(chuàng)新。
二、數(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)如何準(zhǔn)確地暴露代碼問題與項目風(fē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ù)方案討論：最好是負責(zé)人先溝通一個初級的方案，然后找大家一起討論（可能比直接頭腦風(fēng)暴效率搞，根據(jù)負責(zé)人的經(jīng)驗來討論）；然后找大家一起討論。
技術(shù)設(shè)計評審：設(shè)計評審叫上測試。
設(shè)計評審的原則：評審會議應(yīng)該是設(shè)計方案大家基本認同的前提下，做方案的文檔。
設(shè)計接口：重點準(zhǔn)確描述輸入和輸出。
設(shè)計字段：根據(jù)需求定義字段，并確定字段指標(biāo)和獲取來源，建立數(shù)據(jù)字典。
開發(fā)：開分支，寫代碼。做好測試case的建立，然后自測。
代碼review：叫上測試和一個其他開發(fā)同學(xué)，給出review的結(jié)果。目的是讓其他同學(xué)幫忙review其中的邏輯。
提測：給出提測報告，包括羅列測試點。
上線：提前告知運維，提前申請機器資源，根據(jù)業(yè)務(wù)預(yù)估好CPU、存儲、帶寬等資源。
文檔：開發(fā)完成后，文檔記錄一下流程以及提供數(shù)據(jù)表字段說明，方便重構(gòu)。
數(shù)據(jù)需求流程
各個角色職責(zé)
這個流程針對的是項目是開發(fā)，在項目立項的開始，就需要明確各個角色的職責(zé)，而且需要和多個角色進行配合。作為數(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)存等等。 需要和測試同學(xué)同步數(shù)據(jù)處理邏輯，并將一些邏輯的SQL進行文檔化，方便測試同學(xué)進行單元測試，在交付測試之前，需要對代碼進行自測，以便保障流入到測試執(zhí)行環(huán)節(jié)的代碼達到一定的質(zhì)量標(biāo)準(zhǔn)。同時最好能讓代碼通過配置在不同環(huán)境進行切換，方便測試同學(xué)在測試環(huán)境、預(yù)發(fā)環(huán)境進行測試，測試通過后同一套代碼能夠直接上線。
三、日常數(shù)據(jù)支撐
除了項目式的開發(fā)外，數(shù)據(jù)開發(fā)人員大部分情況下都會面對產(chǎn)品提出來的一些臨時性的數(shù)據(jù)需求，例如拉去一下近半年的銷售情況、用戶訪問情況等等，這部分數(shù)據(jù)支撐不需要后端配合、可能也不需要進行測試，而是在已明確的數(shù)據(jù)指標(biāo)的基礎(chǔ)上，定期或者不定期的提供一個數(shù)據(jù)報表。這部分的數(shù)據(jù)開發(fā)模式相對來說比較簡單和快速，但是也需要明確：
明確數(shù)據(jù)需求模板、常規(guī)需求申請單等等，提供需求單的目的是避免長時間的溝通，特別是已經(jīng)有的數(shù)據(jù)指標(biāo)，只需要讓產(chǎn)品提供一份詳細的數(shù)據(jù)需求單，按照需求單的模版進行提供數(shù)據(jù)即可。模版如下：
指標(biāo)需求中通常會涉及到下表中的約定項，如果需要自定義約定項，可以在自定義格式列進行填寫。
明確需求的指標(biāo)含義，和所需求的字段明細、統(tǒng)計周期、開發(fā)周期等。
四、注意
需求評審?fù)瓿珊螅绻l(fā)生需求變更或者迭代，一定需要提供迭代/變更的需求申請單，或者提供JIRA，避免需求不可追溯。
對于一些重要指標(biāo)的定義，就算文檔中寫了，也要和產(chǎn)品進行確定，例如產(chǎn)品需要近半年的所有銷量，那么要明確這個銷量是否包含退款、是按照成交時間還是付款時間來計算等等。避免數(shù)據(jù)指標(biāo)不匹配，導(dǎo)致二次開發(fā)。
開發(fā)過程中，文檔要規(guī)范，先設(shè)計在開發(fā)，而且在做系統(tǒng)建設(shè)的時候，要有全局視野，不局限某一個點，并不是發(fā)布完成了，就算結(jié)束，代碼開發(fā)完成只是第一步，后續(xù)的文檔建設(shè)、代碼復(fù)盤、數(shù)據(jù)監(jiān)控、數(shù)據(jù)告警、穩(wěn)定性等等，都需要在開始規(guī)劃好。
及時反饋，在開發(fā)過程，不論進行到哪個階段，項目期間每天都需要和前后端同步一下進度，避免延期的風(fēng)險。
故障處理，在程序上下后，可能會因為客觀或者代碼的原因出現(xiàn)一些BUG，不同的故障處理方案不同，但是注意復(fù)盤和故障記錄，避免下次出現(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ā)同學(xué)在問題comments內(nèi)說明無法在規(guī)定時間內(nèi)解決的合理的解釋，并告知該問題具體的解決時間點同時郵件說明。
---END---