GitHub đổ lỗi cho sự cố 8 giờ vì lỗi tự mở rộng quy mô và 'cơn bão thử lại' từ VS Code
Sự cố kéo dài gần 8 giờ của GitHub đã khiến người dùng gặp lỗi trên diện rộng tại Issues, Pull Requests, API, Actions và Copilot. Nguyên nhân được xác định đến từ bộ cân bằng tải bị bão hòa, chính sách tự mở rộng quy mô sai cấu hình và một lỗi tiềm ẩn trong Visual Studio Code khiến lưu lượng tăng gấp 10 lần. GitHub cam kết sẽ sửa các chính sách và kiểm tra lại toàn bộ hệ thống.

GitHub đổ lỗi cho sự cố 8 giờ vì lỗi tự mở rộng quy mô và "cơn bão thử lại" từ VS Code
GitHub vừa công bố báo cáo chi tiết về sự cố kéo dài gần 8 giờ trong tuần này, xác định nguyên nhân đến từ bộ cân bằng tải bị bão hòa, chính sách tự mở rộng quy mô sai cấu hình và "lỗi thử lại tiềm ẩn trong Visual Studio Code".
Theo GitHub, sự cố bắt đầu lúc 13:28 UTC ngày 17/8 và chỉ được khắc phục hoàn toàn lúc 21:15 UTC — kéo dài 7 giờ 47 phút, gây ra lỗi nghiêm trọng trên diện rộng tại Issues, Pull Requests, API, Actions và Copilot.
Nguyên nhân gốc rễ
Nguyên nhân trực tiếp là sự bão hòa mạng trên các bộ cân bằng tải tại trung tâm dữ liệu Central US của công ty, khi một sidecar Istio đạt đến giới hạn đồng thời (concurrency limit).
"Vấn đề trở nên tồi tệ hơn do logic thử lại lạc quan (optimistic retry logic) khiến các bộ cân bằng tải nội bộ bị quá tải."
Điều đáng nói là hệ thống tự mở rộng quy mô (autoscaling) đã không hoạt động như mong đợi. Theo giải thích của GitHub, một chính sách bị cấu hình sai đã theo dõi dịch vụ máy chủ nhưng không theo dõi giới hạn đồng thời của sidecar, tạo điều kiện cho sự cố leo thang dây chuyền.
Vai trò của VS Code và Copilot
Điểm đặc biệt trong sự cố lần này là sự tham gia của Visual Studio Code. GitHub giải thích:
"Việc trả lời chậm cho một endpoint nội bộ đã kích hoạt một lỗi thử lại tiềm ẩn trong VS Code, khuếch đại lưu lượng lên khoảng 10 lần và khiến quá trình khôi phục Copilot Token Service bị trì hoãn."
Hầu hết các dịch vụ đã phục hồi lúc 16:36 UTC và Actions lúc 18:03 UTC, nhưng Copilot Token Service phải đến 21:02 UTC mới hoạt động trở lại bình thường.
GitHub cũng cho biết thêm: "Các yếu tố phức tạp cản trở quá trình khôi phục bao gồm một số cuộc tấn công scraping vào các endpoint codeload."
Cam kết khắc phục
Microsoft (công ty sở hữu GitHub) cho biết sẽ thực hiện các biện pháp sau:
- Sửa các chính sách tự mở rộng quy mô bị cấu hình sai
- Xem xét lại các giới hạn thử lại (retry limits)
- Kiểm tra lại cấu hình đồng thời của Istio
- Xử lý hành vi VS Code "khuếch đại lưu lượng token Copilot"
Hệ quả và cạnh tranh
Sự cố lần này có thể là giọt nước tràn ly khiến một số nhà phát triển tìm kiếm giải pháp thay thế. CEO của CloudBees, Moritz Plassnig, nhận xét trên LinkedIn:
"Cursor, OpenAI và một số startup nhỏ hơn đang xây dựng các giải pháp cạnh tranh. GitHub sẽ không còn là lựa chọn mặc định trong tương lai và chúng ta đang chứng kiến một hệ sinh thái phân mảnh hơn nhiều (điều này vừa tốt vừa xấu)."
Đáng chú ý, ngay trong lúc GitHub đang "chật vật", nền tảng lưu trữ mã nguồn Origin Code Hosting của SpaceX (công ty mẹ của Cursor) đã công bố bản beta sớm — tạo thêm áp lực cạnh tranh cho "gã khổng lồ mã nguồn mở".
Ảnh hưởng đến cộng đồng lập trình viên Việt Nam
Đối với cộng đồng lập trình viên Việt Nam, những sự cố kiểu này là lời nhắc nhở quan trọng về việc không nên phụ thuộc hoàn toàn vào một nền tảng duy nhất. Nhiều doanh nghiệp phần mềm trong nước đang sử dụng GitHub làm hạ tầng chính cho quy trình phát triển. Việc xây dựng chiến lược dự phòng, sao lưu mã nguồn định kỳ và theo dõi tình trạng dịch vụ là điều cần thiết để giảm thiểu rủi ro khi các sự cố tương tự xảy ra.