Комментарии

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

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

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

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

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

Интересно узнать как генеративные модели учатся?

Модели разграничения доступа бывают разные.

Access Control List (ACL) — это когда ручками прописывается кто имеет доступ и на что (см. файловая система в *nix)

более эффективной практикой считается разграничение по ролям RBAC — но тут надо предусмотреть разделение обязанности на разные роли (segregation of duties), например чтобы создавая запись об объекте, он не имел дальнейшего доступа к его функциям, чтобы потенциально не смог злоупотребить.

Например если админ создал учетку юзера, то он не знает пароль к учетке и не может под ней залогиниться. Только отправить ссылку со сбросом пароля на почту юзеру. Также не может удалить запись аудита своих действий (логи о создании учетки и сбросе пароля например)

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

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

Подскажите, пожалуйста, какие есть способы реализовать это? Дело в том, что мы это реализовываем в своих проектах через т.н. реализацию МРД (модели разграничения доступа, но, возможно, это наш внутренний термин).

МРД — это документ в котором мы прописываем для каждого объекта правила доступа нему со стороны каждого субъекта. Потом эту МРД реализуем в коде на Java. Но получается жутко сложно, много ошибок и косяков.

Может есть какая-то книжка или бест-практика как это реализовывать проще?

Умение реализовать грамотное REST API — полезный навык в наше время, т.к. все больше сервисов предоставляют свои возможности с помощью API. Но разработка REST API не ограничивается реализацией HTTP запросов в определенном стиле и формированием ответов в соответствии со спецификацией. Задача обеспечения безопасности REST API не так очевидна, как, например, обеспечение безопасности баз данных, но ее необходимость не менее важна.
В настоящее время многие онлайн системы с помощью API передают приватные данные пользователей, такие как медицинские или финансовые. Текущая же ситуация с безопасностью в веб-приложениях весьма печальна: по данным Comnews порядка 70% содержат кри­тичес­кие уязвимости. Поэтому всем, кто участвует в проектировании, реализации и тестировании онлайн систем, важно иметь общую картину по существующим угрозам и способам обеспечения безопасности как всей системы, так и используемого REST API.

В заключении приведу несколько общих выводов:

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

За два года работы мы выпустили 7 новых версий приложения на Symfony framework. Оно сразу автоматически обновлялось на всех устройствах, без дополнительного участия разработчика.

Приложение на Симфони совсем не виснет даже в праздники, когда запросы возрастают. Каждый модуль упакован в контейнер на сервере и может быть горизонтально масштабирован в зависимости от нагрузки.

Симфони экономит деньги клиента на обслуживание. Фреймворк сокращает ресурсы компании на разработку: для написания обновлений и обслуживания приложения нам, как правило, хватает двух программистов. Платить за использование framework и техподдержку не нужно. Так что отличный фреймворк

За два года работы мы выпустили 7 новых версий приложения на Symfony framework. Оно сразу автоматически обновлялось на всех устройствах, без дополнительного участия разработчика.

Приложение на Симфони совсем не виснет даже в праздники, когда запросы возрастают. Каждый модуль упакован в контейнер на сервере и может быть горизонтально масштабирован в зависимости от нагрузки.

Симфони экономит деньги клиента на обслуживание. Фреймворк сокращает ресурсы компании на разработку: для написания обновлений и обслуживания приложения нам, как правило, хватает двух программистов. Платить за использование framework и техподдержку не нужно. Так что отличный фреймворк

В разработке мы решили применить популярный PHP-фреймворк Symfony. Он выстроен на архитектуре MVC и часто используется для проектов open source. Это проекты с открытым кодом, который доступен для общего пользования.

Symfony framework — распространенная альтернатива Laravel PHP-framework для создания веб-приложений (used for development of web applications). Рассказываем, какие плюсы фреймворк Symfony дает для работы сервиса.

Создает новые компоненты быстро и не утяжеляет систему. Благодаря Symfony framework разработчику не нужно писать много кода, чтобы подключить новые функции к системе. Symfony не копирует сам себя при создании новых components, а работает как единый фреймворк благодаря минимально функциональному ядру.

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

