DevOps by REBRAIN

❗ Открытый практикум Отправка событий безопасности из MS Windows в ELK-стек средствами Winlogbeat идёт уже 30 минут Если вы ещё не с нами, скорее подключайтесь! Ссылка для входа: https://my.rebrainme.com/live-class/501 🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате

❗Начало Открытого практикума Отправка событий безопасности из MS Windows в ELK-стек средствами Winlogbeat уже через 5 минут Встречаемся в 19:00 МСК. Ссылка для входа: https://my.rebrainme.com/live-class/501 Также вы можете подключиться к вебинару через личный кабинет, в разделе «Вебинары». 🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате

Открытый практикум Отправка событий безопасности из MS Windows в ELK-стек средствами Winlogbeat начнётся сегодня в 19:00 МСК. Практикум будет проходить на площадке Zoom.US Важно!!! Чтобы вы смогли без проблем к нам присоединиться, заранее протестируйте комнату по ссылке: https://zoom.us/test Ссылку для доступа отправим вам за 5 минут до начала. Либо заходите через личный кабинет в разделе «Вебинары». 🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате

🗓️ Расписание вебинаров на сегодня ⏰ 19:00 МСК - Отправка событий безопасности из MS Windows в ELK-стек средствами Winlogbeat 🔗 Регистрация и программа О вебинаре напомним за 5 минут до начала на этом канале. Также вы сможете зайти через личный кабинет. 🔥 Задать вопросы и обсудить детали можно в нашем чате

⏳ Завтра последний день — траблшутинг 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-инженер или инженер инфраструктуры и хочешь навести порядок в доступах и автоматизации — этот практикум для тебя 🤍

Практический план внедрения 1. Соберите манифесты: определите все ресурсы, которые должны управляться через Argo CD, и перенесите их в Git. 2. Настройте политики безопасности: начните с selfHeal: true и prune: false для продакшена, чтобы защитить данные. На стейдже сразу включайте prune: true. 3. Подключите уведомления: настройте Argo CD Notifications в Slack или Telegram, чтобы мгновенно узнавать о сбоях синхронизации. 4. Внедрите App-of-Apps: централизуйте управление всеми сервисами кластера через один корневой репозиторий. 5. Оптимизируйте Webhooks: настройте webhook от GitHub/GitLab к Argo CD, чтобы синхронизация начиналась мгновенно при пуше, не дожидаясь стандартного 3-минутного опроса (polling). 6. Договоритесь на берегу: обучите команду главному правилу GitOps — никогда не менять ресурсы в кластере напрямую. Только через git commit и git push. Если нарушить этот принцип, Argo CD либо молча перезапишет ваши изменения (при `selfHeal`), либо оставит кластер в перманентном рассинхроне. Единственный правильный подход: commit в Git, а не apply в консоли. Чтобы освоить GitOps на практике, включая работу с Helm-чартами, настройку мультикластерного деплоя и управление конфигурациями, 🔥открывай демодоступы бесплатно🔥 и начинай погружаться в технологию: * Argo CD - установка, настройка, App-of-Apps, интеграция с Helm * Git - продвинутая работа с репозиториями, ветвление, стратегии слияния * Helm - создание чартов, управление зависимостями, шаблонизация

Когда Argo CD не синхронизирует состояние Развернул приложение через Argo CD, всё зелёное, синхронизация прошла успешно. Через час заходишь - висит статус OutOfSync. Непонятно, кто и что изменил. Вроде бы репозиторий не трогали, но кластер думает иначе. Или другая ситуация: разработчик запушил изменения, Argo CD их подхватил, но деплой завис, потому что какой-то ресурс уже существует и его нельзя обновить. А на следующий день выясняется, что кто-то из коллег выполнил kubectl apply вручную, и теперь состояние кластера расходится с Git-репозиторием. 🤔 Главная проблема - непонимание источника истины. В GitOps источник истины - это Git-репозиторий. Любое изменение в кластере, сделанное в обход Git, создаёт рассинхрон. Argo CD это видит, но не знает, что с этим делать, если политики не настроены правильно. 🛠Решение - корректная настройка политик синхронизации Для каждого приложения в Argo CD можно определить, как именно оно должно синхронизироваться с репозиторием. Вот пример конфигурации с тремя ключевыми параметрами:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    targetRevision: HEAD
    path: guestbook
  destination:
    server: https://kubernetes.default.svc
    namespace: guestbook
  syncPolicy:
    automated:
      prune: false        # Не удалять ресурсы, которых нет в Git
      selfHeal: true      # Автоматически возвращать состояние из Git при дрифте
    syncOptions:
    - CreateNamespace=true

