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

Поле данных — это одна из самых маленьких смысловых единиц в программной системе, и тем не менее отслеживание его в масштабах предприятия — одна из самых сложных задач, с которыми может столкнуться разработчик, аналитик или специалист по соблюдению нормативных требований. Поле customer_id Существует где-то в виде определения. Оно хранится в одной или нескольких таблицах. Его считывают программы, передают между сервисами, преобразуют задания ETL, проверяют бизнес-правилами и в конечном итоге отображают в отчетах, панелях мониторинга или ответах API, используемых совершенно другими системами. Вопрос о том, откуда это поле взялось, куда оно направляется и что с ним происходит между этими этапами, — это не вопрос документации или архитектуры. Это актуальный вопрос о самом коде, самих данных и путях выполнения работающей корпоративной системы. Чтобы дать точный ответ, необходимо проследить за полем на каждом уровне, где оно появляется, на каждом языке, платформе и в каждом репозитории, в котором оно находится.

В современных организациях, ориентированных на работу с данными, эта возможность называется отслеживанием происхождения данных, и инструменты для современных аналитических стеков, включая облачные хранилища данных, конвейеры ETL и платформы бизнес-аналитики, значительно усовершенствовались. Отслеживание происхождения данных на уровне столбцов является стандартом во многих аналитических средах. Но корпоративные программные системы — это не аналитические стеки. Это гетерогенные комбинации программ для мэйнфреймов, пакетных заданий, реляционных баз данных, распределенных сервисов и современных API, каждая из которых управляется различными инструментами, различными командами и решениями, принятыми на протяжении десятилетий проектирования. В этой области... ACCT-BALANCE Определенный в COBOL-копибуке параметр не отображается в Databricks или dbt. JCL-задание, которое обрабатывает пакетное обновление для этого поля, не фиксируется ни одним инструментом отслеживания происхождения данных в облаке. Java-сервис, который считывает результирующую строку базы данных и заполняет объект ответа, представляет собой третью систему со своей собственной системой именования для того же базового значения. Как подробно рассмотрено в контексте Сопоставление JCL и COBOLЭти три слоя глубоко переплетены таким образом, что ни один отдельный инструмент не был предназначен для их расшифровки, и отсутствие единого следа — это не незначительный пробел, а структурное «слепое пятно», которое влияет на каждую задачу, затрагивающую общие данные.

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

Что означает отслеживание поля данных в рамках корпоративной системы?

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

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

Разница между трассировкой на уровне таблицы и на уровне поля.

В литературе, посвященной происхождению данных, различают два уровня детализации: происхождение на уровне таблиц, показывающее взаимосвязь наборов данных, и происхождение на уровне столбцов, показывающее, как создаются, преобразуются и используются отдельные поля. Различие заключается не только в точности. Это разница между знанием того, что система А передает данные в систему В, и знанием того, что значение customer_segment в системе B получается в результате расчета, примененного к account_type и tenure_months В системе А. Отслеживание изменений на уровне таблиц показывает команде, что изменение в системе А может повлиять на систему В. Отслеживание изменений на уровне полей показывает, какое конкретное поле в системе В затронуто, каким конкретным преобразованием, при каких конкретных условиях. Именно эта детализация превращает карту происхождения данных из направленной карты в карту, позволяющую принимать решения.

В корпоративных системах с мэйнфреймами и устаревшими компонентами вопрос детализации еще больше усложняется существенными различиями в соглашениях о представлении данных на разных уровнях. Поле рабочей памяти COBOL определяется как WS-ACCT-BAL PIC S9(13)V99 содержит ту же бизнес-концепцию, что и переменная в Java. accountBalance типа BigDecimalкоторый содержит ту же концепцию, что и столбец базы данных. ACCT_BALANCE DECIMAL(15,2)Трассировка на уровне таблицы отслеживает потоки данных из программы COBOL в таблицу базы данных и далее в службу Java. Трассировка на уровне поля позволяет определить, что... WS-ACCT-BAL, ACCT_BALANCE и accountBalance Все они представляют собой одну и ту же бизнес-концепцию, с задокументированными преобразованиями между ними. Именно это разрешение делает отслеживание пригодным для практического применения.

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

