Báo cáo khả dụng GitHub tháng 9/2026: Hai sự cố và nỗ lực nâng cấp hạ tầng

Trong tháng 9/2026, GitHub ghi nhận hai sự cố khiến hiệu suất dịch vụ suy giảm. Báo cáo mới nhất của nền tảng này cũng cho thấy tiến độ di chuyển khối lượng công việc sản xuất sang Azure, giảm áp lực lên cơ sở dữ liệu dùng chung và tăng dư địa vận hành cho GitHub Actions.

Jakub Oleksy, đại diện GitHub, cho biết báo cáo lần này bao quát tiến độ của cả hai tháng 8 và 9 vì nội dung về sự cố ngày 17/8 đã được công bố riêng trước đó. Tóm tắt ngắn gọn: GitHub đã giảm áp lực lên cơ sở dữ liệu dùng chung, bổ sung cơ chế kiểm soát quá tải, tạo dư địa cho GitHub Actions, mở rộng khả năng cô lập lỗi cho pull request và chuyển thêm nhiều khối lượng công việc sản xuất sang Azure.

Tiến độ di chuyển hạ tầng sang Azure

Tính đến ngày 7/10, đã có 120 trong tổng số 160 dịch vụ sản xuất được triển khai tại khu vực Central US, và 13 trong số 51 cơ sở dữ liệu MySQL chính đã được di chuyển. Azure cũng đảm nhận 65,4% lưu lượng đọc cho ứng dụng lõi của GitHub, 48,3% lưu lượng đọc Git và 80,2% lưu lượng xử lý luồng. Các tỷ lệ này đo lường những khối lượng công việc khác nhau nên không thể cộng gộp.

Biểu đồ sự cố hạ tầng GitHub

GitHub đã tạm dừng triển khai tại Central US và việc tăng lưu lượng vào ngày 11/9 do năng lực không đồng đều giữa các vùng khả dụng. Việc tăng tốc trở lại được nối tiếp từ ngày 18/9 sau khi có giải pháp tạm thời, nhưng công việc xây dựng năng lực bền vững vẫn đang tiếp diễn với mục tiêu giải phóng toàn bộ năng lực khả dụng trước cuối tháng 10. GitHub cũng thừa nhận đã bỏ lỡ mục tiêu đầy tham vọng ngày 30/9 là triển khai toàn bộ dịch vụ sản xuất tại khu vực này.

Trong một lần chuyển đổi cơ sở dữ liệu theo kế hoạch, một quy trình khẩn cấp tự động đã ngắt kết nối các bản sao cơ sở dữ liệu tại Central US và gây gián đoạn cho khách hàng trong khu vực. GitHub đã vô hiệu hóa quy trình này trong các lần bàn giao theo kế hoạch, đồng thời cải thiện khả năng phục hồi.

Giảm áp lực cơ sở dữ liệu dùng chung

Ngoài quá trình di chuyển khu vực, 24 bảng lõi xác thực đã được chuyển khỏi cơ sở dữ liệu dùng chung lâu đời nhất của GitHub, loại bỏ khoảng một triệu truy vấn mỗi giây khỏi các bản sao của nó. Cụm cơ sở dữ liệu hỗ trợ issues và pull request đã xóa khoảng 980 triệu dòng lịch sử chỉnh sửa không cần thiết, giải phóng ước tính 1,8 terabyte dung lượng lưu trữ có thể thu hồi.

Số vụ deadlock hàng tuần đã giảm khoảng 77% so với mức đỉnh hồi tháng 6, và quy trình dọn dẹp liên tục hiện ngăn chặn tình trạng tăng trưởng không giới hạn tái diễn. Một nửa lưu lượng pull request được lấy mẫu giờ có thể tiếp tục hoạt động với chức năng hạn chế khi một phụ thuộc dùng chung gặp lỗi. Kết quả thực tế cho thấy một số thao tác đọc vẫn khả dụng trong sự cố cơ sở dữ liệu dùng chung.

Định tuyến lưu lượng cơ sở dữ liệu cũng có thể tự động tăng năng lực khi có đợt tăng đột biến. Một nhóm đã mở rộng từ 14 lên 19 phiên bản trong đợt gia tăng hoạt động pull request ngày 23/9. Cơ chế kiểm soát quá tải trong môi trường sản xuất cho phép đội ngũ ứng phó bảo vệ các luồng API và web ưu tiên cao bằng cách từ chối các yêu cầu ưu tiên thấp trước khi xảy ra bão hòa diện rộng. Tài liệu và đào tạo cho vận hành viên đã hoàn tất.

GitHub Actions cũng có thêm dư địa vận hành. Các thay đổi trong sản xuất giúp giảm khoảng 28% thao tác Redis đo được và khoảng 30% CPU tương đối. Một bộ nhớ đệm hạ tầng riêng biệt giảm 84% băng thông Redis, 66% thời gian phản hồi trung bình, 96% thời gian phản hồi trung vị cho yêu cầu kiểm kê chính và 95% số yêu cầu trong hàng đợi.

