Author: admin

Если вы постоянно слышите про Apache Kafka, но до конца не понимаете, что это и почему о ней так много говорят — эта статья наконец расставит всё по местам.
Мы разберём Kafka на реальных примерах, используя вымышленное e-commerce приложение StreamStore, и посмотрим, как Kafka решает боль, с которой сталкиваются почти все современные архитектуры.

Проблема: когда микросервисы превращаются в домино

В нашем StreamStore есть микросервисы:

• заказы

• платежи

• склад

• уведомления

• аналитика

Когда пользователь оформляет заказ, в системе запускается целая цепочка действий:

• уменьшается складской остаток

• клиенту отправляется email

• создаётся счёт

• обновляется панель продаж

• обновляется статистика выручки

Мы — маленький стартап, поэтому в начале делаем всё максимально просто:
микросервисы напрямую вызывают друг друга.

Order → Payment → Inventory → Notification → Analytics

И всё работает… пока не наступает Чёрная Пятница.

Внезапно:

• приложение начинает тормозить

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

• сервисы падают под нагрузкой

• продажи теряются каждую минуту

• архитектура превращается в хаос

Что же произошло?

Почему прямое взаимодействие микросервисов ломается

1. Жёсткая связность

Если сервис платежей падает — весь процесс оформления заказа встаёт.

2. Синхронные вызовы

Каждый шаг ждёт следующий — как длинная цепочка домино.
Один медленный сервис → всё замедляется.

3. Точки отказа

10 минут простоя склада = 2 часа накопившихся заказов.

4. Потерянные данные

Аналитика упала на час → потерян час данных о продажах.

Нам нужна архитектура, где события проходят через систему
естественным потоком, а не в виде бесконечных цепочек вызовов.

Решение: Kafka как “почтовое отделение” системы

Вместо того чтобы сервисы дергали друг друга напрямую, мы добавляем брокер — посредника между ними.

Kafka = почтовая служба для микросервисов:

• Отправитель (Order Service) кладёт “пакет” (event)

• Почта (Kafka) принимает и сохраняет его

• Получатели (Inventory, Notification, Payments и т.д.) забирают, когда готовы

Никакого ожидания. Никаких прямых вызовов. Никаких зависаний.

Producers и Events: как данные попадают в Kafka

Order Service становится producer-ом.
Он создаёт событие:

“Создан заказ: клиент X, товары Y, детали Z.”

И отправляет его в Kafka.

Событие — это обычный объект с ключом, значением и метаданными.

После отправки сервис не ждёт, получил ли кто-то это сообщение.
Он просто продолжает работу.

Где хранятся события? Kafka Topics

Kafka сортирует события в топики — как отдельные очереди в почте:

• orders

• payments

• inventory

• notifications

Ничего не складывается в одну огромную “кашу”.
Топики создаёте вы — как схемы в базе данных.

Consumers: сервисы, которые реагируют на события

Когда в orders появляется событие “создан заказ”, подписчики получают его:

• Notification Service → отправляет письмо

• Inventory Service → уменьшает остаток

• Payment Service → создаёт счёт

• Analytics Service → обновляет статистику

Каждый работает в своём темпе, независимо от других.

Kafka — это база данных? Нет, и вот почему

Kafka сохраняет события, но не заменяет основную БД.

Например:

• Склад обновляет остатки в базе

• Но также создаёт событие изменения склада, чтобы:

  • сработали оповещения о низком остатке

  • сервис авто-дозаказа сделал новый заказ

  • аналитика могла работать в реальном времени

Kafka — это не состояние.
Kafka — это история изменений.

Real-Time обработка: Kafka Streams

Некоторым приложениям нужно постоянное обновление:

• realtime панель продаж

• локации водителей в Uber

• постоянная проверка порогов склада

Для такого Kafka предлагает Streams API — потоковую обработку событий.

Streams работают не “по одному”, а непрерывным потоком.

Масштабируемость Kafka: Partitions

Kafka масштабируется благодаря партициям.

Представьте:
в почтовом отделении добавили больше сотрудников в каждый отдел:

• письма в Европу → сотрудник A

• письма в США → сотрудник B

