GitHub: Sự cố gián đoạn thao tác Git

 (githubstatus.com)
3 điểm bởi GN⁺ 2025-11-20 | 1 bình luận | Chia sẻ qua WhatsApp
  • Vào ngày 18 tháng 11 năm 2025 (UTC), GitHub gặp sự cố khiến mọi thao tác Git đều thất bại, làm gián đoạn client SSH·HTTP và truy cập tệp thô
  • Nguyên nhân được xác định là chứng chỉ TLS dùng cho giao tiếp giữa các dịch vụ nội bộ đã hết hạn
  • GitHub đã thay thế chứng chỉ hết hạn và khởi động lại các dịch vụ bị ảnh hưởng để khôi phục hoàn toàn
  • Sau đó, GitHub đang tăng cường cảnh báo giám sát hết hạn chứng chỉ và thúc đẩy chuyển đổi sang tự động hóa để loại bỏ các chứng chỉ được quản lý thủ công
  • Sự cố lần này ảnh hưởng đến Git Operations và Codespaces của GitHub, và sau khi khôi phục, tất cả dịch vụ đã trở lại trạng thái bình thường

Báo cáo sự cố gián đoạn thao tác Git

  • Trong khoảng 20:30~21:34 UTC ngày 18 tháng 11 năm 2025, GitHub xảy ra tình trạng mọi thao tác Git đều thất bại

    • Tất cả tương tác của client Git qua SSH và HTTP, cũng như truy cập tệp thô, đều bị ảnh hưởng
    • Các sản phẩm phụ thuộc vào thao tác Git cũng gặp sự cố tương tự

  • Nguyên nhân được xác định là chứng chỉ TLS đã hết hạn được dùng cho giao tiếp giữa các dịch vụ nội bộ

    • GitHub đã thay thế chứng chỉ và khởi động lại các dịch vụ bị ảnh hưởng để khắc phục vấn đề
    • Sau khi khởi động lại dịch vụ, hệ thống đã khôi phục hoàn toàn

  • Để ngăn chặn vấn đề tương tự trong tương lai, GitHub đang tăng cường hệ thống cảnh báo hết hạn chứng chỉ

    • Đồng thời đang thực hiện giám sát và kiểm tra tự động hóa đối với các chứng chỉ khác trong khu vực liên quan
    • Đẩy nhanh việc loại bỏ các chứng chỉ còn được quản lý thủ công và xây dựng cơ chế giao tiếp giữa các dịch vụ được tự động hóa

Diễn biến sự cố và các bước khôi phục

  • 20:39 UTC: Báo cáo suy giảm khả dụng ở thao tác Git và Codespaces
  • 20:52 UTC: Xác nhận một số thao tác Git HTTP thất bại
  • 21:11 UTC: Xác nhận tình trạng mọi thao tác Git đều thất bại
  • 21:25 UTC: Suy giảm khả dụng của Codespaces vẫn tiếp diễn
  • 21:27 UTC: Hoàn tất xác định nguyên nhân, tiến hành khắc phục
  • 21:36 UTC: Bắt đầu khôi phục một phần sau khi triển khai bản sửa lỗi
  • 21:55 UTC: Tất cả dịch vụ trở lại bình thường, Codespaces khôi phục hoàn tất
  • 21:56 UTC: Xác nhận thao tác Git hoạt động bình thường
  • 21:59 UTC: Kết thúc sự cố và công bố báo cáo

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

  • Git Operations
    • Toàn bộ thao tác Git dựa trên SSH và HTTP
  • Codespaces
    • Xảy ra suy giảm khả dụng tạm thời

