Số ngày không có sự cố GitHub

• Days Without GitHub Incidents là một trang hiển thị số ngày đã trôi qua mà không có incident nào của GitHub
• Hiện tại, khu vực số ngày chỉ hiển thị ... days, nên không thể xác nhận số ngày cụ thể
• High Score được hiển thị là 2026
• Các chỉ số cốt lõi có thể xác nhận trên trang là số ngày hiện tại và High Score
• Số ngày hiện tại không hiển thị bằng số mà ở dạng placeholder

[GN⁺]

Ý kiến trên Hacker News

• Gần đây tôi đã chuyển tất cả dự án sang instance Forgejo tự host, và đến giờ khá hài lòng. Nó cũng chạy nhanh
  Nếu đang tìm một lựa chọn thay thế GitHub thì rất đáng để xem thử, vì vẫn có các phương án khác

  • Dù giờ không còn thịnh hành, Phabricator cũng xứng đáng được nhắc đến như một lựa chọn thay thế GitHub có thể tự host
    Thậm chí giao diện “cũ” của nó giờ lại có cảm giác là một điểm cộng, vì nhiều thứ khác hiện nay quá tệ
  • Tôi luôn có cảm giác không thích GitHub, nhưng git thì đã gây ấn tượng với tôi ngay từ khi mới biết đến
    Tôi đã chuyển các dự án cá nhân từ một instance Gitea cũ sang Forgejo và rất hài lòng
  • Gitea thì sao?

• Tôi không nghĩ gộp cả một nền tảng thành một con số duy nhất là công bằng. Nó giống như cộng dồn toàn bộ AWS vào một con số vậy

  • Ngược lại, khi vận hành một hệ thống triển khai có độ phức tạp nhất định, bạn rất dễ bị chôn vùi trong các dashboard về CPU, bộ nhớ, I/O, chỉ số ứng dụng, số người đăng ký, người dùng/phiên hoạt động
    Vì vậy, nghĩ cách biểu diễn trạng thái tổng thể của hệ thống bằng một con số duy nhất là điều hữu ích. Ví dụ có thể lấy số phiên người dùng hoạt động chia cho số kết nối cơ sở dữ liệu rồi hiệu chỉnh theo dung lượng bộ nhớ
    Nếu đó là một con số một chữ số, bạn sẽ quen với khoảng giá trị bình thường của nó và có thể luôn đặt nó ở nơi dễ thấy. Nó không cho biết chi tiết, nhưng khi giá trị thay đổi thì bạn có thể đi xem các chỉ số cụ thể, nên như một dạng viết tắt để kiểm tra cơ bản kiểu “mọi thứ có ổn không?” thì nó có thể hoạt động tốt
  • Nếu tách nhỏ trang trạng thái như hiện nay, theo dõi riêng sự cố git push và git pull, mà điều đó chỉ đủ để trở thành một câu đùa có phần cường điệu, thì đó gần như là đánh lạc hướng và thổi phồng SLA, không nên chấp nhận
    Có những mảng cốt lõi mà hầu như ai cũng dùng như Git, issue, pull request, Actions, và chỉ cần một trong số đó hỏng là coi như site đã hỏng. Trang trạng thái phải cho thấy chuyện đó xảy ra thường xuyên đến mức nào
  • Đây rõ ràng là một trang meme, và con số càng thấp thì meme càng buồn cười
    Người thực sự cần thông tin chính xác sẽ vào trang trạng thái chính thức
  • Chỉ riêng S3, EC2, EKS và RDB mà có mức uptime giống toàn bộ GitHub hiện tại thì mọi người đã biết hết rồi
    Việc wiki của repo, thống kê commit hay gist gặp trục trặc thì không quá quan trọng. Điều quan trọng là tổ hợp các dịch vụ được dùng cùng nhau và phụ thuộc lẫn nhau như PR, Actions, Discussions
    Ngay cả khi tạo một tỷ lệ phần trăm duy nhất cho từng thành phần của hai hệ thống thì GitHub vẫn sẽ lép vế. Có thể số ngày không sự cố sẽ nhiều hơn đôi chút, nhưng đây không phải so sánh đơn giản
  • Từ góc nhìn người dùng thì cách tính này hợp lý. Nhưng từ phía MSFT hay GitHub, đây là một chỉ số khá đáng xấu hổ
    Họ hẳn muốn người dùng sử dụng toàn bộ tính năng của nền tảng và tạo ra sự phụ thuộc mạnh, nhưng nếu một phần nào đó cứ liên tục hỏng thì người dùng khó mà có đủ tự tin để dùng thêm nhiều tính năng hơn
    Càng dùng nhiều thì xác suất một thứ trong số đó gặp sự cố càng cao, nhưng có vẻ với các công ty kiểu này thì độ ổn định giờ không còn là mục tiêu nữa

