Реестр общих проблем

• Статус: опрос поля закончен 2026-09-17 (этапы И1–И5); мини-исследования М1–М3 закрыли всех отложенных кандидатов 2026-09-18; М4 закрыла последнюю открытую запись P-CHG-04 2026-09-22 — открытых записей не осталось
• Метод: 00-plan.md, форма записи — раздел 3
• Заполнено: формулировка, проявление, признак, цена × влияние, жанр, зрелость · частота — после И2, см. итог в конце
• Чем закрыто у нас — заполнено на И3 по спискам карточек блоков, не поиском по терминам
• Дополнение: мини-исследования М1 по P-API-01 (2026-09-17), М2 по P-ACC-02 и М3 по P-ACC-01 (2026-09-18), М4 по P-CHG-04 (2026-09-22) — после закрытия основного исследования

Коды записей — область плюс номер: P-REQ-01, P-CHG-02. Записи пилотов носят коды P-DEG-NN и P-DDEC-NN. Сквозной нумерации нет: реестр пополняется по областям, и новая запись не сдвигает соседние.

Что уже собрано пилотами и сюда не переписывается. И0 · деградация — 8 записей, И0′ · декомпозиция данных — 7 записей. Они входят в общий реестр как готовые фрагменты; ниже — остальное поле.

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

---

A · Требования и цели

P-REQ-01 · Нефункциональные требования названы словами, а не числами

• Проявление. «Должно быть быстро», «должно выдерживать нагрузку». На ревью спорят, выполнено или нет, и спор нечем закрыть.
• Признак. У каждого требования есть величина, единица и способ проверки — или нет. Проверка в одну строку: можно ли написать запрос к метрикам, который ответит «да» или «нет».
• Требует решения? Нет. Это дисциплина шага W0, а не выбор. Записана потому, что из неё вырастает P-REQ-02, а без неё та не формулируется.
• Цена × влияние. Неприменимо.
• Жанр. Карточка и шаг процесса.
• Чем закрыто у нас. Шаг W0 и OPS-09. Достаточно — решать тут нечего
• Зрелость. Устоявшаяся.

P-REQ-02 · Цель уровня обслуживания выбрана не по цене её достижения

• Проявление. В требованиях 99,99 %, потому что это выглядит солидно. Во что обходится каждая девятка — не считали; бюджета ошибок нет, поэтому любой инцидент обсуждается как катастрофа.
• Признак. Стоит ли рядом с целью цена её достижения и бюджет ошибок. Если цель есть, а бюджета нет — цель не выбрана, а объявлена.
• Требует решения? Да.
• Цена × влияние. Дорого × высокое → полная форма. Обещание снимается согласованием, а не правкой конфигурации.
• Известные решения. Цель, выведенная из того, что теряет пользователь, а не из круглого числа; бюджет ошибок как расходуемый ресурс; разные цели для разных сценариев одной системы.
• Жанр. Решение. Кандидат в набор.
• Чем закрыто у нас. OPS-09 · SLI, SLO и бюджет ошибок — механика целиком. Решения нет
• Зрелость. Устоявшаяся (канон — Google SRE, «Service Level Objectives»).

B · Контракты и взаимодействие

P-API-01 · Изменение контракта ломает потребителя, о котором не знали

• Проявление. Поле переименовали, выкатили, сломался кто-то третий. Список потребителей выясняется по факту падения.
• Признак. Известен ли список потребителей интерфейса и есть ли политика совместимости: что считается ломающим изменением и что происходит дальше.
• Требует решения? Да.
• Цена × влияние. Дорого × высокое → полная форма. Смена политики совместимости задним числом требует согласования со всеми потребителями сразу.
• Частота. Измерена, но в соседней популяции — в библиотеках, а не в сервисах (мини-исследование М1). Ломающие изменения часты: 30,0 % релизов Maven содержат хотя бы одно, и в минорных они встречаются практически так же часто, как в мажорных, — 35,7 % против 35,8 %. Задевают они при этом мало кого: 7,9 % клиентов из 293 817; медиана затронутых клиентов на одно изменение — 2,54 %. Весома не частота, а разрыв между ними: почти каждое ломающее изменение не задевает никого, и автор не знает, какое из них исключение.
• Известные решения. Только обратно совместимые изменения плюс срок жизни поля; версия в пути или в заголовке; контрактные тесты со стороны потребителя (каталог, Consumer-driven contract test); реестр схем.
• Жанр. Решение. Кандидат — это тот «контракт данных», который И0′ отвёл от D-07 как чужую тему.
• Чем закрыто у нас. NET-17 · Версионирование API и совместимость и NET-18 · Контракты и схемы — механика целиком. Решения нет
• Зрелость. Устоявшаяся.

P-API-02 · Стиль взаимодействия выбран по привычке

• Проявление. Всё через HTTP и JSON, потому что так начали. Или всё через события, потому что это современно.
• Признак. Назван ли инвариант или требование, из которого следует именно этот стиль. Если единственный ответ — «у нас так принято», выбора не было.
• Требует решения? Да.
• Цена × влияние. Дорого × высокое → полная форма, с рыночным слоем: стиль и его реализации берутся с рынка и устаревают.
• Известные решения. Синхронный вызов, обмен сообщениями, предметный протокол (каталог, Communication Styles); выбор формата и схемы отдельно от выбора транспорта.
• Жанр. Решение. Не путать с D-04: там выбирают синхронность и координацию для участка процесса, здесь — транспорт и форму сообщения.
• Чем закрыто у нас. NET-08 · Стили API: обзор и выбор плюс NET-09…NET-12 по каждому стилю. Ближе всего к решению из всех карточек — в ней есть сопоставление вариантов; вопрос, нужен ли документ сверх неё, решится при сведении
• Зрелость. Устоявшаяся.

P-API-03 · Повтор создаёт дубль

• Проявление. Пользователь нажал дважды или клиент повторил по таймауту — создалось два заказа.
• Признак. Есть ли у операции ключ идемпотентности и хранится ли результат по нему.
• Требует решения? Нет — это следствие. Асинхронность без идемпотентного потребителя уже работает дисквалификатором в D-04; здесь нечего выбирать, есть что построить.
• Жанр. Карточка.
• Чем закрыто у нас. NET-16 · Идемпотентность. Достаточно
• Зрелость. Устоявшаяся.

C · Периметр и доступ

P-ACC-01 · Один клиент съедает ёмкость всех

• Проявление. Один интегратор с циклом без задержки кладёт сервис для остальных.
• Признак. Есть ли лимит и по какому ключу он считается: клиент, пользователь, адрес, метод. Ключ важнее величины.
• Требует решения? Да.
• Цена × влияние. Дёшево × высокое → короткая форма.
• Частота. Измерена косвенно, через митигации (мини-исследование М3). В отчёте GitHub за август 2026 года три инцидента из пяти гасились ограничением входящей нагрузки, в двух названо усиление повторами со стороны клиента, в одном — отсутствие автоматического предохранителя как причина того, что душить пришлось руками. CWE-400 · Uncontrolled Resource Consumption — 24-е место в CWE Top 25 за 2024 год (31 770 записей CVE за год). Поправка к формулировке: усиливающий потребитель у GitHub чаще оказывался своим же сервисом, а не внешним интегратором.
• Известные решения. Лимит по ключу с окном; квота на период; приоритет вместо отказа; предупреждение до отсечения.
• Жанр. Решение, короткая форма. → Не документ (М3): EDGE-06 даёт сравнение, умолчание и область применения. Остаток — три уточнения в карточку и вопрос «срабатывает ли ограничитель сам», принадлежащий REL-03 и D-06
• Чем закрыто у нас. EDGE-06 · Rate limiting — механика целиком, и этого достаточно
• Зрелость. Устоявшаяся.

