GitHub Actions lại gặp sự cố, lời hứa cải thiện độ tin cậy bị thử thách

GitHub Actions — nền tảng CI/CD quan trọng cho hàng triệu lập trình viên — tiếp tục gặp trục trặc chỉ vài ngày sau khi GitHub công bố những cam kết mạnh mẽ để cải thiện độ ổn định. Sự cố mới nhất làm dấy lên lo ngại rằng công ty vẫn chưa thể kiểm soát được áp lực hạ tầng ngày càng lớn.

Trong báo cáo sự cố, GitHub cho biết sự cố bắt đầu từ lúc 15:11 UTC, khi một database primary gặp lỗi và quá trình failover sang bản sao dự phòng không thể khắc phục hoàn toàn tình trạng suy giảm. Công ty đã phải giới hạn lưu lượng truy cập để điều tra các vấn đề liên quan đến Vitess (hệ thống quản lý database dạng sharding), trước khi từ từ khôi phục. Đến 18:00 UTC, Actions hoạt động bình thường trở lại và hàng đợi đã được xử lý xong.

Một năm đầy biến động của GitHub

Sự cố lần này càng đáng lo ngại vì GitHub mới đây tuyên bố họ đang xử lý gấp đôi số commit so với tháng 4, trong khi tháng 4 vốn đã là một tháng tồi tệ. Theo trang lịch sử trạng thái của GitHub:

• Tháng 1: 25 sự cố
• Tháng 2: 37 sự cố
• Tháng 3: 32 sự cố
• Tháng 4: 26 sự cố
• Tháng 5 và 6: 23 sự cố mỗi tháng
• Tháng 7: 26 sự cố
• Tháng 8: 23 sự cố (vẫn còn gần một tuần nữa mới hết tháng)

Như vậy, chưa tháng nào trong năm nay GitHub có ít hơn 23 vấn đề về độ tin cậy. Điều này cho thấy vấn đề không phải là ngoại lệ mà đang trở thành hiện trạng.

Tỷ lệ uptime trượt dốc

Đối với một dịch vụ SaaS, uptime là thước đo quan trọng nhất. Tỷ lệ uptime của GitHub Actions trong tháng 8 hiện chỉ đạt 98,13%, gần chạm mức 97% — một con số đáng báo động cho một nền tảng tự nhận xử lý hơn 2,9 tỷ commit, 24 triệu repository mới và 130 triệu pull request được merge mỗi tháng.

Đặc biệt, ngày 17/8 chứng kiến sự cố kéo dài gần 8 giờ ảnh hưởng đến hàng loạt dịch vụ quan trọng như Issues, Pull Requests, API, Actions và Copilot — đúng thời điểm nhiều doanh nghiệp cần hoàn thiện sản phẩm cuối tuần.

AI và bot là thủ phạm?

GitHub đã nhiều lần đổ lỗi cho AI và bot khiến lượng sử dụng tăng vọt ngoài khả năng xử lý. CTO Vladimir Fedorov từng đưa ra lời xin lỗi công khai sau sự cố ngày 17/8, hứa hẹn: "Chúng tôi sẽ giành lại niềm tin thông qua việc mở rộng quy mô và gia tăng độ tin cậy của nền tảng." Tuy nhiên, chỉ 6 ngày sau tuyên bố đó, một sự cố mới lại xảy ra và tỷ lệ uptime tiếp tục giảm.

"Đây thực sự là một thử thách lớn cho lời hứa của GitHub. Người dùng cần một nền tảng ổn định để phát triển phần mềm, không phải một dịch vụ thường xuyên gián đoạn."

Bài học cho cộng đồng DevOps Việt Nam

Với các nhóm phát triển phần mềm tại Việt Nam ngày càng phụ thuộc vào GitHub Actions để tự động hóa quy trình build, test và deploy, sự cố lặp đi lặp lại này là một lời nhắc nhở quan trọng:

• Đừng đặt tất cả trứng vào một giỏ: Cân nhắc việc có kế hoạch dự phòng hoặc sử dụng thêm các CI/CD pipeline trên nền tảng khác như GitLab CI, CircleCI hay Jenkins.
• Theo dõi sát tình trạng dịch vụ: Đăng ký nhận thông báo từ trang status.github.com để có phản ứng kịp thời khi xảy ra sự cố.
• Thiết kế hệ thống chịu lỗi tốt: Nếu ứng dụng của bạn phụ thuộc vào các webhook hoặc API của GitHub, hãy có cơ chế retry và queue tin nhắn để tránh mất dữ liệu.

GitHub hiện chưa đưa ra phản hồi chính thức cho các câu hỏi về sự cố lần này. Nhưng rõ ràng, con đường "lấy lại niềm tin" của CTO Fedorov vẫn còn rất gian nan.