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

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

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

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

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

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

監(jiān)控

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

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

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

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

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

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

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

雖然我們建立了各種監(jiān)控，有些業(yè)務(wù)問(wèn)題仍然無(wú)法探測(cè)到，這讓我們?cè)馐芰司薮蟮耐纯?，最終建立了業(yè)務(wù)指標(biāo)的監(jiān)控。有時(shí)我們所有的服務(wù)看起來(lái)都在正常運(yùn)行，但關(guān)鍵產(chǎn)品功能不可用！這種監(jiān)控對(duì)我們的組織和領(lǐng)域來(lái)說(shuō)非常有用。因此，我們必須在Uber的可觀察性技術(shù)堆棧的基礎(chǔ)上，為自己定制這種類(lèi)型的監(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)，就是專(zhuān)門(mén)應(yīng)對(duì)這個(gè)問(wèn)題的。感興趣的朋友可以在公眾號(hào)后臺(tái)給我留言，或加我好友 picobyte 交流試用。

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

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

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

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

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

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

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

譯者注：告警事件的聚合、降噪、排班、認(rèn)領(lǐng)、升級(jí)、協(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ā)生了。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

業(yè)務(wù)級(jí) SLO 或功能 SLO 是服務(wù)之上的抽象。它們將涵蓋用戶或面向業(yè)務(wù)的指標(biāo)。例如，業(yè)務(wù)級(jí) SLO 可能是這樣的：期望 99.99% 的電子郵件收據(jù)在旅行完成后的 1 分鐘內(nèi)發(fā)送。此 SLO 可能映射到服務(wù)級(jí)別 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)告它們。對(duì) SLA 和 SLO 進(jìn)行自動(dòng)化監(jiān)控和報(bào)告通常是一項(xiàng)復(fù)雜的項(xiàng)目，工程團(tuán)隊(duì)和業(yè)務(wù)部門(mén)都傾向于降低其優(yōu)先級(jí)。工程團(tuán)隊(duì)可能不太感興趣，因?yàn)樗麄円呀?jīng)有各種級(jí)別的監(jiān)控來(lái)實(shí)時(shí)檢測(cè)故障。另一方面，業(yè)務(wù)部門(mén)更愿意將重點(diǎn)放在提供功能上，而不是投資于一個(gè)沒(méi)有立即商業(yè)影響的復(fù)雜項(xiàng)目中。

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

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

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

快速發(fā)展的科技公司通常會(huì)在早期組建 SRE 團(tuán)隊(duì)，由他們制定自己的路線圖。在優(yōu)步，SRE 團(tuán)隊(duì)成立于 2015 年，其使命是隨著時(shí)間的推移管理系統(tǒng)復(fù)雜性。其他公司可能會(huì)在創(chuàng)建專(zhuān)門(mén)的基礎(chǔ)架構(gòu)團(tuán)隊(duì)時(shí)同時(shí)啟動(dòng)這樣的團(tuán)隊(duì)。當(dāng)一家公司發(fā)展到跨團(tuán)隊(duì)的可靠性工作占用了很多工程師的時(shí)間時(shí)，是時(shí)候?yàn)榇嗽O(shè)立一個(gè)專(zhuān)門(mén)的團(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)買(mǎi)或構(gòu)建 oncall 工具，并且是 oncall 最佳實(shí)踐的 goto 團(tuán)隊(duì)。他們可能會(huì)促進(jìn)故障復(fù)盤(pán)并構(gòu)建系統(tǒng)，以更輕松地檢測(cè)、緩解和防止故障。他們當(dāng)然有助于故障轉(zhuǎn)移演練，經(jīng)常推動(dòng)黑盒測(cè)試，并參與容量規(guī)劃。他們推動(dòng)選擇、定制或構(gòu)建標(biāo)準(zhǔn)工具來(lái)定義和衡量 SLO 并報(bào)告它們。

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

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

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

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

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

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