Цепная реакция между системами

01 С какими ситуациями обращается бизнес

Логистика → маркетплейс → банк

Логистический оператор задержал передачу статусов.

Маркетплейс расценил это как массовую просрочку.

Рейтинг продавца снизился.

Выручка просела.

Банк пересмотрел овердрафт.

Реестр → агрегатор → банк

В официальном источнике появилась спорная или впоследствии исправленная запись.

Её скопировал коммерческий агрегатор.

Из агрегатора сведения попали в риск-модель другого участника.

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

Платёжный шлюз → ЭТП → закупка

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

Электронная площадка не увидела требуемый статус вовремя.

Закупочная процедура пошла дальше без участника.

SaaS → производство → контрагенты

Облачный сервис заблокировал доступ.

Компания потеряла возможность:

• 01 формировать документы;
• 02 выпускать заказы;
• 03 управлять складом;
• 04 подтверждать отгрузки.

Несколько договоров были нарушены уже как следствие.

Антифрод → общий аккаунт → экосистема

Спор возник в одном сервисе.

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

Ограничение начинает распространяться дальше.

02 Что такое цепная реакция

Каскад возникает, когда система Б реагирует не непосредственно на реальное событие, а на результат работы системы А.

Например:

Реальность

товар отгружен.

Но:

Система А

не передала статус.

Система Б

решила, что товар не отгружен.

Система В

увидела падение рейтинга.

Система Г

ухудшила лимит.

То есть на четвёртом уровне решение может быть уже очень далеко от реального исходного факта.

Поэтому:

Каждая система может корректно обрабатывать входные данные и при этом весь каскад может быть построен на неверном исходном событии.

03 Первичная точка отказа

Это центральный уровень страницы.

Внутри кризиса необходимо определить:

Какое событие впервые изменило нормальный ход бизнес-процесса.

Это может быть:

• 01 неверный ответ API;
• 02 задержка сообщения;
• 03 ошибочный статус;
• 04 некорректная запись в реестре;
• 05 автоматическая блокировка;
• 06 отказ инфраструктуры;
• 07 ошибочная обработка данных.

Но Бюро не начинает с вывода:

«Вот первая ошибка в логе — значит мы нашли виновного».

Первая увиденная ошибка и юридически значимая первопричина могут не совпадать.

04 Причина, симптом и усилитель — три разных роли

В каскаде одна система может быть:

Первичным источником

Создала исходную ошибку.

Передатчиком

Просто передала ошибочный статус дальше.

Усилителем

Применяла к статусу собственную жёсткую санкцию.

Например:

реестр содержит спорное значение.

Агрегатор его скопировал.

Банк на основании совокупности собственных факторов пересмотрел лимит.

В такой цепочке нельзя автоматически сказать:

«Всё сделал агрегатор».

И нельзя сказать:

«Банк ни при чём, он только получил данные».

У каждого звена проверяется собственное правовое основание и собственное решение.

05 Retry Storm: когда повторная отправка сама создаёт новый кризис

Короткий сбой может вызвать лавину повторных запросов.

Например:

Сервис не ответил → клиент повторил запрос → таймаут → ещё один retry → тысячи одновременных повторов.

Это называют Retry Storm — штормом повторных запросов.

Платформа может увидеть:

• 01 аномальный объём трафика;
• 02 превышение лимитов;
• 03 множество одинаковых запросов;
• 04 резкий рост обращений с одного диапазона.

И включить:

• 01 rate limiting;
• 02 временное ограничение;
• 03 IP-ban;
• 04 защиту от автоматического трафика.

Но:

Высокая частота запросов ≠ автоматически DDoS.

Сначала проверяется:

Что предшествовало лавине → как была настроена retry-политика → какие ответы возвращал шлюз → применялась ли задержка между повторами → кто контролировал конкретный компонент.

06 HTTP 429 и 503: одинаковая ошибка для бизнеса — разная техническая причина

В упрощённом виде:

HTTP 429 Too Many Requests

обычно означает, что сервис ограничивает частоту запросов.

HTTP 503 Service Unavailable

— что сервис временно не может обработать запрос.

Но одиночный код не устанавливает виновного.

Например, 429 может возникнуть потому, что:

• 01 клиент нарушил согласованный rate limit;
• 02 документация была недостаточно ясной;
• 03 сервис изменил лимиты;
• 04 retry-механизм клиента создал лавину после 503.

Поэтому Бюро не пишет:

«429 = вина платформы».

Проверяется вся последовательность событий.

