GitHub báo cáo 8 sự cố trong tháng 10/2026

GitHub vừa công bố báo cáo độ khả dụng tháng 10/2026, ghi nhận 8 sự cố khiến hiệu năng các dịch vụ bị suy giảm. Đáng chú ý nhất là hai đợt gián đoạn ghi dữ liệu (write outage) cùng nguyên nhân và sự cố mạng tại Azure Central US tác động tới hơn 34.128 người dùng đã đăng nhập.

Báo cáo do Jakub Oleksy công bố ngày 12/11/2026 cho thấy GitHub đã bổ sung dung lượng Azure độc lập có thể mở rộng và loại bỏ nhiều đường lan rộng lỗi. Tuy nhiên, các sự cố trong tháng cho thấy việc tăng dung lượng phải đi kèm vận hành an toàn hơn, cô lập tốt hơn và phục hồi vùng đã được kiểm chứng.

Tiến độ di chuyển hạ tầng

Tính đến ngày 9/11, 140 trong 151 dịch vụ production và 32 trong 50 MySQL primary đã chạy tại Azure Central US. Azure phục vụ 63% lượt đọc của các dịch vụ đã di chuyển, 66% lượt đọc của monolith và 52% lượt đọc Git. GitHub cũng hoàn tất mở rộng compute trên cả 9 cụm Kubernetes tại Central US, tăng hơn gấp đôi dung lượng.

Lưu lượng của các dịch vụ đã di chuyển tăng 82% kể từ tháng 3, và Central US đang hấp thụ phần tăng trưởng vượt mức tải trung bình tuần cao nhất từng được phục vụ từ datacenter cũ. Giai đoạn tiếp theo của East US 3 chậm khoảng một tuần so với kế hoạch, với đợt tăng tải đầu tiên được kiểm chứng vào tuần đầu tháng 12.

Những cải thiện kỹ thuật đáng chú ý

• Thay đổi với GitHub Actions tăng dung lượng cho các request control-plane quan trọng trên Azure.
• Một biện pháp giảm thiểu NAT gateway riêng giúp giảm 85% mức sử dụng; chỉ 4 job production thất bại trong quá trình thay đổi, so với khoảng 800 nếu không có biện pháp này.
• Giới hạn kết nối và cải tiến phía client giảm nguy cơ một gián đoạn phụ thuộc biến thành "bão kết nối lại" (reconnect storm).
• Một endpoint GitHub Actions có lưu lượng hơn 250 triệu request mỗi ngày được chuyển sang đường xử lý hiệu quả hơn, giảm 85% lượt đọc database ở đỉnh.
• Yêu cầu tối thiểu 3 ký tự khi tìm kiếm repository topic giúp giảm khoảng 98% các truy vấn chậm hoặc bị ngắt.

Hai đợt gián đoạn ghi dữ liệu ngày 7/10

Biểu đồ job GitHub Actions khởi động muộn

Đợt đầu kéo dài khoảng 10 phút từ 15:14 UTC, đợt sau khoảng 9 phút từ 17:17 UTC, cùng nguyên nhân. Tỷ lệ request web và API thất bại đạt đỉnh 8,9% ở đợt đầu và 9,3% ở đợt sau, ảnh hưởng hơn 12.000 và hơn 11.000 tổ chức.

Nguyên nhân: trong bảo trì định kỳ, GitHub thay máy quản lý nơi ghi dữ liệu được gửi tới. Một máy mới khởi động với bản ghi lỗi thời còn liệt kê các database server đã nghỉ hưu. Khi được tự động bầu làm leader, nó công bố cấu hình định tuyến gửi ghi dữ liệu của nhiều database cốt lõi tới các server đã ngừng hoạt động. Cấu hình sai vượt qua kiểm tra hiện có và có hiệu lực ngay lập tức. Sau đó, một tác vụ bảo trì tự động không tuân thủ lệnh tạm dừng và kích hoạt một cuộc bầu chọn mới; vì máy mới chưa được gỡ, nó lại trở thành leader.

GitHub đã cải thiện quy trình nghỉ hưu database server, siết kiểm soát khi thêm máy quản lý định tuyến và tăng cường kiểm tra cấu hình định tuyến database.

Sự cố mạng Azure ngày 29/10

Biểu đồ request API thất bại

