前言：

關于什么是SRE，以及在業務上有哪些具體的輸出，網上資料眾多但都只是對基本概念做描述。那容器SRE究竟要怎么結合業務，得物容器SRE又有哪些最佳實踐，本文就得物容器SRE的一些事情向大家做介紹。

一、SRE定義

穩定性工程師，用軟件工程解決復雜的運維問題，50%的時間用于運維瑣事，50%的時間用于軟件工程保障業務的穩定性和可擴展性，包括開發監控，日志，告警系統，業務性能調優等

二、對于SRE的理解

1、SRE的監控和Oncall應急響應

（1）一個團隊 Oncall 至多需要兩個人 （另外一個是新手 shadow），oncall人員需要具備以下能力：

①清晰的問題升級路線

②清晰定義的應急事件處理步驟

③監控巡檢，如下：

• 查看監控，分析服務可用性下降或者耗時增加等影響服務質量的問題的根部原因。
• 整理以上事件的數據
• 分析根本原因，優化并且解決（運維手段，代碼，或者腳本 / 代碼自動化運維手段）

（2）遇到重大故障時的各種重要角色

IC(Incident Commander)：故障指揮官，這個角色是整個指揮體系的核心，最重要的職責是組織和協調，而非執行，下面所有角色都要接受他的指令并嚴格執行。

CL(Communication Lead)：溝通引導，負責對內和對外的信息收集及通報，這個角色一般相對固定，由技術支持、QA或者是某個SRE來承擔，要求溝通表達能力要比較好。

OL(Operations Lead)：運維指揮，負責指揮或指導各種故障預案的執行和業務恢復。

IR(Incident Responders)：即所有需要參與到故障處理中的各類人員，真正的故障定位和業務恢復都是他們來完成的，如具體執行的SRE、運維、業務開發、平臺開發、DBA，甚至是QA

2、SLO和SLA制定和保障

• 100%穩定的系統是不存在的

服務質量指標 SLI（indicator）：量化指標，包括延遲、吞吐量、錯誤率、可用性、持久性等

• 指標不宜過多，應關注用戶的真實需求

常用的指標度量應該盡量標準化（如時間間隔、頻率等）

服務質量目標 SLO（Objective）：對特定 SLI 的目標值

服務質量協議 SLA（Aggrement）：與用戶間的明確協議，一般伴隨著代價

維護服務可用性的成本不是線性增長的，到一定程度，增加一個9可能需要10倍100倍的成本，通過SLO讓成本和收益取得很好的平衡，假設一個業務增加SLO等級，可以計算一下需要的成本和帶來的收益，如果得不償失就可以不用增加SLO等級

3、變更管理

 SRE的經驗大概 70% 的生產事故由某種部署的變更而觸發

  變更管理的最佳實踐：

（1）采用漸進式發布機制

（2）迅速而準確地檢測到問題的發生

（3）當出現問題時，安全迅速地回退改動

4、容量規劃

容量規劃必需步驟：

必須有一個準確的自然增長需求預測模型，需求預測的時間應該超過資源獲取的時間。

規劃中必須有準確的非自然增長的需求來源的統計。

必須有周期性壓力測試，以便準確地將系統原始資源信息與業務容量對應起來。

5、監控系統

SRE的四個黃金指標是構建成功的監控和告警系統的一些基本原則和最佳實踐

延遲：延遲是信息發送方和接收方之間的時間延遲，以毫秒（ms）為單位。而原因往往是由于數據包丟失網絡擁塞和網絡抖動造成的，稱為“數據包延遲差異”延遲對客戶體驗有直接影響，轉化為成功請求的延遲和失敗請求的延遲。

流量：流量是系統工作量帶來的壓力。它通過每秒查詢數（QPS）或每秒事務數（TPS）來衡量。企業通過數量來衡量這一點：關鍵績效指標（KPI）是在給定時間來到站點的人數。這與商業價值有直接關系。

錯誤：錯誤是根據整個系統中發生的錯誤來衡量的。被認為是服務錯誤率的重要指標！有兩類錯誤：顯式錯誤，如失敗的HTTP請求（500個錯誤代碼，例如）；隱含錯誤是成功的響應，但內容錯誤或響應時間長。

