Sự cố ngày 17/8 và những cải tiến hạ tầng sắp tới của GitHub

Cập nhật về sự cố ngày 17 tháng 8 và các bước chúng tôi đang thực hiện để cải thiện độ tin cậy.

Ngày 20 tháng 8 năm 2026

4 phút

Vào ngày 17 tháng 8, GitHub đã gặp phải một sự cố kéo dài 7 giờ 47 phút. Sự cố này làm gián đoạn github.com, xác thực, GitHub Actions, các API, pull request, issues và Copilot, gây ảnh hưởng đến các nhà phát triển và tổ chức trên toàn thế giới. Nếu bạn đang cố gắng phát hành phần mềm vào ngày hôm đó, chúng tôi thành thật xin lỗi vì đã làm bạn thất vọng.

Đây là sự cố nghiêm trọng thứ hai của chúng tôi trong tháng 8, sau lỗi Actions vào ngày 6 tháng 8. Vào tháng 3 và tháng 4, tôi đã chia sẻ về công việc đang được tiến hành để cải thiện độ tin cậy của GitHub. Chúng tôi đã đạt được những tiến bộ, nhưng những sự cố này cho thấy rõ rằng chúng tôi phải đẩy nhanh tiến độ công việc này.

Chuyện gì đã xảy ra

Cuộc điều tra của chúng tôi cho thấy sự cố bắt đầu khi lưu lượng truy cập đạt mức cao kỷ lục mới, và một thành phần cơ sở hạ tầng quan trọng tại trung tâm dữ liệu Central US của chúng tôi đã không thể mở rộng kịp thời. Áp lực về năng lực hệ thống sau đó đã lan rộng, gây ra lỗi xác thực và làm gián đoạn nhiều dịch vụ của GitHub.

Việc khôi phục đòi hỏi nhiều hành động phối hợp. Các đội ngũ đã định tuyến lại lưu lượng truy cập, cô lập cơ sở hạ tầng bị ảnh hưởng và khôi phục dịch vụ theo từng giai đoạn. Hầu hết các dịch vụ của GitHub đã được khôi phục vào đầu ngày hôm đó, nhưng một số dịch vụ Copilot mất nhiều thời gian hơn. Các lỗi trong những dịch vụ đó đã kích hoạt vòng lặp thử lại (retry loop) ở phía máy khách, làm tăng lưu lượng truy cập trong quá trình khôi phục. Chúng tôi đã phải giảm thiểu hành vi đó trước khi có thể khôi phục lưu lượng truy cập một cách an toàn. Phân tích nguyên nhân gốc rễ đầy đủ bao gồm một dòng thời gian kỹ thuật chi tiết.

Cả hai sự cố đều không phải do thay đổi mã nguồn hay cấu hình. Về bản chất, cả hai sự cố đều là lỗi về năng lực hệ thống. Chúng tôi đã không mở rộng kịp các thành phần quan trọng trước khi nhu cầu vượt quá khả năng đáp ứng. Kể từ tháng 4, số lượng commit hàng tháng đã tăng từ 1,4 tỷ lên 2,9 tỷ. Sự tăng trưởng đó giải thích cho áp lực lên hệ thống của chúng tôi, nhưng đó không phải là lý do bào chữa cho những sự cố này.

Những gì chúng tôi đã làm và những bước tiếp theo

Là một phần trong các cam kết về độ tin cậy mà chúng tôi đã đưa ra đầu năm nay, chúng tôi tập trung vào ba ưu tiên: tăng cường năng lực, cải thiện hiệu suất và loại bỏ các nút thắt kiến trúc. Kể từ đó, chúng tôi đã bổ sung hơn 3 triệu lõi CPU, 120 petabyte lưu trữ tốc độ cao và năng lực mạng đáng kể. Chúng tôi đã lắp đặt phần cứng nhiều nhất có thể trong phạm vi điện năng cho phép tại các trung tâm dữ liệu hiện có, đồng thời đẩy nhanh quá trình chuyển đổi sang Azure.

Hiện nay, Azure phục vụ khoảng 58% tải trọng nền tảng của GitHub và một nửa tổng số các thao tác Git, tăng từ mức 12% tải trọng nền tảng vào tháng 5. Sự mở rộng này cũng hỗ trợ cho sự tăng trưởng trong các lượt chạy GitHub Actions như được hiển thị bên dưới.