Инструменты отслеживания происхождения данных в аналитике, включая современные платформы, построенные на основе хранилищ данных и фреймворков преобразования, таких как dbt, работают в средах, где перемещение данных явно координируется с помощью определенных этапов конвейера, и где входные и выходные данные каждого этапа регистрируются в метаданных, которые может прочитать инструмент отслеживания происхождения. Отслеживание происхождения строится на основе определений конвейера, которые представляют собой машиночитаемые артефакты, специально разработанные для поддержки такого рода анализа. Корпоративные программные системы работают иначе. Программа на COBOL не объявляет свои входные и выходные данные в машиночитаемом манифесте. Задание JCL не публикует схему полей, которые оно читает и записывает, в реестр метаданных. Сервис Java не аннотирует каждую ссылку на поле ее концептуальной связью со столбцом базы данных. Связи между ссылками на поля на разных уровнях выражаются в самом коде: в операторах MOVE, в SQL-запросах, встроенных в программы, в определениях структуры файлов, в сигнатурах методов сервиса. Отслеживание этих связей требует чтения и понимания фактического кода, а не использования реестра метаданных конвейера. Как показано в контексте статического анализа распределенных систем , рассуждения о потоке данных между компонентами сложной распределенной системы требуют структурного анализа самого кода, а не просто наблюдения за внешним поведением системы.

Уровни, через которые проходит поле данных в корпоративной системе

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

Слой определения: Откуда берется поле.

Каждое поле имеет точку происхождения: место, где оно впервые определяется как именованный элемент данных с типом, длиной и значением. В средах COBOL это обычно определение в рабочей памяти или член копибука. В реляционных базах данных это определение столбца в схеме таблицы. В сервисах Java или .NET это объявление поля в классе или структуре. В системах, основанных на сообщениях, это поле в определении схемы, будь то JSON Schema, Avro, Protobuf или XSD. Уровень определения важен, поскольку он устанавливает каноническую идентичность поля. Поле с именем CUST-ID В COBOL-копибуке содержится авторитетное определение данного понятия в среде мэйнфрейма, и оно относится ко всему, что читается, записывается или преобразуется. CUST-ID В этой среде находится потребитель данного определения. Отслеживание поля начинается здесь и продолжается по ссылкам наружу через код, который его использует.

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

Уровень хранения данных: базы данных, файлы и наборы данных.

После первоначальной обработки значение поля почти всегда сохраняется. В реляционных базах данных оно хранится в столбце. В средах мэйнфреймов оно может храниться в файле VSAM, плоском файле с определенной структурой или в базе данных, управляемой через CICS или IMS. В распределенных системах оно может храниться в хранилище NoSQL, очереди сообщений, распределенном кэше или системе хранения BLOB-объектов. Уровень хранения — это место, где ссылки на поля чаще всего меняют свое представление: поле с именем CUST-ID В программе на COBOL выполняется запись в столбец с именем CUSTOMER_ID в таблице DB2, и Java-сервис считывает CUSTOMER_ID из той же таблицы и сохраняет ее в поле объекта с именем customerIdКаждое из этих значений одинаково, но ни один автоматизированный инструмент не сможет установить эту эквивалентность без модели, которая связывает ссылку на поле COBOL со столбцом базы данных и полем объекта Java.

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

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

Между определением и хранением, а также между хранением и потреблением, происходит обработка значений полей. Программы вычисляют на их основе производные значения. Сервисы проверяют их на соответствие бизнес-правилам. Пакетные задания агрегируют их, преобразуют формат, фильтруют записи на основе их содержимого или направляют обработку в зависимости от их значений. Каждый из этих этапов обработки является узлом в трассировке поля, и каждый из них необходимо понимать, чтобы ответить на вопросы о корректности значений, логике преобразования и порядке обработки. В средах мэйнфреймов именно на уровне обработки сосредоточена большая часть сложности, и, как подробно описано в разделе, посвященном решениям статического анализа COBOL , для понимания того, что программа COBOL фактически делает с полем, требуется анализ и понимание всей структуры программы, включая условную логику, определяющую, какой путь обработки выполняется для данного входного значения.