• письма в Азию → сотрудник C

В Kafka так же:

• orders-eu

• orders-us

• orders-asia

Разные продюсеры могут писать в разные партиции параллельно.

Ускоряем: Consumer Groups

Если один сервис не успевает обрабатывать поток данных — запускаем несколько его копий.

Kafka автоматически:

• объединяет их по group ID

• распределяет партиции между ними

• перераспределяет нагрузку, если одна копия падает

Это обеспечивает горизонтальное масштабирование “вширь”.

Где физически хранится информация? Kafka Brokers

Kafka работает на кластере серверов — broker-ов.

Брокеры:

• хранят данные на дисках

• принимают запросы

• реплицируют данные друг другу

• обеспечивают отказоустойчивость

Kafka хранит события столько, сколько вы укажете в retention policy.

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

Kafka vs классические очереди: Netflix vs ТВ

Обычная очередь — как телевизор:

• смотрите то, что показывают

• в тот момент, когда показывают

• пропустили — всё, потеряли

Kafka — как Netflix:

• смотрите что хотите

• когда хотите

• в своём темпе

• можно пересматривать

Именно эта гибкость делает Kafka уникальной.

Прощай, ZooKeeper: привет, KRaft

Раньше Kafka использовала ZooKeeper для координации.
Сегодня современные версии используют KRaft, встроенную систему управления.

Это упрощает конфигурацию и уменьшает количество зависимостей.

Вывод

Kafka — это не просто message broker.
Это мощная платформа для потоковой обработки данных, которая решает:

• жёсткую связность

• проблемы синхронных вызовов

• потерю данных

• невозможность анализировать данные в реальном времени

• проблемы масштабирования

Если эта статья помогла вам наконец понять Kafka — поделитесь ею с коллегой, которому она тоже пригодится.

Новая эра для разработчиков

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

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

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

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

Почему этот сдвиг особенный

Мир технологий всегда менялся стремительно — новые версии, новые фреймворки, новые подходы.
Но этот раз — другой.

Дело не просто в изучении ещё одного инструмента или синтаксиса.
Это про переопределение роли разработчика в самом процессе разработки.

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

Вот четыре ключевых навыка, которые сделают вас незаменимыми в эпоху ИИ.

1. Развивайте архитектурное мышление

Когда вашей команде нужно масштабировать приложение под нагрузку в 10 раз больше текущей, младший разработчик бросается оптимизировать запросы к БД. Средний — ищет балансировщики нагрузки.

А архитектор делает шаг назад и задает другие вопросы:

• Подходит ли наша архитектура для таких масштабов?

• Может, пора разбить монолит на микросервисы?

• Не стоит ли пересмотреть подход к хранению данных?

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

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

Архитектурное мышление — это фундамент всего остального. И по мере того как ИИ всё лучше пишет код, ценность стратегических инженеров только растёт.

2. Освойте DevOps и облачные технологии

После принятия архитектурных решений наступает время их реализации — эффективно и безопасно.

И здесь на сцену выходят DevOps и cloud-native технологии.

Современному инженеру нужно понимать:

• Контейнеризацию (Docker) для консистентных сред.

• Kubernetes — для автоматического масштабирования и отказоустойчивости.

• Infrastructure as Code — для надёжных и воспроизводимых инфраструктур.

• CI/CD-пайплайны — для непрерывной доставки.

DevOps — это не просто набор инструментов.
Это создание системы, которая постоянно доставляет ценность пользователю.

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

Компании сегодня ищут именно таких инженеров — тех, кто строит экосистемы надёжности и скорости, а не просто пишет код.

3. Думайте о бизнес-результатах, а не только о технологии

Вот ключевое различие между хорошими и выдающимися инженерами:
Хорошие — создают работающие решения.
Выдающиеся — показывают измеримый бизнес-эффект.

Сравните:

Сценарий 1:

«Мы разбили монолит на микросервисы и задеплоили в Kubernetes».

Сценарий 2:

«Новая архитектура сократила время отклика с 700 до 150 мс, снизила нагрузку на базу на 65 % и сэкономила компании $5 000 в месяц, одновременно повысив безопасность».

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

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

