В понедельник первое занятие интенсива «ИИ-агенты для инженеров». Делимся подробностями, что будет на первом эфире.

Урок называется «Основы coding-агентов: архитектура, запуск и первый ReAct-цикл». Разберём, чем автономный агент отличается от обычного автодополнения кода вроде Copilot, и почему это не одно и то же.

На занятии пройдём:

🟢что такое агент и в чём разница между уровнями автономности
🟢анатомию агента и ReAct-цикл: как он рассуждает (Reason) и действует (Act)
🟢установку и первый запуск opencode на чистой машине
🟢управление контекстным окном: лимиты, счётчики токенов, что делать при деградации контекста

После занятия ты будешь понимать архитектурные отличия автономных агентов от систем автодополнения кода, сможешь сам установить и запустить opencode в рабочем окружении и разберёшь логи tool calls в verbose-режиме, чтобы дебажить действия агента.

Практика: разворачиваешь виртуальную машину, ставишь opencode, запускаешь агента в verbose-режиме и поручаешь ему написать Python-скрипт с тестами, а потом разбираешь вывод ReAct-цикла: что агент думал и какие инструменты вызывал.

📆 До понедельника остались считаные дни. Если ещё не занял место, самое время присоединиться.

↘️ Узнать подробности и занять место

🟡 Анонс открытых практикумов на следующую неделю

1️⃣ Введение в протокол IPv6
↘ Регистрация

Время проведения:
21 июля 2026, вторник, 19:00 по МСК

Программа практикума:
🟢IPv6: основные теоретические сведения
🟢Виды IPv6-адресов
🟢Базовая настройка IPv6 на маршрутизаторах Cisco и Eltex

Кто ведёт?
Андрей Шабалин — Тренер Cisco / Huawei, инструктор академии Eltex и Астра-Университета
---------------------------------------------------------------------------------------

2️⃣ Для чего усложнять работу с дисками? Знакомство в LVM
↘ Регистрация

Время проведения:
22 июля 2026, среда, 20:00 по МСК

Программа практикума:
🟢Что такое LVM
🟢Плюсы LVM
🟢Базовая работа с LVM

Кто ведёт?
Андрей Буранов — системный администратор в департаменте VK Play, 10+ лет опыта работы с ОС Linux, 8+ лет опыта преподавания. Входит в топ 3 лучших преподавателей образовательных порталов
---------------------------------------------------------------------------------------

3️⃣ DockerCustom Image
↘ Регистрация

Время проведения:
23 июля 2026, четверг, 19:00 по МСК

Программа практикума:
🟢Кейсы, где свой образ реально помогает: зависимости, утилиты, сертификаты, агенты, базовые настройки
🟢Что класть в образ, а что оставить в env, secrets или runtime-конфигурации
🟢Практика: собираем свой образ, уменьшаем размер через multi-stage build и пушим в registry

Кто ведёт?
Кирилл Ряховский — практикующий DevOps-инженер с 8-летним опытом в инфраструктуре и автоматизации (Linux, K8s, CI/CD, IaC), прошедший путь от системного администратора до разработки.

Анализ логов в реальном времени: От syslog до EFK с фильтрацией

Приложение упало в 2 часа ночи. Разработчик пишет в чат: «Смотри логи». Ты заходишь на сервер, выполняешь kubectl logs — но под уже перезапустился, и логи пропали. В классической инфраструктуре мы привыкли полагаться на локальный syslog или journald, но когда логи разбросаны по десяти разным хостам или сотне эфемерных контейнеров, поиск ошибки превращается в лотерею. Открывать каждую машину по SSH и на ощупь перебирать файлы ротируемых логов с помощью grep и awk — тупиковый путь. Найти баг, который произошел строго между 23:00 и 23:05 на конкретном эндпоинте, в таких условиях практически невозможно.

Централизованный сбор логов решает эти проблемы раз и навсегда. В классическом стеке EFK (Elasticsearch, Fluentd, Kibana) обязанности разделены максимально эффективно:

🔹 Fluentd — собирает, парсит и фильтрует данные;
🔹 Elasticsearch — хранит и индексирует их;
🔹 Kibana — дает удобный UI для поиска и аналитики.

Шаг 1️⃣ Настройка Fluentd и фильтрация

