史上增長最快的SaaS公司-Slack的混沌工程實(shí)踐 | IDCF

來源：混沌工程實(shí)踐   首發(fā)：slack.engineering

作者：Richard Crowley  譯者：龍塢道長 

標(biāo)題：Disasterpiece Theater: Slack’s process for approachable Chaos Engineering

堪稱史上增長最快的SaaS產(chǎn)品: Slack。這是一家特別神奇的SaaS公司，號(hào)稱在沒有銷售團(tuán)隊(duì)和營銷預(yù)算的情況下，成立3年?duì)I收增長10倍，一度被譽(yù)為“歷史上增長最快的SaaS公司”。今天，我們來看看他們的混沌工程實(shí)踐。

引 子

在過去的五年中，Slack的日活用戶數(shù)超過了1000萬，快速的迭代和重大的架構(gòu)調(diào)整支撐了Slack更多的功能。目前，Slack服務(wù)已經(jīng)變成了一個(gè)龐然大物。對(duì)于這個(gè)龐然大物的測(cè)試，我們遵循假設(shè)驗(yàn)證的科學(xué)方法和流程。

每當(dāng)啟用新的功能或?qū)ζ溥M(jìn)行修改時(shí)，我們都會(huì)測(cè)試新代碼的容錯(cuò)能力。不幸的是，盡管服務(wù)依賴的環(huán)境在發(fā)生變化，我們也很少重復(fù)這些測(cè)試。

最初，我們對(duì)關(guān)鍵系統(tǒng)的韌性和可靠性充滿信心，但隨著時(shí)間的推移，這些最初的測(cè)試結(jié)果就會(huì)失效，這種信心就沒有充分的依據(jù)了。

靠運(yùn)氣？不！我們必須有所改變。

當(dāng)然，如果這是一個(gè)從0到1的新產(chǎn)品，我們一開始就會(huì)實(shí)踐混沌工程。畢竟，測(cè)試故障路徑的最佳方法就是永遠(yuǎn)不要正常關(guān)閉服務(wù)。

但是，我們并不是從零開始，我們經(jīng)營著對(duì)業(yè)務(wù)至關(guān)重要且規(guī)模龐大的服務(wù)，我們現(xiàn)在最需要的是什么呢？

Slack服務(wù)保持盡可能的健壯性：

• 開發(fā)環(huán)境成為一個(gè)對(duì)容錯(cuò)測(cè)試更有信心的地方 ；
• 測(cè)試所有系統(tǒng)（不僅僅是新系統(tǒng)） ；
• 不能造成影響用戶的事件，所做的測(cè)試都必須安全 ；
• 不要虛假的信心，所做的一切都需要在生產(chǎn)中進(jìn)行 。

在2018年1月，我們啟動(dòng)了一個(gè)嚴(yán)格的流程：

• 識(shí)別可能發(fā)生的故障；
• 確保服務(wù)能夠容忍這些故障；
• 故意在生產(chǎn)中引入這些故障。

這還不是Netflix實(shí)踐和宣傳的混沌工程。這是混沌工程的第一步，我們稱之為災(zāi)難劇院。

演練準(zhǔn)備

每次災(zāi)難劇院的演練過程都旨在最大程度地學(xué)習(xí)，同時(shí)最大程度地降低生產(chǎn)事故的風(fēng)險(xiǎn)。每次演練都在一個(gè)確定且通知到位的時(shí)間和地點(diǎn)進(jìn)行，所有相關(guān)的專家都在同一房間或同一視頻會(huì)議中。

這一階段，我們尚未試圖在這些演練中測(cè)試監(jiān)控的部分。在演練之前，主持者們要編寫一份詳細(xì)的計(jì)劃并廣泛分享收集反饋，因?yàn)樵撚?jì)劃對(duì)演練的安全性至關(guān)重要。

不過這份計(jì)劃里面更多是演練的內(nèi)容，不會(huì)提供服務(wù)的容錯(cuò)原理。

