Báo cáo tình trạng hoạt động của GitHub: Tháng 7 năm 2026

Sự cố GitHub Actions vào thứ Năm, ngày 6 tháng 8, là điều không thể chấp nhận được cả về mức độ ảnh hưởng lẫn thời gian kéo dài. Tính khả dụng vẫn luôn là ưu tiên hàng đầu của chúng tôi trên toàn bộ GitHub. Tuy nhiên, với sự cố này, chúng tôi đã không thực hiện đúng cam kết với các bạn. Chúng tôi hiểu rằng khách hàng phụ thuộc rất nhiều vào Actions, và một sự cố gián đoạn kéo dài như thế này gây ảnh hưởng thực sự đến năng suất làm việc cũng như niềm tin của các bạn dành cho chúng tôi.

Chúng tôi vẫn đang tiếp tục thực hiện phân tích nguyên nhân gốc rễ (RCA) sâu hơn về sự cố này, vì có nhiều khía cạnh liên quan mà chúng tôi cần hiểu rõ trước khi tuyên bố kết thúc quá trình điều tra. Chúng tôi sẽ cập nhật bản tóm tắt công khai khi cuộc điều tra hoàn tất và sẽ bao gồm các chi tiết đầy đủ trong bài viết về tính khả dụng tháng 8, dự kiến xuất bản vào tháng 9.

Bên cạnh các hạng mục sửa chữa ngay lập tức được phát hiện qua quá trình điều tra, chúng tôi đang đẩy nhanh lộ trình kiến trúc cho GitHub Actions, phù hợp với những nỗ lực không ngừng của chúng tôi về khả năng cô lập, phục hồi và mở rộng quy mô.

Cần lưu ý rằng dịch vụ GitHub Actions – cốt lõi của sự cố nêu trên – vẫn đang chạy hoàn toàn trong các trung tâm dữ liệu của chúng tôi, đây là một yếu tố góp phần gây ra tình trạng thiếu hụt năng lực mà chúng tôi đã trải qua. Mặc dù phần lớn các actions chạy trên Azure, chúng tôi vẫn chưa ưu tiên di chuyển dịch vụ khởi chạy (launch service) – thành phần kết nối giữa kiến trúc nguyên khối (monolith) với actions – do tính chất bất đồng bộ chung và khả năng xếp hàng đợi công việc để phản hồi các vấn đề. Thật không may, như đã nêu trong bản tóm tắt công khai, các lỗi dây chuyền đã dẫn đến sự chậm trễ không thể chấp nhận được trong quá trình khôi phục. Đây là lý do tại sao chúng tôi đang đẩy nhanh việc chuyển GitHub Actions sang Azure, nơi chúng tôi sẽ có nhiều dư địa và khả năng hơn để hấp thụ các đợt tăng tải đột biến.

Về những nỗ lực rộng hơn, tháng trước, chúng tôi đã chia sẻ cách thức tạm dừng có chủ đích và các biện pháp kiểm soát ổn định chặt chẽ hơn đã thay đổi cách chúng tôi chuyển lưu lượng sản xuất vào Azure. Trong tháng 7, những biện pháp kiểm soát đó đã cho phép chúng tôi tiếp tục công việc với sự tự tin cao hơn, đồng thời tiếp tục giảm bớt các phụ thuộc dùng chung trên toàn bộ GitHub.

Tóm tắt ngắn gọn về tháng 7: GitHub đang dần giảm bớt sự phụ thuộc vào cơ sở hạ tầng dùng chung và các vị trí trung tâm dữ liệu riêng lẻ, giúp chúng tôi có nhiều năng lực hơn để hấp thụ sự tăng trưởng và giúp việc cô lập lỗi trở nên dễ dàng hơn. Trong tháng này, hơn một nửa lưu lượng đọc của kiến trúc nguyên khối đã chạy trên Azure Central US, dữ liệu xác thực bắt đầu được chuyển ra khỏi cơ sở dữ liệu dùng chung cũ nhất của chúng tôi, và các dịch vụ chuyên biệt đã loại bỏ đáng kể tải trọng khỏi đường dẫn dùng chung đó.

