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

Сапан Пандья — старший інженер-програміст і старший член IEEE з Нью-Джерсі, який має понад десять років досвіду роботи з відмовостійкими розподіленими транзакційними системами. Його робота охоплює забезпечення цілісності транзакцій, інтеграцію програмного забезпечення з фізичними пристроями, усунення проблем у виробничому середовищі та перевірку розгортань у регульованих галузях. Він здобув ступінь магістра комп’ютерних наук у Технологічному інституті Стівенса та долучається до рецензування наукових праць і технічних досліджень.

У своїх дослідженнях Пандья вивчає кібербезпеку кіосків, периферійний ШІ та інженерію надійності за допомогою ШІ, а його досвід роботи у виробничому середовищі визначає його увагу до доказів, результатів транзакцій і відповідальності за експлуатацію систем. У цьому інтерв’ю він розповідає про ідемпотентність, суперечливі записи транзакцій, невизначеність у системах відновлення та засоби контролю, потрібні перед тим, як ШІ-агенти зможуть діяти з критично важливою інфраструктурою. Він розмежовує практичний інженерний досвід і дослідження, проведені шляхом аналізу літератури та контрольованого чи синтетичного тестування.

Ваша кар’єра пов’язана з надійністю програмного забезпечення та розподіленими транзакційними системами. Як цей досвід сформував ваше розуміння надійності та які труднощі вплинули на ваш погляд на використання ШІ для керування складними системами?

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

На початку кар’єри я переважно зосереджувався на поведінці застосунків: перевіряв вхідні дані, обробляв відповіді та стежив, щоб інтерфейс відповідав передбаченому сценарію роботи. Коли мої обов’язки розширилися й охопили інтеграцію систем, усунення проблем у виробничому середовищі та перевірку розгортань, мені довелося дивитися ширше, ніж на окремі компоненти.

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

Цей досвід особливо зацікавив мене межами між системами. Що відомо кожному компоненту? Що він припускає? Що стається, коли ці припущення перестають справджуватися?

Цей досвід також впливає на моє бачення ШІ. Він може бути справді корисним, допомагаючи інженерам збирати докази, розпізнавати закономірності та швидше розслідувати збої. Але пояснення того, що, ймовірно, сталося, — це не те саме, що підтверджені відомості про те, що сталося насправді.

Я хочу, щоб ШІ допомагав зменшити зусилля, потрібні для розслідування проблем, не знижуючи вимог до доказів, необхідних для їх усунення.

Ви наголошували, що технічно правильний код не завжди гарантує правильний результат транзакції. Чи можете навести конкретний приклад, коли здається, що транзакція не відбулася через перевищення часу очікування, хоча насправді її вже завершено? Що може піти не так, якщо система автоматично повторить операцію, і як інженерам запобігти дублюванню транзакцій?

Розгляньмо гіпотетичний платіж на суму $50. Застосунок надсилає запит, платіжна служба успішно його реєструє, але відповідь губиться, перш ніж дійти до застосунку.

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

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

Один із поширених засобів захисту — ідемпотентність: можливість повторно надіслати той самий логічний запит без повторного фінансового списання. Під час повторних спроб застосунок зберігає ідентифікатор операції, а служба-одержувач розпізнає його як початковий запит, а не як нову покупку.

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

Якщо результат залишається невизначеним, під час відновлення слід перевірити наявну транзакцію та звірити відповідні записи, а не одразу створювати нову.

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

У розподілених системах база даних, серверна служба та фізичний кіоск можуть повідомляти суперечливі відомості про ту саму транзакцію. Чи стикалися ви з такою невідповідністю у виробничому середовищі, і як її розслідували та усували? Яку роль, якщо така є, міг би відіграти ШІ у звірянні цих суперечливих записів?

Так, розслідування невідповідностей у станах транзакцій було частиною моєї роботи у виробничому середовищі. Щоб пояснити логіку й не обговорювати випадок із конкретного місця роботи, я наведу гіпотетичний приклад.

