GitHub suy giảm dịch vụ 24 giờ (10/2018): thông báo trạng thái ba màu, ước tính sai và quyết định ưu tiên toàn vẹn dữ liệu
Ngày 21/10/2018, 43 giây mất kết nối mạng trong lúc thay thiết bị quang khiến hệ thống tự chuyển đổi cơ sở dữ liệu MySQL sang bờ Tây và gây lệch dữ liệu. GitHub chọn bảo vệ dữ liệu thay vì khôi phục nhanh, nên dịch vụ suy giảm hơn 24 giờ. Bài phân tích sau sự cố nói rõ về giới hạn của trang trạng thái xanh–vàng–đỏ và một ước tính hai giờ đã sai.
Bối cảnh thực tế
Tối 21/10/2018 (22:52 UTC), công việc bảo trì thay thiết bị quang 100G bị lỗi làm mất kết nối giữa trung tâm mạng bờ Đông và trung tâm dữ liệu chính bờ Đông của GitHub. Kết nối trở lại sau 43 giây, nhưng khoảng ngắt ngắn ấy đã kích hoạt một chuỗi sự cố: công cụ Orchestrator quản lý chuyển đổi dự phòng MySQL đã đẩy các máy chủ chính ở bờ Tây lên làm chính, và hai bờ có những bản ghi mà bên kia không có. Không thể chuyển ngược an toàn, còn độ trễ xuyên lục địa làm nhiều ứng dụng không dùng nổi với cấu trúc mới.
Theo bài phân tích của GitHub, không mất dữ liệu người dùng nhưng có thông tin hiển thị cũ hoặc không nhất quán; dịch vụ suy giảm tổng cộng 24 giờ 11 phút. Lãnh đạo chọn ưu tiên toàn vẹn dữ liệu hơn tốc độ phục hồi: giữ nguyên cấu trúc bờ Tây, tạm dừng gửi webhook và dựng trang GitHub Pages để tránh ghi thêm vào dữ liệu lệch.
Về truyền thông, bài phân tích nêu:
- Trang trạng thái chuyển vàng lúc 23:09 UTC rồi đỏ; cập nhật qua trang trạng thái và Twitter.
- Ước tính hai giờ đăng ngày 22/10 đã sai, và GitHub thừa nhận ước tính chưa tính hết các biến số.
- Trang chỉ có ba mức xanh, vàng, đỏ nên không thể hiện rõ dịch vụ nào còn chạy; GitHub đẩy nhanh cơ chế hiển thị theo từng thành phần.
- Trạng thái được giữ đỏ trong lúc xử lý hàng đợi để không báo quá lạc quan.
Phân tích nguyên nhân theo chuẩn PMP
Ước tính thời gian khôi phục không kèm khoảng bất định
Con số hai giờ được đưa ra như một điểm duy nhất. Với công việc có độ bất định cao, ước tính ba điểm hoặc khoảng giá trị cùng các giả định đi kèm giúp các bên liên quan tự điều chỉnh kỳ vọng thay vì thất vọng khi con số sai.
Mô hình trạng thái quá thô cho một nền tảng nhiều thành phần
Quy trình Quản lý truyền thông phải chọn định dạng phù hợp với thông tin cần truyền. Ba màu cho cả nền tảng che mất việc từng chức năng ra sao, nên khách hàng và các nhóm tích hợp phải tự đoán.
Quyết định đánh đổi khó nhưng được truyền thông minh bạch
Chọn giữ dữ liệu đúng thay vì nhanh là một quyết định chất lượng và quản trị rủi ro đúng đắn, nhưng nó cần được giải thích rõ cho các bên liên quan: vì sao chậm, đang làm gì, rủi ro nếu làm khác. Giữ trạng thái đỏ để không nói quá là một cam kết minh bạch tốt.
Giả định về chuyển đổi dự phòng tự động chưa được kiểm thử đủ
Cấu hình cho phép chuyển chính sang bờ khác khi gián đoạn ngắn là giả định chưa kiểm chứng bằng thử nghiệm lỗi. GitHub cam kết cấu hình lại và tăng thử nghiệm giả lập lỗi — Quản lý rủi ro cần đưa các giả định kiểu này vào sổ đăng ký và kiểm tra.
Lẽ ra PM nên làm gì
- 1
Bước 1: Chuẩn hoá cách nói về thời gian khôi phục
Đặt quy tắc: không đưa một con số khi chưa rõ nguyên nhân; đưa khoảng, giả định, thời điểm cập nhật kế tiếp. Ví dụ mức độ tin cậy:
- Đã biết cách sửa
Có thể đưa khoảng thời gian cùng giả định; cập nhật mỗi 30–60 phút.
- Biết nguyên nhân, chưa rõ khối lượng
Chỉ nêu bước đang làm và thời điểm sẽ có ước tính; không hứa mốc.
- Chưa rõ gốc, có thể mất dữ liệu
Không đưa ước tính; nói rõ đang điều tra, ưu tiên bảo vệ dữ liệu, lần cập nhật kế tiếp.
- Đã biết cách sửa
- 2
Bước 2: Thiết kế trang trạng thái theo thành phần
Mỗi dịch vụ (git, API, Pages, webhook…) có trạng thái riêng, để khách biết phần của họ ảnh hưởng ra sao.
- 3
Bước 3: Giải thích đánh đổi đã chọn ngay khi quyết định
Khi ưu tiên toàn vẹn dữ liệu, đăng ngắn gọn lý do và hệ quả; hỏi ý kiến các nhóm bị ảnh hưởng nếu có thể.
- 4
Bước 4: Kiểm thử giả định tự động chuyển đổi dự phòng
Đưa thử nghiệm mất kết nối ngắn vào chương trình thử lỗi trước khi coi hệ thống là chịu lỗi.
PM Takeaway (Bài học rút ra)
Khi chọn chậm để bảo vệ dữ liệu, uy tín nằm ở cách bạn nói: trạng thái chi tiết hơn là ba màu, ước tính là khoảng kèm giả định thay vì một con số, và lý do của đánh đổi được giải thích sớm.
Nguồn tham khảo
Nguồn: October 21 post-incident analysis — The GitHub Blog ↗ (mở trong thẻ mới)
Trắc nghiệm tình huống PMP
Câu 1/1Bạn chọn phương án nào?
Khi dữ liệu có thể bị lệch, bạn sẽ ưu tiên điều gì khi truyền thông với khách hàng?
Tình huống này hữu ích với bạn?
Bình luận (0)
Tình huống cùng lĩnh vực
Khách hàng đòi thay thế Tech Lead & Nghệ thuật Bảo vệ Đội ngũ
Mảng kiến thức trọng tâm: Quản lý Nguồn lực, Quản lý Các bên liên quan & Lãnh đạo Phục vụ (Resource Management, Stakeholder Engagement & Servant Leadership - PMBOK 6/7)
"Hố sâu chuyển giao" (Operational Transition Gap) – Khi Đội Vận hành từ chối tiếp nhận hệ thống
Mảng kiến thức trọng tâm: Chuyển giao từ Dự án sang Vận hành & Quản lý Các bên liên quan nội bộ (Project-to-Operations Transition, Operational Readiness & Internal Stakeholder Engagement - PMBOK 6/7)
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ố.