не знаю насколько это поможет в ваших поисках. У нас была конкретная задача - найти все opensource/пропроитеарные решения которые были развернуты на боевых машинах и составить из них реестр.
У нас был условный верхний класс решений:
Брокеры
Операционные системы
Реляционные СУБД
Балансировщики и т.д.
Из документов мы уже знали заявляемый список продуктов, которые должны быть на машинах - kafka, pulsar, Ubuntu и так далее.
Потому задача свелась к тому, чтобы проверить на соответствие заявленного, установленному. На верхнем уровне были конкретные продукты, например kafka и была попытка вытащить название пакетов, которые бы явно указывали на kafka. Но и модель выглядела как соотнесение kafka - названиям пакетов, которые бы явно указывали на эту технологию-продукт. Но дальше модель начала усложняться - как вытащить версию? А с продуктами типа Postgres еще и проблема разделения где opensource, а где лицензионный продукт типа PG Pro. В итоге начинала вырисовываться сложная матрица, которую надо было наполнить и эту задачу мы поставили на паузу, т.к. было чем заняться по-мимо этого
Честно говоря готовых, рабочих продуктов, которые бы работали не синтетических данных не видел. На демо все умеют показать продукт с лучшей стороны, сам часто тоже готовил такие демо. На практике делали такие кейсы сами и в итоге уперлись в ограничения, чтобы чтобы работала магия с "автодискавери" 2.0, модель интерпретации превосходит стоимостью и сам интрумент и вообще команду архитектуры. Пара последних задач:
Привязывать виртуальные машины к ИТ системам, которые их используют. Скажем система называется Обработчик документов, она работает на каких-то ВМ, как получив список ВМ из среды виртуализации, автоматически их связать с этой системой. В итоге анализировать семантику названия машины типа doc-hand-worker-prod-01. Если машины все именуются одинаково, значит для них заданы правила и когда люди машины выделяют, они эту семантику соблюдают. Если они от неё отойдут и назовут типа main-db-03, сопоставить автоматом не получится. В итоге просто договорились, о что при выделение ресурса, команда будет делать связку в репозитории вручную.
Формировать реестр технологиий, которые используют решения через анализ пакетов. Заметили, что документы на системы порой расходятся с тем, что реально развернуто. От версий ПО, до прям принципиально других технологий. Т.е. стэк обновили, а документы нет. В итоге собрали через анализ все технологии по документам и хотели провести анализ по данным сканера. Даже научились парсить логи сканера, но дальше чтобы вытаскивать конкретные технологии нужна была табличка маппинга - тех же пакетов кафки, на технологию Кафка, это уже большая работа по сопоставлению одного с другим. А если добавить версии, то матрица становится просто гигантской. И её надо поддерживать вручную, через чью-то голову. У нас такой одной головы не было, было несколько и головы это дорогие, переложить на дешевый ресурс не получилось, в виду отсутствия знаний. В итоге поняли, что сама семантическая модель потребует колоссальных усилий на создание и поддержание и от идеи отказались. Перешли в режим выборочного аудита.
Выбрать то, что подходит под требования. В том числе бюджет, требования ИБ, импортозамещения и так далее. У всех организаций свои требования. У меня есть сравнения разных инструментов, но не хочу их показывать. Потому как это вызывает холивар - почему их так много, не возможно выбрать? или так мало, где вот те или те. А у вас критерии не те, что нам нужны и так по-кругу. Если букв много и нужна ссылка, вам не нужен тул. Пользуйтесь бесплатными и доступными решениями.
Это статья про Софт скиллы, а это тесно связано с развитием личности. Это не учебник по SQL, где есть чёткая структура и понятные команды. Не стоит понимать Сунь Цзы слишком буквально о войне или о Китае (ещё кстати качество перевода сильно влияет).
Важна интерпретация - первая глава о том, что при начинании большого дела, нужно расчитывать свои ресурсы и выходить на самоокупаемость проекта. Плохое планирование и постоянные запросы ресурсов у спонсора ни к чему хорошему не приведут. В последней главе описаны шпионы, читай инсайдеры, не обязательно внешние. Секретарь большого босса - которая говорит вам когда лучше всего зайти, а когда босс не в духе - просто находка.
Книга в разделе структурного мышления. Просто отбросьте мысли про Китай, войну и прочеее. Человек описывает структуру явления, последовательно, связно, тезисно, в труде нет воды, ссылок на другие исследования, личного мнения и пространных рассудений.
Интерпретация - это тоже навык, который надо тренировать. Перекладывать одну структуру на другую, искать общие черты - не учат на курсах программиста. Любые отношения между людьми построены через систему, как правило неявную, с кучей неформальных правил. Никто их не выкладывает в открытый доступ в виде должностных инструкций или регламента.
Ну это типовые ошибки, я же не один раз их встречал. Выбрал из опыта самые яркие и показательные. Действительно, задача архитектора смотреть шире и думать на пару шагов вперёд, взвешивать последствия и принимать непростые решения.
не знаю насколько это поможет в ваших поисках. У нас была конкретная задача - найти все opensource/пропроитеарные решения которые были развернуты на боевых машинах и составить из них реестр.
У нас был условный верхний класс решений:
Брокеры
Операционные системы
Реляционные СУБД
Балансировщики и т.д.
Из документов мы уже знали заявляемый список продуктов, которые должны быть на машинах - kafka, pulsar, Ubuntu и так далее.
Потому задача свелась к тому, чтобы проверить на соответствие заявленного, установленному. На верхнем уровне были конкретные продукты, например kafka и была попытка вытащить название пакетов, которые бы явно указывали на kafka. Но и модель выглядела как соотнесение kafka - названиям пакетов, которые бы явно указывали на эту технологию-продукт. Но дальше модель начала усложняться - как вытащить версию? А с продуктами типа Postgres еще и проблема разделения где opensource, а где лицензионный продукт типа PG Pro. В итоге начинала вырисовываться сложная матрица, которую надо было наполнить и эту задачу мы поставили на паузу, т.к. было чем заняться по-мимо этого
Честно говоря готовых, рабочих продуктов, которые бы работали не синтетических данных не видел. На демо все умеют показать продукт с лучшей стороны, сам часто тоже готовил такие демо. На практике делали такие кейсы сами и в итоге уперлись в ограничения, чтобы чтобы работала магия с "автодискавери" 2.0, модель интерпретации превосходит стоимостью и сам интрумент и вообще команду архитектуры.
Пара последних задач:
Привязывать виртуальные машины к ИТ системам, которые их используют. Скажем система называется Обработчик документов, она работает на каких-то ВМ, как получив список ВМ из среды виртуализации, автоматически их связать с этой системой. В итоге анализировать семантику названия машины типа doc-hand-worker-prod-01. Если машины все именуются одинаково, значит для них заданы правила и когда люди машины выделяют, они эту семантику соблюдают. Если они от неё отойдут и назовут типа main-db-03, сопоставить автоматом не получится. В итоге просто договорились, о что при выделение ресурса, команда будет делать связку в репозитории вручную.
Формировать реестр технологиий, которые используют решения через анализ пакетов. Заметили, что документы на системы порой расходятся с тем, что реально развернуто. От версий ПО, до прям принципиально других технологий. Т.е. стэк обновили, а документы нет. В итоге собрали через анализ все технологии по документам и хотели провести анализ по данным сканера. Даже научились парсить логи сканера, но дальше чтобы вытаскивать конкретные технологии нужна была табличка маппинга - тех же пакетов кафки, на технологию Кафка, это уже большая работа по сопоставлению одного с другим. А если добавить версии, то матрица становится просто гигантской. И её надо поддерживать вручную, через чью-то голову. У нас такой одной головы не было, было несколько и головы это дорогие, переложить на дешевый ресурс не получилось, в виду отсутствия знаний. В итоге поняли, что сама семантическая модель потребует колоссальных усилий на создание и поддержание и от идеи отказались. Перешли в режим выборочного аудита.
Выбрать то, что подходит под требования. В том числе бюджет, требования ИБ, импортозамещения и так далее. У всех организаций свои требования. У меня есть сравнения разных инструментов, но не хочу их показывать. Потому как это вызывает холивар - почему их так много, не возможно выбрать? или так мало, где вот те или те. А у вас критерии не те, что нам нужны и так по-кругу.
Если букв много и нужна ссылка, вам не нужен тул. Пользуйтесь бесплатными и доступными решениями.
А в чем кошмар?
Это статья про Софт скиллы, а это тесно связано с развитием личности. Это не учебник по SQL, где есть чёткая структура и понятные команды. Не стоит понимать Сунь Цзы слишком буквально о войне или о Китае (ещё кстати качество перевода сильно влияет).
Важна интерпретация - первая глава о том, что при начинании большого дела, нужно расчитывать свои ресурсы и выходить на самоокупаемость проекта. Плохое планирование и постоянные запросы ресурсов у спонсора ни к чему хорошему не приведут. В последней главе описаны шпионы, читай инсайдеры, не обязательно внешние. Секретарь большого босса - которая говорит вам когда лучше всего зайти, а когда босс не в духе - просто находка.
Книга в разделе структурного мышления. Просто отбросьте мысли про Китай, войну и прочеее. Человек описывает структуру явления, последовательно, связно, тезисно, в труде нет воды, ссылок на другие исследования, личного мнения и пространных рассудений.
Интерпретация - это тоже навык, который надо тренировать. Перекладывать одну структуру на другую, искать общие черты - не учат на курсах программиста. Любые отношения между людьми построены через систему, как правило неявную, с кучей неформальных правил. Никто их не выкладывает в открытый доступ в виде должностных инструкций или регламента.
Ну это типовые ошибки, я же не один раз их встречал. Выбрал из опыта самые яркие и показательные. Действительно, задача архитектора смотреть шире и думать на пару шагов вперёд, взвешивать последствия и принимать непростые решения.
Пожалуйста, надеюсь поможет на нелегком пути :)