P-ACC-02 · Модель доступа выбрана до того, как описаны правила

• Проявление. Взяли роли, а правила зависят от связи объекта с пользователем — «владелец документа», «участник проекта». Появляются особые случаи, потом особые случаи особых случаев.
• Признак. Выражаются ли существующие правила выбранной моделью без исключений. Одно исключение — предупреждение, три — модель выбрана не та.
• Требует решения? Да.
• Цена × влияние. Дорого × высокое → полная форма. Смена модели доступа задевает каждую проверку в коде.
• Частота. Измерено следствие, не причина (мини-исследование М2). Нарушенное управление доступом — первая категория OWASP Top 10 2021 (поднялась с пятого места): 318 487 случаев — больше, чем у любой другой категории, средняя частота встречаемости 3,81 %, максимальная 55,97 %, выборка — свыше 500 тыс. приложений. В CWE Top 25 за 2024 год три записи про авторизацию: CWE-862 — 9-е место, CWE-269 — 15-е, CWE-863 — 18-е. Измеряется поломка, а не выбор модели: связь между ними — довод, а не наблюдение.
• Известные решения. Роли; атрибуты; отношения; их сочетания. Выбор определяется не вкусом, а тем, от чего зависит право: от субъекта, от контекста или от связи.
• Жанр. Решение. Кандидат. → Не документ (М2): SEC-04 несёт сравнение трёх моделей с условиями, умолчание, область применения и признак смены модели. Остаток — проверяемый порог «три исключения» в карточку и два входа в существующие решения
• Чем закрыто у нас. SEC-04 · Авторизация: RBAC, ABAC, ReBAC — механика целиком, и данные подтвердили именно её
• Зрелость. Устоявшаяся.

P-ACC-03 · Класс защищаемых данных не назван, и режим применяется ко всему или ни к чему

• Проявление. Либо шифруют и аудируют всё подряд, платя за это везде, либо не делают нигде и узнают о требовании от юриста.
• Признак. Существует ли перечень классов данных и того, что каждый обязывает: шифрование на диске, аудит доступа, локализация, ограниченный круг лиц, срок хранения.
• Требует решения? Да, но частично уже разнесено: класс данных входит в D-02 v5.0, D-05 v3.0 и D-07.
• Цена × влияние. Дорого × высокое.
• Жанр. И то и другое: карточка (её нет — в очереди) плюс вход в три существующих решения. Отдельного документа, похоже, не требует.
• Чем закрыто у нас. Ничем. DATA-19 покрывает хранение и удаление, но не классификацию по режиму защиты. Дыра в карточках
• Зрелость. Устоявшаяся в регулировании, разрозненная в инженерной практике.

D · Эксплуатация и наблюдаемость

P-OPS-01 · Сигналов много, а «что сломалось» не отвечается

• Проявление. Дашбордов десятки, в инциденте смотрят в логи и гадают. «Всё медленно» — и непонятно, какой участок цепочки.
• Признак. Можно ли по имеющейся телеметрии ответить, на каком участке ушло время, не добавляя ничего нового. Если нет — телеметрия отвечает на заранее заданные вопросы, а инцидент задаёт незаданные.
• Требует решения? Да.
• Цена × влияние. Дорого × высокое → полная форма. Сквозная трассировка — изменение во всех участниках сразу, а не настройка.
• Частота. ⚠️ Измерена не она, а цена решения. Расходы на наблюдаемость — в среднем 17 % от расходов на вычислительную инфраструктуру, медиана 10 %; 37 % называют её слишком дорогой, 39 % — сложной, 38 % жалуются на шум; в среднем 8 технологий на компанию (Grafana Labs, опрос 2025, n = 1255; опрос проведён поставщиком средств наблюдаемости и набирался через его каналы — сдвиг выборки в сторону тех, кто уже вложился, надо держать в уме).
• Известные решения. Сбор логов, метрики приложения, сквозная трассировка, журнал аудита, журнал выкатов (каталог, Observability); выбор определяется тем, какие вопросы надо уметь задать, и ценой хранения.
• Жанр. Решение. Кандидат: состав телеметрии и её цена.
• Чем закрыто у нас. OPS-07 · Observability и OPS-08 · Стоимость observability — механика и экономика обе. Решения нет
• Зрелость. Устоявшаяся.

P-OPS-02 · Выкат необратим на практике, хотя обратим на бумаге

• Проявление. Откат кода есть и работает. Откат вместе с ним не работает, потому что миграция схемы уехала вперёд и старый код с новой схемой не живёт.
• Признак. Есть ли в выкате изменение, несовместимое с предыдущей версией кода. Если есть — отката нет, что бы ни было написано в регламенте.
• Требует решения? Да.
• Цена × влияние. Дорого × высокое → полная форма.
• Частота. Измерена косвенно, и это самая весомая цифра исследования. В выборке инцидентов облачных сервисов Microsoft ведущие причины — инфраструктура 27,2 %, конфигурация 24,5 %, ошибки в коде 21,5 %, внешнее использование 14,1 %, операционные ошибки 12,7 % (Yan, Chen, Ma и др., arXiv:2504.08865). Конфигурация и операции вместе — 37,2 %, то есть изменение системы порождает больше инцидентов, чем ошибки в её коде. Оговорка: работа посвящена сервисам генеративного ИИ, сравнение с прочими приводится, но перенос долей на системы вообще — экстраполяция.
• Известные решения. Изменение схемы в два шага — сначала совместимое, потом сужающее; флаг вместо ветки; выкат порциями с проверкой.
• Жанр. Решение. Относится к третьей стадии — системе под изменением.
• Чем закрыто у нас. OPS-02 · Стратегии выкатки и DATA-17 · Миграции схемы без простоя — механика целиком. Решения нет
• Зрелость. Устоявшаяся.

E · Стоимость

P-COST-01 · Счёт растёт, и неизвестно, вместе с чем

• Проявление. Расходы выросли в полтора раза. На вопрос «почему» отвечают «выросла нагрузка», но в полтора ли раза — никто не сверял.
• Признак. Есть ли метрика стоимости на единицу полезной работы — на запрос, на активного пользователя, на заказ. Без неё рост неотличим от неэффективности.
• Частота. Не измерена. Но цена смежного события измерена: более половины (54 %) значимых отказов обошлись дороже 100 тыс. долларов, 16 % — дороже миллиона (Uptime Institute, Annual Outage Analysis 2024; опрос, сами авторы советуют относиться к данным об отказах скептически — они коммерчески чувствительны).
• Требует решения? Скорее нет. Выбор здесь один — какую единицу взять, — и он невелик. Остальное дисциплина.
• Жанр. Карточка и процесс.
• Чем закрыто у нас. PERF-11 · Стоимость, TCO и unit-экономика. Достаточно
• Зрелость. Устоявшаяся.

F · Система под изменением

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

P-CHG-01 · Переехать надо, остановиться нельзя

• Проявление. Данные надо перевезти в другое хранилище или под другую схему, а система работает круглосуточно.
• Признак. Существует ли способ проверить, что перевезённое совпадает с исходным, до переключения. Если сверки нет, миграция необратима, как бы она ни называлась.
• Требует решения? Да.
• Цена × влияние. Дорого × высокое → полная форма.
• Частота. Та же доказательная база, что у P-OPS-02: изменение системы — ведущая причина инцидентов, 37,2 % против 21,5 % у ошибок в коде (arXiv:2504.08865). Отдельной цифры по миграциям нет.
• Известные решения. Двойная запись с источником порядка; перенос порциями с курсором; сверка выборкой и сплошная; переключение чтения раньше записи; strangler fig и слой предотвращения порчи.
• Жанр. Решение. Первый документ третьей стадии.
• Чем закрыто у нас. ARCH-13 · Миграция монолита: strangler fig и DATA-17 — частично: обе про приёмы, ни одна про перенос данных между хранилищами целиком. Решения нет
• Зрелость. Устоявшаяся.

P-CHG-02 · Два пути живут вместе дольше, чем планировалось

• Проявление. Старый и новый путь чтения сосуществуют «временно». Через год оба в проде, и каждое изменение делается дважды.
• Признак. Назначены ли срок снятия старого пути и владелец, который его снимает. Не назначены — путь постоянный.
• Требует решения? Да, но дёшево.
• Цена × влияние. Дёшево × высокое → короткая форма. Вероятно, раздел P-CHG-01, а не отдельный документ.
• Жанр. Решение или раздел решения — определится при сведении.
• Чем закрыто у нас. ARCH-13 упоминает сосуществование, срок и владельца — нет. Решения нет
• Зрелость. Устоявшаяся.
• Замечание. Оба наших прогона записали это в последствия ADR и ни один — в решения. Симптом того, что документа нет.

P-CHG-03 · Новый код обязан работать одновременно со старым

• Проявление. Во время выката в проде две версии сразу. Они читают одну схему и пишут одни очереди.
• Признак. Есть ли изменение, при котором две версии несовместимы между собой — не с данными, а друг с другом.
• Требует решения? Нет — следствие P-OPS-02 и P-CHG-01.
• Жанр. Карточка.
• Чем закрыто у нас. DATA-17 и OPS-02. Достаточно
• Зрелость. Устоявшаяся.

P-CHG-04 · Данные уходят в чужую организацию, и проверить там ничего нельзя

Запись добавлена 2026-09-18 после реестра, по итогам узкого прогона U-01. Остальные записи собраны опросом поля; эта — работой.

• Проявление. Часть системы или её данные передаются другой организации: продано направление, выделена дочерняя компания, сменён подрядчик, партнёр берёт обслуживание на себя. После передачи мы не видим ни метрик приёмника, ни того, дошло ли до него изменение, ни того, исполнено ли требование клиента о стирании.
• Признак. Есть ли хоть один способ проверить состояние данных на той стороне, кроме переписки. Если единственный ответ — «спросим у них», проверки нет. Уточнено М4: способа, кроме переписки, экспериментально не нашлось — но переписка ловит неисполнение в каждом пятом случае. Это не проверка состояния, а выборочный контроль, и планировать его надо как выборочный контроль: по частоте, а не по поводу.
• Требует решения? Да, и критерий общности пройден (М4, 2026-09-22) — всеми тремя типами подтверждения сразу. Нужен ли под это документ — отдельный вопрос и отдельная развилка: М1–М3 прошли критерий все трое, а документ дали один. Ни один документ набора этого не обслуживает: D-07 даёт реестр копий, но последняя строка в нём впервые оказалась чужой; D-08 и D-09 получили по MAJOR именно на этом случае и закрыли перенос, а не то, что после него.
• Цена × влияние. Дорого × высокое → полная форма. Обязательства перед людьми, чьи данные переданы, остаются нашими независимо от того, у кого данные.
• Частота. Частота отказа неизмерима по устройству предмета (М4): чтобы измерить, в каком состоянии данные на той стороне, нужен доступ к той стороне — тот самый, которого проблема лишает. Закрыто частотой обстоятельства: более четырёх компаний из пяти провели три и более продажи направлений за 36 месяцев, более половины продавцов живут с переходным соглашением, и они же называют его самой частой трудностью после сделки (Deloitte, опрос 500 руководителей, 2024). Из четырёх проявлений записи числом закрыто одно.
• Известные решения. Приложение к договору с составом и форматом передаваемого; сверка по контрольным суммам на стороне приёмника; обязательство приёмника отвечать на запросы о стирании в срок; срок, после которого наши копии удаляются. Всё это договорные механизмы, и это само по себе наблюдение: технических тут почти нет.
• Жанр. Решение — и это предсказание по гипотезе о жанре, записанное до работы: предмет выглядит обещанием (что мы обязуемся передать и что можем обещать после) плюс необратимостью (переданное не отзывается), а не меню механизмов. Если запись когда-нибудь дойдёт до документа и он окажется меню — гипотеза ошиблась.
• Чем закрыто у нас. Ничем. Ближайшее — строка «приёмник не наш» в D-08 v2.0 и «передача ПДн» в D-09 v2.0; обе про переход, ни одна про то, что после
• Зрелость. Устоявшаяся в юридической практике, отсутствующая в инженерной. Подтверждено М4 с неожиданной стороны: все три содержательных источника — измерения того, как плохо исполняется юридическая норма, и ни один не описывает технического способа установить состояние данных на чужой стороне.

G · Организация

P-ORG-01 · Одна команда держит больше доменов, чем помещается

• Проявление. Команда отвечает за четыре несвязанные области. Переключение между ними стоит дороже самой работы; глубины нет ни в одной.
• Признак. Сколько предметных областей на команду, а не сколько сервисов. Сервисов может быть много при одном домене — это нормально; доменов больше двух-трёх при одной команде — нет.
• Требует решения? Да, но не отдельным документом: это вход в решение о гранулярности — D-02 и D-05, где уже есть ось организационного соответствия и дисквалификатор «сервисов больше, чем команд».
• Цена × влияние. Дорого × высокое.
• Жанр. Вход в существующие решения плюс карточка, которой, возможно, нет.
• Чем закрыто у нас. Ничем. OPS-14 про роли и ссылается на Team Topologies в источниках, но когнитивной нагрузки как признака нет. Дыра в карточках
• Зрелость. Устоявшаяся (канон — Skelton & Pais, когнитивная нагрузка команды).

---

Предварительный счёт после И1

Записей от пилотов	15 (8 + 7)
Записей И1	15
Всего в черновике	30
Из них требуют решения	20
Из них помечены «не требует решения» или «следствие»	5
Кандидатов в новые документы	7 — P-REQ-02 цели уровня обслуживания · P-API-01 совместимость контракта · P-API-02 стиль взаимодействия · P-ACC-01 лимитирование · P-ACC-02 модель доступа · P-OPS-01 состав телеметрии · P-CHG-01 миграция без остановки
Записей, входящих в существующие решения	P-ACC-03, P-CHG-02, P-ORG-01

Тридцать записей при плановых двадцати-тридцати — верхняя граница достигнута до этапов И2–И4. Сведение будет работать на сокращение, а не на добор: часть записей схлопнется в следствия, часть окажется входами в существующие документы.

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

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

---

Итог И2 · данные отрасли и публичные разборы

Что удалось измерить

Что измерено	Значение	Источник и оговорка
Изменение системы порождает больше инцидентов, чем ошибки в коде	Конфигурация 24,5 % + операционные ошибки 12,7 % = 37,2 % против 21,5 % у кода; инфраструктура 27,2 %	arXiv:2504.08865, выборка инцидентов Microsoft, июнь 2020 — февраль 2024. Оговорка: работа про сервисы генеративного ИИ; перенос долей на системы вообще — экстраполяция
Сеть — крупнейшая единичная причина отказов ИТ-услуг	19 % отказов площадок; авторы отдельно отмечают сеть как ведущую причину именно отказов услуг	Uptime Institute 2024. Оговорка: опрос про площадки, не про приложения
Цена значимого отказа	54 % дороже 100 тыс. долларов, 16 % дороже миллиона	Там же. Авторы сами советуют относиться скептически
Цена наблюдаемости	17 % от расходов на вычисления в среднем, медиана 10 %; 8 технологий на компанию	Grafana Labs 2025, n = 1255. Оговорка: опрос поставщика, набор через его каналы
Усиление ретраями	Более 50 % изученных метастабильных отказов	OSDI '22 — уже было в И0
Сорок три секунды против суток	43 с разделения сети → 24 ч 11 мин деградации	GitHub, 2018 — уже было в И0′

Чего измерить не удалось — и почему

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

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

Отсюда практическое следствие для очереди: строить её только на частоте нельзя — получится очередь по величине рынка, а не по величине проблемы. Частота работает как довод, когда она есть, и не работает как сортировка.

Поправка к правилу допуска: опрос от поставщика

К четырём поправкам о каноне добавляется пятая, про тип 2.

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

Опрос Grafana Labs — ровно этот случай: набор через каналы поставщика средств наблюдаемости смещает выборку к тем, кто уже вложился в наблюдаемость. Цифра «17 % от расходов на вычисления» от этого не перестаёт быть полезной, но означает «у тех, кто этим занимается», а не «в среднем по отрасли».

Очередь документов после И2

Первые две позиции опираются на данные, остальные — на рассуждение, и это разделение записано намеренно.

#	Документ	На чём основана позиция
✅	P-CHG-01 → D-08	Написан 2026-09-17. Данные: изменение системы даёт 37,2 % инцидентов против 21,5 % у кода
✅	P-OPS-02 → D-09	Написан 2026-09-17 отдельным документом: предмет другой — код и схема, а не данные
⊘	P-OPS-01 слита в D-10	Третий случай правила «карточка делает работу решения», и первый, стоивший документа из очереди. Решающая часть — обязательство отвечать на вопросы — оказалась обратной стороной цели
✅	P-REQ-02 → D-10	Написан 2026-09-17 вместе с P-OPS-01 одним документом
✅	P-API-01 → D-11	Написан 2026-09-18 по итогам М1. Позиция стояла на рассуждении, документ получил данные
6	P-ACC-02 · Модель авторизации	Рассуждение: ошибка модели проявляется через год и правится в каждой проверке
7	P-API-02 · Стиль взаимодействия	Рассуждение. Единственный кандидат с рыночным слоем, то есть стареющий быстрее прочих
8	P-ACC-01 · Лимитирование	Рассуждение. Короткая форма, дешевле остальных

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

---

Итог И3 · наш корпус

Правило поймало вторую ошибку того же рода

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

Запись	Что я написал	Как на самом деле
P-DDEC-05 · удаление данных человека	«Ничем. Дыра и в карточках, и в решениях»	DATA-19 покрывает механику полнее, чем её описал реестр. Исправлено в И0′
P-DDEC-07 · предел по соединениям	«Ничем. Дыра в карточках»	PERF-06 · Пулы соединений, N+1 и батчинг покрывает механику пулов. Не покрыт только множитель от числа сервисов: предел хранилища упирается в число потребителей, умноженное на экземпляры. Найдено только сейчас

Оба промаха — одного происхождения: поиск по терминам, которыми я сам же назвал проблему. Правило внесено в метод после первого случая; второй показывает, что оно не запасное, а обязательное. Дыра в карточках по P-DDEC-07 остаётся, но она уже: не «нет карточки», а «в карточке нет одного множителя», и это другая по цене правка.

Покрытие: сводка по всем тридцати записям

	Записей
Механика покрыта карточками, решения нет	13
Покрыто полностью — решать нечего	8
Дыра в карточках	3 — класс защищаемых данных, когнитивная нагрузка команды, множитель соединений
Покрыто частично, требует и того и другого	6

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

Главный вывод — и он не про очередь

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

Это подтверждает разделение жанров, объявленное в README, причём третий раз подряд и из трёх независимых источников — так было в И0, в И0′ и теперь на всём поле. Совпадение можно было счесть случайным дважды, но не трижды.

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

Меняет ли И3 очередь

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

Одно исключение стоит внимания: у P-API-02 (стиль взаимодействия) карточка NET-08 называется «обзор и выбор» и содержит сопоставление вариантов. Это ближе к решению, чем любая другая карточка в наборе. Вопрос «нужен ли здесь документ сверх карточки, или карточке не хватает только рыночного слоя и дисквалификаторов» — первый вопрос сведения.

---

Итог И4 · сведение

1. Слияния и понижения

Что	Решение сведения
P-DEG-08 «деградированный режим навсегда» и P-CHG-02 «два пути живут вместе дольше»	Слиты. Один и тот же признак — не назначены срок и владелец снятия — и одно и то же лечение. Общая формулировка сильнее обеих: временное состояние становится постоянным, потому что его снятие никому не поручено. Приложима и к режиму деградации, и к двум путям чтения, и к фича-флагу
P-DDEC-05 удаление данных	Понижена до частного случая P-DDEC-01: изменение обязано дойти до всех копий, удаление — такое же изменение. Решено при разборе И0′
P-API-03 повтор создаёт дубль	Следствие. Дисквалификатор в D-04 уже есть, выбора нет — есть работа
P-CHG-03 новый код со старым	Следствие P-OPS-02. Механика в DATA-17
P-DEG-07 таймауты по цепочке	Не требует решения. Отведена ещё при сборке D-06: согласовать таймауты — работа, а не выбор
P-REQ-01, P-COST-01	Не требуют решения. Дисциплина шагов W0 и W10
P-ACC-03 класс защищаемых данных, P-ORG-01 когнитивная нагрузка, P-DDEC-07 множитель соединений	Входы в существующие решения, не новые документы. Первые два уже внесены в D-02 v5.0 и D-05 v3.0

2. Карточка, которая делает работу решения

P-API-02 — стиль взаимодействия — документа не порождает, и это единственный такой случай из тридцати.

Карточка NET-08 · Стили API: обзор и выбор содержит то, ради чего обычно заводят документ: сравнение семи вариантов с колонкой «слабое место», умолчание («наружу REST, внутрь gRPC или сообщения»), область применения («стиль выбирается для границы, а не для системы») и главный вопрос перед выбором — синхронно по смыслу или асинхронно. Не хватает дисквалификаторов, рыночного слоя и формы записи; но самое тяжёлое в этом выборе — синхронность — уже решается в D-04, а самое дорогое — необратимость публичного контракта — принадлежит P-API-01.

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

