系統之間的數據對接和傳輸，產品經理視角的萬字總結

一個系統裝再多數據，不與其他系統交互，那也是孤島系統。一個系統若很外向，不斷撩撥周圍的系統，也樂意被撩撥，成為了眾系統中的“交際花”，那麼這貨基本就是中台的性質。

而更多的系統是介於上述兩種極端之間的，像人一樣，自己搞生產，也要參與社交——就是系統之間的數據對接。對接的本質是為了實現數據信息的傳輸，在後端產品的世界裏，各子系統之間，或與外部系統之間的對接非常常見。

作為產品經理，不僅要知道數據從哪來，還要理清楚獲取數據之後的握手方式、運算邏輯、異常規則、容錯機制、數據日誌等等。

本文嘗試聊聊如下話題：

• 數據傳輸的場景和意義
• 數據傳輸的方式
• 數據傳輸的處理機制
• 數據傳輸的注意事項

一、 數據傳輸的場景和意義1. 數據傳輸的應用場景

• 前端和後端本身無時不刻的數據互動；
• 公司的各個系統之間的信息共享：比如，式系統部署之後，就需要各個系統模塊之間進行數據的配合，比如訂單系統的庫存扣減數據要同步給備貨系統進行採購；
• 與第三方平台的對接：比如入駐第三方銷售平台亞馬遜之後，店家可能自己需要管理自己的訂單，這時候就要從亞馬遜平台獲取訂單數據，也就是抓取；
• 調用現成的公共插件：避免重複造輪子，市場上很多開放性的功能插件可以調用或接入，比如接入百度地圖的API，接入微信小程序的二次開發。

2. 數據傳輸的意義

• 不重複生產數據庫，避免資源和功能的浪費；
• 統一數據的維護或生產源頭，避免數據不同步：比如同一個公司的兩個系統都要用人員信息架構數據，如果各自都能維護，勢必出現不一致，也浪費資源；
• 別人家的數據，自己沒辦法生產；
• 複用現成的輪子，API或SDK共享（可能自己也發明不出來）。

二、數據傳輸的方式

數據傳輸的方式，作為產品經理我將其分為：接口傳輸、中間件傳輸、message方式傳輸等。散開了説，比如：MQ（隊列）、HTTP接口、otter、文件共享傳輸等，每一種又有細分的方式和適合的場景。

1. 接口

這是一種傳統的問答式的傳輸方式，是典型才c/s 交互模式。相當於一台客户機，一台服務器（注：這裏的客户機或服務器根據數據的提供方和接收方相對而言的，並不一定是實際的）。

目前我們常用的http調用、java遠程調用、webserivces 都屬於這種方式，只不過，不同的就是傳輸協議以及報文格式的區別。

1）接口的作用

通過接口，可以調用成熟的第三方功能插件為我所用（一般就是API接口），也可以根據實際需求由開發寫具體的接口代碼解決具體場合的信息傳輸問題（一般所説的http接口）。

對後端產品經理來説，http接口的使用場景最多。比如：公司先上線了OA系統，後上線了訂單系統，訂單系統需要同步OA系統的人員組織結構信息。那麼一個可行做法就是OA系統創建一個接口，訂單系統請求，獲取最新的人員結構信息。

這個籠統的方案描述中，包含了這麼些信息：創建接口、請求接口、獲取最新信息等，那麼分別是什麼以及有什麼原則呢？下面分別討論。

2）哪一方負責創建接口？

在討論需求的時候，開發會問哪方創建接口呢？有時候產品經理只知道需要建接口，不知道哪個系統來建。可以這樣理解，如果把數據源比成一缸水，那麼接口就像是鑿的一個口，口只能是在缸上面的。所以接口必須是在被請求的數據源這邊，由被請求的一方定義接口。

注意，這裏的數據源是相對的數據源，就是被請求的一方就是數據源方。實際上可能目標數據在請求方。比如例子中也可以是OA系統請求訂單系統，但是如果這樣的話，接口就是訂單系統創建了，因此確切説是被請求的一方創建接口。

通俗的講就像是求婚：男方去求婚帶一百萬，女方接到後就把姑娘嫁過去，這是一來一回。女方也可以去求婚，只是是直接帶着姑娘去敲開男方的門，而後男方才把一百萬送到女方，這也是一來一回。

3）什麼是定義接口