飽和度：飽和度定義了服務的過載程度。它衡量系統利用率，強調服務的資源和整體容量。這通常適用于CPU利用率、內存使用、磁盤容量和每秒操作數等資源。儀表板和監控警報是幫助你密切關注這些資源并幫助你在容量飽和之前主動調整容量的理想工具

6、可靠性衡量

可靠性是MTTF（平均失敗時間）和MTTR（平均恢復時間）的函數。評價一個團隊將系統恢復到正常情況的最有效指標，就是MTTR。

任何需要人工操作的事情都只會延長恢復時間。一個可以自動恢復的系統即使有更多的故障發生，也要比事事都需要人工干預的系統可用性更高

三、得物容器SRE的實踐

1、Oncall應急響應的總結

Oncall是直接體現SRE價值所在，能夠直接影響MTTR時間的主要核心系數，一個好的Oncall甚至可以幫助公司挽回很多資損甚至是公司的形象，所以Oncall是每個SRE最重要的工作。

我們有自己的Oncall機制、適用范圍、人員構成、復盤跟進、不同場景會邀請不同隊員參與排障。有基本的故障處理原則，事故處理后的閉環。下圖為整個Oncall流程的進行方式：

當然每次都只是處理故障，恢復后不做總結歸納是不會有任何沉淀的，容器SRE會記錄每次有意義的故障進行文案撰寫并在故障中總結現有系統存在的工具類、平臺類、代碼類隱患點，分等級高中低進行推進push幫助業務，基架不斷完善系統健壯性；

2、一次容器故障的分享

（1）延遲問題背景：

某天下午SRE側開始陸續接到業務研發反饋redisRT 增長導致超時，其中某服務有多個pod存在redis RT突增導致部分請求超時（截圖如下）

經過了一系列的驅逐與資源規整等止血操作后，該故障在30分鐘后恢復。在這種場景下排查根因通常是一個很棘手的問題，因為第一現場很難在短時間內再進行模擬、恢復，第二在生產環境下不易做太多的測試工作。這種背景下就要發揮SRE的價值了。下面是敘述我們整個問題的排查思路與過程，希望能給大家一些借鑒。

（2）問題排查思路：

排障過程描述只是說了一個思路，部分時間點可能和故障產生的時間重合

先排查是否是網絡問題引起的，當問題發現解決后后我們梳理了對應的宿主機的信息，想發現一些規律來確認故障的根因；

圖上可見，這三臺并不是一個網段的，唯一相同的也就是同一個區域，這個范圍較大，不像是一個局部事件。所以我優先想到了云商故障；

為了進一步確認問題，我將對故障的 ecs ID 給到了阿里并進行了一個授權，隨后還拉群做了語音討論

接下來是整個根因排查分析：

①排除鏈路問題

翻閱故障時的監控發現，網絡耗時在故障時間點附近比較平穩、經過和阿里內部監控的核對，當時問題宿主機網絡延遲在故障時間點延遲僅從 2ms 增加到 4ms 所以可以排除是由于網絡問題導致的

②發現異常現象

node監控有大量的異常包，drop 計數異常，常規情況下應該為0（上圖），我們對這些drop 包做了分析（下圖）發現Drop 的統計數非常高，同時tcpofo，tcprcvq這兩個指標指向了TCP內存限制，需要擴充內存空間。

為了更進一步知道根因所在，我們又去觀察了對應的 io夯、調度（任務等待）、 夯住（應用進程鎖）、用戶態內存等待、網絡 (系統 5狀態分類左圖) （這里第一步已經排除了“網絡”故障所以這里做了刪除線處理），可以看到排查到io等待時間過長（下圖）

③深挖排查到IO平均等待時間上存在問題

IO平均等待時間在秒級以上，遠超了正常范圍，故開始排查percpu iowait 狀況。經過一系列的操作最終我們使用sls 導入tidb 的方法數據做了一個可視化；

