DevOps *

🔖 AI больше не стыдно?

Обратили внимание, как быстро мы прошли фазу от «фууу, это нейрослоп» до состояния, когда уже даже лютые AI‑нигилисты сдулись?

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

Нас приучили к тому, что AI теперь с нами везде, надолго и уходить никуда не собирается.

Если ещё полгода назад тебе приносили пуллик со словами «я тут нагенерил нейронкой, можете поревьювить?» — и у тебя от такого полыхало внутри, то теперь зайти с пулликом в вообще незнакомый бизнес‑домен не только нормально, но и даже приветствуется.

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

Теперь порог входа почти исчез.

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

И с одной стороны — это офигенно.

Количество вещей, в которые ты потенциально способен залезть, выросло на порядок. Границы между «моё» и «я в этом ничего не понимаю» становятся сильно тоньше.

Но есть и обратная сторона.

AI очень хорошо убирает ощущение собственного незнания.

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

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

А понимание при этом могло вообще не появиться.

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

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

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

—
Telegram | Github | YouTube | X

14 уроков для системных администраторов, которым мало просто «чтобы работало»

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

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

В этом посте собрали 14 бесплатных уроков для тех, кто хочет увереннее работать с серверами, сетями, Kubernetes, мониторингом и безопасностью.

Linux и Windows

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

• 23 сентября в 20:00. «Linux на практике: безопасный доступ к серверу и автоматизация через SSH». Записаться

• 24 сентября в 19:00. «Сможет ли ИИ починить Linux‑сервер: где заканчиваются подсказки и начинается инженерная диагностика». Записаться

Диагностика и наблюдаемость

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

• 14 октября в 20:00. «ИИ для мониторинга: что Prometheus и Grafana могут рассказать агенту». Записаться

• 20 октября в 20:00. «OpenTelemetry в.NET: от чёрного ящика к наблюдаемой системе». Записаться

Kubernetes и автоматизация инфраструктуры

• 1 октября в 20:00. «Kagent + Ollama: ИИ‑агент для работы с Kubernetes». Записаться

• 7 октября в 20:00. «GitOps‑практики: развертываем сервис через ArgoCD». Записаться

• 15 октября в 20:00. «Поднимаем кластер Kubernetes с помощью Terraform и Ansible». Записаться

Трафик, отказоустойчивость и веб‑инфраструктура

• 22 сентября в 20:00. «Автоматизация управления трафиком с mitmproxy». Записаться

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

• 5 октября в 19:00. «Автоматические TLS‑сертификаты: модуль ACME (Angie)». Записаться

• 20 октября в 19:00. «Балансировка HTTP и L4 сервисов в Angie». Записаться

Безопасность инфраструктуры

• 21 октября в 20:00. «Пентест инфраструктуры: поиск слепых зон IDS/IPS». Записаться

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

Что можно почитать по теме:

1. «Ваш docker‑compose.yml сломается: 5 настроек, которые все забывают»

2. «Разбираемся с форвардингом IP‑пакетов в сетевых уровнях L2 и L3»

3. «Как выстроить доверенный TLS в Kubernetes без InsecureSkipVerify»

5 причин посетить GoCloud Tech 2026 очно, помимо докладов

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

💻 Воркшопы — берите ноутбук и решайте прикладные задачи вместе с экспертами Cloud.ru, если что-то не получится, обязательно разберем почему.

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

🧪 Лаборатория решений — компьютерный клуб, где можно выбрать готовый сценарий и протестировать сервисы Cloud.ru на практике.

🚀 Лаборатория карьеры — место для знакомства с культурой нашей компании, новыми ИТ-профессиями и карьерными путями.

💡 Доска инженерных решений — находите знакомую проблему и забирайте карточку с решением, чтобы не забыть обсудить его со своей командой.

Ждем всех, кто двигает технологии в эпоху искусственного интеллекта.

📍 Где: Москва, ул. Волочаевская, 48, стр. 1 (м. Площадь Ильича), Loft #8 (ДК «Серп и молот»).

