本文是 Uber 的工程師 Gergely Orosz 的文章，原文地址在：https://blog.pragmaticengineer.com/operating-a-high-scale-distributed-system/

在過去的幾年里，我一直在構(gòu)建和運(yùn)營一個(gè)大型分布式系統(tǒng)：優(yōu)步的支付系統(tǒng)。在此期間，我學(xué)到了很多關(guān)于分布式架構(gòu)概念的知識，并親眼目睹了高負(fù)載和高可用性系統(tǒng)運(yùn)行的挑戰(zhàn)（一個(gè)系統(tǒng)遠(yuǎn)遠(yuǎn)不是開發(fā)完了就完了，線上運(yùn)行的挑戰(zhàn)實(shí)際更大）。構(gòu)建系統(tǒng)本身是一項(xiàng)有趣的工作。規(guī)劃系統(tǒng)如何處理10x / 100x流量的增加，確保數(shù)據(jù)持久，面對硬件故障處理等等，這些都需要智慧。不管怎樣，運(yùn)維大型分布式系統(tǒng)對我來說是一次令人大開眼界的體驗(yàn)。

(資料圖)

系統(tǒng)越大，墨菲的“什么可能出錯(cuò)，就會出錯(cuò)”的定律就越會體現(xiàn)。頻繁部署、部署代碼的開發(fā)人員數(shù)量很多，涉及多個(gè)數(shù)據(jù)中心、系統(tǒng)被大量全球用戶使用，這種出錯(cuò)概率越大。在過去的幾年里，我經(jīng)歷過各種各樣的系統(tǒng)故障，其中很多讓我感到驚訝。有些來自可預(yù)測的事情，比如硬件故障或一些看起來無害的Bug，還有數(shù)據(jù)中心線纜被挖斷、同時(shí)發(fā)生多個(gè)級聯(lián)故障。我經(jīng)歷了數(shù)十次業(yè)務(wù)停擺，系統(tǒng)的某些部分無法正常工作，從而導(dǎo)致巨大的業(yè)務(wù)影響。

這篇文章是我在Uber工作時(shí)總結(jié)的，可以有效運(yùn)維大型系統(tǒng)的實(shí)踐的集合。我的經(jīng)驗(yàn)并不是獨(dú)一無二的 - 在類似規(guī)模的系統(tǒng)上工作的人也經(jīng)歷了類似的旅程。我與Google，F(xiàn)acebook和Netflix的工程師進(jìn)行了交談，他們分享了類似的經(jīng)驗(yàn)和解決方案。這里列出的許多想法和流程應(yīng)該適用于類似規(guī)模的系統(tǒng)，無論是在自己的數(shù)據(jù)中心（如Uber大多數(shù)情況下）上運(yùn)行，還是在云上運(yùn)行（Uber 有時(shí)會把部分服務(wù)彈性部署到云上）。但是，對于規(guī)模較小或較少關(guān)鍵任務(wù)的系統(tǒng)而言，這些做法可能過于苛刻。

涉及的內(nèi)容很多——我將討論以下主題：

監(jiān)控值班，異常檢測和警報(bào)故障和事件管理流程事后分析，事件回顧和持續(xù)改進(jìn)文化故障演習(xí)，容量規(guī)劃和黑盒測試SLOs、SLAs 及其報(bào)告SRE 作為獨(dú)立團(tuán)隊(duì)可靠性作為持續(xù)投入更多推薦閱讀監(jiān)控

要知道系統(tǒng)是否健康，我們需要回答“我的系統(tǒng)是否正常工作”的問題？為此，收集系統(tǒng)關(guān)鍵部分的數(shù)據(jù)至關(guān)重要。對于在多臺計(jì)算機(jī)和數(shù)據(jù)中心上運(yùn)行多個(gè)服務(wù)的分布式系統(tǒng)，可能很難確定要監(jiān)控的關(guān)鍵內(nèi)容是什么。

