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

Tháng trước, chúng tôi đã thêm một phần mới vào các báo cáo hàng tháng của mình với những cập nhật về công việc đảm bảo tính khả dụng của GitHub và các khoản đầu tư cơ sở hạ tầng đằng sau đó. Phản hồi và những câu hỏi mà chúng tôi nhận được đã làm rõ một điều: khách hàng muốn biết nhiều hơn về vấn đề này, chứ không phải ít đi—ngay cả khi đó là những tin tức trái chiều.

Tóm tắt ngắn gọn về tháng 6: Chúng tôi đã đạt được tiến bộ thực sự về mặt cấu trúc, chúng tôi đã chủ động tạm dừng khi một quá trình tăng tải gặp trục trặc và chúng tôi đã bỏ lỡ một mục tiêu mà hiện tại chúng tôi đã thiết lập lại cơ sở.

Lưu lượng truy cập Monolith trong Azure đạt đỉnh 45% tại khu vực Central US trong tháng này. Con số đó thấp hơn kỳ vọng của chúng tôi vì chúng tôi đã tạm dừng việc tăng tải trong khoảng một tháng sau sự cố ổn định vào ngày 21 tháng 5, khi nhận thấy môi trường chưa sẵn sàng để tiếp nhận thêm lưu lượng. Chúng tôi đã khởi động lại quá trình tăng tải vào ngày 17 tháng 6 với một cổng kiểm soát ổn định (stability gate) mới cho mỗi lượt tăng, yêu cầu môi trường phải được xác minh là ổn định trước mỗi bước nâng cấp. Đi chậm hơn với sự tự tin cao hơn là một sự đánh đổi đúng đắn—một sự tạm dừng có kiểm soát vẫn tốt hơn là phải rút ra cùng một bài học ở mức tải cao hơn.

Git trong Azure đã tăng từ 30% lên mức đỉnh 43% (kết hợp cả HTTP và SSH) trong tháng, và chúng tôi đã bỏ lỡ mục tiêu 50% của tháng 6. Chúng tôi dự đoán Git sẽ đi ngang ở mức gần 45% trong thời điểm hiện tại do hai quyết định có chủ đích nhằm tránh làm tăng độ trễ cho người dùng: chúng tôi đang chờ thêm lưu lượng vPoP để định tuyến đến Central US thay vì backhaul lưu lượng Git từ IAD HUB, và chúng tôi chỉ đang định tuyến HTTP vì SSH hiện không có cơ chế tách biệt đọc/ghi tại biên (edge). Chúng tôi vẫn tiếp tục ưu tiên vấn đề này nhưng chưa có mục tiêu mới để chia sẻ. Chúng tôi sẽ tiếp tục làm việc nhanh chóng và an toàn nhất có thể, đồng thời sẽ báo cáo các con số cụ thể trong bản cập nhật tiếp theo.

Bên dưới những con số tiêu đề đó, chúng tôi đã đạt được những tiến bộ mà chúng tôi đặc biệt hào hứng. Dịch vụ pull request được tách rời mới của chúng tôi, pullsd, hiện đang xử lý 100% các yêu cầu đọc pull request ẩn danh trong môi trường production; lưu lượng này không còn được phục vụ bởi monolith nữa. Reposd, dịch vụ repository được tách rời mới của chúng tôi, đã trở thành dịch vụ tách rời đầu tiên phục vụ lưu lượng REST production từ Azure, tăng lên 50% lưu lượng đọc trước khi chúng tôi chủ động giảm tải do hạn chế về dung lượng Redis. Không có sự cố nào xảy ra và không có việc rollback nào trong tình trạng khẩn cấp. Nó sẽ tăng tải trở lại khi công việc mở rộng dung lượng hoàn tất. Dịch vụ người dùng mới của chúng tôi hiện đang giảm tải khoảng 500.000 truy vấn mỗi giây vào giờ cao điểm từ cơ sở dữ liệu chính, với việc di chuyển vật lý các bảng xác thực và phân quyền sẽ hoàn tất vào đầu tháng 7. Việc giới hạn tốc độ API (API rate limiting) hiện được xử lý khoảng 97% tại Gateway, vì vậy các quyết định giới hạn tốc độ không còn cạnh tranh với các worker phục vụ yêu cầu bên trong monolith. Cơ chế loại bỏ tải (load shedding) cơ sở dữ liệu phía client đang chạy trên 5% lưu lượng production thực tế, điều này có nghĩa là chúng tôi hiện có bằng chứng thực tế rằng chúng tôi có thể loại bỏ các truy vấn ưu tiên thấp khi bị quá tải trước khi chúng gây ra lỗi cho người dùng. Ngoài ra, quy trình xác nhận bởi hai người hiện là bắt buộc đối với quyền truy cập production tương tác và các thay đổi ChatOps, với một dấu vết kiểm toán (audit trail) thống nhất đi kèm.

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