GitHub hiện có thể phục vụ phần lớn các yêu cầu của khách hàng từ năng lực Azure độc lập, giảm sự phụ thuộc vào bất kỳ trung tâm dữ liệu đơn lẻ nào trong khi vẫn duy trì hiệu suất. Lưu lượng đọc từ kiến trúc nguyên khối được phục vụ từ Azure Central US đạt đỉnh 52,75% vào ngày 28 tháng 7 – lần đầu tiên chúng tôi duy trì ổn định trên mức 50%. Lưu lượng Git trên Azure đạt 47%, tăng từ 43% trong tháng 6, và 29% tổng số kho lưu trữ (repositories) hiện đã có bản sao thứ hai tại Central US, giúp việc chuyển đổi dự phòng (failover) ít gây gián đoạn hơn khi một khu vực bị suy giảm hiệu năng. Quan trọng không kém, quy trình xác thực tính ổn định được giới thiệu sau sự cố tháng 5 hiện là một phần của mọi đợt mở rộng lưu lượng lớn, giúp chúng tôi tăng năng lực mà không làm tăng rủi ro cho khách hàng.

Chúng tôi cũng đã giảm các điểm lỗi dùng chung đằng sau các quy trình công việc quan trọng của khách hàng. Các bảng xác thực đầu tiên đã được chuyển từ cơ sở dữ liệu dùng chung cũ nhất sang cơ sở hạ tầng chuyên biệt, chứng minh mô hình di chuyển cho các công việc còn lại. Các kiểm tra xác thực và phân quyền hiện gây áp lực ít hơn đáng kể lên đường dẫn dùng chung đó: vào lúc cao điểm, dịch vụ người dùng chuyên biệt đã giảm tải hơn một triệu truy vấn mỗi giây, trong khi 80% các tra cứu phân quyền chính đã chuyển sang đường dẫn dịch vụ cô lập. Lưu lượng nội dung kho lưu trữ hiện chạy hoàn toàn từ Central US trên cơ sở hạ tầng chuyên biệt, và dịch vụ pull request chuyên biệt – vốn đã phục vụ lưu lượng ẩn danh – đã đạt mức tương đương 99,87% với kiến trúc nguyên khối cho các yêu cầu đọc đã xác thực khi chúng tôi dần dần chuyển toàn bộ lưu lượng sang đó. Tổng hợp lại, những thay đổi này làm giảm khả năng áp lực hoặc lỗi ở một phần của GitHub gây ảnh hưởng đến các hoạt động không liên quan của khách hàng.

GitHub hiện có thể hấp thụ sự tăng trưởng khối lượng công việc lớn hơn trước khi cơ sở hạ tầng dùng chung trở thành nguồn gốc gây suy giảm hiệu năng ảnh hưởng đến khách hàng. Một thay đổi trong sản xuất đã cắt giảm một nửa tổng thời gian truy vấn trên bảng artifacts, trong khi việc lưu vào bộ nhớ đệm (caching) trong đường dẫn xác thực Git đã giảm tải cho dịch vụ xác thực xuống 18,2%, ngay cả khi khối lượng yêu cầu tăng lên. Tìm kiếm (Search) cũng ít bị ảnh hưởng hơn bởi các hạn chế về năng lực vốn đã góp phần gây ra các sự cố trước đó: tất cả khối lượng công việc tìm kiếm trong sản xuất hiện được phục vụ từ Central US với dư địa bổ sung trong thời điểm nhu cầu tăng cao hoặc cơ sở hạ tầng gặp áp lực.

Chúng tôi cũng đang thay đổi cách đo lường và vận hành độ tin cậy. Ngoài sức khỏe cơ sở hạ tầng, chúng tôi ngày càng đo lường sức khỏe của các quy trình công việc quan trọng của khách hàng như pull requests để các nhóm có thể xác định sự suy giảm sớm hơn. Chúng tôi đang tiếp tục thay thế các hoạt động sản xuất thủ công rủi ro cao bằng tự động hóa, kiểm soát đánh giá và các biện pháp bảo vệ vận hành, để trải nghiệm của khách hàng ít phụ thuộc vào sự thực thi hoàn hảo của con người hơn.