В Symfony оригинальна система множественного использования кода — The Bundle System to create reusable code. Это готовая библиотека с рецептом интеграции в Dependency Injection контейнер приложения и описанием необходимых параметров конфигурации. Мы часто используем бандлы в работе с Symfony framework.

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

Организует среду вокруг кодовой базы, с которой удобно работать. Чтобы программисту было удобно работать, фреймворк Symfony создает специальную среду, где сохраняет материалы с паролями, адресами в файлах разных форматов.

Symfony поддерживает любые форматы файлов: как нативные PHP-файлы, так и XML, INI, YAML. В Posiflora мы используем формат YAML: он легко читается и органично описывает необходимые структуры параметров. Фреймворк по умолчанию производит кеширование результатов парсинга файла конфигурации YAML, из-за этого работа framework не влияет на производительность приложения.

В разработке мы решили применить популярный PHP-фреймворк Symfony. Он выстроен на архитектуре MVC и часто используется для проектов open source. Это проекты с открытым кодом, который доступен для общего пользования.

Symfony framework — распространенная альтернатива Laravel PHP-framework для создания веб-приложений (used for development of web applications). Рассказываем, какие плюсы фреймворк Symfony дает для работы сервиса.

Создает новые компоненты быстро и не утяжеляет систему. Благодаря Symfony framework разработчику не нужно писать много кода, чтобы подключить новые функции к системе. Symfony не копирует сам себя при создании новых components, а работает как единый фреймворк благодаря минимально функциональному ядру.

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

В Symfony оригинальна система множественного использования кода — The Bundle System to create reusable code. Это готовая библиотека с рецептом интеграции в Dependency Injection контейнер приложения и описанием необходимых параметров конфигурации. Мы часто используем бандлы в работе с Symfony framework.

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

Организует среду вокруг кодовой базы, с которой удобно работать. Чтобы программисту было удобно работать, фреймворк Symfony создает специальную среду, где сохраняет материалы с паролями, адресами в файлах разных форматов.

Symfony поддерживает любые форматы файлов: как нативные PHP-файлы, так и XML, INI, YAML. В Posiflora мы используем формат YAML: он легко читается и органично описывает необходимые структуры параметров. Фреймворк по умолчанию производит кеширование результатов парсинга файла конфигурации YAML, из-за этого работа framework не влияет на производительность приложения.

Хорошая CRM-система, особенно подходит для управления персоналом и клиентами, в нашем случае мы используем DSR CRM в нашем ИТ отделе

Если такие вопросы задаются при собеседовании человека с >3 лет реального опыта — возможно да. Для новичков в отрасли тестирования они просто могут помочь понять произошла-ли уже проф. деформация мышления, т.е. остановится-ли человек на условной перепроверке шагов воспроизведения из дефекта или все же полезет щупать потенциально затронутые области.

Создаётся впечатление, что вопросы типа «QA vs QC» и «верификация vs валидация» больше нужны, чтобы на собеседованиях умничать

Есть общеизвестные лучшие практики для создания эффективных кластеров Kubernetes:

Выберите правильный размер узла

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

— Учитывайте требования к рабочей нагрузке − ваш выбор размера узла должен основываться на требованиях к рабочей нагрузке. Для рабочих нагрузок с интенсивным использованием ЦП выбирайте узлы с высокой производительностью ЦП. Для рабочих нагрузок с большим объемом памяти выбирайте узлы с большим объемом памяти.

— Избегайте чрезмерного расширения − Чрезмерное расширение узлов может привести к ненужным затратам. Выберите наименьший размер узла, соответствующий вашим требованиям к рабочей нагрузке, чтобы избежать чрезмерного расширения.

— Используйте горизонтальное масштабирование − Если ваши требования к рабочей нагрузке со временем меняются, используйте горизонтальное масштабирование для добавления или удаления узлов из вашего кластера по мере необходимости.

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

Изучайте наши новейшие онлайн-курсы и осваивайте новые навыки в своем собственном темпе. Зарегистрируйтесь и станьте сертифицированным экспертом, чтобы повысить свой карьерный рост.

Оптимизация размещения модулей

Размещение модулей является важным фактором оптимизации использования ресурсов в кластере Kubernetes. Вот несколько рекомендаций по размещению модулей −

