DevOps *

LLM пишут код. Почему разработка все еще занимает столько времени?

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

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

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

Например, раньше цепочка после разработки выглядела примерно так: открыть MR → смерджить → собрать main → перевести задачу → уведомить следующего участника процесса.

Теперь ее можно запустить одной командой. Система сама выполняет действия в трекере, репозитории и сборке — но только в рамках заданных инструкций и с предусмотренными проверками.

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

2 сентября в 15:00 мск приходите на вебинар, чтобы посмотреть, как такой подход устроен изнутри и что из него можно применить в своих процессах.

На вебинаре разберем:

• как устроены инструкции: что входит в описание одного действия и как из отдельных инструкций собирать цепочки;

• какие метрики помогают найти узкие места: ожидание, передачи задач и переключения между системами;

• как одной командой запускать действия сразу в нескольких инструментах;

• как автоматизировать дежурство по ошибкам;

• какие проверки мы оставили за человеком и почему;

• что не сработало при создании системы и какие решения пришлось пересмотреть.

Отдельно поговорим о код-ревью, ответственности за прод и о том, какие действия мы не стали отдавать автоматизации.

Спикер: Владимир Шилун, старший frontend-разработчик Just AI.

Участие бесплатное, достаточно зарегистрироваться. А если вдруг не успеете на эфир — пришлем запись и материалы, чтобы можно было посмотреть все в удобное время.

Зарегистрироваться можно по ссылке.

Как выстроить аварийное восстановление в гибриде и мультиоблаке. Вебинар Хайстекс

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

26 августа в 11:00 (МСК) команда Хайстекс проведет вебинар. Эксперты разберут, почему в гибридной инфраструктуре недостаточно просто настроить бэкап, и покажут на практике, как в Хайстекс Акура выстраивать сценарии восстановления для разрозненных платформ и площадок.

Что обсудим:

• где чаще всего ломаются бэкап и репликация – сеть, окна копирования, ручные операции, ограничения площадок;

• когда достаточно резервной копии, а когда уже нужен полноценный DR-сценарий;

• почему заявленные RTO/RPO без тестовых восстановлений мало что значат;

• как организовать восстановление между разными площадками и платформами.

После основной части спикеры проведут Q&A-сессию: можно принести архитектуру своего контура в чат и получить разбор от инженеров Хайстекс.

Зарегистрироваться на вебинар

3 неочевидных open source инструмента для разработки в облаке

Собрали инструменты, о которых не так часто говорят, но они закрывают конкретные боли dev-команд в облаке.

🖥️ Cреды разработки

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

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

➖ Docker Hub закрыт для российских IP — образы нужно тянуть через собственное зеркало на Harbor/Nexus или GHCR-прокси.

Альтернативы: 

• DevPod. Если маленькая команда или нужна гибкость по вендору. Инструмент работает как чистый CLI вообще без сервера, единообразие окружений обеспечивается через конфиг devcontainer.json, но централизованного управления нет.

• Eclipse Che.Если у команды уже есть Kubernetes-кластер и нужна полноценная K8s-native среда. Также подходит тем, кто работает в экосистеме Red Hat / OpenShift.

🔑 Хранение секретов и разграничение доступов

OpenBao. Есть смысл внедрять, когда секреты уже расползлись по переменным, .env-файлам и табличкам в общем доступе, и теперь это добро трудно найти аудировать, легко потерять и невозможно безопасно ротировать. Инструмент позволяет собрать управление в одном контуре и применять единые политики доступа.

➕ Полностью открытая лицензия (MPL 2.0), можно не только использовать, но и перепродавать в составе других коммерческих продуктов; поддерживает и статические, и динамические секреты, есть PKI для выпуска X.509-сертификатов.

➖ Развертывание и обновления требуют дисциплины, нужны внутренние зеркала container images, helm-чартов и исходников, чтобы поставка не зависела от доступности внешних registry и Git-hosting.

Альтернативы/дополнения: 

• Infisical. Хороший выбор, если в приоритете удобство для разработчиков и более широкий продуктовый контур вокруг секретов. Еще он удобнее всего для работы с учетными данными ИИ-агентов.

• External Secrets Operator. Не замена OpenBao, а Kubernetes-слой для доставки секретов. Он забирает значения из внешнего хранилища: OpenBao, Infisical, AWS Secrets Manager или любого другого бэкенда — и синхронизирует их в нативные Kubernetes Secrets внутри кластера. Стоит выбирать, когда приложения уже живут в Kubernetes и нужен GitOps-подход, когда в Git хранятся только ссылки на секреты и политики доступа, а сами значения остаются в защищенном хранилище (HashiCorp Vault, OpenBao) и никогда не попадают в репозиторий.

🚩 Флаги фич

GO Feature Flag. Выручает, когда нужно безопасно выкатывать фичи без передеплоя. Ну, или мгновенно вернуть как было, не трогая инфраструктуру.

➕ Легкая библиотека флагов на базе стандарта OpenFeature, работает встроенно в приложении или как промежуточный прокси-сервис. Конфиг может хранится в YAML-файле, в Git (даже self-hosted без привязки к GitHub), также можно держать в S3 или Redis. MIT-лицензия, минимум внешней инфраструктуры. 
➖ Маленькое коммьюнити, мало готовых интеграций, а поддержка держится на GitHub Issues, доступность которых в РФ нестабильна.

Альтернативы:

• Unleash. Если флаги больше нужны инженерам для безопасных раскаток и управления циклом изменений.

• Flagsmith. Если кроме включения/выключения функций нужны продуктовые сценарии, например, сегментация пользователей или A/B-тесты.

Не будем скромничать, у нас тоже есть свое open source решение: фильтр для доступа к внешним нейросетям, которое, во-первых, позволяет использовать LLM (в том числе для кодинга), не сливая туда чувствительную инфу, а во-вторых, не ломает при этом вызов функций. Как мы этого добились, рассказывали в статье. Забирайте в свой контур, открывайте pull request’ы, оставляйте issuе — мы открыты к обратной связи.