select * from cpus where time > now() - 4h and host = 'i-bp11f8g5h7oofu5pqgr8' and iowait > 50.0

我們對那些 CPU iowait 比較高的篩選出來，看看能不能找到對應的業務（當時就懷疑是不是由于混部原因導致的）但是找了一圈沒有發現什么問題。

（3）最終根因定位：

繞了一圈發現線索又斷了，還是回到那個TCP 內存限制的問題，為什么會判斷tcpofodrop 指標會與tcp_mem 有關呢？可以直接看代碼邏輯

內核源碼網站推薦

??https://lxr.missinglinkelectronics.com/linux+v4.19/net/ipv4/tcp_input.c#L4459??

（一個展示源代碼存儲庫的軟件工具集）

上面的邏輯簡單敘述：TCP的核心預分配緩存額度函數為tcp_try_rmem_schedule，如果無法分配緩存額度，將首先調用tcp_prune_queue函數嘗試合并sk_receive_queue中的數據包skb以減少空間占用，如果空間仍然不足，最后調用tcp_prune_ofo_queue函數清理亂序數據包隊列 （out_of_order_queue）。簡單說：如果內存分配失敗，對應drop計數就會遞增

另外當時我們也發現了dmesg日志里tcp oom的日志，如下圖所示

于是就搜了一些實踐準備將線上連接數比較高的那幾臺機器做一個替換處理試試

#命令查看方法
sysctl -a|grep -i tcp_mem|tcp_rmem|tcp_wmem

當時想準備替換的配置（當時這個調整低于線上目前的值）

# 擴大TCP 總內存大小
# 擴大到 32G  最小值不動  中間數為max 的 70%  
echo  "net.ipv4.tcp_mem = 1104864 5872026 8388608">> /etc/sysctl.conf  
#單個 socket 讀分配最大內存 
#原先16MB 擴大到 32MB （中間數為最佳實踐推薦）
echo "net.ipv4.tcp_rmem = 4096 25165824 33554432">> /etc/sysctl.conf
#單個 socket 寫分配最大內存 
#原先16MB 擴大到 32MB （中間數為最佳實踐推薦）
echo "net.ipv4.tcp_wmem = 4096 25165824 33554（）432">> /etc/sysctl.conf

當時線上內存

cat /proc/sys/net/ipv4/tcp_mem
6169920        8226561        12339840，這里是最小值24G 壓力值32G 最大值48G

在check這些參數的過程中突然就發現了一個問題，我們線上的參數換算成內存值是48G左右，已經算大了，可以想象一下 tcp 鏈接總的內存已經用了48G！這部分還不光是網絡開銷只是一個 TCP 鏈接，我們就有 ss 看了下當時的鏈接情況：

通常出現這種情況的原因有以下兩種：1、應用沒有正確close他的socket進程 2、沒有處理異常情況下的socket??

感興趣的同學可以看下這個文檔（推薦）

?https://stackoverflow.com/questions/38837724/linux-too-many-closed-connections?

然后我們怎么找到是誰呢？通常情況下可以這么理解，一個 soket 就是一個 fd （句柄），對應soket 大必然fd 也大！（因為linux 一切皆文件）隨后我們用了 for 循環查找對應的/proc 下的文件數量，結果如下：

附上命令參考：

#看進程對應哪個容器
for i in `docker ps |grep Up|awk '{print $1}'`;do echo \ &&docker top $i &&echo ID=$i; done |grep -A 15 4078683
#看FD誰占用的多
for pid in `ls -1 /proc/|grep -Eo '[0-9]{1,}'`; do pnum=$(ls -1 /proc/${pid}/fd/|wc -l); if [ $pnum -gt 1000 ];then echo "${pid} ${pnum}"; fi; done

為了確認又去容器中查看，確認無疑！

拉了對應引用的負責人后將結果反饋，業務得到信息后立即響應并將自己的應用做了下線處理，隨后觀察指標立馬恢復了 - 破案~

這次故障我們深刻反省，同事建議將我們的系統參數的監控覆蓋完全，所以之后我們立即就成立了一個項目，優化推進監控覆蓋

