公司內部分享

公司20年老系統+傳統組織, 正面臨數位轉型中
團隊管理與開發定義SLO目標
DevOps這文化帶給傳統開發團隊的新思維與習慣
紀錄,監控與可觀測性帶給開發與維運雙方團隊的好處

文章連結

Talking About DevOps & Observability

Outline

• 運維盲區Operational Blindness
• 監控Monitoring
• 紀錄Logging
• 指標Metrics
• Observability

前言

主要針對公司內部現況做分享.
站在DevOps的右側, 偏運維角度看事情
Observability的部分只是介紹

Operational Blindness

War Story

Note:
某天中午, 運維組內暴發出警報通知, 一堆訊息湧現. 大家也跳了起來, 發現網站癱瘓了, 外部監控近幾次健康檢查都沒過, 而觸發了警報.

Note:
發現網站癱瘓了

Black-Box Monitoring

Note:
登入主機監控系統, 發現網站的系統指標正常, 記憶體也還有, CPU沒到100%, Disk跟IO也還在容許範圍內, 資料庫也活著

Note:
不知道原因只好把問題擴大到開發團隊, 因為主機與網站服務的進程本身看起來還算正常

Note:
開發團隊也不確定要看什麼, 且它們沒有直接登入正式環境主機的權限; 也不會讓所有人都有權限進入主機, 管理成本高與資安風險高

Note:
開發團隊只好與運維團隊一起工作並且只能發號施令
最終在資料庫上發現, 一堆慢查詢跟一堆連線處於CLOSE_WAIT狀態
在Web服務上也看到有幾乎一樣多數量的進程
推測很可能Web服務已經達到了最大處理容量並停止響應新的request(例如healthcheck)
最後把db的query session都砍掉, Web服務上的請求隊列也清空, 就正常了

Note:
查找這些問題的根源, 浪費了很多時間;
當問題被升級時, 被波及的人也沒足夠權限查看對找問題有用的主機資訊與服務資訊.
最終還是得依賴運維團隊.且在這種情境下, 每一分鐘的無法服務或停機時間都是要錢的
運維團隊之所以只能把問題擴大, 是因為他們能看到的就幾乎只有主機的監控指標,

Question

• Dev/Ops團隊的分離, 這樣的組織與溝通方式, 有間接成本的產生
  Note:
  傳統的結構上, 有一條明顯的紅線把開發與運維的職責劃分開.
  運維團隊負責主機與基礎設施, 使得應用程式的交付成為可能.

Note:
Developer與Operations如果組織結構與合作方式上職責分的太開, 往往會像拔河一般, 分散了力道.
相互拉扯中, 復原時間就流逝了.

Note:
最可怕的還是, 使用者對平台提供的服務品質沒信心了, 跳去競品平台了

DevOps

What is SRE | Tasks and Responsibilities of an SRE | SRE vs DevOps

Note:
Developer與Operations不應該相互拉扯在拔河, 而分散了眾人的力道.

非同步系統的服務水準保證 淺談非同步系統的 SLO 設計-91APP

Note:
SLI（service level indicator）
指的是指標，例如：QPS，TPS，Duration，準確性，延遲，性能等

不是所有的metric都視為SLI，選擇儘可能少的SLI，但這些SLI卻能說明服務是否穩定，可靠。

SLO（service level objective）:服務等級目標
指的是一段時間內的目標，例如：1個月內的QPS 99.99%，響應時間<10ms等等

SLO是一組值的範圍，這個值就是由SLI定義的服務級別數值。自然的SLO定義就是，某SLI在正常情況下需要小於某值或者處於某個大小值之間。
選擇一個合適的SLO並不是一件容易的事情，當然一開始並不需要設定好這個範圍

SLA （service level agreement）:服務等級協議
指的是整個協議，協議的內容包含了SLI，SLO以及恢復的方式和時間等等一系列所構成的協議

• 基於時間的可用性

基於時間的可用性 = 系統正常運行時間 / (系統正常運行時間 + 停機時間)
SLO 99.95%, 以一年來看, 不可用佔了4小時22分鐘
SLO 99.99%, 以一年來看, 不可用佔了52分鐘

• 基於次數合計的可用性

基於合計的可用性 = 成功請求數 / 請求數總和
SLO 99.99%, 如果一天要接受2.5M個請求, 每天錯誤個數應<250個

事件處理案例

• 基於延遲

SLO 99% 前台每秒User訪問延遲 < 300ms

[架構師的修練] #2, SLO - 如何確保服務水準?

Monitoring