AI-аналитик, MCP-сервер и GenAI-трейсы: что появилось в Proto Observability Platform 203

Главной темой релиза Proto Observability Platform 203 стало расширение инструментов для анализа телеметрии и наблюдаемости LLM-приложений: к существующим ИИ-расследованиям добавились AI-аналитик для работы с телеметрией на обычном языке, MCP-сервер для подключения ИИ-агентов и представление GenAI-трейсов для анализа работы внешних LLM-приложений.

AI-аналитик работает с метриками, логами, трейсами, инцидентами и ресурсно-сервисной моделью. В ответе он показывает затронутые сервисы, возможные причины проблемы и ссылки на найденные объекты платформы. Для анализа данных в платформе теперь не требуется знание PromQL, LogsQL или топологии приложений - все это теперь можно запрашивать в режиме чата на обычном языке.

Встроенный MCP-сервер предоставляет ИИ-агентам инструменты для работы с данными платформы по стандарту Model Context Protocol. Через него доступны метрики, логи, события, ресурсы, трейсы, сервисы, алерты и инциденты.

Новое представление GenAI-трейсов показывает выполнение LLM-приложения как последовательность действий. На одном экране видны сообщения по ролям, обращения к модели и инструментам, ошибки вызовов и длительность отдельных шагов.

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

AI-аналитик, MCP-сервер и GenAI-трейсы: что появилось в Proto Observability Platform 203

Главной темой релиза Proto Observability Platform 203 стало расширение инструментов для машинного анализа телеметрии и наблюдаемости LLM-приложений: к существующим ИИ-расследованиям добавились AI-аналитик для работы с данными телеметрии на обычном языке, MCP-сервер для подключения ИИ-агентов и представление GenAI-трейсов для анализа работы внешних LLM-приложений.

AI-аналитик работает с метриками, логами, трейсами, инцидентами и объектами ресурсно-сервисной модели. В ответе на запросы оператора он показывает затронутые сервисы, возможные причины проблем и ссылки на найденные объекты платформы, сам проводит анализ ключевых данных производительности приложений и инфраструктуры. Для анализа данных в платформе теперь не требуется знание PromQL, LogsQL или топологии приложений - все это теперь можно запрашивать в режиме чата на обычном языке.

Встроенный MCP-сервер предоставляет ИИ-агентам инструменты для работы с данными платформы по стандарту Model Context Protocol. Через него доступны метрики, логи, события, ресурсы, трейсы, сервисы, алерты и инциденты, ошибки и другие ключевые данные платформы.

Новое представление GenAI-трейсов показывает выполнение LLM-приложения как последовательность действий. На одном экране видны сообщения по ролям, обращения к модели и инструментам, ошибки вызовов и длительность отдельных шагов.

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

12 уроков по системному администрированию: от nftables до RAID

Пока всё работает, инфраструктура редко требует пристального внимания. Настоящая проверка начинается в момент сбоя: L2-петля кладёт сеть, изменение firewall грозит потерей SSH‑доступа, место на диске заканчивается не вовремя, а по логам сложно понять, где именно возникла проблема.

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

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

Linux: безопасность, сервисы и хранение

• 20 августа, 20:00. «Средства защиты в ядре Linux». Записаться

• 26 августа, 19:00. «Nftables без потери SSH: безопасно настраиваем firewall на удаленном сервере». Записаться

• 3 сентября, 19:00. «Первый веб‑сервер на Linux: Nginx, Apache и проверка доступности». Записаться

• 8 сентября, 20:00. «LVM без простоя: расширение тома, перенос данных и аварийный откат через snapshot». Записаться

• 17 сентября, 20:00. «Где Linux хранит настройки и логи: разбираем файловую структуру на практике». Записаться

• 21 сентября, 20:00. «Типовые задачи с RAID‑массивами: создание, эксплуатация, перенос данных и восстановление». Записаться

Сети

• 24 августа, 20:00. «Защита от петель L2: что выбрать, если STP уже не устраивает». Записаться

Windows‑инфраструктура

• 7 сентября, 20:00. «Linux для Windows администратора за 60 минут». Записаться

• 22 сентября, 20:00. «Топ GPO, которые помогут тебе». Записаться

Автоматизация, диагностика и высокая доступность

• 10 сентября, 20:00. «Настройка GitLab Runners». Записаться

• 23 сентября, 20:00. «eBPF: рентгеновское зрение для production». Записаться

• 23 сентября, 20:00. «Узнайте, как использовать Patroni для управления высокодоступными кластерами PostgreSQL». Записаться

ЧТО ПОЧИТАТЬ ПО ТЕМЕ:

• «Прощай, Fail2Ban: усиливаем защиту Netbird и Caddy с CrowdSec» — практический разбор защиты сервера: работа с логами, блокировка нежелательного трафика и настройка nftables. Читать на Хабре

• «Пять проблем Bash, которые ломают скрипты в самый неудачный момент» — о типичных ошибках в Bash‑скриптах, которые могут проявиться уже при эксплуатации и автоматизации системных задач. Читать на Хабре

• «Ищем петли и шторма в L2 сети» — как диагностировать L2-петли, broadcast‑штормы и MAC flapping, найти проблемный порт и восстановить работу сети. Читать на Хабре

Больше открытых уроков по инфраструктуре и смежным направлениям собрали в дайджесте.

NUMA и топология CCD Ryzen 9 9950X: как размещение vCPU влияет на задержки.

NUMA и топология CCD Ryzen 9 9950X не равнозначны: гость видит NUMA-схему, но не границы L3. Сравнивать нужно размещение vCPU на одной VM внутри CCD, между CCD и без pinning. Результат зависит от нагрузки, BIOS, ядра, QEMU и SMT.

Как определить, какие vCPU находятся на одном CCD?

Сопоставьте логические CPU с ядрами и SMT-сиблингами, затем найдите группы общего L3-кэша. Каждый CCD объединяет восемь ядер с общим L3, номера CPU зависят от хоста, поэтому проверяйте shared_cpu_list. Запишите BIOS, микрокод, ядро и governor.

