作者：Ben McCormack (Evernote)，William Bonnell (The Home Depot)，

編輯：Garrett Plasky (Evernote)，Alex Hidalgo，Betsy Beyer和Dave Rensin

儘管SRE的許多原則都是在Google內部形成的，但它的原則早已存在於Google之外。許多Google SRE的標準已被業內多個組織實踐應用。

SLO是SRE模型的基礎。自從我們組建了客戶可靠性工程（CRE）團隊——這是一組幫助Google Cloud Platform（GCP）客戶構建更可靠的服務的經驗豐富的SRE——幾乎與每個客戶互動都以SLO開始以SLO結束。

我們在這裡介紹了兩個不同行業的公司事蹟，概述了他們在與Google CRE團隊合作時採納SLO和基於錯誤預算的方法的過程。有關SLO和錯誤預算的討論，請參閱本書的第2章和第一本書的第3章。

 

Evernote的SLO故事

Evernote是一款跨平臺的APP，可幫助個人和團隊建立、整合和共享資訊。在全球擁有超過2.2億使用者，我們在平臺記憶體儲了超過120億條資訊——包括文字筆記、檔案和附件/影象。在後臺，Evernote服務由750個以上的MySQL例項支援。

我們向Evernote引入了SLO的概念，並將其作為更廣泛的技術改造的一部分，旨在提高工程速度，同時保持服務質量。我們的目標包括：

• 將工程重點從資料中心中冗餘的繁重工作轉移到客戶實際關心的產品工程工作上。為此，我們停止執行物理資料中心並轉移到公有云。

• 調整運維和軟體工程師的工作模式，旨在保持整體服務質量的同時提高變更速度。

• 改進我們對SLA的看法，以確保我們更加關注故障對龐大的客戶群所造成的的影響。

這些目標對許多行業的組織而言可能都很熟悉。雖然沒有一種方法可以全面實現這些型別的變更，但希望我們分享的經驗可以為面臨類似挑戰的人提供有價值的參考意見。

 

為什麼Evernote採用SRE模型？

過渡開始階段的Evernote的特點是傳統的運維和開發分離：運維團隊維護生產環境的穩定性，而開發團隊的任務是為客戶開發新的產品功能。這些目標通常是衝突的：開發團隊 感覺被繁瑣的流程所束縛，而運維團隊又會因新程式碼在生產環境中引入新的問題變得不滿。 當我們在這兩個目標之間不斷動搖時，運維和開發團隊之間蔓延了一種不滿和緊張的關係。我們希望達到一個雙方都滿意的節點，更好地平衡所涉及團隊的不同需求。

在五年多的時間裡，我們嘗試了各種方式解決這種傳統二分法中的差距。在嘗試了“你編碼，你執行”的開發模式，以及“你編碼，我們為你執行”的運維模式之後，我們轉向了以SLO為中心的SRE方法。

那麼是什麼促使Evernote向這個方向發展呢？

在Evernote，我們將運維和開發的核心目標視為工程師專業化的獨立發展方向。一個方向關注的是近乎7*24小時地持續為客戶提供服務。另一個關注的是服務的擴充套件和發展，以滿足客戶未來的需求。近年來，這兩個方向已經越來越接近，例如SRE和DevOps強調將軟體開發應用於運維。（資料中心自動化和公有云的發展進一步推動了這種融合，這兩者都為我們提供了一個可以完全由軟體控制的資料中心。）另一方面，全棧所有權和持續部署也越來越多地應用於軟體開發。

SRE模型完全接受幷包容了運維和開發間的差異，同時鼓勵團隊朝著共同的目標努力。它並不試圖將運維工程師轉變為應用程式開發人員，反之亦然。相反，它給出了一個共同的參考框架。根據我們的經驗，由於使用錯誤預算/SLO方法的兩個團隊在交流時很少帶著主觀感情，所以在面對同樣的情況時通常會做出類似的決定。

 

SLO簡介：正在進行的旅程

旅程的第一步是從物理資料中心遷移到Google雲平臺。當Evernote服務在GCP上穩定執行後，我們就引入了SLO。我們的目標有兩個：