主持者們負(fù)責(zé)分享他們的電腦桌面，講出整個(gè)計(jì)劃背后的思考邏輯。同時(shí)，還要精細(xì)地記錄如何引發(fā)故障，將要運(yùn)行的命令，以及如何選擇涉及的EC2實(shí)例（我們將其稱為“貢品”）。

我們還要求主持者繼續(xù)記錄，用開發(fā)環(huán)境的容錯(cuò)狀況去預(yù)測(cè)生產(chǎn)中的容錯(cuò)能力，他們有多少信心。此外還包括需要監(jiān)控的所有日志、指標(biāo)和告警，以及在此演練過程中需要的運(yùn)行手冊(cè)。

最重要的是，他們需要在計(jì)劃中，提出一個(gè)具體的假設(shè)，用來描述上下游系統(tǒng)以及Slack客戶端經(jīng)歷故障的過程。

例如，“MySQL主服務(wù)器的終止，將導(dǎo)致依賴于該數(shù)據(jù)庫的請(qǐng)求，延遲增加20秒，而其它請(qǐng)求的延遲不會(huì)增加，失敗的API請(qǐng)求數(shù)少于1000個(gè)，所有這些都是由于客戶端重試造成的?！?/span>

災(zāi)難來襲

在開始演練之前，我們會(huì)審核演練計(jì)劃，將Grafana中定義好的儀表板和Kibana中預(yù)置的實(shí)時(shí)搜索結(jié)果，投到幕布上或分享出來。現(xiàn)在我們準(zhǔn)備注入故障。

我們先在Slack擁有700多人的運(yùn)維頻道，宣布了這項(xiàng)演練的開始。

在演練過程中，我們不會(huì)停止部署或其他任何正?；顒?dòng)，但會(huì)讓相關(guān)的人提前知曉我們的演練計(jì)劃。

在整個(gè)演練過程中，我們會(huì)在運(yùn)維頻道中提供一些粗略的狀態(tài)更新，而在災(zāi)難劇場(chǎng)的頻道中提供每一步的結(jié)果。

演練總是先在開發(fā)環(huán)境中注入故障。

之后，我們檢查日志和指標(biāo)，以確認(rèn)故障以我們期望的方式表現(xiàn)出來。碰到問題想要修復(fù)是一種常見的本能，但在這里我們必須控制自己，作為旁觀者，監(jiān)視系統(tǒng)的自行維護(hù)。

我們通過使用負(fù)載平衡和流量管理的方式進(jìn)行故障轉(zhuǎn)移或更換容量。極少的情況，我們會(huì)按照運(yùn)行手冊(cè)來恢復(fù)服務(wù)。

在開發(fā)環(huán)境中注入故障后，我們會(huì)暫停，決定是否在生產(chǎn)上進(jìn)行同樣的操作。很多時(shí)候，我們都覺得，如果不在生產(chǎn)上進(jìn)行，這個(gè)演練就是失敗的或者浪費(fèi)大家的時(shí)間。

但實(shí)際上，往往最有價(jià)值的一些經(jīng)驗(yàn)教訓(xùn)反倒是來自開發(fā)環(huán)境。

如果系統(tǒng)的自動(dòng)補(bǔ)救措施不起作用，或者不能按預(yù)期見效，亦或者花費(fèi)的時(shí)間太長，更重要的是，如果故障會(huì)導(dǎo)致更多的破壞，而不是客戶端延遲短暫且輕微的增加，我們會(huì)認(rèn)真考慮中止。

如果我們決定終止，就會(huì)在運(yùn)維頻道中宣布。

幸運(yùn)的是，我們對(duì)開發(fā)環(huán)境的結(jié)果感到滿意，準(zhǔn)備在生產(chǎn)環(huán)境中注入故障。我們把Grafana中定義好的儀表板和Kibana中預(yù)置的實(shí)時(shí)搜索，投到幕布上或分享出來，并在運(yùn)維頻道中宣布我們即將在生產(chǎn)注入故障。

最后的時(shí)刻到了，在生產(chǎn)中注入故障，和我們?cè)陂_發(fā)環(huán)境中所做的一樣，我們檢查日志和指標(biāo)，以驗(yàn)證我們的假設(shè)。同時(shí)，我們也為系統(tǒng)預(yù)留了自動(dòng)修復(fù)所需的時(shí)間。

