GitHub tái kiến trúc hạ tầng Git để phục vụ kỷ nguyên phát triển bằng AI agent

Mỗi ngày, hàng triệu lập trình viên trên GitHub xây dựng sản phẩm, đóng góp cho mã nguồn mở và theo đuổi các dự án cá nhân. Kiến trúc của GitHub đã thay đổi dần qua nhiều năm để đáp ứng khối lượng công việc ngày càng lớn. Nhưng giờ đây, sự phát triển phần mềm bằng AI agent đang tạo ra một bước ngoặt kiến trúc mới.

Hạ tầng Git của GitHub cho phát triển quy mô agent

Khi cả lập trình viên lẫn các agent cùng lúc làm việc trong những kho mã nhận hàng triệu commit mỗi ngày, khối lượng công việc này đòi hỏi một kiến trúc Git hoàn toàn khác. GitHub đang xây dựng lại nền tảng Git của mình để đáp ứng điều đó. Brian Celenza, kỹ sư phần mềm chính tại GitHub, đã chia sẻ chi tiết về những thách thức và nguyên tắc thiết kế đằng sau công việc này.

Quy mô đáng kinh ngạc của khối lượng công việc hiện tại

Những khối lượng công việc có lưu lượng cao nhất hiện nay cho thấy quy mô mà GitHub đang nhắm tới. Khoảng cách giữa một kho mã thông thường và những kho mã bận rộn nhất lớn hơn nhiều so với tưởng tượng của phần lớn mọi người.

Kho mã bận rộn nhất trên GitHub đã ghi nhận khoảng một tỷ yêu cầu chỉ trong tháng 8/2026. Tổng hoạt động Git trên nền tảng cũng tăng trưởng chóng mặt: từ tháng 9/2025 đến tháng 8/2026, con số này đã tăng hơn gấp đôi, từ 218,2 tỷ sự kiện mỗi tháng lên 473,3 tỷ.

Chỉ riêng trong tháng 9, lập trình viên và agent đã thực hiện 7,38 tỷ commit trên GitHub, gấp hơn năm lần so với một năm trước đó.

Những kho mã ở đỉnh của đường cong này cho thấy diện mạo của phát triển bằng agent ở mức tiên tiến: các đội kỹ thuật lớn vận hành pipeline CI bận rộn song song với đội quân agent ngày càng đông đảo.

Những thách thức kiến trúc cần giải quyết

Việc xây dựng cho quy mô này đồng nghĩa với việc phải đối mặt với nhiều vấn đề kiến trúc then chốt.

Độ trễ mỗi commit trở thành điểm nghẽn với từng agent. Một agent hoạt động trong vòng lặp chặt chẽ sẽ commit hoặc tạo checkpoint sau gần như mỗi hành động. Tốc độ của nó bị giới hạn bởi việc một lần push hoàn tất nhanh đến đâu, nên độ trễ mà con người không hề nhận ra lại trở thành yếu tố giới hạn.

Nhu cầu thông lượng ghi tăng theo cấp số nhân. Số lần push tăng 4,9 lần so với năm trước, từ 0,69 tỷ lên 3,35 tỷ mỗi tháng. Hàng nghìn agent làm việc trên các nhánh riêng trong cùng một kho mã tạo ra tốc độ ghi liên tục, dồn về một điểm duy nhất trong kiến trúc.

Các thao tác merge tranh chấp trên một reference. Phát triển dựa trên nhánh chính (trunk-based), các đợt phát hành và hàng đợi merge đều dồn công việc vào một ref duy nhất phải hấp thụ mọi thao tác merge. Số lượt merge pull request trên GitHub đã tăng gần gấp bốn lần so với năm trước.

Mỗi lần push nhân lên thành hàng nghìn lượt đọc. CI và quét mã bảo mật clone hoặc fetch cùng một đỉnh nhánh hàng nghìn lần mỗi phút, và sự lan tỏa đó phải diễn ra với chi phí thấp. Chỉ riêng GitHub Actions đã chạy 3,26 tỷ lần trong tháng 9, gấp hơn bốn lần một năm trước.

