Lịch sử thời gian hoạt động của GitHub

 (damrnelson.github.io)
1 điểm bởi GN⁺ 21 ngày trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Trang trực quan hóa thời gian hoạt động theo tháng của GitHub từ năm 2016 đến 2026
    • Toàn bộ dữ liệu được tổng hợp dựa trên các bản ghi thu thập từ trang trạng thái chính thức
  • Cấu trúc cho phép xem tách biệt giữa tỷ lệ hoạt động trung bình (Average) và chi tiết các lần gián đoạn (Breakdown)
  • Có thể truy cập trực tiếp nguồn dữ liệu gốc (View source) ngay trên trang
  • Tư liệu trực quan giúp nắm bắt nhanh xu hướng ổn định dịch vụ trong dài hạn
  • Được xây dựng theo hướng tập trung vào trực quan hóa dữ liệu mà không có phân tích hay diễn giải bổ sung

Bài viết liên quan

1 bình luận

 
GN⁺ 21 ngày trước
Ý kiến trên Hacker News

  • Tôi từng tự hỏi liệu dữ liệu trước năm 2018 có thực sự chính xác hay không
    Tôi nhớ là trước đây cũng đã có nhiều lần sự cố
    Có lẽ từ thời điểm đó họ mới bắt đầu dùng hệ thống theo dõi uptime hiện tại

    • Dữ liệu được lấy từ trang status chính thức
      Nhưng có vẻ trang này thiên về marketing/giao tiếp hơn là để quan trắc

  • Cá nhân tôi thấy trang trạng thái thay thế này tốt hơn
    Nó có tên là “The Missing GitHub Status Page”, hiển thị tổng hợp tỷ lệ khả dụng trong 90 ngày gần nhất
    Hiện tại là 90.84%, nhỉnh hơn một chút so với 90.00% vài ngày trước

    • Tình hình gần đây khá khốc liệt
      Tỷ lệ khả dụng của GitHub Actions trong tháng 2 năm 2026 là 98%, tức chỉ ở mức một số ‘9’
      Cảm giác thực tế là cứ 50 lần thì có 1–2 lần thất bại (khoảng 2%)
    • Kiểu chỉ số tổng hợp này có vẻ không phải thước đo hợp lý lắm
      Ví dụ khi OpenAI bị down khiến CoPilot không hoạt động, liệu có nên tính đó là downtime của GitHub không thì tôi vẫn băn khoăn
    • Thực ra hai trang chỉ là trình bày cùng một thống kê theo cách khác nhau
      Có vẻ OP đã đưa ra theo hướng muốn nhấn mạnh kết quả sau thương vụ Microsoft thâu tóm
    • “90% thì tương đương gần 5 tuần downtime” theo cách tính đó
      Nói đùa thôi, nhưng xem ra GitHub giờ cũng xứng đáng được hưởng mức ‘nghỉ phép có lương’ như vậy

  • Việc hiển thị dữ liệu mà không đánh dấu thời điểm tính năng được đưa vào là thiên lệch
    Ví dụ GitHub Actions ra mắt vào tháng 8 năm 2019, nên việc trước đó không có downtime là điều hiển nhiên

    • Trong mục “Breakdown”, bạn có thể bấm “Actions” để ẩn hạng mục đó
    • Nếu xem trang chi tiết thì quy mô của từng dịch vụ riêng lẻ có giảm đi, nhưng xu hướng tổng thể vẫn giống nhau
    • Tệ hơn nữa là nó còn hiển thị “100% uptime” cho cả giai đoạn dịch vụ đó chưa hề tồn tại

  • Tôi cũng đã thử vẽ cùng biểu đồ đó bằng Claude cách đây vài tuần
    Tôi từng đoán sẽ có một cú giảm mạnh trước và sau khi Microsoft thâu tóm, nhưng thực tế là từ rất lâu rồi đã tồn tại một mô hình sự cố thất thường
    Câu chuyện rằng trước khi bị thâu tóm thì ổn định hơn nghe khá thú vị, nhưng hồi đó còn chưa có các sản phẩm như Actions
    Với các dịch vụ đã tồn tại (API, Git ops, Pages, v.v.), có lẽ điều này lại được giải thích bằng cải thiện khả năng quan sát

    • Cảm giác như kể từ khi Actions ra mắt, một giai đoạn ác mộng về vận hành và khả dụng đã bắt đầu
      Sau đó các vấn đề lan sang cả những khu vực vốn ổn định như Issues hay PR
    • Cá nhân tôi nghĩ GitHub Actions nên biến mất hẳn
      Git vốn là công cụ được thiết kế để làm tốt một việc, và việc gắn thêm đủ thứ tính năng không cần thiết vào đây là một sai lầm lớn

  • Nếu mọi người đang tìm nguyên nhân, thì bài viết này trên The New Stack có thể là lời giải thích

    • Hoàn toàn đồng ý. Các sự cố Azure của đội tôi và sự cố GitHub gần như xảy ra cùng lúc
      Giờ chuyện này gần như đã thành meme rồi
    • Tuy vậy, tôi nghĩ khó có thể giải thích hơn 6 năm khả dụng thấp chỉ bằng riêng lý do này
      Họ lẽ ra nên test đầy đủ trong môi trường riêng và chuyển sang Azure trong thời gian ngắn hơn

  • Hiện tại chức năng gộp PR không hoạt động
    Có thể kiểm tra trạng thái liên quan tại trang GitHub Status Incident

  • Tôi nhớ trước đây từng thấy trang lỗi unicorn rất thường xuyên
    Có lẽ hồi đó trang trạng thái không được cập nhật thường xuyên

    • Có vẻ unicorn là lỗi chỉ dành cho trang web
      Các dịch vụ như Git API đôi khi hỏng riêng, và trang trạng thái thì thường phản ánh chậm một nhịp

  • Giờ thì có vẻ lịch sử downtime của GitHub còn tệ hơn cả máy chủ cá nhân của tôi
    Trong khi tôi còn thường xuyên reboot hay dừng dịch vụ để thử nghiệm

    • Thế mà chúng ta vẫn cứ trả tiền
      Có vẻ mọi người tin rằng dù chất lượng giảm đi thì mức QoS vẫn được duy trì
    • Ngay cả VPS nhỏ của tôi cũng ổn định hơn GitHub ở mức đo đếm được

  • Tôi không phải người bênh GitHub, nhưng biểu đồ đó bóp méo trục
    Nó chỉ phóng to phần dưới 99.5%, nên trông tệ hơn thực tế rất nhiều

    • Nhưng nếu vẽ từ 0 thì sẽ không thấy được khác biệt giữa dịch vụ tốt và dịch vụ tệ
      SLA doanh nghiệp là 99.9%, còn đáy của biểu đồ lại cho thấy mức downtime cao gấp 5 lần con số đó
      Tức là không phải nó trông tệ, mà là nó thực sự tệ
    • Biểu đồ không phản ánh yếu tố tải (load)
      Cũng cần tính đến việc trước khi Microsoft thâu tóm, số kho lưu trữ cá nhân còn bị giới hạn chỉ một cái
    • Không cần phải vẽ biểu đồ uptime từ 0
      Chỉ hiển thị phạm vi 99% là hợp lý
      Tôi còn thấy thang log mới là quá tay

  • Tôi đang deploy website bằng GitHub Pages, nên đã tìm hiểu riêng về khả dụng của static hosting
    Theo phân tích trên blog này, GH Pages có thành tích khá tốt trong mảng đó
    Tuy vậy, công đầu có lẽ nên thuộc về Fastly CDN