На уровне обработки данных чаще всего возникают межъязыковые границы. Когда пакетное задание COBOL записывает данные в базу данных, а служба Java считывает их, или когда задание ETL на Python преобразует файл, созданный процессом мэйнфрейма, поле переходит из обработки одного языка в обработку другого. Трассировка поля, охватывающая уровень обработки данных, должна следовать за полем через эти точки пересечения, разрешая различные имена и представления, которые оно содержит в каждом языке, и делая это посредством структурного анализа, а не сопоставления строк.

Уровень потребления: отчеты, API и нижестоящие системы

В конце пути поля его значение используется: отображается в отчете, возвращается в ответе API, передается в модель машинного обучения, публикуется в очередь сообщений для другой системы или отображается в нормативной документации. Эти точки использования важны по двум причинам. Во-первых, они определяют, кто пострадает, если значение поля окажется неверным или недоступным. Во-вторых, они определяют, какие внешние системы, пользователи и нормативные обязательства зависят от поля, что определяет масштаб влияния изменений, когда необходимо изменить определение или обработку поля. Отслеживание на уровне использования часто является наиболее необходимым для групп по соблюдению нормативных требований и регулированию, и, как описано в более широком контексте графов зависимостей и рисков приложений , отображение того, от чего зависит каждый компонент системы, является основополагающим для безопасного управления изменениями и выполнения обязательств, требующих продемонстрированной отслеживаемости.

Почему стандартные методы трассировки не работают в корпоративных средах

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

Поиск по тексту выдает шум и пропускает ссылки.

Наиболее распространенной отправной точкой для трассировки полей является текстовый поиск: поиск имени поля в исходном коде, SQL-скриптах и ​​конфигурационных файлах. Текстовый поиск быстр, доступен повсюду и не требует специальных инструментов. Однако он ненадежен для целей полной и точной трассировки полей. Проблема надежности работает в обе стороны. Текстовый поиск выдает слишком много результатов: короткие имена полей, например, ID, STATUS или DATE встречаются в тысячах совершенно несвязанных контекстов, и даже в более длинных именах, таких как account_balance Они могут появляться в сообщениях журналов, комментариях и тестовых данных, не имеющих структурной связи с отслеживаемым полем. В то же время текстовый поиск выдает слишком мало результатов, пропуская ссылки, где имя поля различается между уровнями, ссылки, выраженные через вычисляемые ключи или псевдонимы, ссылки в сгенерированном коде и ссылки, опосредованные данными, а не прямыми ссылками в коде.

Рассмотрим след WS-CUSTOMER-ID, поле в разделе рабочей памяти COBOL:

кобол

WORKING-STORAGE SECTION.
   05 WS-CUSTOMER-ID   PIC X(10).

PROCEDURE DIVISION.
   MOVE CUSTOMER-RECORD-ID TO WS-CUSTOMER-ID.
   EXEC SQL
       INSERT INTO CUSTOMER_AUDIT
           (CUST_ID, AUDIT_TS)
       VALUES (:WS-CUSTOMER-ID, CURRENT TIMESTAMP)
   END-EXEC.

Поиск текста по запросу WS-CUSTOMER-ID Находит определение рабочей памяти и ссылки в этой программе. Не находит:

• Столбец базы данных CUST_ID который получает значение поля посредством встроенной SQL-инструкции INSERT.
• Java-сервис, который выполняет чтение CUST_ID от CUSTOMER_AUDIT и сохраняет его как customerId
• Ответ API, который сериализуется customerId as customer_id в формате JSON для конечных потребителей
• Отчет или информационная панель, которая в конечном итоге отображает это значение конечным пользователям.

Для каждого из этих соединений требуется свой тип анализа: синтаксический анализ SQL, сопоставление схем, анализ AST Java и проверка контрактов API. Текстовый поиск не предоставляет ни одного из этих инструментов, и его результаты не указывают на то, что эти соединения существуют или были пропущены.

Документация устаревает еще до того, как она будет завершена.

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

Ручной осмотр не масштабируется.

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