Trong tháng 6, chúng tôi đã gặp phải sáu sự cố dẫn đến suy giảm hiệu suất trên các dịch vụ của GitHub.

Ngày 04 tháng 6, 17:30 UTC (kéo dài 1 giờ 25 phút)

Vào ngày 4 tháng 6 năm 2026, từ 17:30 đến 18:55 UTC, tính năng đánh giá mã nguồn của Copilot gặp lỗi gia tăng đối với các yêu cầu đánh giá trên github.com. Người dùng bị ảnh hưởng thấy thông báo “Copilot ran into an error” trên các pull request khi yêu cầu đánh giá mã nguồn.

Trong thời gian xảy ra sự cố, trung bình 81,6% yêu cầu đánh giá mã nguồn của Copilot bị lỗi, với tỷ lệ lỗi cao nhất là 93,9% và tổng cộng khoảng 36.800 yêu cầu đánh giá mã nguồn bị lỗi. GitHub Enterprise Cloud với tính năng lưu trữ dữ liệu (data residency) không bị ảnh hưởng.

Vấn đề gây ra bởi một dependency mới được phát hành mà quy trình xử lý đánh giá mã nguồn của Copilot sử dụng. Bản phát hành này gây ra sự không tương thích với môi trường runtime. Vì quy trình tự động sử dụng bản phát hành mới nhất, phiên bản không tương thích đã được áp dụng mà không có sự kiểm tra tính tương thích đầy đủ, dẫn đến việc xử lý đánh giá bị lỗi. Các tác vụ đánh giá bị ảnh hưởng không báo lỗi nhanh (fail fast); nhiều tác vụ tiếp tục chạy cho đến khi hết thời gian chờ (timeout).

Chúng tôi đã giảm thiểu sự cố bằng cách loại bỏ phiên bản dependency có vấn đề và triển khai lại dịch vụ xử lý bị ảnh hưởng. Các đánh giá mã nguồn mới bắt đầu phục hồi vào lúc 18:44 UTC và tỷ lệ lỗi trở lại mức cơ sở vào lúc 18:55 UTC. Các công việc bị timeout còn lại đã được xử lý xong vào lúc 19:59 UTC.

Để giảm thiểu rủi ro tái diễn, chúng tôi đang ghim (pin) phiên bản dependency thay vì tự động sử dụng bản phát hành mới nhất, thêm các kiểm tra tính tương thích cho các bản phát hành trong tương lai, cải thiện hành vi báo lỗi nhanh khi bộ xử lý đánh giá không thể khởi động, thêm các kiểm soát timeout ngắn hơn cho quy trình đánh giá và cải thiện việc giám sát các lỗi hoàn thành đánh giá.

Ngày 08 tháng 6, 06:30 UTC (kéo dài 2 giờ 06 phút)

Vào ngày 8 tháng 6 năm 2026, trong khoảng từ 06:30 đến 08:36 UTC, người dùng chưa đăng nhập đã gặp phải lỗi HTTP 504 gia tăng liên tục khi truy cập vào pull requests, issues, releases, patch diffs và các trang github.com liên quan khác. Trong sự cố, khoảng 17% yêu cầu không xác thực đến các endpoint github.com bị ảnh hưởng đã trả về lỗi gateway timeout, đạt đỉnh khoảng 34% yêu cầu vào khoảng 06:50 UTC. Một số quy trình GitHub Actions cũng bị ảnh hưởng khi chúng phụ thuộc vào việc tải xuống bản phát hành hoặc các endpoint github.com liên quan. Tác động kéo dài khoảng hai giờ và chỉ giới hạn ở lưu lượng không xác thực; người dùng đã đăng nhập không bị ảnh hưởng.

