GitHub hiện đang gặp sự cố

 (githubstatus.com)
1 điểm bởi GN⁺ 5 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Hiệu năng của Pull Requests đang bị suy giảm, và trên các trang /pulls và /repo/pulls, có thể không hiển thị toàn bộ pull request đã được lập chỉ mục
  • Hiện tại cụm Elasticsearch chưa chứa đầy đủ tất cả tài liệu đã được lập chỉ mục, nhưng bản thân dữ liệu pull request không bị mất và sẽ được lập chỉ mục lại khi có cập nhật
  • GitHub đang одновременно tiến hành lập chỉ mục lại các chỉ mục còn lại và đẩy nhanh full reindex để khôi phục đầy đủ kết quả, ưu tiên tính chính xác và tránh tác động phát sinh
  • Trong bảng trạng thái thành phần, chỉ Pull Requests được hiển thị ở trạng thái suy giảm; Git Operations, Webhooks, API Requests, Issues, Actions, Packages, Pages, Copilot, Codespaces và Copilot AI Model Providers đều ở trạng thái Operational
  • Lịch sử gần đây cũng công khai nhiều sự cố và biện pháp khôi phục, như suy giảm tìm kiếm, lỗi job Actions, lỗi khởi động phiên Copilot agent, hồi quy merge queue, độ trễ Projects và lỗi kết nối Codespaces

Tình trạng sự cố hiện tại

  • Pull Requests đang bị suy giảm hiệu năng và đã được công khai trong mục Incomplete pull request results in repositories
  • Trên các trang /pulls và /repo/pulls, có thể không hiển thị đầy đủ các pull request đã được lập chỉ mục
    • Hiện tại trong cụm Elasticsearch không có đầy đủ mọi tài liệu đã lập chỉ mục
    • Bản thân dữ liệu pull request không bị mất
    • Khi pull request được cập nhật, nó sẽ được lập chỉ mục lại
    • GitHub cũng đang đẩy nhanh full reindex để khôi phục đầy đủ kết quả
  • GitHub đang lập chỉ mục lại các chỉ mục Elasticsearch còn lại, ưu tiên tính chính xác và xử lý theo hướng tránh tác động bổ sung
    • Vẫn duy trì cách tiếp cận thận trọng để backfill dữ liệu an toàn

Trạng thái thành phần

  • Trong bảng trạng thái hiện tại, chỉ Pull Requests được hiển thị là Degraded Performance
  • Các thành phần chính còn lại đều ở trạng thái Operational
    • Git Operations
    • Webhooks
    • API Requests
    • Issues
    • Actions
    • Packages
    • Pages
    • Copilot
    • Codespaces
    • Copilot AI Model Providers
  • Cùng với đó là tỷ lệ uptime trong 90 ngày qua
    • Pull Requests 99.58% uptime
    • API Requests 99.95% uptime
    • Packages 99.97% uptime
    • Copilot AI Model Providers 100.0% uptime

Trang trạng thái theo khu vực và kênh đăng ký

