Во вторник данные на панели аналитики были верны. К четвергу же она показала падение привлечения клиентов на 23%, что команда аналитиков восприняла как реальный сигнал для бизнеса, реорганизовала маркетинговые бюджеты, приостановила кампании и сообщила об этом руководству. В пятницу команда инженеров данных обнаружила, что в исходный сервис был добавлен столбец, допускающий значение NULL. registrations Таблица была обновлена шесть дней назад. Конвейер ETL не был обновлен. Расчет, определяющий метрику приобретения, рассматривал новые нулевые значения как нули, а не исключал их. Уведомление об изменении схемы не было отправлено. Ни один контракт не был нарушен таким образом, чтобы это привело к ошибке. Конвейер выполнился успешно; он выдал неверные числа, которые выглядели правильными.
Смещение схемы представляет собой структурную мутацию, в отличие от проблем качества данных, когда значения некорректны, смещение схемы нарушает договор между источником и получателем. В монолитной среде баз данных с центральным администратором баз данных, контролирующим все DDL, этот договор обеспечивается одним единственным органом. В распределенной системе, где десятки независимых сервисов владеют собственным хранилищем данных, где потоки событий несут схемы Avro, которые развиваются независимо, где интерфейсы плоских файлов между пакетными заданиями мэйнфрейма и облачными аналитическими платформами определяют неявные договоры, которых нет в документации ни одной из систем, договор распределен по всем границам системы. Смещение схемы в распределенной среде не ждет, пока администратор баз данных совершит ошибку. Оно возникает в процессе нормальной работы автономных команд, принимающих индивидуально обоснованные решения без полной видимости каждого конечного потребителя своих данных.
Составьте карту границ устаревшей схемы.
SMART TS XL Определяет каждый контракт в формате плоского файла, связывающий программы мэйнфреймов с современными аналитическими платформами.
УЗНАТЬ БОЛЬШЕ…Что такое «смещение схемы» и чем оно не является.
Смещение схемы — это изменение структуры информационного артефакта, которое не отражается на потребителях этого артефакта. Именно акцент на потребителях отличает смещение схемы от плановой миграции: переименование столбца, выполняемое одновременно в исходной таблице и каждом запросе-потребителе, — это миграция схемы. Аналогичное переименование, выполняемое только в исходной таблице, в результате чего потребители получают устаревшие имена столбцов, — это смещение схемы.
Конвейеры обработки данных основаны на договоре доверия между исходной системой и целевым хранилищем данных. Этот договор — схема: согласованная структура, типы данных и имена столбцов, определяющие набор данных. Когда команды, работающие с исходной системой, изменяют свою базу данных без уведомления команды, занимающейся обработкой данных, они нарушают этот договор.
Смещение схемы — это не то же самое, что смещение данных. Смещение данных — это изменение статистического распределения значений в рамках стабильной схемы: снижение средних значений порядка, увеличение доли нулевых значений, смещение категориальных распределений. Оба явления являются важными сигналами качества данных, но требуют разных подходов к обнаружению и указывают на разные первопричины. Система обнаружения изменений схемы, которая отслеживает имена и типы столбцов, не обнаружит смещение данных; система мониторинга распределения не обнаружит добавление и удаление столбцов.
Изменение схемы не всегда опасно. Отслеживание степени изменения схемы во времени помогает различать активные циклы разработки (безопасное изменение) и нестабильность (критическое изменение). Обратно совместимое добавление столбца, допускающего значение NULL, в таблицу является изменением схемы, но это может не привести к сбоям в работе любого потребителя, игнорирующего новый столбец. Классификация изменения как безопасного или критического требует понимания того, как потребители обрабатывают эти изменения.
Четыре типа дрейфа схемы
Распределенные системы обработки данных приводят к изменению схемы по четырем различным параметрам, для каждого из которых требуются разные механизмы обнаружения:
Тип 1: Структурный дрейф
Изменения в определении физической схемы: добавление столбцов, удаление столбцов, переименование столбцов, изменение типов данных, добавление или удаление ограничений, добавление и удаление таблиц. Это наиболее наглядная форма отклонения схемы, и именно её чаще всего выявляют с помощью инструментов мониторинга. Запросы INFORMATION_SCHEMA к базе данных, сравнение с реестром схем и журналы аудита инструментов миграции эффективно фиксируют структурное отклонение для подключенных систем.
Обнаружение: сравнение снимка схемы с базовым вариантом; опрос INFORMATION_SCHEMA; сравнение версий реестра схем.
Тип 2: Семантический дрейф
Изменение значения существующего поля без изменения его определения. Столбец с именем
statusкоторые ранее содержали значенияACTIVE,INACTIVE,PENDINGтеперь содержит значения1,2,3Потому что сервис-производитель изменил свою нумерацию. Схема, имя столбца, тип данных, ограничение на возможность значения NULL остались неизменными. Семантический контракт нарушен. Потребители, которые обрабатывали строковые значения статуса, теперь получают целые числа, которые их логика не обрабатывает.Семантический дрейф и контекстный дрейф — относительно новые явления, которые крайне редко отслеживаются, хотя оба являются причиной растущей доли сбоев в программах ИИ. Семантический дрейф сложнее всего обнаружить автоматически, поскольку он не дает структурного сигнала; для его отслеживания требуется либо мониторинг распределения значений (изменение соотношения известных и неизвестных значений), либо явное тестирование контрактов.
Обнаружение: Мониторинг распределения значений; правила проверки допустимых значений; тесты контрактов, проверяющие конкретные допустимые значения.
Тип 3: Изменение формата
Изменения коснулись кодировки или формата значений в полях, структура которых осталась неизменной. Поле временной метки, ранее содержавшее строки UTC ISO 8601, теперь содержит целочисленные значения Unix epoch. Поле валюты, ранее содержавшее десятичные значения, теперь содержит значения в центах в виде целых чисел. Столбец существует, тип данных по-прежнему действителен для новых значений, но изменился способ синтаксического анализа.
Изменение формата особенно часто встречается на границах распределенных систем, где один сервис сериализует данные в формате, который другой десериализует, а также на границе между устаревшими и современными системами, где программы на COBOL записывают плоские файлы со специфическими соглашениями о расположении байтов, от которых зависят последующие процессы ETL.
Обнаружение: Статистическое профилирование диапазонов значений и закономерностей; правила проверки формата для конкретных полей; проверка соответствия граничным условиям.
Тип 4: Отклонение контракта
Изменения в гарантиях доступности, актуальности или объема данных в источнике. Ранее исходная система предоставляла набор данных ежедневно к 3:00 UTC; теперь она предоставляет его к 6:00, незаметно нарушая последующие процессы, которые предполагали актуальность данных к 3:00. Ранее исходная система гарантировала минимум 1,000 записей в день; в периоды низкой нагрузки теперь их количество уменьшается. Ни одно из этих изменений не является структурным изменением схемы, но оба нарушают договор между производителем и потребителем.
Обнаружение: мониторинг свежести; выявление аномалий объема; оповещения на основе SLA.
Почему распределенные системы усугубляют проблему
В монолитной системе с одной базой данных и одной командой разработчиков приложений изменения схемы являются контролируемыми событиями. Администратор базы данных пишет миграцию, разработчик обновляет запросы, и изменения развертываются одновременно. Риск смещения схемы существует, но ограничен рамками полномочий единственного ответственного лица.
Распределенные системы устраняют этот единый орган власти. Каждая служба владеет своими данными. Каждая команда принимает решения по схемам независимо. Потребители данных каждой службы часто находятся вне непосредственного поля зрения этой команды, особенно когда потребителем является платформа данных, аналитический конвейер или устаревшая точка интеграции, которую ни одна команда разработчиков продукта активно не поддерживает.
Distributed Schema Drift Propagation Path:
Order Service Kafka Topic Analytics Pipeline
┌─────────────────┐ ┌───────────────┐ ┌──────────────────────┐
│ orders table │──>│ order.created │───>│ orders_fact table │
│ + coupon_id │ │ Avro schema │ │ (missing coupon_id) │
│ (new column) │ │ v1 still used │ │ pipeline runs fine │
│ │ │ │ │ coupon data silently │
│ │ │ │ │ dropped │
└─────────────────┘ └───────────────┘ └──────────────────────┘
▼
BI Dashboard
┌──────────────────┐
│ coupon_revenue │
│ always = $0 │
│ (no error shown) │
└──────────────────┘Диаграмма иллюстрирует схему распространения: команда службы обработки заказов добавляет coupon_id в свою базу данных. Если они также обновят схему событий Kafka, чтобы включить coupon_idДля обработки этих данных необходимо обновить конвейер аналитики. Если схема Kafka по-прежнему находится в версии 1, поле никогда не попадает в конвейер. Если конвейер обновлен, но модель панели мониторинга BI не обновлена, поле существует в хранилище данных, но отсутствует в отчете. Это отклонение может привести к скрытой потере данных на любом из четырех уровней, и для каждого уровня требуется свой механизм обнаружения.
Скрытые сбои в конвейерах обработки данных, устаревшие панели мониторинга, расхождение схем и неполные наборы данных стали основными операционными рисками в современных корпоративных средах обработки данных. Современные стеки данных выходят из строя быстрее, чем традиционные среды, при этом нарушенные преобразования, сбои в актуальности и скрытое повреждение данных распространяются по конвейерам обработки данных задолго до того, как команды обнаружат проблемы вручную.
Свойство «скрытой» корректности — вот что делает расхождение в распределенной схеме дорогостоящим. Ошибка, приводящая к исключению, обнаруживается и исправляется. Изменение, приводящее к скрытым неверным значениям, остается незамеченным до тех пор, пока бизнес-решение, основанное на этих значениях, не приведет к видимым последствиям.
Подходы к обнаружению по слоям
Для обнаружения изменений в схеме распределенной системы требуются разные инструменты и методы для каждого уровня:
Уровень базы данных и хранилища
Наиболее развитый уровень обнаружения. Таблицы INFORMATION_SCHEMA во всех основных базах данных и хранилищах предоставляют снимок метаданных, доступный для запросов:
SQL
-- Detect structural schema changes since a baseline snapshot
-- Run daily; alert when new differences appear
WITH current_schema AS (
SELECT
table_name,
column_name,
data_type,
is_nullable,
column_default,
ordinal_position
FROM information_schema.columns
WHERE table_schema = 'production'
),
baseline AS (
-- Previous snapshot stored in schema_baseline table
SELECT * FROM schema_monitoring.schema_baseline
WHERE snapshot_date = CURRENT_DATE - 1
)
SELECT
'ADDED' AS change_type,
c.table_name,
c.column_name,
c.data_type,
CURRENT_DATE AS detected_date
FROM current_schema c
LEFT JOIN baseline b
ON c.table_name = b.table_name
AND c.column_name = b.column_name
WHERE b.column_name IS NULL
UNION ALL
SELECT
'REMOVED' AS change_type,
b.table_name,
b.column_name,
b.data_type,
CURRENT_DATE
FROM baseline b
LEFT JOIN current_schema c
ON b.table_name = c.table_name
AND b.column_name = c.column_name
WHERE c.column_name IS NULL
UNION ALL
SELECT
'TYPE_CHANGED' AS change_type,
c.table_name,
c.column_name,
c.data_type || ' (was: ' || b.data_type || ')' AS data_type,
CURRENT_DATE
FROM current_schema c
JOIN baseline b
ON c.table_name = b.table_name
AND c.column_name = b.column_name
WHERE c.data_type <> b.data_type;Инструменты, автоматизирующие этот процесс: тесты схемы dbt, прогнозирование столбцов Great Expectations, мониторинг состояния таблиц методом Монте-Карло, мониторинг смещения схемы Acceldata.
Уровень потоковой передачи событий
Темы Kafka используют реестры схем (Confluent Schema Registry, AWS Glue Schema Registry, Apicurio) для управления развитием схем Avro, Protobuf и JSON. Реестр обеспечивает соблюдение правил совместимости во время публикации:
YAML
# Confluent Schema Registry: compatibility rule configuration
# Applied per topic; enforces at producer registration time
compatibility:
BACKWARD:
# New schema can read data written with old schema
# Safe: consumers can be updated after producers
allows: add_optional_fields, remove_fields_with_defaults
blocks: rename_fields, change_types, add_required_fields
FORWARD:
# Old schema can read data written with new schema
# Safe: consumers can be deployed before producers
allows: add_required_fields, rename_with_aliases
blocks: remove_fields_used_by_consumers
FULL:
# Both backward and forward compatible
# Strictest: ensures zero-downtime evolution
allows: add_optional_fields_with_defaults
blocks: everything_elseРеестр схем не предотвращает семантический сдвиг: поле, имя и тип которого остались неизменными, но значение изменилось, проходит проверку совместимости. Для семантической валидации требуется тестирование контрактов (Pact, тестирование AsyncAPI).
API-уровень
Существует четыре принципиально разных подхода к выявлению расхождений в схеме API: сравнение спецификаций, мониторинг соответствия спецификаций и реальности, мониторинг соответствия реальности и обнаружение на основе трафика. Большая часть путаницы в этой области возникает из-за сравнения инструментов, использующих разные подходы.
Для внутренних API сервисов в микросервисной архитектуре наиболее надежным подходом является тестирование контрактов, управляемое потребителем (Pact): каждый потребитель указывает контракт, который ему требуется от производителя, контракты проверяются на соответствие реализации производителя в CI, и любое изменение, нарушающее контракт потребителя, приводит к провалу набора тестов производителя перед развертыванием.
Граница устаревшей системы: где дрейф становится невидимым
Все описанные выше методы обнаружения работают для систем, которые предоставляют метаданные схемы через интерфейсы, допускающие запросы: INFORMATION_SCHEMA, реестры схем, спецификации OpenAPI. На границе между устаревшими мэйнфреймными системами и современными платформами данных таких интерфейсов не существует.
Программа на COBOL, которая ежедневно создает плоский файл для использования облачным ETL-конвейером, определяет неявную схему в своей логике ввода и вывода FD. «Схема» плоского файла, позиции байтов, типы данных, упакованные десятичные поля COMP-3 и структуры REDEFINES, существует в исходном коде COBOL, а не в каком-либо реестре или хранилище метаданных, к которым могут обращаться современные инструменты мониторинга.
кобол
*> This FD entry IS the schema contract for the nightly extract
*> Any change here constitutes schema drift for the downstream ETL
FD CUSTOMER-EXTRACT-FILE
LABEL RECORDS ARE STANDARD
RECORD CONTAINS 350 CHARACTERS.
01 CUSTOMER-EXTRACT-REC.
05 CUST-ID PIC 9(10). *> Bytes 1-10
05 CUST-NAME PIC X(40). *> Bytes 11-50
05 CUST-BALANCE PIC S9(11)V99 COMP-3. *> Bytes 51-57 (packed)
05 CUST-STATUS-CD PIC X(2). *> Bytes 58-59
05 CUST-OPEN-DATE PIC 9(8). *> Bytes 60-67: YYYYMMDD
05 FILLER PIC X(283). *> Bytes 68-350
Если команда разработчиков COBOL изменится CUST-BALANCE от PIC S9(11)V99 COMP-3 в PIC S9(13)V99 COMP-3Добавление двух знаков после запятой для обработки больших значений баланса приводит к расширению поля с 7 байт до 8 байт в упакованном десятичном формате. Каждое поле после байта 50 сдвигается на одну позицию. Теперь в плоском файле, который считывает конвейер ETL, все поля после CUST-BALANCE находятся в неправильных байтовых позициях. Конвейер ETL не выдает ошибку; он считывает байты 51-57 как CUST-BALANCE и интерпретирует следующий байт (который теперь является первым байтом расширенного представления CUST-BALANCE) как часть CUST-STATUS-CD. Конвейер работает. Числа неверны. Предупреждение о расхождении схемы не срабатывает.
Это наиболее опасный тип дрейфа схемы в корпоративных средах: структурные изменения в устаревших системах, которые незаметно распространяются через интерфейсы плоских файлов без каких-либо механизмов обнаружения на обоих концах.
Три свойства делают отклонение от установленных границ особенно опасным:
Схема невидима для инструментов мониторинга. Метод Монте-Карло не может подключиться к файлу VSAM. Acceldata не может запросить запись FD. Единственный способ обнаружить изменение — сравнить исходный код COBOL с предыдущей версией, это операция анализа кода, а не операция мониторинга данных.
Распространение происходит незаметно. Интерфейсы плоских файлов не проверяют структуру записей; они считывают байты. Изменение структуры байтов приводит к некорректным значениям, а не к ошибкам.
Радиус поражения велик. COBOL-копибук, используемый 300 программами, представляет собой схему, разделяемую этими 300 программами. Изменение копибука, эквивалентное команде DDL ALTER TABLE, затрагивает все 300 программ одновременно, и каждый последующий потребитель любого набора данных, созданного любой из этих 300 программ, наследует это изменение.
Контракты схем: формализация того, что обычно подразумевается.
Структурное решение проблемы смещения схемы заключается в том, чтобы сделать неявные контракты явными, определяя, что представляет собой схема, кто от нее зависит и какие изменения разрешены, до внесения изменений, а не после того, как они что-то нарушат.
| Уровень контракта | Что оно регулирует | Инструменты | Устаревший эквивалент |
|---|---|---|---|
| DDL базы данных | Структура таблицы, типы столбцов, ограничения | Ликибаза, Флайвей, Атлас | Скрипты миграции DDL для DB2 |
| Схема событий | Структура Kafka/потока событий | Реестр согласованных схем, Апикурио | Недоступно (плоский файл не содержит реестра) |
| контракт API | Ожидания от интерфейса REST/gRPC | OpenAPI, Pact, AsyncAPI | Неприменимо (интерфейс файла не имеет спецификации) |
| Качество данных | Распределение значений, свежесть, объем | Большие надежды, тесты ДБТ | Неприменимо (отсутствует собственная тестовая среда) |
| Договор о формате файла | Структура байтов плоского файла, позиции полей | Запись в COBOL FD (источник достоверной информации) | Система контроля версий Copybook |
Запись «Управление версиями копибука» в столбце «Устаревший эквивалент» представляет собой практический механизм управления эволюцией схемы COBOL: копибук рассматривается как версионированный артефакт с процессом утверждения изменений, ведется реестр программ, включающих каждый копибук, и требуется проведение анализа влияния до утверждения любых изменений копибука.
Процесс утверждения изменений в копибуке:
- Разработчик предлагает внести изменения в
CUSTMSTR.CPY - Анализ воздействия выявляет каждую программу, которая включает в себя
CUSTMSTR.CPY(статический анализ) - Каждый плоский файл, созданный этими программами, идентифицируется как событие изменения схемы.
- Каждый последующий потребитель этих плоских файлов получает уведомление.
- Проводятся потребительские тесты на соответствие новой компоновке.
- Изменение будет одобрено только после подтверждения совместимости всеми потребителями.
Этот рабочий процесс имитирует схему обеспечения совместимости реестра схем, применяемую к уровню COBOL, где отсутствует собственный реестр схем.
Архитектура мониторинга для отслеживания смещения распределенной схемы
Полная архитектура мониторинга изменений схемы охватывает все четыре типа изменений на всех уровнях системы:
База данных моментальных снимков схемы. В ней хранится ежедневный моментальный снимок метаданных INFORMATION_SCHEMA каждой таблицы, каждой версии схемы зарегистрированных событий, каждой версии спецификации API и (для устаревших систем) каждой версии копибука. База данных моментальных снимков является базовым состоянием, с которым сравнивается текущее состояние.
Конвейер обнаружения изменений. Ежедневные задания сравнения выполняются по базе данных моментального снимка, обнаруживая добавления, удаления, изменения типов и ограничений на каждом контролируемом уровне. Изменения высокой степени серьезности, несовместимые с предыдущими версиями изменения типов, удаление столбцов, добавление обязательных полей, вызывают немедленные оповещения. Изменения низкой степени серьезности, добавление столбцов с возможностью значения NULL, изменения индексов, генерируют консультативные уведомления.
Реестр влияния на потребителей. Каталог, сопоставляющий каждый артефакт схемы с известными потребителями: какие конвейеры считывают данные из каких таблиц, какие сервисы потребляют какие темы Kafka, какие задания ETL обрабатывают какие плоские файлы. При обнаружении изменения схемы реестр влияния на потребителей определяет радиус воздействия, количество затронутых потребителей и наиболее критические из них.
Набор тестов для проверки контрактов. Автоматизированные тесты, проверяющие предположения потребителя о схемах производителя. Запускаются при каждом развертывании, затрагивающем сервис генерации данных. Развертывание завершается с ошибкой, если нарушается контракт, от которого зависит зарегистрированный потребитель.
Мониторинг границ устаревших систем. Для мэйнфреймов: сравнение копибуков с контролем версий, мониторинг определений наборов данных JCL и проверка формата плоских файлов на соответствие схеме, определенной в записи FD программы-производителя. Этот уровень требует анализа кода, а не мониторинга данных, и позволяет обнаруживать изменения в исходном коде COBOL, которые представляют собой изменения схемы для последующих потребителей.
Плановый мониторинг имеет большее значение, чем многие команды предполагают. В рекомендациях Acceldata по плановому анализу отклонений рекомендуется автоматическое сравнение со стабильным базовым уровнем с еженедельной или двухнедельной периодичностью, и прямо отмечается, что ожидание внеплановых проверок после сбоя недостаточно. Что касается мониторинга границ устаревших систем, периодичность должна соответствовать графику развертывания COBOL: любой релиз copybook в производственную среду должен немедленно запускать анализ влияния на схему, а не ждать следующего планового сравнения.
Как SMART TS XL Решение проблемы смещения схемы в устаревших средах
SMART TS XL Это решает проблему пробела в обнаружении на границе устаревших систем, на том уровне, где современные инструменты мониторинга перестают работать и где наиболее опасные отклонения от схемы остаются незамеченными.
Функция статического анализа кода анализирует каждую запись дескриптора файла COBOL, член COPY и предложение SELECT, создавая структурированное представление каждого артефакта схемы в устаревшей среде. При выполнении этого анализа для двух версий кодовой базы, до и после развертывания, различия составляют журнал изменений устаревшей схемы: какие копибуки изменились, какие определения полей изменились, каковы были макеты до и после. Это сравнение снимков схемы, применяемое к уровню COBOL.
Сопоставление зависимостей приложений предоставляет реестр влияния на потребителей для устаревших схем: какие программы включают каждую копибук-книгу, какие программы создают какие наборы данных в виде плоских файлов, какие задания JCL вызывают какие программы. Когда журнал изменений схемы идентифицирует измененную копибук-книгу, карта зависимостей немедленно выдает список потребителей, каждую программу, которая включает копибук-книгу, и каждый последующий плоский файл, который создают эти программы. Это расчет радиуса поражения, определяющий, является ли изменение копибук-книги внутренней модификацией с низким риском или событием с высоким риском, затрагивающим сотни программ и десятки последующих потребителей.
Функция анализа воздействия преобразует масштаб последствий в структурированный объем необходимых мер: для каждого потребителя, идентифицированного картой зависимостей, какие изменения необходимы для адаптации к новой схеме и в какой последовательности следует применять эти изменения? Для потребителей, находящихся на границе между устаревшими и современными системами, — конвейеров ETL, считывающих плоские файлы, созданные программами COBOL, — анализ воздействия определяет конкретные изменения положения полей и изменения типов данных, которые необходимо отразить в конфигурации сопоставления столбцов конвейера ETL.
Функция корпоративного поиска позволяет запрашивать информацию об артефактах схемы: находить каждую программу, которая считывает поле в определенной позиции байта (идентифицируя потребителей, на которых повлияет изменение структуры), каждый копибук, определяющий определенное поле (идентифицируя артефакт схемы, который необходимо версионировать и контролировать изменения), каждую программу, которая выводит данные в определенный набор данных (идентифицируя производителей, изменения схемы которых должны вызывать уведомления потребителей). Эта функция поиска поддерживает как проактивный процесс управления схемой, так и расследование инцидентов после внесения изменений.
Для организаций, управляющих модернизация наследия программы, включающие миграцию данных с мэйнфреймов на современные платформы, SMART TS XLАнализ схемы предоставляет исходную документацию по схеме, необходимую инструментам миграции, полные и актуальные определения записей FD и структуры копибуков, которые определяют, что представляют собой данные на самом деле, а не только то, что было на момент написания исходной спецификации миграции.
Контракт, который никто не писал, всё равно остаётся контрактом.
Смещение схемы в распределенных системах — не новая проблема. Это старая проблема, которую распределенная архитектура затрудняет в решении, поскольку полномочия, обеспечивавшие соблюдение контрактов схемы в монолитных системах — центральный администратор баз данных, единая команда разработчиков приложений, унифицированная кодовая база — распределены между десятками независимых сервисов, каждый из которых принимает индивидуально обоснованные решения, имея неполную информацию о каждом последующем потребителе.
Решение заключается не в повторной централизации полномочий над схемой. Оно состоит в том, чтобы сделать неявные контракты явными, зарегистрировать их в системах, которые могут сравнивать текущее состояние с базовым, обеспечивать соблюдение правил совместимости на границах, где вносятся изменения, и отслеживать нарушения на границах, где изменения распространяются. Для современных систем инструменты для этого существуют и быстро совершенствуются. Для устаревших систем, находящихся на границе с современными платформами, разрыв в инструментах реален и имеет существенные последствия: плоский формат файла, представляющий собой контракт схемы для облачного ETL-конвейера, невидим для всех современных инструментов мониторинга, если исходный код COBOL, определяющий его, не проанализирован и не версионирован как артефакт схемы.
Панель мониторинга, показавшая 23-процентное падение привлечения клиентов, не ошибалась в полученных данных. Она ошибалась в том, что эти данные означали, потому что схема, определяющая смысл данных, изменилась на границе, где не был зарегистрирован ни один контракт и не было никакого мониторинга. Эта граница, где бы она ни существовала в распределенной системе, устаревшей или современной, — это то место, до которого должны доходить программы обнаружения изменений схемы.
