И0′ · Пилот: декомпозиция данных#

Статус: пилот закончен · 2026-09-17 · результат — D-07 · Декомпозиция данных, правки в D-02 v5.0 и D-05 v3.0, одна правка метода
Метод: 00-plan.md в редакции после пилота И0 — блоками, с полем «жанр», по смягчённому критерию общности
Зачем этот пилот второй: профиль источников противоположен первому, и он же стресс-тест правила о критическом отношении к канону

Порядок соблюдён строже, чем в И0. Глава 6 Форда и Ричардса — готовый костяк из шести сил дезинтеграции и двух интеграции — принесена последней, уже после того, как реестр собран по другим источникам. Что она изменила, написано отдельным разделом; пока достаточно сказать, что порядок был выбран не зря.

Реестр#

P-DDEC-01 · Запись в два места расходится, и об этом никто не узнаёт#

Как проявляется. Поиск не находит того, что есть в базе. Счётчик не совпадает с содержимым. Ошибок при этом нет ни одной.
Признак. Есть операция, записывающая в два хранилища без общей транзакции, — и нет сверки. Два независимых механизма расхождения: гонка (записи приходят в разном порядке и «останутся несогласованными навсегда, пока кто-нибудь позже не перезапишет значение снова») и частичный отказ (первая запись прошла, вторая нет). Kleppmann.
Требует решения? Да.
Цена изменения × влияние. Дорого × высокое → полная форма. Уйти от двойной записи — сменить способ распространения данных, а не поправить вызов.
Частота. Не измерена. Но природа проблемы объясняет, почему данных и нет: расхождение не порождает ошибок. Kleppmann: «вы, вероятно, даже не заметите… поймёте месяцев через шесть». Проблема, которую не видно, не попадает и в отчёты об инцидентах.
Известные решения. Журнал как единственный источник порядка, из которого читают все потребители; отправка через таблицу исходящих в той же транзакции; захват изменений из журнала БД.
Жанр. Решение. Механика уже есть карточкой MSG-07.
Зрелость. Устоявшаяся.

P-DDEC-02 · Сервисы разделили, базу оставили общую#

Как проявляется. Изменение схемы требует согласования с тремя командами. Долгая транзакция одного сервиса блокирует другой.
Признак. Сколько сервисов пишет в одну таблицу и сколько читает её напрямую. Три связности, названные явно: разработки («разработчику придётся согласовывать изменения схемы с разработчиками других сервисов… это замедлит разработку»), времени выполнения («если длинная транзакция держит блокировку, другой сервис будет заблокирован») и негибкость хранения — одна база не удовлетворяет требованиям всех (Richardson, Shared database).
Требует решения? Да.
Цена изменения × влияние. Дорого × высокое → полная форма.
Частота. Не измерена.
Известные решения. База на сервис; при невозможности — явное владение таблицами с единственным писателем и чтением через интерфейс.
Жанр. Решение. Частично уже закрыто силами интеграции в D-02 v4.0.
Зрелость. Устоявшаяся.

P-DDEC-03 · Запрос, которому нужны данные из двух мест, перестал выражаться#

Как проявляется. Экран или отчёт требует соединения через границу владения. Появляется перебор по сети: один запрос превращается в сотню.
Признак. Есть ли в основном сценарии запрос, соединяющий данные разных владельцев. «Реализация запросов, соединяющих данные, которые теперь лежат в нескольких базах, — задача непростая» (Richardson, Database per service).
Требует решения? Да.
Цена изменения × влияние. Дорого × высокое → полная форма.
Частота. Не измерена.
Известные решения. Соединение в приложении; материализованное представление, собираемое по событиям; денормализация с принятой ценой сверки.
Жанр. Решение.
Зрелость. Устоявшаяся.

P-DDEC-04 · Общее хранилище делает отказ общим#