另外，這個(gè)理論上令人恐懼的時(shí)刻，實(shí)際上是相當(dāng)平靜的。所有的一切完成后，我們?cè)谶\(yùn)維頻道中宣布故障全部清除。

然后，我們開始總結(jié)和持續(xù)跟進(jìn):

• 找到問題根源和解決問題的時(shí)間點(diǎn)；
• 是否有用戶已經(jīng)注意到這個(gè)問題； 
• 是否需要人工干預(yù)這個(gè)問題； 
• 這個(gè)問題的嚴(yán)重程度； 
• 演練計(jì)劃的文檔是否有差錯(cuò)； 
• Grafana中的儀表板是否已過時(shí)。 

演練結(jié)果

我們?cè)赟lack進(jìn)行了數(shù)十次災(zāi)難劇院的演練。其中大多數(shù)能按計(jì)劃進(jìn)行，增強(qiáng)了我們對(duì)現(xiàn)有系統(tǒng)的信心，并驗(yàn)證了新功能的容錯(cuò)能力。當(dāng)然，有些時(shí)候我們還是會(huì)發(fā)現(xiàn)Slack可用性的嚴(yán)重問題，并在影響客戶之前找到提前修復(fù)的機(jī)會(huì)。

以下是三個(gè)特別成功的演練：

1、避免緩存不一致

第一次的災(zāi)難劇院演練，我們把注意力投向了memcached，用于證明在生產(chǎn)中自動(dòng)實(shí)例替換能正常工作。

這個(gè)演練很簡(jiǎn)單，選擇將memcached的實(shí)例斷開網(wǎng)絡(luò)連接，觀察備用實(shí)例是否能正常替換。最后，我們恢復(fù)了網(wǎng)絡(luò)連接并終止了備用實(shí)例。

演練計(jì)劃審核時(shí)，我們發(fā)現(xiàn)了實(shí)例替換算法中的一個(gè)漏洞，并很快在開發(fā)環(huán)境確認(rèn)了它的存在。

根據(jù)最初的設(shè)計(jì)，如果實(shí)例在一組緩存鍵上丟失了租約，然后又獲得相同的租約，則該實(shí)例不會(huì)刷新其緩存項(xiàng)。但是，在這種情況下，備用實(shí)例在此期間已使用了該組緩存鍵，這意味著原始實(shí)例中的數(shù)據(jù)已過時(shí)而且可能不準(zhǔn)確了。

在演練中，我們通過選定適當(dāng)時(shí)間段手動(dòng)刷新緩存，在演練完成后立即更改算法，并再次進(jìn)行測(cè)試來解決此問題。

沒有演練發(fā)現(xiàn)的這個(gè)問題，我們很可能不會(huì)察覺緩存損壞的問題。

2、為了安全反復(fù)嘗試

在2019年初，我們計(jì)劃進(jìn)行十次演練，用來證明Slack對(duì)AWS中的區(qū)域故障和網(wǎng)絡(luò)分區(qū)的容錯(cuò)能力。其中一個(gè)演練涉及信道服務(wù)器(Channel Server)，負(fù)責(zé)將新發(fā)送的消息和元數(shù)據(jù)，廣播到所有關(guān)聯(lián)Slack客戶端的WebSocket中。

這次演練的目標(biāo)是將25％的信道服務(wù)器受到網(wǎng)絡(luò)分區(qū)的故障，并觀察是否能檢測(cè)到對(duì)應(yīng)的故障點(diǎn)，系統(tǒng)是否自動(dòng)會(huì)將原實(shí)例替換為備用實(shí)例。

創(chuàng)建網(wǎng)絡(luò)分區(qū)故障的第一次嘗試失敗了，問題出在提供透明傳輸加密的overlay網(wǎng)絡(luò)。實(shí)際上，我們對(duì)信道服務(wù)器的隔離遠(yuǎn)超出了預(yù)期，與網(wǎng)絡(luò)分區(qū)相比，這是斷開網(wǎng)絡(luò)連接。我們提早停下使信道服務(wù)器重新加入集群，恢復(fù)網(wǎng)絡(luò)故障。

