Tiêu đề: GitHub Actions đã hoạt động trở lại nhưng cần sửa lỗi thủ công

GitHub Actions đã hoạt động trở lại vào lúc 02:04 UTC ngày 7 tháng 8. Sự cố này đã để lại một loạt các sự kiện push và pull-request không được thực thi, vì vậy các nhà phát triển phải chạy lại các tiến trình đó bằng tay.

Trang trạng thái hiện đã hiển thị màu xanh, nhưng bất kỳ workflow nào lẽ ra phải bắt đầu trong thời gian xảy ra sự cố đều không được kích hoạt. Vì GitHub không thể tự động chạy lại các trigger bị lỡ, các nhóm phải push một commit mới, cập nhật pull request, hoặc nhấp vào Re-run jobs trong giao diện người dùng (UI). Người dùng của Actions Runner Controller mã nguồn mở cũng cần kiểm tra xem các runner pods có đang bị kẹt ở trạng thái chờ (idle) hay không.

Chuyện gì đã xảy ra và tại sao điều này lại quan trọng

GitHub Actions vận hành các pipeline CI của hàng triệu kho lưu trữ (repos). Khi dịch vụ bị đình trệ, các thay đổi mã nguồn sẽ bị treo, các bộ kiểm thử (test suites) không chạy và việc triển khai (deployments) bị chậm trễ. Vào ngày 7 tháng 8, dịch vụ đã ngừng xử lý cả sự kiện push (commit mới) và sự kiện pull-request (cập nhật đánh giá), đây là hai trigger CI phổ biến nhất.

Cách khôi phục các pipeline của bạn

  1. Push một commit mới – bất kỳ thay đổi nào đối với nhánh (branch) cũng sẽ kích hoạt lại trigger push.
  2. Cập nhật pull request – thêm một bình luận, thay đổi tiêu đề hoặc push thêm các commit để kích hoạt lại workflow của PR.
  3. Chạy lại workflow một cách thủ công – giao diện Actions UI hiện hiển thị nút “Re-run jobs” cho mỗi lần chạy thất bại.

Nếu bạn chạy self-hosted runners thông qua Actions Runner Controller, hãy kiểm tra các runner pods. Một số pod có thể vẫn ở trạng thái idle sau khi dịch vụ hoạt động trở lại; hãy khởi động lại hoặc triển khai lại chúng.

Hệ quả đối với các nhóm

  • Mất năng suất – các nhà phát triển phải chờ đợi phản hồi mà thông thường chỉ mất vài phút.
  • Chậm trễ phát hành – bất kỳ pipeline nào đóng vai trò kiểm soát việc phát hành (gating a release) đều có thể đẩy lùi ngày ra mắt sản phẩm.
  • Gánh nặng vận hành – các nhóm phải kiểm tra các lần chạy gần đây, phát hiện các khoảng trống và thực hiện các bước thủ công nêu trên, làm tiêu tốn thời gian dành cho việc phát triển tính năng.

Bài học rút ra: Sự cố này cho thấy ngay cả các dịch vụ CI trưởng thành cũng có thể làm mất các job, và việc tự động chạy lại không phải là điều được đảm bảo. Hãy đưa các bước khôi phục thủ công vào kịch bản ứng phó sự cố (incident-response playbooks) của bạn và theo dõi các bước tiếp theo của GitHub hướng tới việc xử lý sự kiện linh hoạt hơn.