Các thao tác trên kho mã phải luôn nhanh. Để giữ tốc độ, hệ thống liên tục nén dữ liệu kho mã và dọn dẹp các đối tượng không còn cần thiết. Mỗi lần ghi mới lại tăng thêm khối lượng công việc này, và chi phí tích lũy khi khối lượng leo thang.

Đó là lý do vì sao clone nhanh chỉ giải quyết được một phần vấn đề. Đọc tương đối dễ mở rộng: thêm cache, thêm bản sao và phục vụ cùng lượng dữ liệu cho nhiều client hơn. Nhưng ghi thì khó hơn nhiều. Mỗi lần push phải được lưu trữ bền vững và hiển thị nhất quán trước khi agent hay tác vụ CI tiếp theo có thể xây dựng dựa trên nó.

Giới hạn của kiến trúc hiện tại

Kiến trúc hiện tại đã phục vụ lập trình viên tốt trong nhiều năm. Mỗi kho mã được lưu trữ bởi hệ thống có tên Spokes, giữ bản sao đầy đủ trên ổ đĩa cục bộ của nhiều fileserver, mặc định là năm máy. Những ổ đĩa nhanh này cho phép các thao tác Git đọc dữ liệu gốc với độ trễ thấp, đồng thời các bản sao thừa cung cấp khả năng dự phòng và phân tải lượt đọc.

Tuy nhiên, chính cơ chế dùng để đảm bảo độ bền vững cũng là cơ chế dùng để mở rộng quy mô. Các bản sao trên ổ đĩa là nguồn chân lý, nên thêm dung lượng đọc đồng nghĩa với việc thêm một bản sao bền vững. Mỗi bản sao đều tham gia vào mọi lần ghi, vì vậy một lần push chỉ nhanh bằng bản sao chậm nhất trong nhóm.

Hệ quả ròng là: thêm bản sao để hấp thụ tải đọc lại khiến việc ghi chậm đi. Với phần lớn kho mã, sự đánh đổi này chấp nhận được. Nhưng ở mức hoạt động cao nhất, nó trở thành giới hạn trần: thêm bản sao đọc làm tăng chi phí cho ghi, mất một bản sao làm giảm dung lượng đọc, và mất đủ số bản sao sẽ khiến việc ghi dừng hoàn toàn.

Nguyên tắc thiết kế cho kiến trúc mới

GitHub đang xây dựng lại hạ tầng trong khi nền tảng vẫn vận hành liên tục, không có cửa sổ bảo trì nào để mã nguồn của cả thế giới ngừng dịch chuyển. Mục tiêu là xây dựng cho những khối lượng công việc khắt khe nhất, qua đó nâng mặt bằng chất lượng cho tất cả mọi người.

Ba nguyên tắc chỉ đạo được đưa ra:

• Xây dựng trên những quy trình lập trình viên đã tin tưởng. Các nhóm dựa vào branching, review, merge và lịch sử để xây dựng, phát hành và quản trị phần mềm ở quy mô lớn. Hạ tầng mới được thiết kế để hỗ trợ chính những quy trình đó ở khối lượng hoạt động cao hơn nhiều.
• Đặt độ tin cậy lên hàng đầu. Niềm tin vào nền tảng là điều cho phép một tổ chức kỹ thuật xây dựng tự động hóa, phát hành theo lịch trình, tuân thủ các nghĩa vụ pháp lý và hiểu rõ phần mềm mình tạo ra.
• Giữ quyền kiểm soát mã nguồn trong tay con người. Khi agent đảm nhận nhiều công việc hơn, những người sở hữu mã nguồn vẫn có thể review, hiểu và phê duyệt nó.

Cách tiếp cận: giảm thiểu phối hợp, tách biệt lưu trữ và tính toán

