Git được thiết kế dành cho con người — các tác nhân cần được nâng cấp

Ngành công nghiệp hiện đang chạy đua để xây dựng lại hệ thống quản lý mã nguồn dành cho các agent. Chúng tôi đã trình bày quan điểm của mình tại GitLab Transcend, nhưng hãy nhắc lại vì sao việc xây dựng lại backend của Git chỉ là một nửa của vấn đề.

Khi các agent trở thành người dùng chính của một máy chủ Git, ba vấn đề lớn xuất hiện. Mọi nhà phát triển vận hành hàng trăm agent đều gặp phải cùng một rào cản, bất kể công cụ họ dùng là gì:

• Chi phí clone. Một agent clone toàn bộ repository chỉ để đọc một tập tin, rồi lại lặp lại thao tác cho agent tiếp theo, cho lần thử lại tiếp theo, truyền nhiều dữ liệu hơn nhiệm vụ yêu cầu và tiêu tốn băng thông cho một thao tác grep hoặc blame cục bộ mà lẽ ra không cần. Một lần gọi agent ngày nay có thể gây chuyển 5GB–10GB dữ liệu và tốn hơn 30 giây thiết lập, chỉ để trả lời một câu hỏi đơn lẻ.
• Sụp đổ do đồng thời. Hàng nghìn phiên làm việc va chạm vào một backend vốn được thiết kế cho quy mô con người, tạo ra tắc nghẽn và độ khả dụng khó đoán.
• Không có sự cô lập. Các agent chia sẻ tài khoản và không gian nhánh chung, vì vậy chúng làm quá tải repository, không có cách sạch để loại bỏ các công việc bị bỏ lại, và không lưu lại bản ghi rõ ràng về agent nào đã thực hiện hành động nào.

Dữ liệu nền tảng của chúng tôi cho thấy áp lực này đang tăng nhanh như thế nào. Trong năm qua, khách hàng của chúng tôi tạo ra nhiều pipeline CI/CD hơn 40%, và số lần push mã lên GitLab.com tăng 50%. Trong khi số kho lưu trữ bảo mật tăng 60%, kích thước codebase cũng tăng tới 500%.

Khi chúng tôi công bố quản lý mã nguồn thế hệ tiếp theo (next-gen SCM) tại GitLab Transcend vào tháng Sáu, chúng tôi đã phân tích lý do vì sao Git, như một mô hình vận hành, không được thiết kế cho lượng tải do agent tạo ra. Vài tuần sau đó, các nhà cung cấp mới, bao gồm các máy chủ Git được xây dựng riêng cho độ đồng thời theo quy mô agent, cũng xác nhận độc lập nhận định đó. Sự hội tụ này làm rõ rằng việc xây dựng lại backend Git là cần thiết, nhưng tự nó thôi vẫn chưa đủ.

Những gì chúng tôi đang xây dựng cho quy mô agent

Next-gen SCM vận hành trên giao thức Git để đảm bảo tương thích ngược, với backend và giao diện được thiết kế lại dành cho agent. Thay vì clone toàn bộ working tree, các agent truy vấn phía server chính xác những gì nhiệm vụ yêu cầu, mỗi agent chỉ được cấp quyền nhìn thấy tối thiểu cần thiết cho nhiệm vụ của nó. Vẫn giữ tương thích Git và khả năng kiểm toán, nhưng bên dưới là một động cơ khác.

Kiến trúc tách lớp trí tuệ (định tuyến, caching, công việc nền) khỏi compute đàn hồi mở rộng theo nhu cầu và lưu trữ đối tượng đàn hồi. API đọc/ghi chuyên dụng cho phép agent lấy dữ liệu file, blame và lịch sử, và commit thay đổi mà không cần kéo toàn bộ repository. Các nhà phát triển có thể chạy agent trên bất kỳ repo nào, mở rộng hàng nghìn phiên, và để chúng thử nghiệm một cách an toàn. Trên thực tế, điều đó có nghĩa một agent nhận một lần đọc theo lô thay vì clone toàn bộ, một yêu cầu diff-stat thay vì clone-rồi-diff, và một tra cứu commit-cuối-cùng-cho-path thay vì clone-rồi-blame.

Thiết kế này không chỉ dành cho cloud. Các tầng compute và lưu trữ giao tiếp với nhau qua API chuẩn S3, nên cùng một kiến trúc chạy trên GitLab.com cũng có thể chạy trên hạ tầng của khách hàng—dù là object storage của nhà cung cấp đám mây lớn hay một hệ thống tương thích S3 tự quản lý trong trung tâm dữ liệu của khách hàng. Với môi trường cách ly mạng (air-gapped), có quy định hoặc bị ràng buộc bởi chủ quyền dữ liệu, điều này có nghĩa khả năng mở rộng ngang và đảm bảo nhất quán tương tự, mà dữ liệu repository không bao giờ rời khỏi hạ tầng do khách hàng kiểm soát.

Trong thử nghiệm nội bộ ban đầu, khi các agent chạy trên next-gen SCM đã cho thấy:

• Tốc độ thực thi nhanh hơn tới 50x theo thời gian tường (wall-clock time)
• Tiêu thụ token giảm tới 2x
• Lưu lượng mạng ít hơn tới 1.000x

