Глава 23. Вывод из эксплуатации, замена и дисциплина завершения жизненного цикла¶

Роль главы в части VIII

Главный вопрос: как безопасно закрыть или заменить агентную систему без оставленных полномочий.

Уникальный артефакт: план вывода из эксплуатации или замены.

Граница с соседними главами: вывод из эксплуатации закрывает старые права действовать.

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

Продолжение сквозного сценария: старый путь записи заявок поддержки лишается возможности действовать после замены.

1. Почему зрелая агентная система должна уметь не только запускаться, но и уходить¶

Очень многие команды мыслят жизненный цикл примерно так:

придумать систему;
построить ее;
защитить ее;
наблюдать за ней;
безопасно выкатывать изменения.

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

Для агентных систем это особенно важно, потому что они обычно оставляют за собой длинный рабочий хвост:

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

То есть вывод из эксплуатации здесь — это не “удалили сервис и забыли”. Это управляемый рабочий процесс.

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

2. Когда вообще пора думать о выводе из эксплуатации¶

Полезно перестать воспринимать вывод из эксплуатации как нечто далекое и неприятное.

На практике триггерами часто становятся:

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

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

3. Вывод из эксплуатации и замена — это не одно и то же¶

Полезно разделять два сценария:

вывод из эксплуатации (retirement): система или возможность просто выводится из эксплуатации;
замена (replacement): старая система снимается, но перед этим или параллельно ее заменяет новая.

Это важное различие.

При выводе из эксплуатации главный вопрос: как безопасно убрать систему.

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

4. Главная опасность — тихо оставить за системой право действовать¶

Одна из самых неприятных рабочих ошибок устроена так:

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

То есть формально система уже “мертвая”, а по факту она все еще может делать действия.

Для агентных систем это особенно опасно, потому что автономные и полуавтономные пути исполнения очень легко забыть.

Сквозной кейс: старый пишущий путь тикета после замены

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

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

5. Вывод из эксплуатации должен идти по слоям¶

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

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

Вывод из эксплуатации лучше делать как последовательное сужение рабочей поверхности системы

flowchart LR
    A["Заморозить поэтапный выпуск"] --> B["Отключить рискованные возможности"]
    B --> C["Отключить записи и фоновые задачи"]
    C --> D["Отозвать исходящий доступ и принципалы"]
    D --> E["Архивировать контрольный след и состояние памяти"]
    E --> F["Пометить систему как выведенную"]

6. Память и контрольные данные требуют отдельной дисциплины¶

Когда система уходит, сразу появляется неудобный вопрос: что делать с накопленным состоянием?

Обычно здесь нужно отдельно решить:

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

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

7. Замена должна быть поэтапной, а не бинарным переключением¶

Когда старую систему заменяет новая, соблазн велик: “переключим и поедем дальше”.

Для агентных систем это рискованный путь.

Полезнее поэтапная замена:

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

8. Старые возможности и схемы нужно уметь официально объявлять устаревшими¶

Полезно иметь не только утвержденный реестр, но и реестр устаревших элементов.

Например:

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

Это важно, потому что вывод из эксплуатации почти всегда начинается не с выключения, а с ясного сигнала:

“это больше не считается нормальным путем”.

9. Переход, видимый пользователю, тоже часть жизненного цикла¶

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

Полезно отдельно продумать:

кого нужно предупредить;
какие потоки изменятся;
какие ожидания надо переустановить;
какие резервные пути появятся;
как временно поддерживать старые интеграции.

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

10. Пример политики вывода из эксплуатации¶

Ниже очень рабочий каркас:

retirement:
  triggers:
    - deprecated_runtime
    - unsafe_capability_pattern
    - maintenance_cost_exceeded
    - replacement_ready
  required_steps:
    - freeze_rollout
    - disable_risky_capabilities
    - stop_memory_write
    - expire_paused_runs
    - stop_background_routes
    - freeze_reinitialization
    - disable_deprecated_patterns
    - revoke_worker_capability_exposure
    - retire_verifier_contracts
    - revoke_egress
    - archive_audit_state
    - set_retired_status

Это полезно не потому, что YAML “решает проблему”, а потому что вывод из эксплуатации превращается в явный операционный контракт.

11. Пример проверки готовности к замене¶

Ниже каркас, который показывает правильный тип проверки:

from dataclasses import dataclass


@dataclass
class ReplacementState:
    shadow_eval_passed: bool
    migration_plan_ready: bool
    risky_capabilities_disabled: bool
    archive_plan_ready: bool
    paused_runs_drained: bool
    capability_sessions_resolved: bool


def ready_for_replacement(state: ReplacementState) -> bool:
    return (
        state.shadow_eval_passed
        and state.migration_plan_ready
        and state.risky_capabilities_disabled
        and state.archive_plan_ready
        and state.paused_runs_drained
        and state.capability_sessions_resolved
    )

Смысл здесь в том, что замена тоже должна иметь шлюз, а не быть “переключением по настроению”.

12. Что чаще всего ломается в дисциплине завершения жизненного цикла¶

Проблемы здесь довольно повторяемые:

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

Именно такие мелочи превращают “почти завершенный” жизненный цикл в источник новых инцидентов.

13. Быстрый тест зрелости дисциплины завершения жизненного цикла¶

Команде не стоит думать, что она умеет делать вывод из эксплуатации, только потому, что умеет отвести трафик в сторону и пометить систему как устаревшую.

Более сильная планка такая:

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

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

14. Практический чеклист¶

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

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

Если на несколько вопросов подряд ответ “нет”, значит жизненный цикл у тебя пока все еще заканчивается на релизе, а не на реальной эксплуатации.

Шаблон завершения главы

Что запомнить: вывод из эксплуатации — это закрытие права действовать, а не удаление старого агента из интерфейса.

Типичные ошибки: забывать старые токены и подтверждения; оставлять фоновые повторы; не закрывать память, корпус, уведомления и трассы вместе с кодом.

Что проверить в своей системе: какие старые возможности еще могут действовать; какие подтверждения висят; где зафиксирован план замены и финальное состояние реестра.

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

Что читать дальше: переходи к Главе 24, чтобы увидеть, как переходные состояния становятся поверхностью агентного риска.

15. Что читать дальше¶

Эта глава замыкает часть VIII в цельный операционный цикл:

SDLC -> ADLC;
управление изменениями;
контур заверения;
управление артефактами;
вывод из эксплуатации и замена.

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

16. Полезные справочные страницы¶

Anthropic, Harness design for long-running application development. ↩