Агенты реагирования на инциденты: доступ к продакшену без хаоса

Агент реагирования на инциденты в продакшене должен сначала расследовать проблему и переходить к восстановлению только после того, как человек подтвердит небольшое именованное действие. Это практическая граница, а не формальность. Во время аварии агент соберет разрозненные сведения быстрее уставшего специалиста, но решение об изменении состояния работающей системы должно оставаться за человеком.

Плохая схема дает агенту оболочку в продакшене, широкую роль в облаке и фразу в регламенте: «действуй по своему усмотрению». Такая схема кажется быстрой, пока агент не перезапустит не тот пул рабочих процессов, не масштабирует сломанное развертывание, не сменит учетные данные, которые еще нужны зависимому сервису, или не превратит локальный сбой в широкую аварию. Хорошая схема дает ему карту диагностики и оставляет настолько короткий список действий восстановления, что человек может понять каждое из них.

Полномочия диагностики и восстановления должны различаться

Диагностика отвечает на вопрос, что произошло. Восстановление говорит системе стать другой. Команды смешивают эти границы, потому что такая команда, как restart, выглядит обычной, а многие панели позволяют с одного экрана и просматривать ресурс, и менять его. Если считать эти возможности одним разрешением, полезный помощник по инцидентам быстро превращается в оператора продакшена с неясной ответственностью.

Диагностические действия не должны менять поведение сервиса. Они могут читать метрики, запрашивать логи за заданный временной интервал, получать метаданные развертываний, проверять эндпоинты состояния, сравнивать ревизии конфигурации и собирать ограниченные сведения из базы данных. Диагностическое действие может раскрыть чувствительную информацию, поэтому ему все равно нужны ограничения и записи аудита. Полномочия менять состояние приложения для него не нужны.

Действия восстановления меняют часть работающей системы. К ним относятся откат, перезапуск, переключение трафика, масштабирование, изменение флагов функций, смена учетных данных, повторная обработка очереди, переключение на резервный контур, исправление базы данных и отключение интеграции. Некоторые действия обратимы, но ни одно из них нельзя считать безвредным по умолчанию. Перезапуск может остановить единственный процесс, удерживающий аренду. Масштабирование способно исчерпать общую зависимость. Повторная обработка очереди может дублировать сообщения клиентов.

При классификации действия используйте такой тест: если повторение того же действия в тот же момент может дать другой результат, потому что оно меняет состояние, отнесите его к восстановлению. Действие также меняет состояние, если оно изменяет кэш, создает обращение в поддержку, отправляет сообщение, меняет отключение оповещений или записывает аннотацию, которую использует другая автоматизация. Не называйте такие операции чтением только потому, что они не обращаются к основной базе данных.

NIST SP 800-61 Revision 2 отделяет сдерживание, устранение последствий и восстановление от обнаружения и анализа. Здесь это разделение особенно полезно. Агент может значительно ускорить обнаружение и анализ. Но как только он предлагает сдерживание или восстановление, ответственный человек должен выбрать действие и принять его последствия. Документ не решает за вас задачу авторизации, зато фазы инцидента не дают создать опасную иллюзию, будто расследование и вмешательство это одна и та же работа.

Роль только для чтения не делает доступ автоматически безопасным. В запросах к логам могут оказаться токены доступа. Атрибуты трассировок способны раскрыть идентификаторы учетных записей. Эндпоинт конфигурации может вернуть учетные данные. Добавьте редактирование и ограничения полей непосредственно в диагностический интерфейс, вместо того чтобы разрешать агенту получать любые необработанные артефакты. Видимость продакшена требует собственной границы.

Давайте агенту вопросы, а не общую оболочку продакшена

Под давлением агент работает лучше, когда его инструменты напрямую выражают вопросы об инциденте. Общая оболочка заставляет агента одновременно изучать систему и безопасный порядок действий, пока время идет. Кроме того, такую работу почти невозможно проверять: kubectl, облачные CLI, клиенты баз данных и SSH умеют гораздо больше, чем требуется для конкретного инцидента.

Сделайте диагностические действия вокруг сведений, которые специалист обычно запрашивает в первые минуты:

• получить уровень ошибок, задержку, насыщение ресурсов и доступность для указанного сервиса и временного диапазона
• найти развертывание, ревизию конфигурации и изменения зависимостей, произошедшие рядом с первой ошибкой
• искать в структурированных логах только по разрешенному набору полей и с ограниченным числом результатов
• проверить состояние и последние события указанного компонента
• сравнить канареечную версию или регион с заведомо исправным аналогом