Как проявляется. Отказ одной базы останавливает всё, что на неё опирается. Переключение расходит копии, и обратное переключение становится невозможным.
Признак. Сколько независимо развёртываемых частей перестанет работать при отказе одного хранилища. И отдельно: может ли переключение произойти без подтверждения, что вторая сторона догнала.
Требует решения? Да.
Цена изменения × влияние. Дорого × высокое → полная форма.
Частота. Единственная запись реестра с измеренным случаем. Сетевое разделение длиной 43 секунды привело к деградации в 24 часа 11 минут. Обратное переключение оказалось невозможным: «базы в обоих центрах теперь содержали записи, отсутствующие в другом», причём западная сторона успела принять около получаса записей. Восстановление упёрлось в то, что резервные копии лежали в облачном хранилище, и «время, нужное на восстановление нескольких терабайт, растянуло процесс на часы» (GitHub, разбор инцидента 21 октября 2018).
Известные решения. Переключение только при подтверждённом догоне; выбор «потерять записи или ждать» сделанный до инцидента, а не в нём; резервная копия рядом с местом восстановления.
Жанр. Решение плюс карточка REL-08.
Зрелость. Устоявшаяся.

P-DDEC-05 · Удалить данные человека, когда они лежат в семи местах#

Как проявляется. Пришёл запрос на удаление. Данные в основной базе, в поисковом индексе, в журнале событий, в аналитическом хранилище, в резервных копиях и в кэше. Удалили в первом.
Признак. Существует ли список мест, где оседают персональные данные, и кто его ведёт. Отдельно: есть ли среди них неизменяемые по построению — журнал событий, копии.
Требует решения? Да.
Цена изменения × влияние. Дорого × высокое → полная форма. Необратимость здесь юридическая, а не техническая.
Частота. Не измерена. Требование названо законом, а не практикой: право на стирание — GDPR, ст. 17.
Известные решения. Реестр мест хранения как часть решения о декомпозиции; шифрование персональной части с уничтожением ключа там, где стереть нельзя; срок жизни вместо удаления.
Жанр. Решение — частный случай P-DDEC-01, а не отдельная тема: удаление есть изменение, которое обязано дойти до всех копий. Особенного в нём только то, что невыполнение замечает юрист, а не пользователь.
Зрелость. Спорная. Техники существуют, общепринятой формы решения нет, и источники здесь заметно слабее остальных.

Поправка после сверки (см. ниже). Сначала я записал, что в нашем наборе этого нет ни документа, ни карточки. Это неверно: DATA-19 · Retention, удаление данных, приватность покрывает механику целиком — карту распространения данных, мягкое и жёсткое удаление, крипто-шреддинг для архивов, обезличивание. Нет только решения.

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

P-DDEC-06 · Аналитика тянет разделённые данные обратно вместе#

Как проявляется. Операционные данные разделили, а отчётность требует их в одном месте. Появляется ночная выгрузка, которая знает схемы всех сервисов и ломается от любого их изменения.
Признак. Есть ли потребитель, читающий хранилища нескольких владельцев напрямую. Если есть — разделения фактически нет: схема осталась публичным интерфейсом, только неявным.
Требует решения? Да.
Цена изменения × влияние. Дорого × высокое → полная форма.
Частота. Не измерена.
Известные решения. Витрина, собираемая из событий, а не выгрузка по таблицам; договор о выгрузке как явный интерфейс со своей совместимостью.
Жанр. Решение.
Зрелость. Устоявшаяся.

P-DDEC-07 · База не выдерживает соединений от всех потребителей сразу#

Как проявляется. Каждый экземпляр каждого сервиса держит свой пул. Число сервисов растёт, число соединений умножается, база упирается в них раньше, чем в нагрузку.
Признак. Число соединений к хранилищу против его предела — и от скольких независимых потребителей они приходят.
Требует решения? Да, но чаще это ограничение, а не развилка.
Цена изменения × влияние. Дёшево × высокое → короткая форма.
Частота. Не измерена.
Известные решения. Внешний пул соединений; сокращение числа прямых потребителей; предел на сервис.
Жанр. И то и другое: ограничение учитывается при декомпозиции, механика — карточка, которой у нас нет.
Источник. ⚠️ Пришла только из главы 6 Форда и Ричардса — единственная запись, которой не было в реестре до неё. Подтверждения из второго типа источников нет.
Зрелость. Устоявшаяся.

Что не попало в реестр и почему#