• Với chúng tôi thì đây là vấn đề thực sự về tính liên tục kinh doanh. Dù đang bị ràng buộc ở mức nào đó với GitHub Enterprise, nếu tình trạng này tiếp diễn thì có lẽ chúng tôi sẽ phải chuyển từ cloud sang on-premise

  • Nếu đi theo hướng đó thì nên cache toàn bộ Actions ở local. Không làm vậy thì cũng chẳng cải thiện được bao nhiêu

• Hiện tôi đang thiết lập Knot tự host để dùng trên tangled.org
  Lý do chính là AtProto rất hay và việc tự host cũng thú vị, nhưng còn vì tôi muốn đi theo hướng tự sở hữu hạ tầng đang host dự án của mình
  Hệ thống Knot của Tangled cho tôi cảm giác như một lớp trừu tượng rất mạnh ở điểm này. Dữ liệu được host trong AtProto Repository, còn việc host và quản lý AtProto Application dùng để hiển thị dữ liệu đó ra thế giới có thể giao cho bên thứ ba
  Ngay cả khi Tangled biến mất, tôi vẫn có thể mang đăng nhập AtProto của mình sang nền tảng khác và trỏ nó tới Knot của tôi, còn cấu hình host vẫn giữ nguyên. Điều đó tiện hơn rất nhiều so với việc tự host cả một web app bị cô lập ở một góc Internet

• Ở đây có khá nhiều lời bào chữa cho GitHub. Việc bào chữa cho một công ty trị giá hàng chục tỷ USD vốn đã hơi kỳ quặc, nhất là khi đó lại là công ty đang nắm phần áp đảo của phần mềm mã nguồn mở
  Có thể là do thiện cảm. Nhưng việc muốn tham gia vào một dự án mình yêu thích mà phải chấp nhận chính trị nội bộ và cách làm việc của một công ty lớn luôn là viên thuốc khó nuốt. Tôi không thấy mình mắc nợ GitHub
  Đặc biệt là khi họ còn không giữ được phần cam kết của mình trong thỏa thuận. Họ gần như được quyền truy cập tự do vào kho phần mềm của toàn thế giới để đổi lấy một đống tín dụng Azure trị giá khổng lồ

  • Nếu đảo ngược câu hỏi lại, thì lý do gì để phản đối GitHub đến mức cho rằng những con người đồng nghiệp đang cố gắng giữ cho hệ thống vận hành lại không xứng đáng nhận được tối thiểu sự tử tế và tôn trọng?
    Chẳng lẽ không thể tách bạch doanh nghiệp với những con người đang làm việc chăm chỉ phía sau nó sao?
    Họ đâu phải không biết rằng có những người như chúng ta đang phụ thuộc vào họ. Họ biết dịch vụ của mình là “tín hiệu mời quay số” của năng lực phát triển phần mềm toàn cầu, và họ rất nhạy cảm với tác động đó
    #hugops đâu rồi? Chỉ vì họ làm việc cho một công ty bạn không thích mà điều đó lập tức biến mất sao?
  • Chính xác hơn thì đây là bào chữa cho Microsoft, một công ty trị giá hàng nghìn tỷ USD
  • Tôi nghĩ còn tùy bạn có trả tiền để dùng hay không. Nếu có trả tiền thì hoàn toàn có quyền kỳ vọng mạnh và yêu cầu trách nhiệm
    Nếu đang dùng dịch vụ miễn phí thì việc bực bội cũng hợp lý, nhưng đồng thời cũng là nhận đúng với những gì mình đã trả
  • Điều đáng ngạc nhiên là nhận thức về GitHub sau vụ mua lại dường như không thay đổi nhiều
    Kết hợp với WSL, với nhiều người điều đó đã giúp cân bằng lại và khiến Microsoft quay về phía “cứ thử tin thêm lần nữa”
    Chuyện lần này không chỉ làm xói mòn thiện cảm tích lũy bấy lâu mà còn khiến các tin xấu đột nhiên trở nên dễ thấy hơn và khó bỏ qua hơn
  • Hai nhóm hay sống chết bảo vệ các công ty hàng chục tỷ USD là người dùng HN và fan Nintendo