lscpu -e=CPU,CORE,SOCKET,NODE,CACHE
grep -H . /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list

Границы CCD измеримы: в открытом наборе для 9950X с AGESA 1.2.0.2 средняя задержка CAS через общую строку кэша составила 22,4 нс внутри CCD и 79,5 нс между CCD, тогда как numactl границу не покажет.

От физических ядер к vCPU, emulatorpin и vNUMA

vcpupin связывает vCPU с CPU хоста, но не трогает остальные потоки VM: эмулятор QEMU и IOThread закрепляются отдельно. NUMA node гостя должен отражать домен памяти, а не границу L3, иначе межчиплетная задержка смешается с доступом к удалённой RAM.

virsh vcpupin vm-latency
virsh emulatorpin vm-latency
virsh numatune vm-latency

Компактный CCD, разнесённые CCD и свободное планирование

Сравните одну VM в трёх конфигурациях: внутри одного L3, между CCD и без vcpupin. Число vCPU и RAM не меняйте, пиннинг задавайте по физическим ядрам, SMT проверяйте отдельно.

Насколько размещение между CCD увеличивает задержку?

Универсальной прибавки нет: результат зависит от общих данных, синхронизации, памяти и миграций. Сравнивайте одну нагрузку на одном хосте, сохраняя p50, p95, p99 и разброс. Core-to-core тест измеряет обмен между CCD, а не p99 приложения.

Как не принять boost, нагрев или соседнюю VM за эффект CCD

Прогрейте VM, фиксируйте частоту, температуру и %st: performance не удерживает частоту на Ryzen. Чередуйте схемы A–B–C–C–B–A и записывайте фоновые задачи. vNUMA должна совпадать с доменами памяти хоста.

Связь задержки с миграциями, кэш-промахами и удалённой памятью

Возьмите приложение с общей памятью или синхронизацией и микротест обмена. Перед серией проверьте pinning в libvirt и память QEMU, затем снимайте context switches, миграции и NUMA faults. Для cache-misses нужен vPMU. Нормируйте счётчики: рост вместе с p99 причину не доказывает.

perf stat -e context-switches,cpu-migrations,cache-misses \
   -- ./test
numastat -p "$(pgrep -fo 'guest=vm-latency')"

Когда пиннинг vCPU улучшает p99?

1. Рабочие потоки часто обращаются к общим данным.

2. Без pinning они мигрируют между группами L3.

3. p99 снижается без потери throughput и роста %st.

Где компактность помогает, а где ограничивает параллелизм

Сведите три схемы в таблицу: медиана p99 по повторам и доверительный интервал разницы. Если интервал пересекает ноль, результат в пределах погрешности. Задачам с независимыми потоками компактность ничего не даёт: обмена между ядрами почти нет, а привязка сужает выбор планировщика.

Как превратить топологию 9950X в правило эксплуатации

До теста задайте порог, например снижение p99 на 10% без потери ops/s. В XML подставьте cpuset и узел.

<vcpu>2</vcpu>
<iothreads>1</iothreads>
<cputune>
 <vcpupin vcpu='0' cpuset='0'/>
 <vcpupin vcpu='1' cpuset='1'/>
 <emulatorpin cpuset='2'/>
 <iothreadpin iothread='1' cpuset='3'/>
</cputune>
<numatune><memory mode='strict' nodeset='0'/></numatune>

Закрепляйте vCPU внутри CCD только если улучшение p99 воспроизводится в повторных прогонах. Если throughput падает или p99 не меняется, оставьте свободное планирование. Топология задаёт гипотезу, решение зависит от VM.

Дайджест: новости за июль 2026

Рассказываем, что произошло в июле и объясняем, чем это может быть полезно.

🤖 Гига-помощник прокачался в управлении
Теперь через помощника можно установить ops-agent на ВМ и собирать еще более подробные данные о хостах для мониторинга и логирования. А еще ИИ-помощник научился по запросу менять размер диска и вычислительный ресурс кластера Evolution Managed Redis: диск можно увеличить на 20% и больше буквально в чате, не переключаясь в консоль.

🧠 AI Factory  —  цифровая среда для работы с генеративным ИИ
Evolution ML Inference — три апдейта для тех, кто гоняет модели в проде: монтирование бакетов S3 прямо в Docker RUN (для новых и уже созданных инференсов), кеширование CUDA Graph для быстрого масштабирования и стабильного serverless-инференса под пиковой нагрузкой, а также cron-расписание масштабирования GPU — можно заранее готовить ресурсы к нагрузке и экономить в тихие часы.

Evolution Foundation Models — пополнили каталог готовых к подключению моделей, а Guardrails Filter (инструмент для защиты чувствительных данных в запросах и ответах LLM) теперь в опенсорсе — можно смотреть код и встраивать в свои пайплайны.

Evolution Notebooks и Distributed Train — добавили статусы «Ожидает ресурсов» и «Подготовка окружения», чтобы было понятно, на каком этапе завис ноутбук или Jupyter Server. Для Distributed Train также обновили образ jupyter-cuda (Python 13.3) и Marimo Hub до 0.2.0 — с SSH-доступом для отладки, SSE-событиями для отслеживания статуса в реальном времени и более понятными ошибками при нехватке портов.

📈 Evolution Data Platform — комплекс управляемых сервисов для работы с данными
Evolution Managed Trino научился работать с каталогом Kafka — теперь топики можно объединять в одном SQL-запросе с данными из СУБД и S3.

☁️ Новости других сервисов Cloud.ru Evolution
Evolution Object Storage — обновили тарификацию для холодного и ледяного классов хранения (минимальный размер объекта 128 КБ, правило только для новых объектов), ограничили Bucket Policy до 64 КБ и добавили роль s3e.auditor для просмотра структуры хранилища без доступа к скачиванию — удобно для аудита и комплаенса.