3、容器底層對于內核參數監控與優化

繼上文說到的故障后，我們意識到了容器監控上的不足故成立了專項來做內核參數上的監控。但是內核參數上千個我們怎么來做？

（1）圈定監控指標范圍

所以第一步就是完成內核指標羅列范圍。我們對以往的故障和反饋分析來看，網絡故障發生較為頻繁，所以范圍圈定為宿主機網絡指標為主；網絡指標在系統中主要由/proc/net/netstat提供，所以我們羅列了他所提供的所有指標；（如圖是netstat的所有指標）

（2）內核指標的采集實現

有了范圍我們要制定采集方案有些是node-export需要特殊配置才能采集到的具體方案；比如下面要增加netstat的監控是需要啟用node-export對應的擴展包

第二個就是通過開源的采集組件監控不到的數據比如tcp.socket.mem這部分只能靠自己開發完成。如下圖通常采用截取字段方式將os的狀態指標采集到

（3）指標的展示可視化

有了采集后就是完成指標的展示與統計，我們通過/proc/net/netstat獲取到了46個網絡指標，同時也借鑒了業內的最佳實踐總共55個指標的羅列與代表的意義，并將各內核常見參數 含義及公式形成文檔，解決了很多參數不目的不明確的問題，下圖是我們展示這些指標的案例截圖

（4）場景分類逐個優化

完成了展示后，我們就需要對這些核心內核指標參數進行分類（這些指標存在問題可能會影響業務正常運行）

以上55個指標大多為輔助定位的指標，作為業務類型不同，關注的指標與內核參數的調整是有區別的

通用類型default資源池模型；（注重并發，多鏈接，多請求的場景）監控參考如下：監控統計可以看到資源使用比較平均，需要均衡的參數配置

算法類型高密度計算類型資源池；（主動睡眠，被動睡眠，看調度延時，cpu消耗在用戶態還是內核態）監控參考如下：監控統計可以看到 cpu大多使用率較高

大數據類型 專有集群資源池；（關注網絡IO，磁盤IO，文件系統cache，網絡開銷大）監控參考如下：監控統計可以看到網絡上開銷較大

（5）參數優化管理與兜底保障

然后我們就對這三個類型的主機分別做了參數調整和鋪平，由于文章長度關系親，就不做詳細描述了。完成了調整后我們怎么去維護和管理這些內核參數呢？這里我們對內核參數管理也做了一個方案，保障這次治理后是長久有效的。具體的流程如下：

有整理出的內核指標后還會通過日常的監控、巡檢對某些需要調整的內核參數做出修改，由于是wget統一拉取的，所以在update的時候只要通過修改oss里面的批量類型init.sh就可以做到了，不需要修改每一個資源池配置

為了更安全起見，我們還做了內核初始化兜底保障功能，當然我們在以往的經歷中發現，有些節點會因為網絡變更等原因拉不到oss的初始化文件，且Ali沒有這塊初始化的提示，所以kube-node會有一個初始化的兜底，如果節點啟動初始化失敗會檢測到對應的錯誤數據并將其修改為正常值

整套上線后，我們配置了7個監控告警項，在實際運行中發現5次以上隱患問題提前在故障發生前就預先進行了處理，保障了產線的穩定性運行。至此，整個故障算是畫上了圓滿的句號

4、容器安全的一些保障

上面正好說到兜底保障，其實我們在整個容器集群里部署有多個保護系統，下面我就舉例一個防誤刪場景的方案。

（1）簡介業內防控體系

首先我們來參考下某知名大廠的防控體系

從架構看來，大致分為三大塊：權限、風控、流控

權限管控：

2018年某大廠整體架構開始往社區K8S方向遷移。遷移是個非常漫長的過程，需要考慮很多的細節。最開始自然是K8S權限體系管控問題，不同BU、不同平臺、基礎組件，都要跟新的ASI對接，第一件事情就是 申請項目專用賬號 。當時SRE開了個Git倉庫，專門用于各個 基礎業務方 提交 賬號申請信息，格式是按照 K8S標準權限資源 進行提交。