• 確保所有團隊都在Evernote SLO的新框架內工作。

• 將Evernote的SLO納入我們與Google 雲團隊的合作中，他們現在負責我們的底層基礎架構。由於在整體模型中加入了新的合作伙伴，因此我們需要確保遷移到GCP不會影響我們對使用者的承諾。

在使用SLO約9個月後，Evernote已經開始實踐使用其SLO的第3版了！

在深入瞭解SLO的技術細節之前，要先從客戶的角度開始提問： 你可以提供哪些承諾？與大多數服務類似，Evernote具有許多功能和選項，使用者可以通過各種創造性方式使用這些功能和選項。我們希望在一開始就關注最重要和最常見的客戶需求：Evernote服務的可用性，以便使用者能夠訪問和同步多個客戶端的內容。我們的SLO之旅從這個目標開始。通過關注服務正常執行時間， 我們完成了接入SLO的第一步。使用這種方法，我們可以清楚地表達我們衡量的內容以及衡量方法。

我們的第一份SLO檔案包含以下內容：

SLO的定義

這是一個（服務、系統）可用時間的計算方法：為某些服務或者是方法，在月級別的統計週期內設定了99.95%的可用性。這個資料是我們基於內部客戶支援團隊、產品團隊，尤其重要的是使用者共同討論得來的。我們特意選擇將SLO和日曆月而不是與滾動的時期進行關聯，就是為了使我們在進行服務複查時保持專注有序。

衡量什麼，以及如何衡量它

衡量度量

我們指定了一個服務終點，我們可以呼叫它來測試服務是否按預期執行。在我們的例子中，我們在服務中內建了一個狀態頁面，它可以執行我們的大部分堆疊並返回200狀態程式碼（如果一切正常）。

如何度量

我們想要一個定期呼叫狀態頁面的探測器。我們希望探測器完全位於我們的環境之外並獨立於我們的環境，因此我們可以測試所有元件，包括負載均衡。我們的目標是確保我們可以統計到GCP服務以及evernote應用任何、所有異常。但是，我們不希望隨機網路問題觸發誤報。我們選擇使用專門建立和執行此類探測器的第三方公司。我們選擇了Pingdom，但市場上還有很多其他產品。我們按如下方式進行衡量：

如何從監控資料計算SLO

最後，我們仔細記錄了我們如何根據從Pingdom收到的原始資料計算SLO。例如，我們指定了如何考慮維護視窗：我們無法假設我們所有的數億使用者都知道我們釋出的維護視窗。因此，不知情的使用者會將這些視窗視為通用和無法解釋的停機時間，因此我們的SLO計算將維護視為停機時間。

一旦我們定義了SLO，我們就必須使它發揮最大的價值。 我們希望SLO能夠推動軟體和運維方面的變革，讓我們的客戶更快樂並讓他們滿意。 怎麼做到最好？

• 探測頻率：我們每分鐘輪詢一次前端節點。

• 探測器的位置：此設定是可配置的; 我們目前在北美和歐洲使用多個探測器

• “down”的定義：如果一個探測器檢測結果為失敗，那麼這個節點會被標記為疑似宕機，然後第二個基於不同地理位置獨立部署的探測機會進行第二次確認。如果第二次檢查同樣也失敗了，出於計算SLO的目的這個節點會被標記為宕機。只要探測請求持續顯示錯誤，那麼這個節點會被持續標記為宕機。

我們用SLO中有關錯誤預算的思維為方法來分配下一步工作的需要的資源。舉例來說，如果我們沒有達成上個月的SLO，這會促使我們高優（對系統、服務）進行目標明確的加固、改進和修復。我們制定最簡原則：evernote團隊以及google團隊共同進行月級別 的SLO目標複查。在這個會議上，我們複核SLO的表現並對所有服務中斷行為進行深入研究。基於針對上個月的上述分析而不是根因分析，我們制定了一些改進措施。

在整個過程中，我們的指導原則是“過猶不及”。即使在SLO還沒有達到完美的時候，它也足以在此期間指導我們進行改進。一個“完美”的SLO應該可以衡量每一個與我們服務有關的潛在使用者互動設計並且解釋所有的邊界行為。雖然字面上看起來這是個好主意，但是如果要實現起來卻要花費數月的時間去改進服務（如果真的可以這到完美）。相反，我們選擇了一個初始SLO，涵蓋了大多數（但不是全部）使用者互動，這是服務質量的良好代理。

