Автор: admin

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

Проблема: коли мікросервіси перетворюються на доміно

У нашому StreamStore працюють мікросервіси:

• замовлення

• платежі

• склад

• сповіщення

• аналітика

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

• зменшення залишку на складі

• надсилання email клієнту

• створення інвойсу

• оновлення панелі продажів

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

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

Order → Payment → Inventory → Notification → Analytics

І все працює… поки не настає Black Friday.

Раптом:

• застосунок починає гальмувати

• користувачі сидять перед вічними екранами завантаження

• сервіси падають під навантаженням

• продажі втрачаються щохвилини

• архітектура перетворюється на хаос

Що ж сталося?

Чому пряме взаємодіяння мікросервісів — це пастка

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 — це історія змін.

Потокова обробка в реальному часі: 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 проти телебачення

Звичайна черга — як телебачення:

• дивишся те, що показують

• у той час, коли показують

• пропустив — все, втратив

Kafka — як Netflix:

• дивишся що хочеш

• коли хочеш

• у своєму темпі

• можеш переглядати знову

Саме ця гнучкість робить Kafka унікальною.

Прощавай, ZooKeeper: вітаємо, KRaft

Раніше Kafka використовувала ZooKeeper для координації.
Сучасні версії перейшли на KRaft, вбудовану систему керування.

Це спрощує конфігурацію та зменшує кількість залежностей.

Висновок

Kafka — це не просто message broker.
Це потужна платформа для потокової обробки даних, яка вирішує:

• жорстку зв’язаність

• проблеми синхронних викликів

• втрату даних

• неможливість realtime аналітики

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

Якщо ця стаття допомогла вам нарешті зрозуміти Kafka — поділіться нею з колегою, якому вона теж стане у пригоді.

Нова ера для розробників

Уявіть: ви багато років пишете код. Ви досконало володієте своїми мовами програмування, знаєте фреймворки та пишаєтеся вмінням вирішувати складні задачі. І ось одного дня ви бачите, як AI-асистент за кілька секунд пише функцію, на яку у вас би пішло 20 хвилин.

Цей момент усвідомлення сьогодні переживають інженери по всьому світу. І він змушує нас визнати нову реальність: ландшафт розробки змінюється.

Питання більше не в тому, чи вплине штучний інтелект на нашу роботу, а в тому, як ми можемо адаптуватися, щоб залишатися потрібними та цінними.

У цій статті ми розглянемо чіткий шлях, як розробникам розвиватися в епоху, коли AI вже здатен виконувати завдання, які колись вважалися виключно людськими.

Чому ці зміни особливі

Світ технологій завжди змінювався швидко — нові фреймворки, нові версії, нові підходи. Але цього разу зміни іншого рівня.

Йдеться не просто про вивчення нового інструменту чи синтаксису. Йдеться про повне переосмислення ролі розробника у процесі створення програмного продукту.

Щоб залишатися конкурентоспроможним, треба зосередитись на навичках, які штучний інтелект не може легко відтворити — стратегічному мисленні, архітектурному баченні та розумінні бізнесу.

Ось чотири ключові навички, які зроблять вас незамінним у світі, де AI стає частиною щоденної роботи.

1. Думайте як архітектор

Коли команді потрібно масштабувати застосунок у 10 разів, молодший розробник оптимізує запити, розробник середнього рівня почне шукати балансувальники навантаження.

А архітектор запитає:

• Чи підходить наша архітектура для такого масштабу?

• Може, варто перейти від моноліту до мікросервісів?

• Чи не слід повністю переглянути систему зберігання даних?

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

AI може оптимізувати запит, але не здатен спроєктувати масштабовану, стійку та економічну систему, яка відповідатиме унікальним потребам вашої компанії.

Архітектори визначають фундамент усього проєкту — і чим розумнішим стає AI, тим більшою стає цінність стратегічного мислення.

2. Опануйте DevOps і хмарну інфраструктуру

Після того як архітектурні рішення прийнято, їх потрібно ефективно реалізувати.

Тут на сцену виходять DevOps і cloud-native технології.

Сучасний інженер має розуміти:

• Контейнери (наприклад, Docker) — для стабільності середовищ.

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