Fluentd запускается как DaemonSet в Kubernetes или как агент на хостах. Он собирает стандартный вывод контейнеров или читает системные файлы.

Вот базовый конфиг, который собирает логи Nginx, парсит их «на лету» и фильтрует, отсекая лишние успешные запросы (200 OK), чтобы не забивать хранилище:

<source>
  @type tail
  path /var/log/nginx/access.log
  pos_file /var/log/nginx/access.log.pos
  tag nginx.access
  <parse>
    @type nginx
  </parse>
</source>

# Фильтруем: исключаем из отправки логи со статус-кодом 200
<filter nginx.access>
  @type grep
  <exclude>
    key code
    pattern /^200$/
  </exclude>
</filter>

<match nginx.access>
  @type elasticsearch_data_stream
  host elasticsearch-service
  port 9200
  # пишем в data stream, а не в датовый индекс. только так работает ILM-rollover
  data_stream_name nginx-logs
  data_stream_template_name nginx-logs
  data_stream_ilm_name logs-policy
  <buffer>
    flush_interval 5s
  </buffer>
</match>

Если приложение сыплет многострочными ошибками (стектрейсами), обычный tail разобьет их на отдельные строки. Чтобы этого не произошло, настраиваем мультилайн-парсер:

<parse>
  @type multiline
  format_firstline /^\d{4}-\d{2}-\d{2}/
  format1 /^(?<time>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}.\d{3}) (?<level>[A-Z]+) (?<message>.+)/
</parse>

Для контейнеров обязательно включаем обогащение метаданными Kubernetes. Это добавит в каждый лог контекст: namespace, имя пода и лейблы.

<filter kubernetes.**>
  @type kubernetes_metadata
</filter>

Шаг 2️⃣ Оптимизация Elasticsearch (ILM)

Без управления индексами Elasticsearch быстро съест весь диск, а поиск станет невыносимо медленным. Настраиваем Index Lifecycle Management (ILM) политику, чтобы вовремя перемещать старые данные на дешевые диски и удалять их:

PUT _ilm/policy/logs-policy
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": {
            "max_primary_shard_size": "50gb",
            "max_age": "7d"
          },
          "set_priority": { "priority": 100 }
        }
      },
      "warm": {
        "min_age": "0ms",
        "actions": {
          "forcemerge": { "max_num_segments": 1 },
          "set_priority": { "priority": 50 }
        }
      },
      "delete": {
        "min_age": "90d",
        "actions": { "delete": {} }
      }
    }
  }
}

PUT _index_template/nginx-logs
{
  "index_patterns": ["nginx-logs*"],
  "data_stream": {},
  "priority": 200,
  "template": {
    "settings": {
      "index.lifecycle.name": "logs-policy",
      "number_of_shards": 1,
      "number_of_replicas": 1
    }
  }
}

🎁 До -30% на ВСЕ практикумы в честь грядущего дня сисадмина

У нас в Rebrain это уже традиция на день сисадмина устраивать распродажи. В этот раз скидка до 30% будет действовать до 28 июля, 23:59 мск. Если давно поглядываешь на практикум и ждёшь повод — вот он.

Самые популярные практикумы сейчас:

🟢 DevOps-инженер [ экономия 48 000 ₽ ]
🟢 Системный администратор [ экономия 40 200 ₽ ]
🟢 Linux Basics [ экономия 22 500 ₽ ]
🟢 Kubernetes (Base + Admin) [ экономия 34 500 ₽ ]
🟢 Linux Advanced [ экономия 27 000 ₽ ]
🟢 Прикладной LLM для инженеров [ экономия 19 500 ₽ ]
🟢 Linux: Анализ производительности и тюнинг [ экономия 9 000 ₽ ]
🟢 Повышение привилегий в Linux [ экономия 7 500 ₽ ]
🟢 Zabbix [ экономия 9 000 ₽ ]
🟢 Container Security [ экономия 9 000 ₽ ]
🟢 Proxmox [ экономия 9 000 ₽ ]
🟢 Patroni [ экономия 9 000 ₽ ]

Скидки действуют и на остальные программы, полный список доступен на платформе или на нашем сайте🤍

К большинству практикумов есть демодоступ: можно попробовать бесплатно и понять, подходит ли программа.

↘️ Смотреть все практикумы со скидкой

