---
# System prepended metadata

title: 2024/01/31 第11章 可觀測性驅動開發

---

# [點此加入 Google Meet 會議室](https://meet.google.com/mch-yqjg-sdg)

[TOC]

## 時間軸
- 20:50-21:00 閒聊/進場/確認相關軟、硬體
- 21:00-21:40 各章節負責人分享 
- 21:40-21:50 閒聊/完畢

---

## 『可觀測性驅動開發』是要解決什麼議題?

### 1. 以測試驅動開發為例
* 測試驅動開發(Test Driven Development, TDD)
* TDD用來測試我們**已知的範圍**，確保應用程式的一致性與隔離性。
* TDD無法測試出我們**不清楚的範圍**，例如: 實際環境的系統效能，或是實際環境上各元件間的依賴。
<!--例如: 最常見開發人員本機訪火牆全開，但部署環境的白名單都沒有申請等; 應用程式在本機記憶體吃了4GB RAM，但僅有申請2GB RAM的主機來部署-->
   
### 2. 開發週期中的可觀測性
* 開發階段無法清楚服務上線後會造成什麼影響?
    * 系統本身
    * 其他系統的元件
* 開發人員在什麼情況下無法快速解決線上的問題?
    * 太久沒接觸的程式碼
    * 維護別人寫的程式
<!--結論: 只能等上線服務報錯了才發現自己疏漏了什麼細節-->
   
---

## 為何透過『可觀測性驅動開發』可以解決上述議題?

### 3. 根因定位
* 除錯器或分析器(顯微鏡):
  1. 將問題依照不同端點分類
  2. 找到可能造成問題的服務及其相關參數
  3. 透過工具在本機重現並釐清問題
  
* 可觀測性工具(望遠鏡): 
  1. 將問題依照不同端點分類
  2. 觀察哪些服務發生相同的問題
  3. 在線上釐清問題是否為程式碼或是基礎設施
<!--備註: 兩者用來相輔相成，並非互相取代的關係-->

:::info 
:bulb:【P.121】可觀測性是為了找出你需要除錯的程式碼，位於系統中的哪個位置。 
:::

### 4. 微服務時代下的除錯方法
* 單體式服務: 
  適合用除錯器或分析器來釐清問題，因為外部依賴元件較少，對環境面的議題也較好掌握。
 
* 分散式服務: 
  適合用可觀測性工具去「定位」問題在哪裡，因為外部依賴元件多，需要較高視角的分析。

:::info
:bulb: **若不用可觀測性工具，改用監控工具是否也可以?**

先詢問你的監控工具是否能做到回答出下列問題的追蹤: 
1. 程式碼中存在錯誤
2. 特定使用者改變他們的使用模式
3. 資料庫超出容量
4. 網路連線限制
5. 錯誤配置的附載均衡
6. 服務註冊或服務發現問題
7. 上述因素的某些組合

上述來自【P.123】

:::

<!--備註: 這邊有個冷知識蠻有趣的，就是為何會使用trace這個詞來描述更加有系統地理解完整的軟體系統-->

---

## 如何透過『可觀測性驅動開發』解決這些議題?

### 5. 如何檢測以推動可觀測性

| 項次 | 項目    | 說明                                |
| --- | ------- | ---------------------------------- |
| 1   | 解決議題 | 開發人員在什麼情況下無法快速解決線上的問題?|
| 2   | 解決方法 | a. 建立反饋迴圈，並透過下列4點檢視反饋迴圈<br/>&nbsp;&nbsp;&nbsp;&nbsp;(1) 程式碼是否按照你的預期運行? <br/>&nbsp;&nbsp;&nbsp;&nbsp;(2) 與之前的版本相比如何?<br/>&nbsp;&nbsp;&nbsp;&nbsp;(3) 使用者是否正在使用你的程式碼?<br/>&nbsp;&nbsp;&nbsp;&nbsp;(4) 是否出現任何異常情況?<br/>b 透過金絲雀部署[^1]加速反饋迴圈|
          
<!--備註: 找不到跟可觀測性的關連...-->

### 6. 左移可觀測性

| 項次 | 項目    | 說明                                |
| --- | ------- | --------------------------------- |
| 1   | 解決議題 | 開發階段無法清楚服務上線後會造成什麼影響? |
| 2   | 解決方法 | 在開發階段就使用可觀測性工具         |

### 7. 使用可觀測性加速軟體交付

| 項次 | 項目    | 說明                                |
| --- | ------- | ---------------------------------- |
| 1   | 解決議題 | 開發階段無法清楚服務上線後會造成什麼影響?  |
| 2   | 解決方法 | a. 可觀測性搭配功能標誌<br>b. 可觀測性搭配漸進式交付模式| 
  
<!--備註: 這3個主題抓不檔重點...好難掰-->
<!--備註: 這3個主題沒有實作過其實很難去評估結果跟優缺點，有可能付出遠大於收穫-->

---

## 誰需要『可觀測性驅動開發』?

### 8. 總結
* 簡答: 開發人員。
* 如何讓開發人員了解營運環境的運作方式?
* 如何讓開發人員在開發階段就可以與營運環境互動?
* 補充群組上有人推薦的可觀測性左移文章[^2][^3][^4][^5]，可以看看。

---
# 共筆區塊

---
# 聊天區塊


---

## 相關資料

[^1]: [金絲雀部署](https://glossary.cncf.io/zh-tw/canary-deployment/)
[^2]: [Shifting Observability Left in the SDLC](https://medium.com/lumigo/shifting-observability-left-in-the-sdlc-43ce83695a49)
[^3]: [Choosing the Right Observability Tools for Developers](https://lumigo.io/blog/choosing-the-right-observability-tools-for-developers/)
[^4]: [The Power of Distributed Tracing in Shifting Observability Left](https://lumigo.io/blog/the-power-of-distributed-tracing-in-shifting-observability-left/)
[^5]: [Shifting Observability Left - Empowering Developers](https://lumigo.io/blog/shifting-observability-left-empowering-developers/)
