Scaling Infrastructure Engineering at Slack

簡譯這篇精彩的分享：Scaling Infrastructure Engineering at Slack

才 2.5y ，就可以把整個 Infrastructure Engineering 弄成這樣的規模。她提到的有很多情境，架構、招募、組織 … 很有感 … XD

要聽她說 (她有點激動 XD) 。。。

Phase 1 - 2016

• 2016 年八月以前 Slack 沒有 Infra Team, 工程師 ~150 人
• 2016 年底，每分鐘有 1600 萬的訊息，走 web socket ..
• 凡事都從炸鍋開始
• 一堆組織性的挑戰
• 怎麼在一家產品導向的組織建立工程導向 (engineering-led)
• Infra 怎麼面對 Sales？ (Sales：你誰？)
• 從內部開始傳 (ㄒㄧˇ) 教 (ㄋㄠˇ), 走公司既有流程

Phase 2 - 2017

• 技術觀點：拆服務 -> cache, 導入 rate limit, traffic mgmt, deployment …
• 調整 DB Sharding 策略
• 拆服務, 定義邊界, 搞清楚誰在用 … (這不是我每天在弄的 orz …)
• 溝通的成本與風險
• 人員的單點: 一堆東西只有一個人會，人員的 SPOF …. 招募很難搞
• 必須確認找怎樣的 Infra Engineers, 建立測驗制度
• 我有好多頂帽子: CTO, Director, PM, PG …

Phase 3 - 2018

• 終於搞定 0 到 1，開始 1 到無極限
• 人長到 100+, 包含 Data, Machine Learning, Search Infra …
• 再也沒炸鍋過
• 服務模式漸進成熟: SLA, 一致的部署流程, 異常處理 … etc.
• 拆分小團隊變得合理: Data Store, Cache Infra, Service Mesh & Web Serving, Distributed Messaging …
• 招募 Director Specialists, PM … etc
• 新挑戰：
  • 大組織的一致性
  • 很難有一致性的願景
  • (Rick: 所以你要換工作了？)

3y ….

• 每天處理 400M 非同步 Jobs
• 3M to 10M DAU (daily active User)
• 1M to 7.5M 同時線上使用者
• 10 to 100 Engineers in SF, NYC, YVR

想到一段話：

不是因為你能夠，所以你應該，而是因為你應該，所以你能夠。