📆 Когда: 15 октября.

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

Дайджест: новости за август 2026

Рассказываем, какие изменения произошли на платформах Cloud.ru в августе и чем это может быть полезно. 

🤖 Cloud.ru Agents Space — новое пространство для работы с ИИ-агентами
Агент умеет планировать задачи, работать с документами и инструментами, подключаться к сервисам. Сложная настройка не нужна: можно сразу поручить ему поиск информации, подготовку материалов или другие повседневные задачи. Меньше переключений между инструментами — больше времени на саму работу. 

🧠 AI Factory
Evolution Notebooks — ноутбуки теперь можно создавать с root-доступом к GPU. Это дает больше свободы при настройке окружения, установке системных зависимостей и проведении ML-экспериментов.

Evolution Managed RAG — появилась фильтрация чанков по метаданным. В поиск можно не пропускать нерелевантные фрагменты — меньше шума в контексте, точнее ответы модели. Интеграция с «Менеджером ресурсов» помогает централизованно отслеживать ресурсы сервиса.

Evolution Distributed Train — запустили бесплатный трекинг экспериментов в режиме Public Preview. Он совместим с wandb SDK: можно логировать метрики и параметры, сравнивать запуски на графиках, хранить артефакты и их версии. Раздел «Эксперименты» отключен, поэтому самое время перейти на новый трекинг.

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

☁️ Cloud.ru Evolution
Evolution Managed Kubernetes — добавили Traefik и Kgateway для маршрутизации и управления трафиком L4/L7, включая HTTP, HTTPS, TCP и gRPC. Обновили GPU Operator до 26.3.3 и Cilium до 1.19.5.

Важно: с 1 октября балансировщики нагрузки v1 автоматически конвертируются в v2, а со 2 ноября начнут тарифицироваться по новой версии. Лучше заранее проверить конфигурации.

Провайдер Terraform — добавили управление кластерами Evolution Data Platform, multiAZ для Evolution Managed Redis, npm-реестры в Evolution Artifact Registry и GroupMembership для связи пользователей с группами. Параметр endpoints теперь необязателен: актуальные адреса public API подставляются автоматически. Меньше ручной конфигурации и расхождений между окружениями.

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

Evolution Managed OpenSearch — стала доступна версия 2.19.5. Поддержка 2.18.0 прекращена — учтите это при планировании обновлений.

🏢 Cloud.ru Advanced
В Advanced Cloud Container Engine добавили Kubernetes 1.35 и автоматическое обновление кластеров с версии 1.34. Для CCE Turbo стала доступна DataPlane V2, а сертификат теперь можно ротировать при обновлении кластера. Также закрыли уязвимости повышения привилегий Copy Fail и Dirty Frag.

🖥 Облако VMware
Квотой ресурсов VDI теперь можно управлять самостоятельно из личного кабинета — без заявок в поддержку. Для дисков ВМ зафиксировали минимальную производительность: 1 000 IOPS на уровне Gold и 3 000 IOPS на Platinum. Предсказуемая дисковая производительность особенно важна для нагруженных баз данных и корпоративных приложений.

📽️Вебинары и обучение
Выложили анонсы вебинаров на сентябрь и записи прошедших встреч: 

• ИИ-проекты: когда и как переходить от API к Bare Metal;

• Как ИИ помогает создавать и сопровождать Spark-задачи в облаке;

• Как построить управляемый Data Lakehouse за неделю на Evolution Data Platform. 

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

💼 Свежие кейсы

Рассказали, как застройщик «Страна Девелопмент» ускорил работу, благодаря переносу ресурсов в облако и организации удаленных рабочих мест с GPU-мощностями для проектировщиков. Продемонстрировали, как облако помогает выдерживать наплывы телезрителей, на примере стримингового сервиса Okko.

До связи! ✌️

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

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

Обсуждаем это всё в новом подкасте #Криптонит_говорит о системных инженерах!

Смотрите на любой удобной платформе:

• VK Видео

