GitHub gặp sự cố ảnh hưởng đến Issues, Actions và các tác vụ Git

 (githubstatus.com)
1 điểm bởi GN⁺ 2026-02-10 | 1 bình luận | Chia sẻ qua WhatsApp
  • Các dịch vụ chính của GitHub như Actions, Issues và các tác vụ Git được ghi nhận có suy giảm hiệu năng và phát sinh lỗi
  • Phạm vi ảnh hưởng lan sang Webhooks, Pull Requests, Packages, Pages, Codespaces và nhiều dịch vụ khác
  • GitHub cho biết đã áp dụng biện pháp giảm thiểu (mitigation) và xác nhận hệ thống phục hồi dần, sau đó toàn bộ dịch vụ đã trở lại bình thường
  • Sự cố cũng ảnh hưởng đến một số dịch vụ như Dependabot, Copilot, nhưng cuối cùng đều đã trở về trạng thái xử lý bình thường
  • GitHub sẽ công bố phân tích nguyên nhân gốc rễ (RCA) sau, đồng thời cảm ơn sự kiên nhẫn và hợp tác của người dùng

Tổng quan sự cố

  • GitHub thông báo đang điều tra các báo cáo suy giảm hiệu năng ở Actions, Git Operations, Issues
    • Ở giai đoạn đầu, ghi nhận phản hồi chậm và yêu cầu thất bại, cùng với các tác vụ Actions bị trì hoãn
    • Sự cố lần đầu được báo cáo vào 19:01 UTC ngày 9 tháng 2 năm 2026

Các dịch vụ bị ảnh hưởng

  • Các thành phần bị ảnh hưởng gồm Git Operations, Webhooks, Issues, Pull Requests, Actions, Packages, Pages, Codespaces
    • Sau đó, sự cố cũng được xác nhận trên Dependabot và Copilot
    • Mỗi dịch vụ đều được đánh dấu ở trạng thái “degraded performance (suy giảm hiệu năng)”

Quá trình ứng phó và phục hồi

  • GitHub cho biết đã quan sát thấy tín hiệu phục hồi sau khi áp dụng biện pháp giảm thiểu
    • Quá trình hồi phục dần diễn ra sau 19:29 UTC
    • Đến 19:54 UTC, nhiều dịch vụ đã được khôi phục nhưng một số vẫn đang được điều tra
  • Đến 20:08 UTC, hệ thống được báo cáo là “mọi dịch vụ đều đang xử lý bình thường”
    • 20:09 UTC, trạng thái được chuyển sang đã giải quyết (Resolved)

Trạng thái cuối cùng và bước tiếp theo

  • GitHub nêu rõ toàn bộ dịch vụ đã trở lại hoạt động bình thường
    • Actions, Codespaces, Git Operations, Issues, Packages, Pages, Pull Requests, Webhooks đều đã ổn định trở lại
  • Phân tích nguyên nhân gốc rễ (Root Cause Analysis) sẽ được chia sẻ khi sẵn sàng
  • GitHub bày tỏ cảm ơn sự kiên nhẫn và thấu hiểu của người dùng

Tóm tắt

  • Đây là sự cố ảnh hưởng đến toàn bộ quy trình phát triển cốt lõi trên GitHub
  • RCA sẽ được công bố sau khi hoàn tất khôi phục, và có thể sẽ có các cải tiến để ngăn sự cố tương tự trong tương lai
  • Việc có thêm một sự cố khác cũng được báo cáo trong cùng ngày càng nhấn mạnh tầm quan trọng của quản lý độ ổn định

Bài viết liên quan