⌚Распродажа будет проходить до 28 июля. Сейчас отличный момент, чтобы разобраться в Kubernetes, подтянуть Linux или освоить новые технологии 🤍

🎁 А при полной оплате скидка увеличивается до 35% - это самый выгодный вариант. Промокод на дополнительную скидку можно запросить у нашего менеджера в телеграм.

Показываем фрагмент первого эфира интенсива «ИИ-агенты для инженеров» с Артуром Сапрыкиным 👀

На видео база, без которой дальше никуда: как LLM вызывает инструменты read, search, shell, edit и git, и что модель получает на каждом шаге: задачу, файлы, историю, результаты вызовов. Отдельно разобрали permissions и compaction: они защищают проект от опасных действий и не дают контексту разрастись до бесконечности.

Дальше больше 🔥

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

↘️ Присоединиться к интенсиву

Настройка Network Policies в Kubernetes для изоляции сервисов

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

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

Network Policies решают эту проблему. Это механизм, который позволяет определить, какие поды могут общаться друг с другом, а какие - нет. NetworkPolicy работает на уровне L3/L4 (IP/порты) и фильтрует входящий (`ingress`) и исходящий (`egress`) трафик.

Важный нюанс: NetworkPolicy - это API-объект, спецификацию которого должен принудительно исполнять ваш CNI-плагин. Cilium и Calico - поддерживают политики из коробки. Популярный Flannel - нет. Если CNI не поддерживает NetworkPolicy, вы можете создать сколько угодно таких объектов, но они просто будут игнорироваться.

Первым делом проверяем, какой CNI управляет сетью:

kubectl get pods -n kube-system -l k8s-app=calico-node
# или проверяем наличие Cilium
kubectl get pods -n kube-system -l app.kubernetes.io/name=cilium-agent

1️⃣Главный принцип: Deny by Default
Основной подход при работе с Network Policies - deny by default, allow explicitly (запрещено по умолчанию, разрешено только явно). Вместо того чтобы пытаться точечно блокировать опасные направления, мы сначала закрываем вообще всё, а затем аккуратно открываем нужные доступы.

Создаём политику, которая полностью блокирует весь входящий и исходящий трафик для всех подов в неймспейсе production:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}  # Пустой селектор выбирает ВСЕ поды в данном неймспейсе
  policyTypes:
  - Ingress
  - Egress

podSelector: {} указывает, что правило применяется ко всем без исключения подам в неймспейсе production. А пустые блоки ingress и egress (так как мы их не описали ниже) означают полный запрет.

После применения этой политики поды в production оказываются в полной изоляции. У них перестают работать даже DNS-запросы, потому что это тоже исходящий (`egress`) трафик. Исправляем это.

Шаг 2️⃣: разрешаем DNS-резолв
Добавляем политику, которая позволит подам отправлять DNS-запросы к CoreDNS. Без этого приложения не смогут разрешить имена соседних сервисов:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: production
spec:
  podSelector: {} # Применяется ко всем подам в production
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
         matchLabels:
           k8s-app: kube-dns

    ports:
    - protocol: UDP
      port: 53
    - protocol: TCP
      port: 53

Здесь мы используем встроенный системный лейбл kubernetes.io/metadata.name: kube-system. Он автоматически присваивается неймспейсам в Kubernetes, что избавляет нас от необходимости маркировать kube-system вручную. PodSelector позволяет задать конкретный поды с dns и открыть трафик только к ним.


Шаг3️⃣: точечный доступ (Связываем Frontend и Backend)
Теперь разрешаем нашему фронтенду обращаться к бэкенду. Нам нужно настроить Ingress-правило для бэкенда:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Bash: скрипты, которые не разваливаются в проде

Bash-скрипты есть в каждой Linux-инфраструктуре: бэкапы, деплой, мониторинг, cron-джобы. Большинство пишут скрипты без строгого режима отладки, обработки сигналов и без защиты от повторного запуска, поэтому они непредсказуемо падают в проде.

Мы собрали практикум по Bash, чтобы инженеры писали безопасные, отказоустойчивые скрипты для инфраструктуры: от строгого режима отладки до парсинга логов без Python.

Вас ждёт:

🟢Уверенное написание скриптов с использованием ветвлений, циклов и функций
🟢Применение строгого режима отладки (set -euo pipefail) для предотвращения скрытых ошибок
🟢Профессиональный парсинг и трансформация логов с помощью sed и awk
🟢Безопасная обработка пользовательского ввода, аргументов командной строки и сигналов ОС
🟢Автоматизация выполнения скриптов через системные планировщики с защитой от параллельного запуска

↘️ Подробная программа

В финальном проекте вы соберёте production-ready утилиту мониторинга дискового пространства и inode: пороги алертов через getopts, lock-файл против повторного запуска, логирование в syslog, обработка сигналов завершения через trap и запуск по расписанию cron.

Практикум уровня Junior/Middle: нужна уверенная работа в командной строке Linux и опыт работы с любым консольным текстовым редактором (Nano, Vim). Отдельно добавили пять тренажёров, более сложные практические задачи: настройка веб-сервера в интерактивном режиме, аудит конфигураций, сбор диагностических данных, проверка доступности сервисов и умная очистка диска.

🎁 До 28 июля на практикум действует скидка -30%

↘️ Купить практикум Bash
↘️ Купить практикум Bash + тренажёры

Напоминаем, что у нас до 28 июля действует скидка до -30% на все программы, начать можно с бесплатного демодоступа 🤍

↘️ Выбрать практикум

Если бы герои сериала «Пацаны» работали в IT, кем бы они были и на какие практикумы пошли бы учиться?

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

🥊 Билли Бутчер | SRE-инженер | Практикум: Ansible

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

🎧 Хьюи Кэмпбелл | Junior-инженер | Практикум: Linux Basics

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

🇺🇸 Хоумлендер | Senior-разработчик с легаси в проде | Практикум: Gitlab CI

Годами прячет проблемы за фасадом пиар-отдела, но ни один pull request так просто не спрячешь. Нормально настроенный пайплайн ловит баги раньше, чем они долетают до прод-релиза.

🤟 Кимико | Инженер мониторинга | Практикум: Zabbix

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

🧪 Французик | DevOps-инженер | Практикум: Docker Swarm

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

🐟 Подводный | Junior DevOps-инженер | Практикум: Kubernetes Base

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

Ставьте 🔥 если смотрели сериал. До 28 июля у нас действует скидка до -30% на все практикумы в честь дня сисадмина. И до -35% при полной оплате. Почти на всех практикумах есть демодоступ - можно начать бесплатно.

↘️ Выбрать практикум

🟡 Анонс открытых практикумов на следующую неделю

1️⃣ CI/CD, который собирается 40 минут. Как ускорить?
↘ Регистрация

Время проведения:
28 июля 2026, вторник, 19:00 по МСК

Программа практикума:
🟢Анализ: какой этап жрет больше всего (сборка, тесты, сборка образа)
🟢Кэширование зависимостей (npm, go mod, pip) — настройка cache: key
🟢Артефакты: как не таскать туда-сюда гигабайты node_modules

Кто ведёт?
Дмитрий Куликов — DevOps-инженер с 7+ лет опыта в IT. Специализация: построение и автоматизация IT-инфраструктуры.
---------------------------------------------------------------------------------------

2️⃣ Как я уронил prod в пятницу вечером и что мне за это было (Postmortem)
↘ Регистрация

Время проведения:
29 июля 2026, среда, 20:00 по МСК

Программа практикума:
🟢Разбор реального инцидента: почему git push сломал всё, а не только код
🟢Правила написания ""Blameless Postmortem"" — отчет, после которого не увольняют
🟢3 главных правила, чтобы не повторить мою ошибку (CI/CD гейты, canary deployment)

Кто ведёт?
Илья Сачков — DevOps-инженер в «Аптеки — Плюс» и автор курса «Linux Basics» Rebrain. Его стек — AWS, Яндекс Облако, Kubernetes, Terraform, Ansible, а наличие сертификатов IBS по Kubernetes и MTCNA подтверждает высокий уровень владения инфраструктурными решениями.
---------------------------------------------------------------------------------------

3️⃣ Ошибки как значения: философия обработки ошибок в Go
↘ Регистрация

Время проведения:
30 июля 2026, четверг, 20:00 по МСК

Программа практикума:
🟢Ошибка — это значение, а не исключение
🟢Явная обработка ошибок
🟢Простота и предсказуемость
🟢Контекст ошибок
🟢Паника не заменяет ошибки
🟢Влияние на качество кода