• Người ta nói số commit trên GitHub đã tăng 14 lần so với cùng kỳ năm trước

  • Có phải các AI agent đang spam đẩy lên không?
  • Là commit hay là push? Xét từ góc độ đo tải, số commit không phải là một thước đo quá có ý nghĩa
  • 14 lần là mức tăng điên rồ. Nhất là khi chất lượng và số lượng phần mềm ngoài đời thực gần như chẳng thay đổi mấy
    Người ta có thể hy vọng năng lực lập trình kiểu agent mới này sẽ tạo ra giá trị thực và cải thiện chất lượng. Nhưng những gì thấy được lại là enshittification và trì trệ. Rốt cuộc người ta đang làm gì với ngần ấy token vậy?
  • Số commit trên GitHub tăng 14 lần so với cùng kỳ năm trước thì sao chứ?
    Nếu Microsoft còn không scale nổi thì ai scale nổi nữa? Nếu chưa thể cung cấp dịch vụ thì phải ngừng bán cho đến khi làm được
    Đây là màn lặp lại của thảm họa tín hiệu bận dial-up AOL giữa thập niên 90. Chỉ khác là lần này thay vì nổi giận, mọi người lại đi bào chữa cho một công ty nghìn tỷ tội nghiệp đang bị vất vả
  • Tôi thật sự khó hiểu với lập luận rằng đây là do commit AI và hoàn toàn chỉ là vấn đề lưu lượng
    Một mức tăng một chữ số, tức mức tăng tải kiểu 14 lần, không đáng ra phải dẫn đến mức sự cố thế này
    Nếu so những gì GitHub làm và thông lượng của họ với các công ty mạng xã hội, thanh toán, nền tảng video... thì cách giải thích rằng đây chỉ là vấn đề tải đơn thuần có vẻ không đúng
    Nó giống việc một nền tảng vốn đã có vấn đề căn bản nay bị tải tăng thêm chồng lên và khuếch đại hơn nhiều

• Lý do trò đùa này hiệu quả là vì mọi người đều âm thầm chấp nhận một rủi ro tập trung đáng kể để đổi lấy sự tiện lợi

• https://repo.autonoma.ca/treetrek
  Đây là phần mềm miễn phí mã nguồn mở tôi viết, một trình xem Git thô thuần PHP với tính năng tối thiểu, không cache, không dependency, không xác thực hay phân quyền
  Tôi làm nó vì GitList từng làm nổ tung dung lượng đĩa và bộ nhớ trên shared hosting do lỗi cache, và tôi muốn hợp nhất các repo GitHub, BitBucket và GitLab
  Tự host và không bị phụ thuộc vào sự thất thường của bên thứ ba là một điều đáng giá

• Chính ứng dụng này, vốn nhiều khả năng cũng chỉ là một ứng dụng vibe coding, có lẽ cũng góp phần vào làn sóng ứng dụng vibe coding đang kéo GitHub đi xuống
  Thật tội cho các nhân viên GitHub đang cố giữ con tàu chìm nổi lên bằng mọi giá, còn Microsoft thì có vẻ đang làm mọi thứ có thể để tự đánh chìm con tàu của mình