街口支付線上故障等級定義
線上出故障了～ 阿北，出事啦！
街口支付，身為台灣電子支付領域的領先者，對於線上故障的定責與錯誤分析看得特別的重要。
試想，一旦線上支付服務不可用，使用者對於服務的信任感必定會大打折扣，一般的支付行為，使用者有替代方案或是現金做選擇，但若是使用交通乘車碼即時付款服務，線上服務不可用，被卡在票閘前或是被公車司機說不能下車，當下的處境是有多麼地尷尬。因此，維持支付服務的穩定性是街口一直致力想達到的目標，而提供可用性4個9， 99.99% 的服務，這是街口責無旁貸的責任。
對於線上服務的不可用，一般使用者的感知場景不外乎是不能登入、不能付款、速度很慢、功能難用，但是一旦問題發生時，不僅僅是在當下解決燃眉之急，重要的是，要怎麼在下次問題發生之前防患於未然。在支付領域中，線上每分每秒都有人在付款，今天銀行連線有誤；明天信用卡聯合中心維護；後天資料庫連線數過多，所有的錯誤都會導致使用者無法付款的情形。而線上的故障百百種，總會有輕重緩急之分，依據出現的機率、是否可輕易復現、影響服務層面等種種變因，幫線上故障等級定義後能更快速的定責並針對錯誤進行復盤會議。
故事是這樣開始的，很久很久以前……
在 2018 年 6 月之前，街口支付是沒有測試團隊的，產品的穩定性與可用性主要依賴當時 PM 與 RD，以最快能上線的模式進行設計與開發後，進行基本的功能驗測後，僅確保功能可用則立即上線，雖然使用者能快速的體驗到服務，但這樣的產品品質很容易讓使用者的黏著度降低。做為一間金融科技解決方案提出者的公司，服務的穩定、安全、高效是使用者最重視的幾大因素，但因為產品於 2015 年 10 月上線，在沒有規劃測試團隊之初，線上故障呈現一整個發散、累積的狀況，給當時的產品與開發團隊帶來極大的困擾，又於 2018 年 2 月上線電子支付相關業務，街口一整個焦頭爛額，而測試團隊建立後，顯而易見地，首要任務是必須、立刻收斂線上故障的增長速度。
歷經一、兩個月的業務熟悉與故障確認，街口針對線上嚴重影響的故障列了 RCA (Root Cause Analysis) 的 issue tracker，但整頓的過程中發現線上故障的發生頻率過高，幾乎是一上線就會出錯，或是修 A 壞 B、修 B 壞 C，對於線上故障的修復很容易流於補丁式的修復，服務並未有完善的解耦，因此成效並不明顯。在這樣的前提下，街口的狀態就猶如一輛收資源回收的腳踏車，新的需求正在處理，舊的故障兼著修復，但在 之前的文章 就有提過，身為一間新創的公司，「快」是首要準則，在這種情形下，服務可動，但根本快不起來，線上都是故障的狀態到底該怎麼處理呢？列了 RCA 後，發現了更嚴重的事，在短短的幾個月中，穩定了支付領域的問題後，RCA 的故障數量仍然高達了 60 幾隻且持續增加，因此故障等級的定義的重要性一整個突顯出來！就如同柏拉圖法則 (Pareto principle) 也就是耳熟能詳的 「二八法則」所提及的：「80％的銷售額來自20％的客戶」。若以軟體測試的角度而言，同理，「80％ 的 Bug 來自 20％ 的主要 Feature」，那當務之急就是必須在短時間之內進行統計與分析這些 RCA issue 到底是怎麼來的？各 RCA issue 之間的關係與優先等級為何？能不能透過線上故障的定級快速定位錯誤？能不能以最少的資源 (e.g. 人力資源、時間資源、實體機器資源) 快速處理？
在上述問題已經存在的前提下，試著跳開目前的困境，先思考一下，這些線上故障的定級是不是有先前的一些規則可以先行參考，經過了一陣子的 Survey，我們發現其實始自於 1950 年的美國空軍，就已經有一套行之有年且相對成熟的故障模式影響分析：FMECA (Failure Mode Effects and Criticality Analysis) ，「故障模式、影響及危害性分析」又稱「失誤模式效應與關鍵性分析法」，而該模式本是用來試驗戰鬥機駕駛員彈射裝置失效的機率與發現其主因，經由以負面風險思維反覆測試後，有效的提高美國空軍戰機的性能，FMECA 為風險管理的先驅，主要是在產品設計的過程中，通過對產品各組成的單元潛在的各種故障模式及其對產品功能的影響進行分析，並提出可能採取的預防與改進措施。針對三項分析 (故障模式、故障影響及故障危害性分析) ，簡述如下，若想知道更多 FMECA 的前後今生與應用請洽 Wiki。
- 故障模式：指元件或是產品故障可被觀察到的表現形式
- 故障影響：指故障模式會影響安全性、產品功能的影響
- 危害性分析：故障模式出現的概率及影響的程度結合起來稱為危害性
阿北，RPN 行不行？
FMECA 這分析當中有一參數引起了我們對於故障風險等級定義的共鳴：RPN (Risk Priority Numbers)，風險優先級數。 RPN 為一種分析方式，由嚴重程度值 (Severity, S)、發生頻率 (Occurrence, O) 和發現指數（Detection, D) 相乘 。
RPN = S * O * D
每個的計分是從 1 至 10 分 (當然可依各單位或系統調整計分的區間)，而在此定義下，最高的風險優先級數為 10 x 10 x 10 = 1000，表示這個故障很嚴重、百分百復現、也很容易察覺到。
下方以四個例子說明，同樣都是功能不可用的狀態，但若在尚未定級前以街口的角度而言，只會被歸類在他們都很嚴重，必須立刻被修復：
街口遭受異常流量攻擊，基本功能與交易完全不可用 (2h30m)
第 1 個例子，「嚴重程度值」在功能完全不可用的狀況下以 10 分計，「發生頻率」在攻擊的當下復現率 100%，因此也以 10 分計，「發現指數」考量到根本無處可知被攻擊的時間點，這部份以 1 分計，乘積分數為 100 分。
更換錯誤街口憑證，App 基本功能與交易完全不可用 (15m)
第 2 個例子，「嚴重程度值」在功能完全不可用的狀況下以 10 分計，「發生頻率」在更換完錯誤憑證的當下復現率為 100%，以 10 分計，「發現指數」的判斷為，當下是人為在更換憑證，因此人為失誤是絕對可以被避免的，因此以 10 分計，乘積分數為 1,000 分。
簽發街口的授權單位憑證過期，基本功能可用但部分交易不可用(6h12m)
第 3 個例子，「嚴重程度值」在交易部份不可用的狀況下以 5 分計，「發生頻率」的復現率為部份使用者，定級後以 5 分計，而憑證是否過期，只要確保排期有正確更換，應該也是可以被避免的，因此「發現指數」以 10 分計，乘積分數為 250 分。
街口綁定載具功能，所有使用者都無法使用 (7d)
第 4 個例子，「嚴重程度值」在綁定載具功能不可用的狀況下，業務優先等級低於支付，以 3 分計，「發生頻率」的復現率為所有使用者，以 10 分計，載具綁定功能不可用「發現指數」在發布前回歸測試時應該要被發現，因此以 10 分計，乘積分數為 300 分。
透過 RPN 的套用，可以很明顯的區分出風險優先級的排序：第 2 個例子 (1000) > 第 4 個例子 (300) > 第 3 個例子 (250) > 第 1 個例子 (100)，但真的是如此嗎？
其中上方的計算有兩個盲點，其一，FMECA 的應用，原意是應用在產品設計的過程中對於組成單元 “潛在的” 故障進行分析，同理，RPN 的應用並不適合被應用於目前在線上發生問題的定責，另外，所謂的「發現指數」的定義是在故障發生前有多大的機率被察覺，但 RCA 著重在分析線上發生問題時定位與解決恢復的速度，發現指數的重要性就被弱化了。其二，在發生問題的當下，仍有許多的因子並未被考慮到，故障發生的時段、故障的影響時長、用戶影響範圍、故障對整體功能的影響，因此，RPN 的風險優先級數對於分析在線上已發生的問題在事後進行復盤的定責上是遠遠不足的，再加上有許多主要的流程優先級本來就是最高的，像是街口的「支付」功能一周不可用，跟街口的「綁定載具」功能一周不可用，影響的範圍與嚴重程度明顯不同。
阿北，那街口自己來了喔～
因此，針對這些部份，我們做了一些調整，把「發現指數」的部份移除並弱化在故障發生前察覺的重要性，將 “故障發現所費時間”, “故障定位所費時間”, “故障修復所費時間” 與 “故障驗證所費時間” 的重要因子「時間」加上，將原本的公式改寫成：
JKO RCA Level = S * O * T
依據業務的重要性，在主要流程上加上了「時間」的概念，若該業務的優先級並未劃分到主要流程中，則以 1 分計，而四個例子重新計算後得分如下：
街口遭受異常流量攻擊，基本功能與交易完全不可用 (2h30m)
第 1 個例子，「嚴重程度值」在功能完全不可用的狀況下以 10 分計，「發生頻率」在攻擊的當下復現率 100%，因此也以 10 分計，「時間」部份，支付的主要流程超過四小時內處理完成，以 5 分計，乘積分數為 500 分。
更換錯誤街口憑證，App 基本功能與交易完全不可用 (15m)
第 2 個例子，「嚴重程度值」在功能完全不可用的狀況下以 10 分計，「發生頻率」在更換完錯誤憑證的當下復現率為 100%，以 10 分計，「時間」部份，支付的主要流程在二小時內處理完成，以 2 分計，乘積分數為 200 分。
簽發街口的授權單位憑證過期，基本功能可用但部分交易不可用(6h12m)
第 3 個例子，「嚴重程度值」在交易部份不可用的狀況下以 5 分計，「發生頻率」的復現率為部份使用者，定級後以 5 分計，「時間」部份，支付的主要流程超過四小時不可用，以 10 分計，乘積分數為 250 分。
街口綁定載具功能，所有使用者都無法使用 (7d)
第 4 個例子，「嚴重程度值」在 “綁定載具功能” 不可用的狀況下，業務優先等級低於 “支付”，以 3 分計，「發生頻率」的復現率為所有使用者，以 10 分計，「時間」部份，綁定載具並未被列於主要流程，因此無論影響時間再長皆以 1 分計，乘積分數為 30 分。
透過 JKO RCA Level 的套用，可以明顯且合理的區分出線上故障的等級：第 1 個例子 (500) > 第 3 個例子 (250) > 第 2 個例子 (200) > 第 4 個例子 (30)
而經由以上的規則定義，街口內部亦產生了一故障定級示意的表格，能快速的在發生問題後進行故障定級。將線上的問題定級後，我們就可以根據不同的優先級來定義處理的 SOP，唯有將一再發生的事件標準化、流程化後，才能讓團隊與組織有規則可循。最重要想要告訴大家，街口缺人啊！不徵才是不行D！再麻煩大家了 歡迎投遞履歷 😎😎😎，感謝。
JKOPay SDET Team
2021.04.18
