任何複雜系統都會有系統變動的部分, 許多信號, 以及許多形式的輸出
我們需要用一個通用的形式來區分, 系統行為是在預料之內. 我們將系統正常運行時的狀態, 定義為系統的穩定狀態
這時候你需要回答以下問題: 你如何知道系統是否在正常運作
例如人是恆溫動物, 肛溫在 36.6 到 37.8 之間. 如果溫度不在這範圍之內, 他可能是發燒, 身體可能有狀況發生.
那系統呢? 你要怎麼知道系統正常呢?
你可能會先登入系統, 如果能登入, 每個 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 的正常服務的原則.
資料來源
全站熱搜
留言列表