Установка и использование 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.
Что посмотреть на неделе: брокеры сообщений, 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 увереннее.
22 июня, 20:00 — «Память в Linux. Cache, swap, dirty pages» Практичный урок о том, как Linux работает с памятью, почему «свободная память» не всегда означает то, что кажется, и как читать поведение системы до того, как всё закончится OOM.
22 июня, 20:00 — «Роль и задачи DevOps в современном IT» Для тех, кто хочет разобраться, где заканчивается классическое администрирование и начинается DevOps‑подход.
10 июня, 20:00 — «Мониторинг распределенных систем» Про наблюдаемость сложных систем, где проблема может быть не на одном сервере, а между сервисами, очередями, базами и сетью.
Все уроки бесплатные. На них можно познакомиться с преподавателями‑практиками, посмотреть на формат обучения и задать свои вопросы.
Если интересны не только инфраструктурные темы, в полном июньском дайджесте собраны ещё 62 бесплатных урока по разработке, данным, архитектуре, ИБ и AI.
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, просто тишина.
ИИ-агент удаляет прод за 9 секунд: новости автоматизации.
Помните, как нас пугали, что ИИ отберёт работу? Пока что он скорее отбирает базы данных.
Свежий кейс. У американской PocketOS ИИ-агент за девять секунд удалил продакшен-базу вместе с бэкапами — без всякого разрешения. На вопрос «зачем» агент невозмутимо ответил, что чинил «несоответствие учётных данных».
Девять секунд на то что бы снести базу и найти оправдание - отличная работа!
88% компаний, гоняющих ИИ-агентов в работе, за год словили подтверждённый или подозрительный инцидент безопасности — при том что на защиту этих агентов уходит жалкие 6% бюджета. Причём чаще всего агент не ломается, а именно сливает данные: в 61% инцидентов была утечка. Он же не виноват — он просто делал свою работу. Ему забыли сказать, где у этой работы край.
Есть и другие случаи, более курьезные. Диллер Cevrolet, их бот под давлением юзеров согласился продать машину за $1 и заявил, что сделка «юридически обязывающая» — no take-backsies.
Разница в том, что раньше у ботов был только язык, а теперь — права доступа. И шутки подорожали на пару порядков. Вывод банальный: ИИ и правда работает. Просто его пускают в прод быстрее, чем успевают огородить забором. Минимальные привилегии, аудит и большая красная кнопка — это теперь не паранойя, а реальность работы с агентами.
В 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 разослал юзерам такое сообщение:
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 часа своими руками поднимем стек мониторинга, настроим дашборды и оповещения! 📊🔔
Для кого это будет полезно: - разработчики 💻 - аналитики 📈 - системные инженеры 🔧
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
Добавлена жесткая валидация сырого вывода модели по белому списку до того, как значение попадет дальше в пайплайн.
Реализовано три политики обработки ошибок: 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 нарушений контракта графа.
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 тестов пройдены):
MoMo Payment API v4: 3-way ветвление, HMAC-SHA256 IPN верификация, цикл пуллинга статуса с ретраями.
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 для распределенного трассирования шагов.
Linux, Docker, Kubernetes и мониторинг: 10 открытых уроков для системных администраторов
Системное администрирование давно не ограничивается «поднять сервер и настроить доступы». Сегодня инфраструктура живёт в контейнерах, кластерах, пайплайнах, распределённых системах и мониторинге, который должен подсказать о проблеме раньше, чем её заметят пользователи.
В этом посте делимся подборкой бесплатных уроков для тех, кто работает с Linux, инфраструктурой, контейнеризацией, Kubernetes, SRE‑практиками и безопасностью. На них можно познакомиться с преподавателями курсов, протестировать формат обучения и задать вопросы экспертам.
4 июня, 20:00. «Продвинутый Bash». Следующий шаг после базовых скриптов: больше контроля, аккуратнее работа с окружением, меньше хрупких одноразовых команд.
Для всех, кто хочет подтянуть основы Linux, рекомендуем подготовительный курс(сейчас всего за символические 10 руб)
Если работаете с контейнерами и Kubernetes
2 июня, 20:00. «Введение в Docker: контейнеризация приложений в Linux». Базовый вход в контейнеризацию: что происходит с приложением внутри контейнера, зачем нужен Docker и как он встраивается в повседневную инфраструктурную практику.
1 июня, 20:00. «Мониторинг распределенных систем». На уроке поговорим о подходах к наблюдаемости распределённых систем и о том, как быстрее понимать, где именно началась деградация.
ИИ не должен управлять исполнением. Заметки о детерминированном 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» с несколькими векторами атак:
С точки зрения эксплуатации самым полезным свойством пока оказались именно детерминированные границы повторного воспроизведения вокруг сайд-эффектов.
Нам также пришлось решать крайне неудобную compliance-проблему: как сохранить неизменяемые цепочки аудита (immutable audit chains) и при этом выполнить требования 152-ФЗ / GDPR об уничтожении данных. Наш текущий подход заменяет ссылки в хранилище на маркеры-надгробия (tombstones), полностью сохраняя криптографическую непрерывность хешей и ссылочную целостность графа.
В основном мне интересно, как другие инженеры решают проблему права на исполнение в stateful-агентах. Вы позволяете модели напрямую управлять сайд-эффектами или встраиваете детерминированный слой контроля между ними?
GitOps без романтики: эксплуатация, советы, решения
Есть подходы, которые в докладах на конференциях звучат как откровение. Git — единственный источник правды, всё декларативно, прод руками не трогаем, система сама себя лечит. А потом наступает понедельник, и выясняется, что кто-то всё-таки поправил что-то руками, конфиг задрейфовал, а rollback работает ровно до того момента, пока не нужен по-настоящему.
В новом выпуске «В SREду на кухне» поговорили о GitOps без хайпа — с Михаилом Кожемским, Lead DevOps в Банк 131, и Павлом Селивановым, руководителем продуктового направления DevTools в Яндекс Клауд.
Что на повестке
Разбираем, чем push-модель отличается от pull и почему выбор между ними — это не вкусовщина, как Argo CD и Flux ведут себя в реальной жизни, а не в туториалах, и почему иллюзия «Git = реальность» — одна из самых дорогостоящих в инфраструктуре. Отдельно — про конфигурационный drift, Terraform и Crossplane, и что GitOps до сих пор так и не научился решать.
Если вы уже внедрили GitOps и думаете «что-то пошло не так» — или только собираетесь и хотите знать, что именно пойдёт не так — этот выпуск для вас.
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, рассказал, как внутри продукта устроено нагрузочное тестирование и почему «запустить тест» — самая простая часть.
1️⃣ Что такое нагрузочное тестирование?
Нагрузочное тестирование показывает, насколько хорошо система справляется с большим количеством пользователей или объемом данных. В случае контакт‑центра это, например:
количество одновременно работающих операторов
нагрузка на входящие и исходящие вызовы
2️⃣ Почему аналитик вообще занимается нагрузочным тестированием?
У каждого аналитика в нашей команде есть свои зоны экспертизы. Я, например, начал погружаться в тему производительности, поэтому нагрузочное тестирование со временем стало частью моей работы.
Моя задача — анализировать требования и описывать, как именно должно проходить нагрузочное тестирование: что проверяем, какие сценарии запускаем и какие параметры считаем важными.
3️⃣ Когда нужно проводить нагрузочное тестирование?
Есть несколько типичных ситуаций, когда без него не обойтись:
Регулярные проверки перед релизом или после обновления серверов.
Тестирование новых фич — если изменения потенциально могут повлиять на производительность.
Запросы от клиентов или команды внедрения — когда нужно проверить нагрузку или конфигурацию.
Внутренние задачи разработки — когда команде нужно проверить свои решения под нагрузкой.
Однако протестировать все невозможно — это требует слишком больших ресурсов. Поэтому мы используем карту нефункциональных требований: проходим по чек-листу и смотрим, могут ли изменения повлиять на производительность системы.
4️⃣ Как принимается решение о проведении тестирования?
Обычно это происходит на встрече по оценке фичи. В обсуждении участвуют тимлиды разработки, архитекторы, тестировщики и другие cпециалисты. Аналитик приносит информацию по изменениям, а дальше команда совместно решает, нужен ли нагрузочный тест.
5️⃣ Как устроен процесс нагрузочного тестирования?
Процесс можно разделить на три этапа:
Первичная аналитика — собираем требования и определяем цель.
Проведение тестов — запускаем тестирование и анализируем результаты.
6️⃣ Почему нагрузочное тестирование требует отдельной инфраструктуры?
Для более-менее реалистичного тестирования недостаточно одного сервера. В нашем случае используются несколько гипервизоров, десятки виртуальных машин, серверы генерации и приема нагрузки, а также инструменты вроде Gatling, JMeter, Grafana и Ansible.
Отдельные компоненты эмулируют работу операторов и клиентов. Например, для проверки нескольких тысяч операторов фактически собирается отдельный контур.
7️⃣ Почему даже короткий тест может занимать полтора часа?
Потому что сам прогон — только часть процесса. До запуска нужно подготовить окружение, очистить старые данные, проверить сервисы, настроить мониторинг и применить параметры. После — собрать артефакты, метрики и результаты. Поэтому тест на 20 минут превращается в полтора часа работы.
8️⃣ Что происходит после тестирования?
После прогона команда анализирует логи, метрики, бизнес-отчеты и дашборды в Grafana. Есть основные метрики, которые проверяются постоянно. Для контакт-центра это, например, скорость установления соединения, скорость открытия экранных форм, переходов между ними и закрытия экранных форм.
Если эти показатели проседают, тест нельзя считать успешно пройденным, даже если сама фича формально работает.
После анализа команда либо фиксирует результаты, либо заводит задачи на доработку сервисов, окружения или инструментов.
🎟 Вход свободный — просто возьмите что-нибудь в баре
---
⚡️ Программа:
🚀 Андрей Ерёменок — «Вербализация как инженерный навык: от кода к тексту, от текста к дизайну» 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.
Из особенностей - написаны хуки на Go, поэтому выполняются буквально за несколько мс. Ну, и каждый, может поправить их под свои нужды, перекомпилировав бинарник. Еще из интересного - большинство хуков покрыты тестами.
Кстати, для простого и корректного управления своими хуками у меня есть отдельный скилл hooks-management, который теперь поддерживает Claude Code, Codex и OpenCode.
Если вам нравится такой контент, то не премините заглянуть в мой Telegram канал, в котором я регулярно делюсь всякими полезностями про AI-Driven Development: https://t.me/+A-CrVovS0lczMDVi
