Организационное состояние можно восстановить. Организационное разрешение — нельзя.

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

Базовое правило восстановления должно быть простым: организационное состояние можно восстановить; организационное разрешение — нельзя. Восстановленный runtime может вернуть устойчивые доказательства и незавершённую работу, но исполнимые полномочия нужно заново проверить по действующим плоскостям идентичности и политик. Это не означает, что нельзя хранить в бэкапе учётные данные или записи токенов. Это означает, что наличие таких данных в снимке не должно становиться решением об авторизации.

Контрольная точка должна описывать организацию, а не только её базу данных

Корректная контрольная точка начинается с более полного определения состояния. Чанди и Лэмпорт определяют глобальное состояние распределённой системы как совокупность состояния процессов и каналов связи; один из вариантов применения этой модели — контрольные точки. Поэтому для автономной организации образ runtime, сохранивший строки workflow, но не включивший ожидающие сообщения, может не представлять согласованное организационное состояние. Сообщение в пути может определять, остаётся ли обязательство открытым или действие лишь выглядит никем не запрошенным.

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

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

Восстанавливайте в карантин, а не в исполнение

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

Например, HashiCorp предписывает тестировать восстановление снимка Vault в изолированной сети: восстановленный экземпляр может взаимодействовать с действующими учётными данными третьих сторон, в том числе пытаться отозвать их с последствиями для production. Смысл шире конкретного продукта. Состояние управляющей плоскости не становится инертным только потому, что пришло из резервной копии. Когда возвращаются сеть и исполнители, историческое состояние может породить новые внешние эффекты.

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

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

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

Это различие соответствует уже существующему поведению систем авторизации. Отзыв токена OAuth 2.0 может сделать недействительным сам токен, связанные с ним токены или исходный грант авторизации. Восстановленная запись токена не доказывает, что сервер авторизации по-прежнему признаёт этот грант. Аналогично Vault документирует динамические секреты и сервисные токены со сроками действия, правилами продления и отзыва. Сохранённое состояние аренды — это свидетельство прошлого условия, а не доказательство текущей исполнимости.

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

Аннулируйте прошлое, прежде чем принять настоящее

Архитектуре восстановления также нужна граница эпохи. Kubernetes отмечает, что снимок etcd содержит всё состояние Kubernetes и критически важную информацию; процедура восстановления останавливает API-серверы и перезапускает компоненты control plane, чтобы они не продолжали работу на устаревшем состоянии. Документация etcd по аварийному восстановлению дополнительно предупреждает: восстановление более старой ревизии может оставить контроллеры и кэширующих клиентов в непредсказуемом или несогласованном состоянии. Поэтому рекомендуются повышение ревизии и маркеры compaction для инвалидирования watch и кэшей.

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

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

Сверяйте эффекты, а не воспроизводите намерения

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

NIST SP 800-53 разделяет резервное копирование, восстановление и реконституцию. Его меры включают проверку целостности и тестовое восстановление, восстановление транзакций и компенсирующие меры безопасности. Для этой архитектуры это верная позиция: успешное восстановление — управляемый процесс валидации, а не операция копирования файлов. Для эффектов с высокими последствиями неразрешённая классификация должна блокировать автоматизацию, а не поощрять оптимистичный повтор.

Сделайте решение о восстановлении проверяемым

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

Манифест превращает технический перезапуск в подотчётный организационный переход. Операторы могут понять, почему workflow возобновился. Аудиторы — отличить старый грант от вновь выданного. Исполнитель нижестоящего уровня может потребовать подтверждение, что восстановленная задача корректно пересекла границу восстановления. Главное же — организация получает ясный ответ на вопрос, который обычные метрики восстановления оставляют без ответа: чему именно вновь разрешили действовать?

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