4. Научитесь эффективно работать с ИИ

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

Не бойтесь автоматизации — интегрируйте ИИ в свои процессы:

• Пусть он пишет шаблонный код.

• Генерирует тесты или документацию.

• А вы сосредоточьтесь на проверке, адаптации и архитектуре.

Такое сочетание — скорость ИИ + человеческое суждение — даёт колоссальное преимущество.

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

Пример: масштабирование приложения

Как работают все четыре навыка вместе:

1. Архитектурное мышление — вы решаете перейти с монолита на микросервисы с кэшем и новой структурой данных.

2. DevOps-навыки — вы контейнеризируете сервисы, настраиваете CI/CD и деплой в Kubernetes.

3. Фокус на бизнес-эффекте — вы показываете, что это снижает задержки на 70 %, экономит $5 000 и улучшает UX.

4. ИИ-коллаборация — вы ускоряете реализацию, используя ИИ для шаблонного кода и тестов.

В итоге вы не просто программист, а технический стратег, двигающий бизнес вперёд.

На протяжении многих лет экосистема open source в .NET сталкивается с проблемой устойчивости. В отличие от таких сообществ, как Node.js, многие разработчики .NET используют пакеты NuGet, но у них нет простого способа напрямую поддерживать их авторов. Однако у Microsoft есть все возможности изменить это и сделать экосистему действительно жизнеспособной.

Опыт npm — и как можно сделать лучше

Недавно NuGet представил функцию, аналогичную npm fund, которая позволяет пользователям поддерживать авторов пакетов. npm внедрил её ещё в 2019 году, и NuGet понадобилось шесть лет, чтобы догнать. Но вместо того чтобы считать это запоздалым повторением, Microsoft может пойти дальше и предложить нечто большее.

NuGet работает в другой среде. Его пользователи — это не только энтузиасты, но и корпоративные разработчики, использующие Visual Studio по подписке. Компании уже платят немалые деньги — от $50 в месяц за Professional до сотен долларов за Enterprise.

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

Идея №1: Распределение доходов для авторов пакетов NuGet

Microsoft могла бы выделять, например, 10% дохода от подписок Visual Studio и распределять их между проверенными авторами пакетов NuGet. Распределение могло бы быть пропорциональным популярности пакетов, аналогично тому, как Spotify платит артистам или YouTube Premium — авторам контента.

Система могла бы работать полностью автоматически. Разработчикам не пришлось бы управлять донатами вручную — они просто получали бы свою долю за вклад в экосистему.

Представьте, что при установке пакета в Visual Studio появляется сообщение:

«Часть вашей подписки Visual Studio направляется на поддержку этого разработчика.»

Это вызвало бы доверие и сделало бы разработку open source в .NET действительно устойчивой.

Идея №2: Встроенная покупка лицензий в NuGet

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

Решение — интеграция NuGet с Azure Marketplace. У Microsoft уже есть зрелая система оплаты. Связав NuGet с Azure Marketplace, компании смогут покупать лицензии прямо из Visual Studio или через свою подписку Azure.

Например:

• Пакет бесплатен до 5 разработчиков.

• При подключении шестого пользователя из той же организации Entra система уведомляет менеджера и предлагает оплатить лицензию.

• Менеджер добавляет оплату напрямую в счёт Azure.

Это просто, прозрачно и создаёт понятную модель дохода для авторов.

Мягкий “paywall” и защита лицензий

Microsoft уже обладает мощной системой аудита лицензий. Если связать использование NuGet с учетными записями Visual Studio и Entra, компании смогут автоматически защищать себя от случайных нарушений лицензий.

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

Результат: устойчивая экосистема .NET

Если Microsoft реализует подобные идеи, экосистема .NET станет действительно устойчивой. Разработчики смогут получать справедливое вознаграждение за свои проекты, а новые специалисты будут охотнее присоединяться, понимая, что open source в .NET может приносить доход.

Это приведёт к:

• Более активному сообществу

• Качественным и регулярно обновляемым пакетам

• Росту доверия и лояльности к платформе .NET и Microsoft

