GitHub bị sập 7 giờ 47 phút: Nguyên nhân và cách ứng phó

GitHub bị sập gần tám tiếng vào ngày 17/08/2026 không phải vì một bản cập nhật lỗi. Theo báo cáo hậu kiểm của chính GitHub, lưu lượng chạm đỉnh mới trong lúc một thành phần hạ tầng quan trọng tại trung tâm dữ liệu Central US không thể mở rộng kịp. Từ một điểm nghẽn, lỗi lan sang đăng nhập, GitHub Actions, API, pull request, issue và Copilot.

Sự cố kéo dài 7 giờ 47 phút. Con số này đủ lâu để biến câu “đẩy nhanh một bản vá nhỏ” thành buổi họp có đông người nhưng ít code. Điều đáng đọc trong báo cáo không phải riêng chuyện GitHub gặp lỗi. Nó cho thấy một dịch vụ lớn có thể vấp ở đâu khi nhu cầu tăng nhanh, vì sao thao tác thử lại liên tục làm phục hồi khó hơn và đội phát triển nên chuẩn bị gì trước lần gián đoạn kế tiếp.

GitHub bị sập ngày 17/08/2026: chuyện gì đã xảy ra?

GitHub cho biết sự cố bắt đầu khi lưu lượng đạt một mức cao mới. Một thành phần hạ tầng quan trọng tại Central US không tăng năng lực xử lý theo kịp. Áp lực tài nguyên sau đó lan qua các hệ thống có liên quan. Người dùng gặp lỗi xác thực, không truy cập được một số tính năng hoặc thấy tác vụ chạy thất thường.

Phạm vi ảnh hưởng khá rộng: github.com, đăng nhập, GitHub Actions, API, pull request, issue và Copilot đều bị gián đoạn. Đây là chi tiết cần để ý. Nhiều đội đã đưa gần hết quy trình phát triển lên GitHub, từ lưu mã nguồn đến kiểm thử và phát hành. Vì vậy, một lỗi hạ tầng có thể chặn nhiều mắt xích cùng lúc chứ không đơn giản là “không mở được trang web”.

Việc phục hồi cũng không diễn ra theo kiểu bật lại một công tắc. Đội vận hành phải chuyển hướng lưu lượng, cô lập phần hạ tầng bị ảnh hưởng rồi khôi phục từng nhóm dịch vụ. Phần lớn dịch vụ trở lại sớm hơn, nhưng một số dịch vụ Copilot mất thêm thời gian.

Lý do khá oái oăm: lỗi ở Copilot kích hoạt vòng lặp thử lại phía máy khách. Khi yêu cầu lỗi, ứng dụng gửi lại; nếu rất nhiều máy cùng gửi lại dồn dập, hệ thống đang yếu phải nhận thêm tải. GitHub phải xử lý hành vi này trước khi đưa toàn bộ lưu lượng trở lại. Nói nôm na, lúc quầy đang kẹt, cả hàng người cùng hỏi “xong chưa?” mỗi giây thì nhân viên càng khó làm xong.

Nguyên nhân không phải một lần triển khai lỗi

Báo cáo của GitHub nói rõ cả sự cố ngày 17/08 và một sự cố GitHub Actions ngày 06/08 đều không bắt nguồn từ thay đổi mã hay cấu hình. Cốt lõi của hai vụ là thiếu năng lực xử lý tại các thành phần quan trọng. Nhu cầu vượt khả năng phục vụ trước khi hạ tầng kịp mở rộng.

Chi tiết này giúp tránh một kết luận quá tiện: cứ hệ thống lỗi là ai đó vừa bấm nút deploy sai. Triển khai có thể gây sự cố, nhưng năng lực, kiến trúc phụ thuộc và cách phần mềm phản ứng khi gặp lỗi cũng quan trọng không kém. Một hệ thống chạy ổn ở tải hôm qua chưa chắc chịu được đỉnh tải hôm nay.

GitHub đưa ra một số số liệu để giải thích sức ép. Số commit mỗi tháng tăng từ 1,4 tỷ vào tháng 4 lên 2,9 tỷ ở thời điểm công bố báo cáo. Công ty nói tăng trưởng giải thích vì sao hạ tầng chịu áp lực, nhưng không dùng nó làm lý do miễn trách nhiệm. Cách nói này khá thẳng: đông khách là chuyện tốt, song quán vẫn phải đủ bàn.

