DevOps *

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.

Современная инфраструктура уже не является простым списком серверов, бакетов, кластеров и баз данных. Это граф связей: workloads обращаются к сервисам, ingress открывает приложения наружу, IAM-роли дают доступы, часть ресурсов управляется Terraform, а часть существует вне декларированного состояния.

https://medium.com/@antonvkrylov/

cloudmapper сканирует AWS и Kubernetes и превращает эту реальность в локальную, структурированную карту. Инструмент написан как standalone Rust CLI. Он создает локальный infra/bundle: инвентарь, JSONL-файлы ресурсов и связей, графовые артефакты, findings, схемы и SQLite-базу map.db. Эту базу можно смотреть через UI, запрашивать SQL, экспортировать и отдавать агентам как компактный контекст. В AWS-графе ресурсы показываются не плоским списком, а топологией: базы данных, Lambda, сети, security groups и findings связаны между собой.

При выборе узла открывается инспектор с деталями: провайдер, сервис, тип, регион, окружение, владелец приложения, Terraform-статус, ingress-правила, ARN и связанные риски. Для Kubernetes используется та же модель: workloads, сервисы, persistent volumes, config maps, service accounts, runtime-компоненты и ingress-пути становятся связанными фактами.

Это важно, потому что AWS и Kubernetes можно анализировать одним языком ресурсов, отношений и рисков. Отдельные представления помогают отвечать на практические вопросы.

Exposure Atlas группирует риск по приложениям, namespace, окружениям или платформенным областям и показывает концентрацию high-risk ресурсов, публичного ingress и unmanaged/drifted-состояния.

Attack Paths показывает достижимость: от публичных входных точек через порты, security groups и compute-цели к downstream-ресурсам и данным. То есть finding превращается в понятный blast radius.

cloudmapper связывает ресурсы с оценочной месячной стоимостью, сравнивает live-состояние с Terraform и показывает unmanaged assets, drift и потенциальную экономию как конкретные findings с рекомендуемыми действиями.

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: как безопасно внедрять ИИ в процессы разработки и эксплуатации» — Записаться

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

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

SELECTOS OpenFix Day 2.0 стартует через час

В 19:00 (мск) мы начинаем митап для инженеров и системных администраторов. Ждем всех, кто не только разворачивает Linux в продакшене, но и читает исходники, гоняет ядро в дебаггере, отслеживает регрессии и закрывает CVE до того, как они становятся инцидентом. 

Программа митапа

• Итоги программы OpenFix и планы на будущее.

• Пластмассовый мир: что не так с ИИ-хайпом и как с этим жить.

• Как ИИ может помочь в управлении ОС.

• Как я ронял прод: конкурс инженерных факапов.

Подключайтесь

✔️ на YouTube

✔️ в VK

Отменили разработчиков и пришли за DevOps'ами. Инженеры — всё!

Раньше увольняли кодеров, теперь у микрофона сисадмины

Coder - больше не профессия. Не верите? Cursor, Claude Code, OpenCode уже закрывают вакансии middle-разработчиков быстрее, чем HR успевают постить новые. Кто не верил - уже сидит с гитбуком в одной руке и резюме в другой.

Но была одна святая группа. Люди, которые смотрели на эту вакханалию и говорили: "Ну, нас-то ИИ не заменит. Сервера сами себя не настраивают, прод сами себя не поднимает. У кого рука на пульсе - у того работа есть".

Знакомо? Я тоже так думал.

До вчерашнего дня.

Встречайте: ваш новый коллега - ничего

Пять дней назад Alibaba Cloud выкатил v1.1.0 своего open-source проекта HiClaw. Если кратко - это оператор для AI-агентов на Kubernetes. Агентская команда, которая живёт в Matrix-чате. Ты видишь их переписку, @ упоминаешь, даёшь задачи.

И в этой команде появился новый участник.

Hermes Worker.

Не человек. Не "помощник". Полноценный DevOps-инженер с terminal-песочницей, который: - Лезит в кластер - Смотрит логи - Чинит конфиги - Пишет постмортемы

Сам. Без approvals. В YOLO-mode.

Раньше ты говорил: "У меня мониторинг в 3 ночи - поднимаюсь, лезу в прод, чиню, я незаменим, ваша говношаражка без меня умерла бы давно". Теперь мониторинг пошлёт алерт Hermes Worker-у, тот лезет в кластер, смотрит логи, чинит, пишет постмортем и уходит в спящий режим. Ты узнаёшь об инциденте из утреннего дайджеста в Matrix.

"Ну, это просто автоматизация рутинных операций", - скажете вы. Ага. Cursor тоже начинали с автодополнения скобочек.

Что конкретно произошло

HiClaw работает так: есть Controller (на Go), который через CRD управляет Worker/Team/Manager/Human ресурсами. Вся команда сидит в Matrix-чате. Manager декомпозирует задачу, воркеры исполняют. Ты @упоминаешь, корректируешь, аппрувишь стратегию.

В v1.1.0 добавили Hermes Worker Runtime - first-class сорт воркера наравне с Node.js и QwenPaw.

Чем он отличается: - Node.js Worker - болтает и дёргает тулы - QwenPaw (Python) - инструменты и скрипты - Hermes Worker - автономный программирующий оператор. Сам планирует, исполняет, итерирует

То есть если Manager говорит "нужна диагностика пода в namespce prod, причина OOMKill", Hermes Worker сам: заходит в кластер → смотрит grafana → чекает лимиты → пересчитывает requests/limits → перекатывает деплой → пишет что сделал.

В 3 часа ночи. Без тебя.

Это ещё не всё

• Helm Chart с Leader Election, RBAC, PVC - enterprise-ready

• Provider-интерфейсы для storage - MinIO, S3, OSS - не надо переписывать контроллер

• Multi-container architecture - Manager больше не тащит Higress+Tuwunel+MinIO+Element в одном образе на 1.7 GB. Инфраструктура вынесена в Controller.

• Worker lifecycle - сам засыпает при простое, просыпается по запросу

• Авто-миграция - старые конфиги сами переезжают в CRD

Всё это open-source (Apache 2.0). Ставится одной строкой:

curl -sSL https://higress.ai/hiclaw/install.sh

А что с российскими реалиями?

С одной стороны - open-source. Форкнул, поставил через Selectel/k3s, LLM заменил на GigaChat/YandexGPT через Higress Gateway. Данные никуда не уходят.

С другой стороны - вы серьёзно думаете, что ваш enterprise с 15 согласованиями на любой чих готов отдать прод AI-агенту? Даже если он пишет постмортемы?

Хотя... если Manager будет сидеть в Matrix-комнате, где ИБ видит каждый чих - почему нет? Прозрачность операций - единственный аргумент, который может продать эту архитектуру в enterprise.

И чо теперь?

Варианта два.

Первый: сделать вид, что это очередной хайп, который не дойдёт до продакшна. Написать коммент "В наше то время все руками делали, где скрепы? Риск: 4.4k звезд на GitHub, 519 форков, 9 контрибьюторов в релизе, код на Go (не очередной Python-прототип). Не похоже на pet project.

Второй: принять, что DevOps как ниша "я один знаю как чинить этот кластер" - умирает. Hermes Worker не заменит инженера, который придумывает архитектуру. Но он заменит инженера, который в 3 ночи заходит по SSH и чинит конфиг.

Вопрос не в том, заменят ли тебя. Вопрос в том, когда.

От Go-интерфейсов до AI-агентов: 16 открытых уроков для IT-специалистов

На этой неделе — серия бесплатных открытых вебинаров для разработчиков, архитекторов, DevOps‑инженеров, аналитиков и специалистов, которые работают с AI‑инструментами.

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

4️⃣ мая

➡ 20:00. «Интерфейсы в Golang изнутри»
_{Разберём, как устроены интерфейсы в Go, что происходит под капотом и почему понимание внутренней механики помогает писать более предсказуемый код.}

5️⃣ мая

➡ 20:00. «Postgres + JSON: реляционная мощь, документная гибкость»
_{Поговорим о том, как использовать JSON в PostgreSQL, когда это оправдано и как совместить строгую реляционную модель с гибкостью документного подхода.}

➡ 20:00. «Архитектурные решения в backend‑разработке»
_{Обсудим, как принимать архитектурные решения в backend‑проектах, где проходит граница между полезной инженерной дисциплиной и избыточным усложнением.}

➡ 20:00. «Ansible: быстрый старт»
_{Практический вводный вебинар для тех, кто хочет автоматизировать рутинные задачи администрирования и быстрее перейти от ручных действий к воспроизводимой инфраструктуре.}

➡ 20:00. «Как не допустить ошибок при написании пользовательских историй (User Story)?»
_{Разберём типичные ошибки в User Story и посмотрим, как формулировать требования так, чтобы они были понятны команде разработки и полезны для продукта.}

6️⃣ мая

➡18:00. «Методы работы с LLM: промпт‑инжиниринг, LoRA и RAG»
_{Поговорим о практических подходах к работе с большими языковыми моделями: от промптов до дообучения и retrieval‑augmented generation.}

➡ 19:00. «Разработка проекта на Kotlin: коллаборация человека, архитектурных шаблонов и ИИ‑команды»
_{Практический вебинар о том, как совмещать инженерный подход, архитектурные паттерны и AI‑инструменты при разработке Kotlin‑проекта.}

➡ 20:00. «Rust в деле: пишем многопользовательский чат с сервером, клиентом и CLI»
_{На примере чата посмотрим, как Rust применяется в реальной задаче: сервер, клиентская часть, CLI и работа с многопользовательским взаимодействием.}

➡ 20:00. «Ключевые тренды AI Governance в 2026 году»
_{Обсудим управление AI‑системами, риски, регулирование, ответственность и подходы, которые становятся важными для компаний, внедряющих искусственный интеллект.}

➡ 20:00. «LangGraph + MCP в Cursor IDE: создаем автономного агента для глубокого анализа Google Trends»
_{Практический вебинар о создании AI‑агента с использованием LangGraph, MCP и Cursor IDE для анализа данных Google Trends.}

7️⃣ мая

➡ 20:00. «Стоп рутина: как self‑service деплой экономит ресурсы команды»
_{Поговорим о self‑service deployment: как снять часть операционной нагрузки с команды, ускорить поставку изменений и сделать процесс деплоя понятнее.}

➡ 20:00. «Настройка удобного рабочего окружения для Python‑проекта»
_{Разберём, как подготовить рабочее окружение для Python‑разработки, чтобы меньше времени тратить на хаос в зависимостях и больше — на сам код.}

➡ 20:00. «От кода до Kubernetes за полтора часа»
_{Посмотрим путь приложения от локального кода до запуска в Kubernetes и разберём базовые шаги, которые помогают понять production‑подход.}

➡ 20:00. «Тестирование микросервисов на Go: почему ваш сервис ломается под 1000 RPS»
_{Разберём, почему микросервисы могут вести себя нестабильно под нагрузкой, и какие подходы помогают находить проблемы до того, как они попадут в продакшен.}

➡ 20:00. «Как бизнес‑аналитик управляет рисками при разработке IT‑продукта?»
_{Поговорим о роли бизнес‑аналитика в управлении рисками: от требований и коммуникации со стейкхолдерами до влияния на итоговое качество продукта.}

➡ 20:00. «Качество C#‑кода: от модульных тестов к системному подходу»
_{Разберём, почему качество кода не сводится только к unit‑тестам, и как выстраивать более системный подход к поддерживаемости C#‑проектов.}

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

Опубликовали митигацию CVE-2026-31431 для Deckhouse Kubernetes Platform

Уязвимость затрагивает модуль ядра Linux algif_aead (интерфейс AF_ALG). До выхода обновлений ядра в дистрибутивах предлагаем временное решение на уровне платформы.

В репозитории:

• NodeGroupConfiguration, который блокирует загрузку модуля и выгружает его, если он загружен;

• FalcoAuditRules для детекта попыток эксплуатации (доступно в DKP EE и CSE).

Применяется через kubectl apply, подробности и инструкции в README.

Гига-помощник в облаке теперь закрывает DevOps-, SRE- и FinOps-задачи: что нового

Рассказываем про большое обновление ИИ-помощника, встроенного в консоль Cloud.ru. В этом релизе расширили возможности работы с виртуальными машинами и добавили три специализированных сценария.

🖥️Несколько ВМ в разных конфигурациях

Гига-помощник научился создавать сразу несколько виртуальных машин за один запрос и управлять ими по команде: может добавлять и удалять диски, менять конфигурации и выполнять другие повседневные операции. Теперь вы сможете легким движением руки развернуть сразу dev, stage и prod или подготовить все необходимое для нагрузочного тестирования. 

🤖Три новых сценария 

Теперь у вас прямо в консоли есть три «подчиненных», которые проследят за тем, чтобы все шло как надо:

• 🛠 DevOps-агент — разворачивает и обслуживает популярные сервисы по текстовому промпту: PostgreSQL, Kafka, WordPress, GitLab и другие. Не нужно держать в голове порядок шагов или обращаться к документации, достаточно описать задачу.

• 📡 SRE-агент — настраивает мониторинг и алертинг, а также помогает разбирать инциденты. Удобен, когда нужно быстро поднять наблюдаемость для нового сервиса или разобраться в причинах сбоя.

• 💰 FinOps-агент — находит забытые и неиспользуемые ВМ и предлагает их удалить, чтобы исключить лишние расходы. Показывает топ дорогих ресурсов и позволяет сравнивать траты за разные периоды.

Ищите Гига-помощника в правом нижнем углу главной страницы консоли

Когда инфраструктура уже не держится на ручном управлении: DevSecOps, Kubernetes, CI/CD и observability на практике

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

В сегодняшней подборке — бесплатные демо-уроки OTUS по DevSecOps, Ansible, self-service-деплою, Kubernetes, Nginx/Angie, OpenTelemetry, CD через GitLab CI и нагрузочному тестированию. Их проводят преподаватели-практики: можно посмотреть на формат обучения, познакомиться с экспертами, задать вопросы и закрыть отдельные пробелы в рабочих темах.

• 30 апреля, 20:00. Планируем внедрение DevSecOps — что следует учесть?

• 30 апреля, 20:00. Битрикс24 + MAX: разработка чат-ботов и автоматизация коммуникаций

• 5 мая, 20:00. Ansible: быстрый старт

• 7 мая, 20:00. Стоп рутина: как self-service деплой экономит ресурсы команды

• 7 мая, 20:00. От кода до Kubernetes за полтора часа

• 14 мая, 19:00. Оптимизация Nginx и Angie под высокие нагрузки

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

• 18 мая, 20:00. Основы Kubernetes: архитектура и абстракции

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

• 19 мая, 20:00. Навыки нагрузочного тестирования и их роль в развитии инженера

• 19 мая, 20:00. Организуем CD с помощью Ansible и GitLab CI

• 19 мая, 20:00. Введение в OpenTelemetry и основы наблюдаемости

• 21 мая, 20:00. API Gateway и не только: шаги к идеальной архитектуре внешних API

Больше полезных материалов для решения практических инфраструктурных задач — в тематическом дайджесте по Kubernetes, DevSecOps, Ansible, Nginx и смежным темам.

DevSecOps без имитации: что учесть, чтобы безопасность не стала тормозом для разработки

DevSecOps часто начинают с инструментов: добавить сканер в CI/CD, включить проверки зависимостей, собрать отчёты по уязвимостям. Но на практике быстро выясняется, что проблема глубже: непонятно, кто отвечает за найденные риски, какие проверки действительно нужны, как не утопить команду в ложных срабатываниях и где проходит граница ответственности между разработкой, эксплуатацией и ИБ.

30 апреля в 20:00 пройдёт бесплатный демо-урок «Планируем внедрение DevSecOps — что следует учесть?».

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

Записаться на урок можно на странице курса «Внедрение и работа в DevSecOps».

Если хочется шире посмотреть на инфраструктуру, Kubernetes, DevSecOps, observability, Ansible, Nginx и не только — в дайджесте собрали больше бесплатных уроков и гайдов по этим темам.

🌲 Открываем регистрацию на Дебаг Кемп

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

📅 6–7 июня 2026 (выходные) 👥 Всего 25 мест — маленький формат, это принципиально.

Цена растёт по мере приближения к дате. Оплатить можно частями через сплит → регистрация

Если вы 💎 практик сообщества — скидка 15% применяется при регистрации автоматически. Ещё не практик, но думаете? Сейчас самый разумный момент.

👀 Узнать больше · 📝 Регистрация

Вопросы — в чат, мы там живём.

Скрипт отработал без ошибок. Каталог – нет

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

Через час выясняется – у 400 пользователей сломалась связка UPN‑sAMAccountName.

Причина – логическая ошибка в условии.
Тест на 10 объектах её просто не поймал.

Дальше обычно три сценария.

Первый – откат из резервной копии.
Но копию сделали 18 часов назад. За это время уже:

– создали новые аккаунты;
– поменяли пароли;
– выдали права.

Откат чинит одно и ломает другое.

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

Обычно это уже режим «админской археологии».

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

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

Не «когда всё поехало», а до того, как нажали Enter.

Массовое изменение без снимка перед изменением – это не автоматизация.

Это ставка на то, что скрипт идеален.

Обычно – нет.

Две попытки миграции FineBI, поломанная синхронизация кластера и выводы, которые пригодятся и вам

На FineBI 6.0 единственным способом резервирования было копирование папки через rsync. Восстановление медленное, переключение на резервный сервер требовало ручной правки конфигураций. Проще было чинить прод, чем восстанавливаться из бэкапа.

В ОТП Банке решили мигрировать сразу на 7.0: нужен был кластер, нормальное резервирование и новые фичи. Первая попытка выглядела логично, прошла без ошибок, но на выходе получился кластер с поломанной синхронизацией между нодами. Как нашли рабочую схему со второй попытки, почему заменили стандартный балансировщик на корпоративный и какие точки отказа остались, расскажет Евгений Иванов на FineDay Online.

📅 22 апреля | 15:00 МСК | FineDay Online 2026

Бесплатно, онлайн, ~3 часа

→ Регистрация

Иллюзия автоматизации: почему API не гарантирует легкую миграцию

Мы в Хайстекс любим API-интеграции, это стандарт и архитектурная основа нашего продукта. Когда нужно мигрировать сотни машин в зрелые публичные облака, API — оптимальный выбор. Но у любого вендора СРК и миграции есть бэклог с кейсами, где API превращается из помощника в серьезную издержку.

Этот пост — для инженеров и архитекторов, которые занимаются миграциями ВМ и регулярно упираются в стоимость и сроки поддержки API-интеграций под каждую новую целевую площадку.

При переносе виртуальных машин между облаками и частными контурами API-интеграция дает максимум автоматизации «на бумаге». Но как только целевых площадок становится больше одной-двух или в проекте появляется специфическая (иногда собранная «на коленке») платформа, выясняется, что у этой автоматизации высокая цена. Вместо быстрого переезда миграция через API превращается в отдельный проект на недели разработки, тестирования и ожидания поддержки со стороны конкретной платформы.

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

Если API целевой среды — это нестабильная переменная, логично вывести её за скобки. Так появилась архитектура Direct2Target (D2T). Это метод, позволяющий сделать целевую сторону миграции полностью воспроизводимой без зависимости от API конкретного облака. В сценарии D2T целевая ВМ-«болванка» подготавливается заранее — вручную или с помощью ваших привычных скриптов («инфраструктура как код»). Решение не тратит время на попытки договориться с облаком о создании ресурсов, а сразу приступает к главной задаче: доставке данных напрямую в диски подготовленной машины.

D2T — не замена API-подходу, это «план Б». Функция позволяет развернуть машину в условиях архитектурных ограничений целевой площадки, не дожидаясь доработок со стороны провайдера.

О том, как реализовать миграцию «в обход» API, почему это в 5 раз быстрее и как перестать превращать переезд в вечную разработку — поговорим на вебинаре 29 апреля в 11:00 (МСК). Регистрация по ссылке.

В программе:

• Прикладные сценарии: когда D2T эффективнее классической интеграции по времени и ресурсам.

• Технологический стек: как обеспечить воспроизводимость миграции на любых площадках без зависимости от API.

• Live Demo: подготовим таргет-ВМ и запустим миграцию в прямом эфире.

Приносите в комментарии баги облачных API, из-за которых сроки проектов улетали в бесконечность. Обсудим, как D2T мог бы упростить вам жизнь в тех кейсах. 

Инженеры перебрали… Linux- кейсов

23 апреля в 18:00 проводим онлайн-митап про Linux — с живым разбором реальных инцидентов в формате подкаста. 

Какие кейсы разберем:

• SSH сломался после обычной операции с архивом

• Сервер не запускается на нужном порту — без очевидной причины

• После обновления ядра система начинает вести себя странно

• Сеть в ВМ ломается после добавления интерфейса

• Балансировщики с одинаковыми конфигами дают разный результат

Обсуждение почти как на офисной кухне, только с логами и командами. А еще дарим мерч, если отправить свой кейс на разбор.

Подробности и регистрация по ссылке.

Мы начинаем GoCloud 2026 — присоединяйтесь к трансляции онлайн☁️

Прямо сейчас в кинотеатре «КАРО 11 Октябрь» на Новом Арбате в Москве начинается ежегодная конференция про ИИ и облака GoCloud 2026. Нет возможности прийти? Тогда жмите кнопку «Смотреть трансляцию» на сайте и присоединяйтесь к нам удаленно.

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

👉 Присоединиться к трансляции

Узнаете на GoCloud, как построить ИИ-инфраструктуру на физических серверах: от инференса до обучения на уровне суперкомпьютера

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

Спикер: Александр Шакмаев — менеджер продукта, Cloud.ru

Трек: Инфраструктура

📅 Когда: 9 апреля в 14:40–15:20 мск
👉 Зарегистрироваться

А пока ждете выступление, загляните в блог: Тестируем B200: живые бенчмарки с GLM-4.7

Автоматизация облачных сценариев в эпоху искусственного интеллекта — одна из тем доклада на GoCloud 2026 ☁️

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

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

Спикер: Антон Щеколдин — менеджер продукта, Cloud.ru

Трек: Приложения и разработка

📅 Когда: 9 апреля в 12:50–13:30 мск
👉 Зарегистрироваться

А пока ждете выступление, загляните в блог: Практическое применение eBPF: serverless-платформа с поддержкой TCP-приложений

SpaceWeb добавил в частное облако четыре DevOps-инструмента: MinIO, Zulip, n8n и Zabbix

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

• MinIO — S3-совместимое объектное хранилище для бэкапов, логов, артефактов сборки и статики;

• Zulip — командный чат с тематическими ветками для асинхронной работы;

• Zabbix — мониторинг серверов и приложений: CPU, память, диски, базы данных, веб-серверы;

• n8n — конструктор автоматизации без кода: соединяет сервисы, ловит вебхуки, создает тикеты, управляет файлами.

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

Подробности — на сайте SpaceWeb.

Управляемые базы данных и почему это тоже про машинное обучение — расскажем на GoCloud 2026 ☁️

Покажем, почему ML-системы начинаются не с моделей, а с дата-инфраструктуры. Разберем роль PostgreSQL, Kafka, Redis, ClickHouse и OpenSearch в реальных сценариях машинного обучения клиентов. Обсудим, как управляемые дата-сервисы становятся фундаментом ИИ-нагрузок, и какие продуктовые требования меняются — превращая дата-платформу в IaaS-слой для машинного обучения.

Спикер: Сергей Геворкян — менеджер продукта, Cloud.ru

Трек: Данные и аналитика

📅 Когда: 9 апреля в 15:35–16:05 мск
👉 Зарегистрироваться

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

Как делать бизнес-процессы как в n8n — безопасно и масштабируемо? Узнаете на конференции GoCloud 2026 ☁️

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

Спикер: Владислав Янковский — старший Go-разработчик, Cloud.ru

Трек: Прикладной ИИ

📅 Когда: 9 апреля в 16:40–17:00 мск
👉 Зарегистрироваться

А пока ждете выступление, загляните в блог: NoCode инструменты для создания AI-приложений с RAG: быстрый старт

Автоматизируем жизненный цикл баз данных: вебинар про DBaaS в Deckhouse

Database as a Service — подход, в котором базами данных управляют как платформенным сервисом: с автоматизацией и предсказуемым жизненным циклом. Вместо ручного администрирования каждой БД по отдельности — единый процесс от создания и развёртывания до обновлений и оптимизации.

Мы реализовали этот подход в Deckhouse Kubernetes Platform. На вебинаре 3 апреля покажем, как он работает, и расскажем:

• что Cloud Native-подход меняет в управлении сервисами данных;

• как устроен DBaaS в Deckhouse: жизненный цикл БД и платформенные модули;

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

Регистрируйтесь и подключайтесь 3 апреля в 12:00 по Москве, если используете БД или хотите применить DBaaS-подход в своей инфраструктуре.

Я не разработчик, но сделал Telegram-бота для Hysteria 2

Я не программист, языков не знаю, я небольшой руководитель отдела в айти, неплохо знаю серверную архитектуру. Но у меня была простая боль: недавно завел для себя и родни сервер Hysteria 2, до этого было с VLESS на сервере и устал каждый раз руками править YAML, когда нужно:

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

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

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

Почему не SSH?

Да, можно через SSH, nano и systemctl. Но когда делаешь это регулярно — растёт шанс ошибки.

Хотелось проще: открыть Telegram, нажать пару кнопок и выдать доступ без ручного редактирования config.yaml.

Веб-панель тоже рассматривал, но бот оказался быстрее и удобнее “на ходу”.

Что умел MVP

Минимум, который был нужен:

/status — жив ли сервис /users — список пользователей add / delete / enable / disable генерация hy2:// ссылки /logs — последние логи /restart — перезапуск с подтверждением

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

Главная проблема: бот ≠ root

Первая (и плохая) идея — дать боту полный доступ: пусть сам правит YAML, дергает systemctl и читает логи.

Это почти готовый root-доступ извне.

Я сделал иначе:

Бот — это интерфейс, не исполнитель.

Бот хранит данные (SQLite) Все опасные действия делает отдельный helper на сервере Helper: генерирует YAML делает backup валидирует только потом применяет и перезапускает

В sudoers разрешены только конкретные команды helper-а, а не shell.

Безопасность (без этого смысла нет)

Сделал максимально жёстко:

deny by default доступ только по Telegram user ID (не username) админ-команды только в личке в группах — никаких опасных действий delete/apply/restart — через подтверждение audit log: кто, когда и что сделал

Бот должен быть параноидальным, а не “удобным для всех”.

Грабли, на которые я наступил

1. Права на конфиг permission denied на /etc/hysteria/config.yaml — лечится не перезапуском, а нормальными правами.

2. Cert/key Один неправильный путь — сервис не стартует. Плюс легко сломать доступ к privkey.pem.

3. URI и userpass

hy2:// и hysteria2:// формат username:password спецсимволы нужно кодировать

Очень легко получить “почти рабочую” ссылку.

4. Клиенты На iOS импорт URI иногда работает хуже, чем ручной ввод.

5. OpenWrt + sing-box Сначала “не работает”, потом “работает, но не так”, и только после настройки DNS и роутинга — всё нормально.

Что получилось

Сейчас это нормальный админ-пульт:

управляю доступами из Telegram не трогаю YAML руками опасные действия подтверждаются и главное — нет полного root-доступа у бота

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

Про LLM

Да, я использовал нейронку. Но это не “магическая кнопка”.

Без продуманной архитектуры (права, границы, apply, валидация, rollback) получилась бы просто опасная игрушка.

Что бы сделал иначе сразу делал бы helper-архитектуру добавил бы audit log с самого начала разделил бы read и write операции по правам сделал бы preflight-проверки перед apply

Что дальше

Планирую:

улучшить UX, возможно добавить лёгкую веб-панель, оставить Telegram, как быстрый пульт

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

P.S. Это моя первая статья, готов ко всем минусам, хейту и так далее. Единственная цель этого поста - рассказать о боте и дать его в народ

ссылка не репу https://github.com/Ramisya4ka/hysteria-bot-manager (внутри есть очень подробное Readme)

Код, контейнеры и немного ИИ. GoCloud 2026: трек «Приложения и разработка»

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

Вот что разберут в докладах:

• AI Assisted Cloud Workflow: автоматизация облачных сценариев в эпоху ИИ — поделимся инструментом, который убирает ручную склейку сервисов: просто берете готовый шаблон, а ИИ-ассистент помогает собрать все от архитектуры до бизнес-логики. Полезно тем, у кого нет выделенного архитектора на каждый проект.

• Артефакты в масштабе: история роста и эволюции Evolution Artifact Registry — как устроено централизованное хранилище артефактов, как оно дружит с Kubernetes и что анонсируют из новых функций в этом году. Полезно командам, у которых артефакты разбросаны по разным местам.

• Evolution Container Apps: платформа для платформ — как на базе одного сервиса поднять изолированные среды для разработки, тестирования и обучения. Разберут на примерах: от личного ноутбука до учебной платформы в стиле «Школы 21».

• Снижаем рутину в облаке: новые сценарии Гига-помощника — как ИИ-помощник теперь умеет разворачивать сразу несколько продуктов и настраивать мониторинг. Покажут живьем, без слайдов с обещаниями.

• Защита cloud native приложения: от GUI до ИИ — как атакуют контейнеры и где типичные дыры в Kubernetes. На практике покажут, как закрыть угрозы через Evolution Container Security за несколько кликов.

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

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

Регистрируйтесь и до встречи на GoCloud 2026! 

Запустили Yandex Cloud Stackland — инфраструктурную платформу для развёртывания приложений в закрытом контуре

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

Платформу можно развернуть на любых виртуальных, арендованных или собственных серверах, а также интегрировать с уже существующими корпоративными системами. Также она позволяет без дополнительной интеграции внедрять готовые сервисы Yandex Cloud, доступные по модели on‑premises. Сейчас в Stackland доступны инструмент для речевой аналитики Yandex SpeechSense и BI‑система Yandex DataLens, в ближайшее время появится ещё несколько решений, в том числе Yandex AI Studio для разработки ИИ‑приложений и агентов.

Подробнее о разработке опенсорс‑решения для бэкапов CloudNativePG в Stackland и предыстории платформы мы уже рассказывали в отдельной статье.

Для получения доступа к Yandex Cloud Stackland оставьте заявку.

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

Так родился lazy-tmux, написанный на Go. Ключевые фичи:

• Сохраняет текущую сессию, конкретную сессию или все сессии целиком. Снимки сохраняют окна, панели, layout, команды (например, npm, docker-compose, редакторы) и опционально scrollback историю шела.

• Ленивое восстановление: поднимается только выбранная сессия. RAM не расходуется на всё сразу.

• Интерактивный TUI браузер с деревом сессий, окон и панелей, таблицей с активными командами, временем последнего снимка, количеством окон/панелей и статусом сессии. Поддержка fuzzy search для быстрого поиска.

• Навигация и полное управление сессиями и окнами с клавиатуры в TUI браузере сессий.

• Гибкая сортировка сессий и окон через флаги --session-sort и --window-sort

• Можно заменить встроенный TUI на fzf, использую облегчённый бинарник.

• Автосейв через фоновый демон, периодически снимающий все сессии на диск.

• Восстановление при старте tmux для автоматизации workflow.

Проект ещё молодой, но буду рад любой помощи и идеям по улучшению: GitHub issues

За моими новостями можно следить в Telegram-канале

ingress-nginx официально переведён в архив

24 марта 2026 года репозиторий kubernetes/ingress-nginx переведён в архив и стал read-only.

Проект просуществовал более восьми лет, набрал 20 тысяч звёзд на GitHub и стал стандартом для HTTP-маршрутизации в Kubernetes. Теперь поддержка и разработка полностью прекращена: новых релизов, багфиксов и патчей безопасности не будет.

Причина архива: ресурс Ingress изначально был слишком ограничен. Весь расширенный функционал реализовали через vendor-специфичные аннотации, нормального RBAC не было, протоколы: только HTTP/HTTPS. Gateway API решает все эти проблемы на уровне спецификации.

Мейнтейнеры рекомендуют переходить на реализации Gateway API:

"If you are not already using ingress-nginx, you should not be deploying it as it is not being developed. Instead you should identify a Gateway API implementation and use it."

Источник

Актуальные варианты: NGINX Gateway Fabric, Cilium, Envoy Gateway, Istio, Traefik.

Худший бэкап — не тот, что не восстановился. А тот, что положил прод.

Что, если post-script не отработал? Моргнула сеть или случился таймаут. Внешний оркестратор просто пишет в лог failed и снимает задачу. А вот PostgreSQL об этом не знает. База остается в режиме бэкапа и начинает непрерывно копить WAL-файлы, ожидая команды на завершение.

Получается, что инструмент для защиты бизнеса от даунтайма, своими руками этот даунтайм и устроил.

Уметь дернуть pg_backup_start( ) — мало. Если СРК не имеет встроенного watchdog-механизма для сброса зависших сессий, резервное копирование превращается в угрозу доступности. Разделение ответственности — правильный архитектурный подход, но он означает, что защита базы от переполнения диска полностью ложится на ваши плечи.

О зависшем backup mode, разрывах PITR и других неудобных вопросах эксплуатации PostgreSQL совместно с Акурой поговорим в режиме live-демо на вебинаре 26 марта в 11:00 (МСК).

Регистрация по ссылке. Приносите в комментарии свои вопросы.

SIP-exporter: eBPF-мониторинг SIP-трафика для Prometheus

Хочу поделиться своим open-source проектом для мониторинга SIP-трафика — SIP-exporter. Это сервис, который использует eBPF для захвата пакетов прямо в ядре Linux и экспортирует метрики в Prometheus.

SIP-exporter — сервис, который захватывает SIP-пакеты (UDP/5060-5061) через eBPF socket filter, использует ringbuf для zero-copy передачи в userspace, парсит SIP в Go и экспортирует 40+ метрик в Prometheus, включает готовый дашборд для Grafana.

Архитектура: SIP Traffic → NIC → eBPF socket filter → ringbuf → Go poller → SIP parser → Prometheus

SIP-exporter экспортирует: активные SIP сессии (диалоги), SIP запросы по методам: INVITE, BYE, REGISTER, OPTIONS... SIP ответы по кодам: 1xx, 2xx, 4xx, 5xx, 6xx-, сессии.

• GitHub: https://github.com/aibudaevv/sip-exporter

• Docker Hub: https://hub.docker.com/r/frzq/sip-exporter

Покажем Internal Development Platform от Deckhouse на вебинаре 26 марта

Внутренние платформы разработки позволяют командам перейти от разрозненного набора инструментов к сервисному подходу. Разработчики получают self-service доступ ко всему необходимому — от создания окружений до управления quality gates и релизами — и могут работать автономно, не привлекая DevOps-команду.

Мы разработали собственную IDP — Deckhouse Development Platform, которая уже доступна для внедрения. 26 марта покажем её демо и расскажем: 

• что вообще такое IDP и когда она будет полезна; 

• на какие DORA-метрики влияет внутренняя платформа разработки;

• для каких сценариев подойдёт Deckhouse Development Platform.

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