定義接口，其實就是定義缸上的出水口。口的大小、濾網、放水的頻率等…就是個規則。這個規則約定了哪些數據是需要流過去，以及流過去的條件（像門禁密碼一樣）。

定義接口就是設定口令、數據範圍、推送前的篩選、轉化運算規則等，這是接口的核心內容。

4）數據在哪一方做轉義？

某些時候，數據從源頭到應用端不是原封不動的，而是轉化了。比如80分、90分都是及格，可能使用者只需要兩個值：及格or不及格。

那麼這就涉及到是在接收之前就轉化為是否及格，還是接收之後自己轉化的問題。考慮的依據主要是：該數據獲取之後是否還有其他用處，只要有可能被二次使用，最好是取原數據。

提前轉化的好處是，流轉的數據會變得簡單直接。但是需要注意的是轉化後數據量不一定會少，比如：數據源是訂單維度的，而目標是轉化為訂單+商品維度的數據，這就可能一條變多條了。

5）是主動獲取還是對方推送

有時候開發還會問是對方推，還是我們主動去取，這就是接口的post/ get方式問題。

get是從服務器方請求數據，post是向服務器方傳送數據。前面也提到了，接口交互數據可以是主動推送，也可以是請求獲取。

主動推送一般是數據生產方一旦更新，則觸發推送，將所需字段對應值傳遞過去；請求獲取就是數據需求方傳遞請求參數（請求參數一般是若干條件，比如：賬號+密碼）。數據生產方則按照協議響應，給出滿足條件的數據到請求方（也就是返回參數）。

所以可以看出來，如果對時效要求高的，則建議生產方主動推。比如產生一個新用户，那麼就可以理解把用户的信息主動推送給運營方使用。如果是時效不高或者數據量大，則可以按一定頻率主動請求，有利於系統負荷壓力穩定。

在具體使用的時候，如果你對接的系統比較多，那麼建議做一個公共接口，以後誰想用他們自己來對接就好了，不然就要來一個對接一次，麻煩還有風險。

另外，選擇post/ get，最終由雙方開發權衡決定，但是一般而言：get傳送的數據量較小，不能大於2KB。post傳送的數據量較大，一般被默認為不受限制。get安全性非常低，post安全性較高。

6）接口定義是開發的事情，但產品經理需要給出輪廓

在輸出方案的時候，接口定義的規則是什麼？傳參和返回參數是什麼？重複傳參時是跳過還是再次獲取（一般都再獲取）？必傳參數是什麼？是否回傳接收結果給數據生產方？這些都是要有大致明確並傳達給開發測試的。

比如：每小時/次取對方表中第一頁最新的50條數據。超過的數據下個小時繼續取，可以這樣設計：

因為一些關鍵參數牽扯到業務的唯一性維度，這些都在產品經理調研的時候獲知的，而這些可能開發根本不知道，因此產品經理要給出輪廓和大概方向。

7）數據流轉的時效

接口創建之後，如果是接收的對方數據庫中的信息，那麼上線之後，要考慮先進行數據的初始化（保持基礎數據一致），然後確保後續雙方是同步的。

同步的機制和要求是在定義方案的時候就確定的，那麼怎麼確保同步呢？方法是兩種：觸發式和定時任務。

• 觸發式：就是一旦一個參數值滿足條件，則觸發同步；
• 定時任務式：一般用在不知道數據源什麼時候更新，需求方就要設置一個定時任務的腳本，隔一段時間查詢一次，請求的頻率需要與更新的頻率相協調。

8）總結接口的特點

• 優點：時效性強，可以觸發式實時問答。容易控制權限，通過傳輸層協議https，加密傳輸的數據，使得安全性提高。通用性比較強，無論客户端是.net架構，java，python 都是可以的。
• 缺點：服務器和客户端必須同時工作，當服務器端不可用的時候，整個數據交互是不可進行。當傳輸數據量比較大的時候，嚴重佔用網絡帶寬，可能導致連接超時。使得在數據量交互的時候，服務變的很不可靠。

9）相關概念擴展

API：即“應用程序編程接口”，是一些預先定義的函數，無需訪問源碼或理解內部工作機制的細節，即可調用的對象。比如和Windows系統溝通，需要調用Windows提供得API。和新浪微博進行溝通，需要調用新浪微博提供得Api，其實它就是一個軟件系統對其他軟件系統提供得服務。

open api：是指對外開發的接口，比如百度地圖API、facebook的API等。

