OmniDocCần có nhật ký để khắc phục lỗi tài liệu, nhưng không cần ghi lại toàn bộ văn bản.
Cần có nhật ký để xác định lỗi dịch thuật nhưng không cần in ra toàn bộ hợp đồng, số ID hoặc mã thông báo tải xuống. Nhật ký phải trả lời "nhiệm vụ nào, ở bước nào và tại sao nó không thành công" thay vì trở thành thư viện tài liệu thứ hai thiếu quản lý quyền.
Cần có nhật ký để khắc phục lỗi dịch tài liệu nhưng nhật ký không cần chứa toàn bộ nội dung của hợp đồng, số ID hoặc mã thông báo tải xuống. Bài viết này giải thích cách tạo câu trả lời cho nhật ký "tác vụ nào không thành công ở bước nào và tại sao" mà không cần sao chép tài liệu của khách hàng vào nhật ký.
Những độc giả phù hợp là các nhà phát triển, nhân viên vận hành và bảo trì, những người chịu trách nhiệm về dịch vụ dịch tài liệu, gắn kết các giao diện dịch thuật hoặc duy trì nhật ký nền. Sau khi đọc, bạn có thể thiết kế một tập hợp các trường danh sách trắng, xác minh rằng nhật ký không hiển thị văn bản gốc và đặt khoảng thời gian lưu giữ cũng như phạm vi truy cập để khắc phục sự cố.
Các ví dụ sử dụng mẫu tổng hợp để minh họa các phương pháp xử lý và mã đã được kiểm tra trong môi trường biệt lập nhưng điều này không thể hiện sự đảm bảo về tất cả các tệp thực hoặc hiệu suất của sản phẩm. Trước khi xử lý các tài liệu quan trọng, vui lòng giữ lại bản gốc và xem xét theo ranh giới và các mục chấp nhận dưới đây.
Cần ghi lại những gì trong nhật ký khắc phục sự cố? Một câu kết luận
Nhật ký chỉ ghi lại các trường được phép như ID nhiệm vụ, giai đoạn, loại lỗi và mức tiêu thụ thời gian chứ không ghi lại nội dung tài liệu và thông tin xác thực.
| hoàn cảnh của bạn | Các phương pháp được đề xuất | lý do |
|---|---|---|
| Cần biết nhiệm vụ nào thất bại | Ghi nhật ký ID tác vụ nội bộ ngẫu nhiên | Khả năng xác định vị trí sự cố mà không để lộ tên hoặc đường dẫn tệp người dùng |
| Cần xác định thẻ đang ở giai đoạn nào | Ghi tên sân khấu và thời gian thực hiện | Không cần từng nguồn văn bản và bản dịch |
| Yêu cầu đã bị từ chối bởi thượng nguồn | Ghi lại các danh mục lỗi được chuẩn hóa | Không được nhập nội dung yêu cầu hoàn chỉnh hạng nhất xác thực vào nhật ký |
| Cần quay lại bản gốc để khắc phục sự cố | Sử dụng tài liệu tham khảo trong một hệ thống được kiểm soát | Các liên kết có thể được tải xuống công khai vĩnh viễn có nguy cơ bị rò rỉ |
Bắt đầu với các trường được phép ghi
Danh sách đen có thể dễ dàng bỏ sót các trường nhạy cảm mới. Một cách tiếp cận thận trọng hơn là chỉ xuất ra các trường được thiết kế, ví dụ:
- ID nhiệm vụ nội bộ
- Giai đoạn xử lý
- loại lỗi
- tốn thời gian
Ví dụ tổng hợp bên dưới sử dụng phép chiếu danh sách trắng để toàn bộ văn bản và mã thông báo trong đầu vào không được nhập vào nhật ký.
Nhật ký xác minh không đưa ra văn bản gốc.
import io
import json
import logging
ALLOWED = ("job_id", "stage", "error_code", "elapsed_ms")
def log_record(data):
return {key: data[key] for key in ALLOWED if key in data}
stream = io.StringIO()
logger = logging.getLogger("synthetic-document-job")
logger.handlers.clear()
logger.propagate = False
logger.setLevel(logging.INFO)
handler = logging.StreamHandler(stream)
logger.addHandler(handler)
event = {"job_id": "demo-12", "stage": "parse", "error_code": "BAD_CONTAINER",
"elapsed_ms": 42, "document_text": "synthetic confidential clause",
"access_token": "synthetic-secret"}
logger.info(json.dumps(log_record(event), sort_keys=True))
logged = json.loads(stream.getvalue())
assert logged["error_code"] == "BAD_CONTAINER"
assert "document_text" not in logged
assert "synthetic-secret" not in stream.getvalue()
assert set(logged) <= set(ALLOWED)
logger.removeHandler(handler)Ví dụ này chỉ sửa đổi trình ghi nhật ký demo tự đặt tên. Không nên xóa trình xử lý chung của ứng dụng trong thư viện doanh nghiệp. Giá trị trường vẫn cần được xác minh về độ dài và loại. Nếu bạn nhét toàn bộ văn bản của người dùng vào error_code, chỉ tên danh sách trắng sẽ không cứu được bạn.
ID hiệp hội thay cho nội dung nhạy cảm
Bảng sau liệt kê các yêu cầu chung trong quá trình khắc phục sự cố cũng như các bản ghi được đề xuất và không được đề xuất.
| Những vấn đề cần điều tra | Bản ghi được đề xuất | Không khuyến khích ghi lại điều này |
|---|---|---|
| Nhiệm vụ nào thất bại | ID nhiệm vụ nội bộ ngẫu nhiên | Tên tệp đầy đủ và đường dẫn của người dùng |
| Giai đoạn nào mất thời gian | Các giai đoạn và mất nhiều thời gian | Mỗi đoạn văn bản gốc và bản dịch |
| Tại sao Upstream lại từ chối? | Chuẩn hóa các loại lỗi | Một yêu cầu hoàn chỉnh với tiêu đề xác thực |
| Cách tìm bản gốc | Tham chiếu trong hệ thống được kiểm soát | Liên kết có sẵn vĩnh viễn để tải xuống công khai |
Thời gian lưu trữ quan trọng không kém phạm vi truy cập
Ngay cả khi nhật ký không có nội dung nội dung, sự kết hợp giữa thời gian tác vụ, ngôn ngữ và kích thước tệp có thể tiết lộ thông tin kinh doanh. Nhật ký nên đi kèm với kiểm soát truy cập, thời gian lưu trữ và quy trình xóa.
Trong quá trình khắc phục sự cố, tạm thời nâng mức nhật ký, làm rõ khi nào tiếp tục hoạt động và tránh chế độ gỡ lỗi để ở lại môi trường sản xuất quá lâu.
Tích hợp dịch thuật cũng cung cấp nhật ký rõ ràng và hạn chế
Khi tích hợp với OmniDoc (Mục sản phẩm), chỉ ghi lại sự liên kết giữa tác vụ cục bộ và từ xa; các tệp do người dùng tải lên không nên sao chép vào nhật ký để dễ dàng khắc phục sự cố.
Một báo cáo sự cố tốt có thể giải thích giai đoạn lỗi và điều kiện tái diễn, đồng thời đảm bảo rằng tài liệu khách hàng chỉ được lưu chuyển trong các đường xử lý được ủy quyền.
Tham khảo: Python logging.
📊 So sánh cốt lõi
| Phương pháp | Ưu điểm | Rủi ro |
|---|---|---|
| Danh sách đen | Phương pháp viết đơn giản và dễ học | Các trường nhạy cảm dễ xuất hiện sẽ bị bỏ sót |
| Danh sách trắng | Chỉ các trường được thiết kế mới được đầu ra, với ranh giới rõ ràng | Cần lên kế hoạch trước các trường và xác minh độ dài cũng như loại giá trị của trường |
🎯 Phương pháp nào phù hợp với bạn?
Nếu bạn cần tìm một tác vụ dịch thuật
Ghi lại các ID tác vụ nội bộ ngẫu nhiên và các giai đoạn thất bại, mà không ghi lại tên tệp đầy đủ hoặc đường dẫn của người dùng.
Nếu bạn muốn xử lý lỗi giao diện upstream
Ghi lại các loại lỗi chuẩn hóa, nhưng không ghi lại các yêu cầu đầy đủ với tiêu đề xác thực.
Nếu bạn đang khắc phục sự cố trực tuyến
Tạm thời nâng mức log và khôi phục ngay sau khi kiểm tra.
Nếu bạn muốn thiết kế trường nhật ký
Ưu tiên danh sách trắng và xác minh độ dài cũng như loại giá trị trường.
❓ Câu hỏi thường gặp (FAQ)
1. Nhật ký có thể ghi lại tên tập tin đầy đủ của người dùng không?
Không khuyến khích. Không khuyến nghị sử dụng đầy đủ tên tệp và đường dẫn để ghi âm; bạn có thể sử dụng các ID tác vụ nội bộ ngẫu nhiên để liên kết thay thế.
2. Tại sao không khuyến khích sử dụng danh sách đen để lọc các trường nhạy cảm?
Danh sách đen thường bỏ qua các trường nhạy cảm mới xuất hiện, trong khi danh sách trắng chỉ xuất ra các trường được thiết kế, khiến chúng đáng tin cậy hơn.
3. Bạn chỉ cần quản lý thời gian làm việc và kích thước tệp thôi sao?
Đúng vậy. Thông tin này cũng có thể tiết lộ các chi tiết kinh doanh, và nhật ký nên đi kèm với kiểm soát truy cập, thời gian lưu trữ và quy trình xóa.
4. Nhật ký gỡ lỗi có thể được giữ mở trong thời gian dài trong quá trình khắc phục sự cố không?
Không khuyến khích. Sau khi tạm thời nâng cấp cấp độ nhật ký, điều quan trọng là phải chỉ định khi nào tiếp tục chế độ gỡ lỗi để tránh để chế độ gỡ lỗi trong môi trường sản xuất quá lâu.
5. Bạn có thể xóa trình xử lý toàn cục khỏi cơ sở dữ liệu kinh doanh không?
Không khuyến khích. Ví dụ chỉ sửa đổi trình ghi demo mà bạn tự đặt tên; thư viện kinh doanh không nên được làm trống ứng dụng trình xử lý toàn cục.
📝 Tóm tắt
Khi khắc phục sự cố dịch thuật, nhật ký nên trả lời nhiệm vụ, giai đoạn và lý do, thay vì lưu nội dung tài liệu. Sử dụng các trường danh sách trắng, trích dẫn kiểm soát và thời gian lưu trữ rõ ràng là điều thiết yếu để cân bằng hiệu quả khắc phục sự cố với bảo mật tài liệu.
Trải nghiệm ngay: Tải lên tài liệu của bạn để bắt đầu dịch, giữ nguyên định dạng gốc