— Используйте правила защиты от привязки − Правила защиты от привязки могут препятствовать размещению модулей на одном узле, что может повысить доступность и отказоустойчивость.

— Используйте селекторы узлов − Селекторы узлов могут помочь гарантировать размещение модулей на узлах с необходимыми ресурсами, что может повысить производительность и использование ресурсов.

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

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

Используйте ограничения ресурсов и запросы

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

— Установите ограничения ресурсов − ограничения ресурсов могут помочь предотвратить использование pod большего количества ресурсов, чем ему нужно, что может улучшить использование ресурсов и предотвратить конкуренцию за ресурсы.

— Задавайте запросы ресурсов − запросы ресурсов могут помочь гарантировать, что модуль получает ресурсы, необходимые ему для правильной работы, что может повысить производительность и доступность.

— Используйте функцию квотирования ресурсов Kubernetes − функцию квотирования ресурсов можно использовать для ограничения объема ресурсов, которые может потреблять пространство имен, что может предотвратить чрезмерное предоставление и повысить экономию средств.

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

Реализовать автоматическое масштабирование

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

— Используйте функцию автоматического масштабирования горизонтальных модулей Kubernetes (HPA) − функция HPA может использоваться для автоматического масштабирования количества модулей в развертывании на основе загрузки процессора или других показателей.

— Используйте функцию автоматического масштабирования кластера Kubernetes (CA) − функция CA может использоваться для автоматического масштабирования количества узлов в кластере на основе использования ресурсов.

— Установите соответствующие пороговые значения автоматического масштабирования − Установите пороговые значения для автоматического масштабирования на основе ваших требований к рабочей нагрузке и шаблонов использования ресурсов.

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

Мониторинг и оптимизация производительности кластера

Мониторинг и оптимизация производительности кластера важны для обеспечения эффективной работы кластера и оптимального использования ресурсов. Вот несколько рекомендаций по мониторингу и оптимизации производительности кластера. −

— Используйте инструменты мониторинга − Используйте инструменты мониторинга, такие как Prometheus, Grafana и Kubernetes Dashboard, для мониторинга производительности кластера и использования ресурсов.

— Оптимизируйте размещение рабочей нагрузки − Используйте методы размещения рабочей нагрузки, такие как правила привязки к pod и анти-привязки, для оптимизации использования ресурсов и повышения производительности.

— Оптимизировать распределение ресурсов − Оптимизируйте распределение ресурсов, установив соответствующие лимиты ресурсов и запросы, а также используя квоты ресурсов Kubernetes.

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

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

Искусственный интеллект — это не только чатботы, отвечающие на любые вопросы, но и инструменты, которые трансформируют все уровни стека программного обеспечения, в том числе СУБД. Как именно меняются базы данных благодаря ИИ?

Данные, на которых обучаются модели ИИ, после извлечения из базы приходится преобразовывать в специальный формат — векторы. Это возможно для данных любого типа, но наиболее широко применяются методы векторного представления (или «вложения», embedding) слов: различным словам и фразам сопоставляются векторы из некоторого набора, кодирующие не только само слово, но и его значение: векторы, «близкие» друг к другу по направлению в пространстве, соответствуют схожим по значению словам. При этом векторов в наборе гораздо меньше, чем количество слов, которые они кодируют. Для формирования такого набора используют разные подходы, в том числе обработку с помощью нейронных сетей.

Поддержка работы с векторами появилась в PostgreSQL и других традиционных СУБД, но существуют и специализированные базы данных, хранящие их в форме векторов, например, Pinecone, Vespa, Milvus и др. Механизмы обработки запросов в таких СУБД способны выдавать не только точные соответствия, но и близкие или наиболее подходящие, словно «угадывая» намерение пользователя. Если раньше для реализации подобных возможностей применялись самостоятельные приложения, то теперь соответствующие алгоритмы встраиваются непосредственно в СУБД. В частности, Oracle предлагает такие решения, адаптированные для различных отраслей, например, для интернет-магазинов.

В традиционных СУБД формируются индексы, ускоряющие поиск информации по конкретным столбцам. Векторные же позволяют создавать индексы, охватывающие весь объем данных и позволяющие легко находить «близкие» друг к другу векторы. К тому же запросы к таким базам можно делать на естественном языке, а не на SQL.

