什麼是SRE？從SLI到故障覆盤，這些要點你不可不知！

2025-05-12 06:32 Linux就該這麼學

來源：https://blog.zhuxingzhao.com/post/sre-de-zhu-yao-gong-zuo/#%E4%BA%8B%E5%8A%A1%E5%B7%A5%E4%BD%9C%E9%A2%84%E7%AE%97

主體

制定SLIs、SLOs、SLAs

SRE最好從整個軟體研發週期的最開始去聯合相關的干係人去制定相關的SLI，在未來軟體進入生產之後，更好的提供一份比較科學嚴謹的SLO以及SLA，以及避免在可能在欠缺SLI的情況下導致我們不得不為相關的指標增加開放工作，而且SRE應該為研發團隊宣導相關SLI的歷練，讓研發在實現功能的同時考慮功能相關的SLI資料的埋點上報。這需要我們跟研發團隊保持良好的溝通和宣導。
概念
  • 服務水平指標（SLIs）：表示對服務能夠穩定執行而定義的一些指標
  • 服務協議目標（SLOs）：基於SLI達到的能夠穩定執行的目標或者範圍
  • 服務水平協議（SLAs）：是跟使用者或者客戶承諾的服務的可靠情況 是一種協議 當達不到承諾的情況下應該做的事情
三者的關係
干係人

可靠性、效能和彈性、飽和度、可觀測性

可靠性
服務時間
MTTR
MTTR 是裝置從任何故障中恢復所需的平均時間。
MTBF
MTBF 是在正常系統執行期間，機械或電子系統固有故障之間的預計經過時間。MTBF 可以計算為系統故障之間的算術平均（平均）時間。該術語用於可修復系統，而平均故障時間 (MTTF) 表示不可修復系統的預期故障時間。
MTTF
MTTF 表示不可修復系統的預期故障時間。

效能和彈性

效能和彈性是兩個衝突的點。如果我們一味的追求效能，必然導致我們的應用不是太彈性。如果太彈性也就意味著我們的應用效能不是那麼強。
這兩者的取捨應該取絕於，我們的單體QPS以及使用者的對於延遲的容忍度。

飽和度

這個定義一般是定義我們的SLO，他可以是當前服務承載的容量，也可以是CPU使用率。飽和度最大值應該是我們服務不可用的時候的所表現的測量點。

可觀測性

我們系統的可觀測性訊號由以下四點
  • 指標
  • 跟蹤
  • 日誌
  • proile
  • crash
這幾個訊號會幫助我們顯著瞭解我們系統的穩定性，並能很好的幫助我們在故障的情況下，快速發現並且快速排障。
而且這幾個訊號我們也應該進行資料標準的統一讓幾者可以關聯起來，更好的幫助觀察和故障排查。這也是現代可觀測性建設的核心目標之一。
我們應該建設一個具備相關訊號的可觀測性平臺以及推動研發進行相關的可觀測性訊號能力的接入以及開發。
最好聯合相關團隊進行宣導，以及最好有在迭代中有10%的人力投入能夠做到相關的支援。
指標
指標是一個很重要的概念，我們常常忽視他的存在。指標的定義，與監控系統所支援的資料模型結構，有著非常密切的關係。監控資料的來源，從資料的型別可以分為：數值，短文字字串，日誌(長文字字串)。通常所講的指標，都是對當前系統環境具有度量價值的統計資料，使我們能夠明確知道當前系統環境的執行狀態。
指標的定義應該遵循 SMART 原則：
  • S代表具體（Specific）指標是明確的，有具體的含義，能反映具體的屬性，有針對性的。
  • M代表可衡量（Measurable）可測量指標的活動，包括百分比、數值等。
  • A代表可實現（Assignable）能夠將指標的值獲取到，有技術手段或工具採集到。
  • R代表相關性（Realistic）與其他指標在邏輯上存在一定關聯性。
  • T代表有時限（Time-bound）在一定的時間範圍內取值跟蹤。
