DevOps by REBRAIN

В понедельник первое занятие интенсива «ИИ-агенты для инженеров». Делимся подробностями, что будет на первом эфире. Урок называется «Основы coding-агентов: архитектура, запуск и первый ReAct-цикл». Разберём, чем автономный агент отличается от обычного автодополнения кода вроде Copilot, и почему это не одно и то же. На занятии пройдём: 🟢что такое агент и в чём разница между уровнями автономности 🟢анатомию агента и ReAct-цикл: как он рассуждает (Reason) и действует (Act) 🟢установку и первый запуск opencode на чистой машине 🟢управление контекстным окном: лимиты, счётчики токенов, что делать при деградации контекста После занятия ты будешь понимать архитектурные отличия автономных агентов от систем автодополнения кода, сможешь сам установить и запустить opencode в рабочем окружении и разберёшь логи tool calls в verbose-режиме, чтобы дебажить действия агента. Практика: разворачиваешь виртуальную машину, ставишь opencode, запускаешь агента в verbose-режиме и поручаешь ему написать Python-скрипт с тестами, а потом разбираешь вывод ReAct-цикла: что агент думал и какие инструменты вызывал. 📆 До понедельника остались считаные дни. Если ещё не занял место, самое время присоединиться. ↘️ Узнать подробности и занять место

🔥Разбор задачи по траблшутингу "Nginx Reverse Proxy" Вы её решали — кто-то справился блестяще, кто-то упёрся в стену, а кто-то нашёл неочевидный костыль и задумался: «А правильно ли я сделал?» Сегодня, 17 июля в 19:00 МСК, мы разберем эту задачу вместе с экспертом, который покажет свой путь поиска проблемы: от первых логов до финального решения. 👨‍💻 Наш эксперт — Юрий Береговой Senior-разработчик, совмещающий бэкенд на Java/Spring с профессиональным управлением инфраструктурой (Kubernetes, Terraform, Ansible, Jenkins, AWS/GCP) и обожающий нестандартные задачи, где прокачка идёт через реальный опыт. На вебинаре он: - покажет 🔥свой собственный процесс диагностики🔥 — как он читает логи, проверяет гипотезы и принимает решения; - ответит на ваши вопросы в прямом эфире. 🎁 Бонус для участников траблшутинга Все, кто решал задачу с 9 июня (независимо от результата), получат специальный промокод на скидку. Просто напишите нашему менеджеру — и он отправит вам промокод. Успевайте! 🎲 И конечно, розыгрыш призов среди всех зарегистрировавшихся — участвуйте и забирайте подарки! 🗓 Когда: Сегодня = 17 июля 2026, 19:00 МСК 🔗 Регистрация обязательна Приходите — будет не просто полезно, а по-настоящему хардкорно. Увидимся! 👀

Blue Team vs Red Team. Почему защищаться сложнее, чем атаковать Red Team эффектно закрывает отчёт: нашли SQL-инъекцию, обошли WAF, забрали Domain Admin за два часа. У Blue Team задача менее зрелищная — закрыть 47 критических уязвимостей, 12 из них в проде, и успеть до дедлайна на исправление. Правило здесь неравное. Атакующему достаточно одной дыры, а защите нужно закрыть все. Практикум BlueTeam учит находить слабые места в инфраструктуре раньше атакующих и защищать то, что уже развёрнуто — контейнеры, Kubernetes, веб-приложения, Active Directory. В программе: 🟢Настройка безопасного окружения Docker и runtime-мониторинга в Kubernetes с помощью Falco 🟢Автоматизация процессов Vulnerability Management и сканирования инфраструктуры с Nessus/GreenBone 🟢Анализ исходного кода и контейнеров на наличие уязвимостей в CI/CD конвейере 🟢Выявление и эксплуатация уязвимостей веб-приложений из списка OWASP Top 10 🟢Проведение аудита безопасности Active Directory, выявление векторов атак и повышение привилегий 🟢Защита инфраструктуры Active Directory ↘️ Подробнее о программе Финальный проект Аудит безопасности гибридной инфраструктуры целиком. Нужно просканировать уязвимости веб-приложения, настроить защиту контейнеров в K8s, найти слабые места в Active Directory и собрать отчёт с планом устранения критических угроз. Практикум уровня Middle, 65 уроков, 240 часов практики. Понадобятся базовые навыки администрирования Linux и Windows, понимание TCP/IP, DNS и основ Docker. 🎁 До 19 июля действует скидка 10 000 рублей для новых участников ↘️ Купить практикум со скидкой Если ты сисадмин, DevOps-инженер или начинающий специалист по ИБ и хочешь закрывать дыры быстрее, чем их находят — этот практикум для тебя 🤍