基礎(chǔ)設(shè)施健康監(jiān)測如果一個(gè)或多個(gè)計(jì)算機(jī)/虛擬機(jī)過載，則分布式系統(tǒng)的某些部分可能會降級。機(jī)器的健康狀況，CPU利用率、內(nèi)存使用情況，是值得監(jiān)控的基礎(chǔ)內(nèi)容。有些平臺可以開箱即用地處理這種監(jiān)控和自動擴(kuò)展實(shí)例。在優(yōu)步，我們擁有一支優(yōu)秀的核心基礎(chǔ)設(shè)施團(tuán)隊(duì)，提供開箱即用的基礎(chǔ)設(shè)施監(jiān)控和警報(bào)。不管技術(shù)層面如何實(shí)現(xiàn)，實(shí)例或基礎(chǔ)設(shè)施出問題的時(shí)候，監(jiān)控平臺需要提供必要的信息。

服務(wù)運(yùn)行狀況監(jiān)控：流量，錯(cuò)誤，延遲。我們經(jīng)常需要回答“這個(gè)后端服務(wù)是否健康？”這樣的問題。觀察訪問端點(diǎn)的請求流量、錯(cuò)誤率和端點(diǎn)延遲等事項(xiàng)都可以提供有關(guān)服務(wù)健康狀況的有價(jià)值信息。我更喜歡將這些都顯示在儀表板上。在構(gòu)建新服務(wù)時(shí)，通過使用正確的HTTP響應(yīng)映射并監(jiān)視相關(guān)代碼可以對系統(tǒng)有很多了解。因此，確?？蛻舳隋e(cuò)誤能返回4XX，以及如果服務(wù)器錯(cuò)誤則返回5xx，這種監(jiān)控易于構(gòu)建且易于解釋。

監(jiān)測延遲值得再考慮一下。對于生產(chǎn)服務(wù)，目標(biāo)是讓大多數(shù)最終用戶獲得良好的體驗(yàn)。事實(shí)證明，測量平均延遲并不是一個(gè)很好的指標(biāo)，因?yàn)檫@個(gè)平均值可以隱藏一小部分高延遲請求。測量p95，p99或p999 - 第95百分位，第99百分位或第99.9百分位的請求所經(jīng)歷的延遲 - 是一個(gè)更好的指標(biāo)。這些數(shù)字有助于回答諸如“99％的人的請求有多快？”之類的問題（p99）?；颉?000人中，至少有一人經(jīng)歷了多慢的延遲？” （p999）。對于那些對這個(gè)主題更感興趣的人，這篇延遲入門文章可以進(jìn)一步閱讀。

從圖上可以明顯看出，平均延遲、p95、p99 差異還是比較大的。所以平均延遲有可能掩蓋一些問題。

圍繞監(jiān)控和可觀察性有很多更有深度的內(nèi)容。值得一讀的兩個(gè)資源是Google的SRE書和關(guān)于分布式系統(tǒng)監(jiān)控的四個(gè)黃金指標(biāo)的部分。他們建議，如果您只能測量面向用戶的系統(tǒng)的四個(gè)指標(biāo)，請關(guān)注流量，錯(cuò)誤，延遲和飽和度。比較簡短的材料的話，推薦來自Cindy Sridharan的分布式系統(tǒng)可觀察性電子書，它涉及其他有用的工具，如事件日志，指標(biāo)和跟蹤最佳實(shí)踐。

業(yè)務(wù)指標(biāo)監(jiān)控。監(jiān)控服務(wù)模塊，可以告訴我們服務(wù)模塊運(yùn)行的如何如何正常，但無法告知我們業(yè)務(wù)是否按預(yù)期工作，是否“照常營業(yè)”。在支付系統(tǒng)，一個(gè)關(guān)鍵問題是，“人們可以使用特定的支付方式進(jìn)行支付業(yè)務(wù)嗎？”。識別業(yè)務(wù)事件并對其監(jiān)控，是最重要的監(jiān)控步驟之一。

雖然我們建立了各種監(jiān)控，有些業(yè)務(wù)問題仍然無法探測到，這讓我們遭受了巨大的痛苦，最終建立了業(yè)務(wù)指標(biāo)的監(jiān)控。有時(shí)我們所有的服務(wù)看起來都在正常運(yùn)行，但關(guān)鍵產(chǎn)品功能不可用！這種監(jiān)控對我們的組織和領(lǐng)域來說非常有用。因此，我們必須在Uber的可觀察性技術(shù)堆棧的基礎(chǔ)上，為自己定制這種類型的監(jiān)控做了大量的思考和努力。

