- GitHub gần đây liên tục gặp sự cố dịch vụ, đến mức không chỉ khó đạt chuẩn ngành '5 nines (99.999%)' mà ngay cả '3 nines (99,9%)' cũng trở nên khó khăn
- Vào ngày 9 tháng 2, các tính năng chính như Actions, Pull Request, thông báo, Copilot đồng thời gặp sự cố, và một số dịch vụ bị trì hoãn trong nhiều giờ
- Do vấn đề lan truyền chính sách Copilot, một số người dùng đã gặp lỗi hiển thị mô hình cho đến sáng ngày 10 tháng 2
- Sau khi GitHub thay đổi cấu trúc trang trạng thái, việc theo dõi mức sẵn sàng trong 90 ngày gần nhất trở nên khó khăn hơn, và dữ liệu không chính thức còn cho thấy có thời điểm mức sẵn sàng xuống dưới 90%
- Dù SLA của Enterprise Cloud nêu 99,9% uptime, trên thực tế điều này không được đảm bảo cho mọi người dùng, khiến nhu cầu xây dựng chiến lược vận hành đối phó downtime ngày càng lớn
Suy giảm mức sẵn sàng và các sự cố dịch vụ lặp lại của GitHub
- Trong bối cảnh sự cố thường xuyên ở các dịch vụ đám mây ngày càng trở nên phổ biến, GitHub cũng đang gặp vấn đề về độ ổn định
- Đã xuất hiện nhận xét rằng “hiếm có ngày nào không có sự cố”, và tình hình được mô tả là không chỉ xa vời với '5 nines (99.999%)' mà ngay cả '1 nine (90%)' cũng khó đạt
- Vào ngày 9 tháng 2 (theo UTC), các chức năng chính của GitHub gồm Actions, Pull Request, thông báo, Copilot đều gặp sự cố
- Khoảng 15:54, GitHub thông báo rằng “một số dịch vụ đang gặp vấn đề”, đồng thời cho biết độ trễ của thông báo lên tới khoảng 50 phút
- Đến 17:57, độ trễ giảm còn khoảng 30 phút, và lúc 19:29 GitHub thông báo đã khôi phục bình thường
- Sự cố liên quan đến Copilot kéo dài lâu hơn
- Từ 16:29 ngày 9 tháng 2 đến 9:57 ngày 10 tháng 2, một số người dùng gặp vấn đề lan truyền chính sách Copilot
- Vì vậy, đã có báo cáo rằng các mô hình mới được kích hoạt không hiển thị với người dùng
- GitHub đã thay đổi cấu trúc trang trạng thái, khiến việc theo dõi mức sẵn sàng trong 90 ngày gần nhất trở nên khó khăn hơn
- Dù vẫn có thông tin chi tiết, giao diện đã đổi sang dạng khó quan sát xu hướng uptime tổng thể bằng trực quan
- Dữ liệu từ trang phục hồi không chính thức (mrshu.github.io/github-statuses/) cho thấy có thời điểm trong năm 2025 mức sẵn sàng giảm xuống dưới 90%
- SLA Enterprise Cloud của GitHub nêu 99,9% uptime, nhưng không đảm bảo điều này cho mọi người dùng
- Trong ngành, '5 nines' được xem là chuẩn lý tưởng, nhưng một số nhà cung cấp bị đánh giá là ngay cả việc duy trì 90% cũng khó khăn
- Điều này cho thấy khách hàng cần chuẩn bị kế hoạch vận hành với giả định sẽ có downtime
Bối cảnh và các trường hợp liên quan
- Gần đây GitHub đã vấp phải nhiều tranh cãi quanh các tính năng AI và thay đổi chính sách
- Xem xét 'công tắc ngắt' AI để chặn mã đối với Pull Request
-
Rút lại kế hoạch gói cước cho self-hosted runner
- Có trường hợp dự án ngôn ngữ Zig rời GitHub vì chính sách tập trung vào AI của Microsoft
- Cùng với các sự việc này, sự suy giảm ổn định dịch vụ đang trở thành yếu tố làm gia tăng bất mãn trong cộng đồng lập trình viên
Kết luận
- Các sự cố gần đây của GitHub cho thấy vấn đề mức sẵn sàng đến mức khó đạt ngay cả 'ba số 9' (99,9%)
- Khi sự bất ổn của các tính năng cốt lõi như Copilot tiếp diễn, việc đảm bảo độ tin cậy của nền tảng phát triển dựa trên đám mây nổi lên như một bài toán quan trọng
- Nhu cầu xây dựng chiến lược ứng phó downtime một lần nữa được nhấn mạnh
5 bình luận
GitHub là dịch vụ miễn phí mà lại kỳ vọng tính sẵn sàng cao ngay từ đầu thì đúng là...
Nếu KakaoTalk gặp sự cố thì liệu bạn cũng sẽ nói như vậy chứ...
Chắc
git reset --hardlà được thôi nhỉChỉ cần GitHub đừng gặp sự cố nữa thì cứ như hiện tại là ổn rồi
Ý kiến Hacker News
Vấn đề uptime của GitHub rõ ràng là nghiêm trọng, nhưng nói rằng “toàn bộ GitHub bị sập” chỉ vì không phải mọi tính năng đều hoạt động cùng lúc thì tôi thấy hơi quá
Tôi hầu như không dùng Copilot, nên dịch vụ đó có hay ngừng hoạt động cũng không làm tôi bận tâm
Điều thực sự quan trọng là độ ổn định của các chức năng cốt lõi như Git, website, API, Actions
Theo Enterprise SLA của GitHub, mỗi dịch vụ phải được đảm bảo tối thiểu 99.9%, còn số liệu thực tế có thể xem ở đây
Copilot ở mức một con số 9, và các dịch vụ cốt lõi như Git và Actions cũng vậy
Một công ty có nguồn lực như vậy mà vẫn bỏ mặc khách hàng thì không có gì để bào chữa
Trên thực tế, chỉ cần còn trả về response lỗi cũng bị tính là “hoạt động bình thường”
Trường hợp thực sự đạt 99.999% như trong ngành mạng là rất hiếm, đa phần chỉ là mẹo cắt lát dữ liệu để giữ trang trạng thái luôn màu xanh
Tôi đã thấy bất an từ khi CTO của GitHub năm 2025 tuyên bố sẽ “chuyển toàn bộ sang Azure” để nâng cao độ ổn định
Trước đây cộng đồng từng hô hào “hãy thêm tính năng mới nhanh hơn”, nhưng giờ điều cấp thiết hơn là độ ổn định và độ tin cậy
GitHub hiện đang cùng lúc chịu ba sức ép: di chuyển sang Azure, thay đổi hạ tầng dựa trên AI, và lưu lượng AI bùng nổ
Với các dự án nổi tiếng, chỉ vài phút sau khi mở issue là đã có hàng chục PR do AI tạo ra đổ vào
Rất khó để gánh loại tải như vậy, và “N 9s” trước thời AI với “N 9s” sau thời AI là hai bài toán hoàn toàn khác nhau
Nhìn vào trang trạng thái của GitHub thì trên thực tế chỉ là 90.21%, tức mức một con số 9
Trong bản lưu trữ năm 2019, sự cố mỗi tháng chỉ khoảng 1–4 lần, còn bây giờ gần như mỗi ngày một lần
Trong lúc GitHub ám ảnh với các tính năng AI, bảo mật của nền tảng lại đang sụp đổ
Gần đây Aqua Security đã bị tấn công khiến nhiều repo bị nhiễm độc, đây là một trường hợp khai thác lỗ hổng mutable reference trong GitHub Actions
GitHub biết về vấn đề này nhưng vẫn chưa sửa
Ví dụ:
uses: actions/checkout@11bd7190...Công cụ tự động hóa có thể tham khảo mheap/pin-github-action
Trước đây người ta deploy bằng Jenkins và chạy test đơn giản bằng script, còn giờ thì đã thành một địa ngục YAML phân tán
Mức uptime 90% là số liệu gộp tất cả các dịch vụ nên cảm nhận thực tế có thể khác
Nhưng ngay cả 96.47% của Copilot cũng vẫn chỉ là mức một con số 9
GitHub khuyến khích người dùng “hãy dùng mọi tính năng cùng nhau”, nhưng càng làm vậy thì độ tin cậy lại càng tụt mạnh
Ví dụ chỉ mở một PR diff đơn giản thôi cũng mất hơn 30 giây
Đã từng có trường hợp CI/CD, git và tính năng PR cùng ngừng hoạt động
Với tư cách người từng tự vận hành GitHub Enterprise Server, tôi không hề ngạc nhiên trước những vấn đề này
Nó không đáp ứng được các yêu cầu cơ bản của tính sẵn sàng cao như không hỗ trợ active-active, không thể nâng cấp không downtime, không thể rollback
Nếu có bug thì ngoài khôi phục từ backup không còn cách nào khác, và trong quá trình đó sẽ xảy ra mất dữ liệu
Việc đem một sản phẩm như vậy bán cho khách hàng trả tiền cao là bằng chứng cho thấy họ thờ ơ với tính sẵn sàng
Microsoft có tài phá hỏng những sản phẩm tốt
Skype là ví dụ tiêu biểu, và Windows, Notepad, Explorer cũng vậy
Sự hỗn loạn về thương hiệu từ Office → Office 365 → Microsoft 365 → Copilot 365 cũng rất nghiêm trọng
Công ty chúng tôi chạy quét bảo mật bằng GitHub Actions cho mỗi PR
Khi GitHub ngừng hoạt động thì cổng kiểm soát bảo mật cũng dừng theo, và các lập trình viên merge mà không qua xác minh
Trong tình huống như vậy, mã có lỗ hổng vẫn lọt vào, nhưng GitHub lại chỉ dồn nhân lực cho Copilot
Việc phớt lờ IPv6 là biểu tượng cho sự cẩu thả kỹ thuật của GitHub
Vấn đề lớn hơn là tại sao trong tình trạng như vậy mà họ vẫn vượt qua kiểm toán bảo mật
Nhìn vào tài liệu bảo mật của GitHub thì chỉ thấy mang tính hình thức