У каждого действия должен быть узкий контракт входных данных. get_service_errors(service, start, end, group_by) сразу показывает проверяющему, что запросил агент. run_query(text) почти ничего не объясняет и создает возможность для случайного полного сканирования, небезопасных условий или текста запроса, внедренного через промпт.

Задавайте жесткие границы в самом инструменте, а не просите модель помнить о них. Инструмент метрик должен отклонять слишком широкий временной диапазон. Инструмент логов должен ограничивать число возвращаемых записей и удалять настроенные поля до того, как данные попадут к модели. Поиск развертываний должен принимать идентификатор приложения из известного реестра, а не произвольный URL из комментария к задаче. Такие ограничения снижают расходы и не дают инциденту превратиться в канал вывода данных.

Следующий каталог действий намеренно скучный. Во время аварии это комплимент.

incident_actions:
  diagnostics:
    - name: service_summary
      inputs: [service, start_time, end_time]
      limits: {max_window_minutes: 180}
    - name: recent_deployments
      inputs: [service, since_time]
    - name: log_sample
      inputs: [service, start_time, end_time, error_code]
      limits: {max_records: 200, redact_fields: [authorization, cookie, token]}
    - name: dependency_health
      inputs: [dependency, region]
  recovery:
    - name: rollback_release
    - name: set_traffic_weight
    - name: restart_component
    - name: disable_feature_flag

Этот фрагмент предотвращает распространенную ошибку внутренних инструментов: якобы агенту только для чтения дают универсальную точку запросов, потому что так удобнее для первой демонстрации. Позже выясняется, что он может получить все строки логов всех сервисов или вызвать скрытый путь записи. Безопасность создают не названия инструментов. Ее создают проверка входных данных, список разрешений, ограниченный вывод и учетные данные без права записи.

Не давайте диагностическому агенту SSH в продакшен только потому, что через SSH удобно проводить проверку. Доступ к оболочке объединяет чтение файлов, управление процессами, сетевой доступ и часто путь к учетным данным. Если нужно открыть сведения о хосте, предоставьте отдельные команды для проверки процессов, использования диска, выбранных записей журнала или контролируемую оболочку команд. Такая оболочка должна отклонять конвейеры, перенаправления, подстановку команд и произвольные флаги. Инструкция на естественном языке не делает оболочку безопасной.

Каталог восстановления должен быть достаточно коротким для репетиции

Человек не может осмысленно подтверждать бесконечное меню изменений в продакшене. Определите короткий каталог восстановления для каждого класса сервисов, добавьте простые описания, фиксированные параметры, где это возможно, и укажите ответственного владельца. Если действие восстановления нельзя объяснить в одной карточке подтверждения, сначала разложите его на части, и только потом позволяйте агенту его запрашивать.

Разумный каталог может включать откат к последнему одобренному релизу, обнуление доли трафика для одной неисправной ревизии, перезапуск одного указанного компонента без состояния, отключение заранее созданного флага функции или приостановку указанного потребителя. В него не должны входить «произвольное исправление», произвольный SQL, широкие изменения IAM или разовые скрипты, скопированные из разговора с агентом.

До следующего инцидента зафиксируйте для каждого пункта пять фактов:

1. Точно укажите, что изменится, включая среду и область ресурсов.
2. Назовите предварительные условия, которые должен собрать агент, например подтвержденный идентификатор релиза или исправный резервный вариант.
3. Опишите ожидаемое наблюдение после выполнения и максимальное время ожидания до эскалации.
4. Назовите действие отката или компенсации, если оно существует.
5. Назначьте роль человека, который может это подтвердить.

Для параметров каталога нужны ограничения. Формулировка «установить долю трафика» слишком широка. Запрос «установить для ревизии orders-v184 нулевую долю трафика в eu-west после того, как стабильная ревизия будет признана исправной» можно подтвердить. Запрос не должен позволять модели самостоятельно выбрать регион, ревизию и процент без ограничений.

Не создавайте впечатление, будто список действий полный. В нем должны отсутствовать действия, требующие отдельного решения. Исправление миграции базы данных, удаление данных, связь с клиентами, выдача доступов и смена учетных данных часто требуют сведений, которые не может вывести универсальный агент инцидентов. Правильный результат для отсутствующего в списке действия это четкий отказ и сохранение уже собранных сведений.

Короткий каталог также позволяет проводить учения. Запустите учебный инцидент и проверьте, сможет ли назначенный подтверждающий отличить запрос на приостановку потребителя от запроса на удаление его очереди. Если для этого нужно читать исходный код или доверять резюме агента, текст подтверждения недостаточно понятен.

Подтверждение должно связывать точный запрос с человеком и моментом

