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

В этой статье я объясню простую структуру, которая поможет вам работать над «вычислительными» частями вашего управления данными внутри Data Mesh.

Мы будем:

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

Управление вычислительными данными означает автоматизированное управление данными.

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

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

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

  • Шаг 1 — привести политику в форму, которую можно автоматизировать,
  • Шаг 2 — автоматизировать выполнение,
  • и Шаг 3 — увеличить скорость автоматизации.

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

Нашей отправной точкой является понимание нашей политики, которое мы теперь должны иметь в письменной форме. Например, они могли прочитать:

Список политик1. Никакая персонализированная информация не может быть передана без строгого контроля доступа.

2. Все данные должны содержать метаданные, идентифицирующие их предметную область.

Первая политика призвана помочь реализовать правила конфиденциальности. В отличие от этого, второй направлен на то, чтобы сделать данные более ЧЕСТНЫМИ, используя универсальные языки компании для бизнес-доменов.

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

Управление вычислительными данными необходимо с самого начала Data Mesh для использования самого персонажа Mesh. Потому что без управления невозможно потреблять или комбинировать узлы самой сетки данных в режиме самообслуживания. Если это невозможно, необходимо вмешательство человека, который не масштабируется и, таким образом, останавливает Data Mesh в самом начале.

Шаг 1. Создание политик для вычислений

Сделать политику вычислительной означает превратить ее в алгоритм.

Что такое алгоритм? Мы можем приблизительно определить алгоритм просто как набор шагов, которые можно выполнять автоматически, возможно, имея вход и выход.

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

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

Давайте посмотрим на два примера, чтобы понять это.

Пример 1, информация о бизнес-доменеКаждые данные должны содержать метаданные, идентифицирующие его бизнес-домен.

Из нашего MVP команда управления может довольно легко превратить эту политику в алгоритм, как показано в следующем примере:

Пример 1, алгоритм информации о бизнес-домене1. Вход: метаданные для продукта данных домена из центрального реестра.

2. Найдите ключ «подразделение» в метаданных.

3. Сравните его со списком бизнес-единиц.

4. Вывод: True, если бизнес-подразделение содержится в списке, False в противном случае.

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

Что бы они ни делали, это повлияет на фактическую политику и немного изменит ее.

Второй пример немного глубже.

Пример 2, персонализированная информацияОбмен персонализированной информацией без строгого контроля доступа запрещен.

Команде управления, скорее всего, будет трудно внедрить эту политику в алгоритм, и нам тоже. Последняя политика применялась только к одному определенному полю метаданных, тогда как эта политика касается всего содержимого данных.

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

Пример 2, персонализированная информация1. Вход: данные одного фактического продукта данных домена.

2. Проверьте, содержат ли данные данные в форме «Имя Фамилия» или «[email protected]» или типичные IP-адреса.

3. Если это не так, верните True, в противном случае верните False.

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

Шаг 2 и 3. Автоматизация проверки политик

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

Для этих двух примеров политик мы не считаем необходимым превращать их в полностью автоматизированные политики. Как вы видели в предыдущем разделе, это довольно сложно. И если мы только начинаем работу с нашим MVP Data Mesh, возможно, даже не потребуется превращать политику «бизнес-подразделения» во что-то полностью автоматизированное.

Шесть уровней автономного вождения можно грубо охарактеризовать следующим образом:

  • Уровень-0: никакой автоматизации. Кто-то управляет «всем». Это ваша отправная точка. Вы сами водите.
  • Уровень-1: система помощи, предоставляющая какую-либо помощь, такую ​​как мониторинг/оповещение, например монитор скорости или монитор расстояния.
  • Уровень 2. Этот уровень описывает частичную полную автоматизацию той части системы, которую вы хотите автоматизировать. Но оператор все еще должен делать другие вещи. К этой категории относится, например, функция «соблюдения дистанции» или функция «ассистент движения по полосе» в автомобиле.
  • Уровни от 3 до 5: полностью автономная работа, хотя и пошагово. Нам не понадобятся подробности этого. Мы сохраняем его как «автономный». Это означает, что вы можете отпустить ведущее колесо.

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

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

Если мы оставим первую политику на уровне 0, человеку из желтой команды нужно будет пройти через JSON и подтвердить их. Так что давайте пока оставим это.

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

Как только Team Yellow почувствует себя уверенно со своим сценарием, они могут принять решение превратить его в систему уровня 2, продвинувшись вперед с частичной автоматизацией. Это означает, что они установят его, например, как «перехватчик git перед фиксацией» внутри репозиториев, где хранятся данные. Затем каждый раз, когда человек помещает новые данные в репозиторий, проверки будут автоматически запускаться до того, как данные поступят в систему. Желтая команда может даже решить остановить фиксацию, вернув ошибку, если политика не соблюдается.

Конечно, поскольку проверить персонализированные данные непросто, этот автоматизированный скрипт все еще может быть неисправен. Таким образом, Желтая команда предоставила бы возможность переопределения с первой попытки.

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

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

Заключение

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

  • 1. Начать с политик, которые можно превратить в алгоритмы.
  • 2. Реализовать эти политики в виде алгоритмов.
  • 3. Чтобы затем использовать структуру уровней автоматизации для повышения скорости управления вычислительными данными.

Я надеюсь, что эти шаги помогут вам внедрить управление вычислительными данными, поскольку это неотъемлемая часть Data Mesh!

Заинтересованы в том, как создать отличные компании, работающие с данными, отличные продукты с большими объемами данных, стать отличной командой по работе с данными или как создать что-то замечательное с открытым исходным кодом? Тогда подумайте о том, чтобы присоединиться к моей бесплатной рассылке «Три точки данных по четвергам». Он стал надежным ресурсом для стартапов, венчурных капиталистов и лидеров данных.