SDK（“軟體開發工具包”）：可以理解為api的集合，也就是封裝後的API為，功能更完善。

http接口：是基於接口的傳輸方式（HTTP協議）來命名的，當然也有基於其他協議傳輸的接口。

比如：

和Windows系統溝通，需要調用Windows的API（CreateWindowEx, bitblt,等等），是C語言函數形式的接口。

和.Net框架進行溝通，需要調用.Net提供得Api，是以C#，VB函數/類形式的接口。和新浪微博進行溝通，需要調用新浪微博提供得Api，是以Http請求形式的接口。

API接口的叫法相對http接口叫法更籠統和概念化一些。因此在寫方案的時候，http接口和API接口都可以，在具體的場景開發都可以理解的。

2. 數據庫對庫同步

接口完成的是信息的傳輸，相對來説比較保守，易於保護敏感信息。而數據庫同步實際就是表對錶的共享，相對接口就大方多了，因此多發生在企業內部兩小無猜的系統之間。

數據庫同步有這麼幾種辦法：

1）使用中間表

例如：B系統要用A系統的數據，可以新建一個數據庫DB，A系統將數據寫入DB，B系統再到數據庫中讀取數據。

也就是將數據放進一箇中間表中，A、B兩個系統都對這個表有訪問權限，這樣的好處就是選擇性地將一大批數據共享出去。

2）直接調取對方數據表

這個方式就是在B系統在開發時，在代碼中加載A系統的數據表，直接從數據表中取數據。這就是實時拉取對方的數據，B系統自己本地不做表保存。比較省，事但是耦合性較大，數據量大的時候不建議。

3）同步對方的數據表

直接將對方的數據表copy一份過來，並保持實時同步，otter技術就是常用的一個方法。

otte可以將mysql的數據同步至另外mysql或者oracle，也支持雙向同步（即A庫同步給B庫，B庫也同步給A庫）、文件同步等，主要應用應用是多數據中心、BI系統抽取數據、災備。

該方式需要DB協助配置。也就是做了一個mysql的同步平台（帶WEB管理界面），在界面上，你可以定義相應的映射規則，otter進程就會根據你定義的規則讀取binlog，並更新到目標庫中去。

該方式主要用於內部系統之間（一般一個公司的才這樣）庫對庫的傳輸，可以實現數據的相互同步更新。建議應用在數據量大的時候，或者基礎數據對周邊兄弟系統提供基礎支持的時候。優點是佔用資源少，交互更加簡單可靠。

當連接B的系統越來越多的時候，由於數據庫的連接池是有限的，導致每個系統分配到的連接不會很多，當系統越來越多的時候，可能導致無可用的數據庫連接。

這時候otter比較適合。而兩個不同公司的系統，不太會開放自己的數據庫給對方連接，因為這樣會有安全性影響。

3. 文件包共享方式

一些第三方公司為了保密，不願意提供接口，那麼會把文件存在類似網盤或網頁上，供需求方下載。

雙方系統約定文件服務器地址、密碼、文件命名規則、文件內容格式等，通過上傳文件到文件服務器，進行數據交互，對大數據量的也很適合。這就是一種異步的上傳下載機制，雙方的操作割裂開，並且一旦上傳可以被多個需求方使用。

比如：第三方支付公司與需求方約定好SFTP服務器（一種文件服務器，可以理解為網盤）的賬號密碼，然後支付公司將賬單數據上傳到SFTP服務器上，那麼需求方就可以登陸SFTP客户端，進行下載、解析，然後保存使用。這也實現了數據在服務器之間的傳輸。

實際上這些數據本身也是加密的，所以只有協議的公司才能拿到解碼鑰匙。長期合作的公司就會持續更新，授權的公司就可以持續下載和解析。這裏就有一個下載頻率的問題，一般使用定時任務按一定頻率去下載。並且要考慮丟包的機制。

案例：

到SFTP服務器抓取並解析WP支付平台的賬單明細，方案如下：到SFTP服務器找到文件路徑，篩選出需要的類型文件，打開文件，按規則解析所需的字段，對應寫入本地數據表。

腳本執行邏輯：每次抓取路徑下‘修改時間’為前一天的文件。（這裏有個隱患：如果出了故障，可能某天的數據就漏了）。

問題：怎麼防止丟抓呢？

分析：因為是外部數據，所以這裏無法對源數據做“是否被抓取過”的標註，因此建議防丟方案是增加斷抓補抓機制。

