Vào ngày 9 tháng 2, lúc nửa đêm giờ Bắc Kinh, hàng chục triệu nhà phát triển trên toàn cầu mở GitHub và nhìn thấy cùng một trang.
Không phải lỗi 404, mà là một điều đáng lo ngại hơn 404 – đó là thanh cảnh báo màu vàng khiến tất cả kỹ sư lạnh gáy, cùng với hàng loạt đèn chỉ báo từ xanh chuyển sang đỏ trên trang trạng thái.
github.com sập.
API sập.
GitHub Actions sập.
Thao tác Git sập – ngay cả Copilot cũng không thoát khỏi.
Đêm đó, các pipeline CI/CD của một số người đã dừng lại ở giai đoạn quan trọng nhất, quá trình triển khai tự động của một số người khác bị treo giữa chừng, và có người đang chờ một Pull Request mãi không thể merge – phía sau là một tính năng đang chờ lên môi trường production, chờ đợi những người dùng thực sự.
Sau sự kiện, GitHub đã công bố báo cáo sự cố. Nguyên nhân gốc rễ, theo ngôn ngữ kỹ thuật, là "quá tải của một cụm cơ sở dữ liệu lõi chịu trách nhiệm xác thực và quản lý người dùng". Nhưng đằng sau những từ này ẩn chứa một chuỗi kích hoạt đáng báo động –
Hai ngày trước đó, để có thể gửi nhanh một mô hình mới cho người dùng, nhóm kỹ sư đã thay đổi thời gian làm mới của một "bộ nhớ đệm cài đặt người dùng" từ 12 giờ xuống còn 2 giờ. Chỉ là một con số cấu hình thay đổi.
Kết quả, lượng công việc ghi lại bộ nhớ đệm vốn được phân bổ trong 12 giờ đã bị nén vào 2 giờ, tạo nên một "cơn bão ghi lại bộ nhớ đệm" dày đặc, hàng đợi tác vụ bất đồng bộ bị bùng nổ ngay lập tức, các thành phần cơ sở hạ tầng chia sẻ sụp đổ, phản ứng dây chuyền lan rộng đến dịch vụ chịu trách nhiệm cho các thao tác Git qua HTTPS, cuối cùng dẫn đến cạn kiệt kết nối toàn bộ nền tảng.
Một con số, từ 12 đổi thành 2.
GitHub, đã bị chính một cấu hình do họ thay đổi làm thủng lỗ.
Nhưng nếu bạn chỉ nhìn thấy một thay đổi cấu hình này, bạn có lẽ đã bỏ lỡ phần quan trọng nhất của câu chuyện này.
01 Không phải một tai nạn, là mười tai nạn
Sự cố ngày 9/2 không phải là một sự kiện riêng lẻ.
Trên thực tế, ba tháng đầu năm 2026, GitHub đã trải qua ít nhất 8 sự cố nghiêm trọng. Riêng tháng 2 đã có 37 bản ghi sự cố lớn nhỏ. CTO của GitHub là Vlad Fedorov sau này đã thừa nhận trong blog rằng, trong hai tháng này, GitHub đã không duy trì được cam kết "ba số 9" – khả dụng 99,9% – đối với khách hàng doanh nghiệp.
Mở hồ sơ sự cố của hai tháng này ra, bạn sẽ thấy một quy luật đặc biệt: mỗi lần sự cố, trông đều do những nguyên nhân khác nhau.
Ngày 2/2: Nhà cung cấp tính toán Azure gặp sự cố, GitHub Actions ngừng hoạt động gần 4 giờ, Copilot code agent, CodeQL, Dependabot đều bị ảnh hưởng.
Ngày 9/2: Bão ghi lại bộ nhớ đệm, quá tải cơ sở dữ liệu xác thực.
Ngày 5/3: Sự cố cụm Redis, 95% luồng công việc của GitHub Actions không thể khởi động trong 5 phút, độ trễ trung bình 30 phút.
Ngày 18/3: Độ trễ Webhook tăng vọt lên 32 lần mức bình thường.
Mỗi lần trông đều là "bất ngờ", mỗi lần nguyên nhân trực tiếp lại khác nhau. Nhưng lời giải thích của Fedorov đã xâu chuỗi chúng thành cùng một câu chuyện. Ông nói, đằng sau những sự cố này có ba nguyên nhân cấu trúc chung: "tăng trưởng tải nhanh chóng, sự kết hợp chặt chẽ giữa các dịch vụ dẫn đến lan truyền sự cố cục bộ, và hệ thống thiếu khả năng bảo vệ lưu lượng truy cập đối với các client bất thường."
Nói theo ngôn ngữ của kỹ sư, nền móng của GitHub, đã bắt đầu xuất hiện vết nứt dưới áp lực của tải mới.
Và "tải mới" này, có một cái tên cụ thể.
02 2,75 Tỷ Commit Mỗi Tuần
Dữ liệu chính
Tổng số commit năm 2025: khoảng 1 tỷ
Số lượng commit hàng tuần năm 2026: 2,75 tỷ
Theo tốc độ này, dự kiến cả năm 2026: 14 tỷ (tăng trưởng 14 lần)
Lượng tính toán GitHub Actions: 2023: 500 triệu phút/tuần → 2025: 1 tỷ → Đầu 2026 một tuần cụ thể: 2,1 tỷ phút
Nếu bạn là kỹ sư cơ sở hạ tầng của GitHub, việc so sánh bảng theo dõi giám sát giữa năm 2025 và 2026, có lẽ sẽ khiến bạn sửng sốt.
Cả năm 2025, GitHub xử lý khoảng 1 tỷ commit. Con số này bản thân đã rất lớn, là kết quả tích lũy nhiều năm của nền tảng GitHub. Nhưng đến năm 2026, số commit mỗi tuần đã đạt 2,75 tỷ. Tính toán một chút – nếu đi hết năm với tốc độ này, tổng số commit năm 2026 sẽ gần 14 tỷ, gấp đúng 14 lần tổng số của cả năm 2025.
Đây không phải là một đường cong tăng trưởng trơn tru, mà là một dốc đứng. Sự thay đổi về lượng tính toán GitHub Actions càng thể hiện rõ hơn vấn đề: năm 2023 tiêu thụ 500 triệu phút mỗi tuần, năm 2025 tăng gấp đôi lên 1 tỷ, và sau đó vào một tuần cụ thể đầu năm 2026, đã bùng nổ lên 2,1 tỷ phút.
Thứ gì đang commit code điên cuồng như vậy?
Không phải nhà phát triển con người.
Dữ liệu của GitHub cho thấy, AI Agent đang trở thành "người dùng" hoạt động tích cực nhất trên nền tảng này. Chỉ riêng công cụ Claude Code, hiện đang đóng góp 4,5% tổng số commit trong tất cả các kho lưu trữ công khai của GitHub. 2,6 triệu commit mỗi tuần, trong khi vào cuối tháng 9 năm 2025, con số này chỉ là 100.000 – tăng 25 lần trong ba tháng.
Số lượng PR do AI Agent tạo ra cũng đang bùng nổ. Tháng 9 năm 2025, PR do AI tạo ra là khoảng 4 triệu mỗi tháng, đến tháng 3 năm 2026, con số này nhảy vọt lên 17 triệu – hơn bốn lần, trong nửa năm.
Có một hình ảnh có thể giúp bạn hiểu điều này có nghĩa là gì.
Trước đây, "người dùng" của GitHub chủ yếu là các lập trình viên con người. Họ làm việc ban ngày, ngủ ban đêm, nghỉ cuối tuần, mỗi lần commit sẽ suy nghĩ, do dự, tốc độ tay có giới hạn. Tải của hệ thống đi theo nhịp sinh hoạt của con người, có cao điểm và thấp điểm, có thể dự đoán.
Bây giờ, ngày càng nhiều "người dùng" là AI Agent. Chúng không ngủ, không nghỉ, không do dự, một nhiệm vụ có thể đồng thời mở nhiều Agent chạy song song, mỗi Agent mỗi giờ commit, dễ dàng vượt quá khối lượng công việc một tuần của một kỹ sư thực sự. Quan trọng hơn, chúng không chỉ đang commit code, mà còn liên tục tạo kho lưu trữ mới – coi kho lưu trữ như "sản phẩm đầu ra" của quy trình làm việc, thay vì "không gian làm việc" của con người.
Các kỹ sư cơ sở hạ tầng của GitHub, giờ đây không phải đối mặt với một vấn đề cùng loại nhưng có lưu lượng lớn hơn, mà là một vấn đề có tính chất hoàn toàn khác.
03 Tiền của Copilot Không Đủ Đốt Nữa Rồi
Sự cố thường xuyên chỉ là một mặt của vấn đề, GitHub còn có một rắc rối khác đau đầu hơn – khi tính toán sổ sách thì phát hiện bị lỗ.
Logic định giá ban đầu của Copilot, được xây dựng trên một giả định hợp lý: người dùng chủ yếu sử dụng kiểu "hỗ trợ hoàn thiện", mỗi lần tương tác là ngắn, khối lượng tính toán có thể dự đoán được. Bản cá nhân 10 đô la mỗi tháng, bản thương mại 19 đô la mỗi tháng, tính phí theo chỗ, mô hình này đã hoạt động tốt trong vài năm qua.
Sau đó, Agentic AI xuất hiện.
Quy trình làm việc Agentic và hoàn thiện truyền thống là hai loài khác nhau. Hoàn thiện mã tiêu chuẩn, yêu cầu là tuyến tính, có thể dự đoán, chu kỳ tính toán ngắn. Trong khi một phiên mã hóa Agentic, có thể chạy hàng giờ, đồng thời khởi chạy nhiều luồng song song, thực hiện lập luận nhiều bước, tự sửa lỗi, tái cấu trúc xuyên kho lưu trữ – số lượng token tiêu thụ trong một phiên, dễ dàng vượt quá phí đăng ký cả tháng của một người dùng thông thường.
Hoàn cảnh GitHub đang đối mặt là, một số ít người dùng Agentic nặng, đang sử dụng vài đô la phí hàng tháng để tiêu thụ tài nguyên tính toán tương đương vài trăm đô la.
Đối mặt với tình hình này, phản ứng của GitHub rất trực tiếp – trước hết kiểm soát lưu lượng, sau đó sửa giá.
Đầu năm nay, GitHub đã bắt đầu khởi động hai cơ chế giới hạn lưu lượng song song cho Copilot: giới hạn trên về thời lượng phiên và giới hạn trên về mức sử dụng hàng tuần, cả hai chiều đều được tính theo lượng tiêu thụ token nhân với trọng số tính toán mô hình. Đồng thời, việc đăng ký người dùng mới đã bị tạm dừng đối với một số gói Copilot cá nhân.
Ngày 1 tháng 6, GitHub đã hoàn thành cải cách giá cơ bản hơn: Copilot chuyển đổi hoàn toàn sang tính phí theo mức sử dụng, thay thế phí gói cũ bằng "AI Credits", 1 AI Credit bằng 1 xu, mức sử dụng được tính theo thời gian thực dựa trên lượng tiêu thụ token.
Thời đại tính phí theo chỗ, trước mặt Agentic AI, đã đi đến hồi kết.
Sự chuyển đổi này không chỉ là nỗi phiền muộn của GitHub. Đây là một cuộc khủng hoảng định giá tập thể mà toàn ngành công cụ AI đang trải qua vào năm 2026 – khi AI bắt đầu thay thế con người thực hiện quy trình làm việc hoàn chỉnh, chứ không chỉ "hỗ trợ" con người làm việc, thì tất cả logic đăng ký dựa trên "mỗi người mỗi tháng" đều sẽ thất bại.
04 30 Lần, Không Phải 10 Lần
Trở lại vấn đề cơ sở hạ tầng. GitHub cuối cùng định ứng phó với "tăng trưởng 14 lần" này như thế nào?
Ở đây có một chi tiết, có thể cho thấy mức độ nghiêm trọng của vấn đề:
Cuối tháng 12 năm 2025, quy trình làm việc Agentic đột nhiên bắt đầu tăng tốc. Các kỹ sư của GitHub nhận ra rằng, gấp 10 lần là không đủ. Đến tháng 2 năm 2026, tức là sau lần ngừng hoạt động nghiêm trọng đó, GitHub thông báo cần thiết kế lại kiến trúc theo quy mô gấp 30 lần so với hiện tại.
Không phải mở rộng quy mô, mà là thiết kế lại.
Sự khác biệt giữa hai từ này rất lớn. Mở rộng quy mô là tăng số lượng máy hiện có, thêm bộ nhớ cho cơ sở dữ liệu hiện có – hướng không đổi, chỉ là quy mô lớn hơn. Thiết kế lại có nghĩa là, các giả định kiến trúc hiện tại sẽ thất bại một cách có hệ thống ở quy mô gấp 30 lần, phải suy nghĩ lại từ cấp thấp nhất về cách chia tách dịch vụ, luồng dữ liệu, cách cô lập sự cố.
Các hướng cụ thể GitHub tiết lộ bao gồm, tách rời các dịch vụ quan trọng để ngăn chặn lỗi lan truyền, giới thiệu cơ chế back pressure và khả năng giảm cấp lưu lượng, triển khai máy chủ độc lập cho các dịch vụ nóng, loại bỏ điểm lỗi đơn, và quản lý thay đổi hoàn thiện hơn – tránh các thao tác như "thay đổi TTL bộ nhớ đệm từ 12 giờ xuống 2 giờ" mà không kiểm tra áp lực đầy đủ trước khi đưa lên môi trường thực tế.
Đáng chú ý là, GitHub không đơn độc.
Stripe đã gặp phải vấn đề về việc AI Agent tạo hàng loạt tài khoản, AWS đang xây dựng hệ thống danh tính, hệ thống nhật ký và cơ chế kiểm soát sản xuất chuyên dụng cho Agent. Những hành động này không phải là phòng ngừa, mà là vì trên bảng theo dõi giám sát đã xuất hiện những tín hiệu mà họ buộc phải giải quyết.
GitHub chỉ là nơi đầu tiên bị thủng lỗ – bởi vì nó ở vị trí lõi nhất của chuỗi công cụ AI.
05 Kho Lưu Trữ Code, Đang Trở Thành Ống Xả Của AI
Dừng lại một chút để suy nghĩ về tính chất của toàn bộ sự việc này.
GitHub là gì? Câu trả lời trực quan nhất là, nó là nơi lập trình viên lưu code. Nhưng ở tầng sâu hơn, nó là cơ sở hạ tầng hợp tác phần mềm của con người – bản ghi commit là dấu vết hợp tác, PR là thùng chứa thảo luận, Issues là ý định được lưu giữ, Action là đường ống thực thi. Toàn bộ hệ thống, được thiết kế cho nhịp độ làm việc, cách suy nghĩ và mô hình hợp tác của con người.
AI Agent đã thay đổi tất cả những điều này.
Khi một AI Agent một ngày có thể commit hàng trăm lần code, mỗi lần "commit" đằng sau không có sự suy nghĩ và cân nhắc của con người, chỉ là một bước tiến trong vòng lặp nhiệm vụ – kho lưu trữ code vẫn là "thùng chứa hợp tác" chứ?
Khi công cụ AI tự động tạo kho lưu trữ, tự động tạo PR, tự động chạy CI, tự động merge – nhà phát triển vẫn là chủ thể của quy trình này, hay họ đã thoái hóa thành "người kiểm duyệt" thậm chí "người quan sát"?
CTO GitHub khi mô tả cuộc khủng hoảng này, đã dùng từ "tăng trưởng tải nhanh chóng". Nhưng từ này rất có thể đã đánh giá thấp bản chất vấn đề – đây không chỉ là sự tăng trưởng về lượng, mà là sự biến đổi về chất trong cách sử dụng. Trong mô hình cũ, GitHub là "công cụ của nhà phát triển"; trong mô hình mới, GitHub đang trở thành "ống xả của AI", một đường ống đầu ra của quy trình làm việc tự động.
Điều này có ý nghĩa gì với GitHub, thực ra vẫn chưa có câu trả lời. Mở rộng quy mô 30 lần có thể giải quyết vấn đề lưu lượng, nhưng không giải quyết được việc định nghĩa lại mô hình kinh doanh, cũng không giải quyết được vấn đề nhận dạng "ai là người dùng thực sự của tôi".
Gần đây có một hiện tượng khá hàm ý: GitHub sau khi ngừng hoạt động đã mở rất nhiều blog kỹ thuật, mô tả rất chi tiết nguyên nhân gốc rễ của từng sự cố, đạt đến mức độ minh bạch gần như gây bất ngờ. Một số người cho rằng đây là GitHub đang chủ động xây dựng niềm tin, một số khác cho rằng điều này là đổi lấy sự kiên nhẫn của cộng đồng nhà phát triển bằng tính minh bạch – bởi vì trong giai đoạn tái cấu trúc sắp tới, sẽ còn có nhiều bất ổn hơn nữa.
Một nền tảng, sau khi bị chính thành công của mình làm thủng lỗ, cần phải tự tháo rời ra và xây dựng lại – và bản thân quá trình này, cũng là một bài kiểm tra xem có thể chịu đựng được hay không.
Đêm ngày 9 tháng 2 đó, người kỹ sư đang chờ merge PR kia, cuối cùng có lẽ cũng đã chờ được đèn xanh. Nhưng anh ta có lẽ không nhận ra rằng, lần ngừng hoạt động khiến anh phải chờ đợi đó, không phải là một tai nạn bất ngờ của GitHub, mà là một âm thanh báo hiệu toàn ngành công nghiệp phát triển phần mềm bước vào một kỷ nguyên mới.
Bài viết từ tài khoản công chúng WeChat "Công viên cực khách" (ID: geekpark), tác giả: Vũ Hàng Viên






