Nhật ký giao dịch của bot: thứ phải có trước tiền thật

Phái sinh VN30F1MCập nhật 13/09/2026

Mọi thứ bot không ghi lại là thông tin mất vĩnh viễn. Ba tháng sau khi cần biết vì sao nó lỗ, bạn chỉ còn đường đoán.

Nhật ký giao dịch của bot là thứ nghe nhàm chán nhất nhưng quyết định nhiều nhất tới việc bạn có cải thiện được hệ thống hay không. Lý do đơn giản: mọi thứ bot không ghi lại là thông tin mất vĩnh viễn.

Ba tháng sau, khi cần biết vì sao bot lỗ trong tháng Tư, bạn chỉ có hai lựa chọn — đọc nhật ký, hoặc đoán.

Ghi gì

Chia làm ba loại, mỗi loại có mục đích và vòng đời khác nhau.

Nhật ký vận hành ghi bot đang làm gì: khởi động, kết nối, mỗi vòng lặp, lỗi. Dùng để gỡ lỗi khi có sự cố. Giữ vài tháng.

Bản ghi quyết định ghi mỗi lần hàm tín hiệu chạy: kết quả trả về, và giá trị của từng vế điều kiện. Đây là phần người mới hay bỏ. Nhờ nó, khi bot không vào lệnh trong một nhịp mà lẽ ra nên vào, bạn đọc là biết vế nào chặn thay vì đoán.

Bản ghi lệnh ghi mọi lệnh: lúc quyết định, giá tham chiếu lúc đó, lúc gửi, lúc khớp, giá khớp thật, khối lượng khớp. Giữ mãi — đây là dữ liệu quý nhất bạn có.

Bản ghi lệnh cần những trường nào

Bốn dấu thời gian và hai mức giá, đủ để tính ra mọi thứ về sau.

log_trade({
    "decided_at": t0,          # lúc hàm tín hiệu trả kết quả
    "reference_price": p0,     # giá tại thời điểm quyết định
    "sent_at": t1,             # lúc gọi API
    "filled_at": t2,           # lúc nhận báo khớp
    "fill_price": p1,          # giá khớp thật
    "qty_requested": 2,
    "qty_filled": 2,
    "strategy": "breakout_20",
    "commit": "a3f9c21",       # phiên bản mã đang chạy
})

Trường commit đáng chú ý: ba tháng sau nhìn lại một chuỗi kết quả, bạn biết chính xác nó đến từ phiên bản mã nào — điều rất khó tái dựng nếu không ghi.

Dùng nhật ký để đo trượt giá thật

Đây là lý do quan trọng nhất khiến bản ghi lệnh đáng giữ mãi.

Hiệu số giữa reference_pricefill_price chính là chi phí thực thi thật của bạn. Backtest giả định con số này; nhật ký cho biết nó thật sự là bao nhiêu.

0358100.5 bước1 bước1.5 bước2 bước2.5 bước3 bước3.5 bước4 bướcTrượt giá mỗi lệnh

Phần lớn lệnh tốn khoảng nửa bước giá — dễ chịu. Nhưng phần đuôi bên phải mới ăn mất lợi nhuận, và những lệnh đuôi đó không phân bố ngẫu nhiên: chúng tập trung vào lúc biến động mạnh và lúc bạn cần thoát gấp.

Vì thế đừng lấy con số trung bình đưa vào backtest — hãy lấy phân vị cao, ví dụ phân vị 90. Chi tiết về cách đo và giảm chi phí này nằm ở bài về thực thi lệnh. Hình minh hoạ, không phải dữ liệu thật.

Ba mức nghiêm trọng

Đừng dùng lệnh in ra màn hình. Dùng thư viện ghi nhật ký chuẩn, xuất ra tệp theo ngày, có dấu thời gian và mức độ.

Thông tin240 dòng/phiênCảnh báo12 dòng/phiênLỗi2 dòng/phiênTần suất điển hình một phiên — lỗi mà nhiều là dấu hiệu có gì đó sai hệ thống

Thông tin cho mọi quyết định bình thường: vòng lặp chạy, tín hiệu trả về, lệnh gửi đi. Nhiều là đúng.

Cảnh báo cho những gì bất thường nhưng xử lý được: dữ liệu thiếu một nến, lệnh khớp một phần, kết nối chập chờn rồi tự phục hồi.

Lỗi cho những gì cần người can thiệp: không kết nối được, lệnh bị từ chối liên tiếp, vị thế lệch so với sổ sách.

Tỷ lệ như hình là dấu hiệu lành mạnh. Nếu mỗi phiên có hàng chục dòng lỗi, đó không phải nhật ký ồn ào mà là hệ thống đang hỏng.

Cảnh báo: chỉ cho thứ phải can thiệp ngay

Nhật ký để đọc sau; cảnh báo để biết ngay. Hai thứ khác nhau và đừng trộn.

Bốn tình huống đáng gửi cảnh báo ra điện thoại: bot chết hoặc không phản hồi, lệnh bị từ chối liên tiếp, vị thế thật lệch so với dự tính, và chạm giới hạn lỗ ngày.

Mọi thứ khác để trong nhật ký. Nguyên tắc: cảnh báo mà nhiều thì sẽ không ai đọc — và khi cảnh báo thật sự quan trọng xuất hiện, nó lẫn vào đám còn lại.

