SLO design + ODD workshop
---

# 目標
Workshop 中完成 Cycle 閉環的設計體驗.

- 設計 criteria
- 測量 outcome
- 回饋

-----

演示專案 : OpenTelemtetry Demo 電商系統 or 自幹一個簡單系統
執行環境 : docker + docker compose

# 任務 1 : 識別系統內的重要功能或交易行為
- 預測系統異常
- 預測性維護
使用 服務依賴映射（Service Dependency Mapping）與 用戶旅程（User Journey)分析（如購物車結賬流程），識別出重要功能或交易行為

高優先級 SLO 候選列表（如「支付 API 延遲 ≤500ms」; 一段時間一定負載下錯誤率 < 1%）
潛在故障模式清單（如庫存同步延遲導致超賣）

# 任務 2 : 定義哪些 metrics 與 event, 對於理解上述的系統行為有幫助

**SLO 驅動的指標設計**
| SLO 維度 | 核心指標 | 關聯 Incident 類型 |
|-------|-------|-------------|
| 可用性 | HTTP 5xx | 錯誤率 服務不可用 |
| 延遲性 | P95 響應時間 | 用戶體驗降級 |
| 資料一致性 | 訂單-庫存差異計數 | 業務邏輯錯誤 |

# 任務 3 : 於系統程式中加入 instrument 埋點
手動操作添加 event; 也能用 git checkout commit 邊講解修改內容, 邊切換然後建製容器

# 任務 4 : 於 o11y 後端工具中能看見這些 event 與 metrics
根據任務2的目標，將資料蒐集進o11y 後端工具

# 任務 5 : 加入 DashBoard 與 Alert
根據任務2的目標，顯示於 dashboard，搭配例外狀況做操作。
一樣有操作難度, 但也是能透過 git checkout commit 講解
透過 k6 產生請求 + Feature flag 或 混沌工程工具來呈現場景

SLO 呈現使用者體驗相關的指標，旁邊搭配業務相關的指標（請求人數、加入購物車數量、結帳數量）。
- 當體驗太差時，請求人數多，但後兩個業務指標很低。
- 試著調整優化後，看見令兩個指標提高

**混沌測試案例**

Scenario: 模擬資料庫故障
  Given 購物車服務運行中
  When 注入db網路延遲 1500ms
  Then 監測到 API 回應變慢
  And SLO 儀表板顯示P95 <= 1000ms failed

透過一些手段讓人找到瓶頸與問題點在哪。

But alert notification, 可能就不太好串了, 畢竟 slack, email 等不好弄一個免費共享的.

# 任務 6 : 迭代與改進

# 任務 7 : o11y 文化推廣