譯者注：業(yè)務(wù)指標(biāo)監(jiān)控這一點(diǎn)，我們實(shí)在是太深有同感了，之前在滴滴有時(shí)就是發(fā)現(xiàn)所有服務(wù)都正常，但是業(yè)務(wù)不好使。我們現(xiàn)在創(chuàng)業(yè)做的北極星系統(tǒng)，就是專門應(yīng)對這個(gè)問題的。感興趣的朋友可以在公眾號后臺給我留言，或加我好友 picobyte 交流試用。

Oncall，異常檢測和警報(bào)

監(jiān)控對于洞察系統(tǒng)的當(dāng)前狀態(tài)而言，是一個(gè)很棒的工具。但這只是自動檢測問題并發(fā)出警報(bào)以供人們采取行動的一個(gè)墊腳石。

Oncall 本身是一個(gè)廣泛的話題 - Increment 雜志在其 “On-Call 問題”中涵蓋了許多方面的內(nèi)容。我的強(qiáng)烈認(rèn)為，如果你擁有了"you build it, you own it"的心態(tài)，那隨著而來的就是 OnCall。構(gòu)建服務(wù)的團(tuán)隊(duì)擁有這些服務(wù)，也負(fù)責(zé)值班。我們的團(tuán)隊(duì)負(fù)責(zé)支付服務(wù)的值班。因此，每當(dāng)出現(xiàn)警報(bào)時(shí)，值班工程師都會響應(yīng)并查看詳細(xì)信息。但是如何從監(jiān)控到警報(bào)呢？

從監(jiān)控?cái)?shù)據(jù)中檢測異常是一個(gè)艱巨的挑戰(zhàn)，也是機(jī)器學(xué)習(xí)可以發(fā)光的領(lǐng)域。有很多第三方服務(wù)提供異常檢測。再次幸運(yùn)的是，我們團(tuán)隊(duì)有一個(gè)內(nèi)部機(jī)器學(xué)習(xí)團(tuán)隊(duì)與之合作，他們根據(jù)Uber的使用情況量身定制了解決方案。位于紐約的 Observability 團(tuán)隊(duì)撰寫了一篇有用的文章，介紹Uber 的異常檢測工作原理。從我的團(tuán)隊(duì)的角度來看，我們將監(jiān)控?cái)?shù)據(jù)推送到該團(tuán)隊(duì)的管道，并獲得具有各自置信度的警報(bào)。然后我們決定是否應(yīng)該呼叫工程師。

何時(shí)觸發(fā)警報(bào)是一個(gè)有趣的問題。警報(bào)太少可能意味著錯(cuò)過有影響的中斷。太多會導(dǎo)致不眠之夜并使人筋疲力盡。跟蹤和分類警報(bào)以及測量信噪比對于調(diào)整警報(bào)系統(tǒng)至關(guān)重要。檢查警報(bào)并標(biāo)記它們是否可操作，然后采取措施減少不可操作的警報(bào)，這是朝著實(shí)現(xiàn)可持續(xù)的隨叫隨到輪換邁出的良好一步。

Uber 使用的內(nèi)部 oncall 儀表板示例，由 Vilnius 的 Uber 開發(fā)人員體驗(yàn)團(tuán)隊(duì)構(gòu)建。

位于 Vilnius 的Uber開發(fā)工具團(tuán)隊(duì)構(gòu)建了整潔的呼叫工具，我們用它來注釋警報(bào)并可視化呼叫班次。我們的團(tuán)隊(duì)每周對上一次值班班次進(jìn)行回顧，分析痛點(diǎn)并花時(shí)間改善值班體驗(yàn)，一周又一周。

譯者注：告警事件的聚合、降噪、排班、認(rèn)領(lǐng)、升級、協(xié)同、靈活的推送策略、多渠道推送、和IM打通，是很通用的需求，可以參考FlashDuty這個(gè)產(chǎn)品，體驗(yàn)地址：https://console.flashcat.cloud/

故障和事件管理流程

想象一下：你是本周的值班工程師。半夜，一個(gè)警報(bào)把你吵醒了。你調(diào)查是否有生產(chǎn)中斷發(fā)生。糟糕，似乎系統(tǒng)的某個(gè)部分出現(xiàn)了故障?，F(xiàn)在怎么辦？監(jiān)控和警報(bào)真實(shí)發(fā)生了。