Evolution Managed Kubernetes — поддержка версии 1.36. В резервном копировании появились инкрементальные копии — тип бэкапа выбирается прямо при создании плана.

В личном кабинете на главную добавили виджет «Баланс» — остаток средств и грантов, пополнение и промокоды в одном месте. А для контроля доступа появились роли «Наблюдатель организации» и «Наблюдатель проекта» — только просмотр, без лишних прав.

🏢 Cloud.ru Advanced и Облако VMware
Новый сервис Advanced GeminiDB — managed multi-model NoSQL с разделением compute и storage, API Cassandra (CQL, включая DynamoDB-совместимый режим), Redis и InfluxDB под кеш, сессии и временные ряды.

Terraform-провайдер обновили до 1.12.20 — поддержка DataPlane v2 для vpc-router и фикс обновления сертификата CCE. Advanced Data Warehouse Service научился создавать кластеры с раздельным хранением и вычислениями.

📽️Вебинары и обучение
Уже анонсировали вебинары на август и выложили записи за июль: 

• КИИ в облаке: от безопасной инфраструктуры к бизнес-драйву.

• Как развернуть платформу данных в облаке и подготовить данные для аналитики.

• ETL в облаке: от хаоса к управляемым процессам.

• Evolution Managed BI: все возможности BI-сервиса в облаке.

А еще выпустили в открытый доступ целую линейку курсов Cloud.ru ML System Design, чтобы вы могли создавать качественные ИИ-продукты.

💼 Свежие кейсы
Рассказали, как Купер полностью перенес свою инфраструктуру в облако, сократил количество инцидентов, их длительность и снизил цену устранения сбоев.

Остаемся на связи! ✌️

FinOps глазами SRE: сколько стоит надёжность

Инженеры умеют считать latency, error rate и uptime. Но когда разговор заходит про P&L, LTM и cloud spend — многие предпочитают сделать вид, что это не к ним. Проблема в том, что инфраструктурный счёт приходит вне зависимости от того, кто за него отвечает.

В новом выпуске «В SREду на кухне» вместе с Павлом Зеленовым, руководителем Tech platform billing в Авито, и Валентиной Калещатовой, руководителем продукта Лемана Про, разобрались: где проходит граница между «это задача финансов» и «это должен понимать каждый SRE».

Что на повестке

Кто реально отвечает за инфраструктурный счёт — и что происходит, когда команда этот счёт превышает.
Чем Showback отличается от Chargeback и почему этот выбор меняет культуру команды. Как «зомби-ресурсы» тихо съедают бюджет, а observability — до 40% инфраструктурных расходов.
Связаны ли FinOps и error budget — оказывается, очень даже.
И главный вопрос: как объяснить инженерам стоимость их сервисов, не превращая каждого разработчика в бухгалтера.

🔵 VK Видео 
📺 YouTube
📌 RuTube
Ⓜ️ Mave

Друзья, на ближайшие дни у нас запланировано два бесплатных вебинара:

🟣 13 августа в 17:00 (Мск) — «DevSecOps на практике: Внедрение безопасности в CI/CD за 60 минут»

На реальном кейсе разберем концепцию DevSecOps. Пройдём путь от написания кода до анализа безопасности в пайплайне. Продемонстрируем, как находить уязвимости на ранних стадиях, а затем на практике настроим базовое сканирование. Вебинар пройдет по принципу «Увидеть → Понять → Применить», чтобы вы сразу могли использовать полученные навыки.

✍️ Записаться

🟢 14 августа в 17:00 (Мск) — «5 ошибок нового тимлида в эпоху ИИ: как перейти от личного результата к результату команды»

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

✍️ Записаться

Подборка вебинаров на август

В августе разберем, как быть во всеоружии на случай отказа ЦОД, выбрать инфраструктуру для ИИ-проектов и упростить работу со Spark-задачами. Регистрируйтесь, чтобы не пропустить.

Отказ ЦОД: выстраиваем защиту с DRaaS и BaaS
Разберем, как подготовиться к отказу дата-центра и выстроить защиту инфраструктуры с помощью Evolution Disaster Recovery и Evolution Agent Backup. Обсудим, чем отличаются DRaaS, BaaS, репликация и аварийное восстановление, а также как выбрать решение с учетом требований к непрерывности, скорости восстановления и безопасности.
🧑‍💻 Для кого: ИТ-директора, руководители инфраструктуры, системные администраторы и специалисты по информационной безопасности.
📅 Когда: 18 августа, 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

ИИ-проекты: когда и как переходить от API к Bare Metal
Расскажем, когда API для инференса перестает отвечать требованиям проекта и почему стоит переходить на выделенную инфраструктуру. Разберем, чем Evolution Bare Metal отличается от облачной виртуализации, как подобрать GPU-конфигурацию для инференса, обучения и дообучения моделей, а также как масштабировать ИИ-нагрузки.
🧑‍💻 Для кого: ML-инженеры, разработчики ИИ-продуктов, архитекторы и технические руководители.
📅 Когда: 25 августа, 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

Как ИИ помогает создавать и сопровождать Spark-задачи в облаке
Покажем, как Evolution Managed Spark с ИИ помогает создавать, запускать и анализировать Spark-задачи с помощью запросов на естественном языке. Разберем работу с данными в Evolution Object Storage, поиск причин ошибок, рекомендации по их устранению и оптимизацию производительности приложений.
🧑‍💻 Для кого: дата-инженеры, разработчики Spark-приложений, аналитики данных и DevOps-инженеры.
📅 Когда: 27 августа, 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

Память VDS. Что стоит за строкой «8 ГБ» в тарифе
Число в тарифе отвечает на один вопрос: сколько памяти увидит гостевая система. Зарезервирован ли объем физически, может ли гипервизор забрать страницы обратно и что будет при пике соседей, оттуда не следует.