Sự cố mạng của Azure ảnh hưởng tới cả ba availability zone tại Central US và ít nhất 34.128 người dùng đã đăng nhập. Báo cáo mô tả đây là ví dụ cho thấy yêu cầu tăng trưởng dung lượng cần đi kèm phục hồi vùng được kiểm chứng.

Các sự cố khác trong tháng

5/10 – Job GitHub Actions trên runner do GitHub vận hành bị xếp hàng lâu hơn bình thường và một số workflow không khởi động được. Trong khoảng 90 phút tệ nhất, phần lớn job không khởi động trong 5 phút. Nguyên nhân là lỗi mạng một phần phía nhà cung cấp cloud làm gián đoạn kết nối giữa một vùng datacenter và các database trên cloud; dịch vụ gán job chờ tới khi timeout, hết bộ nhớ rồi khởi động lại.

6/10 – Lỗi máy chủ hoặc phản hồi chậm trên github.com trong khoảng 6 phút, sau đó migration doanh nghiệp bị tạm dừng khoảng 3 giờ 30 phút. Đỉnh điểm khoảng 1,3% request thất bại hoặc timeout, khoảng 6,4K tổ chức bị ảnh hưởng. Nguyên nhân là làn sóng migration khiến GitHub Enterprise Importer gửi loạt truy vấn rất lớn tới database dùng chung.

19/10 – Chậm cập nhật trạng thái workflow, log và check của Actions; khoảng 5% job khởi động muộn. Nguyên nhân là dịch vụ nội bộ mất kết nối tới các cache server và mọi server đồng loạt thử kết nối lại, làm bão hòa đường mạng dùng chung. GitHub đã giới hạn tốc độ mở kết nối mới và cảnh báo khi có đột biến.

21/10 – Chậm cập nhật pull request, trạng thái workflow và webhook trong khoảng 2 đến 3,5 giờ; audit log chậm tới 1 giờ 50 phút và mất khoảng 6 giờ 46 phút để bắt kịp. Nguyên nhân là một số server trong nền tảng streaming sự kiện gần giới hạn bộ nhớ, và việc kết nối lại ngay lập tức khiến tải lan rộng.

28/10 – Khoảng 1/10 request tới một số model thuộc họ GPT trong Copilot thất bại trong khoảng 1 giờ 16 phút. Nguyên nhân là thông tin xác thực (credential) dùng với nhà cung cấp model phía trên bị vô hiệu hóa. Code scanning autofix và code quality bị ảnh hưởng nặng hơn do chỉ dựa vào một model không có phương án thay thế.

30/10 – Một số request tới github.com treo tới khoảng 10 giây rồi lỗi trong khoảng 9 phút. Đỉnh điểm khoảng 43% lần merge thất bại, so với khoảng 3,5% lệnh gọi API. Nguyên nhân là connection pool database dùng chung cạn kiệt khi một số request cập nhật giữ kết nối lâu hơn dự kiến.

Nguyên tắc vẫn giữ nguyên: độ khả dụng trước, dung lượng sau, tính năng sau.

Góc nhìn

Báo cáo này là bài học thực tế cho các đội kỹ thuật đang vận hành hệ thống trên cloud. Phần lớn sự cố trong tháng 10 không đến từ việc thiếu tài nguyên, mà từ những cơ chế "phản ứng dây chuyền": retry đồng loạt, chờ timeout thay vì fail fast, giữ kết nối database quá lâu. Với các kỹ sư DevOps tại Việt Nam, đây là danh sách kiểm tra đáng tham khảo khi thiết kế hệ thống: thêm độ trễ ngẫu nhiên khi kết nối lại (jitter), giới hạn thời gian giữ kết nối trong pool, và bảo đảm dịch vụ không tự làm quá tải database dùng chung.

Một điểm đáng chú ý khác là bài học về bảo trì: quy trình tự động hóa có thể chính là nguồn gốc sự cố nếu dữ liệu cấu hình cũ chưa được dọn dẹp. Việc GitHub công khai chi tiết từng sự cố, kể cả lỗi do chính mình gây ra, cho thấy giá trị của văn hóa minh bạch sau sự cố (post-incident) — điều mà các đội phát triển phần mềm trong nước có thể áp dụng ngay từ quy mô nhỏ.