Diễn biến: khắc phục từng phần, không phục hồi đồng thời

GitHub bắt đầu điều tra các báo cáo về hiệu năng suy giảm vào khoảng 13:40 UTC, tương đương 9:40 sáng theo giờ miền Đông nước Mỹ (EDT), ngày 17/8. Sự cố nhanh chóng lan sang nhiều dịch vụ mà các nhóm phát triển sử dụng để truy cập mã nguồn, xem xét thay đổi, chạy tự động hóa và đưa phần mềm vào vận hành.

Trong bản cập nhật đăng lúc 12:36 trưa EDT, GitHub cho biết đã xác định “thành phần có vấn đề”, thực hiện biện pháp khắc phục và ghi nhận các dấu hiệu phục hồi rõ rệt. Tuy nhiên, nền tảng khi đó vẫn chưa hoàn toàn ổn định.

Quá trình phục hồi diễn ra không đồng đều. Nhiều dịch vụ chính trở lại trạng thái hoạt động, nhưng Copilot vẫn gặp lỗi xác thực trong một số ứng dụng. Một số báo cáo sự cố ghi nhận toàn bộ gián đoạn kéo dài đến khoảng 21:15 UTC, lâu hơn đáng kể so với giai đoạn suy giảm nghiêm trọng ban đầu.

Mức độ ảnh hưởng ra sao?

Các chỉ số rõ ràng nhất đến từ số liệu lỗi do GitHub công bố:

• Website và lưu lượng API: tỷ lệ lỗi khoảng 20%.
• Tải tệp lưu trữ và nội dung thô của kho mã nguồn: tỷ lệ lỗi khoảng 50%.
• Công cụ phát triển: Pull Requests, Issues, Actions, Webhooks, các thao tác Git và Pages bị suy giảm hiệu năng hoặc không khả dụng ở những thời điểm khác nhau.
• Trợ lý lập trình AI: GitHub Copilot bị ảnh hưởng và vẫn là một vấn đề đang được xử lý sau khi một số dịch vụ cốt lõi đã phục hồi.
• Danh tính doanh nghiệp: SAML và OIDC, hai cơ chế đăng nhập một lần thường dùng trong doanh nghiệp, cùng SCIM provisioning và Team Sync được báo cáo là bị gián đoạn. Điều này có thể khiến tổ chức gặp khó khăn khi đăng nhập cho nhân viên hoặc quản lý quyền truy cập.

Các tỷ lệ trên là tỷ lệ yêu cầu bị lỗi, không phải tỷ lệ người dùng GitHub mất quyền truy cập. Chẳng hạn, tỷ lệ lỗi API 20% không có nghĩa chính xác 20% khách hàng bị ngắt kết nối; con số 50% chỉ áp dụng cho các yêu cầu tải xuống bị ảnh hưởng, không phải toàn bộ lưu lượng kho mã nguồn.

Vì sao thời điểm xảy ra khiến tác động nặng hơn?

Sự cố bắt đầu vào sáng thứ Hai tại Mỹ, trùng với thời điểm nhiều nhóm kỹ thuật bước vào ngày làm việc đầu tuần. Đây thường là lúc các đội bắt đầu xem xét mã, chạy kiểm thử và tích hợp liên tục (CI), triển khai phần mềm hoặc xử lý kế hoạch trong ngày.

Vì Actions, Pull Requests, API và Webhooks đều bị ảnh hưởng, các nhóm có thể gặp lỗi liên tiếp ở nhiều mắt xích của quy trình phát triển và phát hành, thay vì chỉ mất một tính năng riêng lẻ. Một quy trình tự động có thể cần API để lấy mã, Actions để chạy kiểm thử, Webhooks để kích hoạt bước tiếp theo và quyền doanh nghiệp để xác thực người dùng—tất cả đều có nguy cơ bị gián đoạn trong cùng một sự cố.

Số liệu từ các công cụ theo dõi sự cố cũng khác nhau tùy thời điểm và phương pháp. Một báo cáo cho biết Downdetector đã ghi nhận hơn 10.000 lượt báo lỗi vào lúc 8:12 sáng theo giờ Thái Bình Dương, trong khi một bản tin phục hồi khác nêu mức đỉnh gần 3.000 lượt. Đây không phải số người dùng bị ảnh hưởng chính xác: các nền tảng này đếm lượt người gửi báo cáo, và tổng số thay đổi theo khu vực, thời điểm cũng như cách thu thập dữ liệu.

GitHub đã làm gì, và điều gì vẫn chưa được giải thích?

Các cập nhật công khai của GitHub cho thấy ba bước chính trong phản ứng của công ty:

1. Kỹ sư điều tra tình trạng hiệu năng suy giảm trên nhiều dịch vụ.
2. Công ty xác định một thành phần liên quan đến sự cố và triển khai biện pháp khắc phục.
3. GitHub tiếp tục áp dụng các biện pháp giảm thiểu sau khi những dịch vụ chính bắt đầu phục hồi, trong đó có việc xử lý lỗi xác thực Copilot xảy ra không thường xuyên ở một số ứng dụng.

Nhưng bằng chứng hiện có chưa cho biết thành phần đó là gì, biện pháp khắc phục cụ thể ra sao, hoặc chứng minh áp lực tải là nguyên nhân trực tiếp của sự cố ngày 17/8. Lưu lượng do AI tạo ra và các giới hạn hạ tầng nằm trong bối cảnh thảo luận rộng hơn về độ tin cậy của GitHub, song không nên được xem là nguyên nhân gốc rễ đã được xác nhận trước khi có báo cáo sau sự cố.

Một sự cố mới trong giai đoạn khó khăn của GitHub

Sự cố tháng 8 xảy ra sau một giai đoạn độ tin cậy đáng lo ngại. Báo cáo khả dụng tháng 7 của GitHub ghi nhận tám sự cố trong tháng. Riêng sự cố ngày 8/7 kéo dài hơn bảy giờ, ảnh hưởng đến Web UI, REST API, GraphQL API, Actions, Packages, Copilot và các thao tác Git trong một số môi trường Enterprise Cloud.

GitHub cũng từng mô tả quy mô thách thức hạ tầng mà họ đang đối mặt. Trong thông tin về khả dụng, công ty cho biết lưu lượng tăng nhanh, phần lớn được thúc đẩy bởi các quy trình phát triển có AI hỗ trợ và các tác nhân AI tự động. Các hướng xử lý được nêu gồm chuyển thêm năng lực sang Azure, tách các dịch vụ và giảm những điểm lỗi dùng chung.

Quy mô mở rộng dự kiến cũng đáng chú ý. Theo các bài đưa tin về kế hoạch hạ tầng, mục tiêu tăng năng lực ban đầu gấp 10 lần đã được điều chỉnh thành yêu cầu thiết kế ở quy mô gấp 30 lần mức khi đó. Một số báo cáo khác đề cập đến việc mở rộng qua Azure và bổ sung năng lực đa đám mây, bao gồm AWS; tuy nhiên, những kế hoạch này không tự chúng giải thích nguyên nhân sự cố ngày 17/8.

Bối cảnh đó khiến sự cố có ý nghĩa vượt ra ngoài một buổi sáng làm việc bị đình trệ. GitHub không chỉ là nơi lưu trữ kho Git mà còn là lớp cộng tác, nền tảng tự động hóa, hệ thống danh tính và dịch vụ hỗ trợ lập trình bằng AI. Khi các phụ thuộc dùng chung gặp vấn đề, một lỗi đơn lẻ có thể đồng thời làm gián đoạn truy cập mã nguồn, đánh giá thay đổi, quá trình build, triển khai, webhook và hỗ trợ lập trình.

Bài học cho các tổ chức phụ thuộc vào GitHub

Sự cố này không chứng minh rằng các nhà phát triển sắp rời bỏ GitHub, và dữ liệu hiện có cũng không đủ để dự đoán một làn sóng chuyển nền tảng sắp xảy ra. Tuy vậy, nó cho thấy các tổ chức dùng GitHub cho hoạt động phát hành phần mềm cần xem lại những giả định về khả năng chịu lỗi.

Các biện pháp thực tế có thể gồm:

• duy trì bản sao lưu hoặc mirror của kho mã nguồn;
• giữ cấu hình CI/CD đủ linh hoạt để có thể chuyển sang môi trường khác;
• ghi lại quy trình phát hành khẩn cấp;
• chuẩn bị phương án khi SSO, webhook hoặc runner được lưu trữ trên GitHub không khả dụng;
• bảo đảm đội ngũ biết cách tiếp tục vận hành khi các dịch vụ phụ thuộc bị gián đoạn.

Những biện pháp này không loại bỏ rủi ro từ nền tảng, nhưng có thể thu hẹp phạm vi ảnh hưởng của lần gián đoạn tiếp theo.

Kết luận cuối cùng về sự cố ngày 17/8 sẽ phụ thuộc vào báo cáo phân tích sau sự cố của GitHub. Cho đến khi báo cáo đó được công bố, nhận định chắc chắn nhất là: GitHub đã trải qua một sự cố dịch vụ diện rộng có tính lan truyền, gây ảnh hưởng nghiêm trọng đến việc tải nội dung kho mã nguồn và các quy trình phát triển liên kết; nền tảng phục hồi theo từng giai đoạn, nhưng nguyên nhân nền tảng vẫn chưa được công khai.