💡Автоматизируем работу с Helm-чартами Вместо ручного изменения Chart.yaml используем GitLab CI для динамического вычисления версии на основе коммита. Вариант 🔤: Если чарт лежит внутри репозитория сервиса Добавляем джобу автоматического обновления версии перед деплоем. Для изменения YAML используем современный синтаксис утилиты yq (v4+). update_chart_version: stage: prepare image: alpine:3.18 variables: GIT_DEPTH: 0 # без этого в клоне не будет тегов для git describe script: - apk add --no-cache yq git - | RAW=$(git describe --tags --always --dirty 2>/dev/null || true) VERSION=${RAW#v} # убираем префикс v: v1.2.3 -> 1.2.3 # если тега SemVer-вида нет (только хэш) — берём базовую версию if ! echo "$VERSION" | grep -Eq '^[0-9]+\.[0-9]+\.[0-9]+'; then VERSION="0.0.0-${CI_COMMIT_SHORT_SHA}" fi echo "Chart version: $VERSION" yq -i ".version = \"${VERSION}\"" chart/Chart.yaml - cat chart/Chart.yaml artifacts: paths: - chart/Chart.yaml Вариант 🔤: Если чарты хранятся в отдельном общем репозитории Настраиваем автоматический пуш обновлений в репозиторий чартов. Вместо устаревшего gitlab-ci-token для авторизации в GitLab безопаснее и актуальнее использовать oauth2. update_helm_repo: stage: deploy image: alpine/git:2.40.1 script: # HELM_CHARTS_TOKEN — Project/Group Access Token репозитория helm-charts # со scope write_repository. Задать в Settings -> CI/CD -> Variables # (Masked + Protected). Имя пользователя для такого токена — oauth2. - git clone https://oauth2:${HELM_CHARTS_TOKEN}@gitlab.com/infrastructure/helm-charts.git - cd helm-charts - mkdir -p $SERVICE_NAME - cp -r ../chart/* ./$SERVICE_NAME/ - git config user.email "ci@example.com" - git config user.name "GitLab CI" - git add . # коммитим только при наличии изменений, чтобы не ломать пайплайн пустым коммитом - git diff-index --quiet HEAD || git commit -m "Update $SERVICE_NAME to $CI_COMMIT_SHORT_SHA" # -o ci.skip, чтобы пуш не запускал бесконечный пайплайн в репозитории чартов - git push -o ci.skip origin HEAD:main rules: - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH 📌Важно: для кросс-репозиторного пуша CI_JOB_TOKEN не подходит — он даёт клонирование и доступ к API, но не право git push в чужой репозиторий (частичная поддержка появилась только в GitLab 19.1 и требует отдельной настройки allowlist на стороне целевого репозитория). Штатное решение — Project Access Token (или Group/Deploy Token) со scope write_repository, созданный в репозитории helm-charts с ролью не ниже Developer. Токен кладётся в CI/CD-переменную HELM_CHARTS_TOKEN (Masked + Protected). Имя пользователя в URL для access-токена — oauth2 (именно gitlab-ci-token используется только с CI_JOB_TOKEN). 😎 Практический план внедрения 1. Создать отдельный репозиторий для CI-шаблонов. Вынести в него общие этапы сборки, тестирования и деплоя. 2. В каждом сервисе заменить локальный громоздкий .gitlab-ci.yml на подключение шаблонов через include. 3. Унифицировать структуру Helm-чартов во всех сервисах. Использовать общую базу для values. 4. Настроить автоматическое вычисление версии чарта на основе git-тега или хэша коммита. 5. Разделять окружения через переменные: staging деплоится автоматически, а prod — строго вручную через when: manual. Результат: в каждом сервисе всего 20–30 строк конфигурации вместо 200. Новый сервис добавляется за 5 минут: копируется лаконичный шаблон, меняется название, запускается пайплайн. Изменения в логике деплоя теперь раскатываются на все сотни сервисов одновременно — простым обновлением центрального шаблона. Хочешь освоить GitLab CI и Helm на практике? 🔥Открывай демодоступы бесплатно🔥: 🔹GitlabCI & Helm & Kubernetes - полный кейс: CI/CD, Helm-чарты, деплой в Kubernetes. 🔹Gitlab CI -пайплайны, артефакты, кэширование, оптимизация и интеграции. 🔹Helm - создание чартов, управление зависимостями, сложная шаблонизация.

