Гонка в денежном протоколе
Два перевода одновременно проходят проверку лимита, и остаток уходит в минус.
Для каждой денежной операции строится модель протокола. Перебор находит такую гонку за миллисекунды и показывает шаги, которые к ней ведут.
Платежи · банковские переводы · высокие нагрузки
Архитектура, в которой деньги не теряются и не списываются дважды
Я проектирую критичные системы на собственной платформе Architect OS. AI ускоряет проектирование, но ни одно его решение не попадает в проект без проверки: протоколы движения денег проверяются перебором всех состояний, контракты сервисов на совместимость, расчёт мощности считает сервер. Ошибки находятся на схеме, а не в продакшне.
- 35 / 35
- сценариев восстановления после сбоев прошли в трёх сложных проектах
- 18 / 18
- эталонных задач, включая платёжный шлюз и межбанковские переводы
- 0
- пропущенных критичных требований
Модель предлагает, решает сервер
Языковые модели ошибаются уверенно. Поэтому в Architect OS нет шага, на котором слову модели верят без проверки. Каждое предложение проходит детерминированный код, который модель не может ни обойти, ни переписать. Если ответ отклонён, модель получает точный список нарушений и присылает исправление.
| Как ошибается AI | Что это ловит | Результат |
|---|---|---|
| Пропускает гонку, двойное списание, зависший статус | Исполняемая модель протокола: перебор всех чередований (BFS), инварианты, сценарии восстановления после сбоя | Нарушение возвращается с кратчайшей трассой. Денежный протокол без модели не пройдёт согласование: MODEL_REQUIRED |
| Предлагает несовместимый вызов между сервисами | Сверка контрактов: поля, типы, обязательность, ключ идемпотентности у повторяемых операций | CONTRACT_INCOMPATIBLE блокирует согласование |
| Ошибается в арифметике нагрузки | Сервер вычисляет формулы, проверяет размерности, протягивает диапазоны неопределённых входов | Результат считает сервер. Расхождение с другим расчётом — CAPACITY_CHAIN |
| Забывает последствия изменившегося факта | Анализ влияния по графу зависимостей; пометки «на пересмотре» ставит и снимает только сервер | Пока каждый затронутый пункт не исправлен или не обоснован, сохранить проект нельзя |
| Ссылается на несуществующее или теряет связь с требованием | Схема данных, ссылочная целостность, двусторонняя трассировка требований | Обязательное требование без реализации и проверки не допускается к ревью |
| Придумывает факты или одобряет сам себя | Требование «от заказчика» должно ссылаться на реальное сообщение; модель не может одобрить проект или создать доказательство | Догадки становятся допущениями, привилегированные команды отбрасываются |
- Влияниечто новое сообщение меняет в готовой схеме
- Требованиятребования, допущения, вопросы с вариантами
- Проектированиекомпоненты, решения с альтернативами, контракты, модели протоколов
- Критиканезависимый проход по нарушениям, найденным проверками
- Проверка34 правила, модели протоколов, контракты, расчёты
- Сохранениеодна атомарная ревизия или ничего
Сложные системы, проверенные до разработки
Три задачи уровня реальных проектов прошли через Architect OS целиком. На втором шаге каждой условие меняется посреди работы, как это бывает в жизни. Ниже — что система спроектировала, что проверила и как пересмотрела решения. Проекты открываются целиком, только для чтения.
Как это выглядит в работе
Запись реального интерфейса Architect OS: схема системы, проверка протокола, совместимость контрактов, пересмотр решений после нового факта и готовность к разработке.
Одна пропущенная проверка — и бюджет перерасходован
Реальная модель протокола из эталонной задачи о корпоративных закупках: лимит филиала 3, каждый заказ резервирует 2. Уберите из проверки лимита резервы «в пути», и система найдёт перерасход, перебрав все состояния.
В модели 10 переменных и 26 действий: резерв, запрос на склад, ответы, таймауты, отмены, повторные отмены. Показан итог настоящей проверки.
Где проекты теряют деньги
Шесть ситуаций, которые обходятся дороже всего, и что система делает в каждой сама, не полагаясь на внимательность людей.
Статус «неизвестно» после таймаута
Банк или эквайер не ответил вовремя. Повтор запроса означает двойное списание, отмена — потерянные деньги.
Неизвестный исход — отдельное состояние протокола. Сценарии восстановления проверяют, что он всегда разрешается без двойного списания.
Микросервисы там, где хватит монолита
Для задачи, с которой справится один сервис, строят десяток сервисов, очередь и оркестрацию. Всё это потом годами поддерживают.
По умолчанию — модульный монолит. Распределение допускается, только когда его оправдывают требования, и решение фиксируется с альтернативами и условием пересмотра.
Несовместимые требования
«Строгая согласованность между континентами и подтверждение за 5 мс». Противоречие всплывает после месяцев работы.
Конфликт помечается и доказывается цифрами: задержка между регионами, минуты простоя в год. Выходы предлагаются вариантами одного вопроса.
Факты меняются посреди проекта
«Регулятор может подтвердить перевод через 10 минут». Половина решений тихо устаревает.
Всё, что зависело от старого факта, находится по графу и помечается к пересмотру. Сохранить проект нельзя, пока каждый пункт не закрыт.
Мощность «на глаз»
«Хватит трёх серверов». Число в тексте расходится с расчётом, запас на отказ ЦОДа никто не проверял.
Формулы считает сервер. Неопределённые входы задаются диапазонами, результат тоже выходит диапазоном, а значения, взятые из другого расчёта, не могут с ним разойтись.
Результаты на эталонном наборе
Систему оценивают два независимых судьи: машинные проверки с весами по серьёзности (критично ×5, важно ×3, мелочь ×1) и отдельная модель-рецензент, которая видит только задачу, критерии и результат. Набор из 15 задач покрывает простые системы, задачи-ловушки, противоречивые требования, денежные протоколы, пересмотр решений, медицинские данные и рост нагрузки.
Показать таблицей
93% → 100%машинные проверки с весами
6,4 → 7,9средняя оценка рецензента
403автотеста на сам механизм проверок
Ограничения, о которых стоит знать
- Проверка на модели не заменяет нагрузочный тест. В системе это разные статусы: «проверено на модели» и «измерено».
- Три задачи после доработки потеряли по баллу у рецензента — это видно на графике.
- Слабее всего пока расчёт роста нагрузки (6 из 10). После этого появилась автоматическая сверка цепочек расчётов.
Сколько стоит ошибка, найденная поздно
Ошибка проектирования, обнаруженная после начала разработки, стоит команде недель переделки. Подставьте свои значения.
Экономия на проекте—
Аудит существующей системы
Переношу архитектуру в модель и прогоняю проверки. Результат: риски по серьёзности, найденные гонки и несовместимости, план исправлений.
Архитектура нового проекта
От требований до пакета для команды: решения с альтернативами, проверенные протоколы, контракты, расчёт мощности сейчас и при росте, критерии приёмки.
Сопровождение изменений
Когда меняются условия, анализ влияния показывает, что пересмотреть, а журнал хранит, почему решения стали такими.
Обсудим вашу систему
Расскажите о проекте или текущей архитектуре. Покажу, что найдут проверки, на ваших требованиях.