Sự cố GitHub do lượng truy cập tăng đột biến do AI và lỗi cấu hình

Vào đêm ngày 9 tháng 2 năm nay, theo 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 404, mà còn đáng lo lắng hơn thế—đó là thanh cảnh báo màu vàng khiến mọi kỹ sư cảm thấy lạnh sống lưng, cộng với hàng loạt đèn báo trên trang trạng thái chuyển từ màu xanh sang màu đỏ.

github.com đang gặp sự cố.

API đã ngừng hoạt động.

GitHub Actions đã ngừng hoạt động.

Thao tác Git đã bị lỗi—ngay cả Copilot cũng không thể thoát khỏi.

Đêm đó, có người dòng chảy CI/CD bị đình trệ tại điểm then chốt, có người triển khai tự động bị treo giữa chừng, và có người đang chờ một PR chưa thể hợp nhất—đằng sau là một tính năng đang chờ ra mắt, đang chờ những người dùng thực sự.

Sau sự cố, GitHub đã công bố báo cáo sự cố. Nguyên nhân gốc rễ, nói theo ngôn ngữ kỹ thuật, là “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 bị quá tải”. Nhưng đằng sau những từ ngữ này là một chuỗi kích hoạt đáng sợ—

Hai ngày trước, nhóm kỹ thuật đã thay đổi thời gian làm mới bộ nhớ đệm "cài đặt người dùng" từ 12 giờ thành 2 giờ để nhanh chóng triển khai một mô hình mới cho người dùng. Chỉ là sự thay đổi của một con số cấu hình này.

Kết quả, quá trình ghi lại bộ nhớ đệm vốn được phân tán trong 12 giờ đã bị nén vào chỉ 2 giờ, tạo thành một “bão ghi lại bộ nhớ đệm” dày đặc, làm tràn ngập hàng đợi tác vụ bất đồng bộ, khiến các thành phần hạ tầng chia sẻ sụp đổ, phản ứng dây chuyền lan sang dịch vụ xử lý thao tác HTTPS Git qua proxy, cuối cùng dẫn đến việc hết toàn bộ kết nối trên toàn bộ nền tảng.

Một con số, thay đổi từ 12 thành 2.

GitHub bị hỏng do một cấu hình tự sửa đổi.

But if you only see this one configuration change, you’ve probably missed the most important part of this story.

The incident on February 9 was not an isolated event.

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 Hai đã ghi nhận 37 sự cố lớn nhỏ. Sau đó, CTO của GitHub là Vlad Fedorov đã thừa nhận trên blog rằng trong hai tháng này, GitHub đã không duy trì được mức độ sẵn sàng “ba số chín” 99,9% mà họ đã cam kết với khách hàng doanh nghiệp.

Khi xem lại hồ sơ sự cố trong hai tháng qua, bạn sẽ nhận thấy một quy luật kỳ lạ: mỗi sự cố đều dường như có nguyên nhân khác nhau.

Ngày 2 tháng 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ờ, các đại lý mã hóa Copilot, CodeQL và Dependabot đều bị ảnh hưởng.

February 9: Cache rewrite storm, authentication database overloaded.

Ngày 5 tháng 3: Sự cố cụm Redis, 95% luồng công việc của GitHub Actions không thể khởi động trong vòng 5 phút, độ trễ trung bình 30 phút.

Ngày 18 tháng 3: Độ trễ Webhook tăng lên 32 lần so với mức bình thường.

Mỗi lần dường như đều là “sự cố bất ngờ”, và nguyên nhân trực tiếp của mỗi lần đều khác nhau. Nhưng lời giải thích của Fedorov đã nối kết chúng thành một câu chuyện duy nhất. Ông nói rằng, đằng sau những sự cố này có ba nguyên nhân cấu trúc chung: “sự gia tăng nhanh chóng về tải, sự kết hợp chặt chẽ giữa các dịch vụ khiến sự cố cục bộ lan rộng, và hệ thống thiếu khả năng bảo vệ lưu lượng trước các client bất thường.”