07 Распределённая трассировка

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

ERP → API gateway → брокер → платформа → банк.

В современных системах для наблюдаемости может использоваться распределённая трассировка.

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

Но:

Trace ID не существует автоматически в каждой интеграции.

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

08 W3C Trace Context и OpenTelemetry

W3C Trace Context стандартизирует передачу информации о трассировке между компонентами.

OpenTelemetry является распространённым открытым инструментарием наблюдаемости.

При корректной инструментализации могут использоваться:

• 01 Trace ID;
• 02 Span ID;
• 03 traceparent;
• 04 временные интервалы отдельных операций.

Это позволяет увидеть:

Сервис А — 12 мс → шлюз — 38 мс → очередь — 4 часа → сервис Б — 22 мс.

Но:

Trace не «доказывает виновного на 100%».

Он показывает техническую хронологию.

Юридическая ответственность зависит дополнительно от:

• 01 договора;
• 02 SLA;
• 03 обязанностей сторон;
• 04 причинной связи;
• 05 распределения инфраструктурных рисков.

09 Kafka, RabbitMQ и промежуточный транспорт

Сообщение может быть успешно передано отправителем, но ещё не обработано конечным сервисом.

В Kafka, например, значение могут иметь:

• 01 offset;
• 02 consumer group;
• 03 consumer lag;
• 04 время записи;
• 05 время обработки.

В других брокерах существуют собственные аналоги.

Поэтому:

«Мы отправили событие вовремя»

может быть технически правдой.

И одновременно:

«Система-получатель увидела его только через 18 часов»

тоже может быть правдой.

10 Consumer Lag и ответственность

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

Если событие:

Записано в 10:03

а потребитель обработал его:

в 23:47,

возникает технически важный вопрос:

Где находилась задержка.

Но это ещё не юридический вывод.

Нужно установить:

• 01 кому принадлежал consumer;
• 02 какой SLA был установлен;
• 03 была ли допустима асинхронная задержка;
• 04 существовало ли резервирование;
• 05 обязан ли был клиент контролировать этот компонент.

11 Устаревший кэш: первоисточник уже исправлен, а санкция продолжает жить

Ещё один глубокий каскад:

Первоисточник → агрегатор → банк → фактор → контрагент.

Первоначальный статус исправлен.

Но агрегатор ещё хранит старое состояние.

Банк обновляет данные позже.

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

Возникает stale data — устаревшая информация.

12 TTL и период обновления

Кэшированные данные могут иметь TTL — срок жизни в кэше.

Но нельзя публиковать:

«Агрегаторы хранят ошибку 7–14 дней».

Универсального срока нет.

Он зависит от:

• 01 конкретной системы;
• 02 источника;
• 03 регламента обновления;
• 04 API;
• 05 архитектуры кэширования.

Бюро проверяет:

Когда первоисточник изменился → когда агрегатор получил изменение → когда обновил свой статус → какое решение в этот период приняли третьи лица.

13 Устаревшие данные и деловая репутация

Если сервис распространяет о компании фактические сведения, которые:

• 01 не соответствуют действительности;
• 02 порочат её деловую репутацию,

может ставиться вопрос о защите деловой репутации по ст. 152 ГК РФ.

Но здесь важно не смешивать:

Фактическое утверждение

и:

Аналитическую оценку / рейтинг.

Например:

«Компания находится в процессе ликвидации»

— проверяемый факт.

А:

«Риск сотрудничества высокий»

может быть оценочным выводом конкретной системы.

Поэтому правовой маршрут будет разным.

14 Производный скоринг

Один скоринг может использовать результат другого.

Например:

Агрегатор снизил балл → фактор уменьшил лимит → поставщик потерял финансирование.

Но:

Второй скоринг ≠ автоматически незаконен только потому, что первый был ошибочным.

Нужно установить:

• 01 какие данные реально использовались;
• 02 имелись ли другие основания;
• 03 принималось ли самостоятельное решение;
• 04 какую роль сыграл спорный показатель.

15 Vendor Lock-in: когда зависимость от экосистемы становится риском

Цифровой бизнес может зависеть от одного поставщика сразу по нескольким сервисам:

• 01 ID;
• 02 облако;
• 03 API;
• 04 логистика;
• 05 эквайринг;
• 06 реклама;
• 07 электронный документооборот.

Это создаёт vendor lock-in — инфраструктурную зависимость от поставщика.

Но сама зависимость не является нарушением закона.

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

16 Антимонопольный контур