指標資料模型（OpenMetric）
metric_name{<label name>=<label value>, ...} value timestampnode_disk_read_bytes_total{device="sr0"} 4.3454464e+07node_vmstat_pswpout 0http_request_total{status="404", method="POST", route="/user"} 94334
指標型別
  • Counter：計數器是一種累計型的metric度量指標，它是一個只能遞增的數值。計數器主要用於統計類似於服務請求數、任務完成數和錯誤出現次數這樣的資料。
  • Gauge：計量器表示一個既可以增加, 又可以減少的度量指標值。計量器主要用於測量類似於溫度、記憶體使用量這樣的瞬時資料。
  • Histogram：直方圖對觀察結果（通常是請求持續時間或者響應大小這樣的資料）進行取樣，並在可配置的桶中對其進行統計。
  • Summary：類似於直方圖，彙總也對觀察結果進行取樣。除了可以統計取樣值總和和總數，它還能夠按分位數統計。
跟蹤（Trace)
跟蹤對於當下複雜的的分散式應用來說是非常必要的。它們可能分佈在上千個伺服器、不同的資料中心和可用區中，如何監控服務之間的依賴關係和呼叫鏈，以判斷應用在哪個服務環節出了問題，哪些地方可以最佳化？
當前最佳的分散式 Trace 協議選擇應該是 Opentelemetry
Causal relationships between Spans in a single Trace [Span A] ←←←(the root span) | +------+------+ | | [Span B] [Span C] ←←←(Span C is a `child` of Span A) | | [Span D] +---+-------+ | | [Span E] [Span F]
Temporal relationships between Spans in a single Trace––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–> time [Span A···················································] [Span B··········································] [Span D······································] [Span C····················································] [Span E·······] [Span F··]
日誌（Log）
日誌也是我們觀察系統的一個重要訊號，擔心當今軟體形勢的發展，讓我們的日誌收集和儲存受到了巨大的挑戰。當我們的應用越來越多的從主機往 K8s 這種架構轉型的時候，我們的日誌採集受到了比較大的挑戰，而且服務產生的日誌也越來越多的，對於海量的日誌的檢索，我們需要探尋更多的方案。
Profile
對於當下雲原生的技術的發展，如何對雲原生架構下的應用進行 profile，也是我們的一個重要挑戰，所幸的是由於bpf技術的相關發展，我們可以更好的利用底層技術，去快速的利用 bfp 相關的技術進行應用的 profile 從而幫助應用更好的調優。
Crash
crash是我們線上環境出現問題之後的重要現場，我們理應建設好相關的crash分析流程，來更好的跟相關訊號進行打通關聯，從而跟好的做到自動化的問題發現，報告生成。

錯誤預算

我們可以簡單的用 SLO目標 + 錯誤預算 = 100% 來簡單的計算出我們的錯誤預算。我們的一些日常工作例如版本迭代、變更、故障處理都算在錯誤預算裡面，也就是隻要會影響SLO的操作，都應該屬於我們錯誤預算的一部分。如果我們超出了錯誤預算，也就意味著我們的SLA會收到使用者質疑，也就意味著我們應該開始排查為啥錯誤預算的消耗過高，也就是我們應該給錯誤預算一個閾值範圍，在一定範圍的功能釋出，變更操作都屬於正常的，一旦超過某個值，也就意味著我們的系統可能出現了不穩定的情況，這個時候我們應該馬上進行總結，尋找問題的原因，快速解決它。我們應該同真個團隊尋找到一個合理的平衡點。

事務工作預算

作為SRE，我們應該對工作有個要求:
  • 不需要人的地方由機器完成
  • 需要的人的地方由機器輔助完成。
所以需要人操作的地方一般屬於我們的事務工作，但是我們也不需要將全部的時間投入到事務工作上，比如變更需要手工執行命令，手動的通知開放。這個時候我們應該理一理我們的時間投入情況，如果事務性的工作太多，是不是我們沒有梳理好整個釋出流程，變更流程。我們沒有沉澱出相關的自動化流程。所以一旦發現我們的事務性工作佔據太多的時間，一定要停下來梳理，哪些可以自動化的，哪些可以半自動化的。爭取將人工參與的部分降到一個合理的地步。

風險識別和管理