Подтверждение человека полезно только тогда, когда оно разрешает конкретное предлагаемое действие, а не расплывчатую сессию инцидента. Формулировка «подтвердить исправление для платежей» оставляет агенту возможность выбрать изменение после того, как человек перестал следить за процессом. Привяжите подтверждение к типу действия, цели, параметрам, идентификатору инцидента, личности вызывающего и короткому сроку действия.

В запросе на подтверждение должны быть показаны сведения, поддерживающие действие, но сведения и предлагаемое изменение нужно разделять. Специалисту важно увидеть, что уровень ошибок вырос после релиза 184, предыдущий релиз все еще доступен, а в выбранном регионе хватает ресурсов. Он также должен точно понимать, что произойдет после нажатия кнопки подтверждения.

Используйте объект запроса с неизменяемыми полями и отклоняйте выполнение, если любое одобренное поле изменилось:

{
  "incident_id": "inc-2025-041",
  "action": "rollback_release",
  "target": {"service": "orders", "environment": "production", "region": "eu-west"},
  "parameters": {"from_release": "184", "to_release": "183"},
  "evidence_refs": ["metric:err-17", "deploy:184", "health:183"],
  "requested_by": {"agent_session": "sess-8f2a", "process_identity": "signed-agent-build"},
  "expires_at": "2025-03-08T14:35:00Z"
}

Исполнитель должен вернуть результат, сохранив идентификатор запроса и указав, началось ли действие, завершилось ли оно, завершилось ли ошибкой или истекло ли время ожидания. Сообщение «откат выполнен» слишком расплывчато для временной шкалы инцидента. Агент должен прочитать результат и снова выполнить диагностические проверки. Нельзя считать, что успешный ответ API восстановил сервис.

Не используйте одно раннее подтверждение для всех последующих действий. Усталость от подтверждений реальна, но общее разрешение меняет усталость на неопределенность. Объединяйте только действия с одной целью, ожидаемым результатом и уровнем риска. Человек может одним пакетом подтвердить удаление трафика и откат одного релиза, если оба действия заранее зафиксированы. Но это не должно одновременно разрешать изменение базы данных, смену учетных данных или действие в другом регионе.

Требуйте новое подтверждение, если меняется гипотеза агента. Это помогает остановить распространенный сценарий: сначала агент подозревает развертывание, получает разрешение на откат, затем обнаруживает ошибку базы данных и решает выполнить другое действие по старой авторизации. По сути старое подтверждение уже истекло, даже если формально его срок еще не закончился.

Сессии инцидентов не дают полномочиям в продакшене стать постоянными

Агенту инцидента нужна отдельная от человека-оператора личность, не связанная с текстом его чата. Записывайте, какой исполняемый файл или удаленный процесс запросил доступ, к какому инциденту он относится, какие диагностические действия вызвал и кто подтвердил каждый запрос на восстановление. Без этого разделения разбор после инцидента превращается в поиск по тексту вместо анализа полномочий.

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

Полномочия на время сессии лучше, чем подход, при котором каждый диагностический вызов рассматривается как отдельный промпт. Первый запрос нового процесса агента дает оператору возможность проверить источник запроса и причину его видимости в продакшене. После этого агент может собирать сведения, не запрашивая подтверждение для каждого графика или фрагмента логов. Для восстановления по-прежнему нужно отдельное подтверждение каждого вызова.

Разделение личности агента и личности пользователя особенно важно на общих машинах и в средах, похожих на CI. У человека может быть право реагировать на инциденты, а у скопированного процесса агента или вредоносной оболочки инструмента такого права нет. Если среда это поддерживает, фиксируйте полномочие подписи кода или другую проверяемую личность процесса. Заголовок окна и подпись, введенная пользователем, не являются идентичностью.

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

Не передавайте учетные данные в контекст агента даже временно. Учетные данные, вставленные в промпт, уже нельзя забрать обратно, а агент может повторить их в команде, стенограмме, логе или внешнем запросе. Исполнитель должен хранить учетные данные, выполнять разрешенный вызов API или SSH и возвращать только результат, необходимый для расследования.

Записи аудита должны объяснять и намерение, и выполнение

В заметках об инциденте часто записывают, как люди понимают произошедшее. Но в них редко есть точный запрос агента, полномочия, которые его разрешили, и результат от нижележащей системы. Нужны все четыре элемента. Временная шкала с записью «агент откатил orders» не отвечает на вопросы, запрашивал ли агент откат, подтвердил ли человек релиз 183 и приняла ли система развертывания команду.

Создавайте долговечное событие для создания сессии, диагностического вызова, предложения восстановления, подтверждения или отказа, попытки выполнения, результата, отзыва и завершения сессии. Каждое событие должно содержать временную метку, идентификаторы корреляции, личность процесса, название действия, цель, нормализованные параметры и код результата. Чувствительное содержимое запросов нужно хранить осторожно: аудит должен сохранять смысл, но не превращаться в еще одно неуправляемое хранилище секретов.

