DevOps *

Подборка вебинаров на июль

Вы просили — мы сделали. Повторяем вебинары про работу с данными в облаке: от развертывания платформы до ETL-процессов и полноценной BI-аналитики. Регистрируйтесь, чтобы спросить экспертов о важных деталях и получить ответ.

Как развернуть платформу данных в облаке и подготовить данные для аналитики
Покажем, как быстро развернуть managed-сервисы Evolution Data Platform, подключить источники данных и построить пайплайны для подготовки данных к аналитике. Разберем интеграцию с PostgreSQL, ADB, S3 и настройку автоматического обновления — без долгого погружения в инфраструктуру.
🧑‍💻 Для кого: дата-инженеры, аналитики, архитекторы данных.
📅 Когда: 16 июля 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

ETL в облаке: от хаоса к управляемым процессам
Покажем, как выстроить надежную ETL-платформу в облаке на базе Evolution Data Platform. Разберем интеграцию разрозненных источников, управление метаданными и оркестрацию — и покажем всё это в live-демо: от извлечения данных до готовой витрины.
🧑‍💻 Для кого: дата-инженеры, DevOps, руководители дата-команд.
📅 Когда: 23 июля 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

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

Observability ИИ‑агентов: запустили Monium Traces в Yandex AI Studio

Теперь можно анализировать поведение ИИ‑агентов в Yandex AI Studio с помощью трейсов прямо в UI платформы. Трейсы показывают всю цепочку решений агента и контекст каждого шага — системные промпты, вызовы модели и инструментов, промежуточные результаты. Всё, что реально влияет на поведение агента.

Почему это важно
Observability для агентов устроена принципиально иначе, чем для обычных сервисов, где нам доступен дебаг по коду. В случае ИИ главный материал — большие тексты: системные промпты, сообщения пользователя, ответы модели, вызовы тулов. Даже когда инфраструктура может быть полностью «зелёной» — latency в норме, ошибок нет — агент может уверенно отдавать неверный ответ или уходить в бесконечный цикл вызовов. Классический мониторинг здесь не поможет: он не покажет, почему модель выбрала не тот тул или потеряла контекст.

Анализ трейсов:

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

• ускоряет отладку сложных сценариев

• повышает прозрачность работы агента

• позволяет точно локализовать узкие места в цепочке обработки запроса

В видео — как выглядит трейсинг в интерфейсе Yandex AI Studio:

Чтобы начать — откройте AI Studio, перейдите во вкладку «Логирование» и подключите отслеживание трейсов моделей и агентов.

От алерта к его причине за 10 минут — вебинар про ускорение диагностики инцидентов

Когда бизнес-сервис деградирует, причина может быть где угодно: в приложении, инфраструктуре, сети, базе данных или Kubernetes-кластере. Если метрики, логи и трассировки живут в разных системах, команда тратит ценное время не на устранение инцидента, а на сбор контекста: что сломалось, где началась деградация и какие ещё сервисы затронуты.

На вебинаре 17 июля покажем, как Deckhouse Observability Platform (DOP) связывает данные по инфраструктуре и приложениям в единую картину и помогает быстрее пройти путь «алерт → локализация → первопричина». В программе:

• Обзор новых возможностей DOP: APM, распределённый веб-мониторинг, система инцидент-менеджмента, SLA/SLO-дашборды и другое.

• Разбор задач эксплуатации и инфраструктурных команд: как быстрее находить причины сбоев и снижать риск пропустить критический инцидент.

• Демо: развёртывание мониторинга с получением первых данных «из коробки» без ручной настройки.

Спикер — Владимир Гурьянов, технический директор DOP, которого вы можете знать по множеству выступлений о наблюдаемости на конференциях. Регистрируйтесь и подключайтесь 17 июля в 12:00.

FinOps для гибридной инфраструктуры: как считать ЦОДы, облака, лимиты и AI-затраты

FinOps часто начинается с облачных счетов. Но в компаниях с гибридной инфраструктурой этого быстро становится мало.

В реальной модели затрат рядом оказываются on-prem, colocation, Kubernetes, сервисные команды, закупки железа, лимиты, ФОТ, лицензии, публичные облака и новые AI-проекты. Если всё это смотреть отдельными кусками, общий IT-бюджет вроде бы есть, а ответа на вопрос «куда именно уходят деньги» всё равно нет.

В новом выпуске «Практики FinOps» поговорили с Дмитрием Деевым (@Dimperus), руководителем отдела ИТ-инфраструктуры и сервисов компании «ВсеИнструменты.ру».

Обсудили, как перейти от общего бюджета к модели аллокации, зачем приводить on-prem к ежемесячной стоимости, почему команды не сразу привыкают к лимитам и как IT-департамент может перестать выглядеть только затратным подразделением.

В выпуске разбираем:

• чем ITFM отличается от классического FinOps;

• как считать гибридную инфраструктуру: ЦОДы, облака, colocation;

• почему on-prem нужно приводить к ежемесячной стоимости;

• как работают лимиты, ресурсные пулы и служба единого окна;

• зачем нужны теги, метаинформация и дашборды для владельцев бюджета;

• почему FinOps не всегда про экономию;

• как учитывать AI-затраты, GPU и новые инфраструктурные сценарии;

• куда может прийти FinOps через автоматизацию, алерты и LLM.

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

Смотреть выпуск
YouTube
Rutube
VK Видео

Слушать выпуск
Telegram Player (Mave)
Яндекс Музыка
VK Музыка

«Практики FinOps» — cообщество для тех, кто управляет затратами на IT-инфраструктуру и хочет обсуждать FinOps на практических кейсах. Мы в телеграм.

🔥 Docker для начинающих: от «что это» до своего контейнера за 4 часа

Docker используется везде: от локальной разработки до production. Фокус лабы — не на запоминании команд, а на понимании. Вы пройдёте путь от первого контейнера до настройки сетей и данных — своими руками. После лабы сможете уверенно обсуждать контейнеризацию с разработчиками, DevOps и архитекторами.

25 июля, 10:00-14:00 МСК | Максим Тачков, Middle Developer (BIM), преподаватель Docker. По отзывам с прошлой лабы: экспертиза 9/10.

5 блоков за 4 часа: (1) Основы Docker → (2) Сборка (Dockerfile) → (3) Управление (Compose, логи, мониторинг) → (4) Данные (volumes, bind mounts) → (5) Сети (Docker Network, DNS)

За 4 часа вы:

- 🐳 Освоите словарь Docker: image, container, volume, network, Dockerfile

- 🔧 Соберёте и запустите свой первый контейнер из Dockerfile

- 🛠 Научитесь управлять контейнерами через Docker Compose

- 📦 Настроите хранение данных через volumes и bind mounts

- 🌐 Настроите сетевое взаимодействие между контейнерами

Для кого: Backend, frontend, fullstack разработчики, QA-инженеры, системные и бизнес-аналитики, архитекторы, технические менеджеры. Нужно: базовый CLI, понимание веб-приложений, VS Code.

🎬 Запись — 20%. Живая практика с ведущим, ответы на вопросы, разбор ошибок — только на лабораторной.

📖 Pre-read: за 3 дня до лабы высылаем шпаргалку по Docker-командам — подготовьтесь заранее и не теряйте темп.

🛠️ Makefile как «пульт управления» — одна команда = одно действие. Фокус на понимании, а не на синтаксисе CLI.

🚀 Дальнейший маршрут: Kubernetes → REST+OpenAPI → Keycloak → Kafka → Prometheus+Grafana.

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

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

Собрать данные с датчиков — это полбеды. Главная боль — заставить Kafka, PostgreSQL и ClickHouse стабильно работать в приватном облаке без выгорания команды на Day-2-операциях и ручном масштабировании stateful-сервисов.

На вебинаре покажем, как на Deckhouse Kubernetes Platform (DKP) и managed-сервисах упаковать IoT-сценарии и аналитический контур в единую платформу, чтобы снизить стоимость эксплуатации и уйти от DIY-подхода к data-инфраструктуре.

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

В программе:

• Разберём схему event-driven-платформы и разделение операционного и аналитического контуров.

• Покажем live-demo: ingest событий с датчиков, потоковая обработка и вывод в дашборды.

• Проверим, как паттерны из умного дома масштабируются до промышленного IoT на DKP.

• Разберём жизненный цикл data-сервисов (backup, scaling, observability) и то, сколько времени занимает их обслуживание.

Бонусы: промокод на все курсы Deckhouse Академии.

Будет полезно DevOps и SRE-инженерам, инфраструктурным и платформенным командам, enterprise-архитекторам и всем, кто строит IoT- и data-платформы в private cloud или on-prem.