Lịch sử sự cố gần đây

  • Apr 28 Sự cố với một số dịch vụ GitHub

    • Mục Disruption with some GitHub services đã được giải quyết
    • Trên các job Ubuntu được host bởi Actions đã xảy ra chậm khởi động và thất bại
      • Một phần các lần chạy ubuntu-latest và ubuntu-24.04 bị chậm hoặc thất bại
      • Có thời điểm khoảng 5% job bị ảnh hưởng, sau đó giảm xuống dưới 2%, rồi tiếp tục xuống dưới 1%
    • Vấn đề cản trở việc chạy Actions đã được giảm nhẹ và cuối cùng được khôi phục về hoạt động bình thường

  • Apr 27 Suy giảm tìm kiếm GitHub

    • Mục GitHub search is degraded đã được giải quyết
    • Do sự cố kết nối Elasticsearch và tải bổ sung, đã đồng thời xảy ra lỗi tìm kiếm và vấn đề ở nhiều dịch vụ con
      • Issues, Pull Requests, Packages và Actions đều bị ảnh hưởng
      • Đã xảy ra lỗi workflow run, lỗi tải projects và timeout tìm kiếm
    • Sau khi chặn được nguyên nhân gây tải bổ sung, đã xuất hiện dấu hiệu phục hồi và sau đó chuyển sang giai đoạn giám sát ổn định

  • Apr 27 Sự cố phiên Codex của Copilot Cloud Agent

    • Mục Disruption with some GitHub services đã được giải quyết
    • Trong Copilot Cloud Agent đã xảy ra lỗi khởi động phiên Codex agent
      • Không thể khởi động từ mọi điểm vào, bao gồm gán issue và mention @copilot trong bình luận
      • Ảnh hưởng đến 0.5% tổng số tác vụ Copilot Cloud Agent, tương đương khoảng 2,000 tác vụ thất bại
      • Các phiên agent khác của Copilot không bị ảnh hưởng
    • Nguyên nhân là model resolution mismatch trong phiên Codex agent khiến một mô hình không tương thích bị chọn lúc runtime
    • GitHub đã triển khai biện pháp giảm nhẹ để chọn một mô hình mặc định ổn định cho phiên Codex agent

Các trường hợp lớn có công bố nguyên nhân gốc rễ

  • Hồi quy trong merge queue của Pull Requests

    • Incident with Pull Requests đã được giải quyết
    • Khi dùng squash merge trong merge queue, nếu merge group có từ hai PR trở lên thì một merge commit sai có thể được tạo ra
      • Ở các lần merge sau đó, thay đổi của PR trước đó và thay đổi từ commit trước đó có thể bị đảo ngược
      • Trong khoảng thời gian bị ảnh hưởng, 2,092 pull request đã bị tác động
    • Các PR được merge ngoài merge queue và một số nhóm dùng phương thức merge hoặc rebase không bị ảnh hưởng
    • Nguyên nhân là một đường mã mới điều chỉnh việc tính merge base đã được áp dụng trong trạng thái feature flag gating không đầy đủ
    • GitHub đã hoàn tác thay đổi mã và ép triển khai trên toàn bộ môi trường, đồng thời gửi riêng quy trình khôi phục cho quản trị viên các kho bị ảnh hưởng
    • Sau đó, GitHub đang mở rộng phạm vi kiểm thử tính đúng đắn của merge để bao gồm cả các nhóm squash nhiều PR

  • Không thể khởi động Claude·Codex agent từ web

    • Disruption with users unable to start Claude and Codex agent task from the web đã được giải quyết
    • Không thể khởi động tác vụ agent mới bằng Claude hoặc Codex từ github.com
    • Nguyên nhân là thay đổi mã định tuyến task creation request của Copilot mission control
    • Các agent task đang chạy và những tính năng Copilot agent khác không bị ảnh hưởng
    • GitHub đã khôi phục bằng cách hoàn tác thay đổi gây lỗi, đồng thời bổ sung giám sát và kiểm thử tích hợp cho luồng tạo task

  • Bỏ sót xử lý mention Copilot

    • Disruption with some GitHub services đã được giải quyết
    • Mention @copilot trong bình luận pull request không dẫn tới việc chạy Copilot coding agent
      • Trong tổng số bình luận pull request và issue, khoảng 23,000 lần gọi, tương đương 0.5%, đã không được xử lý
      • Bản thân việc tạo, xem và trả lời bình luận không bị ảnh hưởng
    • Nguyên nhân là serialization error khiến không thể phát hành sự kiện tới downstream consumer
    • Sau khi triển khai bản sửa để khôi phục phát hành sự kiện, hệ thống đã trở lại bình thường; GitHub đang tiếp tục rà soát schema sự kiện liên quan và cải thiện giám sát

  • Gián đoạn Copilot Chat và Cloud Agent

    • Disruption with Copilot chat and Copilot Coding Agent đã được giải quyết
    • Lỗi đã xảy ra trong Copilot Chat và Copilot Cloud Agent trên github.com, khiến chúng không thể sử dụng trong khoảng thời gian đó
    • Copilot Memory ở trạng thái preview cũng không thể dùng trong các phiên agent
    • Nguyên nhân là thay đổi cấu hình hạ tầng gây ra vấn đề kết nối cơ sở dữ liệu
    • github.com được khôi phục trước, sau đó các vùng triển khai còn lại lần lượt được phục hồi

  • Độ trễ dịch vụ Projects

    • Disruption with projects service đã được giải quyết
    • Projects có thể không đồng bộ hoặc phản ánh thay đổi chậm
      • Độ trễ phản ánh thay đổi có lúc tăng lên tới khoảng 45 phút
    • Nguyên nhân là serialization error gây lỗi sự kiện và làm tăng đột biến resync, khiến tầng xử lý sự kiện bị quá tải
    • GitHub đã giảm nhẹ bằng cách tăng tốc độ xử lý thay đổi đầu vào, sau đó khôi phục khi dọn hết backlog

  • Suy giảm default setup của code scanning và Code Quality

    • Partial degradation for code scanning default setup and for code quality đã được giải quyết
    • Trên các pull request mới, code scanning default setup và phân tích code quality không được kích hoạt
    • Đồng thời cũng xảy ra vấn đề khiến issue mới tạo không hiển thị trên project board
    • Nguyên nhân là serialization error khiến việc kích hoạt code scanning, phân tích code quality và cập nhật project board không diễn ra đúng cách
    • GitHub đã khôi phục việc phát hành sự kiện cho code scanning và code quality; phía project board được khôi phục bằng thay đổi mã bổ sung và reindex
    • Với các PR không được xử lý trước hoặc trong thời gian sự cố, cần có push mới thì phân tích mới được kích hoạt lại