Как должна работать на практике унифицированная трассировка поля.

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

Начало трассировки: выбор правильной опорной точки

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

Следуя по траектории через каждый слой.

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

В рамках одной программы: разрешение ссылок на поля внутри одного исходного файла, включая определения, чтение, запись, преобразования и условное использование. Для COBOL это означает понимание операторов MOVE, COMPUTE, предложений REDEFINES и потока данных на уровне абзацев. Для Java это означает разрешение доступа к полям, вызовы методов, передающих или возвращающих поле, и выражения преобразования.

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

Преодоление языковых барьеров: разрешение межъязыковых связей, когда значение поля перемещается из программы COBOL в столбец базы данных, из столбца базы данных в поле объекта Java, из объекта Java в ответ JSON API или из любого другого представления на языке источника в представление на языке цели. Это требует единой модели, которая представляет ссылки на поля из всех языков в общей структуре и разрешает концептуальные эквивалентности между различными представлениями одной и той же бизнес-концепции.

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

Разрешение межъязыковых эквивалентностей в предметных областях

Наиболее часто встречающаяся ошибка на практике — это разрешение эквивалентности языковых полей: установление того, что WS-CUSTOMER-ID в COBOL, CUST_ID в столбце DB2, и customerId В объекте Java все элементы представляют одну и ту же бизнес-концепцию. Без этой эквивалентности трассировка, достигающая границы COBOL-базы данных, не может продолжиться в слой Java. Наиболее надежный подход к установлению этих эквивалентностей — структурный анализ кода, заполняющего целевое поле. Когда выполняется программа COBOL... INSERT INTO CUSTOMER_AUDIT (CUST_ID) VALUES (:WS-CUSTOMER-ID)Структурный анализ SQL-запроса напрямую подтверждает, что CUST_ID получает свою ценность от WS-CUSTOMER-IDЭта связь становится ребром в графе трассировки поля, и трассировка продолжается на стороне базы данных.

В таблице ниже показано, как выглядит полная трассировка месторождения в виде структурированной последовательности этапов разрешения для репрезентативного месторождения:

Этап отслеживания	Исходный артефакт	Целевой артефакт	Тип соединения
1. От тетради к программе	CUSTCOPY член копировальной книги CUST-ID	Программа на языке COBOL CUSTINQ	Ссылка на заявление COPY
2. Программа для работы с базой данных	переменная хоста COBOL :WS-CUSTOMER-ID	столбец DB2 CUST_ID in CUSTOMER_AUDIT	Встроенная SQL-запрос на вставку (INSERT)
3. Преобразование базы данных в сервис	DB2 CUST_ID	поле Java customerId in CustomerAuditService	Сопоставление JDBC ResultSet
4. Сервис для API	Java customerId	Поле JSON customer_id в ответе REST	сериализация Джексона
5. API для формирования отчетов	JSON customer_id	Размеры панели управления Customer Identifier	Использование API уровнем бизнес-аналитики

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

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

Анализ влияния изменений схемы

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

Соблюдение нормативных требований и права субъектов данных

Нормативные акты по защите данных, включая GDPR, HIPAA и CCPA, налагают обязательства, требующие отслеживания на уровне полей. Запрос на удаление данных в соответствии с GDPR требует идентификации и удаления всех хранилищ персональных данных запрашивающего лица во всех системах. Аудит HIPAA требует демонстрации того, что доступ к защищенным полям медицинской информации имеют только авторизованные системы и персонал. Оценка BCBS 239 требует доказательства того, что конкретные показатели риска рассчитываются последовательно на основе документированных исходных полей посредством документированных преобразований. Ни одно из этих обязательств не может быть выполнено посредством отслеживания на уровне таблиц, поскольку обязательство распространяется на конкретные поля, а не на целые таблицы. Отслеживание на уровне полей сообщает группам по соблюдению нормативных требований, какие столбцы в каких программах и в каких системах хранят и обрабатывают конкретные поля, являющиеся предметом запроса, и именно эта конкретика определяет, является ли ответ по соблюдению нормативных требований полным и подлежащим аудиту или неполным и обоснованным только посредством аттестации.