Хеш-цепочка позволяет обнаружить последующие изменения, потому что каждая запись содержит хеш предыдущей. Но она не доказывает, что сборщик изначально получил каждое событие. Проектируйте систему с учетом обоих свойств. Сделайте запись событий недоступной для переписывания исполнителем действий, сохраняйте идентификаторы исходных запросов и периодически проверяйте цепочку вне контроля агента.

Офлайн-команда проверки должна возвращать простой результат, который легко изучить:

$ sp audit verify
verified: 1842 records
first sequence: 2025-03-08T12:01:09Z
last sequence:  2025-03-08T14:42:31Z
chain: valid

Sallyport формирует из одного зашифрованного журнала с хеш-цепочкой и журнал сессий, и журнал отдельных действий, а sp audit verify может проверить цепочку поверх шифротекста. Это полезно для доказательств по инциденту: чтобы понять, изменялась ли история, не нужно открывать хранилище.

Не включайте проверку аудита в рабочий цикл агента. Агент может ссылаться на идентификаторы записанных действий, но руководитель инцидента или проверяющий должны иметь возможность самостоятельно изучить запись. Иначе агент, который неверно описывает свои действия, сможет управлять и доказательствами, которые видит специалист.

Неудачный откат показывает, почему сведения должны предшествовать вмешательству

Представьте сервис, в котором вскоре после релиза растет уровень ошибок. Агент замечает совпадение по времени и предлагает откат. Агент с широким доступом к продакшену мог бы сразу его выполнить. Это быстро, но решение может оказаться неверным.

Дисциплинированный агент сначала получает разбивку ошибок по версиям и регионам, записи последних развертываний, состояние зависимостей и насыщение ресурсов. Сведения показывают, что сбой происходит только в одном регионе, но там не работают и новая, и предыдущая ревизии. Откат отнимет время, создаст второе событие развертывания и не устранит аварию зависимости.

Агент не предлагает никаких действий восстановления. Он сообщает, что сбой региональный, а эндпоинт состояния зависимости не отвечает. Затем специалист подтверждает заранее определенное переключение трафика в обход этого региона, если это позволяют доступная емкость и правила работы с данными сервиса. Агент выполняет действие только после подтверждения, наблюдает за новым уровнем ошибок и записывает и запрос, и результат.

Теперь изменим одну деталь. Диагностическое действие возвращает ошибку, потому что запрошенный временной диапазон слишком широк. Агент должен сообщить о неполных сведениях, а не молча повторять запрос с широкой выгрузкой логов. Ограничения не мешают работе во время инцидента. Они не позволяют модели превратить неопределенность в еще более широкий запрос доступа.

Другой вариант еще неприятнее: переключение трафика прошло успешно на уровне API, но уровень ошибок не снизился. Агент не должен сам переходить к перезапуску, откату или смене учетных данных. Он должен собрать следующие разрешенные наблюдения и подготовить новое предложение. Люди тоже принимают плохие решения во время инцидентов, но хотя бы решение должно совпадать с тем, что записано.

Поэтому популярный совет выдавать широкий доступ «только во время инцидентов» не работает. Инциденты снижают внимание, усиливают срочность и часто сопровождаются неполной или вводящей в заблуждение телеметрией. В таких условиях узкие интерфейсы и явные подтверждения становятся еще важнее.

Добавьте пути отказа в регламент до следующей аварии

Безопасному агенту инцидентов нужны четкие условия остановки. В регламенте должно быть сказано, что агент обязан отказать в неописанном изменении, действии за пределами объявленной среды, запросе с отсутствующими предварительными условиями, просроченном подтверждении и любой операции после отзыва сессии. Каждый отказ должен называть условие и сохранять уже собранные сведения.

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

Храните учетные данные восстановления отдельно от диагностических. Если один и тот же ключ позволяет читать логи и удалять очередь, экран подтверждения не исправит исходную проблему полномочий. Исполнитель должен выбирать учетные данные, соответствующие одному действию из каталога. Если система не поддерживает такое разделение, не помещайте ее за автономным агентом, пока не добавите более безопасную точку контроля.

Первое развертывание этой схемы в продакшене должно охватывать знакомый сбой с узким способом исправления. Выберите сервис, где специалисты уже используют небольшой набор запросов на чтение и одно хорошо понятное действие восстановления. Измерьте, сокращает ли агент время на сбор сведений, понимают ли подтверждающие запросы без чтения стенограммы и позволяет ли запись аудита восстановить ход события. Расширяйте каталог только после того, как эти ответы подтвердятся на учениях.

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