Đây là các giới hạn trên, không phải cam kết, được đo trong điều kiện kiểm thử của chúng tôi. Tải công việc thực tế gây áp lực lên backend Git ở quy mô agent là các hoạt động đọc và ghi đồng thời từ nhiều agent độc lập trên cùng một repository, kéo dài dưới tải — nên một con số chỉ có ý nghĩa khi bài kiểm tra nhắm đúng mục tiêu đó, bộ tạo tải không phải là nút cổ chai, và phân bố độ trễ đầy đủ được báo cáo thay vì chỉ một giá trị tốt nhất.

Chúng tôi đặt kết quả của mình theo chuẩn đó, và khuyến nghị bất kỳ ai đánh giá hạng mục này hãy đặt cùng ba câu hỏi cho mọi con số được đưa ra, bao gồm cả của chúng tôi. Chuẩn này được nhúng trong chính kiến trúc, không chỉ trong điều kiện kiểm thử. Bảo trì lưu trữ gom các artifacts nhỏ thành các khối lớn hơn, đã đóng băng theo lịch hình học, điều này đặt một trần cứng về lượng dữ liệu bất kỳ node nào phải lấy để bắt kịp snapshot mới nhất. Với ngưỡng đóng băng 1GB và tỉ lệ nén 2x, trần đó là 2GB, bất kể repository đã lớn tới mức nào.

Next-generation source code management hiện đang trong private beta, và đây là ví dụ trực quan:

Xây dựng lại backend chỉ là một nửa của vấn đề

Các nhà cung cấp mới đang xây dựng các host Git: điểm đích độc lập, hoặc mirror nhanh đứng trước một host hiện có để hấp thụ lưu lượng đọc. Điều đó giải quyết bài toán đồng thời, và đồng thời thực sự là một vấn đề. Nhưng còn hai câu hỏi chưa được trả lời, và cả hai đều nằm ở trung tâm cách chúng tôi nghĩ về hạ tầng agent của GitLab.

Câu hỏi đầu tiên là nguồn gốc hành động (provenance). Khi các agent push mã, chạm tới dependency và kích hoạt triển khai hàng trăm lần, câu hỏi then chốt không còn là “chúng ta đã quét chưa?” mà là “agent nào đã làm gì, theo chính sách nào, và ta có thể chứng minh không?” API dành cho agent của chúng tôi gán mỗi hành động của agent cho một workflow, một mô hình và một token cụ thể. Mọi thao tác của agent đều được định tuyến qua cùng hệ thống ủy quyền dự án và các kiểm soát vai trò-với-điểm can thiệp con người đã quản lý các đóng góp từ con người. Việc quy trách nhiệm và quản lý chính sách là thuộc tính của nền tảng, không phải tính năng của repository đơn lẻ, nên một host Git độc lập không thể trả lời vấn đề này một cách nguyên bản.

Câu hỏi thứ hai là điều gì xảy ra với công việc sau khi nó thành công. Một thử nghiệm ephemeral của agent khi thành công thường nằm trên một host độc lập. Trên GitLab, next-gen SCM là một backend Git nằm trong nền tảng đã có sẵn CI, quản lý chính sách, kiểm soát quản trị và audit đối với mã kết quả. Khi thử nghiệm tạm thời của agent thành công, nó có thể được chuyển trực tiếp vào một pipeline sản xuất có quản trị và quan sát được, mà không cần nền tảng hoặc điểm đích riêng biệt.

Next-gen SCM xử lý việc thực thi ở quy mô agent. GitLab Orbit cung cấp ngữ cảnh cho mọi agent và con người về toàn bộ vòng đời phần mềm dưới dạng một đồ thị tri thức, và GitLab Duo Agent Platform điều phối quản trị và bảo mật xung quanh mọi hành động của agent — vậy nên các agent lên kế hoạch và thực hiện công việc xuyên suốt vòng đời, không chỉ giới hạn ở các thao tác Git. Một backend Git nhanh hơn lưu trữ mã do agent tạo ra. Khi kết hợp với khả năng quản trị, ngữ cảnh vòng đời và điều phối của GitLab, mã đó được chuyển đi qua cùng quy trình CI, chính sách và audit như mọi phần còn lại của nền tảng.

Mọi doanh nghiệp sẽ gặp phải rào cản này

Mọi khách hàng sẽ dùng agent cho việc viết mã, và mọi khách hàng vận hành chúng ở quy mô lớn sẽ vấp phải cùng những giới hạn mô tả ở trên, bất kể họ chuẩn hoá vào mô hình hay công cụ nào. Đó là lý do đây là một tiến hoá trong tầng hạ tầng. Những đội di chuyển nhanh nhất trong kỷ nguyên agent sẽ là những đội có khả năng lưu trữ, quản trị và hấp thụ đầu ra của agent trở lại vào một vòng đời đã được xây để phát hành phần mềm đáng tin cậy.

Bắt đầu

Next-generation source code management đang ở giai đoạn private beta. Yêu cầu truy cập sớm ngay hôm nay!

Để được tư vấn chuyên sâu về cách triển khai, vận hành và mua giải pháp phù hợp với nhu cầu quy mô agent của tổ chức bạn, vui lòng liên hệ Softribution — chúng tôi sẵn sàng hỗ trợ tư vấn hoặc cung cấp giải pháp.