任何複雜系統都會有系統變動的部分, 許多信號, 以及許多形式的輸出
我們需要用一個通用的形式來區分, 系統行為是在預料之內. 我們將系統正常運行時的狀態, 定義為系統的穩定狀態
 
這時候你需要回答以下問題: 你如何知道系統是否在正常運作
 
例如人是恆溫動物, 肛溫在 36.6 到 37.8 之間. 如果溫度不在這範圍之內, 他可能是發燒, 身體可能有狀況發生. 
 
image
 
那系統呢? 你要怎麼知道系統正常呢? 
 
你可能會先登入系統, 如果能登入, 每個 menu 都點選一下, 或許你就會說這系統正常. 但是這樣都是手動太累. 你可能會利用 API 來確認. 可能會有個 API 系統會傳回”還活著“ 訊息. 但這樣可能太簡單了, 更好的方法, 會收集和系統健康相關的數據.像是: 系統 CPU 使用率, 網路 I/O, 目前可用記憶體, web request 的反應時間, 或者 資料庫查詢花費時間等等.
 
但是, 這些跟環境相關數據正常就能說系統是穩定的正常的嗎? 我想這些數據如果不正常, 一定可以說系統不在穩定狀態. 但是這些數據正常, 不見得系統就沒問題. 怎麼說, 因為這些指標是從系統面來衡量, 但是沒有商業的角度來. 例如, 如果系統都沒人用, 環境面的指標應該都很好, 但從商業角度, 必須提出提出警告, 說現在系統沒人在用, 對收益來說是不好的. 
 
在描述系統的穩定狀態時, 不是只有看環境類的指標, 也要有商業角度的指標.
 
例如: 
A. 下單後取消的比例, 如果放到購物車後卻取消, 如果這樣比例變高, 某種程度一定有些地方出錯. 
B. Netflix 有個 index: SPS (Starts Per Second) 每秒開始播放次數, 如果這個數字下降, 代表客戶不想在 Netflix 上看片. 
 
另外, 有時候是否在穩定狀態, 不是只看單一的數值, 可能需要看 pattern. 例如
A. Netflix 的 SPS 值在美東 下午 6點 要比早上 6點. 否則代表系統可能有問題
 
當你定義好系統穩定的狀態之後, 之後你要開始進行測試實驗, 你就要定義這個實驗會帶給穩定狀態什麼影響. 例如:
 
A. 如果對非關鍵的服務進行中斷的實驗時, 應該要假設對不會影響到 SPS. 因為 Netflix 的設計就是要能容錯, 當非關鍵的服務出錯, 不該影響 end to end 的正常服務 SPS 要是正常的狀況
 
B. 例如將 某個 AWS 的區域流量移到另外兩個區域的實驗, SPS 應該也不會偏離穩定狀態. 否則就不滿足 Netflix 不影響end to end 的正常服務的原則.
 
 
資料來源

    全站熱搜

    kojenchieh 發表在 痞客邦 留言(0) 人氣()