CI trông như thế nào ở một nhóm 100 người (PostHog)

Tuần trước, CI của PostHog đã thực hiện 575.894 công việc, xử lý 1,18 tỷ dòng nhật ký và thực hiện 33 triệu thử nghiệm. Ở mức âm lượng đó, ngay cả tốc độ truyền 99,98% cũng tạo ra tiếng ồn có ý nghĩa. Chúng tôi đang xây dựng Mendral, một tác nhân AI có chức năng chẩn đoán lỗi CI, cách ly các thử nghiệm không ổn định và mở PR kèm theo các bản sửa lỗi. Sau đây là những gì chúng tôi đã học được khi chạy nó trên một trong những monorepos công khai lớn nhất mà chúng tôi từng thấy.

Nhưng trước tiên, hãy tìm hiểu bối cảnh về lý do tại sao chúng tôi xây dựng cái này. Trở lại năm 2013, tôi đang quản lý nhóm kỹ thuật gồm 100 người của Docker và người đồng sáng lập Andrea của tôi là trưởng nhóm công nghệ và kiến trúc sư trưởng của nhóm. Chúng tôi đã mở rộng CI của Docker từ một số bản dựng thành thứ gì đó chạy liên tục trên cơ sở cộng tác viên khổng lồ. Ngay cả hồi đó, những bài kiểm tra không ổn định và những bài PR lớn khiến chúng tôi đau đầu khi xem xét. Chúng tôi đã dành rất nhiều thời gian để gỡ lỗi các lỗi CI không liên quan gì đến mã được gửi đi. Đó là hơn một thập kỷ trước, không có công cụ mã hóa AI nào tạo ra PR trên quy mô lớn. Vấn đề chỉ trở nên tồi tệ hơn kể từ đó. Mendral là công cụ mà chúng tôi mong muốn có ở Docker.

CI của PostHog trong một tuần

PostHog là một nhóm có khoảng 100 người hoàn toàn làm việc từ xa, tất cả đều liên tục nỗ lực hướng tới một monorepo công cộng lớn. Họ vận chuyển nhanh chóng và cơ sở hạ tầng CI của họ phản ánh điều đó. Sau đây là diễn biến của một tuần (27 tháng 1 - 2 tháng 2):

575.894 công việc CI trên 94.574 lần chạy quy trình làm việc
1,18 tỷ dòng nhật ký (76,6 GiB)
33,4 triệu lượt thực thi thử nghiệm trên 22.477 thử nghiệm riêng biệt
3,6 năm thời gian tính toán trong một tuần
65 cam kết được sáp nhập vào chính mỗi ngày, 105 PR được kiểm tra mỗi ngày
98 cộng tác viên con người hoạt động trong một tuần
Mỗi cam kết chính sẽ tạo ra trung bình 221 công việc song song

Vào ngày bận rộn nhất của họ (Thứ Ba), họ đã đốt hết 300 ngày tính toán trong 24 giờ. Đây không phải là con số của một đội gặp vấn đề về CI. Đây là những con số của một đội di chuyển cực nhanh và thực hiện việc kiểm tra một cách nghiêm túc.

Tính chất vật lý của quy mô

Với tốc độ này, các cuộc thử nghiệm không ổn định trở thành một quy luật tất yếu của tự nhiên. Tỷ lệ vượt qua bài kiểm tra của PostHog là 99,98%, thực sự xuất sắc qua 22.477 bài kiểm tra. Nhưng với 33 triệu lượt thực hiện thử nghiệm hàng tuần, ngay cả một tỷ lệ thất bại nhỏ cũng tạo ra một lượng tiếng ồn đáng kể. Đó chỉ là toán học.

Khoảng 14% tổng số công việc tính toán của họ bị lỗi và bị hủy, đồng thời khoảng 3,5% tổng số công việc được chạy lại. Đây không phải là vấn đề cụ thể của PostHog. Bất kỳ nhóm nào hoạt động với tốc độ này, với phạm vi kiểm tra này, sẽ đạt được động lực tương tự. Vấn đề là bạn giải quyết nó như thế nào.

Hầu hết các đội đều chấp nhận điều đó. Các kỹ sư tìm hiểu xem thử nghiệm nào không ổn định, họ chạy lại và tiếp tục. Nó hoạt động đến một điểm. Nhưng khi bạn có 98 người đóng góp tích cực và 221 công việc song song trên mỗi cam kết, thì chi phí điều tra và chạy lại sẽ tăng lên một cách lặng lẽ. Nhóm PostHog đã sớm nhận ra điều này và quyết định chủ động xử lý nó, đó là cách chúng tôi bắt đầu làm việc cùng nhau.

Điều gì thực sự xảy ra với các thử nghiệm không ổn định trên quy mô lớn

Một bài kiểm tra đạt 95% thời gian hầu như đều ổn. Nhưng khi CI của bạn chạy 221 công việc trên mỗi lần xác nhận và bạn đang hợp nhất 65 lần xác nhận mỗi ngày vào chính, thì thử nghiệm đó sẽ thất bại nhiều lần trong ngày. Nỗi đau không phải là sự thất bại của cá nhân. Đó là cuộc điều tra. Ai đó nhìn thấy CI màu đỏ, bỏ công việc họ đang làm, mở nhật ký, cố gắng tìm hiểu xem liệu thay đổi của họ có làm hỏng thứ gì đó hay đó là một lỗi đã biết. Sau đó họ chạy lại. Có lẽ nó sẽ trôi qua. Có lẽ nó không. Có thể họ ping ai đó trên Slack. Có thể ba người đang nhìn vào cùng một thất bại một cách độc lập.

Ở 10 kỹ sư, một bài kiểm tra không ổn định là điều khó chịu. Ở mức 100, đó là thuế đánh vào năng suất của mọi người.

Cách Mendral hoạt động tại PostHog

Đại lý của chúng tôi là Ứng dụng GitHub. Bạn cài đặt nó trên repo của mình (mất khoảng 5 phút) và nó bắt đầu xem mọi cam kết, mọi lần chạy CI, mọi đầu ra nhật ký. Đây là những gì nó thực hiện cụ thể:

Nhập nhật ký trên quy mô lớn. Chúng tôi đã xây dựng một hệ thống nhập nhật ký để xử lý hơn tỷ dòng nhật ký hàng tuần của PostHog để nhân viên hỗ trợ có thể nhanh chóng tìm kiếm và đối chiếu các lỗi tương ứng. Không có điều này, bạn không thể thực hiện chẩn đoán có ý nghĩa. Bạn cần có khả năng xem xét một lỗi, lấy các nhật ký có liên quan và tham khảo chéo với các lỗi khác gần đây để xác định xem đó là một sự cố hay một sự hồi quy thực sự.

Phát hiện và truy tìm các mảnh. Tác nhân liên hệ các lỗi với các thay đổi mã. Khi nó thấy một thử nghiệm không liên tục, nó sẽ truy tìm lại nguồn gốc của nó: cam kết nào đã tạo ra nó, điều kiện cơ sở hạ tầng nào kích hoạt nó (đôi khi đó là do sự chậm chạp hoặc tác dụng phụ, không phải mã). Đây là phần mất nhiều thời gian nhất của con người và là phần mà tác nhân mang lại nhiều giá trị nhất.

Mở PR kèm theo bản sửa lỗi. Khi nhân viên hỗ trợ xác định được một thử nghiệm không ổn định và có đủ tin tưởng vào kết quả chẩn đoán, nhân viên sẽ mở một yêu cầu kéo để cách ly hoặc khắc phục thử nghiệm đó. Bởi vì repo của PostHog là công khai nên bất kỳ ai cũng có thể nhìn thấy những PR này. Bạn có thể đi xem chúng ngay bây giờ. Nhân viên hỗ trợ lặp lại quá trình PR dựa trên các nhận xét đánh giá, giống như con người.

Hoạt động với tư cách là thành viên nhóm trên Slack. Người đại diện tham gia Slack và cư xử như một thành viên trong nhóm. Khi có lỗi CI, nó sẽ không phát tới kênh chung. Mọi thành viên trong nhóm PostHog đều liên kết tài khoản của họ với bảng điều khiển Mendral để đại lý biết ai sẽ liên quan. Nếu cam kết của bạn có thể gây ra lỗi, bạn sẽ nhận được tin nhắn trực tiếp. Nếu đó là một mảnh vụn đã biết, người đại diện sẽ xử lý nó mà không làm gián đoạn bất kỳ ai. Đây là thứ mà nhóm PostHog đã thúc đẩy chúng tôi xây dựng tốt hơn và nó trở thành một trong những tính năng có sức ảnh hưởng lớn nhất.

Phân tích liên tục. Tác nhân không chỉ phản ứng với các lỗi. Nó phân tích tất cả các cam kết, tất cả các lần chạy CI và tất cả các nhật ký liên tục. Nó xây dựng một bức tranh về tình trạng của repo theo thời gian, xác định các mẫu và chủ động cung cấp thông tin chi tiết.