自從我們開始執行SLO以來，根據從服務覆盤以及響應客戶有感的宕機事件中得到的啟示，我們對SLO做了兩次修改。因為我們一開始就沒有追求完美SLO，為了適應業務的發展我們樂於做出改變。除了evernote團隊與google進行月級別SLO覆盤之外，我們也設定了一個6個月的SLO覆盤週期，這個週期可以使SLO的維護達到一個平衡：既不會頻繁更新，也不會使之過時。在不斷修訂SLO的過程中，我們也意識到了，期望的衡量標準和可以達到的衡量標準之間的平衡是很重要的。

自引入SLO以來，我們的運維和開發團隊之間的關係有了微妙但顯著的改善。現在團隊對成功有了共同的衡量標準，那就是：取消對服務質量的人為解釋使兩個團隊達成了共同的觀點和標準。在此我們試著舉一個例子，2017年當我們不得不在短期內推動多個版本的釋出任務時，SLO為我們提供了共同基礎。當我們發現一個複雜的bug時，產品開發團隊要求我們將常規的周級別釋出任務分配到多個獨立的釋出視窗，每個釋出視窗都會對客戶產生潛在的影響。通過對問題進行有針對性的SLO計算以及消除方案中的人為主觀因素，我們可以更好的量化客戶感受並且通過把釋出視窗由5個降為2個從而達到了減少了客戶痛點的目的。

 

打破客戶與雲服務商之間的隔閡

介於客戶和雲服務商之間的隔閡看起來是在所難免的。雖然google已經為執行evernote的GCP平臺設定了SLO和SLA（服務等級協議），但是evernote有自己的SLO和SLA。期望兩個技術團隊會將彼此的SLA告知對方看起來是不現實的。

evernote不希望存在這樣的隔閡。當然我們也可以基於自己的SLO和底層的GCP平臺的SLA建立起隔離域，相反從一開始我們就希望google可以理解效能表現對我們來說是多重要以及為什麼這麼重要。我們期望google和我們在目標上達成一致，讓兩家公司把evernote在可靠性方向的成敗當作共同的職責。為了實現這一目標，我們需要一種方法可以：

達成一致的目標

確保我們的合作伙伴（在此指google）真正清楚我們最關心哪些指標

共擔成敗

大多數服務商都為自己的雲服務釋出了SLO/SLA。雖然服務執行在此框架下很重要，但這並不能全面的反映我們的服務在雲服務商的環境中執行的狀況。

例如，一個給定的雲服務商可能在全球運行了數十萬臺虛擬機器，他們為這些虛機的正常執行和可靠性負責。GCP承諾計算引擎（也就是虛機）可以達到99.95%的可靠性。即使當GCP SLO指標顯示為綠色的時候（即可靠性高於99.95%），evernote的監控檢視的表現可能完全不同：因為我們的虛機在GCP全球總量虛機中僅佔有很小的比例，會使導致我們（服務所在）區域成為孤島（或由於其他原因導致成為孤島）的故障最終在全球級別的彙總中被忽略。

為了修正這樣的情況，我們將我們的SLO和未達成SLO的實時效能與goolge進行共享。因此，Google CRE團隊和Evernote團隊基於同樣的效能儀表盤展開合作。這看起來似乎是一個很簡單的觀點，但最終被證明是一種相當有效的、可以形成真正以客戶為中心的工作方法。因此，google會向我們提供更明確的環境執行情況通知，而不是那種泛泛的“x服務當前執行緩慢”的通知。舉例來說，除了那種泛泛的“今天GCP負載均衡環境執行緩慢”之外，我們還會被告知這個問題已經對evernote的SLO造成了5%的影響。這種關係也有助於google內部團隊瞭解他們的行為和決策是如何影響使用者的。