Анализ первопричин инцидентов, связанных с качеством данных.

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

Безопасное переименование и устаревание полей

Переименование поля или объявление поля устаревшим требует знания всех мест, где используется текущее имя, до внесения изменений. В одноязычной кодовой базе с одним репозиторием инструменты рефакторинга IDE надежно справляются с этим. В многоязычной корпоративной системе переименование выходит за рамки языков, и ни один инструмент не обладает полной видимостью: поле, переименованное в COBOL-копибуке, должно быть обновлено в каждой COBOL-программе, которая ссылается на копибук, в каждом SQL-запросе, использующем соответствующее имя столбца, в каждом Java-сервисе, который сопоставляет столбец с полем объекта, и в каждом последующем потребителе этих сервисов. Трассировка на уровне поля предоставляет полный список ссылок до начала переименования, позволяя командам разработчиков заранее проработать список ссылок и развертывать с уверенностью в том, что переименование завершено. То же самое относится и к объявлению поля устаревшим: трассировка устаревшего поля определяет, какие потребители все еще зависят от него, и, следовательно, какие потребители должны быть перенесены до того, как объявление устаревшего поля может быть безопасно завершено.

Как SMART TS XL Создает полную трассировку на уровне поля.

SMART TS XL Создается единая модель перекрестных ссылок всей корпоративной системы путем обработки исходного кода со всех языков и платформ в среде и анализа каждого из них с использованием специфических для языка методов. Программы на COBOL, потоки заданий JCL, схемы DB2 и SQL, службы Java, приложения .NET, скрипты Python, а также артефакты конфигурации XML и JSON — все это анализируется и преобразуется в общий граф символов и связей. Ссылки на поля в каждом языке представлены в виде узлов в этом графе, а связи между ними, включая определения, операции чтения, записи, преобразования и межъязыковые эквиваленты, представлены в виде типизированных ребер. Этот граф является основой для каждой трассировки полей, выполняемой платформой.

Отслеживание на уровне поля в SMART TS XL Обход графа — это обход графа от любого узла, ссылающегося на поле, по ребрам в соответствующем направлении для заданного вопроса. Прямая трассировка от элемента копибука COBOL возвращает каждую программу, которая включает копибук, каждое SQL-запрос в этих программах, который ссылается на соответствующий столбец, каждую таблицу, которая получает значение столбца, каждый сервис, который читает из этой таблицы, и каждый ответ API или отчет, который предоставляет доступ к полю внешним потребителям. Обход автоматически пересекает языковые границы, поскольку межъязыковые эквиваленты разрешаются во время индексирования, а не во время выполнения запроса. Возможность корпоративного поиска платформы обеспечивает точку входа для трассировки полей: разработчик или аналитик, ищущий имя поля в индексированной системе, получает результаты, организованные по типу артефакта, языку и типу связи, при этом определения, операции чтения, записи, ссылки SQL, включения копибука и доступ к API — все это различается в наборе результатов. Как описано в решения для корпоративного поиска На этой странице платформа разработана специально для обнаружения всех мест использования поля во всем портфеле приложений, что позволяет напрямую и в масштабе всего предприятия решать проблему отслеживания полей.

SMART TS XLАнализ влияния завершает рабочий процесс отслеживания полей, автоматически отвечая на основной вопрос. Когда поле в копибуке, схеме базы данных или интерфейсе сервиса помечается для изменения, платформа вычисляет полный график влияния на последующие этапы и представляет его в виде навигационного отчета с перекрестными ссылками, организованного по слоям и по конкретному местоположению ссылки. Это преобразует наиболее трудоемкую часть отслеживания полей — перечисление каждого последующего потребителя перед внесением изменений — из ручного исследования в структурированный результат запроса, который любой член команды может запустить, интерпретировать и использовать. Как показано в контексте топология зависимостей и последовательность модернизацииСпособность точно знать, на что повлияют изменения, прежде чем они будут внесены, является основополагающим требованием для работы по модернизации, которая управляет рисками, а не создает их.

Отслеживание местоположения на местах как непрерывный процесс, а не как проектная деятельность.

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

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