GitLab CI + Helm: Управление микросервисами В репозитории 30 микросервисов. Для каждого свой .gitlab-ci.yml. В каждом — по 200 строк повторяющегося кода. Обновление Helm-чарта для нового сервиса — это копирование папки, замена названий и надежда, что ничего не сломается. Деплой в dev, staging и prod — это ручное изменение values.yaml или передача параметров через --set, которые легко забыть. Знакомая архитектура? Когда микросервисов становится больше десяти, поддержка пайплайнов превращается в отдельную работу. Разработчики начинают копировать конфиги из соседних сервисов, не вникая в детали. В результате в разных сервисах пайплайны ведут себя по-разному, а единого стандарта нет. Helm добавляет свой слой сложности. Чарты обычно лежат в отдельном репозитории, и обновление версии чарта — это отдельный коммит, который нужно синхронизировать с изменениями кода. Без автоматизации этот процесс ручной и подвержен ошибкам. 🛠Решение - централизация через include Мы можем вынести всю логику во внешний репозиторий с шаблонами GitLab CI и автоматически управлять версиями чартов. Создаём универсальные шаблоны для всех этапов пайплайна и переиспользуем их во всех сервисах. Структура центрального репозитория с шаблонами (infrastructure/ci-templates): .gitlab/ ├── templates/ │ ├── build.yml │ ├── test.yml │ ├── deploy.yml │ └── helm.yml └── jobs/ ├── build-job.yml └── deploy-job.yml 1️⃣ Шаблон для сборки образа (templates/build.yml) Используем современные правила rules:if вместо устаревших конструкций. .build_template: stage: build image: docker:24.0.7 services: - docker:24.0.7-dind variables: DOCKER_HOST: tcp://docker:2376 DOCKER_TLS_CERTDIR: "/certs" DOCKER_TLS_VERIFY: "1" # на self-managed раннере в config.toml должен быть volumes = ["/certs/client", "/cache"], иначе клиент не увидит сертификаты и джоба упадёт на TLS. На shared-раннерах GitLab.com это уже настроено. DOCKER_CERT_PATH: "/certs/client" script: - echo "$CI_REGISTRY_PASSWORD" | docker login -u "$CI_REGISTRY_USER" --password-stdin "$CI_REGISTRY" - docker build --tag "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA" . - docker push "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA" rules: - if: $CI_PIPELINE_SOURCE == "merge_request_event" when: manual - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH when: always 2️⃣ Шаблон для деплоя с Helm (templates/deploy.yml) .deploy_template: stage: deploy image: alpine/helm:3.12.0 script: - helm upgrade --install "$CI_PROJECT_NAME" ./chart/ \ --set image.repository=$CI_REGISTRY_IMAGE \ --set image.tag=$CI_COMMIT_SHORT_SHA \ --set environment=$DEPLOY_ENV \ --namespace $DEPLOY_ENV \ --create-namespace \ --wait \ --timeout 5m environment: name: $DEPLOY_ENV url: https://$CI_PROJECT_NAME.$DEPLOY_ENV.example.com rules: - if: '$DEPLOY_ENV == "prod" && $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH' when: manual - if: '$DEPLOY_ENV == "staging" && $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH' when: on_success 3️⃣ Как теперь выглядит .gitlab-ci.yml внутри микросервиса Каждый сервис определяет только свои переменные и расширяет (extends) готовые джобы. Обратите внимание на обязательное объявление стадий (stages), включая стадию предварительной подготовки. include: - project: 'infrastructure/ci-templates' ref: main file: '/templates/build.yml' - project: 'infrastructure/ci-templates' ref: main file: '/templates/deploy.yml' variables: SERVICE_NAME: $CI_PROJECT_NAME stages: - prepare - build - test - deploy build: extends: .build_template deploy_staging: extends: .deploy_template variables: DEPLOY_ENV: staging deploy_prod: extends: .deploy_template variables: DEPLOY_ENV: prod

