Debug bằng giả thuyết có thể kiểm tra

Mô tả lỗi trước khi đề xuất cách sửa

Yêu cầu debug hữu ích nêu hành vi mong đợi, hành vi quan sát được và phạm vi ảnh hưởng. Bao gồm phiên bản, đầu vào liên quan và lỗi. Loại thông tin xác thực và bản ghi riêng tư khỏi log trước khi đưa vào công cụ AI.

“Chức năng xuất bị hỏng” không cho nhiều hướng điều tra. Mô tả tốt hơn là: “Xuất dữ liệu thành công ở môi trường cục bộ. Trong staging, cùng yêu cầu của người quản lý trả về 403 sau lần triển khai mới nhất. Các route khác vẫn hoạt động.”

Mô tả này chưa xác định nguyên nhân. Nó chỉ ra khác biệt có thể định hướng điều tra.

Giữ nhiều cách giải thích để kiểm tra

Yêu cầu agent đưa ra một nhóm nhỏ nguyên nhân hợp lý cùng bằng chứng cho từng nguyên nhân. Đừng yêu cầu agent chốt cách giải thích đầu tiên nghe thuyết phục.

Với lỗi xuất dữ liệu giả định, nguyên nhân có thể gồm thiếu quyền của danh tính dịch vụ, thay đổi ánh xạ vai trò hoặc gửi yêu cầu tới sai môi trường. Mỗi cách giải thích dự đoán bằng chứng khác nhau.

Bảng là điểm bắt đầu. Phản hồi 403 có thể xuất phát từ nhiều lớp. Xác định thành phần tạo phản hồi trước khi cho rằng phân quyền ứng dụng bị lỗi.

Chọn quan sát an toàn

Bắt đầu với quan sát có thể phân biệt cách giải thích mà ít tốn kém. So sánh phiên bản đã triển khai và cấu hình không chứa secret. Kiểm tra lỗi liên quan và định danh yêu cầu. Tái hiện vấn đề trong môi trường thử nghiệm được phép khi có thể.

Không cấp quyền rộng chỉ để xem lỗi có biến mất không. Hành động đó thay đổi ranh giới bảo mật và có thể che quyền thực sự còn thiếu. Không dán toàn bộ log production vào mô hình nếu chỉ cần thông báo lỗi đã loại dữ liệu nhạy cảm và đường đi của yêu cầu.

Nêu điều gì sẽ làm giảm khả năng đúng của từng giả thuyết. Điều này giúp agent sửa cách giải thích thay vì bảo vệ câu trả lời đầu tiên.

Xử lý từng nguyên nhân một

Sau khi bằng chứng chỉ ra nguyên nhân có khả năng đúng, tạo bản sửa có trọng tâm. Tránh gộp thay đổi quyền, nâng cấp thư viện và viết lại handler. Nếu triệu chứng biến mất, bạn sẽ không biết thay đổi nào có tác dụng.

Kiểm chứng điều kiện lỗi ban đầu. Cũng kiểm tra ranh giới liền kề. Nếu sửa quyền truy cập cho người quản lý, xác nhận người dùng không có quyền vẫn bị từ chối.

Với lỗi lặp lại, thêm kiểm tra hồi quy ở lớp có thể phát hiện lỗi. Unit test không phát hiện được mọi lỗi cấu hình triển khai. Một số lỗi cần kiểm tra tích hợp hoặc kiểm chứng có kiểm soát sau triển khai.

Dừng thử lặp lại khi không có bằng chứng mới

Agent có thể tạo nhiều biến thể của bản sửa. Nhiều lần thử hơn không nhất thiết cải thiện chẩn đoán. Nếu cùng lỗi lặp lại, hãy hỏi lần thử tiếp theo sẽ cung cấp quan sát mới nào.

Đặt giới hạn thời gian hoặc số lần thử cho cuộc điều tra chưa chắc chắn. Khi tới giới hạn, báo cáo bằng chứng hiện tại, giả thuyết đã loại và câu hỏi chưa giải quyết. Hồ sơ này giúp người khác tiếp tục mà không lặp lại cùng thí nghiệm.

Sau khôi phục, ghi nguyên nhân và điều kiện đã cho phép lỗi đi tới môi trường bị ảnh hưởng. Bản sửa loại bỏ lỗi trước mắt. Hành động tiếp theo hữu ích làm giảm khả năng lỗi đó quay lại.