Open source нуждается не только в энтузиазме, но и в структуре, признании и поддержке. С правильной моделью финансирования и лицензирования .NET сможет наконец обрести здоровую, живую экосистему.

Microsoft Copilot Studio позволяет создавать интеллектуальных агентов, которые могут взаимодействовать через разные каналы, такие как Microsoft Teams, SharePoint, Slack или Microsoft 365 Copilot Chat.
В этом руководстве показано, как создать, опубликовать и развернуть агента именно в Microsoft 365 Copilot Chat.

Шаг 1: Создание агента в Microsoft Copilot Studio

Сначала откройте Microsoft Copilot Studio и создайте нового агента.
В нашем примере это будет простой агент под названием «Climate Agent».

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

Пример темы

• Название темы: Humidity

• Триггер: Когда пользователь спрашивает о влажности

• Ответ: «Влажность составляет 90%.»

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

Шаг 2: Публикация агента

После настройки темы:

1. Нажмите Publish в Copilot Studio.

2. Дождитесь завершения публикации.

3. Протестируйте агента в тестовом чате, введя «humidity».

Если ответ отображается правильно, агент работает корректно.

Шаг 3: Настройка аутентификации

Перед развертыванием необходимо настроить параметры безопасности.

1. Перейдите в Settings → Security → Authentication.

2. Выберите Authenticate with Microsoft.

Этот параметр включает аутентификацию через Microsoft Entra ID (Azure AD), которая обязательна для публикации агента в Microsoft 365 Copilot, Teams или SharePoint.

Шаг 4: Развертывание агента в Microsoft 365 Copilot

1. Откройте раздел Channels в Copilot Studio.

2. Выберите Teams and Microsoft 365 Copilot.

3. Установите флажок “Make agent available in Microsoft 365 Copilot.”

4. Нажмите Add Channel.

Таким образом, агент будет опубликован сразу для двух платформ — Teams и Microsoft 365 Copilot.

Шаг 5: Настройка внешнего вида и информации об агенте

После публикации можно персонализировать агента:

• Изменить цвет: выберите подходящую тему.

• Изменить иконку: загрузите PNG-файл размером менее 32 KB.

• Добавить описание:

  • Краткое описание: «Агент климата, показывающий влажность.»

  • Подробное описание: можно добавить больше деталей или примеров использования.

• Указать разработчика: добавьте имя, сайт и при необходимости партнёрский ID (MPN).

Сохраните изменения, нажав Save.

Шаг 6: Проверка развертывания в Microsoft 365 Copilot

Чтобы убедиться, что агент опубликован:

1. Перейдите на сайт m365.cloud.microsoft.com.

2. Откройте интерфейс Copilot Chat.

3. В разделе All Agents найдите ваш Climate Agent.

4. Нажмите Add, чтобы добавить его в рабочее пространство.

После этого можно начать использовать агента прямо в Microsoft 365 Copilot Chat.

Шаг 7: Тестирование агента

Когда агент добавлен:

• Откройте Microsoft 365 Copilot Chat.

• Введите команду «humidity».

• Агент ответит: «Влажность составляет 90%.»

Интерфейс здесь выглядит гораздо профессиональнее, чем тестовая среда в Copilot Studio — это уже финальный пользовательский интерфейс.

Шаг 8: Использование агента в Teams и Copilot

Так как агент опубликован сразу в Teams и Microsoft 365 Copilot, он также доступен в Microsoft Teams в разделе Apps. Вы можете закрепить его или удалить при необходимости.

Заключение

Следуя этому руководству, вы сможете:

• Создать агента в Microsoft Copilot Studio;

• Настроить аутентификацию через Microsoft;

• Опубликовать его в Microsoft 365 Copilot Chat и Teams.

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

Поскольку мы говорим об Azure Front Door (AFD), стоит упомянуть сбой, который произошёл 29 октября.

Для тех, кто не знаком с AFD: это глобальный балансировщик нагрузки уровня 7 (Layer 7). Он имеет множество точек присутствия (PoPs) по всему миру.

Как это работает:

• Клиент подключается к ближайшей точке присутствия.

• Используется Split TCP, который завершает TLS-сессию локально для более быстрой реакции.

• AFD получает контент из здорового (работающего) бэкенда.