Три слова, которые каждый понимает по своему. Dedicated обычно означает объем, постоянно доступный машине по условиям тарифа. Слово «постоянно» стоит уточнить: резервируется ли память на хосте и может ли ballooning ее уменьшить. В burstable часть доступна всегда, остальное при свободном ресурсе узла. Shared значит, что резервирования нет. Даже при dedicated провайдер может разрешать swap на хосте, поэтому гарантия в договоре важнее названия модели.

Ballooning и overcommit. Ballooning работает через драйвер внутри гостя. По команде хоста он занимает страницы, ядро гостя освобождает кеш или уходит в свой swap, а высвобожденную память гипервизор отдает другим машинам. Пока баллон надут, приложения работают с меньшим объемом, чем в тарифе. Overcommit это когда сумма лимитов больше физической RAM узла. Умеренная переподписка работает годами, пока гости используют часть лимитов. Пример: после резерва под системные процессы на узле осталось 120 ГБ, машинам назначено 180. При суммарном рабочем наборе 80 ГБ никто ничего не заметит. При 140 придется забирать страницы через ballooning или уходить в swap хоста. Overselling это тот же overcommit, но с недостаточным запасом: разница не в технологии, а в коэффициенте.

Что видно изнутри, а что нет. Сразу о границе: коэффициент переподписки из гостевой системы не определяется никак, эти данные есть только у провайдера. Изнутри ловится давление на память и его совпадение с замедлением сервиса.

free -m && grep -E "MemAvailable|SwapFree" /proc/meminfo
vmstat -y 1 10

procs ---swap-- -----io---- ---cpu---
 r  b   si   so    bi    bo  us sy id wa st
 1  2  184  412  1240   980  22  6 61 10  1

Смотреть надо на MemAvailable, а не на free: файловый кеш при нужде освобождается. Ненулевые si и so в нескольких интервалах подряд это обмен сейчас, а не след прошлого пика.

cat /proc/pressure/memory

some avg10=14.82 avg60=9.31 avg300=3.07 total=8123441
full avg10=6.55 avg60=4.02 avg300=1.18 total=3910228

PSI это доля времени, потерянного задачами из за нехватки памяти. Строка some означает, что простаивала хотя бы одна задача, full что вставала вся работа. Четырнадцать процентов в avg10 при выросшем времени ответа это разговор, а не шум.

journalctl -k -g "oom|Killed process"

Если процесс убило ядро гостя, запись будет здесь. Отсутствие записи при остановившейся машине это отдельный сюжет: OOM хоста может завершить процесс самой машины, и в журнале гостя причины не будет.

Признаки, которые стоит собрать вместе. Задержка растет в одни и те же часы при сопоставимой нагрузке. Устойчивые si и so без изменения профиля приложения. PSI растет синхронно с замедлением. Машина останавливается без записи об OOM у себя. Один признак ничего не доказывает, три совпавших уже повод писать в поддержку с временем эпизодов и метриками.

Что спросить до заказа. Какой объем зарезервирован, а не просто виден. Допускается ли ballooning и до какого минимума. Разрешен ли swap на хосте для памяти машин. Для burstable отдельно: гарантированная часть и условия доступа к остальному.

Тип гипервизора говорит об архитектуре, а не о гарантиях: overcommit поддерживают и KVM, и VMware, и Xen. SLA обычно описывает доступность и компенсацию за простой, но не производительность.

От ядра Linux до ИИ-агентов: 19 открытых уроков недели

Как устроены продвинутые модели Data Science, что происходит на границе user space и kernel space, как проектировать отказоустойчивые микросервисы и автоматизировать рабочие задачи с помощью искусственного интеллекта?

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

Data Science и искусственный интеллект

• 10 августа, 18:00. «Технологии продвинутого Data Science: что под капотом». Записаться

• 12 августа, 20:00. «ИИ-зрение в действии: как из данных с дороги получить карту мира». Записаться

• 13 августа, 20:00. «Управление данными в MSA — дыра в бюджете или актив для ИИ-трансформации?». Записаться

• 17 августа, 20:00. «Создаём первого ИИ-агента за 90 минут: автоматизируем реальную рабочую задачу с Claude Code». Ведущая — Татьяна Березенцева. Записаться

Разработка и архитектура

• 10 августа, 20:00. «Ваш первый код на Go за один вечер». Записаться

• 11 августа, 20:00. «Работа с SQLAlchemy и Alembic в FastAPI». Записаться

• 12 августа, 20:00. «Паттерны отказоустойчивости и масштабируемости микросервисной архитектуры». Записаться

• 12 августа, 20:00. «Тайный язык общения чипов. Подключаем всё к ESP32». Записаться

DevOps и системное администрирование

• 10 августа, 20:00. «Вход в ядро: системные вызовы и граница между user space и kernel space». Записаться

• 10 августа, 20:00. «Kubernetes + CI/CD + GitOps — делаем стабильный деплой без выхода из кластера». Записаться

• 13 августа, 20:00. «Принцип DRY в GitLab CI: как избавиться от дублирования и навести порядок в пайплайнах». Записаться

• 17 августа, 20:00. «Что такое модуль ядра. Как его написать, собрать, запустить». Записаться

• 17 августа, 20:00. «Системы логирования: ELK, EFK или Graylog?». Записаться

Тестирование

• 13 августа, 20:00. «Минимум для старта: как провести своё первое нагрузочное тестирование». Записаться

Системный и бизнес-анализ

• 11 августа, 20:00. «Практическое собеседование системного аналитика». Записаться

• 17 августа, 20:00. «Строим модель в нотации BPMN с помощью ИИ». Ведущий — Андрей Коптелов. Записаться

Управление, поддержка и Битрикс24

• 10 августа, 19:00. «Настройка прав доступа в Битрикс24: от простого к сложному». Записаться

• 10 августа, 20:00. «Колл-центр поддержки изнутри: структура, на которой держится клиентский сервис». Записаться

• 11 августа, 19:00. «Модели организации разработки: продуктовые команды и архитектурное управление». Записаться

Полный спислк бесплатных уроков августа смотрите в дайджесте мероприятий.

Все, что нужно знать DevOps-инженеру: сводка за лето 2026

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