對于小型系統(tǒng)來說，中斷可能不是什么大問題，值班工程師可以了解正在發(fā)生的事情以及原因。它們通常易于理解且易于緩解。對于具有多個(gè)（微）服務(wù)的復(fù)雜系統(tǒng)，許多工程師將代碼推向生產(chǎn)，僅僅查明潛在問題發(fā)生的位置就已經(jīng)足夠具有挑戰(zhàn)性了。有一些標(biāo)準(zhǔn)流程來幫助解決這個(gè)問題會產(chǎn)生巨大的改觀。

附加到警報(bào)的Runbook手冊，描述簡單的緩解步驟是第一道防線。對于擁有良好Runbook手冊的團(tuán)隊(duì)，即使值班工程師不深入了解系統(tǒng)，也很少會成為問題。Runbook 需要保持最新、更新，并在故障出現(xiàn)時(shí)使用新型緩解措施進(jìn)行處理。

譯者注：Nightingale 和 Grafana 的告警規(guī)則配置中，可以支持自定義字段，但是有些附加字段是默認(rèn)就會提供的，比如 RunbookUrl，核心就是想傳達(dá)SOP手冊的重要性。另外，穩(wěn)定性治理體系里，告警規(guī)則是否預(yù)置了RunbookUrl，是一個(gè)很重要的告警健康度的衡量指標(biāo)。

一旦有超過幾個(gè)部署服務(wù)的團(tuán)隊(duì)，跨組織進(jìn)行故障交流就變得至關(guān)重要。在我工作的環(huán)境中，成千上萬的工程師會根據(jù)自己的判斷將他們所開發(fā)的服務(wù)部署到生產(chǎn)環(huán)境中，每小時(shí)可能會有數(shù)百次部署。一個(gè)看似不相關(guān)的服務(wù)部署可能會影響另一個(gè)服務(wù)。在這種情況下，標(biāo)準(zhǔn)化的故障廣播和通信渠道可以起到很大作用。我曾經(jīng)遇到過多種罕見的警報(bào)信息 - 意識到其他團(tuán)隊(duì)中的人也看到了類似奇怪現(xiàn)象。通過加入一個(gè)集中式聊天群組來處理故障，我們迅速確定了導(dǎo)致故障的服務(wù)并解決了問題。我們做得比任何單獨(dú)一人更快地完成了任務(wù)。

現(xiàn)在緩解，明天調(diào)查。在故障期間，我經(jīng)常會感到“腎上腺素飆升”，想要修復(fù)出現(xiàn)問題的地方。通常根本原因是糟糕的代碼部署，在代碼更改中存在明顯的錯(cuò)誤。過去，我會立即跳進(jìn)去修復(fù)錯(cuò)誤、推送修復(fù)并關(guān)閉故障，而不是回滾代碼更改。然而，在故障期間修復(fù)根本原因是一個(gè)可怕的想法。采用前進(jìn)式修復(fù)收益甚微，損失卻很大。因?yàn)樾碌男迯?fù)需要迅速完成，所以必須在生產(chǎn)中進(jìn)行測試。這就是引入第二個(gè)錯(cuò)誤 - 或者在現(xiàn)有錯(cuò)誤之上再出現(xiàn)一個(gè)故障 - 的原因。我見過像這樣的故障不斷惡化。只需先集中精力緩解，抵制修復(fù)或調(diào)查根本原因的沖動。適當(dāng)?shù)恼{(diào)查可以等到下一個(gè)工作日。

譯者注：這一點(diǎn)老司機(jī)應(yīng)該也深有感觸，不要在線上Debug，出現(xiàn)問題立即回滾而不是嘗試發(fā)布hotfix版本來修復(fù)！

事后分析，事件回顧和持續(xù)改進(jìn)文化

這是在說一個(gè)團(tuán)隊(duì)如何處理故障的后續(xù)。他們會繼續(xù)工作嗎？他們會做小規(guī)模的調(diào)查嗎？他們是否會在后續(xù)工作中花費(fèi)驚人的精力，停止產(chǎn)品工作以進(jìn)行系統(tǒng)級修復(fù)？

正確進(jìn)行的事后分析是構(gòu)建強(qiáng)大系統(tǒng)的基石。一份好的事后分析既無指責(zé)，又十分徹底。Uber 的事后分析模板隨著工程技術(shù)的發(fā)展而不斷演變，包括事件概述、影響總覽、時(shí)間線、根本原因分析、經(jīng)驗(yàn)教訓(xùn)以及詳細(xì)跟進(jìn)清單等部分。

這是一個(gè)類似我在 Uber 工作中用到的復(fù)盤模板。

良好的事后分析深入挖掘根本原因并提出改進(jìn)措施，以更快地預(yù)防、檢測或緩解所有類似的故障。當(dāng)我說深入挖掘時(shí)，我的意思是他們不會停留在根本原因上，即錯(cuò)誤的代碼更改和代碼審查者沒有發(fā)現(xiàn)錯(cuò)誤。

他們使用“5why”探索方式進(jìn)行更深入的挖掘，以達(dá)到更有意義的結(jié)論。舉個(gè)例子：

為什么會出現(xiàn)這個(gè)問題？–> 因?yàn)榇a里引入了bug。為什么其他人沒有發(fā)現(xiàn)這個(gè)錯(cuò)誤？–> 代碼審查員沒有注意到代碼更改可能會導(dǎo)致此類問題。我們?yōu)槭裁粗灰蕾囉诖a審查員捕獲此錯(cuò)誤？–> 因?yàn)槲覀儧]有針對此用例的自動化測試?！盀槭裁次覀儧]有針對此用例的自動化測試？” –> 因?yàn)樵跊]有測試帳戶的情況下很難進(jìn)行測試。我們?yōu)槭裁礇]有測試帳戶？ –> 因?yàn)樵撓到y(tǒng)尚不支持它們結(jié)論：這個(gè)問題指向了缺乏測試賬戶的系統(tǒng)性問題。建議將測試賬戶支持添加到系統(tǒng)中。接下來，編寫所有未來類似代碼更改的自動化測試。