• Поддерживает кэширование и интеграцию с Web Application Firewall (WAF).

Эта служба широко используется как сервисами Microsoft (например, Office 365, Xbox, Entra), так и сторонними поставщиками.

Причина сбоя и решение

Сбой был вызван изменением конфигурации тенанта, которое случайно создало некорректное состояние конфигурации, из-за чего большое количество узлов стало «нездоровыми».

В результате снизилась пропускная способность обработки запросов. Исправление заключалось в откате к последней корректной конфигурации, что заняло несколько часов.

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

Что могут сделать клиенты

С архитектурной точки зрения — как можно самостоятельно минимизировать риски?

Azure Front Door — это глобальный балансировщик нагрузки, но в качестве резервного варианта можно рассмотреть Azure Traffic Manager.
Однако следует учитывать:

• Traffic Manager основан на DNS;

• Он не поддерживает WAF, кэширование или Split TCP;

• Не работает с приватными конечными точками или непубличными сервисами.

Таким образом, хотя это не полноценная альтернатива, Traffic Manager может служить «аварийным решением» в чрезвычайных ситуациях.

Microsoft серьёзно инвестирует в предотвращение подобных инцидентов, поскольку они влияют не только на клиентов, но и на собственные сервисы компании — M365, Minecraft и другие.

C# 14 принес с собой множество обновлений, делающих код чище, безопаснее и выразительнее. После тестирования я выделил пять лучших нововведений, хотя одно из них вызывает у меня сомнения. Давайте разберём всё по порядку.

1. Null-условное присваивание

В предыдущих версиях, например C# 13, приходилось вручную проверять объект на null перед присвоением значений свойствам:

if (channel != null) channel.Subscribers = 1000;

Рабочий, но громоздкий вариант.

Теперь, в C# 14, можно использовать null-условное присваивание, что делает код гораздо лаконичнее:

channel?.Subscribers = 1000;

Эта запись безопасно выполнит присваивание только если channel не равен null. Чисто и просто.

2. Ключевое слово field для резервных полей

Ранее при работе со свойствами вы наверняка использовали приватные резервные поля:

private int _subscribers;
public int Subscribers
{
get => _subscribers;
set => _subscribers = value;
}

В C# 14 появилось ключевое слово field, позволяющее избавиться от лишних переменных:

public int Subscribers
{
get => field;
set
{
if (value < 1000)
throw new Exception("Недостаточно подписчиков!");
field = value;
}
}

Теперь код выглядит компактнее, а вы всё так же можете добавлять нужную логику в setter.

3. Пользовательские составные операторы

Эта функция действительно впечатляет. В C# 14 появились пользовательские составные операторы, с помощью которых можно переопределять такие операторы, как + или ++ для своих классов.

Пример

public static Channel operator +(Channel c)
{
c.Subscribers++;
c.Members++;
return c;
}

Теперь достаточно просто написать:

channel++;

И оба свойства — Subscribers и Members — увеличатся автоматически. Просто и красиво.

4. Новый ключевой оператор extension

Методы-расширения давно стали неотъемлемой частью C#, но их синтаксис выглядел немного устаревшим. Раньше это выглядело так:

public static class ChannelExtensions
{
public static void PrintDetails(this Channel channel)
{
Console.WriteLine($"Subs: {channel.Subscribers}, Members: {channel.Members}");
}
}

Теперь в C# 14 можно использовать новое ключевое слово extension напрямую при определении расширения:

public extension Channel
{
public void PrintDetails()
=> Console.WriteLine($"Subs: {Subscribers}, Members: {Members}");
}

Работает так же, только выглядит современнее.
Правда, у меня к этой функции двоякое отношение: она добавляет гибкость, но может внести путаницу в синтаксис между версиями C#.

5. Улучшенный nameof для открытых обобщённых типов

Теперь оператор nameof поддерживает открытые обобщённые типы, чего раньше не было.

В C# 13 следующая запись не работала:

nameof(Channel<>);

А вот в C# 14 — работает и возвращает "Channel".

Изменение небольшое, но полезное при генерации кода, рефлексии и диагностике.

Итоги