🔹 `selfHeal: true` - самый важный параметр для борьбы с «ручными» правками. Он автоматически возвращает кластер к состоянию, описанному в Git, если кто-то изменил ресурс через kubectl edit или apply. Без этого параметра любое ручное вмешательство оставит приложение в статусе OutOfSync. 🔹 `prune: false` - осторожная настройка на этапе миграции. Мы запрещаем Argo CD удалять из кластера ресурсы, которые не описаны в Git. Это защита от случайной потери данных. Включать prune: true (что является стандартом для честного GitOps) стоит тогда, когда вы полностью уверены в чистоте своих манифестов. 🔹 `- CreateNamespace=true` - опция в syncOptions, которая указывает Argo CD автоматически создать целевой namespace в кластере, если его еще не существует. Избавляет от лишних ручных шагов. 😎Масштабируем подход: паттерн App-of-Apps Для больших проектов используется паттерн App-of-Apps (приложение приложений). Это подход, при котором одно главное («рутовое») приложение Argo CD управляет набором других дочерних приложений. Важно: Корневое приложение должно разворачивать дочерние манифесты строго в тот namespace, где работает сам контроллер Argo CD (обычно `argocd`), иначе система их не распознает.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: app-of-apps
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/org/infra.git
    targetRevision: HEAD
    path: apps/
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd  # Обязательно указываем namespace Argo CD
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Каждое дочернее приложение в директории apps/ описывается собственным YAML-файлом и может иметь свои уникальные политики. Например, для баз данных можно оставить prune: false, а для легковесного фронтенда - prune: true. Дополнительно внутри дочерних ресурсов можно использовать Sync Waves (волны синхронизации), чтобы управлять очередью развертывания. Например, сначала гарантированно поднять базу данных, а только потом - зависимый бэкенд:

metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "1"

Ресурсы с меньшим значением волны (включая отрицательные числа) запускаются и проверяются на готовность раньше остальных.

Делимся записью открытого практикума "Что такое ИИ-агенты и почему они сделали LLM полезным", где с Артуром Сапрыкиным разобрали, почему современные языковые модели — это больше, чем просто чат, как устроены ИИ-агенты и как они меняют подход к автоматизации. 20 июля у Артура стартует интенсив «ИИ-агенты для инженеров». Подробности тут: https://clck.ru/3UTeAG Краткий конспект видео 👇🏼 🟢 Модель и агенты — важно разделять мыслительные функции и практическое исполнение. Большая языковая модель выступает в роли координатора, который планирует шаги, а агент является непосредственным исполнителем задач. 🟢Ограничения базовых систем — стандартные текстовые генераторы без специальных надстроек не могут зайти в интернет, отправить электронное письмо или самостоятельно выполнить запрос к базе данных. 🟢 Вспомогательные инструменты — это программные модули, которые система вызывает для работы: код для построения графиков, доступ к корпоративным системам или почтовым серверам. 🟢 Планирование и логика — современные решения используют цепочки размышлений, чтобы разбивать сложную задачу на этапы. Система способна самостоятельно исправлять свои недочеты, анализируя полученные в процессе работы ошибки. 🟢Долговременная память — помимо текущего контекста диалога, программы используют внешние хранилища и базы данных. Это позволяет им помнить предпочтения человека и специфику компании в течение длительного времени. 🟢Совместная работа систем — несколько цифровых помощников могут объединяться для решения одной задачи, где один ищет данные, другой их анализирует, а третий составляет итоговый отчет. 🟢Безопасность и мониторинг — чтобы предотвратить нежелательные действия, необходимо жестко ограничивать права доступа и использовать специальные инструменты для фиксации каждого шага программы. Для ответственных задач лучше применять заранее прописанные сценарии. ↘️ Смотреть в ВК ↘️ Смотреть в Youtube Если тебе интересна тема ИИ-агентов и ты хочешь разобраться, как внедрить искусственный интеллект в разработку и автоматизацию инфраструктуры, то ждем тебя на живом интенсиве «ИИ-агенты для инженеров», где за 9 занятий ты пройдешь весь путь. ↘️ Узнать подробнее об интенсиве и записаться