Các sự cố gần đây khác

  • Disruption with some GitHub services
    • Trải nghiệm web trên GitHub.com bị suy giảm, và khoảng 1.5% yêu cầu web kết thúc với lỗi
    • Ở một số thời điểm, khoảng 10% lưu lượng web bị chậm hoặc thất bại
    • Nguyên nhân là bão hòa dung lượng của thành phần cache tại một khu vực trung tâm dữ liệu
    • GitHub đã khôi phục bằng cách chuyển hướng lưu lượng sang khu vực không bị ảnh hưởng và rollback bản triển khai gần đây
  • Incident with Codespaces
    • Kết nối GitHub Codespaces thông qua trình soạn thảo VS Code bị thất bại
    • Khoảng 40% tác vụ khởi động codespace bị thất bại
    • Kết nối SSH không bị ảnh hưởng
    • Nguyên nhân là sự cố ở upstream download service, làm chặn tải VS Code Server cần thiết khi khởi động
    • Đã giảm nhẹ bằng cách dùng đường dẫn tải thay thế khi endpoint mặc định bị suy giảm
  • Disruption with some GitHub services
    • Khi truy cập trang Copilot Insights của GitHub Enterprise Cloud đã xảy ra lỗi 500
    • Khoảng 709 người dùng bị ảnh hưởng, với tổng thời gian ảnh hưởng khoảng 5 giờ 10 phút
    • Nguyên nhân là lỗi xác thực của metrics pipeline và thay đổi tenant credential
    • GitHub đang tăng cường công cụ chẩn đoán, giám sát chi tiết hơn và alerting

Bài viết liên quan