Розгляньмо звичайну касу самообслуговування. Платіжний сервіс фіксує успішну покупку, принтер повідомляє, що прийняв завдання на друк чека, а потім на екрані з’являється помилка. Ці спостереження можуть стосуватися різних етапів взаємодії, а не доводити, що покупка загалом не відбулася.

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

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

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

ШІ може допомогти зіставити події та виявити відсутню інформацію. Я попросив би його навести кілька можливих пояснень і докази на підтримку кожного з них. Він має допомогти звузити коло пошуку, а не розв’язувати суперечності між записами, обираючи пояснення, яке звучить найпереконливіше.

У міру того як ШІ-агенти переходять від діагностики виробничих інцидентів до рекомендацій щодо відновлення роботи або виконання відповідних дій, які запобіжні заходи мають бути передбачені, перш ніж системі ШІ дозволять повторно виконати, сторнувати чи змінити транзакцію? Як детерміновані механізми контролю, як-от ключі ідемпотентності, журнали транзакцій і механізми звіряння, можуть запобігти тому, щоб ШІ спричиняв додаткові збої?

Я розділив би пропонування дії, її авторизацію та виконання.

ШІ-агент може рекомендувати повторити операцію, але окремий механізм контролю має визначати, чи дозволено це робити. Він має перевіряти поточний стан транзакції, ідентичність операції, права агента та умови, за яких така дія є безпечною.

Цю перевірку потрібно проводити під час виконання дії, а не лише тоді, коли модель уперше аналізує інцидент. Тим часом інший процес міг завершити транзакцію.

Набір інструментів, доступних агенту, також має бути обмеженим. Дозвіл отримати статус транзакції — це не те саме, що дозвіл скасувати платіж або змінити фінансовий запис. Агент не повинен мати змоги самостійно розширювати свої повноваження лише тому, що для бажаного ним рішення потрібен ширший доступ.

Ідемпотентність обмежує дублювання наслідків операцій. Журнали зберігають історію, потрібну для розслідування. Звіряння дає змогу перевірити, чи узгоджуються відповідні записи. Жоден із цих механізмів окремо не підтверджує, що запропонована дія є доречною.

Я також фіксував би використані докази, рекомендацію, рішення щодо авторизації та фактичний результат. Це дає змогу згодом перевірити втручання.

Ці механізми контролю мають забезпечуватися тестованим програмним забезпеченням поза межами моделі. Інструкції агенту бути обережним — це корисні настанови, але не механізм авторизації.

Уявімо, що система моніторингу на основі ШІ виявляє ймовірний збій транзакції та рекомендує автоматично скасувати операцію. Якщо транзакцію насправді було успішно виконано, але підтвердження затрималося, таке втручання може створити нову проблему. Як інженерним командам проєктувати системи відновлення на основі ШІ, щоб вони розпізнавали невизначеність і не вживали коригувальних заходів на підставі неповної інформації?

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

Затримка підтвердження — це привід провести перевірку, а не автоматично скасувати транзакцію. Скасування — це ще одна фінансова операція зі своїми наслідками. Для нього потрібні окремо встановлена підстава та належна авторизація.

Я розділив би реагування на два напрямки. У межах розслідування можна отримати статус, зібрати відсутні події, зіставити записи й повідомити відповідальну команду. Виконання фінансової дії має залишатися заблокованим, доки не буде виконано відповідні умови.

Це не дає оцінці впевненості ШІ підмінити докази щодо транзакції. Модель може бути цілком упевнена в поясненні, побудованому на неповній інформації.

Також має бути визначений момент ескалації. Тримати транзакцію в очікуванні безстроково — незадовільний результат для клієнта. Хтось має відповідати за невирішений випадок і мати достатньо контексту, щоб визначити наступний безпечний крок.

Отже, процес відновлення має давати змогу сказати і «Я поки не можу обґрунтувати зміну цієї транзакції», і «Ось що потрібно зробити, щоб її врегулювати».

