Software Architecture meet Business Requirement

軟體技術架構應該要如何正確與商業需求對齊？很多人有不同的想法，而依據我多年的經驗，不外乎就是質及量。

質與量有很多檢測依據可以評斷軟體技術架構是否符合商業需求，而因為時間與篇幅有限，這裡我先提出兩個最基本的對齊方式。

  1. 質在商業需求就是 SLA (Service-Level Agreement, 服務等級協議)，即公司提供給客戶的服務品質保證。
  2. 量在商業需求就是 MAU (Monthly Activited Users, 月活躍客戶)，即公司商業希望達成的每月活躍客戶數。有些人可能會用 DAU (Daily Active Users，日活躍用戶)。

軟體技術架構與商業需求對齊的目的

對齊其實就是溝通規格。很多軟體技術團隊與商業團隊造成壁壘 (Silo) 的原因，往往在於溝通上出現了問題，然後發生問題後彼此推責。

不管是軟體技術團隊，或商業團隊，都一定要有對質與量的要求。我覺得最基本要做到的，就是：

  1. 公司的服務或產品，在此階段提供給客戶的服務品質為何？這就是質的要求。
  2. 公司的服務或產品，在此階段預設要達到的業績為何？這就是量的要求。

倘若連上述最基本的兩項都沒有規定清楚或對齊，很容易發生：

不管商業團隊有沒有把業績做起來，只要系統有因效能或品質無法支撐所導致服務或產品異常，商業團隊都可以指稱業績不達標的原因，皆因軟體技術團隊的問題，即使實際原因是商業策略或推廣有問題。 反之，倘若商業團隊的業績超標 (超過原本預估的 MAU) 所導致系統服務的異常，也會因為軟體技術團隊當初所進行的溝通是以滿足當初預估 MAU 的架構為前提，也是在符合 MVP 之下的資源投入，所以不會有商業團隊認為這時原本可以做出更多業務為由，來怪罪軟體技術團隊未盡責。

因此，身為軟體技術團隊，也要瞭解所開發服務與產品的商業需求，所以在開發前倘若發現沒有上述的基本要求，軟體技術團隊也應該要請商業團隊提出。畢竟，商業團隊在規劃服務或產品時，若連最基本要達到的 KPI：質與量，都未定義清楚時，顯然商業團隊也有考量不周之處。

這兩點是商業團隊在規劃產品或服務時，最基本的要求。以網際網路產業 (或互聯網產業) 而言，雖然有很多評斷的方式，但這裡我先介紹兩項最基本的：

  1. 質可以是 SLA (Service-Level Agreement, 服務等級協議)，即公司提供給客戶的服務品質保證。
  2. 量可以是 MAU (Monthly Active Users, 月活躍客戶)，即公司商業希望達成的每月活躍客戶數。

上述，要對齊到軟體技術團隊時，需要進行適當的轉換：

  1. 商業團隊的 SLA 可以對齊到軟體技術團隊的 SLI (Service-Level Indicator，服務等級指標)。
  2. 商業團隊的 MAU 可以對齊到軟體技術團隊的 RPS (Requests Per Second，每秒請求量)。

如何將 MAU 對齊至 RPS，以及 SLA 對齊至 SLO

當商業團隊定好最基本的 MAU 及 SLA 後，軟體技術團隊就可以轉換成技術要求的規格。

1. MAU 對齊至 RPS 的公式

RPS (Requests Per Second，每秒請求量) 在技術上有很多類似的名詞，諸如 QPS (Queries Per Second，每秒查詢量) 或 TPS (Transacations Per Second，每秒交易量)。三者有著定義上的不同，更精準的計算有賴引入三者的數值，但最靠近商業團隊所能瞭解的是 RPS (Requests Per Second，每秒請求量)，因此後續我就簡單以 RPS 為例。

倘若商業團隊決定前三個月的服務或產品，預期達到 MAU (Monthly Activited Users, 月活躍客戶) 一百萬。

請問此時的軟體技術團隊，在前三個月的架構規劃，應該如何符合商業團隊的 MAU 需求？

我們先簡單假設，商業團隊定義的 MAU 為客戶在該月於服務或產品有至少點擊五個操作以上，另估計 MAU 與 non-MAU 的比例符合八二法則為 20% : 80%。

則，

  • MAU : 1,000,000 (Monthly Activited Users, 月活躍客戶)
  • non-MAU : 4,000,000 (未計入月活躍客戶的估計量)
  • MAA : 10 (Monthly Average Actions，用戶單月平均點擊行為數，即用戶單月平均在系統點擊的行為次數)
  • ACoA : 5 (Average Calls of Action，用戶每次點擊的平均請求量，即用戶表面上一個點擊行為連帶平均在系統觸發的請求次數)
  • 公式換算法則 : 八二法則

即，

( ( MAU + non-MAU ) * MAA * ACoA * 0.8 ) / ( 86400 * 0.2 ) =

( ( 1,000,000 + 4,000,000 ) * 10 * 5 * 0.8 ) / ( 86400 * 30 * 0.2 ) ≒ 385.8

所以，為了能夠支撐商業團隊 MAU 一百萬的需求，系統必須要能夠承受每秒約 386 次的 RPS。