• Infrastructure as Code — для передбачуваності.

• CI/CD — для швидкої доставки оновлень.

Йдеться не просто про інструменти, а про створення систем, які постійно приносять цінність.

AI може згенерувати код для мікросервісу або скрипт деплою, але не побудує повністю інтегровану систему безперервної доставки, що поєднує розробку, операції й бізнес.

Тому інженери, які розуміють DevOps на стратегічному рівні, завжди будуть затребувані.

3. Орієнтуйтеся на бізнес, а не лише на техніку

Різниця між хорошим і видатним розробником полягає ось у чому:
Хороший розробник створює працюючий код.
Видатний — створює відчутну бізнес-цінність.

Порівняймо:

Приклад 1:

«Ми розбили моноліт на мікросервіси й розгорнули їх у Kubernetes.»

Приклад 2:

«Після переходу на мікросервіси ми знизили затримку з 700 мс до 150 мс, скоротили витрати на інфраструктуру на $5000 щомісяця та усунули три критичні вразливості.»

У другому випадку технічна робота напряму пов’язана з результатом для бізнесу.

AI не розуміє цілей компанії чи потреб клієнтів — це можете зробити тільки ви.

Якщо ви зможете показати, як ваші технічні рішення впливають на прибуток, ефективність або безпеку, — ви стаєте стратегічним партнером, а не просто виконавцем.

4. Співпрацюйте з AI, а не змагайтеся з ним

Остання навичка — це вміння ефективно працювати разом із штучним інтелектом.

Не варто боятися AI — краще використовуйте його як помічника:

• Нехай він генерує шаблонний код.

• Автоматично створює тести чи документацію.

• А ви додаєте логіку, досвід і контекст.

Таке поєднання швидкості AI та людського критичного мислення створює найефективнішу модель роботи.

Ті, хто ігнорує AI, відстануть. Ті, хто навчиться з ним співпрацювати, стануть у кілька разів продуктивнішими.

Приклад: масштабування застосунку

Уявімо, як усі чотири навички працюють разом:

1. Архітектура – ви переходите від моноліту до мікросервісів із кешуванням і швидким доступом до даних.

2. DevOps – контейнеризація, CI/CD, Kubernetes.

3. Бізнес-результат – зниження затримок на 70%, зменшення витрат і підвищення стабільності.

4. AI – допомагає згенерувати базовий код і тести, а ви вдосконалюєте результат.

Тепер ви не просто програміст — ви стратегічний інженер, який приносить бізнес-цінність.

Типові помилки розробників

Деякі намагаються конкурувати з AI у швидкості — марно.
Інші бояться його або повністю на нього покладаються — теж помилка.

Правильний підхід — партнерство: використовуйте AI як інструмент, але не передавайте йому мислення.

Майбутнє належить адаптивним інженерам

Найціннішими стануть ті, хто:

• Мислить архітектурно.

• Розуміє DevOps і хмару.

• Вміє перетворювати технічні рішення на бізнес-результати.

• Використовує AI як прискорювач, а не загрозу.

Технології змінюються, але здатність мислити, вчитися та адаптуватися — ваша найкраща інвестиція.

Підсумок

Не змагайтеся з AI — співпрацюйте з ним.
Не просто пишіть код — створюйте системи.
Не просто випускайте фічі — приносьте цінність бізнесу.

Так ви залишатиметесь актуальними й незамінними в епоху інтелектуальної автоматизації.

Протягом багатьох років екосистема 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 — успішно виконується.

Але важливо: цей тест не демонструє реальної експлуатації уразливості. Він лише показує, що новий runtime по-іншому обробляє некоректні запити. Ніякого обходу авторизації не відбувається.

Спроба зрозуміти суть проблеми

Імовірно, йдеться про атаку типу 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, поясніть детальніше. Напишіть блог, у якому чітко розкажіть, що відбувається і як перевірити, чи наш застосунок у небезпеці.»

Адже виставивши рейтинг 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 та налаштування сервісів.

Налаштування 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 у дії.

Цей шаблон — потужна відправна точка, якщо ви плануєте створити:

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

• Бота для документації

• Або будь-який AI-застосунок на .NET