斷抓補抓機制：比如4號抓了修改時間為3號的數據。5號斷抓，則6號繼續抓取4、5號的數據。斷抓補抓的機制就是説一旦某一天的數據中斷了，發現不連續，那麼系統就自動在下次重新抓一次，看看是否能補上。直到三次都未取到，則不再補救。

該方案可以降低我方抓取故障導致的抓空情況。有時候開發懶省事不願意考慮這麼多，這時候產品經理要提醒他。

4. 消息隊列MQ（Message Queue）

1）MQ概念

消息隊列技術是分佈式應用間交換信息的一種技術。目前市場上有很多開源的jms消息中間件，比如ActiveMQ, OpenJMS。

簡單説就是一方不斷把信息推到隊列中，像排隊進隧道一樣，另一方依次消費這些信息。消息隊列可駐留在內存或磁盤上，隊列存儲消息直到它們被應用程序讀走。

該方式更適用於公司內部，數據量大，規律性強，批量往來的數據。主要解決應用解耦，異步消息，流量削鋒等問題。

2）以異步處理舉例説明

用户註冊後，需要發註冊郵件和註冊短信。傳統的做法有兩種：

• 串行方式：將註冊信息寫入數據庫成功後，發送註冊郵件，再發送註冊短信。以上三個任務全部完成後，返回給客户端。

• 並行方式：將註冊信息寫入數據庫成功後，發送註冊郵件的同時，發送註冊短信。以上三個任務完成後，返回給客户端。與串行的差別是，並行的方式可以提高處理的時間。

假設三個業務節點每個使用50毫秒鐘，不考慮網絡等其他開銷，則串行方式的時間是150毫秒，並行的時間可能是100毫秒。

因為CPU在單位時間內處理的請求數是一定的，假設CPU1秒內吞吐量是100次。則串行方式1秒內CPU可處理的請求量是7次（1000/150）。並行方式處理的請求量是10次（1000/100）

小結：如以上案例描述，傳統的方式系統的性能（併發量，吞吐量，響應時間）會有瓶頸，如何解決這個問題呢？

引入消息隊列，異步處理，改造後的架構如下：

按照以上約定，用户的響應時間相當於是註冊信息寫入數據庫的時間，也就是50毫秒。

註冊郵件，發送短信寫入消息隊列後，直接返回，因此寫入消息隊列的速度很快，基本可以忽略，因此用户的響應時間可能是50毫秒。因此架構改變後，系統的吞吐量提高到每秒20 QPS。比串行提高了3倍，比並行提高了兩倍。

在設計方案的時候要注意異常情況的處理機制，比如：首次消費失敗？

如果第一次數據消費的時候，無法識別沒有匹配上，但是又想下次再消費一次看是否匹配的上怎麼辦？可以設定機制：無法識別的則重新插到隊列後面繼續推送。

如果一直循環仍消費不掉信息積壓怎麼辦？

設定處理機制：超過一定積壓數據量或者循環時間過長則進行報警。

3）MQ、文件包共享、接口的對比

MQ推送過去之後，是否推送成功無需對方再用MQ返回，因為推到中間站就意味着我方能做的事情已經做完。

而接口是一來一往才知道是否成功的，也就是要返回一個信息。這點與mq是不一樣的。但是如果非要對方再返回是否接受成功的話，那麼就要做反向MQ，這相當於另一個獨立的MQ。

文件包共享也不需要反饋機制，因此傳到了文件服務器之後，數據方的事情就做完了。隊列的一個信息只能被消費一次，不同系統不能共同消費一個隊列。因此如果對接多個系統則要多次創建MQ。而接口可以創建一個，讓其他很多系統調取。

在訂單系統對接各個銷售網站和平台的時候就可以採用這樣的機制，避免多次對接。文件包共享也是可以上傳一次，供多個需求方下載。這點和接口有相似之處，是MQ所不具備的。

5. 其他手段

數據傳輸包含了數據信息的獲取和寫入，其實除了線上的自動機制，還有很多土辦法，在後端產品系統中也是常使用的。

1）導入導出

場景：沒有辦法做系統之間的對接，但是線下能獲得數據。數據量不太大，且有規則數據，則可以通過導入的方式。

文檔一般用csv格式，該格式文件較小，兼容性好，然後需要定義好excel表格對應字段的關係，比如A列對應字段‘name’，B列對應字段’age’。