Vấn đề gây ra bởi sự gia tăng đáng kể lưu lượng ẩn danh tự động, mang tính lạm dụng vào các endpoint cụ thể của github.com. Vì các yêu cầu không xác thực được phục vụ bởi một nhóm máy chủ ứng dụng web chuyên dụng, điều này đã làm giảm khả năng phản hồi các yêu cầu không xác thực, khiến các yêu cầu bị xếp hàng vượt quá ngưỡng timeout và trả về lỗi gateway timeout.

Chúng tôi đã giảm thiểu sự cố bằng cách xác định mô hình lưu lượng bất thường và áp dụng các khối chặn mục tiêu tại lớp cân bằng tải và lớp ứng dụng. Khi các khối chặn có hiệu lực hoàn toàn, tỷ lệ lỗi trở lại bình thường và các dịch vụ bị ảnh hưởng đã được khôi phục hoàn toàn vào lúc 08:36 UTC.

Để giảm khả năng xảy ra và tác động của các sự cố tương tự trong tương lai, chúng tôi đang cải thiện khả năng phát hiện và chặn tự động đối với các mô hình lưu lượng này, cải thiện lộ trình triển khai chặn lưu lượng khẩn cấp và đánh giá các thay đổi định tuyến cho các endpoint được sử dụng bởi cả người dùng chưa đăng nhập và các quy trình tự động.

Ngày 10 tháng 6, 15:05 UTC (kéo dài 1 giờ 20 phút)

Vào ngày 10 tháng 6 năm 2026, từ 15:05 đến 16:25 UTC, các dịch vụ API của GitHub bị suy giảm tính khả dụng do lỗi xác thực không liên tục ảnh hưởng đến khoảng 9% yêu cầu. Cả yêu cầu API REST và GraphQL đều bị ảnh hưởng. Khách hàng gặp phải tình trạng "đăng xuất" ngắt quãng do các phản hồi 401 (không được phép) sai lệch khiến các tích hợp ứng dụng của bên thứ nhất và bên thứ ba kích hoạt các quy trình xác thực lặp đi lặp lại. Vì chỉ các yêu cầu được định tuyến qua cơ sở hạ tầng bị ảnh hưởng mới gặp lỗi, cùng một client có thể thành công ở một yêu cầu và thất bại ở yêu cầu tiếp theo, tạo ra hành vi ngắt quãng. Các yêu cầu bị ảnh hưởng cũng gặp thêm khoảng 800ms độ trễ do gateway thử lại xác thực trước khi trả về lỗi.

Một dịch vụ proxy memcached được triển khai vào cơ sở hạ tầng API nội bộ của chúng tôi đã khiến dịch vụ xác thực nhận cấu hình host không chính xác, dẫn đến lỗi tra cứu xác thực không liên tục. Chúng tôi đã giảm thiểu sự cố bằng cách triển khai thay đổi cấu hình cho dịch vụ memcached để sử dụng host chính xác.

Để ngăn chặn các vấn đề tương tự trong tương lai, chúng tôi có kế hoạch di chuyển hệ thống xác thực của mình sang cơ sở hạ tầng lưu trữ đệm (caching) mới để cải thiện khả năng phục hồi và củng cố tình trạng tin cậy tổng thể. Chúng tôi cũng đang cải thiện cách gateway phân biệt các lỗi hệ thống xác thực tạm thời với thông tin xác thực không hợp lệ thực sự, để các lỗi tra cứu tạm thời không còn xuất hiện với người dùng như là bị đăng xuất.

Ngày 16 tháng 6, 17:20 UTC (kéo dài 55 phút)

Vào ngày 16 tháng 6 năm 2026, từ 17:20 đến 18:15 UTC, mô hình Opus 4.8 gặp sự cố suy giảm tính khả dụng trong GitHub Copilot. Trong khoảng thời gian này, một số yêu cầu gửi đến Opus 4.8 bị lỗi. Các mô hình Copilot khác không bị ảnh hưởng và vẫn khả dụng như các lựa chọn thay thế. Sự cố này gây ra bởi một vấn đề từ nhà cung cấp mô hình thượng nguồn (upstream).

