Slack 針對今年年初的爆炸提出了說明：「Slack’s Incident on 2-22-22」，但真正的重點都在 Hacker News 的討論串上：「Slack’s Incident on 2-22-22 (slack.engineering)」。

大概有三件事情可以講，第一個是掛掉的原因，第二個是剛發出來的時候，一堆人對於標題用的「2-22-22」很感冒，第三個是剛剛 (一個小時前)，Cal Henderson (Slack 的 CTO) 跑到 Hacker News 的討論串上回應...

Downtime 的部份

這次的 downtime 主要是發生在 Group Direct Message (GDM) 的部份：

A significant element of the datastore load appeared to be from a query that listed Group Direct Message (GDM) conversations by user. This operation is fronted by our cache tier, so the high query load seemed to indicate something was wrong with our caches.

這個 GDM 的查訊效率不高，而是靠 cache layer 撐住的，加上二月 22 日那天他們在更新 Consul 的 agent，導致 hit rate 的下降，以及遇到一個比較大的 peak time，接著就壓垮了資料庫。

oh，這中間還有 Vitess 一起進來打架，原文講的比較清楚，但需要花一些時間看。

2-22-22

剛發表出來的時候，其實大多數的討論反而是在討論「2-22-22」這件事情，這的確是很差的表示方法，尤其對於一份公告來說，不過這個問題本來就是個 flame war 等級的話題...

Slack CTO (Cal Henderson) 的回應

在重刷頁面的時候發現 iamcal 這個帳號的回應，而 Cal Henderson (Slack CTO) 的個人網站是 www.iamcal.com，雖然不確定這是不是本人帳號，但看起來之前在 2011 註冊後都沒動...

這個帳號回了兩個訊息，一個是提到 AWS 上其實很常看到 failure，需要靠本身架構的穩定性來撐：

Our underlying hardware (AWS) is nothing like this reliable. We see regular (several times a year) failure of racks of machines or whole DCs.

Across the whole fleet (all services), we lose 1-10 servers per day as a baseline. Major events are then on top of that and can impact thousand of hosts at once.

另外一個是反駁自以為的量級估算：

> Even the largest Slack instance probably has under 100,000 users and less than 1000 peak messages per second.

This is not true, by an order of magnitude.

好像還可以繼續在盯一下，不知道還會不會有回應...

To respond on your own website, enter the URL of your response which should contain a link to this post's permalink URL. Your response will then appear (possibly after moderation) on this page. Want to update or remove your response? Update or delete your post and re-enter your post's URL again. (Learn More)