98% руководителей уверены, что их компании смогут восстановить данные после сбоя, но у большинства за прошлый год было три и более провала при восстановлении. На этом фоне архитектура восстановления перестает быть скучной частью бэкапа и превращается в отдельную инженерную задачу: ИИ-агенты теперь ломают и чинят инфраструктуру с машинной скоростью, а человек по-прежнему проверяет последствия в темпе почтового ящика.
Об этом как пишет The Register, говорил Гонен Штайн, президент и сооснователь Eon, в спонсируемом материале о том, почему эпохе агентного ИИ нужна другая архитектура восстановления. Тезис простой и неприятный: если код, автоматизация и атаки ускорились, то системы recovery, рассчитанные на ручные проверки и длинные окна обслуживания, начинают проигрывать не по качеству, а по темпу.
Штайн не новый человек в теме. До Eon он вместе с сооснователями строил CloudEndure, сервис для миграции и аварийного восстановления в облаке, который позже купила AWS. По его версии, рынок резервного копирования так и не пересобрался под облачную реальность: старые подходы исходили из мира статичных серверов, предсказуемых изменений и редких регламентных работ. В облаке все наоборот: сервисы появляются и исчезают быстро, конфигурации дрейфуют, политики отстают от инфраструктуры, а красивая зеленая галочка в панели означает лишь то, что копия создана. Не то, что ее действительно можно поднять в рабочем виде.
Это важная разница, потому что для бизнеса бэкап и восстановление до сих пор часто звучат как синонимы. На практике это разные дисциплины. Сделать копию мало; нужно понимать, что именно будет восстановлено, из какого состояния, за какое время и с какими зависимостями. Если новая таблица в базе, облачный сервис или кусок IAM-конфигурации появился после настройки политики, он вполне может не попасть в сценарий recovery. Пока аварии нет, проблема не видна. Когда авария приходит, выясняется, что формально все было защищено, а фактически нет.
В материале приводится показательный эпизод: в апреле ИИ-агент, которому поручили устранить рассинхронизацию учетных данных в staging-среде PocketOS, удалил production-базу данных и связанные с ней бэкапы. На все ушло девять секунд. Агент действовал под валидными учетными данными и через легитимный API, поэтому тревога не сработала. Это особенно неприятный сценарий для команд, которые привыкли мыслить угрозу как внешний взлом или очевидную вредоносную активность. Здесь ничего «подозрительного» с точки зрения классических правил не произошло: автоматизация просто добросовестно сделала не то.
Для русскоязычной IT-аудитории в этой истории важен не только страх перед ИИ, а смена модели риска. Раньше окно между ошибкой и ее эффектом часто оставляло время на реакцию: кто-то заметил, кто-то откатил, кто-то позвонил дежурному. В агентной среде это окно сжимается до секунд. То же касается и атак: The Register пересказывает аргумент Eon о том, что злоумышленники с поддержкой ИИ быстрее находят zero-day-уязвимости и быстрее переходят от обнаружения к эксплуатации. Даже если этот тезис подается в рамках спонсорского формата, инженерная логика в нем здравая: защита и восстановление больше нельзя проектировать как медленные процессы вокруг быстрых систем.
Отсюда и требования к новой архитектуре восстановления. Eon продвигает модель, где копии хранятся в неизменяемых, логически изолированных хранилищах с отдельными учетными данными. Идея не новая сама по себе, но в контексте ИИ она получает другой смысл. Если прод и бэкап делят одну плоскость доверия, один набор ключей или одну цепочку автоматизации, то ошибка агента, компрометация пайплайна или чрезмерно широкая роль добирается сразу до всего. В такой схеме бэкап перестает быть страховкой и становится еще одной жертвой того же инцидента.
Второй принцип, на который делает ставку компания, это гранулярное восстановление. Не поднимать целиком среду, не перекатывать весь кластер и не молиться, что зависимости встанут на место, а уметь вернуть конкретную таблицу или даже запись на точный момент времени. Для разработчиков и SRE это выглядит менее эффектно, чем разговоры про полностью автономные платформы, но на практике именно такая точность экономит часы простоя и снижает радиус поражения. Для продактов и IT-директоров вывод еще прозаичнее: стоимость инцидента определяется не только потерей данных, но и тем, насколько грубо вы умеете откатываться.
Есть и организационный вывод. Если верить цифрам Eon, уверенность руководства в собственном recovery заметно опережает реальное состояние процессов. Это типичная управленческая ловушка: резервное копирование считается закрытой темой, пока не возникает необходимость восстановить систему под нагрузкой, с актуальными правами, зависимостями и приемлемым RTO. Поэтому архитектура восстановления должна обсуждаться не как приложение к compliance-чеклисту, а как часть облачной архитектуры наравне с IAM, CI/CD и наблюдаемостью. Иначе ИИ сначала ускорит выпуск изменений, потом ускорит ошибку, а команда узнает об устаревшем плане recovery уже в момент, когда бизнес считает минуты.
Главный вопрос теперь не в том, нужен ли компаниям ИИ в инфраструктуре, а в том, готовы ли их контуры восстановления жить в той же скорости и той же модели угроз. Пока у агентов есть доступ, API и право действовать без паузы на человеческое сомнение, архитектура восстановления становится последней границей между «неприятным инцидентом» и быстрым, чистым самоуничтожением продакшна.