GitHub Giải Thích Sự Cố Kéo Dài 7 Giờ 47 Phút

GitHub ngày 20/8 công bố báo cáo về sự cố xảy ra ngày 17/8/2026. Outage kéo dài 7 giờ 47 phút, ảnh hưởng github.com, authentication, GitHub Actions, API, pull request, issue và Copilot. GitHub cho biết đây là sự cố lớn thứ hai của hãng trong tháng 8 sau vấn đề với Actions ngày 6/8.

Nguyên Nhân Bắt Đầu Từ Capacity

Theo điều tra của GitHub, traffic đạt một đỉnh mới và một thành phần hạ tầng quan trọng tại data center Central US không scale kịp. Áp lực capacity sau đó lan qua nhiều hệ thống, gây lỗi authentication và làm nhiều dịch vụ bị gián đoạn. GitHub nhấn mạnh cả sự cố ngày 6 và ngày 17 không xuất phát từ một thay đổi code hoặc configuration. Gốc của hai incident là capacity không theo kịp nhu cầu.

Commit Tăng Rất Nhanh Trong Vài Tháng

GitHub cho biết lượng commit hằng tháng tăng từ khoảng 1,4 tỷ vào tháng 4 lên 2,9 tỷ. Công ty coi mức tăng này là nguyên nhân tạo sức ép lên hạ tầng, nhưng đồng thời thừa nhận đó không phải lý do để biện minh cho outage. Số liệu cho thấy vấn đề scale của nền tảng developer đang trở nên khó hơn khi hoạt động code, automation và AI-assisted development tăng nhanh.

Recovery Gặp Thêm Retry Loop Từ Copilot

Trong quá trình phục hồi, GitHub chuyển hướng traffic, cô lập phần hạ tầng gặp vấn đề và khôi phục dịch vụ theo từng giai đoạn. Phần lớn dịch vụ trở lại sớm hơn, nhưng một số thành phần Copilot cần nhiều thời gian. GitHub phát hiện lỗi ở các dịch vụ Copilot kích hoạt một client-side retry loop. Những client liên tục thử lại khiến lượng traffic tăng đúng lúc hệ thống đang phục hồi, làm quá trình đưa dịch vụ trở lại trở nên phức tạp hơn. Đây là ví dụ rõ về “retry storm”: cơ chế retry vốn nhằm tăng độ bền có thể tạo hiệu ứng ngược nếu quá nhiều client cùng thử lại trong thời gian ngắn.

GitHub Đã Tăng Hạ Tầng Rất Lớn

Công ty cho biết các kế hoạch reliability tập trung vào ba hướng: thêm capacity, tăng hiệu quả và loại bỏ bottleneck kiến trúc. GitHub đã bổ sung hơn 3 triệu CPU core, 120 petabyte high-speed storage cùng lượng network capacity lớn. GitHub cũng đang đẩy nhanh quá trình chuyển workload sang Azure. Tại thời điểm báo cáo, Azure phục vụ khoảng 58% platform load và một nửa Git operation của GitHub, tăng mạnh từ mức 12% platform load vào tháng 5.

Kiến Trúc Monorepo Cũng Được Thay Đổi

Một mục tiêu tiếp theo của GitHub là kiến trúc có thể scale read capacity gần tuyến tính theo số reader, hướng tới hỗ trợ lượng read rất lớn trên monorepo. Hệ thống sẽ được triển khai dần, bắt đầu với các repository quy mô lớn. Bên cạnh phần cứng, GitHub thừa nhận operational practice chưa theo kịp tốc độ và độ phức tạp của nền tảng. Công ty đang đầu tư vào testing, rollout an toàn, observability và alerting.

Retry Budget Là Một Trong Những Thay Đổi Sau Sự Cố

Sau hai incident tháng 8, GitHub cho biết sẽ áp dụng retry limit, retry budget và timeout biến đổi theo cách đồng bộ hơn giữa các service. Mục tiêu là tránh retry storm và cascading load khi hạ tầng đang chịu áp lực. Công ty cũng rà lại những cảnh báo CPU và memory trước đây có độ ưu tiên thấp, nhằm phát hiện sớm component có thể gặp vấn đề khi traffic tăng đột ngột.

Bài Học Cho Đội DevOps

Sự cố cho thấy scale không chỉ là thêm server. Nếu một dependency trọng yếu có giới hạn thấp hơn phần còn lại, toàn hệ thống vẫn có thể bị nghẽn. Retry cũng cần được thiết kế với backoff, jitter, budget và circuit breaker thay vì client liên tục gọi lại. Với CI/CD phụ thuộc GitHub Actions, doanh nghiệp nên có runbook cho thời điểm nền tảng bên ngoài gặp sự cố. Repo mirror, artifact cache và khả năng trì hoãn deployment không khẩn cấp cũng giúp giảm tác động trong các incident kéo dài.

GitHub outage August 2026 ngày 17/8 kéo dài 7 giờ 47 phút và bắt nguồn từ capacity tại Central US không theo kịp đỉnh traffic. Quá trình recovery còn gặp retry loop ở một số dịch vụ Copilot. GitHub đang bổ sung hạ tầng, đẩy thêm workload sang Azure, tách dependency và chuẩn hóa retry policy. Với đội phát triển, incident này là lời nhắc rằng reliability của chuỗi công cụ bên ngoài cần được đưa vào kế hoạch vận hành chứ không thể coi như điều luôn có sẵn.