這種雙向關係也為我們提供了一個非常有效的框架來應對重大事件。大多數情況下，P1-P5級別的工單和常規的支援渠道配合使用，產生了很好的效果，使我們能夠提供穩定的服務，並與谷歌保持良好的合作關係。但眾所周知，當你整個線上服務面臨著拓展業務增長的壓力的時候，P1級別的工單是不能滿足要求的。

這時，我們與CRE團隊共享的SLO和（合作）關係得以實現。我們達成共識，如果SLO影響足夠高，雙方都會將該問題視為P1級別進行特殊處理。這就意味著evernote和google的cre團隊經常要快速組織起一個可以共享的溝通渠道。Google CRE團隊監控（管理）我們共同定義和商定的SLO，使我們在優先順序和恰當響應方面保持同步。

 

當前狀態

• 協調目標

• 確保我們的合作伙伴（在本例中為Google）真正瞭解對我們重要的內容

• 分享成功和失敗

在積極使用SLO大約九個月之後，Evernote已經在使用SLO實踐的第三版了。下一個版本的SLO會以我們當前簡單正常執行時間的SLO為基礎進行改進。我們將關注單個API呼叫和客戶端的指標/效能檢視，以便更好地表示使用者QoS。

通過提供標準定義的QoS測量方法，SLO使Evernote更關注我們的服務是如何執行的。我們內部或者和谷歌進行以資料為驅動的對話，瞭解服務中斷的影響，這能夠推動服務改進，最終建立更強大的支援團隊，使客戶更滿意。

 

Home Depot的SLO故事

Home Depot（THD）是全球最大的家居裝飾零售商：我們在北美擁有2,200多家商店，每家商店都擁有超過35,000種產品（網站上有超過150萬種產品）。 我們的基礎架構託管各種軟體應用程式，支援了近400,000名員工每年處理超過15億的客戶交易。這些商店由全球供應鏈和每年訪問量超過20億次電子商務網站緊密組成。

最近為了提高我們軟體開發的速度和質量，THD轉向敏捷軟體開發並改變了我們設計和管理軟體的方式。我們從支援大型軟體包開發的團隊轉變為小型獨立的微服務架構開發團隊。因此，我們的系統現在由一系列不斷變更的微服務組成，這些微服務也是通過堆疊整合而成。

我們向微服務轉變的過程中，全棧所有權獲得了新的“自由和責任文化”的補充。這種方法使開發人員可以自由地在需要時推送程式碼，同時也使他們為他們對服務的操作負責。對於這種共同所有權工作模式，運維和開發團隊需要達成一種共識，即促進責任制和減少複雜性：SLO。相互依賴的服務需要知道如下資訊：

如果每項服務都能為這些問題提供明確的和一致的答案，那麼團隊就可以清楚地瞭解服務的依賴關係，從而達到更好地溝通，增強團隊之間的信任和責任感。

 

SLO文化專案

在我們的服務模式開始轉變之前，Home Depot沒有SLO文化。監控工具和儀表盤特別多，但都分佈在各處，並且不會隨著時間的推移記錄資料。我們並不總能查出服務中斷的根因。我們通常從遇到的服務問題開始排查，直到我們發現問題為止，這浪費了無數個小時。如果服務需要計劃停機時間，其依賴服務就會受不了。如果一個團隊需要構建一個99.95%的服務，他們不確定有嚴格依賴的服務能否達到99.99%的標準。這些未知導致我們的軟體開發團隊和運維團隊之間的疑惑和失望。

我們需要通過建立SLO的共同文化來解決這些問題。因此，需要一個影響人員、流程和技術的總體戰略。 我們的努力跨越了四個方面：

內部名詞規定：

在THD（Home Depot）公司內部定義SLOs。 來說明如何以一致的方式來進行度量。

福音主義

在整個公司傳播這個詞。

• 通過給銷售提供培訓資料，在公司進行路演、內部部落格、宣傳資料比如T恤和貼紙等方式，傳播為什麼SLO很重要。

• 爭取一些早期採用者來實施SLO並向其他人展示其價值。

• 建立一個感興趣的首字母縮略詞（VALET;稍後討論）以幫助傳播這個想法。

• 建立培訓計劃（FiRE學院：可靠性工程基礎），對開發人員進行培訓使其瞭解SLO和其他可靠性概念。

自動化

為了降低指標收集的難度，用一個指標收集平臺去自動收集生產環境中的服務的服務等級指標。這些SLI以後可以更容易地轉換為SLO。

激勵

為所有開發經理制定年度目標，為其服務設定和衡量SLO。

每個人達成共識很重要。我們還希望保持這個框架儘可能簡單，以幫助這個想法更快地傳播。為了開始，我們仔細研究了我們在各種服務中監控的指標，並發現了一些模式。每項服務都會監控某種形式的流量、延遲、錯誤和利用率指標，這些指標與Google SRE的四個黃金指標密切相關。此外，許多服務都可以從錯誤中明顯監控正常執行時間或可用性。很遺憾，整體來看，並不是所有型別的採集項都統一添加了監控、統一了命名、或者有足夠的監控資料。

我們的服務都沒有SLO。我們的生產系統與面向客戶的SLO最接近的指標是（使用者）支援資料。通過跟蹤商店內諮詢臺接收到的支援電話數量，是我們評價部署在我們商店的應用可靠性的主要（大多數時候是唯一）方法。

 

我們的第一套SLO

我們不能對一個可度量系統的每個方面都建立SLOs，因此我們必須確定系統的哪些指標或SLIS應該具有SLOs。

 

API呼叫的可用性和延遲

我們決定對微服務之間的API呼叫設定可用性和延遲SLOs。例如，Cart微服務呼叫Inventory微服務。針對那些API呼叫，Inventory微服務釋出了SLOs，Cart微服務（以及需要Inventory的其他微服務）可以獲取這些SLOs並以此決定Inventory微服務是否能滿足可靠性要求 基礎設施利用/基礎設施利用率。

 

基礎設施利用率

THD團隊通過不同的方式來衡量基礎設施利用率，而最典型的衡量標準是分鐘級別的實時基礎設施利用率。我們基於某些原因並不會設定這種利用率SLOs。首先，微服務並非十分關注這個指標-只要服務可以承載流量，伺服器正常執行、響應速度很快、不拋錯誤，且並不會耗盡容量，那麼你的使用者就不會真正關心利用率。此外，計劃遷移服務到雲端意味著資源利用率不是重點，這時我們要關注的是成本規劃，而不是容量規劃。（我們仍然需要監控利用率並執行容量規劃，但不需要將其包括在我們的SLO框架內。）

 

流量

由於THD沒有進行容量規劃的傳統，因此我們需要一種機制，該機制能讓開發和運維團隊就其服務可以承載的流量進行溝通。流量通常被定義為對服務的請求，但我們需要確定是否應該跟蹤平均每秒請求數，每秒峰值請求數或報告時間段內的請求數。最終我們決定跟蹤這三項，並給每項服務選擇最合適的指標。我們討論是否為流量設定SLO的原因在於這個指標是由使用者行為決定的，而非我們可控的內部因素決定。我們要討論是否為流量設定SLO，因為流量的衡量跟使用者行為密切相關，我們可控的內部因素無法發揮決定作用。 最終我們認為，作為零售商，我們需要為應對黑色星期五這樣的活動流量峰值增加服務的規模，並根據預期的峰值流量設定SLO。

 

延遲

我們給每個服務定義了延遲SLO並確定其最佳的衡量方式。這裡我們只要求服務應該通過黑盒監控來補充我們常見的白盒效能監控，以捕獲由網路或諸如快取以及微服務外部代理失效等層面的問題。並且，我們認為，採用百分位數比算術平均值更合適。服務最少需要達到90％的目標，而面向使用者的服務則最好達到95%或99%的目標。

 

錯誤

錯誤解釋起來有點複雜。由於我們主要處理Web服務，因此我們必須將錯誤內容以及返回結果標準化。如果Web服務發生錯誤，我們自然會對HTTP響應程式碼進行標準化：

. 在服務的返回內容中，不應該用2xx來標記錯誤; 相反，一個錯誤應該丟擲4xx或5xx。

. 由服務端問題（如記憶體不足）引起的錯誤應該丟擲5xx錯誤。