C# 14 предлагает отличный набор улучшений и синтаксического сахара.
Null-условное присваивание и пользовательские составные операторы — безусловные фавориты, а ключевое слово field делает определение свойств современнее.

Новый синтаксис с extension всё ещё спорный, но в целом язык развивается в правильном направлении.

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

Чтобы понять масштаб

Для сравнения стоит вспомнить уязвимость Log4J — настолько серьёзную, что о ней писали даже на BBC News. Тогда рейтинг уязвимости составлял 10.0, то есть максимальный возможный уровень по шкале CVSS. Более того, Microsoft даже профинансировала профессиональный документальный фильм о том, насколько страшным было происшествие с Log4Shell.

Теперь Microsoft объявила об уязвимости в .NET с рейтингом 9.9, почти на уровне Log4J. Естественно, это вызвало волну тревоги, путаницы и бесконечные неловкие разговоры в IT-отделах по всему миру.

Как это выглядит в реальности

Типичный диалог на этой неделе выглядит примерно так:

Руководитель: «Эта новая уязвимость в .NET с рейтингом 9.9 только что появилась на моём супердорогом “Executive Security Dashboard 3000”. Помнишь Log4J четыре года назад? Там было 10. Это почти то же самое. Мы уязвимы?»

Full-Stack программист: «Всё в порядке, босс. Команда .NET уже выпустила патч».

Руководитель: «Эта проблема существует в .NET уже годами. Как мы можем быть уверены, что нас уже не взломали?»

Программист: «Мы не знаем…»

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

Можно, конечно, проверить логи — если они у вас сохранились — но, по сути, на этом всё.

Отсутствие ясности и ответов

Понимаемо, что такое молчание вызвало возмущение у многих. На GitHub разработчики активно задают вопросы инженерам Microsoft, например Барри Дорансу, но его ответы не добавляют уверенности.

Вот несколько примеров:

• Вопрос: Уязвимо ли приложение, если оно размещено под IIS? Смягчает ли IIS эту проблему?
  Ответ: «Это вопрос к команде продукта IIS. Я не могу говорить от их имени.»
• Вопрос: Смягчает ли Azure Front Door (веб-аппликационный файрвол Microsoft) эту уязвимость?
  Ответ: «Это вопрос к команде Azure Front Door. Я не могу говорить от их имени.»
• Вопрос: Когда Azure App Service обновит свой runtime?
  Ответ: «Это вопрос к команде Azure App Service. Я не могу говорить от их имени.»
• Вопрос: Будет ли выпущен патч для .NET 6?
  Ответ: «Нет, этот выпуск больше не поддерживается.»

А когда разработчики попросили привести конкретные примеры возможных атак или сценариев эксплуатации, ответ был лаконичный:

«Как я уже сказал выше — нет.»

Azure App Service до сих пор работает на уязвимой версии

Через неделю после публикации проблемы проверка новых экземпляров Azure App Service показала, что они всё ещё используют .NET 8.0.16, в котором есть уязвимость. Безопасная версия — 8.0.21 — до сих пор не развернута.

Это особенно раздражает, учитывая, насколько быстро Microsoft внедряет обновления в других областях. Например, GitHub Copilot получил доступ к GPT-5 в тот же день, когда OpenAI его выпустила. Так почему же обновление .NET runtime с критическим патчем занимает столько времени, особенно при рейтинге 9.9 CVE?

Что говорит Microsoft официально

Команда App Service опубликовала сообщение, где заявила, что они «тесно работают с командой .NET для устранения проблем, мешающих своевременно доставлять обновления версий .NET runtime, предоставляемых платформой под Windows».

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

А пока Microsoft рекомендует разработчикам использовать self-contained деплой — собирать приложение с параметром --self-contained и вручную выбирать версию runtime. На данный момент это единственный надёжный способ защитить .NET-приложения в Azure.

Как сообщество пытается помочь

Команда HeroDevs, которая продаёт платные патчи для устаревших версий .NET (например, .NET 6), выпустила на GitHub тестовое приложение, позволяющее проверить, уязвим ли ваш runtime.