Спикер — Дмитрий Гайворонский, менеджер по развитию направления Deckhouse Data Orchestration.

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

Вы пробовали ChatGPT и Cursor. Но система из нескольких AI-агентов — это другой уровень: агенты конфликтуют, теряют контекст, зацикливаются, а отладка напоминает расследование без улик.

🎻 Один AI = музыкант. Несколько AI = оркестр. А кто дирижёр?

19 июля, 10:00-14:00 МСК — лабораторная работа с Андреем Чуяном, создателем ROLES-экосистемы (3 экосистемы, 15+ ролей). За 4 часа: проектирование AI-ролей с YAML-контрактами, 5 хаос-сценариев, MCP-сервер на личной VM, самодиагностика экосистемы.

📐 Проверенная методология FPF + TDD в основе каждого блока.

🔗 Подробное описание: https://debugskills.ru/content?article=labs-ai-orchestration
Готовы спроектировать свою первую AI-экосистему? Приходите 19 июля! 🚀

Релиз ≠ деплой: почему прод падает именно после обновлений

Большинство крупных инцидентов происходят сразу после релиза. Не во время нагрузочного теста, не в случайный вторник — а именно тогда, когда команда только что что-то выкатила и выдохнула. Почему так, если всё прошло тестирование?

В новом выпуске «В SREду на кухне» вместе с Артёмом Гетманским, техруком юнитов в Авито, и Андреем Мухиным, TechLead из MWS, разобрались: что вообще считается релизом, чем он отличается от деплоя — и как не превратить каждое обновление в рулетку.

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

Оказывается, релиз может сломать прод даже без единой строчки нового кода — и это не баг, а особенность современных систем. Разбираем, как Feature Flags, Canary, Blue-Green и Rolling-стратегии помогают снизить риск, когда hotfix тоже считается релизом и что с этим делать, и как error budget влияет на то, насколько смело команда вообще решается катить изменения.

Отдельно досталось вопросу, должны ли SRE участвовать в продуктовых релизах — и у участников выпуска на этот счёт нашлись весьма конкретные мнения.

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

Что почитать по инфраструктуре: Docker, K8s, сети и защита серверов

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

Ваш docker-compose.yml сломается: 5 настроек, которые все забывают
Локально всё крутится, на сервере неделю тоже — а потом Postgres съедает всю память, OOM-киллер убивает соседний сервис, а логи забивают диск. Всё лечится парой строк в compose-файле, но про них забывают: на машине разработчика они просто не проявляются. Разбираем пять настроек, без которых compose не доживёт до второй недели на проде.

Прощай, Fail2Ban: усиливаем защиту Netbird и Caddy с CrowdSec
Fail2Ban десять лет был золотым стандартом, но он реактивен: чтобы он сработал, атакующему сначала нужно постучаться в ваш SSH пять раз. А что, если блокировать вредоносные IP ещё до того, как их трафик дойдёт до сервера? История о переходе на CrowdSec с пошаговыми примерами кода — и о том, как «шум» от атак упал на 99%.

Разбираемся с форвардингом IP-пакетов в сетевых уровнях L2 и L3
Чем коммутатор отличается от маршрутизатора, зачем нужен TTL, как устроена CAM-таблица и почему без ARP ваш пакет никогда не доедет до получателя. Спокойный разбор основ, который наводит порядок в голове — для тех, кто хочет наконец перестать путать L2 и L3.

Self-service деплой: как перестать ждать DevOps и ускорить команду
Знакомая картина: разработчик полчаса висит в Slack, ожидая, пока кто-то накатит сборку на стенд. С ростом команды DevOps-инженер становится единственным шлюзом между кодом и продакшеном — и это горлышко съедает до 30% времени. Tech Lead рассказывает, как self-service платформа убирает узкое место, с кейсами Monzo и Spotify.

Kubernetes: архитектура и абстракции — полный гайд
K8s называют стандартом, но понимание его механик встречается редко. Control Plane и Worker Nodes, Pod, Service, Deployment, Namespace — «прожиточный минимум» абстракций, без которых нельзя выходить в прод. Плюс отрезвляющая история о том, как Tinder год переезжал на кластер из 1000 узлов и что у них при этом ломалось.

От capabilities к AppArmor: что реально остановит атакующего в контейнере
Уязвимость в веб-приложении, злоумышленник уже выполняет команды внутри контейнера — что именно его остановит? На одной и той же рабочей нагрузке показано, как последовательно срабатывают три слоя защиты: capabilities, seccomp и AppArmor. Где каждый помогает, где бессилен и почему работать они должны только вместе.

Хотите системно закрыть пробелы по инфраструктуре? Собрали большой дайджест по Linux, Docker, Kubernetes, CI/CD и сетевой безопасности: бесплатные уроки, практические гайды и курсы — всё в одном месте.

Как я в Zabbix мониторю аккаунт в REG.RU: баланс, неоплаченные счета и сроки всех услуг - через API reg.ru

Домен можно сторожить по WHOIS: взял имя, посмотрел дату, повесил триггер «истекает через 30 дней». Но WHOIS видит ровно один домен и ничего вокруг. Он не знает, что на счёте кончились деньги, что висит неоплаченный счёт, из-за которого услугу снимут раньше срока, что в том же аккаунте ещё десяток доменов, SSL и хостинг. Поэтому я опрашиваю не WHOIS, а биллинговый API самого регистратора - он отдаёт весь аккаунт целиком. Собрал из этого шаблон под Zabbix 7.0, MIT. Расскажу, как он устроен и что в нём, на мой взгляд, сделано правильно.

Архитектура Три HTTP-айтема ходят в api.reg.ru - список услуг, неоплаченные счета и баланс - и складывают сырой JSON. Дальше всё считается из него: dependent items тянут баланс, сумму и число счетов через JSONPath, а LLD разворачивает прототипы под каждую услугу (ненужные типы отсекаются макросом-регуляркой). Каждая цепочка начинается с error_handler - битый или пустой ответ API не роняет айтем, а подставляет безопасное значение. На весь аккаунт получается несколько запросов в час, а не отдельная проверка на каждую услугу.

Что считаю правильным дизайном - две цепочки зависимостей Первое - nodata. Когда API регистратора отваливается целиком, каждый триггер «нет данных» (услуги, счета, баланс) хочет сработать сам, и ты получаешь пачку алертов про одну причину. Я завязал nodata услуг и счетов на корневой «No data from balance API». Полный отвал API теперь - один алерт, а не три. Корень я специально оставил без зависимостей, чтобы случайно не завязали и его, - об этом есть комментарий прямо в шаблоне.

Второе - сроки. На каждую услугу не один триггер, а каскад: ИСТЕКЛА (Disaster) → ≤7 дней (High) → ≤14 (Warning) → ≤30 (Info). Каждый уровень зависит от более тяжёлого. Поэтому услуга, которой осталось три дня, даёт один алерт High - а не три штуки (Info, Warning, High) одновременно. По мере приближения срока ты видишь ровно один триггер нужной серьёзности.

Для работы API, необходимо прописать разершенные IP в кабинете https://www.reg.ru/user/account/settings/api/, в настройках API задать адьтернативный пароль, и сохранить в макрос хоста {$RR_PASSWORD} как Secret. Логин - {$RR_USERNAME}. Для рег.облако взять API в https://cloud.reg.ru/panel/settings и сохранить в {$RRC_API_KEY}

Итог Баланс, неоплаченные счета и сроки всех услуг - под алертами в одном дашборде, без отдельного демона-прослойки. В репозитории два шаблона: разобранный выше под api.reg.ru (домены, хостинг, SSL) и отдельный под облачный api.cloudvps.reg.ru - там к балансу и срокам добавлен мониторинг самих VPS: реглеты, снапшоты, сети. Шаблоны, README и changelog - GitHub, PR и issues welcome.

А чем вы следите за биллингом у провайдеров и регистраторов - дёргаете API, или живёте на письмах «ваша услуга истекает»?

Подключайтесь к вебинару — покажем, как автоматизировать управление сложной инфраструктурой

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

На вебинаре расскажем, как собрать весь зоопарк решений в единую систему с помощью MWS B2B Store. Разберем деплой инсталляций, когда разные ноды находятся на разных инфраструктурных провайдерах, доставку и обновления в закрытых контурах, версионирование и распространение внутренних и внешних решений.

В прямом эфире в режиме демо покажем:

• Деплой сервисов (VMware + K8S) для разных сред, имплементацию Terraform as a service.

• Автоматическое развертывание в изолированные контуры: от стандарта упаковки до «раскатки» в гибридную инфраструктуру.