GitHub cho biết đã bổ sung hơn 3 triệu lõi CPU và 120 petabyte bộ nhớ tốc độ cao. Tại thời điểm báo cáo ngày 20/08, Azure phục vụ khoảng 58% tải nền tảng và một nửa hoạt động Git, tăng từ 12% tải nền tảng hồi tháng 5. Những con số này là thông tin do GitHub công bố, không phải phép đo độc lập từ bên ngoài.

Vòng lặp retry có thể biến lỗi nhỏ thành lỗi lớn

Retry là việc ứng dụng tự gửi lại yêu cầu sau khi lần đầu thất bại. Cơ chế này rất hữu ích khi lỗi chỉ thoáng qua, chẳng hạn kết nối mạng chập chờn vài trăm mili giây. Rắc rối xuất hiện khi hàng triệu máy thử lại cùng nhịp, không có giới hạn và cũng không giãn thời gian chờ.

Hãy hình dung 10.000 tác vụ đều gọi một API. API bắt đầu chậm, mỗi tác vụ lập tức thử lại ba lần. Hệ thống chưa kịp xử lý 10.000 yêu cầu ban đầu đã nhận thêm 30.000 yêu cầu. Độ trễ tăng, nhiều yêu cầu tiếp tục thất bại, rồi một vòng retry mới lại đến. Đây thường được gọi là retry storm, tức “bão thử lại”.

Cách xử lý quen thuộc là đặt số lần thử tối đa, tăng dần thời gian chờ và thêm một khoảng ngẫu nhiên nhỏ để các máy không cùng gọi lại một lúc. Hệ thống cũng cần retry budget, hiểu đơn giản là giới hạn lượng yêu cầu thử lại được phép tạo ra trong một khoảng thời gian. Sau sự cố, GitHub nói sẽ áp dụng thống nhất giới hạn retry, ngân sách retry và thời gian chờ biến đổi cho giao tiếp giữa các dịch vụ.

Đây là phần đáng mang về áp dụng ngay, kể cả khi hệ thống của bạn nhỏ hơn GitHub rất nhiều. Script CI chạy lại vô hạn không phải là “kiên trì”. Nó chỉ là một đồng nghiệp máy móc đang đập cửa phòng máy chủ.

Vì sao một lần GitHub lỗi có thể làm cả quy trình đứng lại?

Nhiều đội dùng GitHub như trung tâm của công việc: mã nằm trong repository, kiểm thử chạy bằng Actions, yêu cầu thay đổi nằm trong pull request, phát hành đi qua API, còn trao đổi kỹ thuật nằm ở issue. Tiện thì rất tiện. Nhưng khi nhiều chức năng cùng phụ thuộc một nền tảng, phạm vi ảnh hưởng cũng rộng hơn.

Ngay cả khi máy lập trình viên vẫn có bản sao Git cục bộ, họ có thể không merge được pull request, không lấy được secret cho pipeline hoặc không đẩy bản build qua quy trình phát hành chuẩn. Đội dùng GitHub Copilot Cloud Agent còn phải tính thêm khả năng tác vụ AI bị chậm hoặc dừng khi dịch vụ Copilot gặp vấn đề.

Điều này không có nghĩa mọi công ty phải rời GitHub hay dựng bản sao cho từng nút bấm. Làm vậy vừa đắt vừa dễ tạo thêm một hệ thống dự phòng không ai biết vận hành. Cách hợp lý hơn là xác định việc nào thật sự phải tiếp tục khi GitHub gián đoạn: xử lý sự cố sản xuất, phát hành bản vá khẩn, truy cập mã nguồn quan trọng và liên lạc với người có quyền quyết định.

Checklist khi GitHub bị lỗi

Đầu tiên, kiểm tra GitHub Status thay vì để mỗi người tự đoán. Trang trạng thái không phải lúc nào cũng phản ánh mọi lỗi ngay phút đầu, nhưng nó cho biết nhà cung cấp đã xác nhận gì và dịch vụ nào đang bị ảnh hưởng. Ghi lại thời điểm bắt đầu, triệu chứng và các hệ thống nội bộ đang chờ GitHub.

Ngăn hệ thống nội bộ retry vô hạn