Это небольшая консольная утилита, которая отправляет “request smuggling” запросы и проверяет, возникает ли исключение. На уязвимой версии .NET 8 тест падает, а на исправленной .NET 10 — проходит.

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

Разбор сути уязвимости

Попробуем понять, что вообще происходит.

Судя по всему, речь идёт об HTTP Request Smuggling — методе, когда злоумышленник прячет один HTTP-запрос внутри другого, например DELETE внутри обычного GET, используя HTTP chunking.

Представьте:

• GET /user — запрос, доступный любому пользователю с ролью User.
• DELETE /user — запрос, требующий роль Admin.

Если эти запросы объединены в один, сервер может разделить их и обработать по отдельности. Обычно Kestrel (веб-сервер .NET) выдаёт исключение BadHttpRequestException, что безопасно.

Но если вы вынесли проверку авторизации за пределы приложения (например, в WAF, API Gateway или внешний прокси), то этот внешний сервис может не заметить скрытый DELETE-запрос. В итоге .NET-приложение получит его и выполнит, полагая, что он уже авторизован.

Итак:

• Приложения с внешней авторизацией могут быть под угрозой.
• Приложения с встроенной авторизацией внутри .NET-кода — вероятнее всего, в безопасности.
• WAF при корректной настройке должен отсеивать такие запросы.

Проблема — не только в коде, но и в коммуникации

По сути, самая большая проблема — это не уязвимость, а отсутствие прозрачности.

«Барри, пожалуйста, как глава .NET Security, дайте больше информации. Напишите развёрнутый блог, объясните, что происходит и как проверить, затронуто ли наше приложение.»

Потому что выставив рейтинг 9.9 без конкретных рекомендаций, Microsoft создала две опасные ситуации:

1. Похоже, будто компания что-то скрывает.
2. Или же — сеет панику без оснований, “крича волк!” там, где его нет.

Если бы рейтинг был 7 или 8, разработчики просто спокойно поставили бы патч. Но 9.9 звучит пугающе — особенно когда сами Azure-сервисы остаются незащищёнными.

Заключение

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

Руководству Microsoft по безопасности .NET нужно не просто выпускать CVE и обновления, а объяснять риски и обеспечивать актуальность облачных сервисов Azure.

Пока же единственный надёжный путь для разработчиков — самостоятельно компилировать приложения с обновлёнными runtime и внимательно следить за официальными обновлениями.

Сегодня мы подробно рассмотрим .NET AI Template от Microsoft, выпущенный в марте. Этот шаблон включает два типа проектов — AI Chat Web App и Local MCP Server Console App.

В этом обзоре мы сосредоточимся на AI Chat Web App: установим шаблон, посмотрим, что в него входит, создадим проект в Visual Studio и запустим его, чтобы увидеть, как всё работает.

Установка .NET AI Template

Начнём с установки шаблона AI.
Откройте терминал и выполните команду:

dotnet new install Microsoft.Extensions.AI.Templates

• AI Chat Web App

• Local MCP Server Console App