1 bình luận

 
GN⁺ 2026-02-10
Ý kiến Hacker News

  • Đang cân nhắc chuyển toàn bộ công ty sang nhà cung cấp khác vì GitHub bị sự cố gián đoạn một phần kéo dài
    Những tính năng trước đây từng hoạt động tốt giờ trở nên chậm chạp, còn Actions cũng không chạy đúng lúc
    Copilot thì tốt đấy, nhưng rốt cuộc nếu git forge không vận hành ổn định thì cũng buộc phải rời đi

    • Hoàn toàn đồng ý. Trước đây nó từng rất tuyệt, nhưng giờ ngay cả các chức năng cơ bản cũng thiếu ổn định
      Chỉ mở một diff PR đơn giản cũng mất hơn 15 giây, và giao diện liên tục rơi vào trạng thái như bị treo
      Thật đáng ngạc nhiên khi mọi người lại chấp nhận kiểu suy giảm hiệu năng bất thường này như chuyện bình thường
    • Câu nói “thích dùng Copilot” nghe như một trò đùa
    • Trớ trêu là Linus Torvalds đã thiết kế git để có kiến trúc không tập trung
      Xét cho cùng, bản chất của git là có thể chạy pipeline CI ngay trên máy cục bộ
      Tôi chỉ dùng GH đơn thuần để đồng bộ
    • Trước đây GitHub thường xuyên công bố postmortem, nhưng gần đây thì hầu như không còn
      Đọc lại các bài cũ có thể thấy họ từng đụng phải giới hạn mở rộng của cơ sở dữ liệu SQL
      Tương tự trường hợp mở rộng Postgres của OpenAI, nhưng có vẻ GitHub đã không ứng phó tốt đến vậy
    • Cho rằng đây là vấn đề của Microsoft, kiểu như “không thể kỳ vọng một sản phẩm đáng tin cậy”

  • Các sự cố thường xuyên của GitHub lại trở thành dịp để kiểm tra độ phục hồi của pipeline triển khai
    Hầu hết các đội ngũ đều phụ thuộc hoàn toàn vào GitHub nên cứ có sự cố là việc triển khai dừng lại
    Vì vậy đã thử các phương án thay thế sau

    1. Mirror các repo quan trọng sang GitLab hoặc Gitea
    2. Cache dependency để tránh build thất bại
    3. Chuẩn bị runbook để có thể triển khai thủ công mà không cần GitHub Actions
      Trang trạng thái chính thức lúc nào cũng cập nhật chậm, nên giờ chỉ còn được xem là thông tin "eventually consistent"

  • GitHub có thể đang chịu tải do sự bùng nổ của các workflow phát triển được tự động hóa
    Số lượng commit ở các repo cá nhân đã tăng bùng nổ nhưng gần như không có ai chuyển sang trả phí

    • Vấn đề thực ra đã bắt đầu từ sau khi Microsoft mua lại
      Có ý kiến cho rằng họ đã bỏ lỡ cơ hội kiếm tiền khi miễn phí repo riêng tư vào năm 2019
    • Thực tế là họ đang di chuyển từ AWS sang Azure, nên sự cố xảy ra thường xuyên
      Và cũng thiếu tinh thần trách nhiệm đối với downtime
    • Cuối cùng thì đây là tình huống đã chạm tới giới hạn mở rộng
    • Do AI tạo mã, số lượng repo, commit và dataset đang tăng bùng nổ
    • Có thể tóm gọn bằng câu: “sống nhờ cơn sốt AI Agent, chết vì sự sụp đổ của AI Agent”

  • Có ý kiến cho rằng GitLab là lựa chọn thay thế
    GitHub giờ chỉ tập trung vào chiến lược lấy AI làm trung tâm, còn chính nền tảng thì bị bỏ bê
    Tỷ lệ chấp nhận Copilot cũng thấp, và doanh nghiệp dùng Claude còn nhiều hơn
    Nếu Microsoft đổi hướng, tình hình sẽ còn tệ hơn

    • Có người hỏi Copilot có phải là mô hình riêng của họ hay không
    • Nhưng GitLab cũng không hoàn hảo
      Tính năng thường được phát hành trong trạng thái mới hoàn thiện một nửa, và tốc độ cũng chậm
      Ưu điểm của mô hình open-core giờ cũng đã mờ nhạt
    • GitLab cũng đang chuyển sang lấy AI làm trung tâm
      Từ Dev → DevOps → DevSecOps → AI DevSecOps nhưng
      ở mỗi giai đoạn độ hoàn thiện đều thấp, và việc nâng cấp giấy phép là bắt buộc nên khá bất tiện

  • Có ý kiến cho rằng chính cấu trúc gộp CI/CD và lưu trữ mã nguồn làm một mới là vấn đề
    Dù có hoạt động hoàn hảo thì cuối cùng vẫn không tránh khỏi vendor lock-in
    Vốn dĩ chỉ cần đổi remote là xong, nhưng giờ lại bị ràng buộc bởi PR, wiki và nhiều thứ khác

    • Thực ra đây không phải nhầm lẫn mà là chiến lược khóa chặt người dùng có chủ đích
    • Dùng hệ thống CI độc lập như giải pháp mã nguồn mở forgejo có thể sẽ khá hơn

  • Giờ sự cố của GitHub không còn giống vấn đề SaaS đơn thuần nữa mà giống sự cố ở cấp độ đám mây
    Vì thế nhiều đội ngũ đang chuyển sang tự host GitLab/Gitea

    • Đã dùng GitLab thành công ở hai startup
      Một tập đoàn lớn dùng GitLab Enterprise on-premise vì lý do bảo mật,
      còn dự án cá nhân thì đang chạy bằng Forgejo
      Git, issue, board, wiki đều hoạt động tốt, và scoped label thì miễn phí
    • Tự host Gitea cũng ổn. Chỉ cần quản lý backup cho tốt
    • Tự host GitLab bản đầy đủ hoàn toàn xứng đáng với chi phí bỏ ra
    • Tự host GitLab thực sự rất hài lòng

  • Có một trang trực quan hóa lịch sử nhiều lần sự cố của GitHub
    Có thể xem tại mrshu.github.io/github-statuses

    • updog.ai/status/github cũng dựa trên dữ liệu Datadog
    • Tuy nhiên có vẻ việc cập nhật đã dừng lại (lần cuối là ngày 6 tháng 2)

  • Cũng có bình luận đùa rằng: “Đội GitHub cứ từ từ thôi, không sao đâu”

  • Muốn rời GitHub, nhưng lại cần CI ổn định và container registry
    Nếu có giải pháp kiểu “chỉ cần chạy tốt” thì sẵn sàng trả tiền

    • Đề xuất Lithus.eu, nơi cung cấp CI dựa trên Forgejo + Firecracker VM
      Phù hợp với workload lớn nhưng chi phí ban đầu cao
    • GitLab CI đơn giản mà vẫn mạnh mẽ
      Việc quản lý quyền cho registry hơi phức tạp một chút nhưng khả năng tích hợp tổng thể rất tốt
    • Có người nghi ngờ liệu repo có nên chịu trách nhiệm cho CI hay không
      Họ cho rằng nên quay lại với các công cụ đơn mục đích theo triết lý Unix
    • Cũng có người đề xuất nix-ci.com
    • CircleCI vẫn là một lựa chọn thay thế hoạt động tốt

  • Sẽ rất thú vị nếu có biểu đồ thể hiện mối tương quan giữa tỷ lệ áp dụng AI và tần suất sự cố

    • Tất nhiên cũng sẽ có nhiều yếu tố khác cùng tác động