Vượt qua mốc 50% là điểm giữa, không phải là đích đến. Giai đoạn tiếp theo là xây dựng đủ năng lực Azure độc lập để phục vụ toàn bộ lưu lượng sản xuất và cuối cùng là chịu đựng được việc mất một khu vực mà không xảy ra lỗi. Quý này, chúng tôi đặt mục tiêu đạt 70% lưu lượng đọc và 30% lưu lượng ghi tại Central US, đồng thời đưa mọi dịch vụ sản xuất trực tuyến tại đó. Việc di chuyển các cơ sở dữ liệu chính (database primaries) sẽ mở khóa lưu lượng ghi; một khu vực Azure thứ hai sẽ cung cấp nền tảng cho khả năng phục hồi khu vực. Chúng tôi hiện đã có tầm nhìn để đưa lưu lượng sản xuất dotcom ra khỏi các trung tâm dữ liệu của mình vào cuối năm 2026.

Tám bản tường trình sự cố tiếp theo là nửa còn lại của bức tranh này – những gì hệ thống đã làm tốt, những gì chưa làm được và những gì chúng tôi đã thay đổi sau đó. Nguyên tắc vẫn tiếp tục dẫn dắt chúng tôi: tính khả dụng, sau đó là năng lực, và cuối cùng là các tính năng.

Ngày 8 tháng 7 năm 2026 (kéo dài 7 giờ 4 phút)

Vào ngày 8 tháng 7 năm 2026, từ 15:07 đến 22:13 UTC, nhiều dịch vụ của GitHub – bao gồm Web UI, REST API, GraphQL API, Actions, Packages, Copilot và các thao tác Git – đã không khả dụng trên các môi trường Enterprise Cloud lưu trữ dữ liệu và trả về lỗi 5xx. Người dùng bị ảnh hưởng gặp lỗi khi tải trang và đăng nhập, các yêu cầu API thất bại, các workflow chạy trên Actions bị xếp hàng hoặc bị từ chối, và các điểm cuối (endpoints) của registry gói không khả dụng. Trong giờ cao điểm, khoảng 84% khách hàng (tenants) đang hoạt động trên các môi trường sản xuất bị ảnh hưởng đã gặp lỗi ở phần lớn các yêu cầu của họ, và tỷ lệ lỗi 5xx cao điểm đạt khoảng 96% trong môi trường bị ảnh hưởng nặng nề nhất.

Hệ thống giám sát tự động của chúng tôi đã phát hiện lỗi 5xx tăng cao trong khoảng 19 phút kể từ khi sự cố bắt đầu.

Một quy trình siêu dữ liệu cơ sở hạ tầng tự động đã thay đổi giá trị cấu hình thời gian chạy trên các máy ảo trong các môi trường bị ảnh hưởng này. Một biện pháp bảo vệ thường ngăn chặn giá trị này thay đổi trên các máy đang chạy đã không được áp dụng cho bản cập nhật này. Giá trị không chính xác đã làm gián đoạn quá trình khám phá dịch vụ (service discovery) và khiến các bộ định tuyến lưu lượng không có các backend khả dụng. Chúng tôi đã giảm thiểu sự cố bằng cách khôi phục các giá trị cấu hình chính xác trong từng môi trường bị ảnh hưởng và cho phép các dịch vụ đăng ký lại. Quá trình khôi phục mất vài giờ vì các giá trị phải được sửa chữa và xác thực trên nhiều máy. Một thành phần cơ sở hạ tầng riêng biệt đã cạn kiệt bộ nhớ khả dụng trong quá trình khôi phục và cần thêm các biện pháp giảm thiểu, kéo dài thời gian khôi phục. Chúng tôi đang thực thi tính bất biến của siêu dữ liệu, loại bỏ hành vi ghi đè không an toàn và cải thiện việc triển khai theo giai đoạn. Ngoài ra, chúng tôi đang đầu tư cải thiện giám sát cho các nhóm backend của bộ định tuyến lưu lượng bị trống; và phát triển các công cụ khôi phục an toàn hơn trên toàn bộ hệ thống. Những thay đổi này nhằm ngăn chặn sự tái diễn và giảm thời gian phát hiện cũng như giảm thiểu cho các vấn đề tương tự trong tương lai.