Hành động tiếp theo

  • Tăng cường giám sát hết hạn chứng chỉ và tự động hóa
    • Thiết lập hệ thống cảnh báo trước khi hết hạn
    • Kiểm tra quy trình gia hạn tự động cho tất cả chứng chỉ nội bộ
  • Mở rộng tự động hóa bảo mật và vận hành
    • Loại bỏ quản lý chứng chỉ thủ công
    • Xây dựng giao tiếp tự động giữa các dịch vụ phù hợp với thực tiễn bảo mật hiện đại

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-11-20
Ý kiến trên Hacker News

  • Gần đây có vẻ các sự cố hệ thống phần mềm lớn xảy ra quá thường xuyên, khá đáng lo
    Năm ngoái chỉ có bốn lần sự cố ảnh hưởng đến công việc, nhưng quý này đã là lần thứ tư rồi
    Có cảm giác khả năng phục hồi (resiliency) của phần mềm mạng đang dần biến mất
    Đội của chúng tôi dùng kiến trúc monolithic, nhưng có rất nhiều phụ thuộc như Redis, S3, các dịch vụ tích hợp bên ngoài
    Vì vậy chúng tôi đã đơn giản hóa hệ thống bằng cách tài liệu hóa các điều kiện lỗi, tăng cường kiểm thử và tự động hóa triển khai, và chuyển từ cloud sang VPS
    Kết quả là hệ thống ổn định hơn nhiều và dễ dự đoán hơn
    Nếu không có những công việc nhàm chán nhưng thiết yếu này, độ phức tạp chỉ tăng lên và hệ thống sẽ càng dễ tổn thương hơn
    Các sự cố gần đây tôi gặp là AWS us-east-1, Azure Front Door, Cloudflare, và sự cố GitHub

    • Cuối cùng tôi nghĩ vấn đề là tiền
      Khách hàng không muốn chi tiền cho khả năng phục hồi hay hạ tầng dự phòng
      Từ sau năm 2008 tôi đã làm hơn chục dự án, nhưng đa số đều có thái độ kiểu “cứ phó mặc cho may rủi”
    • Đồng ý. Việc cắt giảm chi phí cuối cùng dẫn tới chuyện “quên mất cách xây dựng hệ thống có thể trụ được khi sự cố xảy ra”
    • Nói hơi khiêu khích một chút thì tôi cho rằng việc dùng LLM ngày càng nhiều cũng góp phần vào hiện tượng này

  • Git là một hệ thống quản lý phiên bản phân tán, nên dù không có GitHub vẫn có thể làm việc được
    GitHub chỉ là một hub tiện lợi mà thôi

    • Tuy vậy, nếu là công ty phụ thuộc hoàn toàn vào GitHub Actions thì lúc này coi như bị chặn hoàn toàn
    • Giống như kiểu “thang cuốn này tạm thời đã trở thành cầu thang. Xin lỗi vì sự bất tiện”
    • Bản chất vấn đề là GitHub bị sập, chứ không phải git tự nó bị sập
    • Không có GitHub thì sẽ mất chức năng hub cộng tác với người khác
    • Lý do tôi đang ở trên Hacker News lúc này là vì không làm việc được

  • Tôi thấy độ tin cậy kém của GitHub là một vấn đề nghiêm trọng
    Với những người phụ thuộc vào CI/CD thì đây là đòn chí mạng
    Nội bộ có vẻ chỉ nhìn nhận ở mức “CI/CD của đội mình bị hỏng”, thiếu góc nhìn rằng “một nửa thế giới đang đứng yên”
    Kiểu văn hóa silo này và thái độ “không phải vấn đề của chúng tôi” dẫn đến suy giảm độ tin cậy
    Hơn nữa, nhờ vị thế gần như độc quyền nên khách hàng cũng đành phải chịu mà dùng
    Nó giống hệt thái độ kiểu “đằng nào anh cũng chẳng chuyển đi đâu được” mà tôi từng thấy ở Verio và Verisign trước đây

  • Tôi tự hỏi dạo này các sự cố cloud/SaaS có thực sự xảy ra thường xuyên hơn không
    Không rõ chỉ là được đưa tin nhiều hơn, hay tần suất thực sự đã tăng lên
    Liệu có phải do cắt giảm ngân sách, sa thải nhân sự, áp dụng AI, tăng trưởng quá mức không?

    • Có vẻ Microsoft tin rằng chuyển GitHub sang Azure là sẽ giải quyết được vấn đề
    • Với góc nhìn của người đã dùng lâu năm thì đúng là có thể cảm nhận rõ tần suất sự cố tăng lên
      Trước đây là một hai lần mỗi năm, còn giờ gần như hàng tháng, gần đây thì mức hàng tuần
    • Có người từng nói trong sự cố Cloudflare rằng “văn hóa lập trình dựa trên AI” đang làm các vấn đề này tệ hơn
      Những mẩu mã AI nhỏ có thể gây ra sự cố dây chuyền kiểu domino
    • Giống như trong bài viết của Techrights,
      tôi cho rằng các đợt sa thải quy mô lớn đã ảnh hưởng đến độ tin cậy
    • Vì FOMO (sợ bị bỏ lỡ) do AI gây ra mà lịch trình dự án càng bị siết chặt hơn,
      và cuối cùng 10% công việc cuối cùng để đảm bảo ổn định lại bị bỏ qua

  • Lúc đầu tôi tưởng là vấn đề phía mình vì không push được
    Chắc hôm nay đành bỏ cuộc và mai làm lại vậy

    • Xác thực thì được nhưng push không được, đúng là trải nghiệm muốn bứt tóc
    • Thêm lại SSH key mới cũng vô ích. Ban đầu chỉ hiện lỗi kỳ quặc, rồi cuối cùng ra thông báo “upstream unhealthy”
    • Tôi cũng suýt nữa thiết lập lại môi trường từ đầu

  • Hôm nay vốn đã không muốn làm việc, giờ Cloudflare xong lại tới GitHub gặp sự cố, cảm giác như một tín hiệu bảo cứ nghỉ đi

    • Vấn đề là sự phụ thuộc tập trung vào công nghệ lấy Mỹ làm trung tâm
      Cần nhiều hơn chủ quyền công nghệ và phân tán hóa

  • Trong các dịch vụ tôi dùng 5 năm qua thì GitHub là thứ bất ổn nhất
    Không biết GitLab có tốt hơn không. Giờ niềm tin của tôi với GitHub gần như bằng 0

    • Công ty tôi đang self-hosted GitLab, nhưng máy chủ Gitaly hay gặp sự cố
      Có lẽ do môi trường monorepo lớn, nhưng rõ ràng có vấn đề về khả năng mở rộng
    • GitLab có nhiều tính năng nhưng tích hợp lỏng lẻo và độ hoàn thiện thấp
      Dù vậy, việc để repository, CI/CD, issue và wiki ở cùng một chỗ vẫn là ưu điểm
    • Tôi dùng cả GitHub.com lẫn GitLab self-hosted,
      GitHub thì dễ dính sự cố cloud, còn GitLab thì hay bị gián đoạn khi tự động nâng cấp
      Mỗi bên có ưu và nhược điểm riêng
    • Vấn đề của GitLab là nó chậm và nặng
      Nó tải vài MB JS nên trên mạng chậm thì gần như không mở nổi trang
    • Nếu đặt on-premises thì có thể đảm bảo độ ổn định đến mức mình mong muốn

  • Trong tình huống khẩn cấp, có thể sửa file trực tiếp trên web UI của GitHub
    Nhưng actions/checkout@v4 của GH Actions hiện không hoạt động vì vấn đề git

    • Thực ra có thể git push/pull qua bất kỳ host nào truy cập SSH được
    • Bọn tôi cũng đang làm hotfix production thì bị chặn lại. Không hiểu dạo này Internet đang có chuyện gì nữa
    • CircleCI cũng đang thất bại trong thao tác git do vấn đề nhận diện SSH key của GitHub
    • Lần này GitHub AI lại bảo tôi kiểm tra githubstatus.com nên bất ngờ là có ích
    • Không biết trên UI của GitHub có tạo branch được không

  • Trong 10 năm qua, khi đi qua lại giữa tập đoàn lớn và startup, tôi thấy có một mô thức chung
    startup → đáp ứng khách hàng enterprise → tái thiết kế phức tạp → lý tưởng hóa → chạy theo lợi nhuận → sản phẩm phình to → kỹ sư cốt lõi rời đi → chất lượng đi xuống
    Chu kỳ này cũng lặp lại ở các ông lớn cloud (AWS, Cloudflare, GCP...)
    Ngay cả bên trong nội bộ, từng dịch vụ cũng bị chia nhỏ thành các đơn vị kinh doanh nhỏ và vận hành theo hướng lợi nhuận
    Cuối cùng, ngay cả hạ tầng nền tảng cũng đang suy yếu vì áp lực lợi nhuận
    Tôi thấy niềm tin kiểu “AWS hay GCP to thế thì chắc không thể thất bại được đâu” là rất nguy hiểm

    • Đồng ý. Trong quá trình phục vụ enterprise, việc sản phẩm trở nên phức tạp và ì ạch là điều tất yếu
      Nhưng các vấn đề nợ kỹ thuật và bảo mật ở startup giai đoạn đầu cũng rất nghiêm trọng
      Cuối cùng, việc các vết nứt của hệ thống lộ ra trong quá trình tăng trưởng quy mô lớn là điều tự nhiên

  • Trên trang trạng thái của GitHub lại xuất hiện câu “một số người dùng có thể gặp vấn đề”
    Nhưng thực tế thì không chỉ HTTPS mà cả SSH push cũng đều thất bại

    • Có vẻ những người phụ trách trang trạng thái không thoát ra được cách diễn đạt “một số người dùng”
      Lẽ ra công khai thông tin minh bạch thay vì cách nói giảm nói tránh kiểu PR sẽ giúp tăng niềm tin hơn
      Hơn nữa, ngay cả việc cập nhật trang trạng thái đôi khi cũng chậm
    • Bạn tôi nói có lúc push được trong chốc lát, nhưng đa số vẫn đang ở trạng thái lỗi fatal