3. Критерий общности, применённый по-настоящему

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

Кандидат	Канон	Независимое подтверждение	Итог
P-CHG-01 миграция без остановки	Каталог практик, strangler fig	Данные (37,2 % инцидентов) и оба прогона, упершиеся в миграцию	✅
P-OPS-02 выкат и откат	Каталог, OPS-02	Данные (та же выборка)	✅
P-OPS-01 состав телеметрии	Каталог, раздел Observability	Опрос с оговоркой о поставщике	✅
P-REQ-02 цели уровня обслуживания	Google SRE	Наш прогон: дисквалификатор об архитектурном кванте в E-02 родился именно из целей, назначенных без проверки достижимости	✅
P-API-01 совместимость контракта	Каталог, контрактные тесты	Было: нет. Ни данных, ни разбора, ни прогона — наши кейсы до контрактов не дошли. Стало: данные — пять работ, М1	⚠️ → ✅
P-ACC-02 модель авторизации	SEC-04	Было: нет. Стало: данные — OWASP Top 10 2021 и CWE Top 25, М2	⚠️ → ✅
P-ACC-01 лимитирование	EDGE-06	Было: нет. Стало: публичные разборы — отчёт GitHub за август 2026, М3	⚠️ → ✅

Три кандидата из семи держатся на одном каноне. Это не значит, что проблемы нет: значит, что подтверждения нет — и по собственному правилу мы такие записи не выбрасываем, но и документов по ним не пишем.

Дополнение 2026-09-17. Один из трёх — P-API-01 — критерий прошёл: подтверждение найдено мини-исследованием М1 и оказалось не там, где его ждали. Ждали третьего кейса, нашли данные.

Дополнение 2026-09-18. Оставшиеся двое прошли критерий тоже — М2 и М3. Критерий прошли все трое, а документ из этого вышел один. Двух оставшихся закрыло не отсутствие подтверждения, а карточное правило: подтверждение нашлось и подтвердило карточку. Это стоит записать как свойство критерия: общность проблемы и нужда в документе — разные вопросы, и первый на второй не отвечает.

4. Итоговый счёт

	Записей
Собрано за три этапа и два пилота	30
Слито	−1
Понижено до следствий и частных случаев	−4
Не требует решения	−3
Входит в существующие решения	−3
Покрыто уже написанными D-06 и D-07	−11
Порождает новый документ	4
Отложено до подтверждения	3
Не документ — карточка делает работу	1

Тридцать записей дали четыре документа к написанию — против семи, которые виделись после И1. Сокращение вдвое сделали не вкус и не усталость, а критерий общности и слияния; ровно на это сведение и рассчитано.

5. Очередь — итоговая

Пишем

#	Документ	Почему здесь
1	Миграция данных без остановки	Данные и оба прогона. Область не покрыта ничем
2	Выкат и откат	Те же данные. Отдельно от первого: объект другой — код и схема, а не данные
3	Состав телеметрии и её цена	Единственный кандидат с измеренной экономикой решения
4	Цели уровня обслуживания и бюджет ошибок	Вход для всего остального: без цели не считается ни деградация, ни стоимость

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

Откладываем до подтверждения

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

Дополнение 2026-09-17. Ожидание оказалось лишним для первого из трёх: совместимость контракта вышла из отложенных по М1 — подтверждение нашлось в данных, а не в прогоне. И это довод в пользу мини-исследований: отложить до кейса значит отложить до случая, а случай может не прийти вовсе.

Дополнение 2026-09-18. Отложенных не осталось: М2 закрыла модель доступа, М3 — лимитирование. Обе прошли критерий общности и обе не дали документа — карточка делает работу. Раздел «откладываем до подтверждения» закрыт целиком, и главный его урок в том, что отложенность была не тем вопросом: спрашивать надо было не «общая ли проблема», а «есть ли что решать сверх карточки».

Не документ

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

6. Что сведение говорит о вопросе сходимости

В плане ревизии E-02 записано: если третий кейс снова даст MAJOR всем документам, форма не сходится. Исследование различило два объяснения, ради чего и затевалось.

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

Проверить форму можно будет только после. Третий кейс имеет смысл запускать, когда набор перестанет иметь известные дыры — иначе он снова измерит покрытие вместо формы.

---

Мини-исследование М1 · P-API-01 · совместимость контракта

• Статус: пройдено · 2026-09-17
• Повод: на И4 кандидат остался в отложенных — канон есть, независимого подтверждения нет
• Механизм: согласован при обсуждении плана: если чего-то не хватает, тема добирается отдельным коротким прогоном, а не ждёт третьего кейса
• Задача: найти подтверждение типа 2 (данные) или типа 3 (публичный разбор) — либо записать, что его нет, и оставить кандидата отложенным

1. Что нашлось

Работа	Выборка и метод	Что говорит
Raemaekers, van Deursen, Visser. Semantic Versioning versus Breaking Changes (SCAM 2014, расширено в JSS 2017)	22 205 библиотек, 144 934 двоичных архива, 7 лет Maven Central, срез 2011 года; двоичная несовместимость по Clirr	30,0 % релизов содержат хотя бы одно ломающее изменение. Мажорные — 35,8 %, минорные — 35,7 %, патчи — 23,8 %
Ochoa, Degueule, Falleri, Vinju. Breaking bad? (EMSE 2022, arXiv:2110.07889) — внешняя реплика первой работы	119 879 обновлений библиотек, 293 817 клиентов; статический анализ байт-кода (Maracas), срок продлён на семь лет	83,4 % обновлений соответствуют семантическому версионированию, затронуты 7,9 % клиентов. Большинство ломающих изменений приходится на код, которым не пользуется ни один клиент; соблюдение правил со временем растёт
Xavier, Brito, Hora, Valente. Historical and Impact Analysis of API Breaking Changes (SANER 2017)	317 библиотек, 9 тыс. релизов, 260 тыс. клиентов; сравнение API через Eclipse JDT	27,99 % изменений API ломающие (медиана по библиотекам — 14,78 %). Медиана затронутых клиентов — 2,54 %, верхняя четверть — 13,10 %. Из 16 291 типа, задетого ломающими изменениями, хоть одним клиентом используются 1 290 (7,91 %)
Venturini, Cogo, Polato, Gerosa, Wiese. I depended on you and you broke me (TOSEM 2023)	npm; сборки зависимых пакетов, падающие при обновлении зависимости	12 % зависимых пакетов и 14 % их релизов пострадали при обновлениях не мажорных версий; 44 % ломающих изменений внесены в минорных и патч-релизах. Оправились сами примерно в половине случаев — чаще сменой версии поставщика, чем правкой своего кода
Sohan, Anslow, Maurer. A Case Study of Web API Evolution (SERVICES 2015)	9 публичных веб-API (Facebook, Twitter, Stripe, GitHub, Salesforce, Google Calendar, Google Maps, WordPress, OpenStreetMap), 2011–2014; ручное кодирование журналов изменений двумя кодировщиками	Единственная работа про веб-API, а не про библиотеки. Три несовместимых способа обозначать версию — номер, дата, major.minor — и прямое наблюдение: веб-API нередко ломают совместимость, не меняя идентификатор версии. Изменения объявляются свободным текстом на странице, в рассылке или в ленте

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