Ngày 9 tháng 7 năm 2026 (kéo dài 9 giờ 18 phút)

Vào ngày 9 tháng 7 năm 2026, từ 03:29 đến 13:39 UTC, GitHub Actions đã gặp tình trạng chậm trễ và thất bại khi bắt đầu công việc trên các runner do GitHub lưu trữ. Một số bản dựng Pages, công việc của Copilot Cloud Agent và Copilot Code Review cũng bị chậm trễ hoặc thất bại vì chúng phụ thuộc vào GitHub Actions để thực thi công việc. Sự cố gây ra bởi trạng thái không ổn định trong một dịch vụ dữ liệu backend chịu trách nhiệm cung cấp các runner được lưu trữ, ngăn cản việc lấy runner cho một tập hợp các khối lượng công việc. Shard phục vụ khối lượng công việc runner lớn nhất đã bị quá tải và không thể đồng bộ hóa đáng tin cậy giữa các khu vực, ngăn cản việc lấy runner cho các khối lượng công việc bị ảnh hưởng. Trong phần lớn thời gian xảy ra sự cố, khoảng 8% các workflow chạy trên các runner được lưu trữ bị chậm trễ hơn 5 phút, trong khi khoảng 2% không thể bắt đầu.

Chúng tôi đã khôi phục trạng thái ổn định của hệ thống sao chép dữ liệu backend, cho phép việc cung cấp runner phục hồi và lượng công việc tồn đọng được xử lý. Hiệu suất dịch vụ sau đó đã trở lại mức mong đợi. Sự gia tăng đột biến trong quá trình khôi phục đã gây thêm áp lực lên Actions và các dịch vụ phụ thuộc, nhưng lượng công việc tồn đọng đã được giải quyết và hiệu suất dịch vụ trở lại mức bình thường vào lúc 13:39 UTC.

GitHub đã hoàn thành một số cải tiến về giám sát, hướng dẫn vận hành và quản lý khối lượng công việc sau sự cố này. Công việc bổ sung đang được tiến hành để phân phối nhu cầu tốt hơn, bảo vệ các dịch vụ trong quá trình khôi phục và giảm độ trễ khi lưu lượng tăng đột ngột. Các thay đổi dài hạn sẽ cải thiện hơn nữa khả năng phục hồi dữ liệu và năng lực dịch vụ. Những nỗ lực này nhằm giảm khả năng xảy ra và tác động của các sự cố tương tự.

Ngày 16 tháng 7 năm 2026 (kéo dài 3 giờ 7 phút)

Vào ngày 16 tháng 7 năm 2026, từ 08:50 đến 09:50 UTC, công cụ web_search của GitHub MCP Server đã gặp lỗi tăng cao. Tỷ lệ lỗi trung bình là 42% và đạt đỉnh 82% số yêu cầu gửi đến công cụ. Các công cụ khác của GitHub MCP Server không bị ảnh hưởng. Nguyên nhân là do sự suy giảm hiệu năng tại một nhà cung cấp tìm kiếm web thượng nguồn.

Sự cố đã được giảm thiểu khi nhà cung cấp thượng nguồn phục hồi, sau đó chúng tôi xác nhận rằng tỷ lệ thành công của công cụ đã trở lại bình thường.