Sự cố ngày 13/9: Quá tải kết nối cơ sở dữ liệu

Sự cố kéo dài 1 giờ 28 phút, bắt đầu lúc 09:16 UTC ngày 13/9.

Một tác vụ dọn dẹp dữ liệu chạy nền đã làm tăng tải lên cơ sở dữ liệu dùng chung. Tác vụ này có cơ chế bảo vệ được thiết kế để làm chậm ghi khi các bản sao cơ sở dữ liệu bị tụt lại, nhưng cơ chế này không tính đến tải đến trên máy chủ cơ sở dữ liệu chính. Kết quả là tác vụ tiếp tục chạy cho đến khi máy chủ chính đạt giới hạn kết nối, khiến các yêu cầu phụ thuộc vào nó không thể hoàn thành đáng tin cậy.

Hai yếu tố khác làm tăng mức độ ảnh hưởng và trì hoãn phục hồi. Thứ nhất, không có timeout nhanh cho các lệnh gọi cơ sở dữ liệu này, khiến các trình xử lý yêu cầu chờ đợi cơ sở dữ liệu bị đình trệ thay vì thất bại nhanh. Thứ hai, một vòng lặp thử lại quanh việc tạo token liên tục gửi lại các thao tác ghi vốn đã thất bại, giữ cơ sở dữ liệu trong trạng thái bão hòa thay vì để nó phục hồi.

Biểu đồ sự cố ngày 28/9

Để ứng phó, GitHub đã giảm tải nội bộ, tạm dừng tác vụ nền, và cơ sở dữ liệu phục hồi với tỷ lệ lỗi trên các dịch vụ bị ảnh hưởng trở lại bình thường. Các biện pháp khắc phục lâu dài bao gồm bổ sung cơ chế bảo vệ để kiểm soát xử lý nền dựa trên năng lực cơ sở dữ liệu khả dụng, giảm số lần thử lại không cần thiết khi thất bại, và hạn chế tác động của các yêu cầu cơ sở dữ liệu chậm.

Sự cố ngày 28/9: Lỗi dịch vụ review code của Copilot

Sự cố kéo dài 52 phút, bắt đầu lúc 21:16 UTC ngày 28/9.

Dịch vụ review code của Copilot sử dụng một dịch vụ riêng để chạy đánh giá, trả về hai phiên bản kết quả: một bản giới hạn không có nhận xét review và một bản đầy đủ có nhận xét hoàn chỉnh. Copilot code review chỉ đăng review từ bản đầy đủ. Một thay đổi đối với dịch vụ đó bắt đầu chỉ gửi bản đầy đủ cho một số khách hàng, trong khi những khách hàng khác chỉ nhận được bản giới hạn.

Kết quả là Copilot code review không thể tạo review nhưng vẫn báo cáo tác vụ đã hoàn thành thành công. Kết quả review bị thiếu không được phát hiện do thiếu giám sát. Sự cố chỉ được nhận ra khi một số review vẫn chưa hoàn tất quá 30 phút, kích hoạt cảnh báo cho đội ứng phó đầu tiên. GitHub đã khắc phục bằng cách hoàn tác thay đổi.

GitHub Availability Report

Để giảm khả năng tái diễn, GitHub đang tăng cường độ tin cậy của Copilot code review bằng cách bổ sung cơ chế bảo vệ trong suốt quy trình review và phân phối, đảm bảo các review hoàn thành được gửi thành công, cho phép review thất bại tự phục hồi và thông báo sớm hơn khi có vấn đề. Quy trình giám sát và triển khai cũng được cải thiện để phát hiện và xử lý vấn đề nhanh hơn.

Bài học từ bốn tháng biến động

Các sự cố ngày 6/8 của GitHub Actions, ngày 17/8 của github.com, sự cố chuyển đổi tháng 9 và việc tạm dừng năng lực có kiểm soát là lời nhắc rằng những cải thiện đo lường được chỉ có ý nghĩa khi chúng giảm thiểu rủi ro cho khách hàng trong điều kiện thực tế. Nguyên tắc của GitHub vẫn không thay đổi: khả dụng trước, năng lực sau, tính năng sau cùng.

"Những cải thiện đo lường được chỉ có ý nghĩa khi chúng giảm thiểu rủi ro cho khách hàng trong điều kiện thực tế."

Với các nhà phát triển Việt Nam và nhiều doanh nghiệp đang phụ thuộc vào GitHub cho quy trình CI/CD, thông tin này đáng lưu ý để lên kế hoạch dự phòng. Việc GitHub tiếp tục di chuyển sang Azure và cải thiện khả năng chịu lỗi có thể giúp các tổ chức giảm thiểu gián đoạn trong tương lai, nhưng người dùng vẫn nên theo dõi trang trạng thái của GitHub để cập nhật theo thời gian thực.