Slack's Outage on January 4th 2021

Slack · 2021 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bối cảnh

• Ngày làm việc đầu năm: Slack đi từ lúc vắng nhất năm sang một trong những ngày đông nhất chỉ qua một đêm; cache của client nguội nên lần kết nối đầu kéo nhiều dữ liệu hơn thường. Traffic còn có các đỉnh nhỏ đầu mỗi giờ và nửa giờ (nhắc việc, cronjob của khách khắp thế giới).
• Slack đã chuyển từ một tài khoản AWS sang nhiều tài khoản và VPC riêng theo service, nối bằng AWS Transit Gateway (TGW), dịch vụ do AWS quản lý và lẽ ra tự scale.

Thay đổi chính (diễn biến)

• Monitor bên ngoài báo lỗi tăng; đang điều tra thì dashboard và alerting của chính Slack sập. Rollback vài thay đổi trong ngày (không phải nguyên nhân); điều tra bằng console nội bộ, CLI, log và truy vấn thẳng backend metric.
• Mạng suy giảm diện rộng; đỉnh nhỏ lúc 7:00 PST cộng mất gói làm tầng web bão hoà (gọi backend chậm, giữ tài nguyên): Slack không dùng được.
• Tự động hoá làm tệ thêm: instance không với tới backend bị đánh dấu không khoẻ và bị thay; autoscaler scale xuống vì CPU giảm (thread chờ mạng nên CPU thấp) rồi ngay sau đó scale lên theo tỉ lệ thread Apache bận: cố thêm 1.200 server trong 14 phút. Phiên SSH của người đang điều tra bị cắt khi instance bị thu hồi; phải tắt scale xuống.
• provision-service (cấu hình và kiểm instance mới) cũng chạy trên mạng hỏng, gặp đỉnh tải chưa từng có: chạm giới hạn open files của Linux và một quota AWS. Instance được tạo mà không phục vụ, chiếm chỗ tới giới hạn kích thước ASG; không dựng lại được dashboard vì provision-service quá tải.
• Khoảng 8:15 provision-service chạy lại; 9:15 đủ host, Slack từ "sập" thành "chậm": load balancer Envoy vào panic mode (cân tải lên mọi instance khi phần lớn rớt health check) cộng retry và circuit breaker. Cần nhiều instance hơn thường vì mạng vẫn chưa khoẻ.
• Nguyên nhân gốc (AWS tìm ra): một TGW quá tải và rớt gói, không scale kịp với bước nhảy packet/giây; AWS nâng capacity bằng tay, 10:40 mạng bình thường. AWS xem lại thuật toán scale TGW.
• Hành động: hẹn nhắc xin AWS nâng TGW trước kỳ nghỉ năm sau; dashboard chạy cùng VPC với DB của nó để bỏ phụ thuộc vào TGW; load test provision-service thường xuyên; xem lại cấu hình health check và autoscale để không đè provision-service.

Vì sao

• Hệ giám sát và hệ cấp phát cùng đi qua đúng tài nguyên đang hỏng; autoscaler theo CPU hiểu sai tín hiệu khi nghẽn là do chờ mạng.

Bài học cho SWE

• Tín hiệu autoscale phải được hiểu theo nguyên nhân: CPU thấp có thể là đang chờ, không phải đang rảnh.
• Hạ tầng cấp phát là một service có capacity riêng; scale-up lớn bất thường là load test mà nó chưa từng qua.
• Monitoring phải độc lập khỏi đường mạng của production; phụ thuộc ẩn qua thành phần mạng dùng chung chỉ lộ ra khi cần nó nhất.
• Mẫu traffic theo mùa (sau kỳ nghỉ) là lý do để xin trước capacity của dịch vụ managed.

Liên quan

• Sự cố và postmortem · Tự động hoá vận hành và auto-remediation · Observability và monitoring
• Sự cố AZ năm 2021 dẫn tới kiến trúc cell: Slack 2023
• Autoscale theo tín hiệu sai: Together AI 2026
• Tải đầu giờ do chính hệ tạo ra: GitLab 2019