事件回顧是事后分析的重要配套工具。雖然許多團(tuán)隊(duì)在事后分析方面做得很徹底，但其他團(tuán)隊(duì)可以從額外的輸入和對預(yù)防性改進(jìn)的挑戰(zhàn)中受益。同樣重要的是，團(tuán)隊(duì)要有責(zé)任感并有權(quán)執(zhí)行他們提出的系統(tǒng)級改進(jìn)。

對于認(rèn)真對待可靠性的組織，最嚴(yán)重的故障會由經(jīng)驗(yàn)豐富的工程師進(jìn)行審查和挑戰(zhàn)。組織級別的工程管理人員也應(yīng)該出席，以提供授權(quán)來完成修復(fù)——尤其是當(dāng)這些修復(fù)很耗時(shí)并阻礙其他工作時(shí)。健壯的系統(tǒng)不是一蹴而就的：它們是通過不斷的迭代構(gòu)建的。怎么才能持續(xù)迭代？這需要組織層面有持續(xù)改進(jìn)、從故障中學(xué)習(xí)的文化。

故障演習(xí)，容量規(guī)劃和黑盒測試

有一些常規(guī)活動需要大量投資，但對于保持大型分布式系統(tǒng)的正常運(yùn)行至關(guān)重要。這些是我在優(yōu)步第一次接觸到的概念——在以前的公司，我們不需要使用這些，因?yàn)槲覀兊囊?guī)模和基礎(chǔ)設(shè)施沒有促使我們這樣做。

一個(gè)數(shù)據(jù)中心故障演練是我認(rèn)為很無聊的事情，直到我觀察了其中幾個(gè)實(shí)踐。我最初的想法是，設(shè)計(jì)強(qiáng)大的分布式系統(tǒng)正是為了能夠在數(shù)據(jù)中心崩潰時(shí)保持彈性。如果理論上它可以正常工作，為什么要經(jīng)常測試呢？答案與規(guī)模有關(guān)，并且需要測試服務(wù)是否能夠有效地處理新數(shù)據(jù)中心中突然增加的流量。