GitHub đã cải thiện việc xử lý yêu cầu, giám sát và hướng dẫn phản hồi cho công cụ tìm kiếm web: mỗi tìm kiếm hiện chạy trong một ngân sách thời gian tổng thể, vì vậy một nhà cung cấp bị lỗi không thể để một yêu cầu chạy vô thời hạn; giám sát hiện theo dõi cụ thể độ tin cậy của công cụ; và các runbook nội bộ mới giúp người phản hồi chẩn đoán các lỗi từ phía nhà cung cấp và đánh giá khi nào một công cụ bị suy giảm hiệu năng cần được coi là một sự cố công khai.

Các biện pháp bảo vệ bổ sung đang được triển khai, bao gồm một bộ ngắt mạch (circuit breaker) sẽ báo cáo tìm kiếm là không khả dụng khi lỗi kéo dài, thay vì để mỗi yêu cầu tự thất bại. Những thay đổi này giúp việc chẩn đoán sự cố của nhà cung cấp nhanh hơn và rõ ràng hơn đối với khách hàng, nhưng chúng không thể trả về kết quả tìm kiếm khi nhà cung cấp không khả dụng.

Điều đó đòi hỏi một nguồn kết quả thứ hai, độc lập, vì công cụ này không có phương án dự phòng. Do đó, chúng tôi đang đánh giá các tùy chọn sao lưu để giúp duy trì dịch vụ trong các lần gián đoạn nhà cung cấp trong tương lai.

Ngày 19 tháng 7 năm 2026 (kéo dài 2 giờ 11 phút)

Vào ngày 19 tháng 7 năm 2026, từ 18:00 đến 20:11 UTC, một cấu hình lại DNS trên diện rộng đã gây ra sự suy giảm dịch vụ đáng kể trên github.com và tất cả các môi trường lưu trữ dữ liệu. Khách hàng gặp phải tình trạng lỗi yêu cầu tăng cao trên các dịch vụ bao gồm GitHub Actions, webhooks và Copilot. Tác động lớn hơn ở các môi trường lưu trữ dữ liệu của chúng tôi, nơi cơ chế khám phá dịch vụ nội bộ bị ảnh hưởng được dựa vào nhiều hơn. Tỷ lệ lỗi 5xx khu vực cao điểm là 9,9%, và việc gửi webhook trong một môi trường bị ảnh hưởng đã bị gián đoạn trong khoảng 40 phút.

Vào lúc 17:50 UTC, một vấn đề kết nối cơ sở dữ liệu đã ảnh hưởng đến mặt phẳng điều khiển DNS nội bộ của chúng tôi. Dữ liệu không đầy đủ thu được đã bị diễn giải sai bởi quá trình cấu hình lại tự động các máy chủ DNS trên toàn bộ hệ thống và làm gián đoạn quá trình khám phá dịch vụ nội bộ. Khi các bản ghi DNS được lưu trong bộ nhớ đệm hết hạn, một số dịch vụ không thể phân giải các địa chỉ nội bộ, gây ra lỗi yêu cầu.

Hệ thống giám sát tự động đã phát hiện tác động đến khách hàng trong khoảng một phút. Quá trình khôi phục bắt đầu vào khoảng 18:54 UTC khi kết nối cơ sở dữ liệu trở lại. Tác động đến khách hàng kết thúc vào lúc 19:26 UTC khi việc chuyển tiếp DNS và bộ nhớ đệm được nạp lại, và sự cố được giải quyết hoàn toàn vào lúc 20:11 UTC.

Sau sự cố, chúng tôi đã triển khai các biện pháp bảo vệ giúp bảo lưu cấu hình DNS tốt cuối cùng được biết đến, từ chối dữ liệu không đầy đủ và ngăn chặn các thay đổi lớn gây hại. Chúng tôi cũng đã giảm thời gian lưu trữ các phản hồi DNS tiêu cực và cải thiện giám sát đối với tính khả dụng của cơ sở dữ liệu mặt phẳng điều khiển DNS.