Интенсив «ИИ-агенты для инженеров» с Артуром Сапрыкиным стартует уже на следующей неделе — собрали ответы на частые вопросы и коротко рассказали, как всё будет За 9 живых эфиров с Артуром ты разберёшь, как работают автономные coding-агенты — opencode, Aider и Cline, научишься писать собственные MCP-серверы и подключать их к внутренней инфраструктуре, настраивать связку Architect/Editor для экономии на LLM API и генерировать Helm-чарты и Kubernetes-манифесты силами агента. Отдельно разберёте изоляцию AI-процессов в Docker и защиту от Prompt Injection. Отвечаем на вопросы 👇🏼 🟢 Какой компьютер нужен для интенсива? Минимум: 8 GB RAM, 20 GB на диске, 4 ядра CPU (x86-64 или Apple Silicon), GPU не обязательна — большинство заданий работают на CPU-инференсе. Из ОС подойдёт macOS 12+, Windows 10/11 с WSL2 или Linux, плюс стабильный интернет для загрузки моделей и работы с облачным агентом. Комфортный уровень: 32 GB RAM, 40+ GB на диске, 8 ядер или Apple M-series, а для локальных моделей — видеокарта NVIDIA от 8 GB VRAM или Apple M1 и новее. 🟢Нужно ли платить за подписки на нейросети отдельно? Нет. Все инструменты, которые понадобятся по программе, мы предоставляем сами, а в части заданий будем работать с бесплатными моделями. Доплачивать за доступ к LLM для прохождения курса не придётся. 🟢 Будет ли разбор безопасности? Да, целый блок посвящён изоляции в Docker, аудиту вызовов и защите от prompt injection. 🟢 Нужен ли опыт работы с AI-агентами до старта? Нет, интенсив рассчитан на инженеров без опыта именно с агентами. А вот базовые вещи пригодятся: Git на уровне веток и PR, Docker и контейнеризация, понимание CI/CD и Python на уровне простых скриптов. 🟢 Что если пропущу эфир? Все эфиры записываются, записи остаются у тебя вместе с доступом к чату интенсива — можно посмотреть в своём темпе и задать вопросы Артуру и другим участникам после. 🔥По многочисленным просьбам продлили скидку 10 000 руб. На этой неделе как раз многие решили, что готовы пойти на интенсив. Чтобы дать больше времени на решение, скидка остаётся в силе до 19 июля. 📆Начало занятий — 20 июля 🎁 Скидка 10 000 руб теперь действует до 19 июля. А для участников практикума «LLM для инженеров» дополнительная скидка 3 000 руб. ↘️ Узнать подробности и занять место ✉️ Чтобы получить дополнительную скидку, напиши нашим менеджерам в телеграм, они подробно расскажут о программе и помогут с оплатой.

