街口會員服務的浴火重生
Author
- Kevin Yang
主要負責會員業務相關，「今日的最高表現，是明日的最低標準」，測試團隊秉持著相同理念，才能造就更穩定的產品品質。- ChengChi Hsu
主要負責基礎領域服務，身份由 Intern 變為正職，從對測試領域迷茫到基礎設施的品質負責人，對於穩定服務的交付，責無旁貸。
在 2021 年 7 月，金管會公告電支會員法規（電子支付機構身分確認機制及交易限額管理辦法）正式上路。同時間，街口支付已突破 480 萬的註冊用戶數，如此龐大的會員數，會員相關服務的基礎建設顯得極為重要。那街口支付是如何設計會員模組？新制法規揭露了什麼痛點？身為 SDET 的我們，又該如何確保會員模組在頻繁的迭代下正常運作？
街口支付與電支法規的愛恨情仇
在法規中，將用戶角色區分為使用者及特約機構（商家），再依據審查程序上不同之寬嚴程度，將電子支付帳戶分為三個等級，並且賦予其合法的交易行為及交易限額。
三個等級依權限低至高為：
- 第三類帳戶：僅得付款、儲值及自同機構之直系血親或監護人電子支付帳戶進行國內外小額匯兌之收款功能。
- 第二類帳戶：個人使用者及非個人使用者之電子支付帳戶，得具收、付款、儲值功能。（額度較低）
- 第一類帳戶：個人使用者及非個人使用者之電子支付帳戶，得具收、付款、儲值功能。（額度較高）
街口目前身處於電子支付蓬勃發展的階段，隨著國人交易習慣的改變、行動支付的普及下，相信為了維持市場秩序和保障用戶權益，電支相關法規勢必會持續的進步。
每每在金管會公告新的法規條例、修正條例時，街口都必須在短時間內做出相對應的改動，而經過了這些年的發展，當初設計的架構已然不敷使用，往往都要花費不小的成本來修改會員模組，甚至只能先以 Workaround 來應付。有鑑於此，街口決定藉由電支新制上路作為契機，將會員模組重構，設計出一個高彈性的會員模組，以便在未來能夠以最低的成本應對法規的調整。
會員模組最初的構想
街口支付在 2018 年成為獲得電子支付執照的專營業者，隨即在兩個月內開辦電支業務，要在如此趕的時程內上線，街口沒辦法將會員模組設計得非常完善，只能依照會員模組的使用場景，將用戶身份分為二類，分別是商家戶及消費者；再根據用戶的各項驗證完成與否，「逐級」開放功能。乍聽之下再合理不過的設計，隨著街口規模成長，問題逐漸浮上檯面．．．。
「一個手機號碼，無法同時是商家及消費者」
「商家戶要能使用消費者功能。」
看似簡單的需求，卻花費了巨大的成本來實現。原因在於街口非商家即消費者的設計下，用戶若要同時使用兩種身份功能，在街口端得要註冊為兩個完全獨立的帳戶。然而在法規的規定下，雖然允許用戶有多個電支帳戶，但部分功能需要統一規範，例如交易額度需要共同計算。
為了符合法規，街口決定將此用戶的兩種身份帳戶合併。而要將散落在資料庫中各表的兩種帳戶資料合併，同時又要保留各自的唯一索引值，並且確認既有功能不會受到影響及互相掛鉤，這在開發及測試都是巨大的工程。
「法規分級條件改變時，無法快速配合改動。」
「在街口，註冊帳號就像打怪練等一樣，照著步驟升級來解鎖新功能。」
為了保障用戶的交易安全，街口賦予不同等級的用戶相對應允許的交易行為，而用戶帳戶的等級是透過各項審查通過與否來決定：
- 實名認證 ( Know Your Customer, KYC）
- 洗錢防制查驗
- 金融聯合徵信中心各項查驗
- 金融支付工具驗證
- 門號認證（Mobile ID, MID )
- 取得電子簽章憑證
對消費者用戶來說，要先做完實名認證，升級成法規上的「第三類電子支付帳戶」才能開始做最簡單的付款行為；再通過特定的審查，才能分別升級成「第二、一類電子支付帳戶」，開通轉帳等交易行為。
綜觀以上問題其實都有一個共同點，也就是會員模組之間彼此互相耦合得過於嚴重。常常為了解決某個 issue，卻又造成其他 side-effect，產生一系列連鎖反應，讓維運困難度大大提高。
在新制法規下，著手重構會員模組
接著，來看看新制法規是如何揭露現有的痛點
新制法規：a) 整合電子支付、電子票券法規，新增特約機構（商家）角色
b) 依據角色，調整交易額度類別及限額
「調整交易限額，不就改個 Config 的事？」
如上段所述，商家、消費者合併後，這種會員在舊制法規上是屬於使用者角色，使用同一份額度限額，也就是說消費者的收款額度同時也包含了商家獨有的「代理收付實質交易款項之收款」。
然而新制法規新增了「特約機構」角色，專指商家用戶；並且將商家專用額度獨立出來。這也代表，街口必須把使用者和商家的額度拆分，再依據法規設定不同的交易限額。
痛點：
簡單的調整，卻要觸發一連串的改動。解決辦法：
將業務邏輯抽離底層設計（各交易行為的限額），拆分乾淨。
在這次調整中，不只是需要對商業代收款做處理，而是將各項額度徹底分解開來，並將業務邏輯抽出，使其能在不同的應用場景上依據需求彈性地組合，若在未來法規還有任何額度上的調整，就真的只是改個 config 的事了。
「剛將商家、消費者合併，難道又要拆開？」
才剛結束的商家、消費者合併難道白做了嗎？其實不然，透過上次的修改，便已將商家、消費者的功能明確拆分開來，即便這次法規對商家有不同的角色定義，需要針對其做特定的功能劃分，在街口端也能做到只對用戶的「特約機構」角色做改動，而不與「使用者」角色的功能掛鉤。
然而，透過這次新制法規，街口也認知到僅僅是將功能拆分還不夠，勢必得對會員身份做優化。
痛點：
由上方的「商家、消費者合併」案例來看，要在既有模組下調整「身份架構」，絕非易事。解決辦法：
將會員身份重新定義，根據業務需求，以法規的角色組合成街口端的會員身份。
新制法規：c) 強化電子支付機構身分確認機制，比照銀行數存帳戶分類
「不再是打怪練等，而是搜集條件解成就！」
因應第三類數位銀行帳戶（數三帳戶）不能做轉帳的限制，電支法規要求數三銀行帳戶不能作為金融支付工具來做驗證。也就是說，綁定數三帳戶不能升級為「第二類電子支付帳戶」。在最初的設計下，街口沒有針對銀行帳戶類型做判斷，而為了符合法規，必須得將舊有的升級機制做調整；每每在升級機制上有改動時，街口只能在升級步驟下添加新的條件，長期下來，造成了維運上的困難。
痛點：
在既有的設計下，當升級相關的法規大洗牌時，街口只能在升級步驟上添加補丁應對。解決辦法：
打散帳戶升級步驟，改以條件式來判斷帳戶等級。
為此，將升級的流程改為：使用者在不同場景下完成不同的審查，街口再以用戶已完成的審查做為條件，來決定其帳戶等級。
這樣可以確保未來法規上升級條件有所調整時，街口的升級機制不會再被步驟制約，而是可以更彈性的組合帳戶等級。
綜觀以上的處理方法，其實不難發現講的都是同一件事：「抽離業務邏輯，模組化設定、條件以及行為」，這樣做不但解決了維運的難度，也大幅降低在每次調整後的迴歸成本，達到以不變（彈性高的架構）應萬變（需求）的效果。
重構過程中，SDET 的應對方式
專案不斷開發，測試跟得上嗎？
隨著街口的事業逐漸壯大，專案也如隕石一般襲來，在專案的快速開發下，因多數的功能必須仰賴會員模組，測試團隊除了驗證新開發項目的正確性外，也要確保與既有的會員邏輯不衝突，那街口的測試團隊該如何應對？
在持續的迭代下，SDET 介入測試的時間點？
街口支付業務範圍逐漸擴大，業務需求不只來得多；同時為了因應市場，常常要有即時得改動。傳統瀑布式開發的階層式交付無法符合街口的需求。因此街口在開發上採取敏捷式開發，目的是將需求量化且拆分成任務，並增加跨團隊的溝通及資訊同步，讓開發團隊擁有「滾動式調整」的能力。
其中對於 SDET 介入的時間點，敏捷式開發強調測試的左移，街口做到在開發人員持續交付的過程中；也同時進行測試，越早發現問題，越能減少後續開發的錯誤。
而要能真正實現測試左移的概念，「自動化測試」也是不可或缺的元素。因此，街口測試團隊設計出高彈性、高擴充性且易維護的自動化框架，（詳細的自動化選型可以參考 link）。
頻繁迭代下，如何減少測試上的重工？
以此次新制法規為例，不只是未來加入的會員要符合法規；舊有會員的帳戶等級、交易額度都需要調整以符合法規。在這樣的情況下，要確保舊有邏輯的改動在「向上兼容」新法規之時，又不會產生預期外的改變。
在快速得迭代下，SDET 只要在已經寫好的測試下依照需求新增測試案例、調整舊有測資，就能讓自動化 cover 業務邏輯的驗證。甚至相關的開發人員也能直接看自動化產出的測試報告來判斷產出的程式是否合乎需求，不必每次都經由 SDET 來逐次驗證。
「測試範圍不但要廣還要深，才能夠確保每個服務的穩定。有鑒於此，自動化測試的價值便體現出來！」
如何將測試做得更容易？
街口的 SDET 團隊，積極建設「測試平台」，為的是要實現一個概念：「測試不只能由 SDET 驅動，甚至是 PM 都能執行測試！」。
藉由以下功能的實作：
- 案例管理：
系統化管理測試用例的總數、健康度，避免無謂的執行。 - 小工具：
將 tool code 可視化操作，降低技術壁壘，針對特定需求創建測資。 - 客製化測試：
讓 user（PM, RD）自訂測試集，將測試的顆粒度降低到「用例」級別。
將測試「平台化」，讓相關人員能針對需求自行測試得到結果，不但能提高開發人員交付測試的品質，更能夠減少 SDET 的負擔。
然而，當阿北不幸出事時…
提供支付服務為街口帶來龐大的會員數（撰文的同時，已突破 500 萬會員數），隨著規模日漸龐大，甚至連凌晨時段都持續有新用戶加入註冊。也正是因為如此，當線上服務發生問題時影響到的用戶可能是上千、甚至是上萬人。
接下來，以「會員實名認證」作為例子分享，串接了多項外部服務的功能，一旦問題發生了，要如何快速揪出問題點。
- 當發現了問題，如何快速定義問題點？
在以往問題發生時，相關人員只得以散落各地的 log 來找出問題點，查看是街口端會員模組出錯，還是各項驗證串接的外部服務異常。而排查問題的同時，線上 issue 的影響時間也在持續擴大。
為此，我們 filter 出實名流程各模組的 log，各別以 dashboard 實時監控機器狀況以及業務指標，並以線上自動報警輔助我們快速地感知問題，加快反應速度，降低問題影響的時間。
案例分享：「系統連線逾時，導致實名認證失敗」
再以前陣子發生的線上 RCA （ RCA 定義請參考此頁面）來分享，街口 SDET 是怎麼在一個服務流程中快速「發現及定義問題」；以及在每一次線上問題中，街口學習到了什麼。
首先，前情提要一下。會員實名認證會通過多項審查驗證，其中不乏需要第三方外部服務提供查驗功能。
過程
- 發現問題
如同上段所述，我們在實名認證流程中各站已設好相關的監控，而其價值也體現在本次線上 issue。
透過 Slack 自動報警第一時間感知到問題的發生，也即時知道問題發生在流程中的哪一個步驟，省去了對每一步驟排查問題的時間，能夠專注於對第三方系統做排查。
- 排查思路
Step 1：藉由已建立好的監控，一收到報警能立刻確認最外層的問題是「特定服務連線數異常」
Step 2：往業務層面與特定服務查看錯誤日誌
Step 3：第三方服務 Tech Support 介入，確認問題點
-> 等待外部資源耗時約末一整天，嚴重擴大線上影響時間
反思
我們做到了快速發現、感知問題，但後續的處理能如何做到更好？
- 在開發時，就要有快速止血的意識：
當服務不可用且無法快速復原時，要如何縮小影響範圍？
這必須在產品設計時就加入止血方案，像是「機器不可用時要如何導流」等等設計。而當線上故障發生時，由業務相關人員（ PM, SDET, RD）判斷影響程度，並針對不可用的業務服務進行止血措施，確保線上服務可用或是部分可用。
- 對於仰賴第三方系統的服務需有應急措施：
我們不可全然相信第三方系統。因此，用到第三方系統的服務都要在最大限度下設置應急開關，當危急狀況發生時，繞過他方系統，維持街口服務的穩定性。
經歷過新制法規的磨練，街口做出快速的調整、精準的開發及嚴謹的品質把關，成就了現在的會員模組。如同標題所形容的，會員模組如同浴火重生一般，不再受限於曾經的框架，而是奠定了街口高適應性的基礎。
市場的生態反映了國人消費習慣的改變，電子支付勢必成為未來趨勢。而身為領導者的街口支付，維持服務的穩定性是我們一直致力想達到的目標，提供可用性4個9， 99.99% 的服務，是街口責無旁貸的責任。
「街口的 SDET 團隊職責不僅止於功能的交付，更在於追求功能服務的穩定性、排查問題點並優化使用者體驗。」
JKOPay SDET Team
2021.11.08