Với bot chạy liên tục như bot crypto, cần thêm một cảnh báo kiểu ngược: bot gửi tín hiệu sống mỗi vài phút, và hệ thống giám sát báo động khi không nhận được tín hiệu đó. Bot chết thì nó không tự báo được rằng mình đã chết.

Đối chiếu cuối phiên

Thói quen đáng tập: cuối mỗi phiên, bot tự chạy một bản đối chiếu và ghi lại.

Lấy vị thế từ sànnguồn sự thậtSo với sổ sách nội bộsố hợp đồng, giá vốnlệch → báo động ngayTính lãi lỗ trong phiêntừ bản ghi lệnhSo với giới hạn ngàyđã dùng bao nhiêu phầnvượt → dừng phiên sauGhi báo cáo cuối phiênmột dòng tóm tắt

Bản đối chiếu này bắt được hai loại lỗi mà vòng lặp thường không thấy: sai lệch tích luỹ dần giữa sổ sách nội bộ và vị thế thật, và việc vô tình vượt giới hạn rủi ro do nhiều lệnh nhỏ cộng lại.

Một dòng tóm tắt cuối phiên — số lệnh, lãi lỗ, trượt giá trung bình, có cảnh báo nào không — đọc mất mười giây và cho bạn biết hôm nay có gì bất thường không.

So kết quả thật với backtest

Đây là việc mà bản ghi lệnh cho phép làm, và không có nó thì không làm được.

Sau vài tuần chạy song song, bạn có hai chuỗi: chuỗi lệnh mà backtest nói lẽ ra đã xảy ra, và chuỗi lệnh bot thật ghi lại. So hai chuỗi này trả lời được ba câu hỏi mà không cách nào khác trả lời nổi.

Bot có vào đúng những lệnh backtest dự đoán không? Lệch nhau nghĩa là dữ liệu hoặc logic ở hai bên khác nhau — thường do bot dùng nguồn dữ liệu khác, hoặc do backtest tính trên nến đã đóng còn bot tính trên nến đang chạy.

Giá khớp thật cách giá backtest giả định bao xa? Đây chính là chi phí thực thi, và nó phải được đưa ngược vào giả định backtest.

Có lệnh nào backtest có mà bot bỏ lỡ không? Thường do lệnh bị từ chối, do kết nối đứt, hoặc do tầng rủi ro chặn. Mỗi nguyên nhân cần cách xử lý khác nhau, và bạn chỉ phân biệt được khi nhật ký ghi đủ lý do.

Con số đáng theo dõi nhất là tỷ lệ lệnh khớp đúng như dự đoán. Nếu nó dưới chín phần mười, đừng chuyển sang tiền thật — có gì đó trong chuỗi từ dữ liệu tới lệnh đang hoạt động khác với những gì bạn nghĩ.

Nhật ký là dữ liệu, không phải rác

Có một thay đổi cách nghĩ đáng làm sớm: coi nhật ký là dữ liệu để phân tích, không phải thứ chỉ đọc khi có sự cố.

Sau vài tháng chạy, bản ghi lệnh của bạn là một bộ dữ liệu về chính hệ thống của mình — và nó trả lời được những câu hỏi mà không tài liệu nào trả lời được. Lệnh vào buổi sáng có trượt giá khác buổi chiều không? Những lệnh lỗ nặng nhất có đặc điểm chung gì? Tỷ lệ lệnh bị từ chối tăng lên theo thời gian không?

Mỗi câu trả lời là một cải thiện cụ thể, có căn cứ. Đó là khác biệt giữa điều chỉnh hệ thống bằng số liệu và điều chỉnh bằng cảm giác — và sau một năm, khoảng cách giữa hai cách làm rất lớn.

Trước khi sang bài sau

Nên làm được: bật ghi nhật ký ra tệp với ba mức; ghi bản ghi lệnh đủ bốn dấu thời gian và hai mức giá; và chạy được một bản đối chiếu cuối phiên so vị thế sàn với sổ sách nội bộ.

Đến đây bạn đã có đủ các khối của kiến trúc năm tầng. Phần tiếp theo của lộ trình chuyển sang backtest: chạy toàn bộ những gì vừa dựng trên dữ liệu lịch sử, và làm sao để kết quả đó nói lên điều gì đó thật.

Câu hỏi thường gặp

Ghi nhật ký có làm bot chậm không?
Không đáng kể với chiến lược khung phút trở lên. Ghi vào tệp là thao tác rất nhanh so với một lần gọi API, và lợi ích khi cần truy lại lớn hơn nhiều.
Nên ghi ra tệp hay cơ sở dữ liệu?
Nhật ký vận hành ghi ra tệp theo ngày. Riêng bản ghi từng lệnh nên vào cơ sở dữ liệu hoặc tệp có cấu trúc, vì bạn sẽ cần truy vấn và tính toán trên chúng.
Có cần cảnh báo thời gian thực không?
Cần, nhưng chỉ cho những việc phải can thiệp ngay: bot chết, lệnh bị từ chối liên tiếp, vị thế lệch so với dự tính. Cảnh báo mọi thứ thì sẽ không ai đọc.
Giữ nhật ký bao lâu?
Nhật ký vận hành vài tháng là đủ. Bản ghi lệnh thì giữ mãi — đó là dữ liệu để đo chi phí thực thi thật và so kết quả thật với backtest.

Đọc tiếp