Debug khi không được vào production của khách: tìm lỗi bằng log, mẫu dữ liệu và bản tái hiện

Ba giờ chiều, khách hàng báo pipeline nhập liệu đã âm thầm bỏ mất một phần bản ghi từ sáng. Bạn đang ngồi ngay tại site của họ, nhưng đội kỹ sư ở trụ sở thì không có cách nào nhìn vào hệ thống đó. Họ chỉ biết những gì bạn kể lại.

Tình huống này được viết thẳng vào một mô tả tuyển dụng. JD vị trí Senior/Staff Forward Deployed Software Engineer của Twenty nói rằng đội làm việc ở văn phòng không truy cập được môi trường này, nên FDE là kỹ sư duy nhất có mặt ở nơi phần mềm thực sự chạy.

Vì vậy, kỹ năng cần rèn không chỉ là sửa bug. Bạn phải chuyển được lỗi ra khỏi môi trường của khách dưới dạng một thứ người khác chạy được, đọc được và kiểm chứng được, trong khi không mang theo một byte dữ liệu nào của họ.

Vì sao không thể trông vào staging và cảnh báo?

Phản xạ đầu tiên của nhiều kỹ sư là “để tôi thử trên staging”. Một bài viết của Speedscale, hãng bán công cụ tái hiện lỗi, nhận xét rằng kể cả khi có staging, nó cũng hiếm khi giống hệt production. Cấu hình, phiên bản dịch vụ và đặc biệt là hình dạng dữ liệu thật thường lệch đi đủ để lỗi biến mất.

Monitoring cũng không cứu được bạn. Cũng bài viết đó chỉ ra rằng giám sát cho bạn biết có chuyện, nhưng không cung cấp request và response đầy đủ để dựng lại lỗi. Cảnh báo chỉ là điểm xuất phát.

Khoảng trống giữa “biết có lỗi” và “dựng lại được lỗi” chính là phần việc của FDE. Có ba công cụ để lấp nó: log để định hướng, mẫu dữ liệu để hiểu hình dạng đầu vào, và một bản tái hiện để chứng minh.

Log dùng để loại trừ, không phải để đọc từ đầu đến cuối

Chương Effective Troubleshooting trong sách SRE của Google mô tả việc khắc phục sự cố là một vòng lặp: đặt giả thuyết về nguyên nhân rồi kiểm chứng giả thuyết đó. Log là nơi bạn kiểm chứng. Nó không phải cuốn tiểu thuyết để đọc từ dòng đầu tiên.

Cũng chương này gọi chia để trị là một kỹ thuật giải quyết vấn đề rất hữu dụng và áp dụng được ở mọi nơi. Với pipeline nhiều tầng, bạn hỏi xem bản ghi còn tồn tại ở tầng nào và mất ở tầng nào. Mỗi câu trả lời cắt đôi vùng nghi vấn.

Ở site của Twenty, FDE theo dõi sức khỏe nền tảng và luồng dữ liệu bằng stack LGTM gồm Grafana, Loki, Tempo và Mimir. Nếu site của bạn có công cụ tương tự, hãy tận dụng: metric để khoanh vùng thời gian, trace để theo một request đi qua các dịch vụ, log để đọc chi tiết tại đúng điểm hỏng.

Một ví dụ đi trọn vòng

Quay lại pipeline bị mất bản ghi. Đây là một tình huống giả định, dựng ra để minh họa cách làm. Metric cho thấy số bản ghi vào tầng parse bằng số bản ghi ra khỏi tầng ingest, nhưng số bản ghi ra khỏi tầng parse lại ít hơn. Vùng nghi vấn đã thu lại còn một tầng.

Giả thuyết đầu tiên: dịch vụ parse bị khởi động lại giữa chừng. Bạn lọc log quanh thời điểm đó và không thấy lần restart nào. Giả thuyết bị loại, và bạn ghi lại điều này. Sách SRE nhấn mạnh rằng kết quả âm tính không được bỏ qua hay coi nhẹ, vì nó cho người tiếp theo biết không cần đi lại con đường đó.

Giả thuyết thứ hai: một số bản ghi có trường bị rỗng. Bạn xem mẫu vài bản ghi bị bỏ tại chỗ, không copy ra ngoài, và nhận thấy chúng cùng có một đặc điểm: trường quantity là chuỗi rỗng thay vì số. Bạn chỉ ghi chép lại hình dạng của dữ liệu, không ghi giá trị thật.

