Сапан Пандья, старший инженер-программист и старший член IEEE — серия интервью

Sapan Pandya — старший инженер-программист и старший член IEEE из Нью-Джерси с более чем десятилетним опытом работы с отказоустойчивыми распределёнными транзакционными системами. Его работа охватывает обеспечение целостности транзакций, интеграцию программного обеспечения с физическими устройствами, устранение проблем в рабочей среде и проверку готовности к развёртыванию в регулируемых отраслях. Он получил степень магистра компьютерных наук в Stevens Institute of Technology и участвует в рецензировании научных работ и технических исследованиях.

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

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

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

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

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

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

Этот опыт также влияет на моё отношение к ИИ. Он действительно может помочь инженерам собрать доказательства, выявить закономерности и быстрее разобраться в сбоях. Но предположение о том, что, вероятно, произошло, — не то же самое, что подтверждённые сведения о том, что произошло на самом деле.

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

Вы подчёркивали, что технически корректный код не всегда гарантирует правильный результат транзакции. Можете привести конкретный пример, когда кажется, что транзакция не удалась из-за тайм-аута, хотя на самом деле она завершилась? Что может пойти не так, если система автоматически повторит операцию, и как инженерам не допустить повторного списания?

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

Клиент видит сообщение о тайм-ауте, хотя платёж уже прошёл. Если приложение отправит новый запрос на оплату, с клиента могут списать деньги повторно.

Тайм-аут означает, что ответ не пришёл вовремя. Он не показывает, завершилась ли успешно сама транзакция.

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

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

Если результат остаётся неопределённым, при восстановлении следует проверить уже существующую транзакцию и сверить относящиеся к ней записи, а не сразу создавать новую.

Я также ограничил бы число повторных попыток и заранее определил, что делать, если автоматически установить результат не удаётся. Клиенту нужен понятный статус «ожидает обработки» и способ решить проблему, а не повторные списания или бесконечно вращающийся индикатор обработки.

В распределённых системах база данных, серверная служба и физический киоск могут сообщать противоречивые сведения об одной и той же транзакции. Сталкивались ли вы с подобными несоответствиями в рабочей среде и как их расследовали и устраняли? Какую роль, если вообще какую-либо, мог бы сыграть ИИ в согласовании этих противоречивых записей?

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

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

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

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

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

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

По мере того как ИИ-агенты переходят от диагностики сбоев в рабочей среде к рекомендациям по восстановлению или выполнению восстановительных действий, какие меры защиты должны быть предусмотрены до того, как ИИ-система получит возможность повторить, отменить или изменить транзакцию? Как детерминированные механизмы контроля, такие как ключи идемпотентности, журналы транзакций и механизмы сверки, могут помешать ИИ усугубить сбой?

Я бы разделил предложение действия, его авторизацию и выполнение.

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

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

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

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

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

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

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

Система должна предусматривать отдельное состояние «исход неизвестен». Иначе она, скорее всего, ошибочно истолкует отсутствие информации как подтверждение сбоя.

Задержка подтверждения — повод разобраться в ситуации, а не автоматически отменять транзакцию. Отмена — это ещё одна финансовая операция со своими последствиями. Для неё нужны независимо установленные основания и соответствующая авторизация.

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

Это не позволяет подменить данные о транзакции оценкой уверенности ИИ. Модель может быть совершенно уверена в объяснении, построенном на неполной информации.

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

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

Распознавать неопределённость полезно только в том случае, если у системы есть практический способ с ней работать.

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

Я бы проводил границу исходя из последствий ошибки, а не из того, помечено ли действие как «связанное с ИИ».

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

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

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

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

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

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

Вы много работали над отказоустойчивыми серверными системами, инструментами наблюдаемости и интеграцией программных сервисов с физическим оборудованием. Какие телеметрические данные и свидетельства из производственной среды нужны ИИ-агенту, чтобы надежно диагностировать инцидент? Как инженерным командам отличать полезные рекомендации, сгенерированные ИИ, от правдоподобных, но ошибочных выводов, которые могут усугубить сбой?

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

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

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

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

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

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

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

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

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

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

В ходе оценки использовалась синтетическая среда, представлявшая 500 терминалов на протяжении 72-часового моделирования; поведение атак программ-вымогателей имитировалось, а не проверялось развертыванием системы на 500 физических терминалах.

По сравнению с использованным в исследовании базовым вариантом, основанным только на антивирусной защите, среднее время обнаружения сократилось с 52 до 31 минуты, а среднее время восстановления — со 120 до 56 минут.

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

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

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

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

Это исследование создает основу для дальнейших испытаний. Подтвердить безопасную работу в реальных условиях эксплуатации — отдельная задача.

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

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

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

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

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

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

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

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

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

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

Это даст людям больше времени на решения, для которых необходимо понимать обязательства системы и последствия ее изменений.

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

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

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

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

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

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