route: group_by: ['alertname', 'namespace'] group_wait: 30s group_interval: 5m repeat_interval: 12h receiver: default routes: - matchers: - severity = critical receiver: pagerduty - matchers: - severity = warning receiver: slack receivers: - name: default - name: pagerduty pagerduty_configs: - routing_key: <your-routing-key> - name: slack slack_configs: - channel: '#alerts' api_url: <webhook-url> Важный момент - группировка. Параметр group_by: ['alertname', 'namespace'] объединяет похожие алерты в одно компактное уведомление. Вместо десяти отдельных сообщений в Slack о том, что разные поды упали в одном сис-окружении, вы получите всего одно емкое оповещение. Также не забывайте про Inhibition rules (правила взаимоподавления). Если узел (`NodeNotReady`) стал недоступен, все алерты о падении конкретных подов на этом узле должны подавляться автоматически. Нет никакого смысла читать спам о смерти пяти контейнеров, если упал весь сервер, на котором они были запущены. Практический план внедрения 1️⃣ Установить kube-prometheus-stack через Helm с кастомным values-файлом. 2️⃣ Отключить или переопределить избыточные стандартные правила, оставив только критический минимум. Добавить свои правила через additionalPrometheusRulesMap. 3️⃣ Настроить recording rules для тяжёлых графиков, которые выводятся на главные экраны. 4️⃣ Сконфигурировать Alertmanager: задать маршрутизацию по severity, настроить группировку и правила подавления (inhibition). 5️⃣ Подключить каналы уведомлений (`receivers`): Slack/Telegram для предупреждений, PagerDuty или Opsgenie — для ночных критических звонков. 6️⃣ Включить нотификации в тестовом режиме на пару дней и откалибровать пороги срабатывания. 7️⃣ Постепенно добавлять новые алерты, но только тогда, когда старые перестали давать ложные срабатывания. Правильно настроенный мониторинг - это когда вы узнаёте о проблеме до того, как она повлияла на бизнес, и получаете ровно столько уведомлений, сколько ваша команда способна обработать без выгорания. 🔥Открывай демодоступы бесплатно и начинай разбираться: 🔹 Kube Prometheus Stack - полный стек мониторинга на практике: Prometheus, Alertmanager, Grafana, ServiceMonitor, PrometheusRule. 🔹 Grafana - визуализация, продвинутые дашборды, алертинг и интеграции.

Настройка kube-prometheus-stack Развернул kube-prometheus-stack, дашборды в Grafana зелёные. Проходит неделя - и выясняется, что прод упал ещё вчера в 3 часа ночи. Метрики есть, графики зафиксировали момент, но никто не получил уведомление. Или наоборот: каждые пять минут приходит алерт о том, что под перезапустился. Команда перестаёт реагировать на оповещения, а когда случается реальная проблема - её замечают пользователи, а не инженеры. Стандартная установка kube-prometheus-stack поставляется с сотнями предустановленных правил. Многие команды либо отключают их все из-за шума, либо оставляют как есть и тонут в бесконечном потоке уведомлений. В результате мониторинг перестаёт быть инструментом и становится источником раздражения. Проблема не в том, что метрики не собираются. Они собираются, и даже слишком много. Проблема в том, что алерты не настроены под конкретную архитектуру, а Alertmanager не умеет правильно маршрутизировать оповещения. Шаг 1️⃣ Кастомизируем правила и убираем шум Решение начинается с осознания: мониторинг - это про то, чтобы узнать о проблеме до того, как её заметит пользователь. И для этого нужны три вещи: правильные правила, умная маршрутизация и контроль над шумом. Начнём с правил. Оставляем пять-десять действительно важных. Каждый алерт должен иметь чёткое действие. Если на оповещение нельзя ответить действием - это не алерт, это шум. Создаём PrometheusRule с базовым набором. Обратите внимание на алерт PodCrashLooping: вместо капризной функции rate, которая сбрасывает таймер, как только под затих, мы используем точечный фильтр по статусу CrashLoopBackOff. apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: kubernetes-essential namespace: monitoring spec: groups: - name: kubernetes.essential rules: - alert: PodCrashLooping expr: kube_pod_container_status_waiting_reason{reason="CrashLoopBackOff"} == 1 for: 10m labels: severity: warning annotations: summary: "Pod {{ $labels.namespace }}/{{ $labels.pod }} is crash looping" - alert: NodeNotReady expr: kube_node_status_condition{condition="Ready",status="true"} == 0 for: 5m labels: severity: critical annotations: summary: "Node {{ $labels.node }} is not ready" - alert: HighErrorRate expr: | sum(rate(http_requests_total{status=~"5.."}[5m])) by (service) / sum(rate(http_requests_total[5m])) by (service) > 0.05 for: 10m labels: severity: critical annotations: summary: "{{ $labels.service }} has {{ $value | humanizePercentage }} error rate" Это минимальный базовый набор. PodCrashLooping, NodeNotReady и HighErrorRate покрывают большинство критических сценариев, когда в кластере что-то ломается. Тяжёлые запросы и Recording Rules Если вы часто используете сложные вычисления в дашбордах, они создают высокую нагрузку на Prometheus. Используем recording rules - они вычисляют выражение один раз по расписанию и сохраняют результат как новую готовую метрику: - name: recording.rules rules: - record: namespace:pod_cpu:rate5m expr: sum(rate(container_cpu_usage_seconds_total[5m])) by (namespace, pod) Теперь вместо того чтобы каждый раз нагружать CPU вычислением этого агрегата при открытии Grafana, Prometheus моментально отдаёт уже записанное значение. Шаг 2️⃣ Настраиваем Alertmanager Даже самые правильные алерты бесполезны, если они приходят не тем людям или в неподходящее время. Настроим Alertmanager. Настраиваем маршрутизацию по уровню критичности (`severity`) в нативном формате Alertmanager. Критические алерты отправляем в PagerDuty, предупреждения - в Slack, а для непредвиденных ситуаций оставляем дефолтный маршрут:

⏳ Завтра последний день — траблшутинг Nginx Reverse Proxy закрывается 15 июля. 📖 Открыли теорию: разобрали, как nginx находит upstream и откуда берётся классический 502, почему сервис не стартует с виду правильным конфигом, и как ловить OOM Killer раньше, чем это сделает продакшен. Ещё есть время подключиться к живому серверу и починить прокси, который перестал пускать клиентов дальше себя. 🏆 Инженер, который быстрее всех решит задачу, получит любой модуль стоимостью до 30 000 рублей 🟢Среди остальных участников разыграем две годовые подписки на вебинары ↘️ Решить задачу Эфир с разбором задачи проведем 17 июля, регистрация уже открыта: https://clck.ru/3Umgcp

Что будет, если объединить FreeIPA + Bash + Ansible? Обычно управление инфраструктурой держится на трёх разрозненных инструментах. Пользователей заводят вручную на каждой машине, единого каталога доступа нет, а рутинные задачи закрывают Bash-скриптами вместо того, чтобы оформить их в Ansible-роль и использовать на всех серверах. Мы собрали FreeIPA, Bash и Ansible в один практикум: управление инфраструктурой и рабочими станциями, чтобы инженер мог настроить централизованный доступ, автоматизировать рутину через скрипты и роли и держать всю инфраструктуру под контролем из одной точки. Тебя ждёт: 🟢Развертывание отказоустойчивых кластеров FreeIPA и управление политиками доступа. 🟢Интеграция Linux-инфраструктуры с Active Directory через trust-отношения. 🟢Написание безопасных и отказоустойчивых Bash-скриптов для автоматизации задач. 🟢Профессиональный парсинг и обработка сложных логов с помощью sed и awk. 🟢Разработка, структурирование и тестирование Ansible-ролей с помощью Molecule. 🟢Обеспечение качества IaC-кода через статический анализ и безопасное управление секретами. ↘️ Подробная о программа Финальный проект Собираешь все три навыка вместе: разворачиваешь отказоустойчивый домен FreeIPA, пишешь Bash-скрипты для сбора логов и автоматизируешь рабочие станции через Ansible. 🎁 До 19 июля действует скидка 7 500 рублей для новых участников ↘️ Купить практикум со скидкой Если ты системный администратор, DevOps-инженер или инженер инфраструктуры и хочешь навести порядок в доступах и автоматизации — этот практикум для тебя 🤍