定義服務的SLI和SLO，通過全局系統呈現、處理所有服務的SLI/SLO，從而幫助SRE實踐在系統中的落地。本文介紹了Facebook（Meta）在這方面的實踐。原文：SLICK: Adopting SLOs for improved reliability

我們需要與使用我們的應用程序和產品的人們和社區不斷保持聯系，從而為他們提供足夠的支持。我們希望將可靠性方面的經驗提供出來，與我們支持的更大的社區建立信任關系。在像Meta（Facebook的新名字）這樣大規模、快速發展的環境中，有成千上萬的工程師在頻繁部署代碼、創建特性原型，并對更改進行迭代，因此保障可靠性的工作尤其具有挑戰性。我們需要對每個產品、功能和服務有明確的期望，從而可以更好的為使用我們服務的用戶提供可視化的體驗，并分析系統之間的任何瓶頸或復雜的交互。

我們開始研究服務水平指標（SLIs，service-level indicators）和服務水平目標（SLOs，service-level objectives），將其作為期望的設置，并根據這些期望度量服務的性能。為了提供工具支持，我們構建了SLICK，這可以看作是一個專門的SLO商店。有了SLICK，我們能夠集中SLI和SLO定義，從而輕松找到和理解另一個服務的可靠性。SLICK可以利用高留存率，以及其他工具無法找到的關鍵服務指標的完整粒度數據，為服務開發團隊提供洞見，并將SLO與公司的其他各種工作流集成起來，以確保SLO成為日常工作的一部分。

在SLICK出現之前，SLO和其他性能指標存儲在定制的儀表板、文檔或其他工具中。如果想要定位團隊的SLO，可能需要花費一個小時的時間來搜索或要求人們找到相關的數據。此外，之前的系統并沒有以完整的粒度長時間（超過幾周）保留這些指標，這使得對SLO進行更長時間的分析幾乎是不可能的。有了SLICK，我們現在能夠：

以一致的方式為服務定義SLO

精度高達分鐘級別的度量數據，最多可保留兩年

對SLI/SLO指標有標準的可視化和洞見

定期向內部小組發送可靠性報告，允許團隊基于這些報告進行可靠性檢查

可發現性（Discoverability）

SLICK定義了一個標準的模型，幫助公司里的每個人用同樣的術語討論可靠性。這使得新的服務開發團隊能夠無縫遵循公司范圍的標準，在服務的早期設計階段就考慮到服務需要達到的可靠性期望。

只要知道服務名，SLICK就可以幫助我們定位特定服務的可靠性指標和性能數據。SLICK通過構建內置的服務索引來實現這一點，該索引鏈接到帶有標準可視化的儀表板，以分析和評估服務的可靠性。因此，只需單擊一下，就可以知道服務當前是否滿足用戶的期望，如果有任何問題，就可以馬上開始尋找答案。

上圖是SLICK的SLO索引搜索示例

長期洞察（Long-term insights）

服務可靠性的問題非常復雜。在某些情況下，單個錯誤的部署或某一段代碼的變更可能就會導致服務突然退化。而在其他情況下，有可能隨著服務的發展，不斷累積微小的不可靠因素。

SLICK允許服務所有者使用最長可達兩年的完整粒度的度量和性能數據。SLICK中的存儲過程每小時運行一次數據管道，捕獲所有SLI時間序列數據，并將它們存儲在分片的MySQL數據庫中。然后分析這些內容，形成可消費的洞見。這使得每個人——從工程師到TPM到領導——都能夠了解隨著時間的推移，可能會出現的服務可靠性的退化，而這些信息在之前很有可能會被忽視。

工作流（Workflows）

為了放大價值并幫助我們使用新的長期洞見來推動決策，SLI和SLO需要使用一種人人都能理解和使用的語言來規劃和評估影響。為了實現這一點，我們將SLO集成到公共工作流中。

當大規模事件發生時，通過查看實時工具中的SLO，服務開發團隊可以評估其對整體用戶體驗的影響。另一方面，當發生重大事件時，也可以基于SLO來驅動處理流程。我們首先使用SLO作為公司內部事件的標準，其他系統可以使用這些標準來獲得用戶看到的問題的警報。

從本質上說，將SLI和SLO集成到其他工具中，可以方便的將尚未引入的服務引入到SLICK中，從而以易于訪問和易于使用的方式獲得有效的見解。

SLICK引入（SLICK onboarding）

服務開發團隊通過UI或者編寫一個簡單的配置文件來支持SLICK，該文件遵循帶有服務名稱等信息的DSL，可以查詢SLI時間序列以及相應的SLO。

在用戶測試并提交配置之后，SLICK會自動將服務添加到索引中，然后生成特定于服務的指示板，并開始收集數據以進行長期觀測。除了這個配置文件，其他所有集成都是開箱即用的。

使用SLICK

1）儀表板

SLICK儀表板為服務開發團隊提供了監控實時SLI數據以及基于高留存率、長期數據的歷史趨勢的能力。