1 bình luận

 
GN⁺ 5 giờ trước
Ý kiến trên Hacker News

  • Vấn đề lớn hơn lúc này là nó thất bại một cách âm thầm
    Ví dụ có hàng chục PR nhưng lại hiển thị "There aren’t any open pull requests.", khiến mọi người bị đánh lừa rõ ràng

    • Tuần trước còn có vụ dùng merge queue thì lỡ tay làm bay cả trunk, và chuyện đó cũng thất bại trong im lặng
    • Bên tôi thì ngược lại còn đùa là cuối cùng cũng xử lý xong toàn bộ PR nên đang ăn mừng
    • Ngay cả khi danh sách PR hiện ra, đôi lúc nó cũng không hiển thị hết các PR trong danh mục đang xem, thật sự rất tai hại

  • Chuyện này thật sự chạm tới tôi rất nhiều
    Vài tháng trước, $PARENT_CONGLOMERATE đã ép toàn bộ các đơn vị trực thuộc phải migrate sang GitHub với lý do cộng hưởng và hiệu quả, và giờ đến lượt $DAYJOB của tôi phải rời self-hosted GitLab
    Tôi đã có sẵn vài điều không hài lòng
    Chính sách IT liên quan đến tài khoản GH rất thiếu nhất quán, nên dù là tài khoản cá nhân hay tài khoản từng tạo riêng cho $DAYJOB trước đây thì đều không dùng lại được, mà phải tạo tài khoản mới theo đúng quy định IT
    Chúng tôi không dùng monorepo, nên tận dụng groups rất nhiều, nhưng GitHub không có khái niệm tương ứng trực tiếp nên phải tự tay sắp xếp namespace dự án
    Mà giờ độ sẵn sàng của GitHub còn ra nông nỗi này
    Lịch phát hành của đội chúng tôi rất nhạy với doanh thu, chỉ chậm một hai ngày thôi cũng có thể quyết định việc đạt hay trượt mục tiêu tháng
    Trong hoàn cảnh khác thì có lẽ tôi đã mirror sẵn phần code cốt lõi tạo doanh thu, nhưng có vẻ không đáng để chấp nhận rủi ro mà dựng một đường vòng kiểu du kích như thế
    Tôi ước gì trong bản postmortem tương lai có thể đổ lỗi cho The Synergy Mandate, nhưng thực tế thì tôi cũng quá rõ điều đó khó mà xảy ra
    Tôi chỉ mong tiếp tục đạt chỉ tiêu doanh thu và sản phẩm không bị cắt vì thành tích kém
    Viết ra thế này mới càng thấy công việc này đã khác xa thế nào so với lúc tôi mới vào

  • Tôi muốn nhắc lại với mọi dự án OSS
    Dùng một tác vụ CI đơn giản để đồng bộ code giữa nhiều forge là chuyện cực kỳ dễ, và việc nhận email thông báo từ một forge thứ hai cũng hầu như không thêm gánh nặng gì
    Ít nhất cũng nên mở sẵn lựa chọn để có thể đóng góp bên ngoài GitHub, và về lâu dài điều đó tốt hơn cho toàn bộ hệ sinh thái

    • Bản thân việc đồng bộ code là phần dễ và nhỏ nhặt, CI thực ra chỉ giải quyết đúng phần đó
      Với đa số dự án thì ngay cả việc đó cũng chưa chắc là bắt buộc tuyệt đối
      Cái khó là những thứ xung quanh code
      tickets và PR, bao gồm cả lịch sử những thứ đã đóng
      Các loại liên kết tham chiếu đến dự án
      Cấu hình CI
      Với dự án lớn thì còn có cả cấu trúc quyền committer
      Nếu cần thì phải chuyển cả quy tắc push/commit/branch
      Những thứ này mỗi dự án migrate đều rất phiền, và có thể làm mất một phần
      Nhưng vấn đề lớn hơn nữa là đánh mất nền tảng mặc định để tìm phần mềm
      Không biết bao giờ mới có một fediverse dành cho phần mềm
    • Đồng bộ chỉ là chuyện nhỏ, điểm cốt lõi thật sự là CI
      GitHub Actions vẫn là lựa chọn tốt nhất, và dù là FSF hay phòng lab OSS nào khác cũng đều chưa cung cấp được CI tử tế cho các maintainer mã nguồn mở
      Chưa kể tải của CI giờ còn lớn hơn trước rất nhiều
    • Tự dựng một instance GitLab cũng có thể là một giải pháp tốt

  • Giờ tôi thực sự thấy cần phải nghiêm túc thúc đẩy các lựa chọn thay thế
    Chuyện này đã bắt đầu ảnh hưởng thực tế đến công việc kinh doanh của chúng tôi, mà cũng chẳng có dấu hiệu gì cho thấy nó sẽ khá hơn

    • Nếu muốn giao diện kiểu GitHub thì cứ dùng Forgejo hoặc Gitea
      Chỉ cần chấp nhận ràng buộc cấu trúc org/repo
      Nếu muốn trải nghiệm tương tự nhưng hơi khác một chút thì GitLab là phù hợp
      Nếu muốn kiểu gần với phía kernel hơn, tức là hosting với cấu trúc kho linh hoạt, xác thực người dùng bằng ssh key, và web UI đơn giản, thì có thể dùng cgit gắn với gitolite hoặc dùng gitweb
    • Chúng tôi đã self-host Gitea cùng Drone/Woodpecker nhiều năm nay và nó hoạt động rất tốt
      Dù là Gitea hay Forgejo thì chỉ cần đáp ứng đúng tính năng cần có là đủ
      Thỉnh thoảng tôi vào các thread GitHub gặp sự cố để cười chút, vì instance Gitea của chúng tôi trong vài năm qua tổng downtime chỉ tính bằng vài phút, và tất cả đều là các đợt nâng cấp có kế hoạch vào ban đêm
    • Tôi ngạc nhiên vì GitLab không được chú ý hơn
      Nó không phải bản sao hoàn chỉnh, nhưng vẫn đủ gần; tôi thấy khác biệt giống táo với lê hơn là cam với táo
    • Tôi cũng nghĩ như vậy
      Chỉ là GitHub thật sự là một nền tảng rất dính, một khi đã cài Actions và đủ kiểu tích hợp thì rất khó rời đi
      Dù vậy, việc nó gặp sự cố thường xuyên đến mức này giờ thật sự hơi lố
    • Hiện tại tôi đang self-host Git và CI bằng Forgejo và thấy nó chạy rất ổn, rất hài lòng

  • Có vẻ đây không chỉ là chuyện riêng của GitHub mà là một sự cố lớn hơn: https://downdetector.com

    • Điểm chung rất có thể là Azure

  • Hôm nay cũng lại là một ngày có chữ y ở cuối, vậy nên dĩ nhiên lại có GitHub gặp sự cố

  • Codeberg.org lúc này cũng đang có vấn đề

    https://status.codeberg.org/status/codeberg

    https://social.anoxinon.de/@codebergstatus/11647770704799298...

  • Nếu bạn không thích GitHub sập, và cũng không thích chuyện AI ăn cắp code, thì có thể thử sourcehut
    Nó rất hợp với tôi, và tôi mong nó sẽ phát triển thịnh vượng hơn như một nền tảng

    • Tôi thích cảm giác khám phá các kho mới, nên đã chuyển toàn bộ sang Codeberg, và phần lớn các dự án tôi quan tâm cũng ở đó
    • Tôi không rõ sourcehut khác biệt ở điểm nào
      Suy cho cùng chẳng phải nó cũng chỉ là một dịch vụ tập trung khác sao

  • Lần này tôi thấy nó kéo dài bất thường
    Làm tôi nghĩ đến kiểu đùa rằng đội sửa lỗi bị dính giới hạn phiên Claude nên phải chờ hết cooldown mới đụng vào được, còn người duy nhất biết tự sửa mà không cần AI thì lại đang nghỉ để đi phẫu thuật
    Tôi cũng tự hỏi sau này khi cả thế hệ từng biết tự sửa mà không cần AI đều nghỉ hưu hết thì sẽ ra sao

  • Mỗi lần GitHub sập là lại có thêm vài người chuyển sang các lựa chọn thay thế có đạo đức, và cấu trúc để cộng đồng FOSS đặt SPOF vào một mình Microsoft cũng yếu đi đôi chút

    https://sfconservancy.org/GiveUpGitHub/

    • Tôi đồng cảm với tinh thần đó, nhưng khía cạnh xã hội của việc nhiều dự án tập trung trên GitHub rõ ràng vẫn có lợi thế
      Việc cộng tác dễ hơn, còn bây giờ thì vì nhiều lý do mà ma sát đang tăng lên
      issues cũng ngày càng bị dùng như spam, và thậm chí còn bắt đầu xuất hiện những hành vi độc hại hơn thế
    • SPOF là viết tắt của Single Point of Failure