Trong khi sự cố đang diễn ra, chúng tôi đã bật thông báo chế độ suy giảm để thông báo cho người dùng bị ảnh hưởng. Nhà cung cấp thượng nguồn đã giải quyết vấn đề và chúng tôi đã theo dõi Opus 4.8 cho đến khi tỷ lệ thành công trở lại bình thường. Sự cố đã được giải quyết hoàn toàn.

Chúng tôi đang giảm sự phụ thuộc vào bất kỳ nhà cung cấp suy luận (inference provider) đơn lẻ nào cho một mô hình nhất định và cân bằng dung lượng giữa các nhà cung cấp, để lưu lượng có thể chuyển đổi dự phòng (fail over) sang dung lượng ổn định trong trường hợp nhà cung cấp thượng nguồn gặp sự cố. Ngoài ra, chúng tôi đã củng cố công cụ trang trạng thái công khai của mình để đảm bảo các cập nhật sự cố được xuất bản một cách đáng tin cậy, cải thiện cách chúng tôi giữ cho khách hàng được thông tin trong quá trình giảm thiểu sự cố.

Ngày 17 tháng 6, 03:50 UTC (kéo dài 54 phút)

Vào ngày 17 tháng 6 năm 2026, từ khoảng 03:50 đến 04:44 UTC, GitHub Copilot bị suy giảm hiệu suất và hầu hết các mô hình chat tiên tiến của nó tạm thời không khả dụng trên tất cả các khu vực. Trong khoảng thời gian này, các mô hình bị ảnh hưởng hoặc biến mất khỏi bộ chọn mô hình trên web, trình soạn thảo và CLI, hoặc trả về lỗi “model not available” khi được chọn. Khách hàng vẫn có thể tiếp tục sử dụng GitHub Copilot bằng cách chọn một trong các mô hình vẫn khả dụng. Sự cố xảy ra vào giờ thấp điểm, điều này đã hạn chế số lượng khách hàng bị ảnh hưởng.

Điều này là do một thay đổi cấu hình mà hệ thống production của chúng tôi cho là không hợp lệ. Chúng tôi đã giảm thiểu sự cố bằng cách hoàn tác thay đổi cấu hình, sau đó các mô hình bị ảnh hưởng đã tự động quay trở lại khi dịch vụ tải lại cấu hình trước đó.

Chúng tôi đang nỗ lực triển khai các thay đổi cấu hình dần dần với các bước xác thực mạnh mẽ hơn, cảnh báo về sự sụt giảm đột ngột số lượng mô hình khả dụng và tự động hoàn tác các thay đổi cấu hình kích hoạt các cảnh báo này.

Ngày 25 tháng 6, 17:33 UTC (kéo dài 23 phút)

Vào ngày 25 tháng 6 năm 2026, từ 17:33 đến 17:55 UTC, dịch vụ công việc nền (background job service) của chúng tôi bị suy giảm, làm tăng độ trễ cho các pull request, repository pushes, actions workflows và webhooks, với độ trễ đạt đỉnh 7 phút. Vấn đề gây ra bởi các sự cố hypervisor cơ bản và sự gia tăng đột biến lưu lượng truy cập, gây ra timeout dịch vụ dẫn đến bão kết nối và việc tái cân bằng liên tục.

Vấn đề đã được giảm thiểu bằng cách thay thế node bị ảnh hưởng vào lúc 17:49, sau đó tất cả các dịch vụ đã phục hồi vào lúc 18:07.

Để giảm khả năng xảy ra và tác động của các sự cố tương tự trong tương lai, chúng tôi đã làm cho việc xử lý công việc nền trở nên linh hoạt hơn trước các đợt tăng lưu lượng đột ngột, giảm khả năng xảy ra tình trạng kết nối bị gián đoạn trong các trường hợp suy giảm, loại bỏ việc đặt chung các node quan trọng để một node không ổn định không thể ảnh hưởng đến các node khác và thêm cảnh báo sớm hơn về các điều kiện dẫn đến sự suy giảm này.

Hãy theo dõi trang trạng thái của chúng tôi để cập nhật thời gian thực về các thay đổi trạng thái và tóm tắt sau sự cố. Để tìm hiểu thêm về những gì chúng tôi đang thực hiện, hãy xem phần kỹ thuật trên GitHub Blog.

Được viết bởi