Diễn biến: khắc phục từng phần, không phục hồi đồng thời

GitHub bắt đầu điều tra các báo cáo về hiệu năng suy giảm vào khoảng 13:40 UTC, tương đương 9:40 sáng theo giờ miền Đông nước Mỹ (EDT), ngày 17/8. Sự cố nhanh chóng lan sang nhiều dịch vụ mà các nhóm phát triển sử dụng để truy cập mã nguồn, xem xét thay đổi, chạy tự động hóa và đưa phần mềm vào vận hành.

Trong bản cập nhật đăng lúc 12:36 trưa EDT, GitHub cho biết đã xác định “thành phần có vấn đề”, thực hiện biện pháp khắc phục và ghi nhận các dấu hiệu phục hồi rõ rệt. Tuy nhiên, nền tảng khi đó vẫn chưa hoàn toàn ổn định.

Quá trình phục hồi diễn ra không đồng đều. Nhiều dịch vụ chính trở lại trạng thái hoạt động, nhưng Copilot vẫn gặp lỗi xác thực trong một số ứng dụng. Một số báo cáo sự cố ghi nhận toàn bộ gián đoạn kéo dài đến khoảng 21:15 UTC, lâu hơn đáng kể so với giai đoạn suy giảm nghiêm trọng ban đầu.

Mức độ ảnh hưởng ra sao?

Các chỉ số rõ ràng nhất đến từ số liệu lỗi do GitHub công bố:

• Website và lưu lượng API: tỷ lệ lỗi khoảng 20%.
• Tải tệp lưu trữ và nội dung thô của kho mã nguồn: tỷ lệ lỗi khoảng 50%.
• Công cụ phát triển: Pull Requests, Issues, Actions, Webhooks, các thao tác Git và Pages bị suy giảm hiệu năng hoặc không khả dụng ở những thời điểm khác nhau.
• Trợ lý lập trình AI: GitHub Copilot bị ảnh hưởng và vẫn là một vấn đề đang được xử lý sau khi một số dịch vụ cốt lõi đã phục hồi.
• Danh tính doanh nghiệp: SAML và OIDC, hai cơ chế đăng nhập một lần thường dùng trong doanh nghiệp, cùng SCIM provisioning và Team Sync được báo cáo là bị gián đoạn. Điều này có thể khiến tổ chức gặp khó khăn khi đăng nhập cho nhân viên hoặc quản lý quyền truy cập.

Các tỷ lệ trên là tỷ lệ yêu cầu bị lỗi, không phải tỷ lệ người dùng GitHub mất quyền truy cập. Chẳng hạn, tỷ lệ lỗi API 20% không có nghĩa chính xác 20% khách hàng bị ngắt kết nối; con số 50% chỉ áp dụng cho các yêu cầu tải xuống bị ảnh hưởng, không phải toàn bộ lưu lượng kho mã nguồn.

Vì sao thời điểm xảy ra khiến tác động nặng hơn?

Sự cố bắt đầu vào sáng thứ Hai tại Mỹ, trùng với thời điểm nhiều nhóm kỹ thuật bước vào ngày làm việc đầu tuần. Đây thường là lúc các đội bắt đầu xem xét mã, chạy kiểm thử và tích hợp liên tục (CI), triển khai phần mềm hoặc xử lý kế hoạch trong ngày.

Vì Actions, Pull Requests, API và Webhooks đều bị ảnh hưởng, các nhóm có thể gặp lỗi liên tiếp ở nhiều mắt xích của quy trình phát triển và phát hành, thay vì chỉ mất một tính năng riêng lẻ. Một quy trình tự động có thể cần API để lấy mã, Actions để chạy kiểm thử, Webhooks để kích hoạt bước tiếp theo và quyền doanh nghiệp để xác thực người dùng—tất cả đều có nguy cơ bị gián đoạn trong cùng một sự cố.

Số liệu từ các công cụ theo dõi sự cố cũng khác nhau tùy thời điểm và phương pháp. Một báo cáo cho biết Downdetector đã ghi nhận hơn 10.000 lượt báo lỗi vào lúc 8:12 sáng theo giờ Thái Bình Dương, trong khi một bản tin phục hồi khác nêu mức đỉnh gần 3.000 lượt. Đây không phải số người dùng bị ảnh hưởng chính xác: các nền tảng này đếm lượt người gửi báo cáo, và tổng số thay đổi theo khu vực, thời điểm cũng như cách thu thập dữ liệu.

GitHub đã làm gì, và điều gì vẫn chưa được giải thích?

Các cập nhật công khai của GitHub cho thấy ba bước chính trong phản ứng của công ty:

1. Kỹ sư điều tra tình trạng hiệu năng suy giảm trên nhiều dịch vụ.
2. Công ty xác định một thành phần liên quan đến sự cố và triển khai biện pháp khắc phục.
3. GitHub tiếp tục áp dụng các biện pháp giảm thiểu sau khi những dịch vụ chính bắt đầu phục hồi, trong đó có việc xử lý lỗi xác thực Copilot xảy ra không thường xuyên ở một số ứng dụng.

Nhưng bằng chứng hiện có chưa cho biết thành phần đó là gì, biện pháp khắc phục cụ thể ra sao, hoặc chứng minh áp lực tải là nguyên nhân trực tiếp của sự cố ngày 17/8. Lưu lượng do AI tạo ra và các giới hạn hạ tầng nằm trong bối cảnh thảo luận rộng hơn về độ tin cậy của GitHub, song không nên được xem là nguyên nhân gốc rễ đã được xác nhận trước khi có báo cáo sau sự cố.

Một sự cố mới trong giai đoạn khó khăn của GitHub

Sự cố tháng 8 xảy ra sau một giai đoạn độ tin cậy đáng lo ngại. Báo cáo khả dụng tháng 7 của GitHub ghi nhận tám sự cố trong tháng. Riêng sự cố ngày 8/7 kéo dài hơn bảy giờ, ảnh hưởng đến Web UI, REST API, GraphQL API, Actions, Packages, Copilot và các thao tác Git trong một số môi trường Enterprise Cloud.

GitHub cũng từng mô tả quy mô thách thức hạ tầng mà họ đang đối mặt. Trong thông tin về khả dụng, công ty cho biết lưu lượng tăng nhanh, phần lớn được thúc đẩy bởi các quy trình phát triển có AI hỗ trợ và các tác nhân AI tự động. Các hướng xử lý được nêu gồm chuyển thêm năng lực sang Azure, tách các dịch vụ và giảm những điểm lỗi dùng chung.

Quy mô mở rộng dự kiến cũng đáng chú ý. Theo các bài đưa tin về kế hoạch hạ tầng, mục tiêu tăng năng lực ban đầu gấp 10 lần đã được điều chỉnh thành yêu cầu thiết kế ở quy mô gấp 30 lần mức khi đó. Một số báo cáo khác đề cập đến việc mở rộng qua Azure và bổ sung năng lực đa đám mây, bao gồm AWS; tuy nhiên, những kế hoạch này không tự chúng giải thích nguyên nhân sự cố ngày 17/8.

Bối cảnh đó khiến sự cố có ý nghĩa vượt ra ngoài một buổi sáng làm việc bị đình trệ. GitHub không chỉ là nơi lưu trữ kho Git mà còn là lớp cộng tác, nền tảng tự động hóa, hệ thống danh tính và dịch vụ hỗ trợ lập trình bằng AI. Khi các phụ thuộc dùng chung gặp vấn đề, một lỗi đơn lẻ có thể đồng thời làm gián đoạn truy cập mã nguồn, đánh giá thay đổi, quá trình build, triển khai, webhook và hỗ trợ lập trình.

Bài học cho các tổ chức phụ thuộc vào GitHub

Sự cố này không chứng minh rằng các nhà phát triển sắp rời bỏ GitHub, và dữ liệu hiện có cũng không đủ để dự đoán một làn sóng chuyển nền tảng sắp xảy ra. Tuy vậy, nó cho thấy các tổ chức dùng GitHub cho hoạt động phát hành phần mềm cần xem lại những giả định về khả năng chịu lỗi.

Các biện pháp thực tế có thể gồm:

• duy trì bản sao lưu hoặc mirror của kho mã nguồn;
• giữ cấu hình CI/CD đủ linh hoạt để có thể chuyển sang môi trường khác;
• ghi lại quy trình phát hành khẩn cấp;
• chuẩn bị phương án khi SSO, webhook hoặc runner được lưu trữ trên GitHub không khả dụng;
• bảo đảm đội ngũ biết cách tiếp tục vận hành khi các dịch vụ phụ thuộc bị gián đoạn.

Những biện pháp này không loại bỏ rủi ro từ nền tảng, nhưng có thể thu hẹp phạm vi ảnh hưởng của lần gián đoạn tiếp theo.

Kết luận cuối cùng về sự cố ngày 17/8 sẽ phụ thuộc vào báo cáo phân tích sau sự cố của GitHub. Cho đến khi báo cáo đó được công bố, nhận định chắc chắn nhất là: GitHub đã trải qua một sự cố dịch vụ diện rộng có tính lan truyền, gây ảnh hưởng nghiêm trọng đến việc tải nội dung kho mã nguồn và các quy trình phát triển liên kết; nền tảng phục hồi theo từng giai đoạn, nhưng nguyên nhân nền tảng vẫn chưa được công khai.