Types of Monitoring

Multi-Cloud Monitoring

Monitoring Layers

Logging

Deal with discrete events

• Application debug or error messages
• Audit-trail events
• Request-specific metadata
• Specific events
  Note:
  應用程式錯誤訊息、稽核事件、HTTP請求事件

Log Monitoring

• Troubleshooting
• Monitor

• Clearly log level
• Good log message (Structured Log)
• Log aggregation
  Note:
  Show Loki
  單行Log, 又是JSON格式, 針對各種類型的服務定義出固定的metadata key

Defect of Log Monitor

• Low value density

[INFO] .... initializing...
[INFO] ... request from xxx.xxx.xxx.xxx user_id xxxxxx

Note:
有價值的資訊密度太低, 很多都是第一行那樣的無價值資訊

這部影片主要講了很多
Log Cetralize and Monitor的好處
跟Log要怎清楚的表達
Logging in the age of Microservices and the Cloud

• Write log into RDBMS
  • log如果併發寫入很高, 寫入的資料庫又是RDBMS, 併發事務量不會很高
    • 就算buffer pool加大, 也是有極限的, 也不建議
  • log字段很多種類, 索引選擇困難
  • DB真出事了, 想登入看log也沒法, 搞不好還沒寫進去
  • 很容易就是壓死DB的那根樹枝
  • 讓DB回歸, 業務狀態與資料的存儲與存取吧

Metrics

4 Golden Signals

• Latency : time to serivce a request
• Traffic : requests/second
• Error : error rate of request
• Saturation : fullness of a service

SRE-book

Observability: Metric, Logging, and Tracing, Oh My!

Note:
反映用戶體驗，衡量系統核心性能。如：系統的處理時間，作業計算系統的作業完成時間等。

反映系統的服務量。如：請求數，發出和接收的網絡封包大小等。

幫助發現和定位故障和問題。如：錯誤總量、調用服務失敗率等。

反映系統的飽和度和負載。如：系統佔用的內存、作業隊列的長度等。

• Metrics for Prometheus
  • metric name and label sets

<metric name>{<label name>=<label value>, ...}

# TYPE http_requests_total counter
|--------------------------- Metric ----------------------------|-timestamp -|-value-|
|--- metric name --|------------------ labelsets ---------------|
http_requests_total{code="200",handler="prometheus",method="get"}               721

Note:
label sets代表了這個metric name下的一個維度,可以有多個維度方便做聚合操作

Metric Types

- Counters (rate)
- Gauges (value)
- Distribution 
	- Histogram (heatmap)
	- Summary 

Observability of Distributed Systems

Note:
counter只增不減, 通常用來取得request總量, 任務完成的數量, 錯誤發生次數, 或者計算某段時間內的rate變化率; 能事前透過壓力與負載測試能取得可預期的上限, 做監控與警告;
查詢當前系統中，訪問量前10的HTTP URL.

gauge即時變化情況, 隨著時間不斷變化, 通常用來記錄cpu, mem用量, coroutine數量, pool usage, 併發請求數...;
透過計算樣本的線性回歸模型, 對數據的變化趨勢進行預測.

Histogram會對觀測數據取樣，然後將觀測數據放入有數值上界的桶中，並記錄各桶中數據的個數，所有數據的個數和數據數值總和, 請求時延, 各種有樣本數據;用來區分是平均的慢還是長尾的慢,快速了解監控樣本的分佈情況
Summary 與 Histogram 類似，會對觀測數據進行取樣，得到數據的個數和總和。此外，還會取一個滑動窗口，計算窗口內樣本數據的分位數。

Archetecture

Observability

The Observability Pipeline

Note:
Monitoring tells you whether system works, observability lets you ask why it's not working

Pilliars of Obersvability

News

【企業SRE實例：新加坡星展集團】頂尖數位銀行如何再進化，SRE轉型是變身科技公司的關鍵
【臺灣SRE實例：17Live集團】多功能型SRE化身內部信心來源，天天成為開發團隊後盾
【臺灣SRE實例：Line臺灣】如何確保Line服務天天不中斷，專責SRE扮演開發與維運的橋樑
Line臺灣百億筆遙測數據的可觀察性平臺架構大公開
臺灣大型企業如何上手SRE，Google建議先做這4件事

Reference

SRE-BOOK
Operations Anti-Patterns, DevOps Solutions
Logging and Log Management
阿里雲-日誌服務
Grafana Documentation
Prometheus
Loki Documentation
FluentBit Documentation

Thank you!

You can find me on

• Blog
• IT邦