Nói theo cách của các kỹ sư, nền tảng của GitHub đã bắt đầu nứt vỡ dưới áp lực của tải trọng mới.

Và "tải mới" này có một cái tên cụ thể.

Dữ liệu quan trọng

Tổng lượng commit cả năm 2025: khoảng 1 tỷ lần

Số lượng commit trong một tuần năm 2026: 275 triệu

Ở tốc độ này, dự kiến cả năm 2026: 14 tỷ lần (tăng 14 lần so với cùng kỳ năm trước)

Lượng tính toán của GitHub Actions: 500 triệu phút mỗi tuần năm 2023 → 1 tỷ vào năm 2025 → 2,1 tỷ phút trong một tuần đầu năm 2026

Nếu bạn là kỹ sư hạ tầng của GitHub, việc so sánh bảng điều khiển giám sát giữa năm 2025 và 2026 có thể khiến bạn sửng sốt.

Trong cả năm 2025, GitHub đã xử lý khoảng 1 tỷ lần commit mã. Con số này đã rất lớn, là kết quả của nhiều năm tích lũy trên nền tảng GitHub. Nhưng đến năm 2026, số lượng commit trong một tuần đã đạt 275 triệu lần. Tính ra — nếu duy trì tốc độ này trong cả năm, tổng số commit năm 2026 sẽ gần 14 tỷ lần, gấp 14 lần tổng số commit của cả năm 2025.

Đây không phải là một đường cong tăng trưởng mượt mà, mà là một dốc đứng. Sự thay đổi trong lượng tính toán của GitHub Actions càng làm rõ vấn đề này: 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ỷ, rồi vào một tuần đầu năm 2026, trực tiếp nhảy lên 2,1 tỷ phút.

Điều gì đang gửi mã một cách điên cuồng?

Không phải là nhà phát triển con người.

Dữ liệu từ GitHub cho thấy AI Agent đang trở thành “người dùng” sôi động nhất trên nền tảng này. Chỉ riêng công cụ Claude Code hiện đã đóng góp 4,5% tổng số lần gửi mã vào các kho lưu trữ công khai trên GitHub. Con số này đạt 2,6 triệu lần gửi mỗi tuần, trong khi cuối tháng 9 năm 2025, con số này mới chỉ là 100.000 — tăng 25 lần trong ba tháng.

Số lượng PR được mở bởi AI Agent cũng đang bùng nổ. Tháng 9 năm 2025, các PR do AI tạo ra khoảng 4 triệu mỗi tháng, đến tháng 3 năm 2026, con số này đã tăng lên 17 triệu—hơn bốn lần trong vòng sáu tháng.

Có một hình ảnh có thể giúp bạn hiểu điều này có nghĩa gì.

Trước đây, những "người dùng" trên 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 đều suy nghĩ, do dự và tốc độ gõ có giới hạn. Tải hệ thống theo nhịp sinh học của con người, có đỉnh và đáy, có thể dự đoán được.

Hiện nay, 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ự; có thể đồng thời khởi động nhiều Agent song song cho một nhiệm vụ, mỗi Agent có thể nộp lượng công việc vượt xa khối lượng công việc của một kỹ sư thực tế trong một tuần. Quan trọng hơn, chúng không chỉ đang nộp mã, mà còn liên tục tạo ra các kho lưu trữ mới — coi kho lưu trữ là "sản phẩm đầu ra" của quy trình làm việc, chứ không phải là "không gian làm việc" của con người.

Các kỹ sư hạ tầng của GitHub đang đối mặt với một vấn đề hoàn toàn khác biệt, chứ không phải chỉ là một vấn đề tương tự với lưu lượng lớn hơn.

Việc xảy ra 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 khiến người ta đau đầu hơn—khi tính toán thì phát hiện đã lỗ.

Logic định giá ban đầu của Copilot dựa trên một giả định hợp lý: người dùng chủ yếu sử dụng ở chế độ “hỗ trợ hoàn thành”, mỗi tương tác ngắn gọn và lượng tính toán có thể dự đoán được. Phiên bản cá nhân có giá 10 USD/tháng, phiên bản doanh nghiệp có giá 19 USD/tháng, tính theo số lượng người dùng, mô hình này đã hoạt động tốt trong vài năm qua.