Розпізнавати невизначеність корисно лише тоді, коли система має практичний спосіб упоратися з нею.

Одне з найважливіших питань, пов’язаних з автономним ШІ, — визначити, коли погодження людини залишається необхідним. Які дії з відновлення роботи в робочому середовищі, на вашу думку, ШІ має право виконувати самостійно, а які завжди повинні потребувати дозволу людини? Як організаціям установити ці межі, коли йдеться про фінансові транзакції, дотримання нормативних вимог або довіру клієнтів?

Я б визначав межу за наслідками помилки, а не за тим, чи називають певну дію дією «ШІ».

Розумно почати з розслідування без права вносити зміни, за умови, що агент має доступ лише до дозволеної інформації. Він може збирати діагностичні записи, групувати пов’язані сповіщення та готувати підсумок інциденту, не маючи права змінювати саму транзакцію.

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

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

Це не означає, що кожна рутинна фінансова операція потребує погодження людини. Обробка за встановленими правилами — це не те саме, що дозволити моделі вигадати спосіб виправлення під час інциденту.

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

Ці межі слід узгодити до розгортання системи. Аварійна зупинка роботи — не найкращий момент, щоб вирішувати, якими повноваженнями має володіти автоматизована система.

Ви багато працювали з відмовостійкими серверними системами, інструментами спостережуваності та інтеграціями між програмними сервісами й фізичним обладнанням. Які телеметричні дані й докази з робочого середовища потрібні ШІ-агенту, щоб надійно діагностувати інцидент? Як інженерні команди можуть відрізнити корисні рекомендації, згенеровані ШІ, від правдоподібних, але хибних висновків, які можуть погіршити перебіг аварії?

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

Важливі також версії програмного забезпечення та зміни конфігурації. Якщо збій почався після випуску оновлення, це дає фахівцеві корисну зачіпку, але сам збіг у часі не доводить причинно-наслідкового зв’язку.

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

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

Я очікував би, що в рекомендації будуть зазначені записи, на яких вона ґрунтується, пояснено, що залишається невідомим, і вказано, яка додаткова перевірка підтвердить або спростує висновок.

Потім інженерам слід перевіряти важливі рекомендації за первинними записами, а не покладатися лише на підсумок агента. Це особливо важливо, коли в підсумку стисло викладено довгу чи суперечливу історію подій.

Я застосовував би простий критерій: чи зможе інший інженер простежити докази й дійти обґрунтованого висновку? Якщо пояснення не витримує такої перевірки, воно ще не готове стати підставою для змін у робочому середовищі.

У своїх опублікованих дослідженнях стійкості кіосків для проведення лотерей і приймання ставок до програм-вимагачів ви оцінювали систему безпеки за підтримки ШІ в синтетичному середовищі, що моделювало роботу 500 кіосків. Якими були найважливіші висновки і про які обмеження читачам слід пам’ятати, тлумачачи ці результати? Яка додаткова перевірка була б потрібна, перш ніж застосовувати запропоновану архітектуру в реальному робочому середовищі?

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

Створена система стійкого захисту поєднувала превентивні засоби контролю, виявлення аномалій за підтримки ШІ та визначені механізми реагування й відновлення. Компонент ШІ призначався для виявлення підозрілої поведінки. Це не був експеримент, у якому агент на основі мовної моделі міг самостійно змінювати фінансові транзакції.

Оцінювання проводили в синтетичному середовищі, що відтворювало роботу 500 кіосків протягом 72-годинної симуляції; поведінку програм-вимагачів моделювали, а не розгортали систему на 500 фізичних терміналах.

Порівняно з базовим варіантом дослідження, у якому використовували лише антивірусне програмне забезпечення, середній час виявлення скоротився з 52 до 31 хвилини, а середній час відновлення — зі 120 до 56 хвилин.