. 客戶端錯誤（如傳送錯誤格式的請求）應該丟擲4xx錯誤.

一番考慮後，我們決定跟蹤4xx和5xx錯誤，但僅使用5xx錯誤來設定SLOs。與定義其他相關SLO的方法類似，我們採用通用形式來定義錯誤SLO，以便不同環境中的不同應用都可以使用該SLO。例如，除HTTP錯誤外，定義一個批處理服務的錯誤，可能是該服務無法處理記錄的個數。

 

工單

正如前面提到的，工單最初是我們評估大多數生產軟體的主要方式。由於歷史原因，在我們其他的SLOs中，我們決定繼續跟蹤工單。你可以將該指標視為類似於“軟體操作級別”的指標。

 

VALET

我們將新的SLOs概括為一個更簡易的縮略詞：VALET。

容量（流量）

服務可以處理多少業務量？

可用性

需要的時候服務是否正在執行？

延遲

使用時服務是否快速響應？

錯誤

使用時服務是否會丟擲錯誤？

工單

服務是否需要人為干預才能完成請求？

 

推廣SLOs

憑藉這樣一個易於記憶的縮略詞，我們開始在企業內部推廣SLOs：

. 為何SLOs如此重要

. SLOs是怎樣與我們的“自由和責任”文化相契合的

. 應該衡量什麼

. 如何處理結果

因為開發人員現在要負責維護他們自己的軟體，因此他們需要建立SLOs以體現他們開發和維護軟體可靠性的能力，針對面向使用者的服務，他們需要同服務使用者和產品經理進行交流。然而，他們中多數人並不熟悉諸如SLAs和SLOs這樣的概念，因此他們需要接受VALET框架方面的培訓。

由於我們需要獲得強有力的支援來推廣SLOs，因此一開始我們可以面向高階領導者進行SLOs的推廣講解。然後逐個向開發團隊講述SLOs的價值觀。我們鼓勵團隊從他們自定義的度量跟蹤機制（通常是人為制定）轉向VALET框架。為了保持這種推廣態勢，我們每週傳送一份VALET格式的SLO報告給高層領導，這份報告結合了可靠性理念和從內部事件中吸取的經驗。這也有助於構建業務指標，例如在VALET框架下，建立的採購訂單（流量）或支付訂單失敗（錯誤）。

我們還以多種方式擴充套件了我們的推廣渠道：

. 我們建立了一個內部WordPress網站來託管有關VALET和可靠性的部落格，並將其連結到相關資源。

. 我們組織內部技術講座（包括Google SRE演講嘉賓），討論了通用可靠性概念以及如何使用VALET進行度量。

. 我們開展了一系列VALET培訓研討會（之後將演變為FiRE學院），並向所有想參加的人開放，這些研討會持續了好幾個月。

. 我們甚至製作了VALET膝上型電腦貼紙和文化衫，用來支援全面的內部推廣活動。

很快，公司裡的每個人都知道了VALET這一概念，並且我們的SLOs新文化開始在公司佔據主流。對開發負責人來講，實施SLO甚至已正式成為其年度績效評估指標。雖然大約有50項服務正在按周級別獲取並報告其SLOs，但我們會將這些指標儲存在電子表格中。雖然VALET的思想已經非常流行，但為了讓其更廣泛地被接納，我們仍然需要自動化技術來進行資料的收集。

 

自動化VALET資料收集

雖然我們的SLO文化現在有了強大的立足點，但自動化VALET資料收集將加速SLO的應用。

 

TPS報告

我們構建了一個框架來自動捕獲部署到新GCP環境的任何服務的VALET資料。我們將此框架稱為TPS報告，這是我們用於數量和效能測試的術語（每秒交易次數），當然，也是為了滿足多個管理者想要檢視這些資料的想法。 我們在GCP的BigQuery資料庫平臺之上構建了TPS Reports框架。我們的Web服務前端生成的所有日誌都被輸入BigQuery以供TPS Reports處理。當然也包括來自各種監控系統的指標，例如Stackdriver的可用性指標。