• Как управлять лицензиями на серверное ПО и контролировать, кто, где и сколько использовал.

• Работу с инстансами из разных инфраструктур в едином окне: мониторинг, аудит и управление жизненным циклом.

Будет полезно CTO, DevOps, директорам по инфраструктуре и тимлидам инфраструктурных команд.

📅 Когда: 30 июня в 11:00 мск.

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

Новая лабораторная уже в субботу 27 июня! 👩‍🔬 Учимся проектировать API 🛠

Подробнее: https://debugskills.ru/content?article=labs/openapi-rest

Получить доступ: https://boosty.to/polnyistek

Лето и ИТ: как их совместить с прицелом на будущее? Отправьте резюме к нам в SSP SOFT

Про нас как работодателя: компания SSP SOFT работает в сфере заказной разработкой ПО и предоставляет выделенные команды по модели ИТ-аутсорсинга для крупных клиентов. Размер компании — мы «средний бизнес» с числом сотрудников около 500 человек, и с проектами федерального уровня.

Рабочие места у нас в московском офисе, в ЦАО у самой Красной площади. А еще вакансии в департамент в Томске и почти всегда на «удаленку» из любой точки России.

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

Почему вам у нас понравится:
— Здесь интересно применять знания на реальных проектах, а не просто «отрабатывать ставку»
— Здесь не боятся обсуждать сложные вопросы
— Здесь работа оставляет силы на семью, хобби и желание развиваться

Что мы даем взамен:
— Гибкость: удаленка, офис в Москве или Томске, гибридный формат
— Поддержку здоровья и обучения (ДМС и курсы по твоему выбору)
— Атмосферу, где твое мнение важно

📢 Мы ищем прямо сейчас (актуальность проверяйте по ссылке на хх ниже):

1️⃣ DevOps Engineer (MLOps)
2️⃣ Ведущего аналитика 1С (финансовый контур, КТ 2000)
3️⃣ Функционального архитектора 1С
4️⃣ SAP WMS Консультанта
5️⃣ Tech Lead (финтех, инвестиции)