Sau đó, Agentic AI đã xuất hiện.

Các luồng làm việc Agentic và việc điền đầy truyền thống là hai loài khác nhau. Việc điền đầy mã tiêu chuẩn có yêu cầu tuyến tính, có thể dự đoán được và chu kỳ tính toán ngắn. Trong khi đó, một phiên mã Agentic có thể chạy vài giờ, đồng thời khởi động nhiều luồng song song, thực hiện suy luận nhiều bước, tự sửa lỗi và tái cấu trúc xuyên kho lưu trữ—một phiên như vậy tiêu tốn số lượng token vượt xa chi phí đăng ký cả tháng của một người dùng thông thường.

GitHub đang đối mặt với tình huống mà một số ít người dùng Agentic nặng đang tiêu tốn tài nguyên tính toán tương đương hàng trăm đô la với chi phí đăng ký chỉ vài đô la mỗi tháng.

Trước tình hình này, phản ứng của GitHub rất trực tiếp—trước tiên kiểm soát lưu lượng, sau đó điều chỉnh giá.

Từ đầu năm nay, GitHub đã triển khai hai cơ chế giới hạn lưu lượng song song cho Copilot: giới hạn thời gian phiên và giới hạn lượng sử dụng hàng tuần, cả hai đều được tính dựa trên số lượng token tiêu thụ nhân với trọng số tính toán của mô hình. Đồng thời, một số gói Copilot cá nhân đã tạm dừng đăng ký người dùng mới.

Ngày 1 tháng 6, GitHub đã hoàn thành cải cách định giá cơ bản hơn: Copilot chuyển hoàn toàn sang mô hình tính phí theo mức sử dụng, thay thế phí gói cũ bằng "AI Credits", 1 AI Credit tương đương 1 xu Mỹ, và mức sử dụng được tính theo thời gian thực dựa trên số token tiêu thụ.

Thời đại tính phí theo ghế đã kết thúc trước sự xuất hiện của Agentic AI.

Sự chuyển đổi này không chỉ là nỗi lo của GitHub. Đó là cuộc khủng hoảng định giá tập thể mà toàn bộ 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 toàn bộ quy trình công việc, chứ không chỉ “hỗ trợ” công việc của con người, mọi mô hình đăng ký dựa trên “mỗi người mỗi tháng” sẽ trở nên vô hiệu.

Quay lại vấn đề cơ sở hạ tầng. GitHub cuối cùng sẽ đối phó với sự gia tăng “14 lần” này như thế nào?

Có một chi tiết cho thấy mức độ nghiêm trọng của vấn đề:

Cuối tháng 12 năm 2025, các luồng làm việc Agentic đột ngột bắt đầu tăng tốc. Các kỹ sư trên GitHub nhận ra rằng 10 lần là chưa đủ. Đến tháng 2 năm 2026, sau sự cố ngừng hoạt động nghiêm trọng, GitHub tuyên bố cần thiết kế lại kiến trúc với quy mô gấp 30 lần so với hiện tại.

Không phải mở rộng, 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ô có nghĩa là tăng số lượng máy chủ hiện có, thêm bộ nhớ cho cơ sở dữ liệu hiện tại — hướng đi không thay đổi, chỉ tăng quy mô. Thiết kế lại có nghĩa là các giả định trong kiến trúc hiện tại sẽ bị phá vỡ hệ thống khi quy mô tăng 30 lần, buộc phải suy nghĩ lại từ nền tảng cách chia nhỏ dịch vụ, luồng dữ liệu và cách cô lập sự cố.

Các hướng cụ thể được tiết lộ trên GitHub bao gồm: tách rời các dịch vụ then chốt để ngăn chặn lỗi lan truyền, triển khai cơ chế backpressure và khả năng giảm 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 lẻ, và quản lý thay đổi tốt hơn—tránh thực hiện các thao tác như “thay đổi TTL bộ nhớ đệm từ 12 giờ xuống 2 giờ” mà không có kiểm thử áp lực đầy đủ.