🟡 Анонс открытых практикумов на следующую неделю 1️⃣ Отправка событий безопасности из MS Windows в ELK-стек средствами Winlogbeat ↘ Регистрация Время проведения: 14 июля 2026, вторник, 19:00 по МСК Программа практикума: 🟢Агент Winlogbeat: основные теоретические сведения 🟢Установка и базовая конфигурация ELK 🟢Настройка сбора событий безопасности c MS Windows Кто ведёт? Андрей Шабалин — Тренер Cisco / Huawei, инструктор академии Eltex и Астра-Университета --------------------------------------------------------------------------------------- 2️⃣ RAID массивы ↘ Регистрация Время проведения: 15 июля 2026, среда, 20:00 по МСК Программа практикума: 🟢Некоторые уровни RAID массивов 🟢Виды RAID массивов 🟢Создание RAID массива и работа с ним Кто ведёт? Андрей Буранов — системный администратор в департаменте VK Play, 10+ лет опыта работы с ОС Linux, 8+ лет опыта преподавания. Входит в топ 3 лучших преподавателей образовательных порталов --------------------------------------------------------------------------------------- 3️⃣ IPTables-2 ↘ Регистрация Время проведения: 16 июля 2026, четверг, 19:00 по МСК Программа практикума: 🟢Перенаправление пакетов 🟢Работа с NAT 🟢Маркировка трафика 🟢Логирование пакетов 🟢Ограничения (rate limiting) 🟢Изменение свойств пакета (mangle) 🟢Работа со списками (IPSet) 🟢Создание собственных цепочек Кто ведёт? Николай Лавлинский — Технический директор в ООО “Метод Лаб”. Веб-разработчик более 15 лет. Спикер конференций HighLoad++, РИТ++

https://my.rebrainme.com/course/networks/cohort/635/pay?utm_source=tg&utm_medium=post&utm_campaign=25082026 https://my.rebrainme.com/course/nginx-reverse-proxy-hardcore/?utm_source=tg&utm_medium=cpm&utm_campaign=nginx_troubleshooting&utm_date=06072026

On-call без паники: Как настроить умный мониторинг в Zabbix 3 часа ночи. Звонит телефон, в Telegram сыплются алерты: CPU load > 90%. Вы судорожно открываете ноутбук, заходите на сервер и видите, что нагрузка уже упала. Это был плановый бэкап или тяжелый батч-процесс, который запускается каждую ночь. Итог: вы не выспались, инженер рассержен, а проблема оказалась ложной. По статистике, высокая нагрузка во время дежурств (on-call) — одна из главных причин выгорания инженеров. До 30% алертов от систем мониторинга являются «шумом» и не требуют мгновенной реакции. Из-за обилия ложных срабатываний замыливается глаз, и реальный критический инцидент можно легко пропустить. Zabbix позволяет решить проблему «шума» с помощью гибких триггеров, зависимостей, временных окон и механизмов эскалации. Чтобы избежать ложных срабатываний на кратковременные пики, используйте функции усреднения. В современных версиях Zabbix (6.0+) синтаксис триггера выглядит так:

avg(/Template OS Linux/system.cpu.load[percpu,avg1],5m) > 5

Благодаря функции avg(5m), кратковременный скачок процессора (например, при запуске утилиты) не поднимет дежурного среди ночи. Алерт сработает только в том случае, если высокая нагрузка стабильно держится более 5 минут. Следующий шаг - настройка умной эскалации: 1. Сначала уведомление отправляется в некритичный чат Telegram. 2. Если инцидент не закрыт в течение 10 минут — отправляется SMS дежурному инженеру. 3. Если реакции нет 30 минут — включается автозвонок или оповещение тимлида. Для кастомных уведомлений (например, отправки алертов в Slack или корпоративный мессенджер) Zabbix поддерживает вебхуки и скрипты оповещений:

#!/bin/bash
# Скрипт оповещения (Zabbix Alert Script)
# $1 — получатель (канал/webhook URL), $2 — тема, $3 — текст сообщения
ALERT_MSG=$(echo "$3" | sed 's/"/\\"/g')

curl -X POST -H 'Content-type: application/json' \
--data "{\"text\":\"⚠️ *${2}*:\n${ALERT_MSG}\"}" \
"$1"

Zabbix также отлично автоматизирует рутину: с помощью LLD (Low-Level Discovery) он сам находит новые сетевые интерфейсы, диски или сервера в сети и сразу вешает на них нужные шаблоны мониторинга. Чек-лист для настройки эффективного мониторинга: ✅ Используйте шаблоны (Templates): не настраивайте метрики вручную для каждого хоста. ✅ Сглаживайте графики: применяйте функции avg(), max(), min() за промежуток времени вместо мгновенных значений. ✅ Ранжируйте приоритеты: делите алерты на *Information*, *Warning* и *Average/High/Disaster*. Ночью должны будить только последние два. ✅ Используйте макросы: выносите пороги срабатывания (например, `{$CPU.UTIL.CRIT} = 90`) в макросы шаблона, чтобы менять их в один клик. ✅ Регулярно проводите ревизию: удаляйте неактуальные триггеры, снижающие фокус команды. Чтобы научиться настраивать Zabbix на экспертном уровне, создавать кастомные шаблоны, работать с API и автоматизировать сбор метрик - 🔥открывайте бесплатный демодоступ🔥 к нашим курсам с практикой: 🔹Zabbix - установка, архитектура, LLD, триггеры, макросы и эскалации. 🔹Linux Advanced - траблшутинг системы, оптимизация производительности, логи. 🔹Networks - сетевые протоколы, tcpdump, SNMP и мониторинг сетевого оборудования.