Cơ sở hạ tầng và năng lực của Azure cũng đã thúc đẩy công việc của chúng tôi trong việc mở rộng các monorepo lớn nhất. Cột mốc tiếp theo của chúng tôi là một kiến trúc có khả năng mở rộng năng lực đọc tuyến tính theo số lượng người đọc, cho phép thực hiện các thao tác đọc không giới hạn. Chúng tôi sẽ triển khai dần dần, bắt đầu với các monorepo lớn nhất.

Quy mô không phải là thách thức duy nhất. Khi tốc độ và sự phức tạp của các thay đổi tăng lên, các quy trình vận hành hiện tại của chúng tôi đã không theo kịp. Chúng tôi đã chuyển hướng các đội ngũ và nguồn lực sang ưu tiên tính khả dụng, đồng thời đầu tư vào việc kiểm thử chặt chẽ hơn, triển khai an toàn hơn, khả năng quan sát tốt hơn và cảnh báo hiệu quả hơn. Chúng tôi đã đạt được tiến bộ, nhưng công việc này vẫn chưa hoàn tất.

Ngoài ra, chúng tôi cũng đang cô lập các hệ thống quan trọng và loại bỏ các phụ thuộc dùng chung giữa chúng. Công việc này được thiết kế để giảm khả năng xảy ra sự cố và hạn chế tác động của chúng khi có sự cố phát sinh.

Chúng tôi học hỏi từ mọi sự cố và bổ sung các công việc mới vào luồng công việc đảm bảo tính khả dụng. Các sự cố ngày 6 tháng 8 và 17 tháng 8 đã dẫn đến hai thay đổi tức thời. Thứ nhất, chúng tôi đang áp dụng các giới hạn thử lại, ngân sách thử lại và thời gian chờ (timeout) biến thiên nhất quán trên các tương tác giữa các dịch vụ để ngăn chặn tình trạng "bão thử lại" (retry storms) và tải trọng dây chuyền. Thứ hai, chúng tôi đang xem xét các cảnh báo về CPU và bộ nhớ có mức độ ưu tiên thấp hơn để xác định các thành phần có thể gặp lỗi trong các đợt tăng đột biến lưu lượng truy cập.

Cam kết của chúng tôi về tính khả dụng cao không chỉ là một lời hứa kỹ thuật. Cộng đồng nhà phát triển dựa vào GitHub để xây dựng, phát hành và vận hành công việc của họ. Điều đó chỉ có thể thực hiện được nếu bạn có thể tin tưởng vào chúng tôi, và vào ngày 17 tháng 8, bạn đã không thể làm điều đó. Trách nhiệm của chúng tôi là khắc phục vấn đề này. Chúng tôi sẽ giành lại niềm tin của bạn thông qua việc mở rộng và đảm bảo độ tin cậy của nền tảng.

Tác giả

Vladimir Fedorov là Giám đốc Công nghệ (CTO) của GitHub, mang theo hàng thập kỷ kinh nghiệm trong vai trò lãnh đạo kỹ thuật và đổi mới. Là một người ủng hộ nhiệt thành cho năng suất của nhà phát triển, Vlad đang dẫn dắt đội ngũ kỹ thuật của GitHub để định hình tương lai của các công cụ dành cho nhà phát triển và đổi mới với tư duy ưu tiên nhà phát triển.

Trước khi gia nhập GitHub, Vlad đồng sáng lập UserClouds, một công ty khởi nghiệp chuyên về quản trị dữ liệu và quyền riêng tư. Ông đã dành 12 năm tại Facebook (nay là Meta) với tư cách là Phó Chủ tịch cấp cao, lãnh đạo các đội ngũ kỹ thuật với hơn 2.000 nhân sự trong các lĩnh vực Quyền riêng tư, Quảng cáo và Nền tảng. Trước đó trong sự nghiệp, Vlad từng làm việc tại Microsoft và nhận bằng Cử nhân và Thạc sĩ Khoa học Máy tính tại Caltech. Hiện ông đang phục vụ trong hội đồng quản trị của Codepath.org, một tổ chức chuyên tái lập trình giáo dục đại học để tạo ra thế hệ kỹ sư, CTO và nhà sáng lập đầu tiên am hiểu về AI.

Vlad sống tại Bay Area và khi không làm việc, ông thích dành thời gian ở ngoài trời và tham gia các hoạt động trên mặt nước cùng gia đình.

Bài viết liên quan

Chúng tôi cũng có bản tin (newsletter)

Khám phá các mẹo, hướng dẫn kỹ thuật và các phương pháp hay nhất trong bản tin hai tuần một lần dành riêng cho các nhà phát triển.

Địa chỉ email của bạn