Fact: Downtime dài nhất lịch sử GitHub bắt nguồn từ một sự cố bảo trì mạng

Ngày 21 tháng 10 năm 2018, GitHub, nền tảng code lớn nhất thế giới, rơi vào sự cố nghiêm trọng. Trong 24 giờ 11 phút, nhiều dịch vụ chính của GitHub bị gián đoạn, khiến hàng triệu lập trình viên toàn cầu không thể làm việc bình thường. Đây là downtime dài nhất trong lịch sử của GitHub.

Chuyện gì đã xảy ra?

Trong lúc bảo trì định kỳ tại một data center ở bờ Đông nước Mỹ, GitHub thay thế thiết bị mạng quang 100G. Sự cố bất ngờ khiến kết nối giữa các trung tâm dữ liệu bị gián đoạn. Điều này làm hệ thống database replication mất đồng bộ, buộc GitHub phải đưa dịch vụ về trạng thái degraded (giảm chức năng).

Timeline sự cố

21/10/2018 – 22:52 UTC: GitHub phát hiện lỗi sau khi bảo trì mạng.
22/10: Metadata trở nên không đồng bộ. Issue, pull request và trạng thái commit hiển thị dữ liệu cũ. Webhook và GitHub Pages cũng ngừng hoạt động.
22–23/10: Đội ngũ kỹ sư làm việc liên tục để khôi phục dữ liệu từ replica chính xác, đồng bộ lại toàn bộ cluster.
23/10 – 16:00 UTC: Sau hơn 24 giờ, GitHub công bố đã khôi phục hoàn toàn dịch vụ.

Ảnh hưởng

Hàng triệu developer trên toàn cầu bị gián đoạn công việc.
Nhiều pipeline CI/CD phải tạm dừng vì không lấy được metadata chính xác từ GitHub.
Dù downtime kéo dài, toàn bộ source code repository vẫn được bảo toàn, không có dữ liệu nào bị mất.

Cách tổ chức khắc phục sự cố

Kích hoạt quy trình khẩn cấp: GitHub nhanh chóng cô lập các cluster database bị ảnh hưởng để tránh lan rộng.
Khôi phục thủ công từ replica chuẩn: Các kỹ sư chọn replica có dữ liệu chính xác nhất làm nguồn chuẩn, rồi đồng bộ dần với toàn bộ hệ thống.
Làm việc liên tục: Đội ngũ kỹ sư GitHub trực chiến hơn 24 giờ, chia ca để giám sát khôi phục và test tính nhất quán dữ liệu.
Minh bạch với cộng đồng: GitHub cập nhật trạng thái sự cố liên tục trên trang status và sau đó công bố postmortem chi tiết, thừa nhận vấn đề và cam kết cải thiện kiến trúc HA (High Availability).

Phản ứng từ cộng đồng

Trên Reddit và Twitter, nhiều lập trình viên gọi đây là downtime lớn nhất lịch sử GitHub.
Một số ý kiến cho rằng, đây là ví dụ điển hình về rủi ro khi replication database không được thiết kế chống split-brain tốt.
Đồng thời, GitHub cũng nhận được đánh giá tích cực nhờ việc công khai postmortem, thể hiện sự minh bạch và chuyên nghiệp.

DevOps VietNam facts: Bất kỳ một thay đổi dù nhỏ bé nào đó đều có thể gây ra downtime kéo dài nếu không có sự chuẩn bị kỹ lưỡng, vì vậy rollback plan là bắt buộc trong mọi thay đổi hạ tầng.