• YouTube

• Rutube

• Подкаст в telegram

• Я.Музыка

В выпуске приняли участие:

• Александр Телевной, директор департамента инфраструктуры в «Криптоните»;

• Артём Пузанков, руководитель отдела консалтинга безопасной разработки в «Бастионе»;

• Иван Морщагин, ИТ-консультант

Программа конференции GoCloud Tech 2026 уже на сайте

Зарегистрировались на конференцию для тех, кто двигает прогресс в эпоху искусственного интеллекта? Самое время выбрать свой трек: 

В треке «Инфраструктура»
Расскажем, как устроена облачная инфраструктура и как она меняется с ростом ИИ-нагрузок. Обсудим безопасность, отказоустойчивость и инженерные компромиссы при создании инфраструктурных сервисов.
Ждем: архитекторов, инженеров, DevOps и SRE, системных администраторов, технических лидеров и всех, кто проектирует, развивает или эксплуатирует облачную инфраструктуру и ИИ-платформы.

В треке «Разработка»
Обсудим, как меняется процесс разработки платформ с приходом ИИ. Обсудим безопасность, разработку собственных решений и границы возможностей ИИ-агентов.
Ждем: техлидов, backend-разработчиков, DevOps и SRE, AppSec-специалистов и всех, кто внедряет ИИ в разработку, строит внутренние платформы и отвечает за production-надежность.

В треке «Данные и ML»
Поговорим, как строить платформы данных и ML-системы, готовые к работе с ИИ. Разберем архитектуру Lakehouse, Data Governance, защиту чувствительных данных и инфраструктуру для высоконагруженного доступа к моделям.
Ждем: дата-, ML- и ИИ-инженеров, архитекторов, продуктовых менеджеров и всех, кто работает с корпоративными данными, LLM и ИИ-сервисами.

Смотрите программу на сайте. 

Одна платформа для любых нагрузок: большое обновление Deckhouse

Контейнеры, виртуалки, ИИ-нагрузки, on-prem, облака и edge. Чтобы вам было проще запускать разные нагрузки в любых средах и решать инфраструктурные задачи, мы обновили продукты Deckhouse. На онлайн-трансляции 17 сентября вы узнаете, что именно изменилось и какие возможности это даёт инженерным командам:

• зачем мы объединили несколько продуктов Deckhouse в единую платформу;

• какие возможности появились для работы с распределённой инфраструктурой и гибридными средами;

• как Deckhouse помогает строить серверную виртуализацию, частные облака, платформы данных и инфраструктуру для ИИ-нагрузок.

Про изменения расскажут наши первые лица — CEO Александр Титов, CTO Давид Мэгтон и директор продуктовых направлений Карапет Манасян. Трансляция будет полезна, если вы управляете инфраструктурой в разных средах, развиваете платформенные решения или ищете способы упростить работу с разными типами нагрузок.

Зарегистрируйтесь и подключайтесь 17 сентября в 12:00 (МСК).

Хороший бэкап умеет не только сохранять, но и возвращать нужное

В большой инфраструктуре десятки тысяч машин, БД, контейнеров, платформ. И сценарии восстановления у всех свои: где-то нужно поднять всё с нуля, а где-то – вернуть один объект или несколько атрибутов. Российские вендоры последовательно движутся в сторону точности.

Свежий пример: в «Кибер Бэкапе Облачном» теперь можно выбирать отдельные объекты внутри Kubernetes. Резервируешь и восстанавливаешь только то, что действительно нужно, – не тащишь весь кластер ради одной ошибки.

Не просто «есть копия», а умение достать из неё именно то, что сломалось, и не трогать остальное.

Тот же принцип особенно важен для каталогов. В гетерогенных средах и особенно при миграции с AD на Linux инфраструктура становится сложнее: параллельные среды, скрипты, промежуточные состояния. И тут ошибка часто не убивает каталог целиком. Можно неверно изменить атрибуты пользователей, удалить группу, разорвать связи — система продолжит работать, но доступы поедут.

