SWE Wiki
Đăng nhập Nâng cấp
SWE Wiki › Bài tóm tắt › Slack

Shipyard: How We Built Slack's Next-Generation EC2 Platform

Bài tóm tắt Slack 2026 4. Điều chỉnh Độ khó: Trung bình

Slack · 2026 · 4. Điều chỉnh · Độ khó: Trung bình — bài gốc

Phần 3 của chuỗi: phần 1 Slack 2024 · phần 2 Slack 2025.

Bối cảnh

  • Dù rollout Chef đã an toàn hơn, mô hình cập nhật liên tục instance sống lâu chạm giới hạn: deploy theo service khó, drift cấu hình là không tránh khỏi, phối hợp nhiều tầng phức tạp. Container giải được cho một số workload, nhưng không phải tất cả (thành phần hạ tầng, worker Kubernetes, stack mạng egress).

Thay đổi chính

  • Shipyard: instance là artifact deploy được, không phải thứ sửa mãi. Hỗ trợ AMD64 và Graviton, nhiều OS (Ubuntu, RHEL, Amazon Linux).
  • Image phân lớp như container: base "slack-zero" (OS + hardening, mạng, service discovery, agent giám sát và bảo mật) do team Compute cùng Security và Monitoring giữ, build bằng AWS Image Builder (tự dọn AMI cũ, publish ID mới vào SSM Parameter, EventBridge + Lambda kích pipeline của các team phía sau, test trên instance tạm trước khi publish). Mỗi team build AMI service trên slack-zero. Khi base đổi (vá bảo mật), team phải rebuild AMI của mình.
  • Bake và provision tách bạch: cài gói và cấu hình giống nhau giữa môi trường ở pha bake; lúc boot chỉ thả cấu hình theo môi trường, lấy secret, khởi động service: instance lên trong vài giây thay vì vài phút. Chef chỉ chạy ở các pha vòng đời xác định, không còn chạy nền liên tục ghi đè.
  • Deploy = thay máy: build AMI mới rồi rollout qua Gondola (bộ điều phối deploy toàn cục) theo stage, có kiểm metric tự dừng hoặc tự rollback. ASG dùng Instance Refresh; worker Kubernetes dùng Karpenter; executor riêng cho nhu cầu đặc biệt. Artifact deploy gồm AMI + artifact Chef có phiên bản theo commit.
  • Ngoại lệ có kiểm soát: sửa khẩn trên máy đang chạy qua SSM chạy recipe Chef, rồi máy đó phải được thay. Secret vẫn cập nhật động (Consul Template từ Vault): "bán bất biến".
  • Reaper: thay instance khi bị đánh dấu "tainted" (tín hiệu từ công cụ bảo mật, sự kiện EC2, hoặc có người SSH vào máy production) hoặc khi quá tuổi tối đa. Có rate limit theo service/region/AZ và một "nút đỏ" (object trong S3) dừng toàn bộ Reaper khi có sự cố.
  • Peekaboo: inventory gần realtime từ sự kiện cloud và metadata (EventBridge, OpenSearch, Lambda), thay cho việc dùng Chef Server làm nguồn sự thật; thấy cả instance không thuộc Shipyard.
  • Ship Quick: test bake + provision trên hạ tầng thật trước khi merge, qua đội worker tạm (hai đội: Ubuntu trần để test slack-zero, slack-zero để test cookbook service).
  • Chạy tốt cho service sống ngắn; thử thách tiếp theo là instance sống lâu không thay nhanh được (node dữ liệu, GitHub Enterprise, Jira).

Vì sao

Bài học cho SWE

  • Đưa công việc nặng vào lúc build (bake) để lúc scale chỉ còn việc nhẹ.
  • Tự động hoá phá huỷ (Reaper) cần rate limit theo vùng và một công tắc dừng toàn cục.
  • Phân lớp trách nhiệm: nền tảng giữ base, team giữ lớp service, nhưng team phải rebuild khi base đổi.

Liên quan

Deploy và release an toànNền tảng nội bộ cho service (đường ray chung)Tự động hoá vận hành và auto-remediation
#Immutable infrastructure#Golden AMI#AWS Image Builder#Bake vs provision#Gondola#Instance Refresh#Karpenter#Reaper#Instance lifespan#Peekaboo inventory#Big red button

Được nhắc tới trong

Chủ đề (3)
Công ty (1)
Bài tóm tắt (5)