風險識別與管理，我在大學的時候學的是安全工程，這是一門專門學習如何進行風險識別與管理的學科，但是那都是對於現實層面的風險識別識別與管理，例如機械、工業、化學、交通等領域的，但都有著類似的方法論。
說到風險，我們就要認識一下海恩法則：
海恩法則是德國飛機渦輪機的發明者德國人帕布斯·海恩提出一個在航空界關於飛行安全的法則,海恩法則指出：
每一起嚴重事故的背後，必然有29次輕微事故和300起未遂先兆以及1000起事故隱患。法則強調兩點：一是事故的發生是量的積累的結果；二是再好的技術，再完美的規章，在實際操作層面，也無法取代人自身的素質和責任心。
透過海恩法則，我們要認識到事前的風險識別與管理能極大的幫助我們避免相關問題的出現。所以需要我們對於應用架構有著極為深度的瞭解。並從可用性的角度，去判別應用風險的可能點。
  • 比如當容量過載的時候，系統可能出現什麼問題。
  • 機房斷電，會出現什麼問題
  • 域名解析異常，會導致什麼問題
我們列出一份詳盡的系統風險評估文件。從不同的角度列舉不同風險的可能點以及事故預言。在現代雲原生的發展下，我們更加可以利用混沌工程等故障去模擬相關風險的產生。

事故管理

事故是不可避免的，其實事故不可怕，可怕的是我們沒有對事故進行總結學習。只有出現了事故，我們才能對於現有體系的問題進行修復總結，避免同一個事故再發生，所以我們需要對於事故有著細緻的報告和總結覆盤。

事故報告&事故覆盤

事故報告
事故報告是我們瞭解事故全景的重要手段，我們需要透過事故報告瞭解到
  • 事故原因：可以瞭解一下事故致因2-4模型
  • 事故背景
  • 事故半徑
  • 事故時間線
  • 事故干係人
  • 事故處理過程
有了以上的資訊，我們才可以詳細的知道一個事故的全部面貌，最好我們有一個統一的知識庫去存檔這些，幫助以後我們瞭解相關的改進背景以及處理方案有著極好的作用。
事故覆盤
研究故障或者失敗的邏輯非常重要，複製成功者所做所為，不一定回讓你成功，而避免失敗者的做事套路，將一定會增加你的成功機率。
底層邏輯
  • 故障是常態，無法完全避免
  • 故障時表象，背後的技術和管理上的問題才是根因
  • 可以包容失敗，但是不允許犯錯
  • 個體的失誤反而是一件好事
良好的事故覆盤能夠有效的幫助團隊，回顧整個事故的點線面，這樣學習式的覆盤，能更好的給每個人以比較深刻的印象，最好的是學習之後，能夠整理出相關合理的流程幫助未來的事故不在發生以及推動相關工具建設，告警設定以及故障經驗。

專案研發工作

SRE還有重要的工作是相關係統的研發，因為很多重要平臺都是透過sre孵化出來的，例如可觀測系統、海量分散式作業平臺，CMDB系統等。因為這些平臺的使用才能更好的幫助整個團隊提高研發效能水平。
架構設計
SRE也需要有著相當不錯的架構設計能力，因為 sre 需要評估研發團隊的架構以及sre 團隊研發平臺的架構，而且SRE也需要從架構層面去衡量整個系統的可靠性，可觀測性等能力,並給出相關的指導意見。
軟體工程
軟體工程更是SRE需要深入瞭解到，因為我們需要參與到研發流程的建設，不管是瀑布式的研發模式，還是現在 DevOps 敏捷迭代的開發模式，我們都應該完整的瞭解軟體工程。
專案管理
從我的經歷來看，一般sre團隊內部沒有專職的專案管理的成員，所以一般需要某一個成員兼職專案管理的角色，這名成員一般要根據專案週期、時間風險、人力投入、技術分析、周邊團隊協作方面去規範專案進度。一般需要需要經驗豐富的人擔任。
測試流程
SRE 自身的軟體交付質量，也需要有相關的測試流程去把握，但是對於sre團隊來說，最好是做到核心路徑的單元測試覆蓋，這樣在重構或者功能遷移的時候，能快速回歸測試迭代，最後透過完整的整合測試幫助上線前的交付驗證，避免出現問題。
研發流水線
因為 SRE 團隊一般成員較少，所以自身的研發 DevOps 流水線一定要建設得比較好，才能高效的產出交付功能，不然就會陷入研發怪圈。
END
官方站點：www.linuxprobe.com
Linux命令大全：www.linuxcool.com
劉遄老師QQ：5604215
Linux技術交流群：2636170
（新群，火熱加群中……）
想要學習Linux系統的讀者可以點選"閱讀原文"按鈕來了解書籍《Linux就該這麼學》，同時也非常適合專業的運維人員閱讀，成為輔助您工作的高價值工具書！


相關文章