Траблшутинг Nginx Reverse Proxy открыт! Задача доступна всем, приступай к решению и поборись за главный приз Формат участия: 🟢 доступ к рабочей инфраструктуре 🟢 симулятор реального инцидента без искусственных ограничений 🟢 доступ к задаче открыт с 9 по 15 июля 🟢 в конце — эфир с разбором решения Тебе предстоит подключиться к виртуальной машине Ubuntu 24.04 со сломанным Nginx и бэкенд-приложением на Go. Необходимо провести полную диагностику по логам, исправить конфигурацию Nginx и systemd-юнита, устранить проблемы с правами доступа и ресурсными лимитами, восстановить устойчивый автозапуск после перезагрузки и добиться ответа 200 OK при обращении к прокси-серверу. 🎁 Призы: 🏆 инженер, который решит задачу быстрее всех, получит доступ к одному из практикумов стоимостью до 30 000 руб. на выбор 🟢 среди остальных участников разыграем две годовые подписки на вебинары ↘️ Участвовать бесплатно

❗ Открытый практикум Docker-образ весит 1.5 GB. Как похудеть? идёт уже 30 минут Если вы ещё не с нами, скорее подключайтесь! Ссылка для входа: https://my.rebrainme.com/live-class/499 🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате

❗Начало Открытого практикума Docker-образ весит 1.5 GB. Как похудеть? уже через 5 минут Встречаемся в 19:00 МСК. Ссылка для входа: https://my.rebrainme.com/live-class/499 Также вы можете подключиться к вебинару через личный кабинет, в разделе «Вебинары». 🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате

Linux Performance & HighLoad Fundamentals: тюнинг ядра вместо докупки серверов Нагрузка выросла втрое, и через час падает база: OOM Killer выбрал не тот процесс, потому что oom_score_adj никто не выставил. Пакеты теряются на уровне ядра, диск отвечает с задержкой в разы выше нормы, а Docker-образ весит два гигабайта и собирается пять минут. Практикум Linux Performance & HighLoad Fundamentals учит закрывать эти проблемы тюнингом системы, без докупки серверов: инженеры разбирают планировщик CFS, память, диск и сеть на реальных стендах с имитацией пиковой нагрузки. В программе: 🟢Профилирование системных вызовов процессов с помощью strace и vmstat 🟢Изоляция ядер процессора и настройка CPU affinity через taskset 🟢Конфигурирование виртуальной памяти, swappiness и приоритетов выживания OOM Killer 🟢Тюнинг планировщиков ввода-вывода и параметров сброса грязных страниц 🟢Оптимизация параметров sysctl сетевого стека для предотвращения SYN drops 🟢Сборка оптимизированных multi-stage Docker-образов на Alpine Linux 🟢Настройка веб-сервера Nginx с поддержкой HTTP/3 QUIC и ECC-сертификатов ↘️ Подробная о программа В финальном проекте участники оптимизируют медленно работающее веб-приложение в тяжёлом Docker-образе: пересобирают его на Alpine Linux до размера менее 45 МБ, настраивают Nginx на HTTP/3 с ECC-сертификатами, тюнингуют ядро под сетевую и дисковую нагрузку и подтверждают результат ростом RPS на нагрузочном тесте. Практикум уровня Middle. Нужен базовый опыт администрирования Linux (Ubuntu/Debian), понимание TCP/IP и HTTP/TLS, навыки запуска контейнеров в Docker. Отдельно добавили тренажёры — более сложные практические задачи на инфраструктуре. 🎁 До 19 июля действует скидка 5 000 рублей для новых участников ↘️ Купить практикум ↘️ Купить практикум + тренажёры Если ты DevOps-инженер, SRE или системный администратор и хочешь обрабатывать больше трафика на тех же серверах — этот практикум для тебя 🤍

🗓️ Расписание вебинаров на сегодня ⏰ 19:00 МСК - Docker-образ весит 1.5 GB. Как похудеть? 🔗 Регистрация и программа О вебинаре напомним за 5 минут до начала на этом канале. Также вы сможете зайти через личный кабинет. 🔥 Задать вопросы и обсудить детали можно в нашем чате

❗ Открытый практикум Работа с дисками в Linux идёт уже 30 минут Если вы ещё не с нами, скорее подключайтесь! Ссылка для входа: https://my.rebrainme.com/live-class/486 🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате

❗Начало Открытого практикума Работа с дисками в Linux уже через 5 минут Встречаемся в 20:00 МСК. Ссылка для входа: https://my.rebrainme.com/live-class/486 Также вы можете подключиться к вебинару через личный кабинет, в разделе «Вебинары». 🔥 Задать вопрос по практикуму и обсудить детали можно в нашем чате