Налагоджуйте за допомогою перевірюваних гіпотез

Опишіть збій перед пропозицією виправлення

Корисний запит на налагодження описує очікувану поведінку, спостережувану поведінку та межі впливу. Додайте версію, відповідні вхідні дані й помилку. Вилучіть облікові дані та приватні записи з журналів перед наданням інструменту ШІ.

«Експорт зламався» майже не дає напрямку. Кращий опис: «Локально експорт успішний. У staging той самий запит менеджера повертає 403 після останнього розгортання. Інші маршрути досі працюють».

Цей опис не встановлює причини. Він визначає відмінності, які можуть спрямувати дослідження.

Зберігайте кілька можливих пояснень

Попросіть агента запропонувати невеликий набір правдоподібних причин і докази для кожної. Не просіть його одразу обрати перше переконливе пояснення.

Для вигаданого збою експорту можливі причини включають відсутнє право сервісної ідентичності, змінене зіставлення ролей або запит до неправильного середовища. Кожне пояснення передбачає інші докази.

Таблиця — відправна точка. Відповідь 403 може походити з різних рівнів. Визначте компонент, який її створив, перш ніж припускати збій авторизації застосунку.

Оберіть безпечне спостереження

Почніть зі спостереження, яке недорого розрізняє пояснення. Порівняйте розгорнуту версію та конфігурацію без секретів. Перевірте відповідну помилку й ідентифікатор запиту. За можливості відтворіть проблему в дозволеному тестовому середовищі.

Не надавайте широких прав лише для того, щоб подивитися, чи зникне помилка. Така дія змінює межу безпеки та може приховати конкретне відсутнє право. Не вставляйте в модель повний журнал продуктивного середовища, коли достатньо повідомлення про помилку з вилученими чутливими даними та шляху запиту.

Вкажіть, що послабило б кожну гіпотезу. Це допомагає агенту переглядати пояснення, а не захищати першу відповідь.

Змінюйте по одній причині

Коли докази вкажуть імовірну причину, внесіть цільове виправлення. Не поєднуйте зміну прав, оновлення бібліотеки та переписування обробника. Якщо симптом зникне, ви не знатимете, яка зміна вплинула.

Перевірте початкову умову збою. Також перевірте сусідню межу. Якщо виправляєте доступ менеджера, підтвердьте, що користувач без відповідного права все ще отримує відмову.

Для повторюваного дефекту додайте регресійну перевірку на рівні, який може його виявити. Модульний тест не може виявити кожну помилку конфігурації розгортання. Деякі збої потребують інтеграційної перевірки або контрольованої перевірки після розгортання.

Припиняйте повторні спроби без нових доказів

Агент може згенерувати багато варіантів виправлення. Більше спроб не обов’язково покращує діагностику. Якщо повторюється той самий збій, запитайте, яке нове спостереження дасть наступна спроба.

Встановіть межу часу або кількості спроб для дослідження з невизначеним результатом. Коли її досягнуто, повідомте поточні докази, відхилені гіпотези та невирішене питання. Цей запис дає іншій людині змогу продовжити без повторення тих самих експериментів.

Після відновлення запишіть причину та умову, яка дозволила їй потрапити в уражене середовище. Виправлення усуває безпосередній дефект. Корисна подальша дія зменшує ймовірність повторення того самого збою.