Достижение надежности рабочих процессов на уровне 99,99%

«Когда у вас есть демо, которое работает в 90% случаев, это всего лишь первые девятки». — Андрей Карпаты

Концепция «пути девяток» (March of Nines) отражает типичную реальность промышленной эксплуатации: первые 90% надежности достигаются с помощью сильной демонстрации, однако каждая последующая «девятка» требует сопоставимых инженерных затрат. Для корпоративных команд именно расстояние между «обычно работает» и «функционирует как надежное ПО» определяет уровень внедрения.

Математика сложных процентов на пути девяток

«Каждая отдельная девятка требует одинакового объема работы». — Андрей Карпаты

Агентские рабочие процессы накапливают сбои. Типичный корпоративный процесс может включать в себя: анализ намерений, извлечение контекста, планирование, один или несколько вызовов инструментов, проверку, форматирование и ведение аудиторского журнала. Если рабочий процесс состоит из n шагов, и каждый шаг завершается успехом с вероятностью p, то общий успех от начала до конца составляет примерно p^n.

В сценарии из 10 шагов вероятность сквозного успеха снижается из-за сбоев на каждом этапе. Коррелирующие сбои (авторизация, лимиты запросов, коннекторы) будут преобладать до тех пор, пока вы не укрепите общие зависимости.

Определение надежности через измеримые SLO

«Гораздо разумнее потратить чуть больше времени на то, чтобы ваши промпты были более конкретными». — Андрей Карпаты

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

• Уровень завершения рабочих процессов (успех или явная эскалация).

• Уровень успешности вызовов инструментов в рамках тайм-аутов со строгой проверкой схемы входных и выходных данных.

• Доля генерируемых структурированных ответов (JSON/аргументы), соответствующих схемам.

• Уровень соблюдения политик (PII, секреты и ограничения безопасности).

• p95 сквозной задержки и стоимость одного рабочего процесса.

• Частота использования запасных вариантов (более безопасная модель, кэшированные данные или проверка человеком).

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

Девять рычагов, которые надежно добавляют «девятки»

1) Ограничение автономии с помощью явного графа процессов

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

• Вызовы моделей находятся внутри конечного автомата или ориентированного ациклического графа (DAG), где каждый узел определяет разрешенные инструменты, максимальное количество попыток и предикат успеха.

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

2) Обеспечение соблюдения контрактов на каждой границе

Большинство сбоев в продакшене начинаются с дрейфа интерфейсов: некорректный JSON, пропущенные поля, неверные единицы измерения или вымышленные идентификаторы.

• Используйте JSON Schema/protobuf для каждого структурированного вывода и проводите валидацию на стороне сервера до выполнения любого инструмента.

• Используйте перечисления (enums), канонические ID, а также нормализуйте время (ISO-8601 + часовой пояс) и единицы измерения (СИ).

3) Многоуровневые валидаторы: синтаксис, семантика, бизнес-правила

Проверка схемы выявляет проблемы с форматированием. Проверки семантики и бизнес-правил предотвращают появление правдоподобных ответов, ломающих системы.

• Семантические проверки: ссылочная целостность, числовые границы, проверка прав доступа и детерминированное соединение по ID, если таковые имеются.

• Бизнес-правила: одобрение для операций записи, ограничения на размещение данных и ограничения для клиентских уровней.

4) Маршрутизация на основе рисков с использованием сигналов неопределенности

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

Используйте сигналы уверенности (классификаторы, проверки на согласованность или верификатор на базе второй модели) для принятия решений о маршрутизации.

• Защищайте рискованные шаги более мощными моделями, дополнительной верификацией или одобрением человека.

5) Проектирование вызовов инструментов как распределенных систем

Коннекторы и зависимости часто являются главной причиной сбоев в агентских системах.

• Применяйте тайм-ауты для каждого инструмента, экспоненциальную задержку со случайным отклонением (jitter), автоматические выключатели (circuit breakers) и ограничения параллелизма.

• Версионируйте схемы инструментов и проверяйте ответы инструментов, чтобы предотвратить скрытые поломки при изменении API.

6) Предсказуемое и наблюдаемое извлечение данных (Retrieval)

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

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

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

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

7) Создание конвейера оценки для продакшена

Последующие «девятки» зависят от быстрого обнаружения редких сбоев и предотвращения регрессий.

8) Инвестиции в наблюдаемость и оперативное реагирование

Когда сбои становятся редкими, скорость диагностики и исправления превращается в главный лимитирующий фактор.

• Выводите трассировки/спаны для каждого шага, сохраняйте обезличенные промпты и вводо-вывод инструментов с надежным контролем доступа, а также классифицируйте каждый сбой в соответствии с таксономией.

• Используйте руководства по устранению неполадок (runbooks) и переключатели «безопасного режима» (отключение рискованных инструментов, переключение моделей, требование одобрения человека) для быстрого устранения последствий.

9) Внедрение ползунка автономии с детерминированными резервными вариантами

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

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

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

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

• Разрабатывайте возобновляемые точки передачи управления: сохраняйте состояние, показывайте план/различия и позволяйте проверяющему одобрить и возобновить работу с точного шага, используя ключ идемпотентности.

Схема реализации: обертка ограниченного шага

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

def run_step(name, attempt_fn, validate_fn, *, max_attempts=3, timeout_s=15):

    # трассировка всех попыток в рамках одного спана

    span = start_span(name)

    for attempt in range(1, max_attempts + 1):

        try:

            # ограничение задержки, чтобы один шаг не мог заблокировать рабочий процесс

            with deadline(timeout_s):

                out = attempt_fn()

# шлюз: схема + семантика + бизнес-инварианты

            validate_fn(out)

            # путь успеха

            metric(«step_success», name, attempt=attempt)

            return out

        except (TimeoutError, UpstreamError) as e:

            # временный сбой: повторная попытка с задержкой во избежание шквала запросов

            span.log({«attempt»: attempt, «err»: str(e)})

            sleep(jittered_backoff(attempt))

        except ValidationError as e:

            # некорректный вывод: повторить попытку один раз в «более безопасном» режиме (ниже температура / строже промпт)

            span.log({«attempt»: attempt, «err»: str(e)})

            out = attempt_fn(mode=»safer»)

    # резервный вариант: обеспечение безопасности системы при исчерпании попыток

    metric(«step_fallback», name)

    return EscalateToHuman(reason=f»{name} failed»)

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

Пробелы в надежности трансформируются в бизнес-риски. Глобальное исследование McKinsey за 2025 год сообщает, что 51% организаций, использующих ИИ, столкнулись как минимум с одним негативным последствием, а почти треть сообщили о последствиях, связанных с неточностью ИИ. Эти результаты стимулируют спрос на более надежные методы измерения, защитные механизмы и операционный контроль.

Заключительный контрольный список

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

• Добавьте контракты и валидаторы для каждого вывода модели и ввода/вывода инструментов.

• Относитесь к коннекторам и извлечению данных как к приоритетным задачам обеспечения надежности (тайм-ауты, автоматические выключатели, канареечные релизы).

• Маршрутизируйте действия с высоким уровнем воздействия через пути с более высокой степенью защиты (верификация или одобрение).

• Превращайте каждый инцидент в регрессионный тест в вашем эталонном наборе.

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

Нихил Мунгел более 15 лет создает распределенные системы и команды разработчиков ИИ в SaaS-компаниях.

Добро пожаловать в сообщество VentureBeat!

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

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