Building visibility into a CI platform

Optiver · 2026 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bối cảnh

• Lượng code qua pipeline của Optiver tăng mạnh vài năm gần đây, không chỉ do software engineer: researcher và trader cũng viết code (visualisation, thí nghiệm, tự động hoá phân tích) qua cùng pipeline build/test, và AI hỗ trợ viết code làm thay đổi thường xuyên hơn từ nhiều người hơn.
• Nhiều job CI phải chạy trên phần cứng cụ thể: test với card FPGA, code tương tác sát kernel Linux, benchmark trên nhiều kiến trúc CPU, system test có yêu cầu latency nghiêm ngặt. Phần đáng kể không container hoá được, phải chạy trên bare metal của họ.
• Không autoscale được: thêm một agent có FPGA là có người phải lắp card, có khi phải mua server. Câu hỏi chuyển từ "scale nhanh cỡ nào" sang "có đúng capacity không", tức bài toán hiểu nhu cầu.
• Họ dùng GitHub Actions (CI gốc của nơi lưu code, trải nghiệm tốt, pipeline tái dùng được), nhưng nó không lộ queue time, utilisation hay metric toàn hệ khi tự quản lý runner.

Thay đổi chính

• Dựng lại trạng thái từ event: nhận webhook mỗi lần job được xếp hàng, bắt đầu, kết thúc; lưu lại và cập nhật trạng thái từng job để thấy ở mỗi thời điểm cái gì đang chờ, đang chạy, đã xong. Độ trễ từ GitHub tới pipeline đo được và đủ nhỏ để coi là live.
• Biết cái gì chặn hàng đợi: webhook có runner chạy job, nên ánh xạ job lên phần cứng; vì pool runner gần như tĩnh, một job chạy lâu trên một lớp phần cứng hiện ra ngay.
• Hành vi theo thời gian: từ timestamp tính queue time và run time; job xong được biến thành time series (trung bình, phân vị, cực trị) cho dashboard và alert. Hàng đợi tăng trong ngày, đỉnh quanh giờ trưa; ban đêm chủ yếu là job theo lịch. Một lần alert vì p90 queue time vượt ngưỡng là điểm bắt đầu điều tra xem bất thường hay thiếu capacity thật.
• Utilisation: lấy mẫu trạng thái bận/rảnh từng runner thành metric cho cả pool, từng lớp phần cứng, từng loại agent; từ đó biết đang thiếu, thừa hay chỉ là đợt dồn dự kiến.
• CI thành nền tảng thí nghiệm: mỗi build C++ ghi metadata môi trường (phiên bản Linux, compiler, công cụ build) thành artifact; nạp vào để phân tích hiệu năng build theo môi trường. Khi rải bản compiler mới hay nâng OS, đo dần xem build nhanh/chậm đi, regression rơi vào workload nào: gần như A/B test cho toolchain.

Vì sao

• Với hệ không co giãn, quyết định mua thêm phần cứng tốn thời gian và tiền; có dữ liệu thì quyết định tự tin hơn. Theo Optiver, họ chuyển từ phản ứng sang hiểu hành vi, từ đoán capacity sang đo, và vận hành CI như một hệ production.

Bài học cho SWE

• Khi không autoscale được, observability về hàng đợi và utilisation là công cụ lập kế hoạch capacity chính.
• Thiếu metric từ nền tảng mua ngoài thì dựng lại từ luồng event của nó.
• Gắn metadata môi trường vào mỗi build để đo tác động của nâng cấp toolchain thay vì dựa vào lời kể.

Liên quan

• Jane Street 2014 · Jane Street 2025
• CI và build ở quy mô lớn · Observability và monitoring · Load test và kiểm chứng capacity