SRE 的主要職責是什麼？

1 主體

制定 SLIs、SLOs、SLAs

SRE 最好從整個軟件研發週期的最開始去聯合相關的干係人去制定相關的 SLI，在未來軟件進入生產之後，更好的提供一份比較科學嚴謹的 SLO 以及 SLA，以及避免在可能在欠缺 SLI 的情況下導致我們不得不爲相關的指標增加開放工作，而且 SRE 應該爲研發團隊宣導相關 SLI 的歷練，讓研發在實現功能的同時考慮功能相關的 SLI 數據的埋點上報。這需要我們跟研發團隊保持良好的溝通和宣導。

概念：

• SLIs，服務水平指標，表示對服務能夠穩定運行而定義的一些指標。

• SLOs，服務協議目標，基於 SLI 達到的能夠穩定運行的目標或者範圍。

• SLAs，服務水平協議，是跟用戶或者客戶承諾的服務的可靠情況 是一種協議 當達不到承諾的情況下應該做的事情。

三者的關係：

干係人：

smLapF

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

1、可靠性

服務時間：

ofbd9x

• MTTR：MTTR 是設備從任何故障中恢復所需的平均時間。

• MTBF：MTBF 是在正常系統運行期間，機械或電子系統固有故障之間的預計經過時間。MTBF 可以計算爲系統故障之間的算術平均（平均）時間。該術語用於可修復系統，而平均故障時間（MTTF）表示不可修復系統的預期故障時間。

• MTTF：MTTF 表示不可修復系統的預期故障時間。

2、性能和彈性

性能和彈性是兩個衝突的點。如果我們一味的追求性能，必然導致我們的應用不是太彈性。如果太彈性也就意味着我們的應用性能不是那麼強。

這兩者的取捨應該取絕於，我們的單體 QPS 以及用戶的對於延遲的容忍度。

3、飽和度

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

4、可觀測性

我們系統的可觀測性信號由以下幾點：

• 指標

• 跟蹤

• 日誌

• proile

• crash

這幾個信號會幫助我們顯著瞭解我們系統的穩定性，並能很好的幫助我們在故障的情況下，快速發現並且快速排障。

而且這幾個信號我們也應該進行數據標準的統一讓幾者可以關聯起來，更好的幫助觀察和故障排查。這也是現代可觀測性建設的核心目標之一。

我們應該建設一個具備相關信號的可觀測性平臺以及推動研發進行相關的可觀測性信號能力的接入以及開發。

最好聯合相關團隊進行宣導，以及最好有在迭代中有 10% 的人力投入能夠做到相關的支持。

指標：

指標是一個很重要的概念，我們常常忽視他的存在。指標的定義，與監控系統所支持的數據模型結構，有着非常密切的關係。監控數據的來源，從數據的類型可以分爲：數值，短文本字符串，日誌（長文本字符串）。通常所講的指標，都是對當前系統環境具有度量價值的統計數據，使我們能夠明確知道當前系統環境的運行狀態。

指標的定義應該遵循 SMART 原則：

• S 代表具體（Specific）指標是明確的，有具體的含義，能反映具體的屬性，有針對性的。

• M 代表可衡量（Measurable）可測量指標的活動，包括百分比、數值等。

• A 代表可實現（Assignable）能夠將指標的值獲取到，有技術手段或工具採集到。

• R 代表相關性（Realistic）與其他指標在邏輯上存在一定關聯性。

• T 代表有時限（Time-bound）在一定的時間範圍內取值跟蹤。

指標數據模型（OpenMetric）：

metric_name{<label name>=<label value>, ...} value timestamp

node_disk_read_bytes_total{device="sr0"} 4.3454464e+07
node_vmstat_pswpout 0
http_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）：

日誌也是我們觀察系統的一個重要信號，擔心當今軟件形勢的發展，讓我們的日誌收集和存儲受到了巨大的挑戰。當我們的應用越來越多的從主機往 Kubernetes 這種架構轉型的時候，我們的日誌採集受到了比較大的挑戰，而且服務產生的日誌也越來越多的，對於海量的日誌的檢索，我們需要探尋更多的方案。

Profile：

對於當下雲原生的技術的發展，如何對雲原生架構下的應用進行 profile，也是我們的一個重要挑戰，所幸的是由於 BPF 技術的相關發展，我們可以更好的利用底層技術，去快速的利用 BPF 相關的技術進行應用的 profile 從而幫助應用更好的調優。

Crash：

Crash 是我們線上環境出現問題之後的重要現場，我們理應建設好相關的 Crash 分析流程，來更好的跟相關信號進行打通關聯，從而跟好的做到自動化的問題發現，報告生成。

錯誤預算

我們可以簡單的用『SLO 目標 + 錯誤預算 = 100%』來簡單的計算出我們的錯誤預算。我們的一些日常工作例如版本迭代、變更、故障處理都算在錯誤預算裏面，也就是隻要會影響 SLO 的操作，都應該屬於我們錯誤預算的一部分。

如果我們超出了錯誤預算，也就意味着我們的 SLA 會收到用戶質疑，也就意味着我們應該開始排查爲啥錯誤預算的消耗過高，也就是我們應該給錯誤預算一個閾值範圍，在一定範圍的功能發佈，變更操作都屬於正常的，一旦超過某個值，也就意味着我們的系統可能出現了不穩定的情況，這個時候我們應該馬上進行總結，尋找問題的原因，快速解決它。我們應該同整個團隊尋找到一個合理的平衡點。

