Step change（步階變化）是一個量在某一刻一次就從一個值變成另一個值、之後停在新值的改變，中間沒有過渡值。相對的是逐步累積的變化：每一段時間各多一點，兩次量測之間看得到它往某個方向移動。兩者的差別決定了偵測的方式：逐步累積的變化可以從兩次量測推出速度、預測什麼時候到達警戒值；步階變化在兩次量測之間沒有可以外推的趨勢，只能拿現在的值跟基準比對，或在改變發生的當下收到事件。「步階」是台灣控制工程對 step 的譯法（步階函數、步階響應），中國大陸的資料多寫作「階躍」。告警怎麼依條件送出見 Alert。

概念位置

步階變化與逐步累積的變化是同一個量的兩種改變形態，不是兩種量：磁碟用量平常逐步累積，有人一次複製進一個大檔案時是步階變化；服務的延遲平常在一個範圍內波動，部署了一個有問題的版本之後一次跳上去，就是步階變化。所以判斷看的是這一次的改變長什麼樣，而一個量常見的改變形態決定了平常要用哪一種偵測。

偵測方式依形態分開：

• 逐步累積的變化：用趨勢外推，拿兩次量測的差除以時間得到速度，再拿現在的值到警戒值的距離除以速度，得到到達警戒值的時間，檢查間隔從這個時間推出來。外推的前提是速度在下一段時間大致維持，增長由外部請求決定時（對外的寫入端點），兩次量測之間的速度不代表下一段，要改用最壞情況的速度。
• 步階變化：到達警戒值的時間是零，間隔算不出來。偵測靠跟基準比對（拿現在的防火牆規則、接聽清單跟部署時記下的清單比），或在改變發生的當下取得事件（雲端的稽核紀錄、設定變更的通知，見 Audit Log）；比對多久做一次，由能接受改變後的狀態持續多久決定。

基準本身也會隨業務改變而移動，那是另一件事：業務成長讓正常的延遲範圍整體往上移，屬於基準要重新校準，見 SLO Baseline Drift；IaC 宣告的設定與雲端實際狀態不一致，見 Drift（設定漂移），那種不一致多半就是由一次步階變化（有人在主控台改了設定）造成的。

可觀察訊號與例子

步階變化在時間序列圖上是一段近乎垂直的線，之後維持在新的水準；逐步累積的變化是一條斜線或鋸齒（有輪替的 log 在每次輪替時掉下來，之後再往上爬）。

• 主機的設定：有雲端帳號權限的人在主控台把 SSH 的放行來源從管理者 IP 改成 0.0.0.0/0，規則在送出的那一刻就從只放行管理者變成對所有人開放；安裝一個新套件，同時帶進一個在所有介面上接聽的服務。兩次量測之間沒有任何逐步接近的過程。
• 服務的指標：部署後平均延遲從 50 ms 跳到 120 ms 並停在那裡，是步階變化；記憶體洩漏讓程序的用量每小時多幾 MB，是逐步累積的變化。延遲跳上去的那一種，原因在部署時間附近找；記憶體慢慢增加的那一種，要看它多久會碰到上限。
• 外部的設定：CDN 業者新增一個位址段、管理者家裡的 IP 被 ISP 重新分配，對源站來說都是步階變化：放行清單在那一刻就跟實際的來源對不上。

判讀方式

判讀一項要檢查的狀態時，先問它的改變是哪一種形態：逐步累積的，檢查間隔由到達警戒值的時間推出，量測可以留給維護時段；步階變化的，定期量測只能在下一次量測時才發現，所以會造成對外暴露的改變，要用排程比對或變更事件把發現的時間縮短，結果送到主機以外的接收端。一個項目兩種形態都會發生時（磁碟用量平常逐步累積、偶爾一次跳上去），兩種偵測都要：趨勢外推決定維護時段的清理節奏，剩餘空間的告警兜住一次跳上去的那種。

在事故調查裡，這個區分用來縮小原因的範圍：指標是步階變化時，原因多半是那個時間點附近的一次變更（部署、設定修改、流量來源改變），先對照變更紀錄；是逐步累積時，原因多半是一個持續作用的過程（洩漏、資料增長、快取命中率下降），要看斜率從什麼時候開始改變。主機維護裡兩種形態各自的處理方式，見 長期上線主機的維護項目：會累積的資料、定期讀的 log、對外入口的盤點、安全更新、會到期的設定與檢查間隔的推算〈檢查間隔與哪些項目改成自動處理的推算〉。