⏰ Пять дедлайнов, которые уже наступили

• Prometheus 3.5 LTS перестал поддерживаться 31 июля. Новая 3.13 LTS будет поддеживаться до 31 июля 2027. Лучше прямо сейчас запланировать переход всех инстансов Prometheus с 3.5 LTS и других устаревающих версий на актуальную 3.13 LTS. Не забудьте проверить совместимость стека и протестировать обновление в staging.

• В Argo CD обнаружились три уязвимости. Утечка секретов через ServerSideDiff (CVE-2026-43824), обход авторизации (CVE-2026-42880) и RCE в repo-server (CVE-2026-15416). Затронуты 3.2.0–3.2.10 и 3.3.0–3.3.8, учитывая, что как раз вышла свежая версия 3.5, самое время обновиться.

• Self-hosted runner ниже 2.329.0 не зарегистрируется. GitHub просто перестанет пускать к себе раннеров-старичков. Лучше обновиться, чтобы не словить падение CI/CD, на установку свежей версии теперь отводится 30 дней.

• Неявная выкачка кода из форка в pull_request_target и workflow_run теперь запрещена. Если вдруг ваш пайплайн внезапно перестал видеть код PR — поздравляем, вы нашли у себя уязвимый workflow. Это была дыра в безопасности, через которую можно было украсть секреты или изменить ваш код прямо из PR.

• Выпущены патчи Etcd: v3.7.1, v3.6.14 и v3.5.33. Они закрывают утечку watch-ответов через границы RBAC и неограниченное создание goroutine на TLS-handshake. Проверьте, не используете ли вы ту версию etcd, которая дает возможность читать ключи и DoS’ить кластер, ну и не забудьте обновиться.

⚙️Про куберы

Kubernetes научился более умно работать с GPU и другим специальным железом. DRA (Dynamic Resource Allocation) вырос из «пробной» технологии, в штатный механизм. Теперь можно описывать, какое именно устройство вам нужно при выделении, как его делить и что делать при отказе.

Linkerd научился замечать, что конкретный сервис уже перегружен, и направлять новые запросы к другим доступным репликам: у версии Linkerd 2.20 появилась rate-limit-aware балансировка, а destination controller основательно переработали.

Istio добавил экспериментальный agentgateway — отдельный gateway‑proxy для ИИ‑агентов и MCP‑серверов. Еще развивается ambient multicluster: можно соединять сервисы в нескольких Kubernetes‑кластерах в одну mesh‑сеть без sidecar’а в каждом поде.

⛓️‍💥Про цепочки поставок

4 августа произошла масштабнейшая атака на цепочку поставки npm: в более чем 400 легитимных JavaScript‑пакетов встроили червя ChainDrop, который при установке крадет секреты разработчика или CI/CD и с украденным npm‑токеном сам заражает следующие пакеты. Работа для каждого на ближайшие недели — проверить dependency tree и lockfiles на скомпрометированные версии, очистить npm/yarn‑кеши в CI и на рабочих машинах, ну и отозвать и перевыпустить все доступные там секреты с чистого хоста.

CISA обновила минимальные элементы SBOM: подпись автора, инструмент генерации, хеш и алгоритм, лицензия, явные unknowns, машиночитаемость. CRA тоже требует вести машиночитаемый SBOM, поэтому тем, кто работает с рынком ЕС, уже стоит встроить генерацию и хранение SBOM в CI/CD: с декабря 2027 года он станет обязательным.

📊Про наблюдаемость

OpenTelemetry стал graduated-проектом CNCF, это по факту означает, что теперь у нас есть вендоронезависимый стандарт для сбора метрик, логов и трейсов, на который можно опираться при построении наблюдаемости.

Loki 3.6 получил горизонтально масштабируемый compactor. Теперь часть тяжелой работы по удалению логов можно раздать worker‑репликам. Но функция пока экспериментальная.

Grafana Alloy закрепился как официальный дистрибутив OTel Collector. Теперь, если вы строите или обновляете пайплайн сбора телеметрии на Grafana‑стеке, Alloy становится стандартным кандидатом №1, хоть функция пока экспериментальная.

Мы бы рассказали еще про статьи в нашем блоге на тему DevOps, но не можем — места нет.

🤖 AI-агенты для Ansible: как делегировать рутину и не писать плейбуки руками — бесплатный стрим 12 августа

Я перестал писать Ansible-плейбуки руками. Вообще. Вместо этого у меня работает AI-агент, который знает лучшие паттерны, понимает мою инфраструктуру и сам пишет роли, модули, соединяет их и поднимает всё необходимое. Недавно он за вечер собрал связку Terraform + Ansible на новом сервере — и справился лучше, чем я ожидал.

На стриме покажу, как это устроено изнутри:

🔧 Архитектура AI-агента для Ansible: база знаний, инструментарий, что дёргать и как дёргать
📜 Как агент пишет роли и модули: промпты, валидация, итеративное исправление ошибок
🖥 Живой пример: поднимем инфраструктуру с нуля руками агента — в реальном времени
💡 Границы применимости: что агент делает хорошо, а что пока лучше делать самому

Андрей Чуян — основатель DebugSkills, автор AI-агента для работы с Ansible, спикер лабораторных по AI-оркестрации и Kubernetes.

📅 12.08.2026, 19:00 (МСК)
📡 ktalk
⏱️ 45 мин контент + 15 мин Q&A

> «Я ушёл из рутины, делегировал Ansible AI-агенту, который занимается этим.» — Андрей Чуян, из диалога с участником на лекции Jenkins

Это не вебинар и не лабораторная. Это живой разговор о том, как AI меняет работу DevOps-инженера уже сегодня. Без продаж, без подписок — просто приходите и смотрите.

Ссылка на регистрацию: https://debug-skills.timepad.ru/event/4127747/

Жду вас! 🤖