事務工作預算

作爲 SRE，我們應該對工作有個要求：

• 不需要人的地方由機器完成

• 需要的人的地方由機器輔助完成

所以需要人操作的地方一般屬於我們的事務工作，但是我們也不需要將全部的時間投入到事務工作上，比如變更需要手工執行命令，手動的通知開放。這個時候我們應該理一理我們的時間投入情況，如果事務性的工作太多，是不是我們沒有梳理好整個發佈流程，變更流程。我們沒有沉澱出相關的自動化流程。

所以一旦發現我們的事務性工作佔據太多的時間，一定要停下來梳理，哪些可以自動化的，哪些可以半自動化的。爭取將人工參與的部分降到一個合理的地步。

風險識別和管理

風險識別與管理，我在大學的時候學的是安全工程，這是一門專門學習如何進行風險識別與管理的學科，但是那都是對於現實層面的風險識別識別與管理，例如機械、工業、化學、交通等領域的，但都有着類似的方法論。

說到風險，我們就要認識一下海恩法則：

海恩法則是德國飛機渦輪機的發明者德國人帕布斯 · 海恩提出一個在航空界關於飛行安全的法則，海恩法則指出: 每一起嚴重事故的背後，必然有 29 次輕微事故和 300 起未遂先兆以及 1000 起事故隱患。法則強調兩點：一是事故的發生是量的積累的結果；二是再好的技術，再完美的規章，在實際操作層面，也無法取代人自身的素質和責任心。

通過海恩法則，我們要認識到事前的風險識別與管理能極大的幫助我們避免相關問題的出現。所以需要我們對於應用架構有着極爲深度的瞭解。並從可用性的角度，去判別應用風險的可能點。

• 比如當容量過載的時候，系統可能出現什麼問題

• 機房斷電，會出現什麼問題

• 域名解析異常，會導致什麼問題

我們列出一份詳盡的系統風險評估文檔。從不同的角度列舉不同風險的可能點以及事故預言。在現代雲原生的發展下，我們更加可以利用混沌工程等故障去模擬相關風險的產生。

事故管理

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

事故報告 & 事故覆盤事故報告

事故報告是我們瞭解事故全景的重要手段，我們需要通過事故報告瞭解到：

• 事故原因，國內的朋友可以瞭解一下事故致因 2-4 模型

• 事故背景

• 事故半徑

• 事故時間線

• 事故干係人

• 事故處理過程

有了以上的信息，我們纔可以詳細的知道一個事故的全部面貌，最好我們有一個統一的知識庫去存檔這些，幫助以後我們瞭解相關的改進背景以及處理方案有着極好的作用。

事故覆盤：

研究故障或者失敗的邏輯非常重要，複製成功者所做所爲，不一定回讓你成功，而避免失敗者的做事套路，將一定會增加你的成功概率。

底層邏輯：

• 故障是常態，無法完全避免

• 故障時表象，背後的技術和管理上的問題纔是根因

• 可以包容失敗，但是不允許犯錯

• 個體的失誤反而是一件好事

良好的事故覆盤能夠有效的幫助團隊，回顧整個事故的點線面，這樣學習式的覆盤，能更好的給每個人以比較深刻的印象，最好的是學習之後，能夠整理出相關合理的流程幫助未來的事故不在發生以及推動相關工具建設，告警設置以及故障經驗。

2 項目研發工作

SRE 還有重要的工作是相關係統的研發，因爲很多重要平臺都是通過 SRE 孵化出來的，例如可觀測系統、海量分佈式作業平臺，CMDB 系統等。因爲這些平臺的使用才能更好的幫助整個團隊提高研發效能水平。

架構設計

SRE 也需要有着相當不錯的架構設計能力，因爲 SRE 需要評估研發團隊的架構以及 SRE 團隊研發平臺的架構，

而且 SRE 也需要從架構層面去衡量整個系統的可靠性，可觀測性等能力, 並給出相關的指導意見。

軟件工程

軟件工程更是 SRE 需要深入瞭解到，因爲我們需要參與到研發流程的建設，不管是瀑布式的研發模式，還是現在 DevOps 敏捷迭代的開發模式，我們都應該完整的瞭解軟件工程。

項目管理

從我的經歷來看，一般 SRE 團隊內部沒有專職的項目管理的成員，所以一般需要某一個成員兼職項目管理的角色，這名成員一般要根據項目週期、時間風險、人力投入、技術分析、周邊團隊協作方面去規範項目進度。一般需要需要經驗豐富的人擔任。

測試流程

SRE 自身的軟件交付質量，也需要有相關的測試流程去把握，但是對於 SRE 團隊來說，最好是做到核心路徑的單元測試覆蓋，這樣在重構或者功能遷移的時候，能快速回歸測試迭代，最後通過完整的集成測試幫助上線前的交付驗證，避免出現問題。

研發流水線

因爲 SRE 團隊一般成員較少，所以自身的研發 DevOps 流水線一定要建設得比較好，才能效的產出交付功能，不然就會陷入研發怪圈。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/NQPhLgw2TrbYz3qO8c5czQ