Upgrade to Pro — share decks privately, control downloads, hide ads and more …

From Observability to Observability Driven Deve...

Marcus
July 24, 2024

From Observability to Observability Driven Development

近幾年來,隨著軟體架構進化為微服務和雲原生技術的轉變,系統的複雜性急劇增加。 這種變化使得傳統的監控工具難以全面理解並快速適應變化。 在國外研討會越來越多人探討如何透過可觀測性來提高 DevOps 的效率。面對這樣的挑戰,可觀測性變得越來越重要,它不僅讓開發和維運團隊能夠監控系統,更能透過收集系統的遙測數據來深入理解系統的行為和性能。

本次分享的內容將包括:

可觀測性的介紹:定義可觀測性的基本概念及其在現代軟體開發中的關鍵角色。探討為何可觀測性對於成功實施 DevOps 至關重要,以及它如何協助開發人員高效的運維和快速的問題解決。
可觀測性的演進 : 分析可觀測性在過去幾年是如何不斷演進與重新定義的歷程;並探討可觀測性的重要信號(Signals),如日誌(Log)、指標(Metrics)、追踪(Trace)的演化如何協助團隊更好地理解和管理系統,以及這些關鍵信號在提供系統洞察問題的侷限性,並探索如何克服這些挑戰以實現更全面的可觀測性。
可觀測性驅動開發(O.D.D):如何將可觀測性轉變為一種推動開發的策略。將可觀測性原則整合到軟體開發生命週期的各階段中,從基礎的可觀測性措施到開發過程中的全面整合,開發團隊可以更早地發現和解決潛在的問題。

Marcus

July 24, 2024
Tweet

More Decks by Marcus

Other Decks in Technology

Transcript

  1. Agenda Future : Observability Shift Left Present : History of

    Observability Past : Why we need Observability - 可觀測性左移 - 可觀測性的演進史 - Observability Signals - 現代化開發者遇到什麼挑戰,為什麼需要可觀測性 ? 03 02 01
  2. Hello! I’m Marcus 後端打雜工 #自我學習 #熱愛分享 #可觀測性 分享經驗 - 2022

    DevopsDays 可觀測性的實踐 - 2023 ITHome 鐵人賽 DevOps 組佳作 - COSCUP、MOPCON、.NET Conf
  3. Development Process Architecture People Infra Cloud & Packaging Problem 人

    * 架構 * 基礎建設 * 流程 * Cloud = Complexity Credit to : canva
  4. Observability Signals Metrics Distributed Traces Structured Log SLI/KPIs Service dependencies

    Unlimited detail Do I have a problem ? Where is the problem ? What is causing the problem ? Service Level Objective
  5. Metrics 外部 • Service Level Agreement (SLA) 內部 • Service

    Level Objective (SLO) • Service Level Indicator (SLI) • Service Level Status (SLS) • Error budget Credit to : slo
  6. Structured Log Before After • Application Logs • Security Log

    • System Log • Audit log • Infrastructure log
  7. • 我有用 Jenkins,我就是在做 DevOps • 我有用 CI/CD,我就是在做 DevOps • 我有用

    Slack,我就是團隊協作專家 • 我有用 Excel,我就是數據分析大師 • 我有用 Log、Metrics、Tracing,就是 導入可觀測性了嗎 ? 導入工具就能解決問題嗎 ? Credit to : chatGPT
  8. Observability : Shift Left Plan Design Develop Test Deploy Operate

    CI/CD pipeline 開發流程 開 發 & 維 運 的 工 作 , 兩 者 都 非 常 重 要 過去關注的
  9. • Healthy pipelines • 提升穩定性 (Reliability) • 提高效率 (Performance) •

    程式碼行為 (behave) 的假設 • 考慮可觀察性信號 Signals • feedback CI/CD pipeline 開發流程 Observability : Shift Left
  10. CI/CD pipeline Observability Plan Design Develop Test Deploy Operate Unhealthy

    pipeline • Slow deployment • Testing Issues • Technical dept • Reducing any delay in pushing code • Reducing wait time for user • Preventing unnecessarily long cycle time Internal External impact low high
  11. Observability–Driven Development Plan Design Develop Test Deploy Operate 目標 :

    • 建立有效的反饋機制 • 打破開發和運維之間的隔閡 • 培養數據驅動的決策文化 Write Tests Evaluate Tests Refactor TDD Define Expected Outcome Measure The Outcome Change Feature & keep measuring ODD Deployment feedback Is feature behaving as expected
  12. Observability–Driven Development Framework 02 03 04 05 定義衡量指標 01 定義衡量指標

    KPI 持續優化 跟調整 實現自動化的 可觀測性數據 收集 設計階段考慮 可觀測性 建立即時 反饋機制 確 保 在 開 發 周 期 系 統 具 備 良 好 的 可 觀 測 性
  13. Implementing O.D.D : 定義衡量指標 監控指標 (系統健康) Rate(速率) Errors(錯誤) Duration(持續時間) Utilization(利用率)

    Saturation(飽和度) Errors(錯誤) Latency(延遲) Traffic(流量) Errors(錯誤) Saturation(飽和度) • 關鍵服務是什麼 ? • 外部服務有哪些 ? • 各服務之間的依賴關係 ? • 有哪些重要情境不能掛? Bug & Issue Other MBPM(Metrics-Based Process Management) SLA, SLOs, SLIs 系統架構圖 Goal 框架
  14. O.D.D : 定義衡量指標 – 以 AI 智能客服為例 監控指標 Rate(速率):每分鐘處理的客戶查詢數量。 Errors(錯誤):系統處理錯誤的次數。

    Duration(持續時間):平均響應時間 查詢時間:用戶查詢到系統生成回應所需的時間。 語音識別延遲:從用戶語音輸入到語音轉文本的時間 回應生成時間:系統生成自然語言回應所需的時間。 • 自然語言處理模組、回應生 成模組、查詢數據庫模組等 • 語音識別模組依賴於語音到 文本轉換模組。 MBPM(Metrics-Based Process Management) SLA, SLOs, SLIs 系統架構圖 Goal 框架 • 請求 Token 數 • OpenAPI 請求量 • 回答問題正確率
  15. A.B.C + OpenTelemetry AIOps, LLM Observability AI Data Observability, Telemetry

    Data Big Data 收集遙測數據的標準 OpenTelemetry Infrastructure Cloud
  16. Takeaway 可觀測性 1.0 可觀測性 2.0 可觀測性 3.0 特點 基本監控與人工分析 增強監控與主動分析

    智能監控與自動化運營 分析方法 人工分析 半自動分析 自動分析 處理問題 Known-unknown unknown-unknown unknown-unknown 操作模式 被動 主動 自動 優點 對已發生的問題做出反應 主動發現和解決潛在問題 系統能夠自動識別、分析和解 決問題 缺點 被動監控,無法及時預測 和防範問題 數據量大,帶來存儲和處理的 挑戰 初期投入成本大,需對現有系 統全面升級和改造 總結 • 從人工分析到半自動,再到全自動。 • 問題處理方式從被動到主動再到預測性。 • 從基本監控到深入分析,再到預測和洞察