Как проверить VDS до покупки: ядра, память, диск?
Слово VDS не закреплено ни за одной технологией. У одного это машина KVM, у другого контейнер, у третьего просто тариф подороже с пометкой dedicated. За одинаковой строкой характеристик стоят разные модели распределения ресурсов, и утренний тест дает результат, который вечером не повторится.

Что стоит выяснить до тестов? KVM запускает гостя с собственным ядром на аппаратной виртуализации, OpenVZ и LXC делят ядро хоста. Распространенное заблуждение: KVM якобы исключает оверкоммит. Не исключает, провайдер назначает машинам больше vCPU и памяти, чем есть на хосте. Отсюда вопросы к тарифу. Закреплены ли vCPU за физическими процессорами. Зарезервирована ли память. Есть ли лимит IOPS и что при его превышении. Слова dedicated, isolated и NVMe без этих ответов не значат ничего.

Ядра. Под dedicated понимают физическое ядро, закрепленное за машиной. Pinning эксклюзивности не дает: на тот же процессор оператор может посадить чужие vCPU. Проверяется это наблюдением.

mpstat -P ALL 1 60

Колонка %steal показывает время, когда система готова работать, а процессор ей не дали. Важна повторяемость: единичный всплеск это шум, рост в одни часы это конкуренция. На контейнерном тарифе лимит виден как троттлинг, steal остается низким.

cat /sys/fs/cgroup/cpu.max /sys/fs/cgroup/cpu.stat

200000 100000
nr_throttled 1843
throttled_usec 21904331

Ненулевой nr_throttled означает, что режет лимит, а не сосед. В виртуальной машине таких значений не будет. Дальше sysbench в один поток и на всех ядрах, одна версия утилиты и один cpu-max-prime на кандидатах.

sysbench cpu --threads=1 --cpu-max-prime=20000 --time=60 run
sysbench cpu --threads=$(nproc) --cpu-max-prime=20000 --time=60 run

Строгого удвоения при удвоении потоков не будет, мешают кеш и шина памяти. Настораживает обратное: многопоточный результат равен однопоточному, а mpstat показывает steal.

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

free -m && swapon --show
stress-ng --vm 1 --vm-bytes 70% --vm-keep --timeout 10m --metrics-brief

Тест гоняйте на пустой машине и параллельно смотрите vmstat. Использование swap само по себе ни о чем не говорит, оно зависит от настроек гостя. Тревожат устойчивые si и so при умеренной нагрузке и падение MemAvailable. Если процесс исчез раньше срока, ответ в журнале ядра.

journalctl -k --since "-15 min" | grep -Ei "oom-kill|killed process"

Диск. Лимит в 20000 IOPS без размера блока, соотношения чтения и записи и глубины очереди это просто число. Те же 20000 при iodepth 32 ничего не обещают при iodepth 1, а именно так работает приложение, ждущее ответа на запрос. Файл сначала заполняют целиком, иначе чтение из пустых областей завысит результат.

fio --name=randrw --filename=/var/tmp/fio.test --size=4G \
    --rw=randrw --rwmixread=70 --bs=4k --direct=1 --ioengine=libaio \
    --iodepth=1 --time_based --runtime=120 --refill_buffers=1 \
    --group_reporting --percentile_list=50:95:99:99.9

Затем тот же вызов с iodepth 32 и проверка в разделе IO depths, достигнута ли глубина. Сохраняйте IOPS и процентили clat, а не среднее. Один прогон шумного соседа не покажет, нужны три в разные часы. Растущий p99 при стабильной медиане это и есть нестабильность.

Как сравнивать? Не складывайте IOPS, миллисекунды и баллы в один рейтинг. Сначала отсеките тарифы, не проходящие пороги приложения, потом расставьте веса: базе важнее p99 диска, агенту сборки процессор, медиасервису исходящая полоса. Для каждого прогона сохраняйте дату, локацию, образ, версии утилит и команду.

Универсального первого места нет. Есть тариф, проходящий ваши пороги трижды подряд в разное время суток.

Инфраструктура для разработки на гиперскорости: сервисы самообслуживания и MCP в HyperDrive

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

На вебинаре покажем, как Internal Developer Platform меняет эту модель: разработчик получает готовую инфраструктуру через каталог стандартных сценариев, а DevOps-инженер управляет платформой, шаблонами и политиками.

Ключевые темы:

• Почему инфраструктура стала главным ограничением скорости разработки

• Почему модель «разработчик → тикет → DevOps» больше не масштабируется

• Что такое Internal Developer Platform на практике

• Как меняются роли DevOps и ИБ

• Как ИИ-агент безопасно и предсказуемо взаимодействует с инфраструктурой через Model Context Protocol

• Живое демо новой IDP-функциональности в HyperDrive: создание окружения, self-service, GitOps, встроенные политики безопасности и путь от запроса до готовой инфраструктуры

Кому будет полезно:

• CTO

• CIO

• Head of Platform Engineering

• Head of DevOps

• Руководителям разработки

• Platform Team

• DevOps-инженерам

Спикеры:

Павел Лавров
Лидер продукта HyperDrive, Orion soft

Даниил Рахновский
Архитектор продукта HyperDrive, Orion soft

Регистрация по ссылке

Облако для продакшена. Что показывают steal, await и реальная полоса?
Два провайдера, одинаковая строка в тарифе: 4 vCPU, 8 ГБ, 100 ГБ SSD, гигабит. Цена расходится на 15 процентов, и непонятно почему. Через неделю тестов выясняется, что p99 отличается в разы. Тариф описывает то, что выделено виртуально. Что происходит в железе, туда не попадает.

Почему синтетика не отвечает на вопрос? Geekbench и sysbench меряют потолок за короткий тест. Продакшен работает иначе: нагрузка неровная, соседи по ноде непредсказуемы. Провайдеры делают оверкоммит, и пока суммарная нагрузка умеренная, все хорошо. Стоит нескольким машинам дать всплеск разом, растет steal, удлиняется дисковая очередь, канал упирается в шейпер. Короткий тест может не попасть в это окно. Нужно от получаса нагрузки, а на суточные паттерны от 24 часов.