Использовать их можно в Visual Studio, Visual Studio Code (с установленным C# Dev Kit) или напрямую из командной строки, выполнив:

dotnet new aichatweb

dotnet new mcpserver

Для сегодняшней демонстрации мы выберем AI Chat Web App и будем работать в Visual Studio.

Создание проекта в Visual Studio

Перейдём в Visual Studio.
На экране Create a new project (создание нового проекта) откройте выпадающее меню All project types. Вы увидите новую категорию AI.

Выберите её — появятся два шаблона:

• AI Chat Web App

• Local MCP Server Console App

Выберите AI Chat Web App и нажмите Next.
Введите имя проекта, например ChatApp1. Укажите папку для сохранения и нажмите Create.

После этого появится возможность выбрать поставщика AI-модели и хранилище векторов.

Доступные поставщики AI-сервисов:

• Azure OpenAI

• GitHub Models

• Alma

• OpenAI Platform

В этом примере мы используем GitHub Models с локальным хранилищем векторов — это самый простой способ быстро начать работу.

Нажмите Create, и Visual Studio автоматически создаст проект, включая интерфейс на Blazor, папку Data и службы (Services).

Настройка GitHub-токена

Далее необходимо добавить GitHub-токен.
В файле README вашего проекта указана инструкция:

"GitHubModelsToken": "your-token"

Откройте secrets.json и вставьте туда свой токен, соблюдая тот же JSON-формат, что в примере.

Изучаем структуру проекта

Теперь, когда токен добавлен, давайте посмотрим, какие файлы создались.

• Папка Pages содержит страницы Blazor, например Chat.razor — это основной интерфейс чата.

• В папке Services находится логика, управляющая ходом диалога.

• В wwwroot/data расположены примерные PDF-файлы, используемые для загрузки данных и семантического поиска.

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

Файл Program.cs

Откройте файл Program.cs. В нём автоматически настроены AI-сервисы и хранилище векторов.

• В качестве языковой модели (LLM) используется GPT-4.0 Mini.

• Для эмбеддингов — Text-embedding-3-small.

• Векторная база данных — SQLite.

Всё это создаётся автоматически — вручную ничего настраивать не нужно.

Как работает загрузка данных

Проект содержит несколько ключевых классов, отвечающих за обработку данных.

Класс DataIngestor

Этот класс читает и обрабатывает PDF-файлы из папки wwwroot/data.
Он извлекает текст, создаёт эмбеддинги с помощью выбранной модели и сохраняет их в векторной базе данных SQLite.

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

Класс SemanticSearch

Во время диалога этот класс преобразует вопрос пользователя в эмбеддинг, сравнивает его с сохранёнными векторами документов и выбирает наиболее релевантные фрагменты информации.

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

Благодаря этим классам приложение может отвечать, опираясь на содержимое документов, а не генерировать случайный текст.

Запуск приложения

Теперь давайте запустим приложение и посмотрим, как оно работает.

После запуска программа автоматически обработает примерные PDF-файлы из папки wwwroot/data и создаст их эмбеддинги.

Затем откроется браузер с чистым и удобным интерфейсом чата на Blazor.

Теперь можно задавать вопросы, например:

«Что входит в набор для выживания?»

Приложение выполнит:

1. Обработку вопроса,

2. Семантический поиск по базе векторов,

3. Формирование ответа с указанием источника (файла и страницы).

Всё это происходит автоматически — без дополнительной настройки.

Использование собственных данных

Теперь посмотрим, как заставить чат-бота работать с вашими собственными документами.

Откройте папку wwwroot/data — там находятся два PDF-файла по умолчанию.
Чтобы добавить свои данные, просто поместите туда нужный PDF.

Например, можно взять свою статью о пагинации в EF Core, сохранить её как PDF и скопировать в эту папку.

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

Теперь можно задать вопрос:

«Какой метод пагинации лучше использовать для больших наборов данных?»

Чат ответит, используя контент из вашей статьи, объяснив, что Keyset Pagination эффективнее Offset Pagination на больших таблицах, поскольку она не пропускает строки и работает быстрее.

Под ответом вы также увидите ссылки на файл и страницу, откуда взята информация.

Расширение возможностей чат-бота

Теперь, когда приложение работает, посмотрим, как можно расширить его функциональность.

Проект построен на Microsoft.Extensions.AI, что позволяет легко добавлять собственные C#-функции, которые чат-бот сможет вызывать.

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

Пример: функция GetWeather

В файле Chat.razor можно определить новую C#-функцию, например:

string GetWeather(string city) { // Возвращает пример прогноза погоды return city switch { "London" => "Drizzle", "Paris" => "Sunny", _ => "Cloudy" }; }

Теперь чат-бот сможет вызывать эту функцию при соответствующем запросе.

Если теперь спросить:

«Какая погода в Лондоне?»

Чат-бот вызовет функцию GetWeather и ответит:

«Погода в Лондоне — моросящий дождь.»

Так чат-бот напрямую взаимодействует с вашим кодом на C#.
Далее вы можете подключать реальные API, базы данных или даже устройства IoT.

Заключение

Вот и всё — полный обзор работы .NET AI Template от Microsoft.

Этот шаблон — отличная отправная точка, если вы хотите создать:

• AI-ассистента

• Бота-документацию

• Пользовательское AI-приложение на .NET