Bốn điều khiến chúng tôi ngạc nhiên khi xây dựng một tác nhân CI trên quy mô lớn

Một số điều khiến chúng tôi ngạc nhiên:

Nhập nhật ký là một vấn đề khó khăn. Mọi người đều tập trung vào phần AI/chẩn đoán, nhưng điểm nghẽn thực sự là khiến hàng tỷ dòng nhật ký được lập chỉ mục và có thể tìm kiếm đủ nhanh để hữu ích trong thời gian thực. Nếu nhân viên hỗ trợ của bạn không thể tìm kiếm nhật ký trong vài giây, thì nhân viên đó sẽ không thể chẩn đoán bất kỳ điều gì trước khi kỹ sư chuyển ngữ cảnh để điều tra theo cách thủ công.

Thử nghiệm không ổn định hiếm khi xảy ra ngẫu nhiên. Hầu hết mọi thử nghiệm "không ổn định" đều có nguyên nhân gốc rễ xác định, chỉ một nguyên nhân khó tìm ra. Sự phụ thuộc về thời gian, trạng thái chia sẻ giữa các lần kiểm tra, sự khác biệt về cơ sở hạ tầng, việc thực thi phụ thuộc vào thứ tự. Tác nhân này giỏi việc này vì nó có thể tương quan trên hàng trăm lần chạy CI cùng một lúc, điều mà con người sẽ không đủ kiên nhẫn để làm.

Vấn đề định tuyến bị đánh giá thấp. Biết ai thông báo về lỗi cũng có giá trị gần như biết điều gì bị lỗi. Ở quy mô của PostHog, một thông báo lỗi chuyển đến một kênh chung có nghĩa là 98 người xem qua và 97 người bỏ qua nó. Việc yêu cầu người đại diện tìm ra ai thực sự cần xem xét nó, dựa trên sự thay đổi mã và chữ ký lỗi, sẽ loại bỏ được nhiều nhiễu loạn.

Làm việc trên một kho lưu trữ công khai giúp bạn luôn trung thực. Mọi PR mà đại lý của chúng tôi mở trên kho lưu trữ của PostHog đều hiển thị với bất kỳ ai. Điều này rất tốt cho chúng tôi vì nó đòi hỏi sự minh bạch hoàn toàn. Bạn có thể biết chính xác tác nhân đang làm gì, lý do gây ra lỗi và đề xuất giải pháp khắc phục.

Bức tranh lớn hơn

Chúng tôi cho rằng thách thức CI sẽ ngày càng tăng đối với hầu hết các nhóm chứ không bị thu hẹp lại. Các công cụ mã hóa AI (Cursor, Copilot, Claude Code) đang làm tăng số lượng thay đổi mã. Nhiều thay đổi hơn có nghĩa là nhiều lần chạy CI hơn, nhiều lỗi tiềm ẩn hơn, nhiều thử nghiệm không ổn định hơn. Đường ống phân phối trở thành nút cổ chai.

PostHog là một ví dụ điển hình về hình ảnh của một nhóm được điều hành tốt và phát triển nhanh trên quy mô lớn. Họ có 22.477 bài kiểm tra với tỷ lệ vượt qua 99,98%, gửi 65 cam kết chính hàng ngày và giúp 98 kỹ sư làm việc hiệu quả trên một monorepo duy nhất. Đó là kỹ thuật ấn tượng. Công việc của chúng tôi là giúp các nhóm như của họ duy trì tốc độ nhanh khi số lượng không ngừng tăng lên.

Chúng tôi đã may mắn được giới thiệu PostHog sớm trong đợt YC của mình. Quy mô của họ đã đẩy nhanh giới hạn của đại lý của chúng tôi, theo những cách mà chúng tôi không thể tự mô phỏng được. Nó buộc chúng tôi phải giải quyết các vấn đề thực tế với số lượng lớn ngay từ ngày đầu tiên. Xin chân thành cảm ơn Tim vì sự tin tưởng và hỗ trợ của anh ấy cũng như toàn bộ nhóm PostHog đã làm việc với chúng tôi một cách công khai trên một kho lưu trữ công khai và cung cấp cho chúng tôi những phản hồi đã định hình rất nhiều những gì Mendral làm ngày nay. Sau một thập kỷ tự mình xây dựng và mở rộng quy mô hệ thống CI, bắt đầu tại Docker vào năm 2013 khi vấn đề vốn đã khó khăn, thật thú vị khi cuối cùng đã xây dựng được tác nhân tự động hóa công việc mà chúng tôi từng làm thủ công.