Подробности о вакансиях читайте на нашей странице ХХ.ру, но там откликаться необязательно. Ждем резюме напрямую в ЛС нашей HR Lead (https://t.me/AONikitina).
Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».

Желаем всем хабровцам успешной карьеры в 2026 году 🚀

Зачем провайдеру помогать клиенту снижать счёт за облако

Обычно всё растёт постепенно: сервисов стало больше, команды активнее используют инфраструктуру, появились новые тестовые среды, где-то добавились AI-нагрузки, где-то остались временные инстансы после задачи.

Потом приходит счёт, и начинается разбор.

— Кто создал ресурс?
— Он ещё нужен?
— Можно ли его выключить?
— Почему рост увидели только в конце месяца?
— Кто должен отвечать за такие расходы: финансы, инженеры, продуктовая команда или владелец сервиса?

На этом месте появляется ещё один вопрос, уже к рынку:

зачем облачному провайдеру помогать клиенту платить меньше?

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

В новом выпуске «Практики FinOps» мы поговорили об этом с Александром Либкиндом, руководителем направления развития сервисов управления затратами в Cloud.ru.

О чём выпуск

Разговор получился не про разовые скидки и не про универсальный способ «порезать облако».

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

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

Какие вопросы разобрали

• почему FinOps в России развивается медленнее, чем на западных рынках;

• зачем Cloud.ru помогает клиентам снижать счета;

• где обычно находятся первые 15–30% экономии;

• почему отчёт раз в месяц плохо работает для управления затратами;

• чем FinOps для AI отличается от классического FinOps;

• почему автоматические рекомендации не решают проблему без владельцев ресурсов и процессов;

• как компании проходят этап Inform и почему на нём часто начинаются сложности.

Для кого выпуск

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

Смотреть выпуск:
YouTube
Rutube
VK Видео

Мы в телеграм. Подписывайтесь.

Открытые уроки для прокачки: Linux, backend, ИИ, безопасность и управление

Эта неделя хорошо закрывает сразу несколько рабочих зон: инфраструктуру, backend, безопасность, ИИ, аналитику и управление. Темы подобраны так, чтобы за один открытый урок можно было не просто «послушать про тренды», а разобраться в конкретной задаче: от cache и swap в Linux до проектирования аутентификации, SRE-инцидентов, NLP и системного анализа.

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

Linux, DevOps и инфраструктура

• 22 июня, 20:00. «Память в Linux. Cache, swap, dirty pages». Записаться

• 22 июня, 20:00. «Роль и задачи DevOps в современном IT». Записаться

• 24 июня, 20:00. «Инцидент-менеджмент в SRE. Как быстро находить, устранять и предотвращать сбои в системе». Записаться

• 25 июня, 19:00. День открытых дверей курса «Администратор Linux. Продвинутый уровень». Записаться

Backend и разработка

• 22 июня, 20:00. «Контейнеризация Java-приложений с Docker». Записаться

• 24 июня, 20:00. «RabbitMQ против Kafka — что выбрать для вашей структуры: сравнение и лучшие практики». Записаться

• 24 июня, 20:00. «Отказоустойчивый и высокодоступный кластер RabbitMQ». Записаться

• 25 июня, 20:00. «Кеширование в ASP.NET Core: от IMemoryCache до Redis». Записаться

Информационная безопасность

• 22 июня, 20:00. «OAuth 2.0, JWT и коварные куки: проектируем безопасную аутентификацию». Записаться

• 22 июня, 20:00. «Киберпанк для CISO — щит и меч ИИ». Записаться

• 22 июня, 20:00. «Анализ журналов событий ОС Windows». Записаться

ИИ, ML и NLP

• 22 июня, 20:00. «Продвинутое структурирование промптов: как получать предсказуемый результат». Записаться

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

• 23 июня, 20:00. «Обзор инфраструктуры Ollama». Записаться

• 25 июня, 18:00. «Ландшафт современного NLP: от эмбеддингов и классических ML-методов до современных LLM». Записаться

Data, аналитика и базы данных

• 23 июня, 20:00. «ClickHouse: интеграция с Postgres, Kafka, S3 и Superset — готовые решения». Записаться

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

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

• 25 июня, 20:00. «Какие навыки прокачать, чтобы стать экспертом в системном анализе в 2026 году». Записаться

Управление, продукт и Agile

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

• 24 июня, 20:00. «Ретроспектива в Agile: что это, нужна ли она и как сделать её полезной». Записаться

• 24 июня, 20:00. «Топ-навыки менеджера продукта в 2026 году». Записаться

• 24 июня, 20:00. «Кто такой COO и почему он нужен сейчас». Записаться

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

▶️ История USmall — хайлоад изнутри

6+ млн товаров, 130 ритейлеров и до 70 млн запросов во время распродаж. Мигрировали USmall в наше облако и записали видеокейс о том, как устроена инфраструктура такого проекта.

Из любопытного:

1️⃣ 130 площадок — 130 изолированных контуров. На каждую свой репозиторий и Docker-образ. Релизы независимы, все изменения изолированы.

2️⃣ Свой механизм иерархических подов. В основе паттерн одноразовых подов — каждый выполняет один цикл и завершается. Поверх него команда построила иерархию, где родительский под запускает дочерние. Так обходят ограничение Python по пропускной способности одного воркера и обрабатывают задачи параллельно.

3️⃣ Выделенный сервер под оркестратор. Когда Airflow потребовалась отдельная конфигурация, под него собрали сервер на двух 32-ядерных процессорах и перенесли без простоя.

4️⃣ AI прямо в Kubernetes-кластере. В тестовом режиме крутится нейросеть, которая ускоряет подключение новых магазинов.

Все это команда ведет сама — новые ноды добавляет за пару минут через панель, без отдельных DevOps-инженеров. А инфраструктура у нас вышла на 35% дешевле прежнего провайдера — при том же объеме.

В видео Станислав, руководитель Python-разработки USmall, рассказывает про архитектуру и почему выбрали наше облако.

Смотреть видеокейс на ютубе, рутубе и в вк.

Или читать подробный разбор на сайте →

Многодоменная архитектура: почему бэкап одного домена не восстанавливает сервис

В инфраструктурных проектах иногда возникает идея разделить окружение на несколько доменов:

• пользователи – в одном контуре;

• серверы и рабочие станции – в другом;

• тестовая среда – в третьем.

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

Но в эксплуатации важен не только вопрос «где лежит объект».

Важнее другое: какие зависимости связывают объекты между собой.

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

Сценарий

Пользователь – в домене A.
Рабочая станция – в домене B.
Группа доступа к приложению – в домене C.

Цепочка доступа:

учётная запись → группа → DNS → доверие между доменами (Kerberos) → права на сервере.

Каждый компонент по отдельности может выглядеть исправным:

KDC отвечает. LDAP-серверы доступны. DNS разрешает имена. Билеты выдаются. Группа существует. Пользователь в группе.

А доступ к приложению всё равно не работает.

Почему? Потому что сломался не отдельный объект, а связь между объектами.

Именно здесь обычная логика «объект изменился → нашли резервную копию → восстановили объект» перестаёт быть достаточной.

В многодоменной среде важно уметь восстановить не только объект, но и связность: группы, доверительные отношения между доменами, DNS SRV-записи, Kerberos-зависимости и порядок применения политик.

Что стоит проверить заранее

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

• Карта доверительных отношений – какие домены доверяют друг другу, в каком направлении работает доверие и что произойдёт, если одно звено станет недоступным.

• Контур восстановления – какие домены можно восстанавливать отдельно, а какие требуют жёсткой последовательности: например, сначала восстановить домен A, проверить состояние доверия к B и только потом тестировать доступ.

• DNS и Kerberos – понимаем ли мы, как после восстановления домены находят друг друга? Не разъедутся ли ключи на сервисах и контроллерах, если восстановление идёт из старого снепшота? При откате может измениться KVNO в SPN-записях, и Kerberos-аутентификация для ресурсов сломается, хотя формально всё «зелёное».

• Сквозной тест доступа – проверяем не только доступность серверов, а весь путь: пользователь из одного домена должен получить доступ к ресурсу в другом.

Главный вывод

Многодоменная архитектура – это не просто «удобно разделили контуры». Это более сложная эксплуатационная модель.

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

Иначе гибкость на этапе проектирования превращается в непрозрачность при первой серьёзной аварии.

Коллеги, тестируете восстановление всей цепочки доступа или только каждый домен по отдельности?

#Linux #Инфраструктура #Backup

Подборка вебинаров на июнь 

В июне вас ждут еще три онлайн-встречи с экспертами Cloud.ru — о Spark, облачных расходах и Redis. Регистрируйтесь заранее, чтобы ничего не пропустить.

🎥Spark Connect для ИТ-команд: упрощаем разработку и работу с данными

Покажем, как сделать использование Apache Spark удобным для всей команды с помощью Spark Connect и Evolution Managed Spark. Затронем вопросы разработки в IDE, анализа данных в Jupyter и построения ETL на чистом SQL в dbt. Не бойтесь споткнуться о порог входа — здесь он минимальный. 

🧑‍💻 Для кого: дата-инженеры, аналитики, руководители дата-отделов.

📅 Когда? 23 июня 11:00 мск.

📍 Где? Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

🎥Как управлять расходами в облаке и не удивляться счетам

Разберем, как сделать облачные расходы прозрачными с помощью FinOps-инструментов. Вы узнаете, почему важно назначать владельцев ресурсов, как правильно выбирать тариф, выставлять автоматические квоты и настраивать алерты, чтобы сократить затраты на 20–30%. Всё — с живым демо в личном кабинете.

🧑‍💻 Для кого: ИТ-менеджеры, DevOps, финансовые директора.

📅 Когда? 25 июня 11:00 мск.

📍 Где?  Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

🎥Эволюция приложения в облаке: как настроить кеш с Redis и ничего не сломать

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

🧑‍💻 Для кого: бэкенд-разработчики, DevOps-инженеры, архитекторы.

📅 Когда? 30 июня 11:00 мск.

📍 Где?  Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

Настроить мониторинг за 60 секунд: вебинар про Deckhouse Observability на практике

Метрики, лейблы, Prometheus, PromQL, Grafana, дашборды, алерты, каналы уведомлений. Тема мониторинга большая и сложная, но базовый пайплайн от сбора метрик до визуализации данных и настройки алертов можно разобрать за 60 минут. Этим и займёмся на вебинаре Deckhouse Академии на примере живого сценария.

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

• Рассмотрим, как Prometheus собирает данные и как начать собирать их со своего приложения, добавив три строчки в Deployment.

• Визуализируем метрику и покажем пример агрегации сырых данных с помощью PromQL.

• Создадим правило для алерта, настроим свой канал уведомлений и получим уведомление по агрегированной метрике.

Регистрируйтесь и подключайтесь 23 июня в 12:00 (МСК). После вебинара вы поймёте, как работает цепочка App → Metric → Prometheus → PromQL → Grafana → Alert, сможете подключить своё приложение к Prometheus без правки scrape_config, написать простой запрос на PromQL и настроить оповещения с защитой от шума.

Установка и использование Nexus Repository для хранения артефактов

Nexus закрывает типовую DevOps-задачу: единое хранилище для Maven, npm, Docker, NuGet, PyPI и собственных бинарей, кэш внешних зависимостей и предсказуемый источник артефактов в CI/CD. Версии — Community Edition, Pro и связка с Repository Firewall для отсечения небезопасных компонентов на входе.

В статье разобрали установку Nexus Repository 3.91.1 тремя способами, а также показали первичную настройку, загрузку артефактов и политики очистки. И не забыли про разграничение прав через Privileges, Roles и Users, отключение анонимного доступа и вывод Nexus наружу по HTTPS через Nginx с Certbot.

Все детали — в статье Рег.облака.

Ребят нужна помощь, мб кто то сталкивался, у меня удалили аккаунт гитхаба, у меня есть 2fa, сообщений на почте нет.

Что посмотреть на неделе: брокеры сообщений, Kubernetes и ИИ‑агенты

Привет, Хабр. На этой неделе в OTUS пройдет серия бесплатных уроков для тех, кто работает с архитектурой, инфраструктурой, разработкой, аналитикой и ИИ‑инструментами.

Будет много практики: выбор брокера сообщений, деплой Java‑приложения в Kubernetes, мониторинг распределённых систем, создание AI‑ассистентов и интеграция ИИ‑агентов в рабочую разработку.

Все уроки бесплатно проводят преподаватели в рамках курсов. Можно прийти на один вебинар по своей задаче или собрать мини‑маршрут на неделю.

Архитектура и backend

• 8 июня, 19:00. «RabbitMQ vs Kafka. Как выбрать подходящий брокер сообщений?». Записаться
  _{разберём, чем отличаются RabbitMQ и Kafka, в каких задачах они работают лучше и как выбрать брокер под архитектуру проекта.}

• 15 июня, 20:00. «Системы обмена сообщениями: RabbitMQ и Kafka». Записаться
  _{поговорим об устройстве систем обмена сообщениями и сценариях, где брокеры помогают строить устойчивые распределённые решения.}

Инфраструктура и эксплуатация

• 8 июня, 20:00. «Java в Kubernetes за 40 минут: как задеплоить приложение в Minikube». Записаться
  _{покажем, как подготовить Java‑приложение к запуску в Kubernetes и развернуть его локально через Minikube.}

• 10 июня, 20:00. «Мониторинг распределённых систем». Записаться
  _{разберём, как отслеживать состояние сложных систем, быстрее находить проблемы и не теряться в метриках, логах и алертах.}

ИИ в рабочих процессах

• 11 июня, 20:00. «Создаём ИИ‑ассистента для системного аналитика за 1 час». Записаться
  _{покажем, как ИИ может помогать аналитику в рабочих задачах: от обработки требований до подготовки артефактов.}

• 15 июня, 20:00. «Интеграция ИИ‑агентов в рабочую разработку: обвязка агента навыками и MCP». Записаться
  _{разберём, как расширять возможности ИИ‑агента с помощью навыков и MCP, чтобы он был полезен в реальном рабочем процессе.}

• 15 июня, 20:00. «Создаём AI‑ассистента и интегрируем его в Telegram». Записаться
  _{покажем, как собрать AI‑ассистента и подключить его к Telegram для пользовательских сценариев.}

Команды и процессы

• 11 июня, 20:00. «Внутри Scrum: как работают мастер, владелец и команда». Записаться
  _{разберём, как на практике распределяются роли в Scrum и почему процесс часто ломается не из‑за фреймворка, а из‑за его применения.}

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

Сервер работает. Инфраструктура — нет: открытые уроки для сисадминов

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

Собрали открытые уроки, которые будут полезны системным администраторам, DevOps‑инженерам, SRE и тем, кто хочет увереннее работать с production‑инфраструктурой.

Linux и автоматизация: меньше ручной рутины

• 4 июня, 20:00 — «Продвинутый Bash»
  _{Для тех, кто уже пишет shell‑скрипты и хочет использовать Bash увереннее.}

• 18 июня, 20:00 — «Основы Bash: пишем простые скрипты для автоматизации в Linux».
  _{Подойдёт тем, кто хочет системно подойти к автоматизации повседневных задач в Linux.}

• 22 июня, 20:00 — «Память в Linux. Cache, swap, dirty pages»
  _{Практичный урок о том, как Linux работает с памятью, почему «свободная память» не всегда означает то, что кажется, и как читать поведение системы до того, как всё закончится OOM.}

• 25 июня, 19:00 — День открытых дверей курса «Администратор Linux. Продвинутый уровень»
  _{Формат для тех, кто хочет понять, какие навыки нужны администратору Linux на продвинутом уровне.}

Что почитать перед уроками:

Мастерство поиска в Linux: Grep и регулярные выражения
_{Полезная база для тех, кто регулярно работает с логами, конфигами и текстовым выводом в консоли.}

Docker и контейнеризация: когда «работает локально» уже недостаточно

• 22 июня, 20:00 — «Контейнеризация Java‑приложений с Docker»
  _{Разберем, как упаковывать приложения в контейнеры и что учитывать при работе с Docker в инженерной среде.}

• 8 июня, 20:00 — «Java в Kubernetes за 40 минут: как задеплоить приложение в Minikube»
  _{Прикладной урок для тех, кто хочет посмотреть на деплой приложения в Kubernetes без длинной теории.}

Что почитать перед уроками:

Ваш docker‑compose.yml сломается: 5 настроек, которые все забывают
_{Разбор типовых ошибок в Docker Compose: лимиты ресурсов, restart policy, ротация логов, healthcheck и бэкапы volumes.}

Kubernetes, DevOps и self‑service‑инфраструктура

• 18 июня, 20:00 — «Kubernetes под прицелом: почему ваш кластер может взломать даже стажер и как этого избежать»
  _{Один из самых важных уроков для инфраструктурной аудитории: типовые ошибки в Kubernetes, слабые места кластеров и практики защиты.}

• 22 июня, 20:00 — «Роль и задачи DevOps в современном IT»
  _{Для тех, кто хочет разобраться, где заканчивается классическое администрирование и начинается DevOps‑подход.}

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

• 16 июня, 20:00 — «IDS/IPS как часть эшелонированной защиты инфраструктуры»
  _{Продолжение темы: как системы обнаружения и предотвращения атак встраиваются в многоуровневую защиту.}

• 22 июня, 20:00 — «OAuth 2.0, JWT и коварные куки: Проектируем безопасную аутентификацию»
  _{Полезно тем, кто работает с веб‑инфраструктурой, внутренними сервисами, прокси, доступами и безопасностью приложений.}

Что почитать перед уроками:

Разбираемся с форвардингом IP‑пакетов в сетевых уровнях L2 и L3 
Материал для тех, кто хочет лучше понимать, как пакеты проходят через сеть и где могут возникать проблемы при настройке инфраструктуры.

Мониторинг, SRE и инциденты

• 10 июня, 20:00 — «Мониторинг распределенных систем»
  _{Про наблюдаемость сложных систем, где проблема может быть не на одном сервере, а между сервисами, очередями, базами и сетью.}

• 16 июня, 20:00 — «Инцидент‑менеджмент в SRE. Как быстро находить, устранять и предотвращать сбои в системе»
  _{Практичный урок о том, как быстрее локализовать сбой, не тушить пожары вслепую и снижать вероятность повторения инцидентов.}

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

Если интересны не только инфраструктурные темы, в полном июньском дайджесте собраны ещё 62 бесплатных урока по разработке, данным, архитектуре, ИБ и AI.

Почему тесты проходят, но система всё равно сломана

Классы скрытых ошибок в QA automation, которые не приводят к падению CI

Пайплайн прошёл. Логи без ошибок. Значит всё работает.

Но в реальных QA automation системах это предположение часто не выдерживает проверки.

Тесты могут проходить, даже если система сломана.

И это не редкий edge case. Есть несколько типов проблем, которые не приводят к падению CI:

• False positives — тест подтверждает поведение, которое уже не соответствует бизнес‑логике. Проверка формально зелёная, смысл потерян.

• Missing assertions — тест проходит, потому что не проверяет ничего критичного.

• Flaky suppression — флаки ретраят или игнорируют. Шум скрывает реальные проблемы, CI выглядит стабильным.

• Duplicated execution — один и тот же набор тестов запускается несколько раз из‑за конфигурации runner'а.

• Contract drift — API или поведение системы меняется, но тесты продолжают проверять старые ожидания. Пока не появится явный конфликт — всё зелёное.

В проекте была добавлена пагинация к одному из API эндпоинтов. До изменения ответ выглядел так:

json [{ "id": 1 }, { "id": 2 }]

После — так:

{ "data": [...], "total": 10, "page": 1, "limit": 20 }

API тесты не упали: они проверяли статус и структуру нового формата — всё корректно.

Я была уверена что если API возвращает 200 и схема верна — клиент получает данные.

Но в клиентском коде была строка:

cachedRows = Array.isArray(rows) ? rows : []

Для объекта Array.isArray возвращает false. Список записей стал пустым.

Формально всё работало корректно. Просто данных больше не было.Никаких ошибок в консоли. Никакого 500. Просто пустая страница.

CI остался зелёным — потому что API тесты проверяли API, а не то, как клиент использует ответ.

Дальше сработал каскад: fixture teardown тоже вызывал этот эндпоинт, получал объект вместо массива, не чистил данные — и следующие тесты падали с совершенно другой ошибкой, в совершенно другом файле.

Три теста упали из-за одного изменения shape ответа.

Ни один из них не указал на настоящую причину.

Почему CI это не ловит

CI отвечает на вопрос: «выполнились ли тесты без ошибок?»

Но не отвечает на: «имеют ли тесты смысл относительно текущей системы?»

CI реагирует только на падения. Он не знает про бизнес-инварианты, не отслеживает правильность выполнения и не видит contract drift.

Что с этим делают в зрелых системах

Начинают появляться дополнительные слои:

• контрактные тесты (contract testing) — фиксируют ожидания потребителя API

• явно наблюдаемость тестов — метрики не как %, а как сигналы поведения

• контроль изменений API через diff-инструменты

Ни один из них не заменяет хорошие тесты. Но каждый закрывает слепое пятно, которое тесты не видят.

Финальный вывод

Тесты не доказывают, что система работает.

Они только доказывают, что система не сломалась определённым способом.

Признаки сбоя

• CI зелёный

• UI показывает пустой список

• API возвращает 200

• fixture teardown не чистил данные, занимал слот

Скрытое предположение

«Я решила что статус 200 означает, что потребитель по‑прежнему правильно читает ответ»

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

Contract drift — один из тех классов ошибок, которые можно воспроизвести намеренно. В проекте есть buggy branch именно с этим кейсом: API возвращает изменённый shape ответа, все API тесты зелёные, но клиентский код получает пустой список — без ошибок, без 500, просто тишина.

Код и структура проекта: GitHub

Из серии «Тихие отказы в тест-автоматизации»

Разборы таких кейсов с кодом — в Telegram-канале Тесты как система

ИИ-агент удаляет прод за 9 секунд: новости автоматизации.

Помните, как нас пугали, что ИИ отберёт работу? Пока что он скорее отбирает базы данных.

Свежий кейс. У американской PocketOS ИИ-агент за девять секунд удалил продакшен-базу вместе с бэкапами — без всякого разрешения. На вопрос «зачем» агент невозмутимо ответил, что чинил «несоответствие учётных данных».

Девять секунд на то что бы снести базу и найти оправдание - отличная работа!

88% компаний, гоняющих ИИ-агентов в работе, за год словили подтверждённый или подозрительный инцидент безопасности — при том что на защиту этих агентов уходит жалкие 6% бюджета. Причём чаще всего агент не ломается, а именно сливает данные: в 61% инцидентов была утечка. Он же не виноват — он просто делал свою работу. Ему забыли сказать, где у этой работы край.

Есть и другие случаи, более курьезные. Диллер Cevrolet, их бот под давлением юзеров согласился продать машину за $1 и заявил, что сделка «юридически обязывающая» — no take-backsies.

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

Источники: PocketOS, кейс с удалением базы — Information Age (ACS): https://ia.acs.org.au/article/2026/gone-in-9-seconds--ai-agent-deletes-company-database.html

Тот же кейс глазами ServiceNow — Fortune: https://fortune.com/2026/05/06/servicenow-kill-switch-ai-agents-bill-mcdermott/

Статистика по инцидентам с ИИ-агентами — beam.ai: https://beam.ai/agentic-insights/ai-agent-security-breaches-2026-lessons

В self-hosted Git-сервисе Gogs обнаружили непропатченную уязвимость нулевого дня. Суть в argument injection: если включена опция Rebase before merging, атакующий может внедрить флаг --exec в команду git rebase через вредоносное имя ветки в пулл-реквесте.

Это даёт полный RCE. Злоумышленник получает доступ ко всем репозиториям, хешам паролей, API-токенам и SSH-ключам. Ситуация осложняется тем, что в Gogs по умолчанию открыта регистрация.

Под ударом версии 0.14.2 и 0.15.0+dev. Мейнтейнеры подтвердили баг ещё в марте, но патча до сих пор нет. Временные меры: закрыть публичную регистрацию, отключить rebase-merging или закрыть доступ к серверу "Из внешней сети".

The.Hosting — всё.

Сегодня The.Hosting разослал юзерам такое сообщение:

IMPORTANT: Notice of Service Discontinuation and Account Closure

Dear Customer,

We are writing to inform you that due to unforeseen and unavoidable force majeure circumstances, THE.Hosting is forced to permanently discontinue all its operational services and wind down its activities.

As a result, our platform, support channels, and all associated services will be closed in the coming days.

What this means for you:

➖ New Orders & Renewals: All active forms of registration, ordering, and renewals have been disabled. No new services can be purchased.

➖ Data & Accounts: If you have any active data, configurations, or account details stored within our systems, we urgently advise you to retrieve and back up your information immediately.

➖ Final Termination: Once the wind-down process is completed, all accounts and data will be permanently deleted from our systems.

We deeply regret that we are forced to take this step and understand the inconvenience this causes. We want to thank you sincerely for your partnership and trust in THE.Hosting over the past period.

Sincerely,The Management of THE.Hosting

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

Проблемы у The.Hosting начались около двух недель назад, через несколько дней стало известно об изъятии серверов в Нидерландах, теперь история подошла к закономерному финалу.

Привет, коллеги! 👋 Уже в это воскресенье, 31 мая в 10:00, устроим мощный заряд знаний! ⚡️ За 4 часа своими руками поднимем стек мониторинга, настроим дашборды и оповещения! 📊🔔

Для кого это будет полезно:
- разработчики 💻
- аналитики 📈
- системные инженеры 🔧

Все подробности здесь: https://debugskills.ru/articles/labs/prometheus-grafana/

GitHub Actions не маскирует секреты из фоновых процессов

Настраивал CI, в котором токен доступа переполучается в фоне — раз в 30 минут, пока идут тесты. Первый токен замаскирован через ::add-mask::, но что с экранированием новых токенов в логах? Можно ли вызвать ::add-mask:: прямо из фонового процесса?

В документации GitHub я ответа не нашёл. Там есть только общее место: workflow commands вида ::... раннер читает из stdout шага. А вот что происходит со stdout, который остался от фонового процесса после завершения шага, — непонятно.

Решил проверить — сделал тестовую репу. Схема простая: в одном шаге запускаю background-процесс, который через 15 секунд пишет ::add-mask:: — уже во время следующего шага. Потом специально печатаю секрет: сразу, после sleep, в следующем шаге и в отдельном job’е.

Foreground-секрет (маска из основного процесса) — замаскирован во всех шагах той же job’ы ✅ Background-секрет (маска из фонового процесса) — открыт везде, и до, и после срабатывания ::add-mask:: ❌

Бонус: маски вообще не живут между job’ами — даже foreground-маска в зависимом job’е уже не действует ❌

У нас это, к счастью, не стреляет: переполучение токена уходит в /dev/null, тесты ходят через API, секрет в stdout не попадает. А вот если какой-нибудь refresh-скрипт всё-таки может напечатать новый секрет в лог — на ::add-mask:: из background-процесса рассчитывать нельзя.

Дисклеймер: и код, и текст этого поста написаны в соавторстве с Claude Code.

llm-nano-vm v0.8.0 — выход в PyPI, валидация вывода и per-step таймауты

В прошлом посте мы описывали концепцию nano-vm — детерминированного ядра исполнения на базе конечных автоматов (FSM) для LLM-воркфлоу, где модель не является оркестратором, а лишь предлагает действия внутри жесткого графа \delta(S, E) \to S'.

За это время проект перерос стадию концепта. Мы опубликовали рантайм на PyPI и выпустили релиз v0.8.0. Ниже — сухой отчет о том, что конкретно было сделано, измененено и протестировано.

Что нового в v0.8.0

1. Выход на PyPI и релиз пакетов

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

pip install llm-nano-vm==0.8.0
pip install llm-nano-vm[litellm]==0.8.0   # поддержка провайдеров через LiteLLM
pip install nano-vm-mcp                    # MCP-шлюз

2. allowed_outputs — LLM enum guard

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

{
    "id": "classify",
    "type": "llm",
    "prompt": "Classify. Reply ONLY with: refund / query / other",
    "allowed_outputs": ["refund", "query", "other"],
    "on_error": "skip",   # → подставит "refund" (первый элемент) на mismatch
}

Реализовано три политики обработки ошибок: fail (trace \to FAILED), skip (подстановка allowed_outputs[0]) и retry (перезапрос модели до max_retries).

3. timeout_seconds + on_timeout — таймауты на уровне шага

Решена проблема «зависания» внешних LLM API. Любой llm-шаг теперь можно ограничить по времени выполнения с политиками fail или fallback (подстановка дефолтного значения без падения автомата).

4. Стабилизация ASTEngine

Мы окончательно избавились от eval() для условий (condition). Написан кастомный песочный интерпретатор JSON AST. Любые системные вызовы и скрытые вызовы методов (вроде .lower()) теперь вызывают ASTEvalError на этапе компиляции графа.

Результаты бенчмарков (v0.8.0 · WSL2 · Python 3.12)

Тесты производительности на синтетическом адаптере (3 провайдера \times 5 сценариев \times 10k итераций) показали 1,096,500 операций и 0 нарушений контракта графа.

СценарийСредний TPSp95Refund pipeline2,200/s123 msDouble-execution guard2,800/s69 msBudget enforcement2,400/s97 msParallel throughput1,000/s196 msGovernanceEnvelope (аудит-лог)2,100/s108 ms

• Crash consistency (BM-INT-07): При crash_rate=100% повторное воспроизведение (replay) пайплайна после симулированного падения рантайма выдает идентичный хэш трейса в 100% случаев.

• Memory leak test (BM-INT-10): Пиковый RSS — 76.5 MB, аллокация — 3.62 MB для программ на 1000 шагов. Утечек памяти нет.

Валидация на реальных платежных API

Концепт успешно проверен на двух интеграционных сценариях (9/9 тестов пройдены):

1. MoMo Payment API v4: 3-way ветвление, HMAC-SHA256 IPN верификация, цикл пуллинга статуса с ретраями.

2. Stripe Payment API v1: Обработка 3DS-флоу (REQUIRES_ACTION), refund-пайплайн и верификация вебхуков.

В процессе интеграции со Stripe пофиксили важный баг: коллизию доменного статуса "PENDING" от API Stripe с внутренним сентинелом рантайма, который триггерил заморозку (SUSPEND) автомата.

Текущий фокус и краткосрочный роадмап

• Phase 0: Разработка ProgramValidator для статического анализа графов до их выполнения (поиск циклов, недостижимых шагов и битых таргетов). Актуально, когда сами программы генерируются «на лету» внешними моделями.

• Phase 1: Консистентность шлюза. Перенос StateContext между вызовами MCP в SQLite WAL (execution_contexts + UPSERT на каждый шаг). Это полностью уберет риск повторного списания (Double-Spend) при перезапуске процесса шлюза.

• Phase 2: Интеграция OpenTelemetry для распределенного трассирования шагов.

Репозитории проекта:

• Core runtime: github.com/Ale007XD/nano_vm

• MCP layer: github.com/Ale007XD/nano-vm-mcp

Linux, Docker, Kubernetes и мониторинг: 10 открытых уроков для системных администраторов

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

В этом посте делимся подборкой бесплатных уроков для тех, кто работает с Linux, инфраструктурой, контейнеризацией, Kubernetes, SRE‑практиками и безопасностью. На них можно познакомиться с преподавателями курсов, протестировать формат обучения и задать вопросы экспертам.

Если хотите закрыть базу по Linux и автоматизации

• 18 июня, 20:00. «Основы Bash: пишем простые скрипты для автоматизации в Linux».
  _{Для тех, кто хочет перестать делать рутинные операции руками и начать автоматизировать админские задачи через простые, понятные Bash‑скрипты.}

• 4 июня, 20:00. «Продвинутый Bash».
  _{Следующий шаг после базовых скриптов: больше контроля, аккуратнее работа с окружением, меньше хрупких одноразовых команд.}

• 22 июня, 20:00. «Память в Linux. Cache, swap, dirty pages».
  _{Практичная тема для тех, кто сталкивался с ситуацией «память вроде есть, но сервер ведёт себя странно».}

Для всех, кто хочет подтянуть основы Linux, рекомендуем подготовительный курс (сейчас всего за символические 10 руб)

Если работаете с контейнерами и Kubernetes

• 2 июня, 20:00. «Введение в Docker: контейнеризация приложений в Linux».
  _{Базовый вход в контейнеризацию: что происходит с приложением внутри контейнера, зачем нужен Docker и как он встраивается в повседневную инфраструктурную практику.}

• 28 мая, 20:00. «Безопасность K8s: основные концепции и частые проблемы».
  _{На уроке разберем базовые концепции безопасности K8s и ошибки, которые регулярно всплывают в реальных кластерах.}

• 18 июня, 20:00. «Kubernetes под прицелом: почему ваш кластер может взломать даже стажер и как этого избежать».
  _{Более прикладной взгляд на безопасность Kubernetes: где кластеры обычно оставляют открытыми, какие настройки создают риск и что стоит проверить в первую очередь.}

Если отвечаете за стабильность систем

• 1 июня, 20:00. «Мониторинг распределенных систем».
  _{На уроке поговорим о подходах к наблюдаемости распределённых систем и о том, как быстрее понимать, где именно началась деградация.}

• 16 июня, 20:00. «Инцидент‑менеджмент в SRE. Как быстро находить, устранять и предотвращать сбои в системе».
  _{Для тех, кто хочет перейти от тушения пожаров к управляемому процессу: как реагировать на инциденты, разбирать причины и снижать вероятность повторения сбоев.}

• 3 июня, 20:00. «Internal Developer Platform: self‑service‑инфраструктура за один вечер».
  _{Как организовать инфраструктуру так, чтобы разработчики могли получать нужные ресурсы быстрее, а инфраструктурная команда не превращалась в ручной сервис‑деск.}

Если зона ответственности включает защиту инфраструктуры

• 16 июня, 20:00. «IDS/IPS как часть эшелонированной защиты инфраструктуры».
  _{На уроке разберем, как такие системы вписываются в инфраструктурную безопасность и где от них действительно есть польза.}

Больше открытых уроков по ИТ-инфраструктуре, разработке и не только смотрите в календаре открытых уроков OTUS.

ИИ не должен управлять исполнением. Заметки о детерминированном FSM-рантайме для агентов

Большинство рантаймов для ИИ-агентов сейчас работают по одному простому паттерну: LLM -> вызов инструмента -> рантайм выполняет сайд-эффект.

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

В процессе подготовки части наших внутренних агентов к деплою, мы пришли к необходимости полностью разделить процессы «рассуждения» (reasoning) и право на исполнение (execution authority).

Мы написали nano-vm — детерминированный FSM-рантайм (конечный автомат), в котором:

• модель лишь предлагает действия;

• рантайм жестко контролирует переходы состояний и сайд-эффекты.

Рантайм принудительно обеспечивает:

• конечные графы исполнения;

• строгий порядок шагов, зафиксированный при компиляции (compile-time ordering);

• capability-gating для инструментов (жестко изолированные доступы);

• границы идемпотентности и защиту от replay-атак;

• append-only историю аудита.

Одно из архитектурных решений, которое оказалось критически важным: слой политик намеренно сделан менее выразительным, чем Python.

Мы полностью отказались от eval-подобного исполнения и ограничили политики небольшим детерминированным подмножеством AST:

• только простые операторы;

• никаких циклов;

• никаких системных вызовов.

Это ограничение радикально упростило аудит и исключило целые классы рантайм-поведения, которые мы не хотели видеть в финансовых воркфлоу.

Sabotage Mode и семантика отказов

Чтобы протестировать семантику отказов, мы добавили в демо-стенд «Sabotage Mode» с несколькими векторами атак:

• неавторизованная инъекция инструментов (tool injection);

• попытки повторного выполнения (replay-атаки);

• подделка хешей (hash corruption);

• пропуск шагов пайплайна (skipped transitions).

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

Нам также пришлось решать крайне неудобную compliance-проблему: как сохранить неизменяемые цепочки аудита (immutable audit chains) и при этом выполнить требования 152-ФЗ / GDPR об уничтожении данных. Наш текущий подход заменяет ссылки в хранилище на маркеры-надгробия (tombstones), полностью сохраняя криптографическую непрерывность хешей и ссылочную целостность графа.

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

• Core runtime: github.com/Ale007XD/nano_vm

• MCP layer: github.com/Ale007XD/nano-vm-mcp

• Live Sabotage Demo: demo.bannerbot.ru:8843

В субботу 23 мая лабораторная — Docker для системных аналитиков! 🐳📊

Присоединиться и получить виртуальную машину со всеми настройками можно через Boosty! 🚀 Скидка для тех, кто хочет попробовать! 💸

Boosty - https://boosty.to/polnyistek

Подробнее - https://debugskills.ru/articles/labs/docker-basics/ 📖✨

GitOps без романтики: эксплуатация, советы, решения

Есть подходы, которые в докладах на конференциях звучат как откровение. Git — единственный источник правды, всё декларативно, прод руками не трогаем, система сама себя лечит. А потом наступает понедельник, и выясняется, что кто-то всё-таки поправил что-то руками, конфиг задрейфовал, а rollback работает ровно до того момента, пока не нужен по-настоящему.

В новом выпуске «В SREду на кухне» поговорили о GitOps без хайпа — с Михаилом Кожемским, Lead DevOps в Банк 131, и Павлом Селивановым, руководителем продуктового направления DevTools в Яндекс Клауд.

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

Разбираем, чем push-модель отличается от pull и почему выбор между ними — это не вкусовщина, как Argo CD и Flux ведут себя в реальной жизни, а не в туториалах, и почему иллюзия «Git = реальность» — одна из самых дорогостоящих в инфраструктуре. Отдельно — про конфигурационный drift, Terraform и Crossplane, и что GitOps до сих пор так и не научился решать.

Если вы уже внедрили GitOps и думаете «что-то пошло не так» — или только собираетесь и хотите знать, что именно пойдёт не так — этот выпуск для вас.

Смотрите видео на площадках:

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

Puppet 8 for DevOps Engineers — книга, после которой лучше понимаешь инструмент

Puppet - мой основной рабочий инструмент. Сейчас он обслуживает нашу офисную и торговую сеть, а это более 9000 хостов на Linux под самые разные нужды. На русском языке актуальных материалов по нему практически нет, поэтому я взялся за англоязычную «Puppet 8 for DevOps Engineers». Читалось не быстро, но, как говорится, дорогу осилит идущий.

И книга оказалась просто 10 из 10.

Больше всего понравилось, что это не просто сборник синтаксиса и примеров, а разбор Puppet как полноценного инженерного инструмента.

Что внутри:

Сначала автор рассказывает историю создания Puppet и задачи, ради которых он создавался. Потом переходит к философии: почему он устроен именно так, как работает декларативный подход, зачем нужна идемпотентность и почему это важно для управления инфраструктурой.

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

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

Последняя небольшая часть посвящена сравнению с платной версией. Автор честно говорит, что многие возможности можно собрать и в бесплатной версии, если готовы вложить время и поддерживать всё самостоятельно.

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

По итогу:

Книга оказалась полезной со всех сторон: и для написания нормального Puppet-кода, и для понимания архитектуры, и для эксплуатации серверов Puppet в реальной инфраструктуре.

Хочется, чтобы по другим DevOps-инструментам чаще попадались книги такого уровня.

Есть, правда, грустный контекст: Puppet 8 стал последней open source-веткой. После изменений со стороны Perforce новые пакеты и бинарные сборки Puppet начали уходить в закрытую модель распространения. Сообщество в ответ развивает форк OpenVox. По командам, структуре и общей логике он во многом продолжает привычный Puppet-подход, так что история инструмента, похоже, не закончилась.

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

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

Егор, аналитик в Naumen Contact Center, рассказал, как внутри продукта устроено нагрузочное тестирование и почему «запустить тест» — самая простая часть.

• количество одновременно работающих операторов

• нагрузка на входящие и исходящие вызовы

2️⃣ Почему аналитик вообще занимается нагрузочным тестированием?

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

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

3️⃣ Когда нужно проводить нагрузочное тестирование?

Есть несколько типичных ситуаций, когда без него не обойтись:

• Регулярные проверки перед релизом или после обновления серверов.

• Тестирование новых фич — если изменения потенциально могут повлиять на производительность.

• Запросы от клиентов или команды внедрения — когда нужно проверить нагрузку или конфигурацию.

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

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

4️⃣ Как принимается решение о проведении тестирования?

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

5️⃣ Как устроен процесс нагрузочного тестирования?

Процесс можно разделить на три этапа:

1. Первичная аналитика — собираем требования и определяем цель.

2. Детальная аналитика — описываем сценарии, метрики, инфраструктуру.

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

6️⃣ Почему нагрузочное тестирование требует отдельной инфраструктуры?

Для более-менее реалистичного тестирования недостаточно одного сервера. В нашем случае используются несколько гипервизоров, десятки виртуальных машин, серверы генерации и приема нагрузки, а также инструменты вроде Gatling, JMeter, Grafana и Ansible.

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

7️⃣ Почему даже короткий тест может занимать полтора часа?

Потому что сам прогон — только часть процесса. До запуска нужно подготовить окружение, очистить старые данные, проверить сервисы, настроить мониторинг и применить параметры. После — собрать артефакты, метрики и результаты. Поэтому тест на 20 минут превращается в полтора часа работы.

8️⃣ Что происходит после тестирования?

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

Если эти показатели проседают, тест нельзя считать успешно пройденным, даже если сама фича формально работает.

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

🔥 МастерАп 262: AI-оркестрация, фронтенд, бекенд и системная разработка

Второй МастерАп в серии — живая встреча, рестобар, три доклада от практикующих экспертов.

В этот раз говорим про AI в разработке: вербализация как инженерный навык, оркестрация AI-систем и как AI меняет системную разработку Linux.

---

📅 12 мая, 19:00–22:00
📍 Рестобар Точка, 5 минут от м. Пионерская → Яндекс Карты

👉 РЕГИСТРАЦИЯ

🎟 Вход свободный — просто возьмите что-нибудь в баре

---

⚡️ Программа:

🚀 Андрей Ерёменок — «Вербализация как инженерный навык: от кода к тексту, от текста к дизайну»
CTO, сооснователь, AI-консультант с 20-летним опытом. Ведущий канала «Пикник Айтишника».

🐳 Андрей Чуян — «Оркестрация AI систем в разработке контента и решений»
FullStack-разработчик, автор канала «IT-волна» (ITChuyana). Основатель сообщества ПолныйСтек. Эксперт по автоматизации и AI.

🐧 Алексей Сапрунов — «AI в системной разработке Linux»
Системный разработчик Linux. Эксперт по AI в системной разработке, автоматизации и низкоуровневому программированию.

---

👥 Для кого:
Разработчики всех направлений, тимлиды, CTO, DevOps — и все, кто хочет живого общения про AI без воды

---

✅ Что будет:
— Три доклада от практиков
— Вопросы и дискуссия вживую
— Нетворкинг в неформальной обстановке

Опубликовали программу infra.conf'26 — большой конференции про инфраструктуру и высоконагруженные сервисы

Команда Yandex Infrastructure открыла полную программу infra.conf 2026, которая состоится 4 июня в Москве и онлайн. Фокус конференции этого года — построение и особенности эксплуатации инфраструктуры в эпоху ML. 

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

Среди докладов от инженеров и разработчиков Яндекса, Сбера, X5 Tech, Wildberries & Russ и других компаний нас ждут темы: 

• «Как появилась Алиса AI: путь одной LLM» (Аркадий Альшан, Яндекс) 

• «ML‑платформы для больших компаний» (Антон Алексеев, AvitoTech) 

• «Как мы построили два больших GPU‑кластера на Kubernetes» (Иван Юмашев, Ozon) 

• «Два подхода к надёжности распределённых систем» (Евгений Дюков, Yandex Cloud) 

• «ИИ‑агенты для MLOps‑инфраструктуры» (Марк Кузнецов, Альфа‑банк) 

• «Особенности observability LLM‑приложений и агентов» (Даниэль Халиулин, Yandex Infrastructure)

Также участникам будут доступны мастер‑классы и выставочная зона инженерных команд.

Infra.conf'26 пройдёт 4 июня в Москве в пространстве TAU. Для участия нужно зарегистрироваться и дождаться приглашения. Также посмотреть доклады в прямом эфире можно будет на сайте конференции.

Сбалансированные Claude Code Safety Hooks с минимум false positive благодаря AST-парсингу Bash

Наконец-то сделал хуки моей мечты - достаточно безопасные и практически без false-positive. Хуки вымученные, эволюционировали на граблях можно сказать.

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

Соответственно, когда хуков нет совсем или их мало, безопасность хромает - агент может уронить базу, сделать rm rf и тд, а если хуков слишком много , то... вы привыкаете клацать Enter на Allow, уже даже не читая о чем вообще сыр-бор. Поэтому, нужен тонкий баланс и хуками важно закрывать только действительно деструктивные, необратимые или критические действия.

Ну, и сразу второй нюанс - для блоков я предпочитаю использовать ask хуки вместо блокирующих, т. к. агенты нынче слишком умные и получив блокирующий хук, наверняка найдет способ обойти ограничение (особенно если прилетел какой-нибудь prompt-injection), тк хуки обычно весьма примитивны.

Короче-говоря, с учетом всех этих нюансов я написал свои opiniated-хуки, которые сам использую, они максимально сбалансированны по allow/ask с практически нулевым false positive - благодаря парсингу AST, а не regex'ам, которые обычно в хуках. Частично в основе лежит claude-code-safety-net весьма сильно переработанный и дополненный.

Внутри:
1. rm — rm/unlink/shred вне cwd, по /etc, $HOME; через sudo, xargs, find -delete, pipe-to-shell.
2. infra — kubectl, docker, terraform, helm, gcp.
3. db — DROP/TRUNCATE/DELETE через psql/mysql; redis-cli FLUSHALL/SHUTDOWN, supabase.
4. paas — Railway, Fly, Heroku, Vercel, Netlify с destructive-глаголами (PocketOS-класс).
5. git — reset --hard, clean -fd, checkout . / restore ., branch -D, stash drop/clear, push -f, push --delete.

Ссылка на репо: https://github.com/CodeAlive-AI/ai-driven-development/tree/main/hooks/balanced-safety-hooks

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

Кстати, для простого и корректного управления своими хуками у меня есть отдельный скилл hooks-management, который теперь поддерживает Claude Code, Codex и OpenCode.

Если вам нравится такой контент, то не премините заглянуть в мой Telegram канал, в котором я регулярно делюсь всякими полезностями про AI-Driven Development: https://t.me/+A-CrVovS0lczMDVi

20 открытых вебинаров OTUS: архитектура, DevOps, ML, аналитика, Go, безопасность и управление

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

В программе — метрики технического директора, управление ресурсами, BPMN, Kafka Streams, ClickHouse, Deep Learning в проде, Nginx/Angie под нагрузкой, Kubernetes, Go, пентест, ИИ‑агенты и DevSecMLOps.

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

12 мая

• 18:00. «Какие метрики использует технический директор?» — Записаться

• 19:00. «Управление ресурсами в условиях жестокого дефицита» — Записаться

• 20:00. «Кастомизация интерфейса Bitrix24: создание уникальных пользовательских решений» — Записаться

13 мая

• 18:00. «Yahoo Finance и не только — работа с российскими торговыми площадками» — Записаться

• 18:00. «Обзор нотации BPMN 2.0» — Записаться

• 20:00. «ClickHouse для аналитики больших данных: практические кейсы и связь с NoSQL-экосистемой» — Записаться

• 20:00. «Kafka Streams DSL» — Записаться

• 20:00. «Как выкатить в прод Deep Learning модели» — Записаться

14 мая

• 18:00. «Графическое описание бизнес-процессов и требований» — Записаться

• 19:00. «Архитектор как модератор изменений: как проводить архитектурные решения через стейкхолдеров» — Записаться

• 19:00. «Оптимизация Nginx и Angie под высокие нагрузки» — Записаться

• 20:00. «Матрица компетенций для лида поддержки» — Записаться

• 20:00. «Вкатиться в пентест в 2026: кому это реально и как этому учиться на практике» — Записаться

• 20:00. «Взаимодействие с базой данных и миграции на Go» — Записаться

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

18 мая

• 20:00. «Корреляция признаков. PCA» — Записаться

• 20:00. «Деплой на стероидах: ускоряем доставку через Golden Path» — Записаться

• 20:00. «Go внутри: планировщик» — Записаться

• 20:00. «Основы Kubernetes: архитектура и абстракции» — Записаться

• 20:00. «DevSecMLOps: как безопасно внедрять ИИ в процессы разработки и эксплуатации» — Записаться

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

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