> ## 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. # Выводы и проблемы > Превращайте аудиторские доказательства в отслеживаемые работы по исправлению. Выводом называется подтвержденное аудитом утверждение об отказе. Проблемой называется устойчивый рабочий процесс для реагирования на него. ## Сортировка и распределение работы 1. Откройте **Analyze → Audits**, выберите завершенный прогон и выберите вывод для проверки его анализа, рекомендаций, сеансов и запросов доказательств. 2. Подтвердите, распределите, отклоните, отключите, разрешите или возобновите вывод после проверки его доказательств. 3. Перейдите в **Analyze → Issues** и отфильтруйте постоянный почтовый ящик по статусу, серьезности или ответственному лицу. 4. Откройте проблему, чтобы распределить ее, добавить комментарии или подписчиков, и разрешите ее после проверки исправления. Начните с краткого описания вывода. Убедитесь, что описание отказа, рекомендуемый ответ, серьезность и рейтинг соответствуют сеансам, которые должна была проверить аудит. Вывод аудита с серьезностью, количеством случаев, анализом первопричин, рекомендуемым действием, факторами рейтинга и доказательствами. Затем откройте затронутый сеанс вместо принятия решения только на основе краткого описания. Связанная трассировка должна показать точное событие и полезные данные, которые подтверждают вывод. Сеанс, связанный с выводом аудита, открытый в соответствующей ошибке с метаданными события и необработанной полезной нагрузкой. После проверки доказательств используйте Issues, чтобы назначить ответственного за ответ и отследить его независимо от будущих прогонов аудита. Почтовый ящик Issues, показывающий активные, подтвержденные и разрешенные работы с серьезностью и ответственностью. Откройте проблему, чтобы записать заметки о расследовании, уведомить подписчиков и сохранить историю ответов. Разрешите ее только после развертывания и проверки исправления. Представление детального описания проблемы с ее источником, доказательствами нарушения, ответственными, подписчиками, временной шкалой и комментариями. ```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 ``` Используйте `fp issues subscribe `, `fp issues unsubscribe ` и `fp issues subscribers ` для управления наблюдателями. См. [справочник Cloud CLI по аудитам и проблемам](/ru/reference/cloud-cli#audits) для выводов аудита и [`fp issues`](/ru/reference/cloud-cli#issues) для управления проблемами. ## Проверка вывода Убедитесь, что он содержит: * Стабильный режим отказа, а не только разовое название * Серьезность и операционное воздействие * Затронутые идентификаторы сеансов или вспомогательные запросы * Достаточный контекст для воспроизведения поведения * Предложенный ответ, который соответствует доказательствам ## Использование проблемы для управления ответом Создайте или свяжите проблему, когда вывод требует распределения, обсуждения, изменения статуса, комментариев или подписчиков. Проблемы также могут представлять инциденты оповещений и вручную сообщаемые проблемы, поэтому они находятся под ответом на аудит, а не в основной навигации. Разрешите проблему, когда исправление развернуто и проверено. Разрешите вывод, когда режим отказа был устранен для аудиторской совокупности. Эти моменты могут отличаться. ## Превращение проблемы в черновик политики 1. Откройте проблему и проверьте ее вывод, цитируемые сеансы, первопричину и рекомендацию. 2. Выберите **generate policy** и проверьте результат применимости и предложенное намерение принудительного применения. Результат **no policy** означает, что поведение может требовать оповещения, изменения рабочего процесса или ручного ответа. 3. Выберите **write this policy**, затем проверьте и протестируйте созданный источник в **Admin → policy editor** перед выбором **publish version**. Используйте **open the editor anyway**, если вы не согласны с проверкой применимости. 4. Перейдите в **Admin → enforcement**, разверните версию в режиме **observe** и проверьте ее решения в **Observe → policy** перед принудительным применением. Название проблемы, описание вывода, первопричина, рекомендация и намерение применимости помогают составить черновик. Ничего не публикуется и не развертывается автоматически. Используйте CLI для проверки доказательств перед открытием проблемы в панели управления: ```bash theme={null} fp issues show fp audits finding fp events --session-id --full --all ``` Применимость политики, публикация в облаке и развертывание парка — это рабочие процессы панели управления. Используйте `failproofai policies --install --custom `, когда хотите сначала локально проверить эквивалентный источник политики. Преобразуйте подтвержденный, повторяемый шаблон действий в версию политики.