Нельзя писать:

«Крупная экосистема → значит она доминирует → любая блокировка нарушает ст. 10».

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

Статья 10 Закона №135-ФЗ запрещает злоупотребление доминирующим положением.

Для определённых владельцев цифровых платформ действует также специальная ст. 10.1 Закона №135-ФЗ. Она применяется при установленной законом совокупности условий, включая сетевой эффект, долю сделок свыше 35% соответствующего рынка и выручку свыше 2 млрд рублей.

Поэтому Бюро проверяет:

Есть ли антимонопольный статус → какой рынок → каково положение платформы → какое действие совершено → создаёт ли оно предусмотренные законом последствия.

17 Пределы права партнёра на блокировку

Контрагент может иметь договорное право:

• 01 приостановить сервис;
• 02 изменить лимит;
• 03 прекратить договор;
• 04 ограничить доступ.

Но наличие такого пункта не означает:

«Можно сделать что угодно при любом автоматическом триггере».

Проверяются:

• 01 текст договора;
• 02 условия реализации права;
• 03 добросовестность;
• 04 наличие реального основания;
• 05 соблюдение процедуры;
• 06 специальные ограничения закона.

18 Внешний провайдер и ст. 401 ГК РФ

Особенно важно не превращать внешний сбой в универсальную защиту.

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

Поэтому:

«Упал наш облачный поставщик»

не означает автоматически:

«Мы не отвечаем перед своим клиентом».

Внешний сбой может иметь значение для:

• 01 причинной картины;
• 02 последующего регресса;
• 03 распределения риска по договору.

Но не является автоматическим форс-мажором.

19 Каскадные убытки

Самая дорогая часть спора:

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

Статьи 15 и 393 ГК РФ позволяют требовать возмещения убытков при наличии предусмотренных законом оснований.

Но истец должен обосновать:

• 01 нарушение;
• 02 наличие убытка;
• 03 размер;
• 04 причинную связь.

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

20 «Косвенный убыток» не означает автоматически невзыскиваемый

Оппонент может сказать:

«Мы сломали только API. То, что вы потеряли тендер, — ваши косвенные проблемы».

Такой ответ сам по себе спор не закрывает.

Вопрос:

Было ли последствие разумно связано с нарушением.

Но и клиент не может просто сложить:

• 01 все штрафы;
• 02 всю потерянную прибыль;
• 03 все убытки группы

и предъявить одну сумму первому провайдеру.

Каждое звено доказывается отдельно.

21 Упущенная выгода

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

Проверяется:

• 01 насколько реальной была сделка;
• 02 был ли договор или высокая степень готовности;
• 03 какой доход компания получила бы;
• 04 какие расходы понесла бы;
• 05 почему именно спорный сбой лишил её этого результата.

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

22 Обязанность уменьшать ущерб

При каскадном кризисе нельзя просто наблюдать, как потери растут.

Статья 404 ГК РФ и подход Верховного Суда позволяют учитывать, предпринимал ли кредитор разумные меры для уменьшения убытков.

Поэтому важна фиксация:

Что бизнес сделал, чтобы остановить каскад.

Например:

• 01 уведомил партнёров;
• 02 включил резервный канал;
• 03 временно изменил маршрут;
• 04 предоставил подтверждение первичного инцидента;
• 05 сохранил возможность исполнения другим способом.

23 Когда каскад нужно останавливать до судебного решения

Иногда ждать итогового решения действительно экономически невозможно.

Например:

Ещё неделя блокировки → срыв контракта → потеря товара → кассовый разрыв.

В таком случае рассматривается вопрос об обеспечительных мерах.

АПК РФ предусматривает возможность принятия срочных временных мер при наличии установленных процессуальных оснований.

Но:

«Нам очень плохо»

само по себе недостаточно.

Нужно показать:

• 01 связь меры с будущим требованием;
• 02 риск затруднения исполнения либо значительного ущерба;
• 03 соразмерность;
• 04 необходимость именно такой меры.

24 Предварительные обеспечительные меры до подачи иска

Статья 99 АПК РФ позволяет организации или гражданину просить суд обеспечить имущественные интересы до предъявления иска.

Это действительно сильный инструмент.

Например, в зависимости от предмета спора может ставиться вопрос о временном запрете совершать определённые действия.

Но формула:

«Суд за 24 часа обязательно разблокирует кабинет»

юридически неверна.

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

Поэтому Бюро не продаёт:

«Экстренную разблокировку за сутки».

