Отстранявайте дефекти с проверими хипотези

Опишете неуспеха, преди да предлагате поправка

Полезното искане за отстраняване на дефект посочва очакваното поведение, наблюдаваното поведение и засегнатия обхват. Включете версията, съответните входни данни и грешката. Премахнете данните за удостоверяване и частните записи от логовете, преди да ги предоставите на AI инструмент.

„Експортът не работи“ дава малко насоки. По-добро описание е: „Експортът успява локално. В staging същата заявка от мениджър връща 403 след последното внедряване. Другите маршрути все още работят.“

Това описание не установява причината. То определя разлики, които могат да насочат проучването.

Запазете няколко възможни обяснения

Поискайте от агента малък набор правдоподобни причини и доказателствата за всяка. Не го карайте да се придържа към първото убедително обяснение.

При измисления неуспешен експорт възможните причини включват липсващо право на служебната идентичност, променено съответствие на роли или заявка към грешната среда. Всяко обяснение предполага различни доказателства.

Таблицата е отправна точка. Отговор 403 може да идва от различни слоеве. Определете кой компонент го е създал, преди да приемете, че проверката на правата в приложението е отказала достъп.

Изберете безопасно наблюдение

Започнете с наблюдение, което може да разграничи обясненията при нисък разход. Сравнете внедрената версия и конфигурацията без тайни стойности. Прегледайте съответната грешка и идентификатора на заявката. Възпроизведете проблема в разрешена тестова среда, когато е възможно.

Не предоставяйте широки права само за да видите дали грешката изчезва. Това действие променя границата на сигурността и може да скрие действително липсващото право. Не поставяйте пълен продукционен лог в модела, когато са достатъчни текст на грешката с премахната чувствителна информация и пътят на заявката.

Посочете какво би отслабило всяка хипотеза. Това помага на агента да преразгледа обяснението си, вместо да защитава първия си отговор.

Променяйте по една причина

След като доказателствата определят вероятна причина, направете целева поправка. Избягвайте да комбинирате промяна на права, обновяване на библиотека и пренаписване на обработчик. Ако симптомът изчезне, няма да знаете коя промяна е имала значение.

Проверете първоначалното условие за неуспех. Проверете и съседната граница. Ако поправите достъпа за мениджър, потвърдете, че потребител без право все още получава отказ.

За повтарящ се дефект добавете регресионна проверка в слоя, който може да го открива. Unit тест не може да открива всяка грешка в конфигурацията на внедряването. Някои неуспехи изискват интеграционна проверка или контролирана проверка след внедряване.

Спрете повторните опити без нови доказателства

Агент може да генерира много варианти на поправка. Повече опити не подобряват непременно диагностиката. Ако същият неуспех се повтаря, попитайте какво ново наблюдение ще даде следващият опит.

Задайте ограничение на времето или броя опити за несигурно проучване. При достигането му докладвайте текущите доказателства, отхвърлените хипотези и нерешения въпрос. Този запис позволява на друг човек да продължи, без да повтаря същите експерименти.

След възстановяване запишете причината и условието, което е позволило тя да достигне засегнатата среда. Поправката отстранява непосредствения дефект. Полезните последващи действия намаляват вероятността същият неуспех да се повтори.