Це результати роботи комбінованої архітектури за експериментальних умов. Їх не слід приписувати лише ШІ або вважати гарантією продуктивності в реальному середовищі. Один із важливих висновків полягав у тому, що саме по собі раннє виявлення не забезпечило такого самого поліпшення відновлення. Важливу роль також відігравали локалізація загрози та проєктування процесу відновлення.

Важливо враховувати обмеження дослідження. Змодельовані робочі навантаження, мережеві умови, сценарії атак і базові засоби захисту не охоплюють усіх умов експлуатації. Для інших пристроїв і застосунків знадобиться нова перевірка.

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

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

Дослідження створює основу для подальших випробувань. Доведення безпечної роботи в реальному середовищі експлуатації — це окремий етап.

Ваш погляд поєднує багаторічний досвід розробки програмного забезпечення для продуктивних систем із науковими дослідженнями надійності програмного забезпечення та безпеки на основі ШІ. Чи можете ви розмежувати механізми забезпечення надійності, які особисто впроваджували або експлуатували в реальних продуктивних системах, і підходи, які досліджували в науковій роботі чи під час моделювання? Які можливості відновлення за допомогою ШІ, на вашу думку, вже практично застосовні, а які поки що здебільшого залишаються експериментальними?

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

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

У статті про програми-вимагачі оцінюється запропонована система безпеки в змодельованому тестовому середовищі. Моя стаття про периферійний ШІ — це огляд літератури про інтелектуальну обробку даних на пристроях і можливе застосування таких рішень у платіжних терміналах. У статті для IEEE FeedForward розглядається архітектура надійності за підтримки ШІ на основі контрольованого моделювання, зокрема моніторинг, ескалація та резервний режим роботи.

Жодну з цих публікацій не слід вважати доказом того, що я впровадив автономного ШІ-агента, уповноваженого керувати реальними фінансовими транзакціями.

Для практичного застосування я насамперед зосередився б на допоміжних засобах, роботу яких інженери можуть перевірити: зведеннях про інциденти з посиланнями на вихідні записи, виявленні взаємозв’язків між сповіщеннями та рекомендаціях щодо діагностичних перевірок. Їхню корисність усе одно потрібно оцінювати в середовищі, де їх використовуватимуть.

Складніша проблема — це відновлення у відкритих сценаріях, коли модель обирає та виконує зміни за непередбачених обставин. Для цього потрібні значно вагоміші докази, ніж для корисної діагностичної рекомендації.

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

З огляду на те, що ШІ-агенти дедалі краще виявляють аномалії, діагностують збої та координують відновлення в розподілених системах, як, на вашу думку, змінюватимуться взаємини між автономними системами та інженерами? Які технічні засоби захисту, докази ефективності в експлуатації та механізми підзвітності будуть необхідні, перш ніж організації зможуть упевнено надати ШІ ширші повноваження щодо критично важливої виробничої інфраструктури?

На мою думку, ШІ виконуватиме дедалі більшу частину роботи зі збирання цілісної картини інциденту. Інженери зможуть одразу отримувати корисну хронологію подій, перелік уражених компонентів, кілька можливих пояснень і дані, яких бракує, замість того щоб витрачати стільки часу на ручне збирання цієї інформації.

Завдяки цьому люди матимуть більше часу на рішення, для яких потрібно розуміти зобов’язання системи та наслідки її змін.

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

Оцінювання має охоплювати помилкові втручання, невиявлені проблеми, непотрібну ескалацію та здатність виправляти помилки самого агента. Швидка рекомендація не має цінності, якщо через неї команда реагування рухається в хибному напрямку.

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

З розвитком автоматизації відповідальність людей не зникає. Хтось має відповідати за правила експлуатації, докази, необхідні для внесення змін, і процедуру розслідування збоїв.

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

Дякуємо за чудове інтерв’ю. Читачі, які хочуть стежити за його роботою над надійністю розподілених транзакцій і відповідальним відновленням за допомогою ШІ, можуть зв’язатися із Sapan Pandya.