Cách tiếp cận của GitHub xoay quanh các nguyên lý thiết kế hệ phân tán cốt lõi, áp dụng cho tính đồng thời và quy mô của phát triển phần mềm bằng agent.

Giảm thiểu phối hợp

Một kho mã nhận nhiều push phải chấp nhận và công bố cập nhật nhanh chóng. Việc phối hợp có giá trị khi bảo vệ tính đúng đắn, nhưng quá nhiều sẽ giới hạn thông lượng ghi.

• Chỉ phối hợp những gì cần đồng thuận. Phần thực sự cần đồng thuận trong một lần push chính là việc cập nhật reference. Lưu trữ đối tượng, xác thực kết nối và quét bí mật là công việc nhiều hơn nhưng phần lớn có thể diễn ra song song với các lần ghi khác. Điều này thu hẹp đường tới hạn của một lần push xuống bước nhỏ cần phối hợp, nên phần việc còn lại không còn làm chậm thời điểm xác nhận.
• Đưa công việc bảo trì ra khỏi đường phục vụ. Nén dữ liệu và thu gom rác là những công việc nặng nhất của một kho mã, hiện chạy trên cùng máy chủ đang trả lời các yêu cầu Git trực tiếp. Trong kiến trúc mới, các worker riêng biệt xử lý bảo trì trực tiếp trên lớp lưu trữ bền vững, giúp kho mã bận rộn được tối ưu liên tục trong nền mà không làm chậm push và fetch.

Tách biệt lưu trữ khỏi tính toán

Hiện nay, các bản sao đầy đủ trên ổ đĩa cục bộ vừa đóng vai trò lưu trữ bền vững, vừa là lớp trả lời các yêu cầu Git. Tách hai vai trò này cho phép mở rộng từng phần một cách độc lập.

• Mở rộng lượt đọc mà không cần thêm bản sao bền vững. Dung lượng đọc đến từ các worker nhẹ nhàng lưu cache dữ liệu để phục vụ yêu cầu, còn bản sao có thẩm quyền nằm ở lớp lưu trữ bền vững bên dưới.
• Để mỗi lớp làm một việc. Dữ liệu kho mã có thẩm quyền được lưu trong Azure Blob Storage, vốn đã cung cấp độ bền vững và khả năng sao chép ở quy mô Azure. Lớp tính toán được tối ưu cho thông lượng ở độ trễ thấp nhất.
• Phục hồi nhanh hơn sau sự cố. Khi lưu trữ và tính toán tách rời, mất một worker tính toán gần giống như một lần trượt cache: worker thay thế có thể bắt đầu phục vụ yêu cầu ngay và dần lấp đầy cache từ lớp lưu trữ bền vững.
• Khớp dung lượng với nhu cầu. Worker tính toán có thể thêm hoặc bớt khi lưu lượng thay đổi, thay vì phải dự phòng cho đỉnh tải từ trước. Một kho mã đang bùng nổ hoạt động, như khi phát hành hoặc có đội agent mới tham gia, có thể được cấp thêm dung lượng tạm thời.

Điều gì tiếp theo

GitHub đang xây dựng một kiến trúc hướng tới thông lượng và độ tin cậy cao nhất. Lượt đọc và lượt ghi mở rộng độc lập, hệ thống phục hồi linh hoạt sau sự cố. Trong các bài kiểm thử nội bộ, kiến trúc này đã đạt thông lượng ghi cao hơn tới 35 lần, với dung lượng đọc tự mở rộng theo nhu cầu.

Khi phát triển tự động làm tăng tần suất và tính đồng thời của thay đổi phần mềm, GitHub sẽ tiếp tục phát triển nền tảng mà không đánh đổi khả năng quản trị và kiểm soát mà các đội ngũ dựa vào. Trong bài viết tiếp theo của loạt này, GitHub sẽ đi sâu hơn vào kiến trúc tương lai và hành trình dẫn đến nó.