需要注意的是，採用的公式換算法則很重要，這會影響到最後換算出來的數值。這裡就需要依據團隊或你，在各個特定領域過去的實際或觀察的經驗所累積出來。

以上述為例，若採用的公式換算法則為九一法則：

( ( MAU + non-MAU ) * MAA * ACoA * 0.9 ) / ( 86400 * 0.1 ) =

( ( 1,000,000 + 4,000,000 ) * 10 * 5 * 0.9 ) / ( 86400 * 30 * 0.1 ) ≒ 868.1

兩者相差了 2.25 倍，所以選擇錯誤的公式換算法則，不是讓我們錯估形勢而崩潰，就是讓我們過早投入太多資源最佳化，違反了 MVP。

例如我從事過各種不同的產業，包括製造業、電子商務(電商)、售票網站、數位廣告、機上娛樂、銀行金融、第三方支付、資安服務、博弈娛樂及古典音樂等領域，也長期也觀察許多企業提供的數值來進行倒推，包括阿里巴巴(雙11)、微信紅包 (過年搶紅包) 等。各領域採用的換算法則有所不同，並不一定都可以套用八二法則。有些領域需要使用九一法則、峰值法或超峰值法等。

如此，未來當你處於該領域時，你就可以更準確的套用正確的公式換算法則，更精準換算出所需對應的 RPS。

2. SLA 對齊至 SLI 的公式

SLI 及 SLA 要依據彼此對於服務與產品的需求而定。而 SLI 又與 SLO (Service-Level Objective，服務等級目標) 相關。

舉例，

  • SLI 是，『測量的五分鐘內，首頁請求 95 百分位數的延遲 (Latency) 低於 300 ms』。
  • SLO 則可以是，『整年度，首頁 SLI 的 95 百分位數成功開啟率達到 99.9%』。
  • 最後的 SLA 則可以是，『整年度，首頁 SLI 的 95 百分位數成功開啟率保證達到 99.5%』。可以等於 SLO 或略低，通常實務上是略低。

接下來就是從軟體技術架構的模式，用公式換算出數值。

假設商業團隊的需求是 SLA 為 99.5%，而軟體技術架構如下，

Software Architecture #1

則整體架構的 SLO 推算為：

95% * 95% * 99% ≒ 89.35%

故尚不符合商業團隊要求的 99.5%。

此時有兩種方式改善。除了提高各個服務的 SLI (例如把 Web 提到至 99%) 外，也可以引入高可用性架構 (High Availability, HA)。例如將 Web 引入高可用性架構後，

Software Architecture #2

則整體架構的 SLO 推算，可以從原本的 89.35% 提升為 93.81%。

當然，不管採用何種方式，都需要投入資源來換取。倘若商業團隊一開始有著很高的 SLA 期望，此時軟體技術團隊也可以依據提供符合該架構的成本考量，這些都是經過合理的數學模型計算，絕非盲目猜測，可以有效提升彼此的信任感，促進溝通。就視最後商業團隊與軟體技術團隊共同決定，初期願意先調低 SLA，還是要依據有理有據的公式來投入較多的資源來滿足 SLA。

想要更高的品質，自然就要投入相對的資源。

補充：如何進行有效的 RPS 測試

效能測試基本有三項指標：

  1. 效能測試 (Performance Test)：測試是否能滿足預期目標。
  2. 負載測試 (Load Test)：不管有沒有預期目標，測試時不斷加壓到安全臨界值。
  3. 壓力測試 (Stress Test)：不管有沒有預期目標，測試時不斷加壓到系統崩潰的最大負載。

以前述範例，系統必須要能夠承受每秒約 386 次的 RPS 為例。

效能測試是只要通過 386 RPS 即可。負載測試除了可以回頭得知是否滿足目標外，也可以進一步得知目前系統的安全臨界值，例如可能是 600 RPS。壓力測試主是要測試系統是否有雪崩問題 (Thundering herd)，以及是否可以滿足服務降級的要求。這些還有很多實務技巧，但這裡就先略過不談。

效能測試的工具有很多，比較常見的諸如：

  1. ApacheBench，簡稱 ab
  2. Siege
  3. Tsung
  4. Apache JMeter
  5. wrk
  6. wrk2
  7. 或 SaaS 服務

但需要注意的是，每個工具的行為不同，測量出來的數字也有所不同。

我這邊建議使用宣稱符合 Coordinated Omission 的測試工具，包括但不限於：

  1. wrk2
  2. vegeta

我曾為了深入瞭解工具彼此的行為差異，使用類似 Wireshark 等網路封包分析器，對於工具行為有興趣深入的人，也可以嘗試我使用的方法，相信你會學到更多。

最後，既然我們已知效能測試工具的量測結果有所不同，反過來說，當有人對我們販售服務或商品時，對於所提供的 RPS 數值，我們也應當要具備反思的能力。包括使用測試工具為何？數值是否值得懷疑？大量負載測試的工具是否正確使用？如此就可以避免陷入廠商提供的美化數值。

後記

本篇是 TGONext 架構組 - Ant 組在 2020-02-22 第一次聚會的內容整理。這些經驗與能力決定了你的價值。