GitHub và "tội ác" đối với phần mềm: Khi sự phình to và AI đánh bay sự ổn định

Khi tôi bắt đầu viết bài này, GitHub một lần nữa lại gặp sự cố. Mặc dù đã có rất nhiều bài viết nói về những khó khăn của GitHub về độ tin cậy, bảo mật và hiệu suất, nhưng chúng mới chỉ chạm đến bề mặt của vấn đề. GitHub đóng vai trò như một tín hiệu cho thấy sự mục nát của hạ tầng không chỉ ở chính nền tảng này mà còn trong thế giới dịch vụ phần mềm nói chung. Là một chuyên gia về hệ thống phân tán hiệu suất cao, tôi có thể đưa ra cái nhìn sâu sắc hơn về vấn đề này so với một phóng viên công nghệ thông thường.

Vấn đề không chỉ là việc dịch vụ thường xuyên bị gián đoạn. Trang trạng thái chính thức của GitHub tuyên bố mức thời gian hoạt động lên tới 99,8%, nhưng bất kỳ ai sử dụng dịch vụ gần đây đều biết con số thực tế hoàn toàn không cao như vậy. Các trang theo dõi trạng thái bên thứ ba như "Missing GitHub Status" đã cho thấy bức tranh thực tế.

Trạng thái thực tế của GitHub thường xuyên gặp sự cố

Lý do từ AI hay do sự tắc trách?

GitHub đã cố gắng xoa dịu người dùng bằng một bản cập nhật về tính sẵn sàng, trong đó đổ lỗi cho sự gia tăng đột biến của "quy trình phát triển dạng tác nhân" (agentic development workflows) kể từ tháng 12/2025. Tuy nhiên, việc sử dụng thụ động trong tuyên bố này là sự ngụy biện. GitHub thuộc sở hữu của Microsoft, công ty đang nhồi nhét AI và "Agents" vào mọi sản phẩm.

GitHub nhồi nhét quá nhiều tính năng AI vào giao diện

Microsoft và GitHub liên tục thúc đẩy người dùng sử dụng các công cụ AI này. Trên trang chủ của một kho lưu trữ (repository) trung bình, có tới bốn cách khác nhau để khởi chạy Copilot chỉ riêng trong góc phần tư phía bên phải màn hình. Việc họ subsidize (trợ cấp) chi phí cho các công cụ này trong nhiều năm để thúc đẩy việc áp dụng thực chất là đang tự trả tiền cho một cuộc tấn công từ chối dịch vụ phân tán (DDoS) chống lại chính mình.

Ưu tiên tính năng gây ảo giác hơn sự ổn định

Microsoft tuyên bố ưu tiên của họ rõ ràng: "tính sẵn sàng trước, sau đó là sức chứa, và cuối cùng là tính năng mới". Đây là một lời nói dối.

Nhật ký thay đổi (changelog) công khai của GitHub trong vòng 30 ngày kể từ khi thông báo cập nhật đó chứa từ "copilot" 59 lần, "agent" 8 lần, nhưng không hề có từ "performance" (hiệu suất) hay "reliability" (độ tin cậy) nào. Vấn đề này không chỉ giới hạn ở GitHub mà còn lan rộng sang VS Code. Trình chỉnh sửa mã phổ biến nhất thế giới này ngày càng tích hợp thêm các tính năng "agent" mới mẻ trong khi các tính năng cơ bản như terminal tích hợp lại bị suy giảm đến mức khó sử dụng.

Sự xuất hiện quá nhiều của các nút AI trên giao diện GitHub

Tôi không mù quáng. Tôi là một con người. Đừng tè vào giày tôi rồi bảo tôi là trời đang mưa.

Phân tích kỹ thuật: Sự phình to của Front-end

Microsoft thừa nhận rằng hệ thống của họ đang gặp khó khăn và cần cải thiện caching, cô lập các dịch vụ quan trọng. Tuy nhiên, gốc rễ của vấn đề nằm ở kiến trúc phần mềm. Để hiểu rõ hơn về năng lực kỹ thuật của GitHub, chúng ta hãy xem xét mã nguồn front-end của họ so với các đối thủ như GitLab và Codeberg.