Средства ИИ также применяются для автоматической классификации неструктурированных данных и размещения их в таблицах СУБД. Алгоритмы могут упорядочивать информацию, фильтровать «шум», классифицировать текст по эмоциональной окраске или фотопортреты по выражению лица. Сервисы классификации данных и автоматического размещения в базах предлагает, например, компания Amazon Web Services.

Оптимизация производительности традиционных СУБД — сложная задача, связанная с настройкой многочисленных параметров и схем. Обычно этим занимается администратор базы данных, но теперь оптимизацию могут выполнять алгоритмы машинного обучения, учитывающие закономерности запросов и структур данных. Они могут следить за трафиком на сервере, адаптировать настройки в зависимости от нагрузки в режиме реального времени и прогнозировать потребности пользователей. В Oracle стали позиционировать свои СУБД в качестве автономных и не требующих администратора, так как они с помощью алгоритмов ИИ сами регулируют свою производительность «на лету».

ИИ может помогать в очистке данных: алгоритмы способны обнаруживать аномалии и предлагать корректировки. Автоматизированная система, к примеру, может найти неверно записанную фамилию клиента и исправить на правильный вариант с учетом остальных вхождений. Microsoft для своей СУБД SQL Server предлагает решение Data Quality Services, которое автоматически устраняет проблемы наподобие незаполненных полей, дублирующихся вхождений и др.

Алгоритмы ИИ, регистрирующие аномалии в данных, позволяют превратить СУБД в систему обнаружения мошенничества. Например, если кто-то впервые для себя воспользовался банкоматом поздно ночью или кредиткой в чужой стране, это может быть сигналом, на который среагирует подобная система. Возможности интеграции механизмов обнаружения мошенничества в стек ПО для работы с данными предлагает, например, облако Google.

Похожие алгоритмы применяются в организациях для нужд безопасности: ИИ способен обнаруживать отклонения от стандартных закономерностей работы с СУБД, могущие указывать на попытку взлома. Например, если пользователь удаленно запрашивает полные копии каких-либо таблиц, это повод забить тревогу. Пример инструмента, интегрируемого с уровнями хранения данных для управления доступом и регистрации аномалий, — IBM Guardian Security.

Итак, ИИ обучается на данных, хранимых непосредственно в СУБД, и позволяет делать к ним запросы на естественном языке. Чатботы вроде ChatGPT, Bard и Bing Chat сегодня претендуют на роль альтернативы традиционным системам веб-поиска, а возможна ли замена СУБД на подобный сервис? ИИ нередко «галлюцинирует», выдавая «выдуманные» ответы, или меняет формат выдачи по своей «прихоти». Но если предметная область достаточно узкая, а обучающая выборка по ней была исчерпывающей и свободной от ошибок, то для каких-то из задач ИИ вполне мог бы с успехом заменить и СУБД.

Эволюция архитектур баз данных — прямое следствие неумолимого технологического прогресса. Движение от жестких структур традиционных РСУБД к гибким решениям NoSQL БД и масштабируемым облачным решениям обусловлено потребностями в более интенсивном и эффективном использовании данных. Более того, интеграция ИИ в разы расширяет функциональность БД, давая тем самым «зеленый свет» более интеллектуальным и автоматизированным решениям по управлению данными. В будущем внедрение инновационных технологий будет играть важнейшую роль в формировании следующего поколения архитектур баз данных.

Вопрос поставлен некорректно. Протокол RDP, как и терминальный сервер — это технологии, используемые в продукте VDI. VDI не есть альтернатива RDP, поэтому сравнивать их не корректно. Одного не бывает без другого.

Под пользователем я имею в виду обычного юзера. В чём принципиальное отличие VDI от банального терминального сервера с RDP? При условии, что обе аббревиатуры развёрнуты на своем якобы дорогостоящем оборудовании или в вашей инфраструктуре? То есть VDI vs. RDP, без продажной шелухи.

С точки зрения пользователя отличия огромные, как минимум из-за отсутствия необходимости содержать собственную дорогостоящую серверную. Напомню, что в случае VDI используется провайдерская инфраструктура и провайдерское администрирование.

Ну а в чём, с точки зрения пользователя?