Поле «жанр», добавленное по итогам И0, отработало сразу: оно отсеяло два кандидата до сборки документа, а не во время неё.

Кандидат	Почему не сюда
Схема данных — контракт, но версионируется как код	Жанр — решение, но другого документа: это контракт данных, а не декомпозиция. Вопрос «совместимость вперёд или назад, реестр схем, версия в сообщении» существует и без всякого разделения хранилищ
Миграция данных между хранилищами без остановки	Жанр — решение третьей стадии, «система под изменением». Пласт, которого в наборе нет вовсе; включать его в `D-07` значит спрятать целое направление внутрь чужого документа
«Выбрать подходящий тип хранилища под задачу»	Это D-01. У Форда и Ричардса это сила дезинтеграции («оптимизация типа базы»), у нас — отдельное решение с рыночным слоем

Что изменила глава 6, принесённая последней#

Ради этого пилот и ставился вторым. Результат:

Сила дезинтеграции у Форда и Ричардса	Что было в реестре до главы
Управление изменениями	P-DDEC-02 — уже был
Отказоустойчивость	P-DDEC-04 — уже был, и с измеренным случаем
Масштабируемость	Частично P-DDEC-02, частично D-01
Архитектурные кванты	Уже внесено в D-02 v4.0 находкой 20
Оптимизация типа базы	Это D-01
Управление соединениями	Не было. Единственная новая запись — P-DDEC-07
Сила интеграции: отношения в данных	P-DDEC-03 — уже был
Сила интеграции: транзакции	Дисквалификатор, уже в D-02 v4.0

Шесть сил из восьми глава подтвердила, одну добавила, одна оказалась чужим документом. Если бы я начал с неё, реестр состоял бы из восьми её пунктов и я бы решил, что тема покрыта. P-DDEC-01, P-DDEC-05 и P-DDEC-06 в ней отсутствуют, а P-DDEC-01 — про расхождение, которого не видно, — вероятно, самая коварная запись реестра.

Правило сработало ровно так, как задумано, и это его первая настоящая проверка. Канон дал формулировки и одну новую тему. Костяк он не продиктовал.

Сверка с нашим корпусом#

Проблема	Чем закрыта у нас	Достаточно ли
P-DDEC-01 Двойная запись расходится незаметно	MSG-07 outbox и CDC, DATA-16 целостность данных	Механика — да. Решения нет
P-DDEC-02 Общая база при разделённых сервисах	ARCH-01 монолит и микросервисы, силы интеграции в D-02 v4.0	Частично: `D-02` спрашивает про отношения в данных, но решает границы сервисов, а не границы данных
P-DDEC-03 Запрос через границу владения	ARCH-02 границы вскользь	Нет. Ни карточки, ни решения
P-DDEC-04 Общее хранилище — общий отказ	REL-08 multi-region и failover, REL-07 ячейки	Механика — да. Решения нет
P-DDEC-05 Удаление данных человека из семи мест	DATA-19 retention, удаление, приватность — карта распространения, крипто-шреддинг, мягкое и жёсткое удаление	Механика — да, и подробно. Решения нет
P-DDEC-06 Аналитика собирает разделённое обратно	DATA-15 OLTP и OLAP	Механика — да. Решения нет
P-DDEC-07 Соединения от всех потребителей	PERF-06 · Пулы соединений, N+1 и батчинг — механика пулов	Поправка И3: сначала записал «ничем» — снова поиском по терминам. Не покрыт только множитель от числа сервисов, а не тема целиком

Картина та же, что в И0, и это уже не совпадение: механика покрыта, решений нет. Дыр в карточках две: предел по соединениям (P-DDEC-07) и классификация данных по режиму защиты — механизмы защиты описаны двенадцатью карточками блока SEC, а вопрос «какой класс данных что обязывает» не описан ни одной.

Ошибка сверки и её причина — отдельно, потому что она про метод#

Я записал, что удаление персональных данных не покрыто ничем. Это было неверно: DATA-19 покрывает механику полнее, чем реестр её описал.