Hầu hết các trang front-end của GitHub và các đối thủ về cơ bản là danh sách các liên kết với một số yếu tố UX nhỏ. Chúng nên có thể chạy rẻ và dễ dàng trên bất kỳ máy tính hoặc điện thoại nào. Trên thực tế, GitHub từng có thể làm được điều này.

Tuy nhiên, các thí nghiệm cho thấy GitHub đang sử dụng khối lượng tài nguyên khổng lồ không tương xứng với nhiệm vụ:

• Quá nhiều mã: Có nhiều mã được kéo xuống để hiển thị một kho lưu trữ trống (540K) so với tổng số dòng mã để xây dựng game DOOM (35K) hay toàn bộ hệ điều hành MS-DOS 4.0 (332K dòng).
• Quá nhiều tệp: GitHub chia nhỏ mã JavaScript của mình thành hàng trăm tệp, làm tăng chi phí cho từng yêu cầu HTTP.
• RAM lãng phí: GitHub sử dụng lượng RAM quá mức cần thiết. Một trang vấn đề đơn giản có thể tốn tới 148MB RAM chỉ để hiển thị văn bản và một vài liên kết. Đây là mức lãng phí kinh khủng so với khả năng xử lý của các máy-console game đời cũ như PlayStation 2 hay Nintendo Wii.

So sánh hiệu suất

Khi so sánh với các đối thủ:

• GitLab: Cũng đang gặp khó khăn, kéo xuống quá nhiều tài nguyên và sử dụng kém hiệu quả với một khối mã 3MB mất 255 mili-giây chỉ để phân tích cú pháp.
• Codeberg/Forgejo: Một nền tảng trẻ triển vọng nắm bắt tốt các nguyên tắc cơ bản nhưng thiếu kinh nghiệm và không hỗ trợ nén dữ liệu.
• GitHub: Rõ ràng là sinh viên đang dùng LLM để làm bài tập về nhà. Công cụ PageSpeed cho thấy 528KB JavaScript và CSS hoàn toàn không được sử dụng.

Biểu đồ dưới đây cho thấy sự so sánh về kích thước mã nguồn giữa các nền tảng (trục Y bị cắt bớt che mất con số cụ thể, nhưng sự chênh lệch là rõ rệt):

So sánh kích thước mã nguồn giữa GitHub và các đối thủ

Tải trang mất 22 giây chỉ để xem một trang trống là một trò đùa sick. Ngay cả với máy tính xách tay nhanh và kết nối cáp quang tốc độ cao, nó vẫn mất hơn một giây để kho lưu trữ có thể sử dụng được.

Kết luận: Tội ác đối với phần mềm

Thuật ngữ phổ biến cho những gì đang xảy ra với GitHub và các sản phẩm hạ tầng phần mềm khác là "enshittification" (quá trình mục nát). Tuy nhiên, vấn đề tại GitHub còn tệ hơn thế. Nó giống như một dạng tự tử chậm để dỗ dành những ảo tưởng của các nhà điều hành và nhà đầu tư.

Rõ ràng là các tập đoàn lớn đơn giản là không thể tin tưởng được để quản lý hạ tầng phần mềm. Chúng ta đang sống trong một thế giới ngập trong phần mềm và chúng ta đang chết đuối trong nó. Các dịch vụ được xây dựng và duy trì bởi những công ty giàu có nhất thế giới với hàng ngũ kỹ sư được trả lương cao lại rõ ràng là những thứ rác rưởi run rẩy, dễ dàng bị vượt qua bởi các dự án cá nhân của các nhóm nhỏ tình nguyện viên.

Việc lãng phí và kém cỏi của GitHub không chỉ là một sản phẩm tồi, đó là một tội ác đối với phần mềm. Chúng ta đã nâng đỡ một nhóm người thiếu năng lực cơ bản hoặc liêm minh nghề nghiệp lên một vị thế cao. Chúng ta không chấp nhận Microsoft đổ hàng ngàn tấn hóa chất vào nguồn nước uống của mình, nhưng lại chấp nhận điều đó trong hạ tầng internet của chúng ta.

Tôi yêu phần mềm. Sức mạnh của phần mềm - suy nghĩ về một vấn đề và giải quyết nó hoàn hảo mãi mãi - là một món quà tuyệt vời. Nhưng sự lãng phí đáng xấu hổ của GitHub và các dịch vụ tương tự đang làm lu mờ đi vẻ đẹp đó.