TPS報告將這些資料轉換為任何人都可以查詢的每小時VALET指標。新建立的服務自動註冊到TPS報告中，因此可以立即查詢。由於資料全部儲存在BigQuery中，因此我們可以跨時間幀有效地報告VALET指標。我們使用此資料構建了各種自動報告和警報。 最有趣的整合是一個聊天機器人，讓我們直接在商業聊天平臺上報告服務的VALET。例如，任何服務都可以顯示過去一小時的VALET，前一週的VALET，未達成SLO的服務以及聊天頻道內的各種其他值得引起關注的資料。

 

VALET服務

我們的下一步是建立一個VALET應用程式來儲存和報告SLO資料。因為SLO最適合用作趨勢工具，所以該服務以每日、每週和每月粒度跟蹤SLO。請注意，我們的SLO是一種趨勢工具，我們可以將其用於錯誤預估，但不直接連線到我們的監控系統。相反，我們有各種不同的監控平臺，每個平臺都有自己的警報。這些監控系統每天彙總其SLO併發布到VALET服務以進行趨勢分析。此設定的缺點是監控系統中設定的警報閾值未與SLO整合。 但是，我們可以根據需要靈活地更換監控系統。

預計需要將VALET與未在GCP中執行的其他應用程式整合，我們建立了一個VALET整合層，該層提供API來收集聚合的VALET資料以生成服務日報。TPS Reports是第一個與VALET服務整合的系統，我們最終集成了各種本地應用程式平臺（佔在VALET中註冊的服務的一半以上）。

 

VALTE 儀表盤

VALET儀表板（如圖3-1所示）是我們用於視覺化和報告此資料的UI，並且相對簡單。 它允許使用者：

圖3-1 VALET儀表盤

• 註冊新服務。 這通常意味著將服務分配給一個或多個URL，這些URL可能已經收集了VALET資料。

• 為五個VALET類別中的任何一個設定SLO目標。

• 在每個VALET類別下新增新的指標型別。 例如，一個服務採集99%的請求所用的延遲，而另一個服務採集90%的請求所用（或兩者）的延遲。或者，後端處理系統可以跟蹤每日總量（一天內建立的採購訂單），而客戶服務的前端可以跟蹤每秒交易的峰值。

VALET儀表盤允許使用者一次報告許多服務的SLO，並以多種方式對資料進行切片和切塊。例如，團隊可以檢視過去一週未達到SLO的所有服務的統計資訊。負責覆盤服務效能的團隊可以檢視其所有服務及其所依賴的服務的延遲。VALET儀表盤將資料儲存在一個簡單的Cloud SQL資料庫中，開發人員使用流行的商業報告工具來構建報告。

這些報告成為開發人員新的最佳實踐的基礎：定期對其服務進行SLO稽核（通常是每週或每月）。基於這些，開發人員可以建立操作項以使服務迴歸SLO，或者可能按照需要調整不符合實際的SLO。

 

SLOs的擴散

一旦SLOs融入到組織的集體思想中，並且具備了有效的自動化技術和報表，那麼新的SLOs就可以快速實施。在年初跟蹤了約50項服務的SLOs之後，到今年年底我們正在跟蹤800項服務的SLOs，每月約有50項新服務在VALET註冊。

由於VALET允許我們在THD中推廣SLO的應用，因此自動化開發這項工作是非常有意義的。但是，不具備這種自動化開發能力的公司也不用擔心採用SLO會帶來的麻煩。雖然自動化為THD提供了額外的收益，但一開始就編寫SLO也收益頗多。

 

將VALET應用於批處理應用程式

當我們圍繞SLO開發強大的報表時，我們發現了VALET的一些其他用途。 經過一些調整，批處理應用程式可以適用此框架，如下所示：

數量

已處理的記錄數量

可用性

在一定時間內完成工作的頻率（百分比）

等待時間

作業執行所需的時間

錯誤

程式執行失敗的記錄

工單

操作員必須手動修復資料和重新處理作業的次數

 

在測試中使用VALET

由於在發展SRE文化的同時，我們發現在臨時環境中，VALET可以支援我們的破壞性測試（混沌工程）自動化。有了TPS Reports框架，我們就可以自動進行破壞性測試並記錄對service’s VALET data造成的影響（希望沒有影響）。

 

未來展望

