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

想到一段話:

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


Comments