上傳時需要對文件檢驗，比如格式不對、必填項為空等，建議一旦一處錯誤，就全部不予導入。並返回錯誤提示，修改後繼續導入。

若數據太大（與服務器的性能也有關係，比如超過一萬條），可以採用異步上傳機制，就是上傳之後不立即執行寫入，而是後台自動分批寫入。

2）爬取

作為數據需求方，獲取數據可以通過協商接口的方式、SFTP解析的方式、或者直接爬取的方式。

比如需要獲取第三方網站商標庫中最新商標名稱、註冊地、logo、授權期限等信息，如果該網站不給於開放的接口授權，可能就需要我們開發寫爬蟲代碼爬取（當然有的商業數據也是帶有反爬機制的，這就看誰道高一尺魔高一丈了）。

三、數據傳輸的處理機制1. 數據同步的觸發機制

前面提到了數據獲取的方式，那麼數據獲取頻次或者觸發機制是怎麼樣的呢？這要根據應用場景來設定方案，但是一般都是要求持續獲取的。

一種方式是操作事件觸發，比如頁面的按鈕點擊則觸發傳遞最新狀態。這種的時效性比較高，但是也會由於併發而增加系統負荷。

如果對時效要求不高就可以採用異步機制。比如使用腳本監控。設定腳本的運行頻率，當讀取到更新時間為頻寬內的數據，則將其捕獲並傳輸。定時腳本也叫定時任務等，定時腳本在後端是很常用的。

比如説每次獲取A系統6小時內更新的數據，那麼每2小時取一次的話是沒問題的。但是若每7小時獲取一次就會漏掉1小時的數據。因此一定是每次獲取的數據時間區間，要高於數據獲取的時間間隔。

當然用時間是一種維度，更安全的是用標示性字段。比如每次獲取is_got為0的數據。前台是is_got做表索引（索引前面講到過），這樣遍歷（遍歷約等於全表查詢）數據庫的時候就不會太慢。

2. 是否異步執行數據處理

如果獲取後還要在本地進行規則運算，則最好先落地到中間表，再由中間表寫入最終表，也就是異步寫入。

比如：按照訂單+包裹號維度，從物流系統獲取運費到財務系統，然後財務系統再將其分攤到包裹的商品上面，算出每個商品分攤的運費金額。

這時候就很容易出錯，因為分攤規則是個算法，算法就帶有規則的可變動性。一旦分攤規則的參數不準確，或者算法結構變化，都會導致最終分攤的運費金額錯誤，那麼這時候追查錯誤原因並修復數據就很麻煩。

所以在進行分攤之前，先落地到財務系統的臨時表（中間表）中，然後獲取數據完成，再進行寫入分攤運費的操作。

除了上述方便查錯誤原因外（有種數據清洗的意思），這種異步操作同時也確保了較少的偶聯，不至於一個環節出錯，則聯動出錯。同時它作為一個基礎數據，也可以被其他功能調用。若數據量萬級以上的，必須這樣做。

3. 判重機制

數據通道搭建好之後，數據流往往是持續獲的。而數據源在別人那裏，可能會被增刪改，因此常常有相似或相關的數據進來。在寫入本地表的時候，不管是覆蓋、更新還是插入，都是以確定若干字段做為判重的標示為前題的。

比如職工信息表：（姓名+手機號+性別+家鄉+身份證號）。（姓名+手機號+性別+家鄉）這幾個字段對一個職工不一定唯一，但是身份證號就是唯一的。因此如果我們更新這裏的數據，就以身份證號為唯一標示。

比如獲取到同一個身份證號的手機號與我們的數據庫的不同，則更新。遇到我們的數據庫不存在的身份證號碼則插入。

某些時候無法確定那幾個是唯一字段，則可以添加一個備用字段，人為定義其取值規則，然後作為去重字段，比如這個字段叫unique_code，取數據源表的主鍵+日期，（或者直接就取源表的id，也就是外鍵）。

有了判重字段（也就是數據唯一的字段），就可以進行更新、插入或者跳過規則設定了。

注意：若一段時間之後，改變了表的去重規則，則需要考慮到歷史數據對新數據的影響，因為二者的判重維度不一樣，可能會進來和以前的歷史數據衝突的交叉數據。

4. 獲取到數據之後，如果使用?

