Как безопасно восстановить корпоративного ИИ после сбоя

База восстановилась, веб-интерфейс открылся, агент снова отвечает. Через несколько минут клиенты получают старые уведомления, в очереди появляются вчерашние задания, а поиск показывает документы с прежними правами доступа. Сервер вернулся в строй. Рабочее состояние компании восстановилось лишь частично.

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

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

Определите, что именно должно пережить сбой

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

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

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

Разделите допустимую потерю и время возврата

Два полезных понятия – RPO (Recovery Point Objective, целевая точка восстановления) и RTO (Recovery Time Objective, целевое время восстановления). Первое задаёт, какую глубину потери последних изменений бизнес готов допустить. Второе – за какое время требуется вернуть оговорённую работоспособность. Это цели проектирования и проверки, а не свойства, которые появляются после включения резервного копирования.

Если есть пригодная непрерывная последовательность журналов базы, данные можно восстановить ближе к моменту сбоя. В PostgreSQL для восстановления на выбранный момент используют базовую копию и необходимые WAL (Write-Ahead Log, журнал предзаписи). Но восстановление базы само по себе не возвращает соответствующую версию внешнего файлового хранилища и не отменяет операции, выполненные в сторонней системе.

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

Согласуйте копии базы и файлов

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

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

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

Не копируйте файлы работающей базы произвольным архиватором в надежде получить корректный снимок. Используйте поддерживаемый выбранной СУБД способ резервирования и проверяйте его восстановлением. Журналы PostgreSQL также не заменяют резервирование конфигурационных файлов сервера, которые изменяются вне обычных SQL-операций.

Возвращайте среду сначала без внешних действий

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

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

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

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

Изолированное восстановление позволяет проверить комплект копии до подключения рабочих интеграций. Изображение: AiHummer

Сверьте окно расхождений с внешним миром

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

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

Не поручайте языковой модели угадывать статус по переписке. Она может собрать доступные признаки и подготовить материал для сверки. Разрешение на повторный побочный эффект должно опираться на проверку состояния и контракт конкретного инструмента.

Входящие события тоже требуют порядка

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

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

Перепроверьте доступ и знания до ответа клиенту

Восстановленная система может вернуть старую роль сотрудника или прежнее разрешение на документ. За время после копии человек мог сменить подразделение, организация могла отключить интеграцию, а документ – выйти из использования.

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

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

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

Сохраните совместимую версию приложения

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

Сохраняйте доступный для развёртывания пакет приложения, сведения о миграциях и зависимости, необходимые для выбранного режима. Если поисковое представление зависит от модели эмбеддингов, укажите её идентификатор и параметры. Индекс, построенный другой моделью, может потребовать полного пересоздания; это влияет на время возврата поиска.

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

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

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

Проведите учение на реальном размере данных

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

Проверьте небольшой, заранее составленный набор сценариев:

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

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

Общая платформа помогает собрать план восстановления

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

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

AiHummer объединяет агентов, память, знания и корпоративные инструменты; конкретная схема резервирования зависит от выбранного размещения и подключений. Описанные здесь manifest, сверка операций и порядок открытия полномочий являются требованиями к проектируемому процессу. Их нельзя считать автоматически реализованными без проверки установленной конфигурации.

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

Изображение на обложке: AiHummer