我觀察到的最常見的故障場景是在發(fā)生故障轉(zhuǎn)移時(shí)，新數(shù)據(jù)中心的服務(wù)沒有足夠的資源來處理全球流量。假設(shè)ServiceA和ServiceB分別從兩個(gè)數(shù)據(jù)中心運(yùn)行。假設(shè)資源利用率為60％，每個(gè)數(shù)據(jù)中心都有數(shù)十或數(shù)百臺虛擬機(jī)在運(yùn)行，并設(shè)置警報(bào)以在70％時(shí)觸發(fā)?，F(xiàn)在讓我們進(jìn)行故障轉(zhuǎn)移，將所有流量從DataCenterA重定向到DataCenterB。 在沒有提供新機(jī)器的情況下，DataCenterB突然無法承受負(fù)載。提供新機(jī)器可能需要足夠長的時(shí)間，以至于請求會堆積并開始丟棄。這種阻塞可能會開始影響其他服務(wù)，導(dǎo)致其他系統(tǒng)的級聯(lián)故障，這些系統(tǒng)甚至不是此故障轉(zhuǎn)移的一部分。

其他常見的故障場景包括路由級別問題、網(wǎng)絡(luò)容量問題或背壓痛點(diǎn)。數(shù)據(jù)中心故障轉(zhuǎn)移是任何可靠分布式系統(tǒng)應(yīng)該能夠在沒有任何用戶影響的情況下執(zhí)行的演習(xí)。我強(qiáng)調(diào)“應(yīng)該”——這個(gè)演習(xí)是測試分布式系統(tǒng)可靠性最有用的練習(xí)之一。

譯者注：切流量，本就是預(yù)案“三板斧”之一。出故障的時(shí)候，要保證預(yù)案是可用的，那平時(shí)就少不了演練。重視起來吧，老鐵們。

計(jì)劃的服務(wù)停機(jī)時(shí)間練習(xí)是測試整個(gè)系統(tǒng)彈性的極好方法。這些也是發(fā)現(xiàn)特定系統(tǒng)的隱藏依賴項(xiàng)或不適當(dāng)/意外使用的好方法。雖然對于面向客戶且依賴較少的服務(wù)，這種練習(xí)相對容易完成，但是對于需要高可用性或被許多其他系統(tǒng)所依賴的關(guān)鍵系統(tǒng)來說，則不那么容易嘍。但是，當(dāng)某一天這個(gè)關(guān)鍵系統(tǒng)不可用時(shí)會發(fā)生什么？最好通過受控演練來驗(yàn)證答案，所有團(tuán)隊(duì)都知道并準(zhǔn)備好應(yīng)對意外中斷。

黑盒測試是一種測量系統(tǒng)正確性的方法，盡可能接近最終用戶所看到的條件。這種類型的測試類似于端到端測試，但對于大多數(shù)產(chǎn)品來說，擁有適當(dāng)?shù)暮诤袦y試需要單獨(dú)投入。關(guān)鍵用戶流程和最常見的面向用戶的測試場景是好的黑盒可測性示例：以這種方式進(jìn)行設(shè)置可以隨時(shí)觸發(fā)它們，以檢查系統(tǒng)是否正常工作。

以優(yōu)步為例，一個(gè)明顯的黑盒測試是檢查乘客-司機(jī)流程是否在城市層面上正常工作。也就是說，在特定城市內(nèi)的乘客能否請求優(yōu)步，并與司機(jī)合作并完成行程？一旦這種情況被自動化，這個(gè)測試可以定期運(yùn)行，模擬不同的城市。擁有強(qiáng)大的黑盒測試系統(tǒng)使得驗(yàn)證系統(tǒng)或部分系統(tǒng)是否正確工作更加容易。它還對故障轉(zhuǎn)移演練非常有幫助：獲取故障轉(zhuǎn)移反饋?zhàn)羁旖莸姆椒ㄊ沁\(yùn)行黑盒測試。

上圖是在故障轉(zhuǎn)移演練失敗時(shí)，使用黑盒測試的示例，在演練幾分鐘后手動回滾。

容量規(guī)劃對于大型分布式系統(tǒng)同樣重要。所謂大型，是指計(jì)算和存儲成本每月達(dá)到數(shù)萬或數(shù)十萬美元。在這個(gè)規(guī)模下，使用固定數(shù)量的部署可能比使用自動擴(kuò)展的云解決方案更便宜。至少，固定部署應(yīng)該處理“業(yè)務(wù)常態(tài)”流量，并在高峰負(fù)載時(shí)進(jìn)行自動擴(kuò)展。但是，在接下來的一個(gè)月內(nèi)、未來三個(gè)月內(nèi)以及明年需要運(yùn)行多少最小實(shí)例呢？