上圖：左邊以完整的粒度說明了SLI時間序列。右側顯示基于時間的SLI值的每周聚合和SLO的相對差距。

2）周期性報告

SLICK為工程師提供了SLO性能總結報告的能力，這些報告會定期發布給內部團隊。報告為服務開發團隊提供了一種簡單的方法來關注回歸并進行回顧，我們經?？吹椒臻_發團隊在這些帖子的評論中討論可靠性問題。

3）CLI

SLICK提供了命令行接口，使服務所有者能夠執行某些操作，比如回填數據、根據需要生成報告，或者測試對SLICK配置的更改的效果。

SLICK架構

總體架構

SLICK配置（SLICK CONFIGS）：使用SLICK的DSL編寫的配置文件，由用戶提交到SLICK配置存儲區。

SLICK同步器（SLICK SYNCER）：將對SLICK配置所做的更改同步到SLICK配置元數據存儲的服務。

SLICK UI：為每個服務生成的SLICK儀表板，SLICK UI還提供了前面提到的索引。

SLICK服務（SLICK SERVICE）：提供API的服務器，能夠回答諸如“如何為特定的可視化計算SLO？”這樣的問題。服務器允許我們抽象出關于數據存儲和分片的所有細節，使調用者能夠輕松找到所需數據。

SLICK數據流水線（SLICK DATA PIPELINES）：周期性運行的流水線，以便長期獲取SLI數據。

數據獲取詳細設計（Zooming in on the data ingestion）

SLICK每小時運行一次數據流水線，這些流水線通過查詢SLICK的配置元數據來查找所有SLI。流水線對被監控的數據集執行所有需要的查詢，以獲得以分鐘為粒度的當前時刻每個SLI的原始時間序列數據。

然后，流水線參考SLICK分片映射確定每個SLI的數據應該存儲在哪里，然后將數據批量插入到適當的分片中。

此外，可以執行數據質量檢查，從而使我們對數據流水線的操作方式充滿信心，并快速捕獲真正的錯誤。數據質量檢查針對一組確定性測試時間序列運行，用處理真實SLI序列同樣的方式處理這些確定性時間序列，也就是說，對它們執行流水線，將它們插入到分片數據庫中，最后，將數據庫中的行與預期的時間序列進行比較，以驗證系統的行為。

Meta應用SLICK的SLO的當前狀態

在2019年創建了SLICK后，我們發現到2021年，全公司已經有超過1000個服務接入了SLICK。我們還看到其他許多公司在可靠性方面的成功案例，下面會分享其中的一部分。請注意，出于保密原因，下面圖表使用了模擬數據，我們刪除了日期并略微修改了數值，但圖表的整體形狀保持不變。

LogDevice：回歸檢測和修復示例

LogDevice是我們的分布式日志存儲系統。服務開發團隊可以通過SLICK對讀可用性進行回歸檢查，并且可以基于這些數據修復回歸發現的問題，并通過SLICK確認修復恢復了讀取可用性的服務級別。

上圖：LogDevice可靠性(讀可用性)。此圖不按比例繪制，僅供討論之用。

后端ML服務可靠性示例

2020年，Meta公司一個關鍵后端ML系統開始出現顯著的可靠性退化，而這是一個影響到我們終端應用用戶的ML服務。

SLICK數據顯示，該服務始終沒有達到SLO要求，服務開發團隊能夠識別這種回歸，并幫助啟動了可靠性評估，從而幫助他們調查、發現和修復可靠性問題的根本原因。團隊解決了根本原因，服務回到了滿足SLO的狀態。

上圖：后端ML服務可靠性(可用性)。此圖不按比例繪制，僅供討論之用。

我們的收獲

在推進SLO的過程中，我們走過了很長的一段路，并從中吸取了一些經驗教訓：

長期跟蹤能力非常有價值，能夠幫助我們了解趨勢，從而使我們可以計劃一段更長時間的可靠性工作。

SLO必須處于工程文化的中心，無論是在戰略可靠性規劃還是日常溝通中。

引入SLO有助加強我們服務的整體可靠性。

SLICK團隊將繼續致力于平臺的發展以提供更多的價值。我們特別希望在以下領域進行投資：

使服務的SLO與其依賴項的SLO保持一致。這將允許團隊理解他們的依賴關系如何影響他們的性能，還能幫助我們揭示調用棧中服務之間不匹配的期望值，而這些不匹配因素有可能觸發級聯失敗。

為服務開發團隊提供如何提高服務可靠性的反饋和建議。我們希望利用在提高可靠性方面的經驗，為服務開發團隊提供可操作的見解，以幫助他們提高可靠性并滿足SLO。

進一步發展SLICK的覆蓋范圍。我們希望在SLICK上搭載更多的團隊和服務，為了做到這一點，SLICK需要保持可靠性和可擴展性（滿足我們自己的SLO）。

編輯：黃飛