Slack 22/02/2022: nâng cấp Consul làm bộ nhớ đệm rơi, cơ sở dữ liệu quá tải và cách vừa giảm tải vừa thông tin cho người dùng

Sáng 22/02/2022, đúng giờ cao điểm, nhiều người dùng Slack không kết nối được. Nguyên nhân là một chuỗi yếu tố: nâng cấp Consul theo từng bước 25%, bộ nhớ đệm mất hiệu quả, truy vấn quét mọi shard làm Vitess quá tải và máy khách thử lại dồn dập. Slack giảm tải có kiểm soát, thông báo trên mạng xã hội rồi công bố bản post-mortem kỹ thuật vào cuối tháng 4. Phân tích dưới góc nhìn quản lý truyền thông sự cố.

Nguyễn Thu Hà, PMP

09/10/2026

5 phút đọc 0

Bình luận0

Bối cảnh thực tế

Slack là công cụ nhắn tin làm việc mà nhiều công ty dùng suốt ngày. Theo bài viết kỹ thuật chính thức của Slack, sự cố bắt đầu ngay sau 6 giờ sáng giờ Thái Bình Dương ngày 22/02/2022, tức quanh đỉnh lưu lượng của ngày. Nhiều người dùng không kết nối được; yêu cầu "client boot" (tải danh sách kênh, tuỳ chọn và hội thoại gần đây) chậm hoặc lỗi.

Nguyên nhân là một chuỗi các yếu tố chồng lên nhau, không phải một lỗi đơn lẻ:

Slack đang nâng cấp tác tử Consul theo từng bước phần trăm. Bước ngày 22/02 áp dụng cho 25% đội máy, và việc khởi động lại lần lượt loại các nút bộ nhớ đệm ra khỏi hệ thống.
Mcrib, thành phần điều khiển bộ nhớ đệm mới hơn, nâng nút dự phòng lên và làm sạch nút quay lại; điều này làm bộ nhớ đệm biến động nhiều và tỉ lệ trúng cache giảm.
Khi tải client boot, thành viên của hội thoại nhóm (GDM) được lấy bằng một "scatter query" trên dữ liệu phân mảnh theo người dùng. Khi cache trượt, gần như mọi truy vấn chạm vào mọi shard, làm cơ sở dữ liệu Vitess quá tải; phần lớn truy vấn hết hạn nên cache không thể nạp lại.
Máy khách thử lại thêm làm tải càng nặng.

Đội ngũ giảm tải bằng cách giới hạn tốc độ (throttle) các yêu cầu client boot, nhờ đó những người đã khởi động xong vẫn dùng được. Lần nới giới hạn đầu tiên làm cơ sở dữ liệu quá tải trở lại, nên họ hạ xuống và nới từng bước nhỏ hơn. Họ cũng sửa truy vấn để chỉ đọc phần còn thiếu và đọc từ bản sao. Trong lúc đó, nhóm Truyền thông và Mạng xã hội của Slack đăng thông báo ghi nhận gián đoạn và cảm ơn sự kiên nhẫn của người dùng. Bản phân tích kỹ thuật được công bố ngày 26/04/2022, khoảng hai tháng sau.

Phân tích nguyên nhân theo chuẩn PMP

Kế hoạch quản lý truyền thông (Plan Communications Management) cho sự cố chưa phân tầng theo giai đoạn
Một sự cố dây chuyền cần kế hoạch truyền thông gồm các tầng: xác nhận ban đầu, cập nhật định kỳ, khi khôi phục và post-mortem. Thông báo ban đầu "đã ghi nhận gián đoạn, cảm ơn kiên nhẫn" đúng nhưng chưa nói được người dùng nên làm gì hay khi nào có tin tiếp theo; thiếu nhịp cập nhật cam kết trước thì kỳ vọng bị bỏ trống.

Slack 22/02/2022: nâng cấp Consul làm bộ nhớ đệm rơi, cơ sở dữ liệu quá tải và cách vừa giảm tải vừa thông tin cho người dùng

Bối cảnh thực tế

Phân tích nguyên nhân theo chuẩn PMP

Kế hoạch quản lý truyền thông (Plan Communications Management) cho sự cố chưa phân tầng theo giai đoạn

Phân tích các bên liên quan (Identify Stakeholders) chỉ nhìn thấy "người dùng cuối"

Quản lý thay đổi (Perform Integrated Change Control) rủi ro nằm ở sự tương tác giữa các thay đổi

Giảm tải có kiểm soát cũng là thông điệp cần được truyền đạt

Lẽ ra PM nên làm gì

Bước 1: Chuẩn bị sẵn khung truyền thông sự cố trước khi sự cố xảy ra

Bước 2: Tách thông điệp theo nhóm bên liên quan

Bước 3: Đưa đánh giá tương tác thay đổi vào kế hoạch triển khai

Bước 4: Công bố post-mortem và theo dõi cam kết

PM Takeaway (Bài học rút ra)

Nguồn tham khảo

Trắc nghiệm tình huống PMP

Khi sự cố đang diễn ra và chưa biết khi nào xong, bạn sẽ ưu tiên kiểu cập nhật nào cho người dùng?

Tình huống này hữu ích với bạn?

Bình luận (0)