預(yù)測成熟且具有良好歷史數(shù)據(jù)的系統(tǒng)的未來流量模式并不困難。這對于預(yù)算、選擇供應(yīng)商或鎖定云提供商的折扣都很重要。如果您的服務(wù)費(fèi)用很高，而您沒有考慮容量規(guī)劃，那么您就錯(cuò)過了降低和控制成本的簡單方法。

SLOs, SLAs 以及相關(guān)報(bào)告

SLO 代表服務(wù)級別目標(biāo) - 系統(tǒng)可用性的數(shù)字目標(biāo)。對于每個(gè)獨(dú)立的服務(wù)，定義服務(wù)級別 SLO（例如容量、延遲、準(zhǔn)確性和可用性的目標(biāo)）是一種很好的做法。然后，這些 SLO 可以作為警報(bào)的觸發(fā)器。服務(wù)級別 SLO 示例可能如下所示：

SLO Metric	Subcategory	Value for Service
Capacity	Minumum throughput	500 req/sec
	Maximum expected throughput	2,500 req/sec
Latency	Expected median response time	50-90ms
	Expected p99 response time	500-800ms
Accuracy	Maximum error rate	0.5%
Availability	Guaranteed uptime	99.9%

業(yè)務(wù)級 SLO 或功能 SLO 是服務(wù)之上的抽象。它們將涵蓋用戶或面向業(yè)務(wù)的指標(biāo)。例如，業(yè)務(wù)級 SLO 可能是這樣的：期望 99.99% 的電子郵件收據(jù)在旅行完成后的 1 分鐘內(nèi)發(fā)送。此 SLO 可能映射到服務(wù)級別 SLO（例如支付和電子郵件接收系統(tǒng)的延遲），或者它們可能需要以不同方式衡量。

SLA - 服務(wù)水平協(xié)議 - 是服務(wù)提供者和服務(wù)消費(fèi)者之間更廣泛的協(xié)議。通常，多個(gè) SLO 組成一個(gè) SLA。例如，99.99% 可用的支付系統(tǒng)可以是 SLA，它分解為每個(gè)支持系統(tǒng)的特定 SLO。

定義 SLO 后，下一步是衡量這些并報(bào)告它們。對 SLA 和 SLO 進(jìn)行自動化監(jiān)控和報(bào)告通常是一項(xiàng)復(fù)雜的項(xiàng)目，工程團(tuán)隊(duì)和業(yè)務(wù)部門都傾向于降低其優(yōu)先級。工程團(tuán)隊(duì)可能不太感興趣，因?yàn)樗麄円呀?jīng)有各種級別的監(jiān)控來實(shí)時(shí)檢測故障。另一方面，業(yè)務(wù)部門更愿意將重點(diǎn)放在提供功能上，而不是投資于一個(gè)沒有立即商業(yè)影響的復(fù)雜項(xiàng)目中。

這就引出了下一個(gè)話題：運(yùn)營大型分布式系統(tǒng)的組織遲早需要為這些系統(tǒng)的可靠性投入專門的人員。讓我們來談?wù)劸W(wǎng)站可靠性工程團(tuán)隊(duì)。

SRE 作為獨(dú)立團(tuán)隊(duì)

網(wǎng)站可靠性工程（Site Reliability Engineering）起源于谷歌，大約在2003年左右開始，現(xiàn)在已經(jīng)發(fā)展成為擁有超過1,500名SRE工程師的團(tuán)隊(duì)。隨著生產(chǎn)環(huán)境運(yùn)營變得越來越復(fù)雜，并需要更多自動化操作，這項(xiàng)工作很快就會成為一項(xiàng)全職工作。公司意識到他們有工程師正在全職從事生產(chǎn)自動化的時(shí)間因情況而異：這些系統(tǒng)越關(guān)鍵、故障越多，則此類情況出現(xiàn)得越早。

