> ## Documentation Index > Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt > Use this file to discover all available pages before exploring further. # Phát hiện và vấn đề > Chuyển đổi bằng chứng kiểm toán thành công việc khắc phục được sở hữu và có thể theo dõi. Một phát hiện là một tuyên bố được hỗ trợ bằng bằng chứng về một lỗi từ kiểm toán. Một vấn đề là quy trình durable để phản ứng với nó. ## Phân loại và gán công việc 1. Mở **Analyze → Audits**, chọn một lần chạy đã hoàn thành và chọn một phát hiện để kiểm tra phân tích, khuyến nghị, phiên và truy vấn bằng chứng của nó. 2. Xác nhận, gán, bác bỏ, tắt tiếng, giải quyết hoặc mở lại phát hiện sau khi kiểm tra bằng chứng của nó. 3. Đi tới **Analyze → Issues** và lọc hộp thư thoại durable theo trạng thái, mức độ nghiêm trọng hoặc người được gán. 4. Mở vấn đề để gán nó, thêm nhận xét hoặc người theo dõi, và giải quyết nó sau khi sửa chữa được xác minh. Bắt đầu với tóm tắt phát hiện. Xác nhận rằng mô tả lỗi, phản ứng được đề xuất, mức độ nghiêm trọng và xếp hạng phù hợp với các phiên mà bạn dự kiến kiểm toán sẽ kiểm tra. Một phát hiện kiểm toán với mức độ nghiêm trọng, số lần xảy ra, phân tích nguyên nhân gốc rễ, hành động được đề xuất, các yếu tố xếp hạng và bằng chứng. Tiếp theo, mở một phiên bị ảnh hưởng thay vì chỉ quyết định từ tóm tắt. Dấu vết liên kết sẽ hiển thị sự kiện chính xác và tải trọng hỗ trợ phát hiện. Một phiên được liên kết từ một phát hiện kiểm toán, được mở tại lỗi liên quan với siêu dữ liệu sự kiện và tải trọng thô. Sau khi xác minh bằng chứng, sử dụng Issues để gán người sở hữu cho phản ứng và theo dõi nó độc lập với các lần chạy kiểm toán trong tương lai. Hộp thư Issues hiển thị công việc đang hoạt động, được xác nhận và đã giải quyết với mức độ nghiêm trọng và quyền sở hữu. Mở vấn đề để ghi lại ghi chú điều tra, thông báo cho những người theo dõi và bảo tồn lịch sử phản ứng. Chỉ giải quyết nó sau khi khắc phục được triển khai và xác minh. Dạng xem chi tiết vấn đề với nguồn, bằng chứng vi phạm, người được gán, những người theo dõi, dòng thời gian và nhận xét của nó. ```bash theme={null} fp audits findings --audit checkout-reliability --status open fp audits finding fp audits ack --reason "owner assigned" fp audits assign --to engineer@example.com fp issues list fp issues show fp issues assign --assignee engineer@example.com fp issues comment-add --body "policy is in observe mode" fp issues resolve --yes ``` Sử dụng `fp issues subscribe `, `fp issues unsubscribe ` và `fp issues subscribers ` để quản lý những người theo dõi. Xem [tham chiếu Cloud CLI kiểm toán và vấn đề](/vi/reference/cloud-cli#audits) để tìm các phát hiện kiểm toán và [`fp issues`](/vi/reference/cloud-cli#issues) để quản lý vấn đề. ## Xem xét một phát hiện Xác nhận rằng nó chứa: * Một chế độ lỗi ổn định, không chỉ là một tiêu đề một lần * Mức độ nghiêm trọng và tác động hoạt động * ID phiên bị ảnh hưởng hoặc truy vấn hỗ trợ * Đủ bối cảnh để tái tạo hành vi * Một phản ứng được đề xuất phù hợp với bằng chứng ## Sử dụng một vấn đề để quản lý phản ứng Tạo hoặc liên kết một vấn đề khi phát hiện cần gán, thảo luận, thay đổi trạng thái, nhận xét hoặc những người theo dõi. Các vấn đề cũng có thể đại diện cho các sự cố cảnh báo và các vấn đề được báo cáo thủ công, đó là lý do tại sao chúng nằm trong phản ứng kiểm toán thay vì ở trong điều hướng chính. Giải quyết vấn đề khi khắc phục được triển khai và xác minh. Giải quyết phát hiện khi chế độ lỗi đã được giải quyết cho dân số kiểm toán. Những lúc đó có thể khác nhau. ## Chuyển một vấn đề thành bản nháp chính sách 1. Mở vấn đề và xác minh phát hiện, phiên được trích dẫn, nguyên nhân gốc rễ và khuyến nghị của nó. 2. Chọn **generate policy** và xem xét kết quả ứng cử và ý định thực thi được đề xuất. Kết quả **no policy** có nghĩa là hành vi có thể yêu cầu cảnh báo, thay đổi quy trình làm việc hoặc phản ứng của con người thay thế. 3. Chọn **write this policy**, sau đó xem xét và kiểm tra mã nguồn được tạo trong **Admin → policy editor** trước khi chọn **publish version**. Sử dụng **open the editor anyway** khi bạn không đồng ý với kiểm tra ứng cử. 4. Đi tới **Admin → enforcement**, triển khai phiên bản ở chế độ **observe** và xác minh các quyết định của nó dưới **Observe → policy** trước khi thực thi nó. Tiêu đề vấn đề, mô tả phát hiện, nguyên nhân gốc rễ, khuyến nghị và ý định ứng cử giúp soạn thảo. Không có gì được xuất bản hoặc triển khai tự động. Sử dụng CLI để kiểm tra bằng chứng trước khi mở vấn đề trong bảng điều khiển: ```bash theme={null} fp issues show fp audits finding fp events --session-id --full --all ``` Ứng cử chính sách, xuất bản Cloud và triển khai bộ là các quy trình bảng điều khiển. Sử dụng `failproofai policies --install --custom ` khi bạn muốn xác thực mã nguồn chính sách tương đương cục bộ trước tiên. Chuyển đổi một mẫu hành động lặp lại được xác nhận thành một phiên bản chính sách.