本文轉載自微信公衆號“七牛雲”。
在 1 月 5 日 ECUG 大會的分享中 ，我司創始人兼 CEO 劉奇爲大家帶來了主題爲《Chaos Engineering at PingCAP》的精彩演講，和大家分享了關於 Chaos Engineering 的有關內容和深度思考。以下爲演講實錄。
在演講的開始，我先提一下 TiDB。TiDB 是一個分佈式數據庫，可以對外支持 MySQL 協議和 Spark API。TiDB 是目前在 NewSQL 領域目前使用規模最大、用戶最多也是最火的數據庫之一。
TiDB 典型場景是這樣的：比如大家要做分庫分表，用 TiDB 就不用折騰了；再比如大家如果需要複雜的 workload， 譬如 OLTP + OLAP 同時在系統裏面是並存的情況。通常大家用數據庫的時候會考慮是 OLAP 還是 OLTP，但是對用戶來說，不希望數據庫的人去教育他什麼是 OLAP，什麼是 OLTP，SQL 能足夠快跑出來就可以了，使用要儘可能簡單。還有一些用戶，比如日本、美國的用戶，是從 Amazon Aurora 遷移到 TiDB 上面的，當規模到幾十 T 的時候，Aurora 跑起來就很吃力了。
我們再來說 PingCAP 是一傢什麼樣的公司？可能大家都知道 TiDB，不知道 PingCAP。其實 TiDB 是 PingCAP 開發的。
那 CNCF 又是什麼呢？CNCF 全稱是雲原生計算基金會。可能很多人知道 K8s 但是不知道 CNCF，就像大家知道 TiDB 不知道 PingCAP 是一樣的道理，Kubernetes 是 CNCF 下面最火的一個項目。目前在整個 CNCF 所有代碼貢獻裏面，PingCAP 在裏面全球排名第六，在我們下面排名第七的是華爲，前八名裏面只有兩家中國的公司。
接下來，我們會以 TiDB 爲例，來具體演示 Chaos Mesh 的使用。首先，我們需要關注的是 TiDB 的結構。下圖是 TiDB 的結構，爲什麼會講 TiDB 的結構？
如圖，TiDB 大體上分成兩層：
-
計算層，就是大家通常理解的 SQL 層。
-
存儲層，包括一個支持行存模型的 TiKV 和一個支持列存模型的 TiFlash。
除此之外，還有一個調度器 PD，負責對整個系統進行全局控制。
做數據庫這個事情，當時入坑的時候並不知道這麼難，後來才知道怎麼這麼難，我講完以後大家可能覺得這個事更難。這幾年我們遇到了編譯器的 bug，遇到了操作系統的 bug，遇到文件系統的 bug，也被坑到過造成了數據的丟失，好在最終修復了。可能這些問題大家平時遇到的相對比較少，但是在我們這兒都遇到了，我們還遇到了某雲存儲廠商採購的某批磁盤硬件驅動有問題，寫進去的數據和讀出來的數據有一部分是不一樣的。我不知道大家有沒有遇到這些神奇的現象，但是作爲一個數據庫廠商，在我們這兒都遇到過。
上圖是 GitHub 的一個頁面，大家應該都見過，一年它會掛幾次，如果大家足夠幸運，應該會看到。這張圖告訴我們什麼呢？告訴我們的是你重新刷新可能就好了。當他說這個的時候，意味着他對這個情況是有預期、有處理的。我們的系統是不是也有這樣的機制呢？比如出現一個什麼問題，在用戶側大致怎麼操作一下，就可以恢復。但最近 GitHub 又掛了一次，這次好像花了好幾個小時才恢復。
這隻黑天鵝就是我們這幾年的體驗。差不多前面十年寫程序遇不到的問題，這幾年全部遇到了。大家見到黑天鵝之前會覺得這個世界上天鵝全是白的，直到編譯器和操作系統的 bug 把我們坑到的時候，我們才覺得自己沒有那麼幸運。
上圖是我們遇到的一個操作系統 bug，我們後面還專門寫了文章描述怎麼找到這個 bug 的。大概意思是 Linux kernel 有一個 bug，明明有內存，但是內存分不出來，導致沒法將 page cache 刷到磁盤上，丟失了數據。我想說的是操作系統 bug 離我們也挺近的，我們上面應用程序寫得再好，後面也可能會在操作系統遇到問題。不過我們通常寫程序的時候，這點考慮得比較少。
大家都覺得文件系統很穩定，應該沒有遇到過文件系統的 bug，大家以前也不知道文件系統有這麼脆弱，直到有一個工具出現了：它最早用來找安全漏洞，後來被用來找其他的系統漏洞。我們拿着這個工具去測試一下已有的文件系統，下圖是遇到第一個 bug 的時間。
當時看來這些系統都是非常好的。Ext4 是被認爲相當不錯的，確實表現也不錯，因爲它扛了 2 小時才找到第一個 bug。最早我們推薦的兩個文件系統是 Xfs 和 Ext4，後來有一次我們被 Xfs 坑到了，就把 Xfs 關掉不推薦了，所以我們現在只推薦 Ext4。這個工具很有意思，大家一目瞭然就知道文件系統成熟度是什麼樣的，誰能扛得最久，誰在現實中是最穩定的文件系統。所以有時候我們會在穩定性和性能之間，根據不同的業務要求來做選擇。
說到 Chaos Engineering，我不知道大家會想起什麼。Chaos 的中文翻譯是混沌，可能混沌這個概念有點模糊，不過我們今天就來看它到底能解決什麼問題。
上面是我剛剛創業的時候寫的幾篇文章，關於分佈式系統測試的，當時就已經知道分佈式系統測試無比困難。我記得我們要在幾百個微服務裏面找一個掛掉的微服務，這個很有意思，幾百個微服務中那個抖動的微服務如果剛好是你存儲相關的，或者和你登陸相關的，那麼整個系統會是什麼樣的反應？用戶就登陸不上去，或者登陸很卡，要麼後面的操作會很卡。
這方面歷史上的先行者是 Netflix，他們創建了一個叫做 Chaos monkey 的東西，就是在整個系統裏面，隨機地去 kill，比如幾百幾千個冗餘服務，隨機 kill 掉一個，來看系統會怎麼樣。
我不知道大家有沒有人在線上真的做過這種測試，應該是沒有的。之前我們提到過黑天鵝，當然不僅有黑天鵝還有墨菲定律，就是所有你覺得可能會出現的最後一定會出現。如果你自己不去 kill，它一定會被別人 kill 掉，各種意外都會有。
這裏面比較有啓發的一件事是 Netflix 在 2014 年創建了一個新的崗位，這個崗位就叫 Chaos engineer，是專門有個工程師做這件事，在線上去隨機 kill 節點。到時候大家很可能面臨的情況是，可能某一天半夜，研發突然被全部拉起來，所有人同時在查問題，卻不知道問題在哪裏。大家第一反應是「這不是我的問題」，甩鍋一定要快。到底誰的問題呢？其實老闆不關心到底是誰的問題，關心的是能不能儘快找到以及什麼時候可以恢復。那麼這個系統會幫你非常大的忙。
2019 年 12 月底，我們在 GitHub 上公開了這個項目，叫 Chaos Mesh，是目前 Star 數增長最快的一個項目之一。
它的思想很簡單，通常情況下你係統有一個正常狀態，所有人都知道，在這個正常狀態下，你就開始做一些假設，比如說 kill 掉一個節點，我覺得應該出現什麼情況。然後你去做實驗，根據我的經驗，通常大家假設都是不對的，你假設kill 這個節點以後，系統還是穩定的，過幾秒它就恢復了，或者對系統沒有什麼多大影響，或者會稍微抖動一下。這個假設很可能是不靠譜的，因爲它也許開始影響別人，別人又可能繼續影響其他服務，在系統裏面就像塞車一樣，你發現塞車，只要它塞過的地方就會一直在塞車。
然後再去 verify 一下你剛纔做的實驗，你發現它是不靠譜的，然後去改進你的系統，再來一圈。這個思路很簡單。
上面是我們爲整個系統設計的圖，我不知道大家看到這個 monkey 的時候有什麼感受。我當時第一反應是中外文化太一致了，因爲國外叫 Chaos Monkey，國內叫什麼？中國有四大名著，很厲害的那隻猴子叫什麼？天庭以前從來沒有想到過，一隻猴子可以造成這麼大的影響，最後得改整個體系，以便讓這隻猴子能融入整個體系。
這個跟 Chaos Monkey 的想法是一模一樣的，你會讓這隻猴子融入你的系統，最終，你會把它吸納到你的體系來。你不得不爲它單獨建一個職位，單獨建一個體系，單獨建一個流程。所以這個過程中，是不是中國幾千年的文化跟老外的文化突然有了共同點，大家都一樣，都需要猴子，一隻猴子的效果非常好。在猴子出現之前，楊戩是無敵的，天庭的蟠桃也從沒被偷吃過。
上圖是我們開源之後的反應，馬上就登上了 Go 語言的 trending 第一名，在 hacker news 上面也登上了首頁，當時排名是第十。全世界人民都覺得這個很好，很歡欣很鼓舞，我們自己也是。
其實大家都想發明一隻猴子，這隻猴子可能是一般的猴子，也可能是孫悟空，到底我們需要什麼樣的猴子呢？所以，在做這個系統前我們做了一個調研，我們自己做的 Chaos Mesh 有哪些功能，我們做了哪些事。
比如 CPU burn，就是相當於，在一個系統裏面你有一個進程把 CPU 都燒光，死循環，再不行，就多線程的死循環，總能把 CPU 吃得差不多，這個有點像什麼呢？有點像 CPU 的過熱，CPU 過熱之後就開始降頻，就是你的系統突然變慢了，很有可能是機房的通風不行，可能是一個小小的意外，你係統就變慢了，變慢了以後，你整個公司的業務是什麼樣的，沒有人知道。最可怕的是老闆不知道，老闆不知道大家就比較辛苦，不管是誰的問題，全部叫起來。Mem burn 是內存分不出來，比如一個系統 20G 內存，突然一個程序佔了 19G，你本來應該能夠跑的沒有內存了，這個很容易理解，讓內存泄露，別的不擅長，這個太簡單了。這些功能很好做，Chaos Mesh 目前還沒有做而已，後面會馬上支持。
講了這麼多好處，大家是不是想實戰一下？我們很不好意思的貼出了一些猴子找到的 bug。
我們之前有個同事發了一條關於 Chaos Mesh 的朋友圈，他是這麼說的，『以前我覺得自己寫代碼挺牛逼的』。我問了一句，『後來呢？』他說『不說了，連續幾周都在修 bug』。相信我，大家的應用程序跑上來，不會有什麼意外，都一樣，因爲你們從來沒有測過這種情況，在這種情況下它的表現正常才奇怪，因爲你都沒定義這種情況正常是什麼。大家有沒有想過，你寫進磁盤，在磁盤上讀，讀出來的數據不一樣，程序什麼表現？很可怕，有人程序沒有掛，因爲他自己寫的東西他沒有校驗，寫出來的數據在後面沒有加一個校驗符，下次讀出來直接用了，天知道這是個什麼結果。然後關鍵是它還沒死，在系統裏面接着跑，跑了以後影響別的，就像一個病毒在系統裏面複製，結果是不可預期的。怎麼辦？這個系統都可以幫大家搞定。下面是我們自己找的一些 bug。
上圖是一個 pod 跑數據庫的過程，跑的過程中我們 kill 掉了前面大圖裏面的一個存儲節點，我們的預期是 QPS 肯定會掉下來，後面會恢復。我們看起來好像是的，QPS 會掉 0，到 0 之後，大概過幾秒鐘好像又恢復了，看起來一切都正常。直到我們去觀察整個系統的時候，會發現 QPS 的恢復花了相當長的一段時間，整個持續了大概有 10 分鐘才恢復到正常值。我們的預期是 kill 掉之後很快應該能夠恢復到正常值，但是它實際上沒有做到。毫無疑問後來我們發現了一個 bug。
上圖是它的用法，像一般的開源項目一樣，先克隆下來，當然 K8s 有個好處，安裝比較方便，三部曲就完了。完了以後就開始設定行爲，比如說我整個系統裏面想隨機 kill 掉一些節點或者 kill 掉某一些節點，我應該怎麼做，我選擇我 kill 掉哪些標籤的節點，kill 的方式什麼樣呢？每隔 2 分鐘一次，這個配置很好理解。我們只要部署一下剛纔的 YAML 文件就行，當我們不想做實驗的時候，只要停掉整個實驗，這個時候通常我們的系統應該是恢復的，這個時候是大家最緊張的時候，因爲大概率你的系統是沒有恢復的。這是我們的經驗，總是能找到問題。
這是我們每隔 5 分鐘 kill 掉一個節點的圖，看起來 QPS 是這樣的，最終都能回來。希望大家的線上系統看起來是這樣，看起來還是正常的。
接下來是比較難的一部分，很多人可能對 K8s 是什麼不太清楚，其實 K8s 相當於是一個操作系統，node 是相當於一臺機器，operator 是相當於 systemd，pod 相當於 process，sidecar 相當於 thread，最後一個需要一點時間來理解。
其實上面這麼多，總結下來一句話就是 All in K8s，整個系統是完全基於 K8s 在用的，如果你的系統沒有用 K8s，你沒有辦法用這套系統在上面做實驗。有個很有意思的事，我們在美國跟用戶聊，你用什麼部署方式，我說我們用 Ansible。再問你們有沒有 K8s？要是沒有，那我就不看了。在美國就是這樣，K8s 是一個政治正確的選擇了，如果你的系統不是跑在 K8s 上面，就不用聊了，大家 match 不上。就像相親一樣，有車嗎？有房嗎？如果沒有，再見。所以還沒學的同學趕緊學一下，要不然以後跟美國人交流有困難。
這是它的整個結構，重點看 CRD 裏面，可以構造的幾種常見的錯誤，像網絡分區、網絡丟包、網絡重發、帶寬限制等等。然後是文件系統，我們可以進行文件操作，寫出來的數據和讀出來的數據不一樣。或者是寫入失敗，或者讀取失敗。
Kubernetes 有 API Server，很好理解，你可以認爲有 N 只猴子，每隻猴子只做一件事，比如有一隻猴子只做網絡相關的，有一隻就只做 I/O 相關的，本身都是 CRD。網絡相關的使用的是 iptables，大家都知道 iptables 可以做網絡上的各種操作，比如說隔離，比如說讓數據只能進不能出等等，I/O 這邊用的是 fuse。
這是常見的幾種錯誤，這裏看看 I/O delay，我們曾經遇到一個問題，某雲盤，一次寫入操作花了 5 秒，你知道大概率是哪裏有個 bug，但是你不知道具體哪裏有 bug。你就是起個虛擬機掛了個盤，最後一個操作 flush 5 秒，就一點點數據，肯定是哪裏有個 bug，通常情況下大家覺得這個 disk 是本地的，沒有問題。我印象中有人寫過一篇文章說，比磁盤損壞更可怕的是什麼？是不知道爲什麼一個磁盤讀寫速度只有原來的 1/10，就是它突然掉速了，這比壞掉更可怕。
下面這些圖我們可以看出它是怎麼 work 的。
再來談下未來的計劃，我們未來計劃有 verifier，verifier 這邊可以添加更多的功能，比如我可以在某個時間點可以做什麼操作，甚至我中間替換數據然後再去觀察系統狀態是不是不對。當然也會增加一個好看好用的界面，現在整個是通過命令行去操作的。另外也希望能夠支持多雲的錯誤注入，大家也不要假設雲上的服務都是 OK 的。程序都是人寫的，黑天鵝一定會出現的。
最後說一下整個系統可觀測性的重要性，我不知道大家有沒有做過數據庫運維，通常業務那邊說我有一個什麼問題，我的第一反應是你是什麼 workload。對方跟你講了半天，你問對方你是讀多還是寫多，讀是寫的多少倍。對方說我也不是太清楚，這時候怎麼辦？這時候就需要有一套系統，能夠在不需要業務側給你解釋的時候，你就知道業務側做的是什麼事，因爲業務側給你解釋也不一定準確，因爲他有自己的理解，每個人理解不一樣。這個很可怕，這時候如果有一套系統，能夠很好地去觀測，你什麼也不用跟我講了。
這個系統大概什麼意思呢？大家可以看一下上圖。這裏面最亮黃色是什麼意思呢？是整個系統的寫入熱點，寫入熱點是什麼概念？它是一條這樣傾斜的斜線，這條線告訴我們的是什麼？我後面怎麼操作數據庫不用管，看一眼就知道，這代表這個系統裏面現在有 6 個表一直在做追加數據的操作。比如我們看到上面一大片紫色的分佈很均勻，意味着它的寫入相對比較隨機，所以數據庫這一側，你不用跟別人聊，你一看就知道你要做什麼操作，幾個表在追加，幾個表在隨機寫，幾個表在隨機讀，還是有幾個熱點，這個好處是什麼？當出現問題的時候快速定位，有這樣一套系統就清楚了
這是整個項目在 GitHub 上的 pingcap/chaos-mesh 上，也歡迎大家關注我們的 Twitter：chaos_mesh，以上就是我爲大家帶來的分享，謝謝大家。
原文閱讀：https://mp.weixin.qq.com/s/dYv7neg6Pewbt1Mih_6c6Q?scene=25#wechat_redirect