Bây giờ mới viết bản tái hiện. Tài liệu hướng dẫn của scikit-learn khuyên một bản tái hiện tối giản nên dựa vào bộ dữ liệu nhỏ do chính code sinh ra khi chạy, thay vì dữ liệu bên ngoài. Tài liệu cũng chỉ ra rằng phần lớn lỗi không gắn với cấu trúc cụ thể của dữ liệu thật, nên dữ liệu giả thường là đủ.

import json
from ingest.parse import parse_event  # module trong repo của đội

# Dữ liệu tổng hợp: chỉ giữ hình dạng, không có giá trị thật của khách
rows = [
    {"id": "r1", "quantity": "3", "ts": "2026-01-01T00:00:00Z"},
    {"id": "r2", "quantity": "",  "ts": "2026-01-01T00:00:01Z"},
]

for r in rows:
    print(r["id"], parse_event(json.dumps(r)))
# Kỳ vọng: cả hai đều trả về event
# Thực tế (giả định): r2 trả về None và không ghi log lỗi

Lưu ý những gì đã bị cắt bỏ: không kết nối queue, không cấu hình retry, không đọc file. Theo scikit-learn, xóa các dòng không liên quan và bỏ những tùy chọn không mặc định giúp chính bạn và người khác thu hẹp nguyên nhân. Nếu bỏ một dòng mà lỗi vẫn còn, dòng đó không phải thủ phạm.

Gửi bằng chứng, đừng chuyển tiếp cảnh báo

Khi leo thang lên đội ở trụ sở, bạn cần mang theo một bức tranh rõ ràng về những gì đã tìm thấy, chứ không chỉ điều gì đã kích hoạt cảnh báo. Ghi chú leo thang tốt vì thế có cấu trúc khác hẳn một tin nhắn “hệ thống lỗi rồi, mọi người xem giúp”.

Phần quan trọng nhất là file repro. Scikit-learn nhận xét rằng hướng dẫn tái hiện viết bằng lời thường mơ hồ. Một đoạn code người nhận copy, dán và thấy lỗi ngay sẽ tiết kiệm nhiều vòng hỏi đáp qua lại, và sách SRE cũng khẳng định một test case tái hiện chắc chắn giúp debug nhanh hơn rất nhiều.

Code của bạn cũng phải debug được từ xa

Bài toán này có cả chiều ngược lại. Code bạn viết cho site của khách phải test, debug và bảo trì được bởi những kỹ sư không vào được môi trường nơi nó chạy, và JD của Twenty ghi rõ đó là một yêu cầu. Trong ví dụ trên, lỗi khó tìm chính vì parse_event trả về None mà không để lại dòng log nào.

Khi viết code, hãy tự hỏi: nếu hàm này hỏng, log có đủ để người ở xa biết nó hỏng ở bản ghi nào và vì sao không? Một dòng log ghi ID bản ghi và tên trường gây lỗi, không ghi giá trị nhạy cảm, có thể rút ngắn cả buổi điều tra.

Những lỗi hay gặp

Lỗi phổ biến nhất là tin vào staging. Lỗi không xuất hiện trên staging không có nghĩa là lỗi không tồn tại; rất có thể chỉ là dữ liệu staging không có hình dạng gây lỗi.

Lỗi thứ hai là bỏ qua giả thuyết đã bị loại. Nếu bạn không ghi lại rằng mình đã kiểm tra chuyện restart, đồng nghiệp ở trụ sở sẽ mất thời gian kiểm tra lại đúng điều đó.

Lỗi thứ ba là bản tái hiện quá to: kéo theo cả cấu hình production, đọc file mẫu mà người khác không có, hoặc tệ hơn là chứa dữ liệu thật. Nếu người nhận không chạy được file đó ngay trên máy mình, bản tái hiện coi như chưa làm xong việc.

Cách thể hiện kỹ năng này khi đi xin việc

Với developer Việt Nam muốn chuyển sang FDE, khi đọc JD hãy để ý những cụm như “on-site”, “air-gapped”, “cleared environment” hay yêu cầu về observability stack. Đó là dấu hiệu công việc đòi hỏi đúng kỹ năng này.

Trong CV, đừng chỉ viết “debug production issues”. Hãy kể một lần bạn khoanh vùng lỗi bằng log hay trace, dựng lại nó bằng dữ liệu tổng hợp và bàn giao cho đội khác sửa. Nếu có thể, đưa một bản tái hiện đã từng gửi vào một issue mã nguồn mở lên GitHub để nhà tuyển dụng tự xem.

Một FDE giỏi không phải người có quyền truy cập rộng nhất. Đó là người mà khi bước ra khỏi phòng máy của khách, trong tay chỉ có vài dòng code, vẫn đủ để cả đội nhìn thấy cái lỗi mà họ không bao giờ được chạm vào.