第二次嘗試好了很多，但在投入生產(chǎn)前就結(jié)束了。但這次演練提供了積極的結(jié)果，我們發(fā)現(xiàn)Consul適合管理網(wǎng)絡(luò)分區(qū)上的路由。這個(gè)結(jié)果給了我們更多的信息，但還是結(jié)束了這次演練，因?yàn)殡m然做了很多工作，最終還是沒有產(chǎn)生任何信道服務(wù)器的故障。

第三次也是最后一次嘗試，我們使用了完整的iptables規(guī)則庫，并成功地將網(wǎng)絡(luò)分區(qū)故障注入到25％的信道服務(wù)器。Consul迅速檢測(cè)到故障，并立即采取替代行動(dòng)。最重要的是，這種大規(guī)模自動(dòng)重新配置的工作，給Slack API帶來的負(fù)荷完全在該系統(tǒng)的能力范圍內(nèi)。

漫漫長路的盡頭，最后都是積極的成果！

3、看似不可能的結(jié)果

演練也會(huì)有負(fù)面的結(jié)果。事件響應(yīng)，通常涉及使用自研系統(tǒng)Confabulator進(jìn)行配置更改。

在一次特別嚴(yán)重的事件中，Confabulator未能按預(yù)期運(yùn)行，因此我們不得不手動(dòng)進(jìn)行配置更改的部署。

因此，我們認(rèn)為這個(gè)事件值得進(jìn)一步調(diào)查。系統(tǒng)維護(hù)人員和我們計(jì)劃進(jìn)行一次演練，直接模仿我們之前遇到的狀況，這將會(huì)導(dǎo)致Confabulator的網(wǎng)絡(luò)分區(qū)，其他的系統(tǒng)都運(yùn)行正常，我們也不會(huì)嘗試手動(dòng)更改配置。

重現(xiàn)了這個(gè)問題很容易，然后我們開始跟蹤代碼，很快就發(fā)現(xiàn)了問題。該系統(tǒng)的作者發(fā)現(xiàn)問題出在Slack本身宕機(jī)的情況下。

當(dāng)提交的配置更改無法驗(yàn)證進(jìn)而無法部署時(shí)，系統(tǒng)就會(huì)應(yīng)用一種緊急模式，直接跳過了驗(yàn)證過程。但是，在正常模式和緊急模式中，系統(tǒng)都會(huì)試圖將配置更改的通知發(fā)布到Slack通道。該操作恰恰沒有設(shè)置超時(shí)，盡管配置API是有超時(shí)的。

因此，即使在緊急模式下，如果Slack本身處于關(guān)閉狀態(tài)，該請(qǐng)求也永遠(yuǎn)無法進(jìn)行配置更改的部署。

這個(gè)演練之后，我們對(duì)代碼和配置部署進(jìn)行了很多的改進(jìn)，并審核了這些關(guān)鍵系統(tǒng)中的超時(shí)和重試策略。

未來展望

災(zāi)難劇院演練，已對(duì)Slack關(guān)鍵系統(tǒng)的容錯(cuò)能力進(jìn)行了定期且安全的驗(yàn)證，幫助我們了解和提高了Slack服務(wù)的可靠性。

在我們拓展和迭代產(chǎn)品時(shí)，這是贏得并保持客戶信任度的最重要因素之一。

上面提到的三個(gè)演練，增強(qiáng)了Slack服務(wù)的健壯性，并建立或糾正了我們對(duì)系統(tǒng)容錯(cuò)能力的信心。

我們的韌性工程團(tuán)隊(duì)會(huì)一直不斷地拓展和迭代這個(gè)過程。當(dāng)然，我們計(jì)劃進(jìn)行更多的災(zāi)難劇院演練。

2021 IDCF 公開課招生ing

王立杰老師授課《端到端DevOps持續(xù)交付（5P）工作坊》第一期課程本周四開播啦，限時(shí)拼團(tuán)優(yōu)惠，快識(shí)別下圖二維碼報(bào)名吧~