一種是直接在頁面展示，不保存在本地數據庫中。相當於每刷新一次頁面則通過接口調取一次對方的數據展示。但這種從性能和場景上都是比較少的，一般都是先保存到本地數據庫上，自己本地各種調用。

對於先保存到本地的情況，有兩個問題要考慮：是否異步保存，和如何確保同源同步。

5. 處理日誌

數據日誌：目的是記錄數據的來龍去脈，追溯以分析問題，日誌要記錄三個主要事項：數據源系統是否提供數據、目標系統是否接收到數據、目標系統是否寫入了數據。

產品經理告訴開發加數據捕獲日誌的時候，需要告知是否存到表裏，因為系統一般都有一個類似緩存一樣的日記，只是會定期清理的，只有保存下來才能一直記錄和追溯。

開發後台本身是有數據log日誌的，因為log4j開源代碼定義了5個主要級別的log：FATAL、ERROR、WARN、INFO、DEBUG，一般情況下，開發都會自覺配置INFO或DEBUG級別的日誌，以方便查數據。

但是代碼中的kog保存時間不會太長，比如一個月就會清除了。因此如果需要保留的時間長，則可以將其保存到本地數據庫。

根據實習需要，存了數據庫就可以做成頁面，展示給用户看，比如可以從以下維度展示：

四、數據傳輸的注意事項1. 目標數據表最好和中間表的維度一致

假設從A系統獲取的數據存入B系統，先落地到中間表b，然後經過一些列運算後將數據從b寫入到b’表。注意b和b’表的去重字段要對應起來，並傳遞下去。因為維度相同，做到一對一，方便實現異常數據溯源。

2. 不同入口寫入同一類型數據時，如何與自身入口的數據去重，且與其他入口的數據互相去重？

案例：有新舊兩個不同的寫入程序，寫數據到利潤表，寫入的都是‘退件入庫’利潤類型，是殊途同歸。不巧的是兩個寫入入口各自有本身的去重規則，彼此去重的規則不能通用：假設入口1對應的去重字段是A+B，入口2寫入的去重字段是B+C。

這就意味着同一個數據如果分多次寫入，有可能從兩個入口都會寫入。如何實現避免重複寫入是核心問題。我們首先考慮的是，如果一條源信息從一個入口已經寫入了利潤表，那麼就不能從另一個入口再寫。

其次，如果從入口1寫入一次，那麼後面源數據更新再次觸發寫入的時候（判重，確定是插入還是更新），就還要從入口1寫。也就是一旦從一個入口寫入，後面該數據的變更觸發的再次寫入也只能從這個入口繼續變更。

只有這樣才能保證這個數據不重複。好比先找到是哪家的孩子，再確定是第幾個孩子，且只能是基於這家內部去確認。

方案一：比如入口1遇到一個待寫入的數據，則先按自己的去重字段A+B校驗。如果發現不存在該數據，則再按照入口2的去重字段B+C（這個事先是知道的）判斷是否存在，若也不存在，則回到入口1寫入。若存在，則入口1不在寫入，且結束進程（因為入口2會觸發寫入該數據的）。

方案二：比如入口1遇到一個待寫入的數據，則先按入口2的去重字段B+C校驗。

查看對方入口下是否有重複數據，有，則本入口不寫（繼續按對方的路徑寫）；無，則自己的路徑寫。顯然方案二的判斷路徑更短，相對好一點。

3. 同步基礎數據的時候是否提前過濾

這個在上面內容中也提到過。比如：A系統維護了員工的基礎信息，其中有個狀態為【是否有效】，只有有效狀態的才能在整個系統中看得到才是生效的。B系統要取用員工信息的數據，但不做數據維護。那麼是否只取啓用狀態的數據到B，還是不區分狀態都取呢？

答案是：在數據量差異不大的情況下，取全量。

原因之一就是，若啓用狀態的用户忽然被A系統禁用，那麼可能該用户在B系統的生產數據報錯，這時候到中間表看狀態就可以看出來問題，而不需跨系統或跨部門溝通查證。

#專欄作家#

唧唧歪歪PM，公眾號：唧唧歪歪PM（ID：jjyypm），人人都是產品經理專欄作家，2019年年度作者。《後端產品經理寶典》作者，藥學碩士轉行互聯網產品多年；熟悉跨境電商業務，醫藥領域；擅長大型後台體系，社交APP。

本文原創發佈於人人都是產品經理，未經作者許可，禁止轉載

題圖來自Unsplash，基於CC0協議