Đáng chú ý là GitHub không đơn độc.

Stripe đã gặp vấn đề về việc AI Agent tạo tài khoản hàng loạt, AWS đang xây dựng hệ thống xác thực, hệ thống ghi nhật ký và cơ chế kiểm soát sản xuất dành riêng cho Agent. Những hành động này không phải là phòng ngừa trước, mà là phản ứng với các tín hiệu đã xuất hiện trên bảng điều khiển giám sát mà họ buộc phải giải quyết.

GitHub chỉ là cái đầu tiên bị xâm nhập — vì nó nằm ở trung tâm cốt lõi của chuỗi công cụ AI.

Hãy dừng lại và suy nghĩ về bản 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 các lập trình viên lưu mã nguồn. Nhưng sâu hơn nữa, nó là cơ sở hạ tầng cho sự hợp tác phần mềm của con người—các bản ghi commit là dấu vết của sự hợp tác, PR là nơi chứa các cuộc thảo luận, Issues là lưu giữ ý định, và Action là đường ống thực thi. Toàn bộ hệ thống này được thiết kế để phù hợp với nhịp làm việc, cách tư duy và mô hình hợp tác của con người.

AI Agent đã thay đổi tất cả.

Khi một AI Agent có thể gửi mã hàng trăm lần mỗi ngày, và sau mỗi lần “gửi” không có sự suy nghĩ hay cân nhắc của con người, mà chỉ là một bước tiến trong chu trình nhiệm vụ — kho mã vẫn còn là “bộ chứa hợp tác” không?

Khi các công cụ AI tự động tạo kho lưu trữ, tự động mở PR, tự động chạy CI và tự động merge — liệu các nhà phát triển vẫn là chủ thể của quy trình này, hay họ đã suy giảm thành vai trò “người kiểm duyệt” thậm chí là “người quan sát”?

CTO của GitHub khi mô tả cuộc khủng hoảng này đã sử dụng cụm từ “tải tăng trưởng nhanh chóng”. Tuy nhiên, cụm từ này rất có thể đã đánh giá thấp bản chất của vấn đề — đây không chỉ là sự gia tăng về lượng, mà là sự thay đổi về chất trong cách sử dụng. Trong mô hình cũ, GitHub là “công cụ của các 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 các luồng công việc tự động hóa.

Điều này có nghĩa gì đối với GitHub? Hiện vẫn chưa có câu trả lời. Việc mở rộng 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 như không giải quyết được vấn đề danh tính “Ai là người dùng thực sự của tôi?”.

Gần đây, có một hiện tượng khá mang tính biểu tượng: Sau khi xảy ra sự cố ngừng hoạt động, GitHub đã đăng tải một lượng lớn bài viết kỹ thuật, mô tả chi tiết nguyên nhân gốc rễ của từng sự cố, đạt đến mức minh bạch khiến nhiều người bất ngờ. Một số người cho rằng đây là nỗ lực chủ động xây dựng niềm tin của GitHub, trong khi những người khác cho rằng đây là cách họ đổi lấy sự kiên nhẫn từ cộng đồng nhà phát triển – bởi vì giai đoạn tái cấu trúc sắp tới còn sẽ có thêm nhiều sự bất ổn khác.

Một nền tảng, sau khi bị chính thành công của mình xuyên thủng, cần phải tự bóc tách và xây dựng lại—và chính quá trình này cũng là một cuộc kiểm tra xem nó có thể trụ vững hay không.

Đêm ngày 9 tháng 2, kỹ sư đang chờ hợp nhất PR có lẽ cuối cùng cũng đã nhận được tín hiệu xanh. Nhưng anh ấy có thể chưa nhận ra rằng, sự cố gián đoạn khiến anh phải chờ đợi không phải là sự cố ngẫu nhiên của GitHub, mà là một tiếng động báo hiệu sự khởi đầu của một thời đại mới trong ngành phát triển phần mềm.

Bài viết này đến từ tài khoản WeChat “GeekPark” (ID: geekpark), tác giả: Yu Hang Yuan