Причина не в невнимательности, а в способе сверки. В И0 я читал список карточек блока 08-reliability целиком и сравнивал с реестром. Здесь пошёл быстрее: искал по терминам, которыми сам же назвал проблемы. Поиск находит то, что уже названо моими словами, — и молчит о том, что названо чужими. Карточка называется «Retention, удаление данных, приватность», запись реестра — «удалить данные человека, когда они лежат в семи местах»; общих слов между ними почти нет.

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

Отчёт о методе — второй результат пилота#

Что проверялось	Итог
Поле «жанр» (правка И0)	✅ окупилось сразу. Отсеяло двух кандидатов на входе, а не при сборке документа, как было с P-DDEC-07 в первом пилоте
Смягчённый критерий общности (правка И0)	✅ работает. По строгой редакции прошла бы одна запись из семи; по действующей — шесть, и одна помечена как пришедшая из единственного источника
Реестр блоками, а не таблицей (правка И0)	✅ без замечаний
Правило о критическом отношении к канону	✅ первая настоящая проверка, и оно решило исход. См. раздел о главе 6
Поле «частота»	⚠️ по-прежнему почти пустое: одна запись из семи. И здесь видна причина, а не лень: P-DDEC-01 не измерена потому, что не порождает ошибок. Отсутствие данных — иногда свойство проблемы, а не источников
Ожидаемый объём 6–10 проблем	✅ семь, из них одна из единственного источника, две отведены по жанру
Противоположность профилей источников	✅ подтвердилась. В И0 данные дала работа с выборкой инцидентов, здесь — один публичный разбор с числами и один закон. Ни одного отчёта с методикой

Что предлагаю поправить в методе#

Одну правку — и её потребовала моя же ошибка.

Сверка с корпусом идёт по списку карточек блока, а не поиском по терминам. Поиск находит то, что уже названо моими словами; список показывает, что есть на самом деле. В И0 я читал список и ошибки не сделал; здесь пошёл поиском и объявил дырой то, что покрыто карточкой DATA-19 полнее, чем описано в реестре.

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

Решение по P-DDEC-05, принятое при разборе. Удаление персональных данных — частный случай согласованности данных (P-DDEC-01): изменение обязано дойти до всех копий, и удаление — такое же изменение. Поэтому в D-07 оно входит не отдельной темой, а случаем. Но требования к защищаемым данным этим не исчерпываются: класс данных влияет на границы, и должен участвовать в решении о них. Отсюда правки в D-02 и D-05, а не только в D-07.

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

Чем кончился пилот#

Документ написан: D-07 v1.0.

Запись реестра	Куда вошла
P-DDEC-01 · двойная запись расходится незаметно	Первый дисквалификатор и третья сила интеграции «число копий»
P-DDEC-05 · удаление данных человека	Частный случай P-DDEC-01: реестр копий и путь изменения по нему. Отдельной темой не стала
P-DDEC-02 · общая база при разделённых сервисах	Сила «управление изменениями» и форма «разделить владение внутри одной базы»
P-DDEC-03 · запрос через границу владения	Сила интеграции «отношения в данных» с ценами оплаты
P-DDEC-04 · общее хранилище — общий отказ	Сила «отказоустойчивость» и пятый дисквалификатор
P-DDEC-06 · аналитика собирает разделённое обратно	Форма «копия только для чтения из журнала» и вопрос о реестре копий
P-DDEC-07 · предел по соединениям	Сила «управление соединениями» — единственная, пришедшая из главы 6

Плюс то, чего в реестре не было и что пришло из разбора: класс защищаемых данных вошёл шестой силой разделения в D-07 и, что важнее, в решения о границах — D-02 v5.0 и D-05 v3.0 получили вопрос, дисквалификатор и форму разреза.

D-07 — первый документ, построенный на двусторонней форме целиком, и место для неё выбрано верно: вопрос здесь ровно «делить или держать вместе», и однонаправленного ответа у него не бывает. Третья сила интеграции — число копий, которые придётся синхронизировать — в источниках отсутствует: у Форда и Ричардса силы интеграции про связи между данными, а эта про связи между копиями. Разделение не только разрывает соединения, но и размножает истину, и второе дороже, потому что невидимо.

Что пилот дал сверх документа

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