2. Как это читается

Первое: частота ломающих изменений и частота сломанных потребителей — разные величины, и расходятся они на порядок. Ломающих изменений много — от четверти до трети релизов. Задетых клиентов мало — единицы процентов. Причина названа прямо: изменение чаще всего приходится на часть интерфейса, которой никто не пользуется. У Xavier это сосчитано с другой стороны: из типов, задетых ломающими изменениями, кем-либо используются 7,91 %.

Второе: номер версии не является свидетельством совместимости. В минорных релизах Maven ломающие изменения встречаются почти так же часто, как в мажорных (35,7 % против 35,8 %); в npm 44 % их внесены в минорных и патч-релизах; веб-API ломаются, вовсе не меняя идентификатор. NET-17 говорит «версия нужна только для несовместимых изменений» — это предписание, и данные меряют, насколько оно не исполняется. Значит, управляющий орган здесь не номер, а проверка: сравнение схем в сборке и знание о потребителях.

Третье, и оно решает жанр. Все пять работ возможны только потому, что у исследователя есть список потребителей, которого нет у автора интерфейса. Maven Central и npm дают полный граф зависимостей — авторы посчитали то, чего в обычной жизни не видит никто. Это и есть предмет решения: список потребителей добывается, но не даром, и вопрос в том, сколько мы за него платим.

3. Поправка к правилу допуска — шестая

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

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

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

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

4. Вердикт

Критерий общности выполнен. Канон (каталог практик, контрактные тесты со стороны потребителя) плюс данные — четыре работы с названными выборками и методиками — плюс публичный разбор по веб-API, пусть и не постмортем. Подтверждение получено из типа, которого от этой записи не ждали: И4 рассчитывал на прогон.

P-API-01 выходит из отложенных и встаёт в очередь на документ. Отложенных остаётся двое: модель авторизации и лимитирование.

5. Чего мини-исследование не дало

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

6. Что это меняет в предмете будущего документа

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

Что нужно документу решения	Есть ли в NET-17 и NET-18
Сравнение вариантов с условиями применимости	Частично. Сравнивается, где разместить номер версии. Политика совместимости как выбор — нет
Умолчание	Есть: версия только для несовместимых изменений; клиент обязан игнорировать неизвестные поля
Область применения	Есть: любая граница между командами или наружу
Дисквалификаторы	Нет
Цена выбора в числах	Нет — и мини-исследование принесло как раз её

Предмет сужается так же, как у D-09. Карточки описывают, как обеспечивать совместимость. Решать надо, какое обещание совместимости мы даём потребителям и сколько платим за знание о них. Рабочее название — D-11 · Обещание совместимости интерфейса.

Это третье обещание в наборе, и совпадение стоит проверить при написании: D-06 — что пользователь получит при отказе, D-10 — как часто и как быстро, D-11 — что не сломается при изменении. Если три документа об обещаниях сойдутся по осям и дисквалификаторам, это скажет о шаблоне больше, чем ещё один кейс.

Проверено 2026-09-18, после написания D-11. Оси не сошлись ни одной, форма тоже: D-11 оказался перечисляемого типа, а не полного. Сошёлся один дисквалификатор — и он есть у всех четырёх документов с обещанием в предмете: обещание, исполнение которого нечем установить, обещанием не является. Разбор и предложение к шаблону — в бэклоге.

---

Мини-исследование М2 · P-ACC-02 · модель доступа

• Статус: пройдено · 2026-09-18
• Повод: второй из трёх отложенных на И4; механизм тот же, что в М1
• Итог коротко: критерий общности выполнен, документа не будет — карточка делает работу

1. Что нашлось

Источник	Тип и выборка	Что говорит
OWASP Top 10 2021, A01 Broken Access Control	Тип 2, данные. Свыше 500 тыс. приложений от 12 названных организаций и анонимных доноров; 8 категорий из 10 отобраны из данных, 2 — опросом	Поднялась с пятого места на первое. 34 сопоставленных CWE, 318 487 случаев — больше, чем у любой другой категории, 19 013 CVE. Средняя частота встречаемости 3,81 %, максимальная 55,97 %; проверялись на это 94 % приложений
MITRE CWE Top 25, 2024	Тип 2, данные. 31 770 записей CVE за год (июнь 2023 — июнь 2024), оценка «частота × тяжесть»	Три записи про авторизацию в двадцати пяти: CWE-862 Missing Authorization — 9-е место, CWE-269 Improper Privilege Management — 15-е, CWE-863 Incorrect Authorization — 18-е
Zanzibar (USENIX ATC 2019)	Тип 3, публичный разбор. Сотни служб Google	Триллионы записей доступа, миллионы запросов в секунду, 95-й процентиль меньше 10 мс, доступность выше 99,999 % за три года. Построена модель отношений, а не ролей
OWASP API Security Top 10 2023	Тип 4, каталог — и это важно, см. ниже	Авторизация занимает три позиции из десяти: API1 объектный уровень, API3 уровень свойства объекта, API5 уровень функции
BOLA in the Wild, arXiv:2605.25865	Тип 3 с двумя оговорками. 84 подтверждённых случая из раскрытых отчётов HackerOne 2021–2026, отобранных по числу голосов; классификация с помощью языковой модели, согласие 85 % на 20 образцах; автор один, лаборатория при поставщике средств защиты API	Горизонтальные нарушения (право зависит от связи объекта с пользователем) — 85,7 %, вертикальные (право зависит от роли) — 11,9 %. Последовательные числовые идентификаторы — в 36,9 % случаев

2. Две поправки, без которых эти цифры врут

Каталог OWASP по API — не данные, и это сказано в нём самом. Открытый сбор данных шёл с 1 сентября по 30 ноября 2022 года и, по словам авторов, не дал материала, пригодного для статистики; оценки распространённости выведены «из согласия участников проекта, основанного на их опыте в предметной области». Значит, «три позиции из десяти» — голос, а не измерение, и складывать его с OWASP Top 10 2021 как независимое подтверждение нельзя: это второй голос той же организации, а не второй источник. Ровно то, о чём поправка «цитирование — один голос»; здесь она впервые сработала не на книгах.

Работа про BOLA — поставщик плюс отбор по голосам. Пятая поправка (опрос от поставщика) применяется к ней прямо: лаборатория принадлежит продавцу средств защиты API, и вывод «объектная авторизация — главная беда API» — ровно тот, который выгодно получить. Вдобавок выборка набрана по числу голосов за отчёт, то есть меряет заметность, а не частоту: эффектную подмену идентификатора в адресе голосуют охотнее, чем скучный промах в проверке роли. Допускаю как таксономию, не как частоту: соотношение 85,7 / 11,9 показывает, какие формы нарушения бывают, и не показывает, в какой пропорции они случаются.

3. Что данные подтверждают на самом деле

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

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

И ровно это уже написано в карточке. SEC-04 говорит: «Самая частая уязвимость веб-приложений — не взлом аутентификации, а отсутствующая проверка на уровне объекта», и «RBAC разрастается комбинаторно, как только права зависят от объекта… признак, что нужна другая модель». Исследование подтвердило карточку. Подтверждение карточки — не повод писать документ.

4. Карточное правило, применённое честно