Мы определяем:

Есть ли процессуальные основания для срочной судебной защиты.

25 Единая судебная стратегия

Когда из одного инцидента возникают несколько процессов, опасно вести их независимо.

Например:

• 01 Процесс 1 — провайдер
• 02 Процесс 2 — покупатель
• 03 Процесс 3 — фактор
• 04 Процесс 4 — платформа.

Если в каждом деле компания по-разному описывает:

• 01 время;
• 02 причину;
• 03 распределение ответственности,

возникает процессуальный риск.

Поэтому полезна единая центральная фактологическая позиция.

26 Третье лицо в первом процессе

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

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

Но:

Привлекли третье лицо → значит автоматически получили преюдицию для всех будущих споров

— неверно.

27 Пределы преюдиции

Часть 2 ст. 69 АПК РФ говорит: обстоятельства, установленные вступившим в силу судебным актом арбитражного суда, не доказываются вновь в другом деле, в котором участвуют те же лица.

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

Но её сила состоит не в магической формуле:

«Один суд решил — все остальные обязаны».

А в:

• 01 согласованной доказательственной позиции;
• 02 участии необходимых лиц;
• 03 установлении ключевых обстоятельств;
• 04 возможности использовать судебный акт в пределах процессуальных правил.

28 Что нельзя считать доказанным автоматически

Retry Storm не равен DDoS

Но и не доказывает автоматически дефект платформы.

HTTP 503 не означает автоматически вину сервиса

HTTP 429 не означает автоматически вину клиента

Trace ID не существует в каждой инфраструктуре

Trace ID показывает связанную техническую трассу, но не определяет юридическую ответственность

Consumer Lag показывает задержку обработки, но не отвечает сам по себе, кто отвечал за SLA

Устаревший кэш не означает автоматически нарушение закона

Сначала проверяется источник, регламент, вид информации и возникшие последствия.

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

Один ошибочный скоринг не означает автоматически незаконность всех последующих решений

Зависимость от экосистемы не означает автоматически доминирующее положение поставщика

Крупная цифровая платформа не автоматически подпадает под ст. 10.1 №135-ФЗ

Предварительная обеспечительная мера не гарантируется

Один судебный акт не создаёт универсальную преюдицию для любых будущих процессов

Сбой подрядчика должника не является автоматически форс-мажором

Все штрафы третьих лиц не становятся автоматически убытками первичного нарушителя

29 Что проверяет Бюро

Работа строится по четырём уровням.

1. Root Cause Layer — первопричина

Что именно произошло первым:

• 01 API;
• 02 шлюз;
• 03 очередь;
• 04 статус;
• 05 реестр;
• 06 антифрод;
• 07 блокировка.

2. Propagation Layer — распространение

Как исходное событие передавалось:

• 01 через API;
• 02 webhook;
• 03 агрегатор;
• 04 кэш;
• 05 скоринг;
• 06 брокер сообщений;
• 07 общую систему авторизации.

3. Contract & Legal Layer — договорная и правовая сеть

Что имел право сделать каждый участник:

• 01 приостановить;
• 02 уменьшить лимит;
• 03 заблокировать;
• 04 начислить штраф;
• 05 расторгнуть договор.

4. Damage Layer — финансовое последствие

Что действительно возникло:

• 01 прямой убыток;
• 02 штраф;
• 03 простой;
• 04 потеря финансирования;
• 05 упущенная выгода;
• 06 дополнительные расходы.

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

30 Чем Бюро отличается от обычного сопровождения

Обычный подход:

«Напишем в банк. Потом в маркетплейс. Потом ответим поставщику».

Бюро:

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

Наша роль:

Архитектура купирования каскадного B2B-кризиса

Мы соединяем:

• 01 Инженерный след
• 02 Данные и скоринги
• 03 Договорную сеть
• 04 Процессуальную стратегию
• 05 Финансовую карту ущерба.

Для:

• 01 собственника;
• 02 генерального директора;
• 03 юридического директора;
• 04 финансового директора;
• 05 CIO / CTO;
• 06 e-commerce;
• 07 финтеха;
• 08 логистики;
• 09 производства;
• 10 бизнеса с критической зависимостью от цифровых платформ.

31 Что остаётся закрытым

Бюро не публикует:

• 01 внутреннюю последовательность поиска первичной точки отказа;
• 02 алгоритм корреляции распределённых событий;
• 03 правила сведения Trace ID и локальных журналов;
• 04 внутренние способы нормализации временных шкал;
• 05 методику анализа retry-каскадов;
• 06 критерии веса consumer lag;
• 07 внутреннюю модель распространения устаревших статусов;
• 08 алгоритмы оценки производности скоринговых решений;
• 09 модель причинной связности многоуровневых убытков;
• 10 внутренние коэффициенты влияния каждого звена;
• 11 процессуальные шаблоны экстренных заявлений;
• 12 структуру каскадного Defense File;
• 13 методологию Контура М4.

Рынок видит, какие классы событий мы умеем соединять.

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

32 Чего нельзя делать при раскрутке каскада

Не признавать автоматически собственную вину

Фраза:

«Извините, мы всё сорвали»

может оказаться гораздо шире реальной причины.

Но и не отрицать очевидный факт

Если собственная система действительно дала сбой — это нужно учитывать.

Не называть внешний сбой форс-мажором без проверки

Не вести пять разных версий инцидента

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

Не удалять логи

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

Не пытаться вручную переписать timestamps

Не создавать «правильные» скриншоты после исправления интерфейса

Не ждать обновления агрегаторов пассивно, если от статуса уже зависят деньги и договоры

Не рассчитывать, что один судебный процесс автоматически решит остальные

Не соглашаться на все штрафы «чтобы сохранить отношения»

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

35 Что получает клиент

Не:

«У вас был retry storm».

Не:

«Во всём виновата Kafka».

Не:

«Подадим ст. 99 и завтра всё включат».

И не:

«Один суд решит все десять споров».

Клиент получает:

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

В зависимости от ситуации Бюро может подготовить:

• 01 карту первичного события;
• 02 единую каскадную хронологию;
• 03 карту API / интеграционного маршрута;
• 04 анализ Retry Storm;
• 05 карту распределённой трассировки;
• 06 анализ промежуточного брокера;
• 07 карту распространения устаревшего статуса;
• 08 квалификацию производных скорингов;
• 09 анализ условий блокировки;
• 10 антимонопольную квалификацию — если есть основания;
• 11 карту прямых и последующих убытков;
• 12 расчёт упущенной выгоды;
• 13 структуру уведомлений контрагентам;
• 14 материалы для заявления об обеспечительных мерах;
• 15 единую судебную фактологическую позицию;
• 16 пакет для профильных судебных представителей.

Но Бюро не гарантирует:

• 01 признание конкретного участника единственным виновником;
• 02 отмену всех производных ограничений;
• 03 принятие обеспечительных мер судом;
• 04 восстановление всех коммерческих лимитов;
• 05 применение антимонопольного режима к конкретной платформе;
• 06 взыскание всех заявленных каскадных убытков;
• 07 преюдициальность судебного акта для любых третьих процессов;
• 08 конкретный судебный исход.

Принципиальная позиция Бюро

Мы не тушим последствия по одному.

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

Обычная помощь:

«Напишем в пять служб поддержки».

Бюро:

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

Именно здесь находится высокая стоимость работы.

36 Официальные источники

Статья 10 — пределы осуществления гражданских прав и запрет злоупотребления правом.

Статья 15 — убытки: реальный ущерб и упущенная выгода.

Статья 310 — пределы одностороннего отказа и изменения обязательств.

Статья 328 — встречное исполнение обязательств.

Статья 393 — возмещение убытков при нарушении обязательства.

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

Статья 404 — вина кредитора и непринятие разумных мер к уменьшению убытков.

Статья 406 — просрочка кредитора.

Статья 450.1 — реализация права на односторонний отказ.

Статья 152 — защита деловой репутации применительно к распространению не соответствующих действительности порочащих сведений; для организаций применяются правила статьи в предусмотренном ГК РФ объёме.

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

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

Статья 90 — основания обеспечительных мер.

Статья 91 — виды обеспечительных мер.

Статья 93 — заявление об обеспечении иска рассматривается судьёй единолично не позднее следующего дня после его поступления, без извещения сторон.

Статья 99 — предварительные обеспечительные меры до предъявления иска.

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

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

Статья 10 — запрет злоупотребления доминирующим положением.

Статья 10.1 — специальный запрет монополистической деятельности хозяйствующего субъекта — владельца цифровой платформы при наличии предусмотренной законом совокупности условий.

Применяется к отношениям в сфере информации и информационных систем в предусмотренном законом объёме.

Технические стандарты

Открытый технический стандарт передачи информации о распределённой трассировке между компонентами.

Открытый стандарт и инструментарий наблюдаемости распределённых систем.