Кто ведёт?
Дмитрий Гордеев — тимлид разработки облачных решений в X5 Tech с опытом работы в Go больше 5 лет

Динамическое конфигурирование: как перезагрузить Nginx без потери соединений

Поменяли конфиг Nginx, выполнили nginx -s reload — и в логах посыпались ошибки от клиентов. WebSocket-сессии упали, загрузка больших файлов прервалась, а пользователи обновляют страницы. Вроде бы сделали reload, а не restart, но часть соединений всё равно потерялась.

Почему так происходит и как сделать перезагрузку по-настоящему бесшовной?
Давайте разбираться.

💡 Как работает Graceful Reload

Когда вы отправляете сигнал nginx -s reload, главный процесс (Master) получает сигнал SIGHUP и запускает целую цепочку событий:

1️⃣ Проверка: Master-процесс проверяет синтаксис новой конфигурации. Если там ошибка, релоад отменяется, а Nginx продолжает работать на старом конфиге (это встроенная защита).
2️⃣ Запуск новых воркеров: Если всё ок, Master запускает новые рабочие процессы (Workers) с обновленной конфигурацией.
3️⃣ Мгновенный подхват трафика: Новые воркеры сразу начинают принимать новые запросы. Им не нужно заново занимать порты — слушающие сокеты всегда удерживает Master-процесс.
4️⃣ Увядание старых воркеров: Старые процессы получают сигнал на закрытие. Они перестают принимать новые соединения (выходят из цикла `accept`) и занимаются только обслуживанием уже открытых сессий.

❓ Почему рвутся соединения

Если схема идеальна, откуда ошибки? Причин обычно две:

🔹 Директива worker_shutdown_timeout: По умолчанию старые воркеры ждут завершения всех своих соединений бесконечно. Но во многих конфигах (или дефолтных чартах Kubernetes) выставляют этот таймаут (например, 5 минут). Как только время истекает, старый воркер принудительно завершается, убивая все живые WebSocket-сессии и недокачанные файлы.
🔹 Специфика HTTP/2 и HTTP/3: При релоаде Nginx отправляет клиентам фрейм GOAWAY. Это вежливое «переподключитесь, пожалуйста». Большинство современных браузеров делают это незаметно, но самописные клиенты или старые библиотеки могут выдать ошибку соединения.

😎 Правильный пайплайн обновления конфигурации

Чтобы минимизировать риски в продакшене, автоматизация (CI/CD, Ansible, Bash) должна следовать строгому алгоритму.

1️⃣ Атомарная проверка и перезагрузка

Никогда не делайте reload вслепую. Сначала — валидация.

Пример безопасного Bash-скрипта для продакшена:

#!/bin/bash
set -e

# Проверяем синтаксис конфигурации
if nginx -t > /dev/null 2>&1; then
    echo " Настройка корректна. Перезапускаем воркеры..."
    nginx -s reload
    echo " Релоад успешно выполнен."
else
    echo " Ошибка в конфиге! Отмена операции."
    nginx -t # Выводим ошибку в консоль для логирования
    exit 1
fi

2️⃣ Особенности работы в Docker и Kubernetes

В контейнерах Nginx обычно работает как PID 1. Перезапускать сам контейнер ради смены конфига — плохая идея (это гарантированный даунтайн).

Вместо этого отправляйте сигнал прямо в контейнер:

docker kill -s HUP <container_name_or_id>

Совет: если вы используете динамическую генерацию конфигов (например, через consul-template или envsubst`), обязательно прогоняйте `docker exec <container> nginx -t перед тем, как слать сигнал HUP.

Настройка баланса: `worker_shutdown_timeout`

Внесите эту директиву в главный блок nginx.conf (на уровне main, рядом с `worker_processes`), чтобы контролировать жизненный цикл старых процессов:

worker_processes auto;
worker_shutdown_timeout 15m; # Даем старым воркерам 15 минут на завершение долгих скачиваний

🔹 Если у вас много WebSocket/EventSource соединений, ставьте таймаут больше или не ставьте вовсе (но следите за потреблением памяти старыми процессами).
🔹 Если у вас обычный REST API — достаточно 10–30 секунд, чтобы «долить» долгие запросы.