Ngoài ra, chúng tôi đang tiếp tục kiểm tra tất cả các đường dẫn cấu hình lại DNS tự động và thêm phương án dự phòng cơ sở dữ liệu chỉ đọc khi cơ sở dữ liệu chính không khả dụng để đảm bảo dữ liệu không đầy đủ không thể gây ra các thay đổi mang tính phá hủy. Những cải tiến này nhằm ngăn chặn sự tái diễn và giảm thời gian phát hiện cũng như giảm thiểu cho các vấn đề tương tự.

Ngày 19 tháng 7 năm 2026 (kéo dài 5 giờ 10 phút)

Từ 23:05 UTC ngày 19 tháng 7 năm 2026 đến 03:55 UTC ngày 20 tháng 7 năm 2026, GitHub Actions đã gặp tình trạng chậm trễ và thất bại khi bắt đầu công việc đối với các runner tự lưu trữ (self-hosted) và runner lớn hơn. Các công việc sử dụng runner tiêu chuẩn do GitHub lưu trữ và runner macOS không bị ảnh hưởng bởi sự cố này. Nhìn chung, 9% các workflow chạy trên Actions bị chậm trễ khi bắt đầu, với tác động đạt đỉnh 21,4%. Trong số các loại runner bị ảnh hưởng, 78,99% các công việc trên runner lớn hơn, 29,8% các công việc trên scale-set và 8,7% các công việc trên runner tự lưu trữ mất hơn năm phút để lấy được runner. Lưu lượng kết nối lại từ các runner bị ảnh hưởng cũng làm tăng tải lên các API của GitHub, dẫn đến độ trễ yêu cầu trung bình tăng thêm từ ba đến bốn giây và tỷ lệ lỗi 5xx tăng cao.

Sự cố gây ra bởi lỗi quản lý vòng đời chứng chỉ trong một tập hợp các dịch vụ nội bộ, dẫn đến việc chứng chỉ SSL hết hạn làm gián đoạn kết nối runner. Chứng chỉ cụ thể này được sử dụng để thực thi phiên bản runner tối thiểu. Nó dựa vào việc triển khai thủ công và mặc dù bản thay thế đã được tạo, nó không được triển khai tự động khi nhận được cảnh báo tự động. Chúng tôi đã khôi phục dịch vụ bằng cách xoay vòng chứng chỉ bị ảnh hưởng. Quá trình khôi phục bắt đầu lúc 02:45 UTC. Đến 03:55 UTC, lượng công việc workflow tồn đọng đã được xử lý và tỷ lệ chậm trễ workflow trở lại bình thường.

GitHub đã tăng cường các biện pháp bảo vệ để hạn chế tác động rộng hơn của các vấn đề kết nối runner. Chúng tôi đang thêm tính năng giám sát hết hạn chứng chỉ độc lập và cải thiện tự động hóa gia hạn để ngăn chặn các gián đoạn tương tự. Chúng tôi cũng đang cập nhật các quy trình cảnh báo, truy cập và phản hồi để các vấn đề về chứng chỉ có thể được xác định và giải quyết sớm hơn.

Ngày 21 tháng 7 năm 2026 (kéo dài 1 giờ 26 phút)

Vào ngày 21 tháng 7 năm 2026, từ 07:41 đến 11:57 UTC, dịch vụ xác thực SSH trên github.com bị suy giảm hiệu năng, và một số kết nối SSH sử dụng khóa RSA người dùng và khóa triển khai (deploy keys) đã bị từ chối. Trung bình, 12,2% các yêu cầu xác thực SSH thất bại, đạt đỉnh 15,7%. Cả khóa RSA người dùng và khóa triển khai đều bị ảnh hưởng.

Điều này là do một lỗi hồi quy (regression) được đưa vào trong một thay đổi cơ sở hạ tầng nội bộ không liên quan. Lỗi hồi quy ảnh hưởng đến một luồng xác thực khóa công khai ít phổ biến hơn: phương thức khóa công khai được ký trực tiếp thường được sử dụng bởi các khóa triển khai và tự động hóa. Các nỗ lực xác thực hợp lệ sử dụng phương thức này đã bị từ chối là không hợp lệ.