Что нужно документу решения	Есть ли в SEC-04
Сравнение вариантов с условиями применимости	Есть — три модели, колонка «когда уместна»
Умолчание	Есть — запрещено по умолчанию, одно место принятия решения, проверка там, где объект известен
Область применения	Есть — авторизация не выносится на границу периметра
Главный вопрос перед выбором	Есть — колонка «решение основано на»: субъект, контекст или связь
Признак, что модель выбрана не та	Есть качественно («разрастается комбинаторно»), нет порога
Дисквалификаторы, рыночный слой	Нет — но здесь варианты не продукты, а модели, и рынок не при чём

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

1. В карточку — проверяемый порог из формулировки записи: одно исключение из модели предупреждение, три — модель выбрана не та.
2. В D-02 — граница режет решение о доступе: право зависит от объекта, значит проверка живёт там, где объект, и разрез сервиса разрезает проверку. Кандидат в вопрос или дисквалификатор.
3. В D-06 — централизованная служба решений есть зависимость на горячем пути; что обещано пользователю, когда она недоступна, — форма деградации, которой в списке из семи нет.

---

Мини-исследование М3 · P-ACC-01 · лимитирование

• Статус: пройдено · 2026-09-18
• Повод: третий и последний из отложенных на И4
• Итог коротко: критерий общности выполнен, документа не будет, формулировка записи исправлена

1. Что нашлось

Источник	Тип и выборка	Что говорит
GitHub, отчёт о доступности за август 2026	Тип 3, публичные разборы. Пять инцидентов одного провайдера за один месяц, первоисточник	Три инцидента из пяти гасились ограничением входящей нагрузки. В двух названо усиление повторами со стороны клиента: 17 августа «латентная ошибка повторов резко усилила трафик к одной внутренней точке аутентификации» — пик отказов на входе 56,07 %, задеты около 29 тыс. организаций. 26 августа названа прямая причина ручного тушения: не было автоматического предохранителя, который придушил бы входящий поток при первых признаках перегрузки базы; пик отказов запуска выше 20 % в минуту
MITRE CWE Top 25, 2024	Тип 2, данные. 31 770 записей CVE	CWE-400 · Uncontrolled Resource Consumption — 24-е место. Присутствует, но у самого низа: как уязвимость неограниченное потребление весит мало
Fairness in multi-tenant systems, David Yanacek, AWS Builders' Library	Тип 4 с именем. Инженерный разбор Amazon	Ключ квоты бывает мельче клиента — «на конкретном ресурсе, которым клиент владеет». Разделение на отказ и сглаживание: незанятую ёмкость соседей можно отдавать наверх, и это уже не «лимит», а распределение
OWASP API Security Top 10 2023	Тип 4, каталог, оценки из согласия участников — см. оговорку в М2	API4 «Неограниченное потребление ресурсов» — четвёртое место. Голос, не измерение

2. Что разборы поправили в самой записи

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

Исправлено 2026-09-21 по развилке Ж7. Прежняя редакция называла вторым источником усиления «собственный шлюз, долбивший внутреннюю точку аутентификации», — в отчёте этого нет: там названа ошибка повторов у клиента, а «сокращение повторов шлюза» стоит среди мер тушения, а не среди причин. Заголовок наблюдения тоже смягчён: «чаще» — это частота, а её из этого источника брать запрещено оговоркой ниже. Ошибка отсюда успела переехать в карточку EDGE-06 и исправлена там же.

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

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

3. Карточное правило

EDGE-06 несёт пять алгоритмов с колонкой свойств, умолчание («скользящее окно со счётчиками — практический выбор»), уровни ограничения, контракт в заголовках, распределённый счётчик, плавную реакцию, границу применимости («не спасает от перегрузки легитимным трафиком — для этого REL-03») и даже заранее решённый отказ хранилища счётчиков. Для короткой формы это больше, чем документ решения обычно содержит.

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

1. В карточку — три уточнения: ключ важнее величины; усиливающий потребитель чаще внутренний; ограничитель, включаемый руками, — средство восстановления, а не защиты.
2. В REL-03 и D-06 — автоматический предохранитель по признакам перегрузки: что именно система делает сама и что обещано, пока она это делает.

---

Итог мини-исследований М1–М3

Счёт

Отложенных кандидатов было	3
Прошли критерий общности	3
Дали документ	1

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

Наблюдение о жанре — и оно проверяемое

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

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

Выжили	Что выбирают
D-02, D-05, D-07	Границу — что с чем разрезано
D-06, D-10, D-11	Обещание — что мы обязуемся дать
D-08, D-09	Необратимость — переход, который нельзя переиграть
D-01, D-03, D-04	Держатся на дисквалификаторах и рыночном слое, которых карточка не несёт

Проверяемая формулировка, кандидат в мастер-шаблон:

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

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

Побочный итог: правило, которое умеет не только резать

Карточное правило четырежды убило и дважды сузило предмет — D-09 (существование отката, а не стратегии выката) и D-11 (обещание совместимости, а не механика версий). Это стоит отметить, потому что правило, которое только запрещает, обычно подозрительно: здесь оно и запрещает, и формулирует.

---

Мини-исследование М4 · P-CHG-04 · данные ушли в чужую организацию

• Статус: пройдено · 2026-09-22
• Повод: единственная открытая запись реестра — и единственная, добавленная работой, а не опросом поля (U-01)
• Механизм: тот же, что у М1–М3
• Задача: найти подтверждение типа 2 (данные) или типа 3 (публичный разбор) — либо записать, что его нет
• Объём шага ограничен намеренно: мини-исследование отвечает на вопрос о критерии общности. Нужен ли под запись документ — отдельная развилка; М1–М3 показали, что это разные вопросы
• Итог коротко: критерий общности выполнен; поле «частота» закрыто не числом отказов, а числом обстоятельств — и это оказалось свойством предмета, а не пробелом поиска

1. Что нашлось

Работа	Выборка и метод	Что говорит
Rupp, Syrmoudis, Grossklags. Leave No Data Behind — Empirical Insights into Data Erasure from Online Services (PoPETs 2022, вып. 3, с. 437–455)	90 сервисов из верхних списков SimilarWeb; заведены живые учётные записи с вымышленной личностью, шесть недель использования, затем запрос на стирание — кнопкой или письмом по ст. 17 GDPR; спустя полгода — запрос доступа по ст. 15. Декабрь 2019 — ноябрь 2020	24 сервиса из 90 (27 %) стирание не довели. Письменный запрос исполнен в 82 % случаев, кнопка — в 69 %. Из 33 сервисов с публичными данными 9 (27 %) их не убрали и не обезличили; 12 сервисов (18 %) продолжали слать рассылку. На запрос доступа ответили 78 из 90, и в 14 ответах лежали персональные данные, которые полагалось стереть
Syrmoudis, Mager, Grossklags. A Longitudinal Analysis of Corporate Data Portability Practices Across Industries (ACSAC 2024)	129 сервисов по выгрузке и 137 по загрузке, три года подряд — 2020, 2021, 2022; проверка соответствия ст. 20 GDPR, состава выгрузки и наличия загрузки	Полностью соответствуют требованиям 31 %, 29 % и 33 % по годам; во все три года — 16 %. Загрузку не предлагают 70 %, полную — 8 %. Прямая передача между сервисами за три года так и не появилась, и отправитель не может установить, что именно получил приёмник
SEC. Morgan Stanley Smith Barney to Pay $35 Million for Extensive Failures to Safeguard Personal Information (пресс-релиз 2022-168, 20.09.2022)	Решение регулятора по пятилетнему эпизоду, начавшемуся в 2015 году	Вывод из эксплуатации тысяч дисков и серверов поручили транспортно-складской компании без опыта уничтожения данных. Та перепродала оборудование третьему лицу, и оно ушло на интернет-аукцион с неудалёнными данными 15 млн клиентов. Часть удалось выкупить обратно, но «подавляющее большинство устройств фирма не вернула». Отдельно: при выводе офисов пропали 42 сервера
Deloitte. 2024 Global Corporate Divestiture Survey (отчёт)	Опрос 500 руководителей уровня «старший директор и выше» в компаниях с выручкой свыше 500 млн долл.; десять стран, октябрь 2023	Более четырёх компаний из пяти провели три и более продажи направлений за 36 месяцев; около 80 % ждут трёх и более в ближайшие 12–18 месяцев; менее 2 % не планируют ничего продавать. Соглашения о переходных услугах использует более половины продавцов, и они же названы самой частой трудностью после сделки