除了 RBAC，SRE還管控 CRD、WebHook 、Kubeconfig 等核心資源

風險控制Webhook風控：

不同平臺方、業務方一般在自己的前端或者后端都有對應的邏輯進行風險控制。但是也搞不好業務方在邏輯上存在Bug或者不夠完善的地方，因此在最基礎的底層上，需要有個SRE的WebHook對所有請求進行攔截校驗兜底。

流量控制K8S-Defender

阿里搞的 K8S防火墻主要針對于API流量風控，早期是Webhook機制實現，但是K8S-Webhook天然存在一些缺陷，比如無法站起全局視角進行精準流控，因此后面是獨立出來了。做成了C/S模型，但需要強制讓所有接入ASI的基礎組件在關鍵的位置統一使用 Defender 做K8S流量風制，這個目前在得物這個階段很難推得動，所以可以降級到Webhook機制去實現。

他山之石，可以攻玉。我們可以參考

（2）得物現在防護具備的功能

① Namespace 防誤刪：

這里分為硬性和軟性兩種方式。

對于核心的Namespace，例如 kube-system、monitoring。不應該以任何理由刪除，這類Namespace可以 普通賬號直接鎖死，即便你RBAC里面擁有刪除NS的權限，就不允許刪除。

對于 Addons 或者 純業務類型的Namespace，因為可能出現調試場景，比如：調試或者測試某個復雜的Addons組件，因為牽涉到太多的配置和資源，過程中已經混亂不堪，想徹底干凈地重裝一遍，回到初始狀態。這種情況下是需要利用K8S級聯刪除特性，把該Namespace包括下面所有資源清理一次。如果鎖死該Namespace，業務方遇到這種情況，就會很麻煩，所以這個場景走 硬性防刪 就不是明智之舉。

相對于硬性防刪，我們引入了軟性防刪策略。也就是對于非核心的Namespace，在一定的時間內，我們對刪除的請求做計數統計，在沒達到閥值之前，會一直拒絕刪除。并在返回的結果上給予風險提示，如果N秒內再提交X次，則真的執行刪除動作。這種方式對業務方明顯會更加友好一些，一方面起到了一定防誤刪效果，另一方面也不至于在你真正想刪除的時候刪不掉。

另外我們還開發了一種策略，專門針對批量刪除Namespace的場景。對于我們目前Namespace的使用方式是不合理的，說不定哪天可能會對Namespace做治理，以域的方式來確定Namespace。這個時候就會涉及到大量Namespace的清理工作。這種合法的刪除，如果不斷地被Webhook攔截中斷，這不是個合理的設計。所以我們支持以管控標降級策略，也就是給對應的Namespace打一個管控標，則Webhook對這類Namespace就主動做降級處理，不再校驗攔截。這樣運維就可以正常地做批量刪除動作。

②NS-CRD|CR 防誤刪：

K8S WebHook 機制，是可以對任意帶Namespace的CRD|CR進行攔截。其攔截邏輯是可以共享的，只是資源類型不一樣。所以我們可以動態配置，攔截邏輯對哪些資源生效。

支持 Ingress、WorkLoad、Service、ConfigMap、Secret、Pod ... 類型資源，并支持標簽篩選能力

高危配置校驗：

對于 Ingress 規則配置比較復雜，很多初學者會犯一些低級錯誤。比如：rule.host 配置為 '*' ，這意味著該規則匹配所有域名，所有請求都會過這條規則進行轉發，顯然生產環境這種配置是不合理的。而且一旦配置上可能會覆蓋掉大量的rule，導致生產故障。所以這類低級錯誤配置一定要攔截，不允許配置。

這里就簡單畫下方案圖，大致基本借助于webhook的能力，對一些刪除動作的時候加強校驗與攔截的機制。

四、總結

上述幾個案例都是得物容器SRE團隊在日常工作中真實發生的事件，覆蓋的也只是多項工作中的冰山一角，寫這篇文章也是想讓大家認知到我們團隊，了解我們容器SRE。由于篇幅有限其余細節不再展開了，大家有疑問歡迎找我們討論。