Вопросы и ответы

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

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

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

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

Слева ничего не сломано. Там порядок держится на том, что кто-то в своё время предусмотрел этот случай и не ошибся, — и держится ровно до тех пор, пока случай не окажется тем, о котором не подумали. Справа он держится на описании, которое проверяется до выпуска и исполняется как записано.

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

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

Из четырёх частей, и это один артефакт, а не четыре документа рядом.

• Контракт данных: что в процессе существует и какого типа — состояние, факты, поручения наружу. Чего в контракте нет, того для процесса не существует.
• Таблицы решений: условия и результаты. Их правит владелец процесса, и условие читается фразой на языке площадки, а не выражением.
• Обработчики шагов: небольшая вычислительная логика там, где таблицы недостаточно — рядом с процессом и под теми же контрактами. Работы совсем без кода мы не обещаем.
• Стратегия выбора следующего шага: штатная считает по близости к заявленным целям, её можно заменить своей — в том числе уходящей за решением к внешнему решателю.

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

Журнал фиксирует действия: шаг, время, результат, код возврата. Это ответ на вопрос «что произошло». В разборе спрашивают другое — на основании чего.

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

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

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

Восстановление опирается на пять источников, и каждый следующий выглядит надёжнее предыдущего. Ни один не даёт ответа.

• Отчёт. Операция, упавшая до первой записи, в нём отсутствует. «Не завершилось» и «не начиналось» выглядят одинаково: никак.
• Журналы. Отвечают, что произошло, а не на основании чего.
• Номер сработавшего правила. Через год он приведёт к сегодняшнему тексту правила, и подмену не заметить.
• Версии правил. Прогон возьмёт сегодняшние данные, и верные правила по неверным данным дадут результат, которого не было ни тогда, ни сейчас.
• Снимок данных. Справочники, ответы внешних систем и ваш собственный изменившийся код вам не принадлежат — «по состоянию на март» их не запросить.

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

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

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

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

Нет. Учётные системы, CRM, процессинг, шина остаются на месте и продолжают выполнять действия — Вердикт их не подменяет и не проксирует.

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

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

Процессам, где сходятся четыре условия:

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

Отрасль значения не имеет, сходится чаще всего в финансовых и операционных процессах: скоринг и кредитный конвейер, KYC и ПОД/ФТ, тарификация, согласования с лимитами, обработка обращений со сроком ответа.

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

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

Процессам, где правила не менялись годами и объяснять решение некому. Механизм рассчитан на изменение и на внешний вопрос; без них он лишний.

Размер не определяет ничего. Определяет число шагов, систем и людей внутри процесса: от него зависит, во что обходится одно объяснение.

Цена объяснения растёт не от количества ошибок, а от количества участников: каждый новый шаг, каждое новое условие и каждый новый человек добавляют к ней понемногу.

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

У каждого шага есть предел числа запусков, у каждой цели — таймаут и дедлайн. «Зависло» перестаёт быть ощущением: это исчерпанный именованный бюджет, и он попадает в запись отдельным терминальным исходом.

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

Пока процесс ждёт, он принимает типизированные команды снаружи. «Клиент доплатил», «партия отгружена» меняют состояние до следующего такта, а не после следующей проверки по расписанию.

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

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

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

Отдельный вопрос владельца — «а сейчас она ещё так делает». На него отвечает повторный запуск на тех же данных.

Отвечают две проверки, обе до выпуска.

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

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

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

Отчёт первой строкой называет охват. Молчание проверки означает «не доказано», а не «всё хорошо»: непрочитанное условие приходится считать более широким, чем оно есть, и оно перестаёт конфликтовать с соседями.

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

Проходит она между значением и предметом: значение живёт в таблице, новый предмет объявляется в контракте.

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

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

Прежние версии сохраняются целиком, а не в виде разницы.

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

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

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

Одно и то же событие, доставленное дважды, не приводит к действию дважды.

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

Можно — как внешнего решателя, выбирающего следующий шаг. Разрешают при этом правила.

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

В записи каждого решения стоит имя стратегии, которая выбирала. «Модель предложила» и «разрешили правила» — разные записи, а не одна.

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

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

Внутрь ваших систем ничего не устанавливается, их интерфейсы не переписываются.

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

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

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

Два направления, оба настраиваете вы.

Входящее: ваши системы вызывают REST-границу Вердикта — запуск операции, чтение состояния, ответ на поручение, событие снаружи, сворачивание.

Исходящее: Вердикт отправляет поручение на адрес вашего обработчика. Адрес резолвится по паре «пространство, тип поручения», поэтому разные типы поручений можно развести на разные адреса. В поручении едет подписанный токен, которым обработчик отчитывается; отправка журналируется и переживает перезапуск, ответ со статусом от 300 считается провалом поручения и обрабатывается правилами повторов.

Адресов ваших внутренних систем и доступов к ним у Вердикта нет: к ним ходит ваш обработчик. Внешние сервисы о существовании Вердикта не знают — их вызывают их собственным интерфейсом.

Прикладная поверхность — пять адресов:

Всё это обычный HTTP с JSON в теле. Чтение состояния отвечает, чего операция ждёт, какие цели не достигнуты, какие поручения и сроки в работе и какой была ошибка последней фазы.

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

На вашей стороне два предмета: обработчик поручений и вызов запуска операции из системы-инициатора. Оба — обычный HTTP с JSON.

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

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

Часть уже написана — в каждом сервисе по-своему, разными людьми, в разные годы. Именно поэтому решение, прошедшее через четыре сервиса, сегодня не объяснить.

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

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

Разворачивается в вашем контуре. Запись операций остаётся там же и наружу не уходит.

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

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

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

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

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

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

Ноль находок без указанного охвата ничего не значит. Значит «ноль находок при прочитанных стольких-то процентах».

Нет. Откат работает для шагов, у которых описано обратное действие. Порядок строгий — обратно по последнему касанию, без повторного прохода.

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

Шаг, который не успел выполниться, не отменяется: система не отменяет того, чего не было.

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

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

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

С одной реальной операции годичной давности: берём её и смотрим, что от основания осталось и за сколько это собирается сегодня.

Нужны полчаса того, кто отвечает за процесс. Не ИТ.

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