DZone.com Feed на русском Заметка

DZone.com Feed на русском

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

Трэд заметок

Суть предложения Foundry IQ заключается в том, что ваши агенты получают единую конечную точку для обоснованного, цитируемого, многоисточникового контекста вместо самодельного стека поиска. То, о чем недостаточно говорят, это то, что "единая конечная точка" — это некоторое упрощение. Под ней вы фактически управляете четырьмя отдельными поверхностями аутентификации, которые не имеют общей модели безопасности: плоскостью управления, которую вы используете для предоставления ресурсов, учетными данными для каждого источника знаний, которые различаются в зависимости от типа источника, аутентификацией соединения между базой знаний и вызывающим ее агентом, и, что люди чаще всего упускают из виду, уважает ли сам контент разрешения запрашивающего.Если вы допустите ошибку на любой из этих поверхностей, вы обычно не получите ошибку. Вы получите агента, который уверенно отвечает на вопросы, используя данные, которые запрашивающий пользователь никогда не должен был видеть. Это практическое руководство по развертыванию реального Foundry IQ, источников знаний, базы знаний, а также агента Foundry и агента Microsoft Agent Framework, основанных на ней, с акцентом на правильную настройку каждой из этих четырех поверхностей аутентификации, вместо использования ключа администратора, который работает в кратком руководстве.
Спустя пятнадцать лет разговор, который я чаще всего веду с руководителями служб безопасности, по-прежнему начинается одинаково: как ваша периметрия, как ваше покрытие конечных точек, как укомплектован ваш SOC? Почти никто не начинает с вопроса "как ваш пайплайн". Именно об этом разрыве я хочу поговорить, потому что 2025 год стал годом, когда этот разрыв превратился в пропасть.Вот цифра, которая должна пересмотреть каждую дорожную карту безопасности на 2026 год: крупные DevOps-платформы — GitHub, GitLab, Azure DevOps, а также Jira и Bitbucket от Atlassian — исправили 236 уязвимостей в 2025 году, согласно отчету GitProtect "DevOps Threats Unwrapped". Из них 59% были оценены как высокие или критические: 14 критических, 126 высоких, 75 средних, 21 низкая. Тенденция хуже, чем общее количество. Критические уязвимости подскочили с 4 в первой половине года до 10 во второй. Высокосерьезные находки выросли на 55%, с 39 до 87 за тот же период. Только в ноябре 2025 года было обнаружено 36 исправленных уязвимостей — 15% от общего годового показателя за один месяц. Это не малоизвестные внутренние инструменты. Один только GitHub объединяет более 180 миллионов разработчиков в 630 миллионах репозиториев. Когда платформы, хранящие такой объем кода, ускоряют раскрытие уязвимостей квартал за кварталом, это не просто шум. Это тенденция с направлением (DevOps.com, SecurityBrief).
Развертывания становятся сложнее, когда один релиз изменяет как механизмы, управляющие платформой Kubernetes, так и зависящие от них рабочие нагрузки. Новое определение пользовательских ресурсов (CustomResourceDefinition), вебхук приема, контроллер или API маршрутизации могут изменить то, что принимает кластер и как он себя ведет; новый образ приложения может одновременно зависеть от этих изменений. Argo CD и Argo Rollouts решают разные части этой проблемы.Argo CD подходит для установления декларативных предварительных условий в детерминированном порядке, в то время как Argo Rollouts ограничивает воздействие на производство по мере того, как версия рабочей нагрузки приближается к стабильной. Безопасная доставка достигается путем комбинирования этих обязанностей, а не рассмотрения любого контроллера как универсального механизма развертывания. Документация Argo Rollouts явно не рекомендует использовать Rollouts для инфраструктурных компонентов, таких как cert-manager, CoreDNS и NGINX.
В предыдущей статье "Работа с электронными таблицами в Java: Практический обзор" мы рассмотрели распространенные сценарии взаимодействия Java-приложений с электронными таблицами и категории доступных для этой задачи инструментов. Одним из упомянутых там факторов была поддержка современных формул Excel — тема, заслуживающая большего внимания, чем один пункт списка.Java-приложения взаимодействуют с Excel чаще, чем большинство команд планируют: загрузка файлов из финансовых отделов, логика расчетов, созданная в книге, экспорт отчетов для бизнес-пользователей. Файлы, которые эти пользователи создают сегодня, отличаются от тех, что они создавали пять лет назад. Excel 365 и Excel 2021 представили новую модель формул, и книги, созданные в этих версиях, регулярно ее используют. В зависимости от используемой библиотеки, эти формулы могут вычисляться корректно, молчаливо завершаться с устаревшими кэшированными значениями или вызывать исключения во время пересчета.
Вы можете понять, когда электронное письмо было написано LLM. Начало "Надеюсь, это письмо застанет вас в добром здравии", три вежливых абзаца, отвечающих на однострочный вопрос. Мне нужен был агент для составления ответов, который этого не делал, и "не звучай как ИИ" оказалось трудно сформулировать в запросе. Запретить несколько фраз легко. Остальное — это суждение, и один запрос, который подходит как для приглашения на дружеский ужин, так и для холодного письма от рекрутера, потребовал больше итераций, чем я предполагал.Это не только проблема электронной почты. Некоторые платформы понижают рейтинг контента, который воспринимается как сгенерированный ИИ, поэтому команды, публикующие материалы в больших объемах, действительно заинтересованы в прозе, которая проходит детектор, даже когда ее написал человек. Рабочий процесс здесь применим к любому из этого.
При запуске веб-приложения разработчики стремятся быстро и недорого реализовать необходимый функционал: бюджеты все еще ограничены, команды небольшие, а ресурсы скудны. Эти команды часто обращаются к инструментам с открытым исходным кодом для добавления функциональности просмотра PDF, и эти библиотеки работают: они предоставляют основы с простой интеграцией и нулевой стоимостью.Однако, независимо от того, являетесь ли вы стартапом или устоявшейся организацией, создающей новый функционал на платформе с большой существующей пользовательской базой, библиотеки с открытым исходным кодом могут стать своего рода "обезьяньей лапкой": они исполнили ваше желание, но боль приходит позже. В случае с функциональностью обработки документов эта боль проявляется в виде "ада интеграции", поскольку вам приходится добавлять больше возможностей для работы с документами одну за другой, и возможности и зависимости всех интегрированных вами библиотек с открытым исходным кодом начинают давать трещины. Обслуживание растет, пользовательский опыт страдает, и разработчики тихонько прикладывают лоб к столу.
Ландшафт корпоративного программного обеспечения претерпевает фундаментальный архитектурный сдвиг, сравнимый с первоначальным переходом от монолитных приложений к распределенным системам. В течение последнего десятилетия архитектура микросервисов успешно позволяла инженерным командам управлять сложностью приложений путем строгого разделения бизнес-доменов на независимо развертываемые, масштабируемые единицы, взаимодействующие через четко определенные программные интерфейсы приложений (API).Однако агрессивная интеграция больших языковых моделей (LLM) в слой выполнения приложений катализировала совершенно новую парадигму: архитектуру агентных микросервисов. В этой продвинутой модели основной принцип единственной ответственности эволюционирует от разделения статических бизнес-доменов (таких как Сервис Заказов или Сервис Платежей) к разделению динамических когнитивных нагрузок (таких как Агент Планирования, Агент Исследований и Агент Выполнения).
Я наткнулся на этот шаблон, когда создавал агентов с помощью Deep Agents, наблюдая, как реестр инструментов разрастается до точки, когда отправка каждой схемы в каждом ходе перестает иметь смысл. Далее следует сам шаблон, упрощенный так, чтобы он мог быть интегрирован в любой цикл агента, вызывающего инструменты, независимо от фреймворка, подкрепленный тестом на синтетическом реестре из 61 инструмента. Проблема: Количество инструментов растет, релевантность за ход — нет.Большинство фреймворков агентов собирают список инструментов один раз во время создания и отправляют его целиком модели при каждом вызове, независимо от того, о чем идет речь в данном ходе. Это нормально при 5-10 инструментах. Как только вы подключаете несколько серверов MCP (Slack, GitHub, Linear, календарь, CRM, каждый из которых предоставляет 3-6 схем), каждый ход начинает нести 40-60 определений инструментов, независимо от того, спрашивал ли пользователь о сообщении в Slack или нет.
Любой, кто пытался создать небольшую, реалистичную тестовую базу данных на основе производственной схемы, знает, как это бывает: вам нужны не просто "все заказы". Вам нужны заказы клиента, позиции его заказов, продукты, на которые они ссылаются — но не вся история платежей, не каждая строка журнала аудита, не таблицы внутренней отчетности, находящиеся в трех соединениях. Каждая таблица, которую вы извлекаете по одной причине, тянет за собой еще три, о которых вы не просили, потому что ваша схема — это граф, а не список.Jailer решает механическую половину этой проблемы: дайте ему начальную таблицу, условие и набор правил для следования отношениям, и он пройдет по графу внешних ключей и вернет вам согласованный, ссылочно-валидный срез базы данных. То, что он не решал до недавнего времени, — это утомительная половина: сесть и решить, ассоциация за ассоциацией, что включить, а что отбросить. На схеме с несколькими сотнями таблиц это не пятиминутная задача.
Фреймворк DORA построен на настолько фундаментальной предпосылке, что редко подвергается анализу. Когда исследовательская группа, стоящая за ним, изучила тысячи инженерных организаций и определила метрики, предсказывающие производительность доставки программного обеспечения, они измеряли то, что сообщают конвейеры. Частота развертываний из журналов развертываний. Время выполнения от временных меток коммитов. Частота сбоев изменений из записей об инцидентах, связанных с событиями развертывания. Время восстановления после неудачного развертывания из временных меток разрешения инцидентов. Частота переделок развертываний из доли развертываний, потраченных на исправление ранее выпущенной работы.Каждая из этих метрик является точной записью того, что, по словам конвейера, произошло. Ни одна из них не имеет механизма для оценки того, было ли то, что, по словам конвейера, произошло, точным.
Через несколько месяцев после начала серьёзного внедрения RAG большинство инженерных команд сталкиваются с той же стеной. Наша демонстрация платежного ассистента на базе искусственного интеллекта прошла прекрасно. Пилот с двадцатью внутренними пользователями сработал прекрасно. Затем он запускается, кто-то задаёт вопрос о медицинских льготах или о банковском переводе, который не удался, модель уверенно что-то придумывает, и вдруг «чат-бот» становится словом, которое никто из команды не хочет слышать в посмертном анализе. Решение — не более умный запрос. Это архитектура, которая предполагает, что модель иногда будет ошибаться, иногда её спрашивают на что-то, на что она не должна отвечать, и иногда приходится полностью уходить в сторону и передавать человека человеку. Вот как бы я структурировал эту систему, если бы строил её сегодня.
Корпоративное программное обеспечение все чаще требует от пользователей выполнять множество ролей. Инженер по безопасности, который управляет контролем доступа сегодня, завтра занимается реагированием на инциденты. Операционная команда, которая автоматизирует рутинные развертывания, также должна справляться с разовыми исключениями в инфраструктуре. Эти редкие, когнитивно сложные задачи попадают в неловкую нишу: слишком редкие для мышечной памяти, но слишком важные, чтобы полагаться на догадки.Традиционный корпоративный UX предлагает два неудовлетворительных решения: создание громоздких форм, которые пользователи должны каждый раз переучивать, или направление работы через цепочки согласований, которые превращают минуты в дни. Протокол контекста модели (MCP) в сочетании с интерфейсами на основе агентских больших языковых моделей предлагает третий путь — особенно привлекательный для управления контролем доступа и подобных областей, где задачи редки, но имеют высокие ставки.
Девять секунд. Именно столько времени потребовалось агенту по написанию кода на базе ИИ, чтобы удалить производственную базу данных и ее резервные копии у PocketOS, поставщика программного обеспечения для аренды автомобилей, в апреле 2026 года. По словам основателя Джера Крейна, агент по написанию кода на базе ИИ столкнулся с несоответствием учетных данных во время обычной задачи на этапе тестирования, просмотрел кодовую базу и нашел токен API в несвязанном файле. Этот токен предоставлял неограниченные разрешения через API инфраструктуры Railway. Агент использовал токен. База данных и резервные копии были удалены до того, как кто-либо заметил.Никто не атаковал PocketOS. Никакие учетные данные не были украдены, не было выполнено внедрение подсказок, не было запущено вредоносное ПО. Агент преследовал цель, столкнулся с препятствием и использовал предоставленные ему полномочия для его устранения. Проблема не в том, что агент мог удалить производственную базу данных. Проблема в том, что ничто в архитектуре авторизации не помешало ему сделать это — для задачи, которая вообще не должна была касаться производства. В этом заключается различие, на котором строится вся эта дисциплина, и именно поэтому исправление должно находиться в архитектуре, а не в системной подсказке, говорящей агенту быть осторожным.
Параллельные кодирующие агенты создают проблему параллелизма раньше, чем принесут пользу в производительности. Два автономных процесса, редактирующих одну и ту же корзину, могут перезаписывать файлы, нарушать предположения, загрязнять состояние тестов или производить изменения, которые по отдельности корректны, но совместно несовместимы.Более безопасная операционная модель рассматривает каждого агента как изолированного участника с выделенным рабочим деревом Git, явным контрактом на уровне файлов, детерминированными командами валидации и без права прямой интеграции в защищенную ветку. Рабочие деревья Git предоставляют несколько связанных рабочих деревьев для одного репозитория, в то время как современные платформы кодирующих агентов независимо подкрепляют тот же принцип через изолированные песочницы, ограниченный доступ на запись и контролируемые сетевые разрешения.
Сегодня платформы потоковой обработки данных облегчают анализ в реальном времени данных, непрерывно поступающих от устройств Интернета вещей (IoT), финансовых транзакций, веб-приложений и серверов в банках, производственного оборудования, логистических систем на складах и судах, а также действий клиентов с помощью диалоговых агентов на веб-порталах. Фреймворки потоковой обработки, такие как Apache Kafka, Apache Flink, Apache Spark Structured Streaming и потоковые базы данных, позволяют специалистам обрабатывать миллионы событий в реальном времени.Но ценность вашей платформы потоковой обработки полностью зависит от качества данных, поступающих в нее. Неправильно сформированное событие, дублирующееся сообщение, отсутствующее поле или недействительная временная метка могут привести к некорректной генерации аналитики, ложным срабатываниям оповещений, всплескам оповещений и даже сбоям приложений. Пакетная обработка позволяет очищать данные перед выполнением, но потоковая обработка требует, чтобы проверка и исправления происходили во время потока данных. Таким образом, разработка надежной стратегии качества данных является основной необходимостью любой событийно-ориентированной архитектуры.
В большинстве программных продуктов красный тест означает ошибку. В системах, над которыми я работаю, красный тест может быть сигналом о безопасности пациента. Это одно отличие меняет почти каждое решение, которое вы принимаете, когда садитесь разрабатывать стратегию качества.Я провел более десяти лет в области качества программного обеспечения, большая часть из них — в области программного обеспечения для медицинских устройств: роботизированная хирургия, хирургическое моделирование и платформы клинического образования. Инженерия сама по себе интересна. Что делает ее по-настоящему сложной, так это то, что каждый тест, каждый конвейер и каждый выпуск должны одновременно удовлетворять две аудитории. Инженеры хотят быстрой обратной связи. Регуляторы хотят отслеживаемых доказательств того, что программное обеспечение делает именно то, что указано в его требованиях, и ничего опасного вдобавок.