Оговорка к четвёртой строке. Это опрос намерений руководителей, а не замер событий: он меряет, как часто возникает обстоятельство, и ничего не говорит о том, чем оно кончается. Взят он ровно за этим — см. раздел 3.

Оговорка к третьей строке. Тем же эпизодом занималось и Управление контролёра денежного обращения США: по заголовку его пресс-релиза OCC Assesses $60 Million Civil Money Penalty Against Morgan Stanley (2020) штраф составил 60 млн долл. [не проверено] — страница не открылась, прочитан только заголовок, и перечень нарушений, который в ней, по описаниям, приведён, здесь не используется.

2. Как это читается

Первое: ненаблюдаемость подтверждена прямым текстом, причём исследователями, у которых было больше рычагов, чем у нас. Авторы работы о стирании пишут, что само стирание ненаблюдаемо, и им пришлось выдумывать косвенную проверку — спустя полгода запросить у сервиса доступ к своим данным и посмотреть, не пришлют ли они то, что обещали стереть. Признак записи P-CHG-04 сформулирован как «есть ли хоть один способ проверить, кроме переписки»; здесь его проверили экспериментально, и ответ — нет, кроме переписки способа не нашлось.

Второе, и оно важнее первого: переписка сработала. Косвенная проверка дала 14 попаданий из 78 ответов — почти каждый пятый. То есть «спросим у них», объявленное в записи недостаточным, не бесполезно: оно не даёт уверенности в исполнении, но ловит неисполнение. Это уточняет формулировку записи: переписка — не проверка состояния, а выборочный контроль, и относиться к ней надо как к выборочному контролю: планировать частоту, а не ждать повода.

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

Четвёртое: разбор Morgan Stanley — это наш случай целиком, а не аналогия. Организация передала носители другой организации; проверять не стала; узнала со стороны — оборудование всплыло на аукционе. Ключевые слова регулятора — «подавляющее большинство устройств фирма не вернула»: не «данные утекли», а состояние данных на той стороне неизвестно и остаётся неизвестным. Пять лет, 15 млн клиентов, и отдельной строкой — 42 пропавших сервера, о которых просто ничего не известно.

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

3. Поправка к правилу допуска — седьмая

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

Чем популяции различаются	Куда смещает вывод
В работах просит физлицо: ни договора, ни денег, ни рычага	Завышает безысходность. У организации рычаг есть — приложение к договору, срок, сверка. Но он договорный, и это ровно то, что запись и утверждала
Приёмник в работах — действующий сервис под тем же регулятором, заинтересованный остаться в законе	Занижает остроту. У нас приёмник после передачи не обязан нам ничем сверх подписанного, и общего регулятора может не быть вовсе
Меряется стирание по запросу, а у нас — состояние данных после передачи целого направления	Меняет предмет, а не направление вывода. Общее — что проверить нечем; различается, что именно проверяется
Эпизод Morgan Stanley — организация организации, и это наш случай точно	Ничего не смещает и ничего не обобщает: один разбор — подтверждение типа 3, а не выборка

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

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

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

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

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

4. Вердикт

Критерий общности выполнен, и всеми тремя типами сразу.

Тип подтверждения	Что есть
1 · канон	Юридический: ст. 17 и ст. 28 GDPR, приложения к договору, право на аудит, ISO/IEC 27001:2022 — мера 8.10 «Удаление информации» [не проверено по тексту стандарта: номер и название взяты из вторичного описания]. Инженерного канона нет
2 · данные	Две рецензированные работы с названными выборками и методиками: 90 сервисов и 129/137 сервисов за три года
3 · публичный разбор	Решение регулятора по пятилетнему эпизоду ровно нашего устройства — сильнее обычного постмортема, потому что сторона там не сама о себе рассказывает

P-CHG-04 проходит критерий и встаёт в очередь. Решение о том, будет ли документ, — отдельная развилка, и связывать его с этим вердиктом нельзя: М1–М3 прошли критерий все трое, а документ дали один.

5. Чего мини-исследование не дало

• Ни одной цифры о том, чем кончаются передачи между организациями. Всё измеренное — либо потребительские сервисы, либо один эпизод. Это не пробел поиска: по правилу выше, измерять это некому.
• Ни одного технического способа установить состояние данных на чужой стороне. Схемы проверяемого удаления в литературе есть, практики их применения в найденном — нет.
• Ничего о цене. Сколько стоит приложение к договору с составом передаваемого, сколько — сверка контрольных сумм на стороне приёмника, сколько — право на аудит и его осуществление: не измерено нигде.
• Ничего о смене подрядчика и о партнёре, берущем обслуживание на себя. Из четырёх проявлений записи числом закрыто одно — продажа направления. Про остальные три нет даже частоты обстоятельства.
• Ближайшее, что нашлось и в дело не пошло: Verizon DBIR 2025 сообщает, что доля утечек с участием третьей стороны удвоилась до 30 % (22 тыс. инцидентов, 12 195 подтверждённых утечек). Это про третью сторону как канал утечки, а не про состояние данных после передачи. В таблицу не взято сознательно: цифра звучная и не о том.

6. Что известно о предмете — до решения о документе

Собрано здесь, чтобы будущая развилка начиналась не с нуля. Выводов о том, нужен ли документ, этот раздел не делает.

Вопрос, который задаст развилка	Что уже известно
Не делает ли работу существующая карточка?	Проверено не было. Ближайшие кандидаты — DATA-16 (целостность и сверка) и блок SEC; ни один не про чужую сторону
Что бы выбиралось, если документ появится?	По находкам — охват обещания и его срок: что мы обязуемся передать, что можем обещать после передачи и до какого дня держим свои копии. Это тот же предмет, что у D-11, только адресат — не потребитель интерфейса, а тот, чьи данные уехали
Чем бы отличался от D-08 и D-09?	Те двое кончаются на переходе. Здесь предмет начинается там, где они кончились, и живёт после
Предсказание о жанре	Стоит с 2026-09-18 и не разрешается здесь: оно разрешается на решении о документе. Записано «решение, не меню»; находки этому пока не противоречат — выбирать приходится охват обещания, а не приём из списка

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