Восстанавливать весь каталог из полной копии — как из пушки по воробьям.

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

Простая логика для каталога: перед миграцией сделал копию, потом сравнил состояния и точечно исправил последствия.

И здесь Kubernetes и каталог оказываются ближе, чем кажется: бэкап ценен не только фактом наличия, но и тем, насколько точно ты можешь им воспользоваться, когда что-то пошло не так.

Источники:

«Киберпротект» расширил возможности «Кибер Бэкапа Облачного» для крупных гетерогенных инфраструктур

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

Безопасная разработка от кода до прода — новый бесплатный курс Cloud.ru

Кто-то считает безопасность головной болью ИБ-отдела и вспоминает о ней за день до релиза — когда править уже долго и дорого. Кто-то уверен, что контейнер — это просто «легковесная виртуалка», и удивляется, когда изоляция оказывается не такой уж изолированной. Безопасность часто воспринимают как отдельный этап в конце пайплайна, а не как часть жизненного цикла разработки. Чтобы глобально исправить это, мы собрали свой опыт провайдера облачных и ИИ-решений в экспресс-курс «Основы безопасной разработки в облаке» и сделали доступ к нему открытым.

⏳За один кофе-брейк (около 20 минут) вы можете узнать: 

• Как безопасность распределяется между этапами разработки, сборки, развертывания и эксплуатации приложения.

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

• Какие практики чаще всего приводят к инцидентам, и как их избежать с самого начала.

• Какие готовые сервисы безопасности закрывают типовые задачи защиты быстрее самостоятельной разработки.

Кому подойдет курс?

• ИТ-специалистам и DevOps-инженерам. Поможет встроить проверки безопасности в существующий CI/CD-конвейер и автоматизировать их без потери скорости релизов.

• Специалистам по ИБ и облачной безопасности. Структурирует модель угроз для облачных приложений и позволит говорить с разработкой на одном языке.

• Всем, кто интересуется кибербезопасностью. Систематизирует разрозненные знания об облаке в единую картину жизненного цикла.

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

Сделайте безопасность частью разработки, а не препятствием перед релизом!

Записаться на курс 👈

Сервис тормозит, а мониторинг ничего не показывает: разбираемся с eBPF

Сервис начал отвечать медленнее, пользователи жалуются на ошибки, а привычные дашборды показывают только рост задержек. Где искать причину, если приложение, сеть и инфраструктура выглядят «почти нормально»?

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

На открытом уроке курса «DevOps практики и инструменты» вместе с преподавателем разберём, как eBPF помогает исследовать сетевые взаимодействия, производительность и безопасность современных систем. Посмотрим, какие задачи он решает в реальной эксплуатации и где его применение действительно оправдано. Когда: 23 сентября в 20:00. Присоединяйтесь

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

Incident Management: почему компании живут от аварии до аварии

Давайте признаем, системы без аварий не существует. Вопрос даже не в том, случится ли инцидент, а в том, будет ли команда к нему готова? Что будет после инцидента: система станет лучше или просто вернётся в исходное состояние до следующего раза.

В новом выпуске «В SREду на кухне» вместе с Максимом Бурцевым, руководителем отдела мониторинга в e-commerce, разбираемся, чем отличаются команды, которые учатся на ошибках, от тех, кто забывает их как страшный сон.

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

Почему большинство инцидентов случаются сразу после релиза — и при чём тут овертаймы и дежурства. Как работать с Root Cause вместо того, чтобы латать одни и те же дыры по кругу. Кто должен управлять инцидентом в моменте и какие три вопроса нужно задать сразу после аварии. Сколько на самом деле стоит инцидент — и стоит ли рассказывать об этом пользователям. Отдельно — про AI: добавит ли вайб-кодинг новых аварий и может ли AI помочь ими управлять. В Авито уже попробовали — рассказали, что получилось.

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

Посмотрите этот выпуск, если ваша команда разбирает инциденты по принципу «нашли виноватого, закрыли тикет».

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