快速發(fā)展的科技公司通常會在早期組建 SRE 團(tuán)隊(duì)，由他們制定自己的路線圖。在優(yōu)步，SRE 團(tuán)隊(duì)成立于 2015 年，其使命是隨著時(shí)間的推移管理系統(tǒng)復(fù)雜性。其他公司可能會在創(chuàng)建專門的基礎(chǔ)架構(gòu)團(tuán)隊(duì)時(shí)同時(shí)啟動這樣的團(tuán)隊(duì)。當(dāng)一家公司發(fā)展到跨團(tuán)隊(duì)的可靠性工作占用了很多工程師的時(shí)間時(shí)，是時(shí)候?yàn)榇嗽O(shè)立一個(gè)專門的團(tuán)隊(duì)了。

有了 SRE 團(tuán)隊(duì)，這個(gè)團(tuán)隊(duì)可以讓所有工程師更輕松地維護(hù)大型分布式系統(tǒng)的操作方面。SRE 團(tuán)隊(duì)可能擁有標(biāo)準(zhǔn)的監(jiān)控和警報(bào)工具。他們可能購買或構(gòu)建 oncall 工具，并且是 oncall 最佳實(shí)踐的 goto 團(tuán)隊(duì)。他們可能會促進(jìn)故障復(fù)盤并構(gòu)建系統(tǒng)，以更輕松地檢測、緩解和防止故障。他們當(dāng)然有助于故障轉(zhuǎn)移演練，經(jīng)常推動黑盒測試，并參與容量規(guī)劃。他們推動選擇、定制或構(gòu)建標(biāo)準(zhǔn)工具來定義和衡量 SLO 并報(bào)告它們。

鑒于公司有不同的痛點(diǎn)，他們尋求 SRE 來解決，因此 SRE 組織在公司之間是不同的。這個(gè)團(tuán)隊(duì)的名稱通常也會不同：可能被稱為運(yùn)維、平臺工程或基礎(chǔ)設(shè)施。Google 出版了兩本關(guān)于站點(diǎn)可靠性的必讀書籍，這些書籍可免費(fèi)獲取，是深入了解 SRE 的絕佳讀物。

可靠性作為持續(xù)投入

在構(gòu)建任何產(chǎn)品時(shí)，構(gòu)建第一個(gè)版本只是一個(gè)開始。在 v1 之后，新功能會添加到即將到來的迭代中。如果產(chǎn)品成功并帶來業(yè)務(wù)成果，那么工作就會繼續(xù)進(jìn)行。

分布式系統(tǒng)具有相似的生命周期，只是它們需要更多投資，不僅僅是為了新功能，還要跟上擴(kuò)展的步伐。隨著系統(tǒng)開始承受更多負(fù)載、存儲更多數(shù)據(jù)、更多工程師對其進(jìn)行處理，它需要持續(xù)關(guān)注以保持平穩(wěn)運(yùn)行。很多人第一次構(gòu)建分布式系統(tǒng)時(shí)會認(rèn)為這個(gè)系統(tǒng)就像一輛汽車：一旦建好，只需要每幾個(gè)月進(jìn)行必要的維護(hù)。但是這種比較與實(shí)際情況相去甚遠(yuǎn)。

我喜歡把操作分布式系統(tǒng)的努力比作經(jīng)營大型組織，例如醫(yī)院。為了確保醫(yī)院運(yùn)轉(zhuǎn)良好，需要進(jìn)行持續(xù)的驗(yàn)證和檢查（監(jiān)控、警報(bào)、黑盒測試）。不斷有新員工和設(shè)備加入：對于醫(yī)院來說，這是像護(hù)士和醫(yī)生這樣的員工以及新的醫(yī)療設(shè)備；對于分布式系統(tǒng)來說，則是招募新工程師和添加新服務(wù)。隨著人數(shù)和服務(wù)數(shù)量的增長，舊有做事方式變得低效：就像鄉(xiāng)村小診所與大都市中的大型醫(yī)院不同一樣。提出更有效率的方法成為全職工作，并且測量并報(bào)告效率變得重要。就像大型醫(yī)院有財(cái)務(wù)、人力資源或安全等支持性質(zhì)的辦公室人員一樣，經(jīng)營較大規(guī)模分布式系統(tǒng)也依賴基礎(chǔ)架構(gòu)和SRE等支持團(tuán)隊(duì)。

為了讓團(tuán)隊(duì)運(yùn)行可靠的分布式系統(tǒng)，組織需要持續(xù)投資于這些系統(tǒng)的操作以及它們所構(gòu)建的平臺。

關(guān)鍵詞：