Tạm dừng các job đang thử lại dồn dập nếu bạn kiểm soát được chúng. Đừng bấm chạy lại hàng loạt pipeline chỉ vì giao diện chưa báo thành công. Việc đó vừa không giúp GitHub phục hồi nhanh hơn, vừa có thể tạo hàng dài job phải xử lý khi dịch vụ trở lại.

Giữ một đường lui vừa đủ

Repository quan trọng nên có bản sao theo chính sách backup của công ty. Remote Git dự phòng có thể hữu ích cho nhóm cần phát hành bản vá khẩn, nhưng phải kiểm tra định kỳ quyền truy cập và cách đồng bộ. Một bản sao tồn tại mà đến lúc cần mới phát hiện khóa truy cập hết hạn thì giá trị chủ yếu là trang trí.

Runbook ứng phó nên nằm ở nơi vẫn truy cập được khi GitHub lỗi. Tài liệu đó cần ghi người quyết định có phát hành ngoài quy trình chuẩn hay không, cách lấy artifact đã được kiểm tra và kênh liên lạc thay thế. Không nên sao chép secret bừa bãi sang tài liệu hoặc máy cá nhân để “phòng hờ”.

Khôi phục theo thứ tự ưu tiên

Khi GitHub hoạt động lại, đừng cho mọi pipeline cùng chạy trong một phút. Hãy ưu tiên việc phục vụ sản xuất hoặc khách hàng, sau đó mới đến build định kỳ và tác vụ ít gấp. Cách này giảm tải cho cả GitHub lẫn runner, registry và hệ thống triển khai của chính bạn.

GitHub đang sửa gì sau sự cố?

Ngoài việc tăng năng lực, GitHub nói đang tách các hệ thống quan trọng và gỡ bớt phụ thuộc dùng chung. Mục tiêu là giảm khả năng một lỗi lan rộng. Công ty cũng rà soát cảnh báo CPU, bộ nhớ từng được xếp ưu tiên thấp để tìm thành phần có thể đổ vỡ khi lưu lượng tăng đột ngột.

Một hướng khác là kiến trúc đọc có thể tăng năng lực gần tuyến tính theo số lượng máy đọc, trước tiên áp dụng cho các monorepo lớn. GitHub cũng nhắc đến kiểm thử tốt hơn, triển khai an toàn hơn, khả năng quan sát hệ thống và cảnh báo hiệu quả hơn. Đây vẫn là kế hoạch do nhà cung cấp công bố. Hiệu quả thực tế cần được nhìn qua độ ổn định trong những tháng tiếp theo.

Báo cáo có một điểm đáng đánh giá cao: GitHub nêu thời lượng, phạm vi, nguyên nhân và phần khiến phục hồi chậm, thay vì chỉ nói “dịch vụ đã ổn định” rồi đóng rèm. Với đội vận hành, hậu kiểm tốt không nhằm tìm người chịu trận. Nó giúp tìm ra điều kiện khiến lỗi lan rộng và biến phát hiện đó thành thay đổi có thể kiểm tra.

Đội nhỏ có cần làm mọi thứ như GitHub?

Không. Đội năm người không cần ba trung tâm dữ liệu và một dự án di chuyển hạ tầng khổng lồ. Nhưng các nguyên tắc vẫn dùng được: đặt giới hạn retry, đo tải ở điểm nghẽn, tránh phụ thuộc chung không cần thiết, sao lưu mã và tập trước cách phát hành khẩn.

Bắt đầu bằng một câu hỏi thực tế: nếu GitHub mất tám tiếng vào sáng mai, việc nào trong công ty buộc phải tiếp tục? Liệt kê hai hoặc ba việc đó, người chịu trách nhiệm và công cụ thay thế tối thiểu. Một trang runbook đã thử qua thường có ích hơn sơ đồ dự phòng rất đẹp nhưng chưa ai đăng nhập bao giờ.

Nếu chỉ rút ra một việc từ lần GitHub bị sập này, hãy kiểm tra cơ chế retry trong script, ứng dụng và pipeline. Lỗi của nhà cung cấp nằm ngoài tay bạn; việc hệ thống của mình phản ứng bình tĩnh hay góp thêm một xe tải yêu cầu thì vẫn kiểm soát được.

Nguồn tham khảo

• GitHub: The August 17 outage, and the work ahead, công bố ngày 20/08/2026.
• GitHub Status: báo cáo nguyên nhân sự cố ngày 17/08/2026.
• GitHub Status: sự cố GitHub Actions ngày 06/08/2026.