通過800個（並且不斷增長）服務來收集VALET資料，我們可以擁有大量有用的運營資料。我們對未來有幾個期望。

既然我們正在有效地收集SLO，我們希望使用這些資料來採取行動。我們的下一步是類似於Google的錯誤預算文化，當服務不在SLO時，團隊停止推送新功能（除了提高可靠性相關的）。為了滿足業務增長的需求，需要平衡SLO報告的生成頻率（周級別或月級別）和SLO標準的更新頻率。和許多采用錯誤預算的公司一樣，我們正在權衡滾動視窗與固定視窗的優缺點。

我們希望進一步優化VALET以跟蹤詳細的節點和服務的使用者。目前，即使特定服務具有多個節點，我們也只在整個服務中跟蹤VALET。因此，很難區分不同的操作（例如，對目錄的寫入與對目錄的讀取；雖然我們對這些操作添加了單獨的監控和報警，但不跟蹤SLO）。同樣，我們也很樂意為服務的不同消費者提供對應的VALET結果。

雖然我們目前在Web服務層跟蹤延遲SLO，但我們還希望跟蹤終端使用者的延遲SLO。此度量將捕獲網路延遲和CDN快取等因素如何影響頁面開始呈現和完成呈現所需的時間。

我們還想將VALET資料擴充套件到應用程式部署。具體來說，在將更改推廣到下一個伺服器、域或區域之前，我們希望自動化驗證VALET是否在容差範圍內。

我們已經開始收集有關服務依賴性的資訊，並且製作了一個視覺化圖表原型，該圖表顯示了我們在呼叫樹中未觸及到VALET指標的位置。 新興的網格服務平臺將簡化這種分析。

最後，我們堅信服務的SLO應該由服務的業務所有者（通常稱為產品經理）根據其業務的重要性來設定。至少，我們希望業務所有者設定服務正常執行時間的最低要求，並將SLO用作產品管理和開發之間的共享目標。雖然技術人員發現VALET很直觀，但對於產品經理來說，這個概念並不那麼直觀。我們正在努力使用與它們相關的術語來簡化VALET的概念：我們既簡化了正常執行時間的選擇數量又提供了示例指標。我們還強調從一個級別轉移到另一個級別所需的大量投入。以下是我們可能提供的簡化VALET指標的示例：

. 99.5％：商店員工使用次數很少的應用程式或新服務。

. 99.9％：適用於THD的大多數非銷售系統

. 99.95％：銷售系統（或支援銷售系統的服務）

. 99.99％：共享的基礎設施服務

以業務術語來衡量指標並在產品和開發之間共享可見目標（SLO！），這種行為將大量減少公司常見的對可靠性的錯誤預期。

 

概要

向大公司介紹一個新流程，都需要一個好的策略、高管的支援、強大的傳播、簡單的採用模式以及最重要的耐心，更不用說是一個新文化了。像SLO這樣的重大變革可能需要數年才能在公司中牢固地建立起來。我們想強調的是，Home Depot是一家傳統企業;如果我們能夠成功地引入這麼大的變化，那麼你也可以。你也不必一次完成這個任務。雖然我們逐步實施SLO，但制定全面的傳播策略和明確的激勵結構促進了快速轉型：我們在不到一年的時間內獲得了從0到800的SLO服務支援。

 

結論

SLO和錯誤預算為解決許多不同問題提供了強大的理論支援。這些來自Evernote和Home Depot的案例研究提供了非常真實的例子，說明如何實施SLO文化可以使產品開發和運維更緊密地結合在一起。這樣做可以促進溝通並更好地為制定決策提供資訊。它最終將為你的客戶帶來更好的體驗 - 無論這些客戶是內部、外部、人類還是其他服務。

這兩個案例研究強調實現SLO文化是一個持續的過程，而不是一次性修復或解決方案。雖然它們共享哲學基礎，但THD和Evernote的度量風格、SLIs、SLOs和實現細節明顯不同。這兩個案例都補充了谷歌對SLOs的看法，說明了SLO實現不一定是Google所特有的。正如這些公司為自己獨特的環境量身定製SLO一樣，其他公司和組織也可以這樣做。