CPU steal. Steal это доля времени, когда vCPU готов работать, но гипервизор не дает ему физическое ядро. Приложение получает задержку без видимой причины: процессор загружен, работа не идет.

vmstat 1 30

procs -----------memory---------- ---cpu---
 r  b   swpd   free   buff  cache  us sy id wa st
 2  0      0 512344  81920 210488  31  4 58  1  6

Колонка st справа. Шесть процентов несколько строк подряд это не шум. Разбивку по ядрам дает mpstat -P ALL 1 10, длинный срез пишут в файл через sar -u 1 3600 и сравнивают часы между собой.

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

Для транскодирования и компиляции steal переводится во время выполнения почти линейно. Для API и запросов к базе иначе: медиана держится, а p99 растет, потому что в моменты steal запросы копятся в очереди. Отдельная история это всплески до 20 процентов на пару секунд при спокойном фоне. Такой скачок опаснее ровного высокого steal, он тянет каскад таймаутов.

Диск. Публикуемые IOPS измерены в идеальных условиях и под смешанной нагрузкой мало о чем говорят. Мониторинг запускают параллельно с тестом.

iostat -xz 1 10

В выводе важны два числа: await это время запроса вместе с ожиданием в очереди, avgqu-sz это глубина очереди. Растет второе, следом первое. Профиль OLTP проверяют так:

fio --name=rand4k --rw=randrw --rwmixread=70 --bs=4k --direct=1 \
    --numjobs=4 --iodepth=32 --size=4G --runtime=60 \
    --time_based --ioengine=libaio --group_reporting

Флаг direct обязателен, без него тест уедет в страничный кеш и покажет память вместо диска. В отчете смотрите iops и clat p99, именно второе объясняет хвосты запросов. Ориентир для средней базы это 5000 IOPS на чтении 4К при await ниже 2 мс, для нагруженной 20000 при await ниже миллисекунды.

Очередь выше восьми под OLTP это первый признак насыщения. Загрузка под 100 процентов для SSD не приговор, тревожно когда вместе с ней растет await. У дисков с лимитом IOPS порог срабатывает раньше насыщения железа, и покажет это именно await.

Сеть. Заявленный гигабит это верхний предел, а не гарантия. Шейпинг под нагрузкой в документации обычно не описан.

iperf3 -c 10.0.0.5 -t 60 -P 4
mtr --report --report-cycles 100 10.0.0.5

Четыре потока нужны потому, что один упирается в размер окна и RTT, а не в канал. Минута нужна, чтобы поймать burst лимит: полная полоса первые пятнадцать секунд и просадка дальше это он. Потери на одном промежуточном хопе при чистом трафике дальше это деприоритизация ICMP роутером. Потери подряд на нескольких хопах уже другое.

Проверьте MTU. Overlay сети добавляют заголовок к каждому пакету, 1500 превращаются в 1450, а пакеты с флагом DF молча теряются.

ping -M do -s 1472 10.0.0.5

Порядок проверки. Срез в покое сразу после деплоя, он же точка отсчета. Затем steal под боевой нагрузкой. Дальше fio с профилем приложения и iostat в соседнем терминале. Потом сеть. И наблюдение сутки или трое, иначе суточный паттерн конкуренции пройдет мимо.

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

Друзья, я просто обязан сказать огромное спасибо всему сообществу Хабра за вашу поддержку и активность под статьей о моем проекте Kakehashi!

Вдохновившись вашими отзывами, вчера вечером я опубликовал проект на Hacker News. Результат превзошел все ожидания: прямо сейчас тред держит 204 поинта, а репозиторий набрал более 220 звезд на GitHub.

Проект попал в радар к хардкорным системщикам со всего мира. Среди тех, кто дал звезду, оказались инженеры из команд Cursor, Fly.io, Astro, создатель пакетного менеджера Pixi, разработчик Redox OS и в дискуссии на HN был легендарный автор утилиты Cydia @saurik.

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

Огромное вам спасибо! 

P.S. Хотел опубликовать в хаб «Я пиарюсь», но интерфейс не пропустил из-за нехватки кармы (нужно 30). Поэтому публикую в профильные хабы как апдейт к прошлой статье. Надеюсь на понимание!

Проект: https://github.com/wie-project/kakehashi

Статья на Хабре: https://habr.com/ru/articles/1065502/

Пост на Hacker News: https://news.ycombinator.com/item?id=49145937

🔥 Основы FastAPI: собираем сервис «прочитать позже»

У каждого есть свалка ссылок «прочитаю потом»: 40 вкладок, сохранёнки в Telegram, закладки с 2022 года. Проблема не в том, что нечего читать, — а в том, что всё это невозможно найти и разгрести.

Решим по-инженерному: напишем свой Read-Later сервис и с нуля освоим FastAPI.

6 августа, 19:00–20:30 МСК — бесплатный воркшоп с Ольгой Пичужкиной, Middle Python Developer (S-Cats).

За 1.5 часа:
⚡️ Поймёте, что такое FastAPI и почему он удобен
🧱 Опишете модель данных (SQLAlchemy + Pydantic)
🔁 Напишете полный CRUD
🔍 Научитесь фильтровать через query-параметры
📄 Получите Swagger UI бесплатно
🌐 Подключите простой фронтенд

Для кого: знаете Python, но ещё не писали API.

🛠 Куда дальше — дорожная карта: FastAPI — не просто фреймворк. На нём построен наш MCP Knowledge Server (Qdrant + семантический поиск) — ядро AI-ассистента сообщества, который «помнит» всё изученное.

Цепочка: 🐳 Docker (25.07) → 🐍 FastAPI (06.08) → 🧠 MCP Knowledge Server (сентябрь). В сентябре — отдельный воркшоп: поднимем такой сервер вместе.

📖 Pre-read: за 3 дня до воркшопа — инструкция по установке uv и Python.

🔗 Подробнее: https://debugskills.ru/content?article=labs-fastapi-workshop

#DebugSkills #FastAPI #Python #Backend