Глава 19. От SDLC к ADLC¶

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

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

Уникальный артефакт: модель состояний ADLC.

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

Что эта глава не покрывает: правила выпуска, реагирование на находки и реестр владельцев.

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

1. Почему здесь вообще нужно вспоминать классический SDLC¶

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

Это плохая отправная точка.

Классический жизненный цикл разработки ПО по-прежнему нужен, потому что именно он задает базовую инженерную дисциплину:

постановку требований;
дизайн;
реализацию;
тестирование;
выпуск;
эксплуатацию;
вывод из эксплуатации.

NIST в своем ИИ-профиле к SSDF прямо исходит из той же идеи: практики безопасной разработки для генеративного ИИ нужно не изобретать с нуля, а расширять поверх существующей дисциплины безопасной разработки ПО.¹

То есть агентная система не отменяет SDLC. Она делает его недостаточным в исходном виде.

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

2. Что в SDLC остается тем же¶

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

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

Это важный психологический момент для команды: ADLC не должен выглядеть как “магия поверх инженерии”. Он должен выглядеть как взрослая надстройка над уже знакомым SDLC.

3. Что в агентных системах ломает классический процесс¶

Вот здесь и начинается реальная разница.

У обычной системы многое определяется кодом и сравнительно детерминированным поведением. У агентной системы появляется дополнительный слой изменчивости:

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

Именно поэтому NIST AI RMF GenAI Profile подчеркивает, что trustworthiness considerations должны жить не только в момент релиза, а на всем жизненном цикле: design, development, use и evaluation.²

4. ADLC полезно мыслить как SDLC плюс новые поверхности изменений¶

Самая рабочая инженерная рамка здесь простая:

ADLC = SDLC + model behavior + prompts/routines + policies + retrieval/memory + tools + evals + governed autonomy

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

Полезно думать об ADLC как о расширении классического SDLC, а не как о его замене

flowchart LR
    A["Классический SDLC"] --> B["Требования"]
    A --> C["Дизайн"]
    A --> D["Реализация"]
    A --> E["Тестирование"]
    A --> F["Выпуск"]
    A --> G["Эксплуатация"]
    A --> H["Вывод из эксплуатации"]

    H --> I["ADLC добавляет"]
    I --> J["Поведение модели"]
    I --> K["Инструкции и рабочие процедуры"]
    I --> L["Политики и подтверждения"]
    I --> M["Извлечение и память"]
    I --> N["Побочные эффекты инструментов"]
    I --> O["Оценки и управляемая автономия"]

5. Какие артефакты теперь несут риск выпуска¶

В обычном SDLC команда чаще всего спорит вокруг кода, инфраструктуры и схем данных. В ADLC список артефактов, несущих релизный риск, шире:

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

Сквозной кейс: дубли как ADLC-change

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

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

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

6. Почему в ADLC одних тестов уже недостаточно¶

Тесты остаются важными, но их уже мало.

В агентных системах нужен более широкий контур заверения:

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

OpenAI и Anthropic с разных сторон приходят к той же практической мысли: сначала нужна базовая линия поведения, потом управляемые итерации, а не “сразу автономия и посмотрим, что выйдет”.³⁴

7. Отдельный жизненный цикл нужен и для заверения безопасности¶

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

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

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

8. Цепочка поставки агента шире, чем просто пакетные зависимости¶

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

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

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

То есть происхождение в ADLC нужно не “для красоты”, а для нормального управления изменениями и расследования инцидентов, включая восстановление экспортированных свидетельств неудачного запуска, например failure_reason, когда путь выпуска уходит в деградированное состояние.

9. Хороший ADLC начинается не с релиза, а с приема инициативы и архитектурной проверки¶

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

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

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

Вот это уже и есть первые шаги ADLC.

10. Предлагаемая рамка ADLC¶

Для промышленной агентной системы я бы рекомендовал минимум такие стадии:

Прием инициативы и проверка уместности агента
Архитектурная проверка и проверка безопасности
Сборка и интеграция
Базовая линия оценок
Поэтапный выпуск
Устойчивая эксплуатация
Реагирование на инциденты и исправительные действия
Вывод из эксплуатации или замена

ADLC полезно мыслить как непрерывный контур, а не как путь до первой выкладки

flowchart LR
    A["Прием инициативы"] --> B["Архитектурная проверка"]
    B --> C["Сборка и интеграция"]
    C --> D["Базовая линия оценок"]
    D --> E["Поэтапный выпуск"]
    E --> F["Эксплуатация"]
    F --> G["Инциденты и исправительные действия"]
    G --> H["Вывод из эксплуатации или замена"]
    H --> A

11. Чем ADLC полезен команде на практике¶

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

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

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

Именно это и делает ADLC полезным: он превращает разговор про агентов из обсуждения ажиотажа в управляемую инженерную программу.

12. Чего не стоит делать¶

Есть несколько очень частых ошибок:

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

Если так делать, ADLC превращается в красивое слово без операционной пользы.

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

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

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

Если на несколько вопросов подряд ответ “да”, вы уже живете не просто в SDLC, а в ADLC, даже если пока его так не называете.

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

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

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

Что проверить в своей системе: какие артефакты несут риск выпуска; кто владеет переходами состояния; как один инцидент меняет код, политики, оценки и реестр.

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

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

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

Эту главу удобно читать вместе с более ранними разделами про оценки, выкладку и организационную модель: