DevOps by REBRAIN
29K subscribers
497 photos
13 videos
4 files
1.05K links
Открытые практикумы по DevOps, Linux, Golang, Networks, Security

Мы на связи:
info@rebrainme.com
+7 (499) 116-34-68

https://rebrainme.com/

Зарегистрированы в РКН: https://knd.gov.ru/license?id=674db558d793bc0b0b8845ff&registryType=bloggersPermission
Download Telegram
Media is too big
VIEW IN TELEGRAM
Показываем фрагмент первого эфира интенсива «ИИ-агенты для инженеров» с Артуром Сапрыкиным 👀

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

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

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

↘️ Присоединиться к интенсиву
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7👍1
Настройка 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
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥65👍1
Эта политика применяется к подам с лейблом app: backend и разрешает входящий трафик на порт 8080 только от подов с лейблом app: frontend в рамках того же неймспейса.

Если вам нужно разрешить доступ из подов, находящихся в другом неймспейсе (например, сбор метрик Прометеусом), мы комбинируем селекторы:

ingress:
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: monitoring
podSelector:
matchLabels:
app: prometheus



Обратите внимание на синтаксис: когда podSelector и namespaceSelector находятся внутри одного элемента списка (как выше), они работают по логике И (под с лейблом prometheus *внутри* неймспейса monitoring). Если бы они начинались с разных дефисов (`-`) - это была бы логика ИЛИ.

Практический план внедрения в продакшен
1. Проверить CNI: убедитесь, что ваш сетевой плагин (Calico, Cilium, Antrea) физически умеет обрабатывать NetworkPolicy.
2. Начните с тестового контура: не раскатывайте default-deny-all сразу на весь продакшен кластер. Выберите один некритичный неймспейс.
3. Включите логирование (если позволяет CNI): Cilium и Calico умеют логировать отброшенные пакеты (dropped packets). Это поможет увидеть, какой легитимный трафик вы случайно заблокировали.
4. Внедрите deny-all и DNS: изолируйте неймспейс и сразу дайте доступ к порту 53 CoreDNS.
5. Опишите явные взаимосвязи: переведите архитектуру приложения в YAML-манифесты политик.
6. Протестируйте доступность: используйте kubectl exec для финальной проверки:

kubectl exec -it <pod-frontend> -n production -- curl http://backend:8080



Важные правила на заметку:
🔹 Если к поду применяется несколько NetworkPolicy, разрешённым считается объединение (*Union*) всех правил. Вы не можете одной политикой «перекрыть» или запретить то, что уже разрешено другой.
🔹 Если вы включили default-deny-all для всего неймспейса, то для успешного соединения под-источник должен иметь разрешение на egress (исходящий трафик), а под-получатель - на ingress (входящий трафик).
🔹 Обратите внимание, это справедливо в рамках одного namespace. Если у вас открыт доступ в соседний неймспейс, а там нет сетевых политик, то доступ будет разрешён.
🔹 Для удобства запоминания: внутри kubernetes доступ чаще всего открывается парно egress/ingress, а вот наружу открывается только egress правило.


Чтобы освоить сетевую безопасность в Kubernetes на практике, включая тонкости работы с CNI, Network Policies, Service Mesh и концепцией Zero-Trust, 🔥открывай демодоступы бесплатно🔥 и прокачивай навыки:
* Kubernetes Admin - администрирование кластера, сеть, безопасность, политики.
* Networks Basics - основы сетей, CNI, маршрутизация трафика внутри K8s.
* Container Security - безопасность контейнеризации, изоляция сред, политики доступа.
👍11🔥62
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% на все программы, начать можно с бесплатного демодоступа 🤍

↘️ Выбрать практикум
Please open Telegram to view this post
VIEW IN TELEGRAM
9🔥2
Если бы герои сериала «Пацаны» работали в 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% при полной оплате. Почти на всех практикумах есть демодоступ - можно начать бесплатно.

↘️ Выбрать практикум
Please open Telegram to view this post
VIEW IN TELEGRAM
👎18🔥182😁2👍1
🟡 Анонс открытых практикумов на следующую неделю

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 лет
Please open Telegram to view this post
VIEW IN TELEGRAM
👍42
Динамическое конфигурирование: как перезагрузить 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 секунд, чтобы «долить» долгие запросы.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍122
Чек-лист для бесшовного релоада в продакшене
Всегда валидируйте конфиг через nginx -t перед отправкой сигнала.
Не рестартуйте контейнеры, если изменился только nginx.conf — используйте docker kill -s HUP.
Настройте мониторинг процессов: после релоада количество старых воркеров (в статусе *is shutting down*) должно постепенно снижаться до нуля. Проверить состояние процессов можно командой ps ax | grep nginx.
Закладывайте время жизни соединений в worker_shutdown_timeout в зависимости от специфики вашего трафика.

Чтобы глубже разобраться в архитектуре веб-серверов, настроить отказоустойчивую балансировку, кэширование и работу с SSL/TLS без даунтайма, 🔥попробуйте бесплатно на демодоступе🔥

🔹Nginx - производительность, архитектура процессов, релоады и тюнинг под высокие нагрузки.
🔹Docker - сигналы процессов, управление контейнерами, PID 1 и лучшие практики.
🔹Bash - автоматизация рутины, написание безопасных скриптов деплоя и обработка ошибок.
👍15
Топ программ 2025/2026 со скидкой до -30%

Недавно смотрели, какие практикумы были популярны в 2025 году, и заметили: часть этого топа так же уверенно держится и в 2026-м. Собрали 7 практикумов, которые инженеры выбирают второй год подряд.

Самые популярные практикумы 2025/2026

🟢 №1 Kubernetes Base
Развернёте кластер с нуля, настроите деплойменты, сервисы и сетевое взаимодействие подов на рабочей инфраструктуре.

🟢 №2 Прикладной LLM для инженеров
Изучите LLM, от архитектуры Transformer до инференса (vLLM). Освойте RAG (LlamaIndex) и Fine-Tuning. Создайте Агентов с Function Calling (LangChain, n8n).

🟢№3 Networks
Разберёте, как трафик реально ходит между серверами: маршрутизацию, VLAN и firewall на практике.

🟢 №4 Ansible
Настроите автоматизацию серверов через плейбуки и роли — от установки пакетов до раскатки конфигов на десятки машин.

🟢№5 PostgreSQL
Настроите репликацию и бэкапы, разберётесь с поведением базы под нагрузкой и типовыми задачами администрирования.

🟢№6 Grafana
Соберёте дашборды с метриками инфраструктуры и настроите алерты на конкретные пороговые значения.

🟢№7 Prometheus
Настроите сбор метрик с серверов и сервисов и создадите алерты, которые сработают раньше, чем упадёт прод.

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

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

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

Распродажа закрывается уже завтра. Сейчас отличный момент, чтобы освоить новые технологии 🤍
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🔥3
🔧 Дайджест правок июля

Привет, на связи команда Rebrain! 👋
За месяц закрыли 232 задачи: исправляли материалы и автопроверки, разбирали обратную связь студентов и менторов.
Больше всего работы пришлось на Ceph, DevOps, Linux, Kubernetes и RabbitMQ.

1️⃣ Ceph
Разобрали серию расхождений между условиями заданий, окружениями и автопроверками. Уточнили требования к именам файлов, IQN и ACL для iSCSI, CRUSH-правилам, настройкам Prometheus и Grafana. Исправили команду получения публичного ключа Ceph.
Отдельно поправили проверки, которые ожидали конкретные названия или содержимое файлов, хотя в заданиях это не было указано. Разобрались с проблемами из-за разных версий Ceph на узлах и уже развёрнутых кластеров. Учли обратную связь о необходимости обновить версию курса.

2️⃣ DevOps
Поправили автопроверки, привязанные к устаревшей инфраструктуре или одному конкретному варианту решения. Также разобрали проблемы с GitLab-токеном и повторяющимися проверками. Уточнили формулировки про git rebase, Terraform-модули и финальное задание по Terragrunt, где было неясно, сколько окружений и проектов нужно создать.

3️⃣ Kafka Admin
По итогам бета-теста доработали урок по настройке Kafka в режиме KRaft. Синхронизировали теорию и практику: уточнили параметры, которые должны различаться на нодах, добавили пропущенные проверки кластера и исправили несовпадение имени каталога после распаковки Kafka.

4️⃣ Gateway API
Уточнили проверку сервиса через внешний IP, исправили названия ресурсов и расхождение между gateway-system и фактическим envoy-gateway-system.

5️⃣ Kubernetes для Yandex Cloud
Починили команду добавления ключа Helm, ссылку на Metrics Server, порядок модулей и пример с helm template.

6️⃣ Kubernetes Admin
Обновили ссылки и разобрали замечания по ресурсам кластера, ingress и порядку обновления control plane и worker-узлов.

7️⃣ Linux Basics
Поправили опечатки, противоречия в командах и некорректные параметры find. Уточнили инструкции по SSH, установке операционной системы и созданию пользователей. Смягчили проверки, которые принимали только один способ выполнения задания, хотя корректных вариантов было несколько.

8️⃣ Linux: анализ производительности и тюнинг
Исправили ошибки в скриптах и обновили устаревшие названия показателей. Уточнили материалы про tcp_tw_reuse, ionice, cgroups, systemd и файлы в /etc/sysctl.d/. Поправили задания, где автопроверка ожидала конкретный файл или службу без явного требования в условии.

9️⃣ RabbitMQ
Исправили содержательную ошибку в примере маршрутизации: сообщения с ключами вида logs.auth.error не соответствовали указанному binding *.error.#. Уточнили роли брокера и потребителя при подтверждении доставки и поправили проверку, которая искала exchange с другим именем.

🔟 Bind
Cмягчили проверки, зависевшие от пробелов, переносов строк, комментариев и конкретных названий объектов. Расширили пояснения по TSIG, конфигурационным файлам и split-horizon DNS. Также починили отображение Mermaid-схемы.

1️⃣1️⃣ Grafana
Поправили проверки, чувствительные к пробелам и точному виду JSON, обновили параметры API и уточнили задания по Data Links, Loki и переменным дашбордов. Исправили расхождения в названиях панелей и папок.


1️⃣2️⃣ HAProxy
Доработали проверку sticky-сессий с nocache, права доступа экспортера к сокету и пример модификации HTTP-запросов, где в условии и выводе использовались разные пути.

1️⃣3️⃣ Terraform
Разобрали проблемы с квотами Yandex Cloud, расположением outputs и неочевидной необходимостью выполнить terraform plan после принудительного пересоздания ресурса.

Спасибо за вашу обратную связь💗мы ее читаем и внедряем изменения🤝
🔥82👍2👏2
🔥 Июльские модули уже на платформе!

Материалы залиты на платформу, инфра настроена, менторы готовы отвечать на вопросы.
Не откладывайте обучение - заходите в личный кабинет и начинайте проходить курсы:

🤖 Интенсив AI Agents 👉 О практикуме
Первые вебинары уже прошли, но еще можно присоединиться, если кто-то был в отпуске или никак не решался.

🔐 Keycloak + тренажеры 👉 О практикуме
Разворачиваем SSO, настраиваем управление идентификацией и разграничение доступа в enterprise-инфраструктуре на реальных серверах.

Linux Performance & HighLoad Fundamentals + тренажеры 👉 О практикуме
Учимся находить узкие места системы, оптимизировать ядро, дисковую подсистему и готовить инфраструктуру к высоким нагрузкам.

💻 Bash + тренажеры 👉 О практикуме
Автоматизация повседневных задач инженера: от чистых скриптов до сложной обработки логов и работы с API напрямую из консоли. Всем, у кого ранее был куплен bash, вам по почте напишет поддержка с инструкцией как 🔥бесплатно🔥 обновить практикум до новой версии.

🛠️ Управление инфраструктурой и рабочими станциями 👉 О практикуме
Централизованное управление, автоматическое конфигурирование и масштабирование парка серверов и рабочих мест.

💡 Всё ещё сомневаетесь и не знаете, подойдет ли вам формат?
Мы понимаем, что перед стартом хочется «потрогать» всё руками. Уже в августе на платформе появятся бесплатные демодоступы к этим модулям. Вы сможете лично протестировать боевую инфраструктуру, оценить формат «меньше теории - больше консоли» и решить первые задачи абсолютно бесплатно.

Следите за анонсами, а тем, кто уже с нами - продуктивной практики и до встречи на платформе! 🚀
👍2
🔐 Интенсив с Константином Зубченко по безопасности операционных систем стартует 10 августа

Кстати, тему вы выбрали сами: она набрала больше всего голосов в опросе. Раз проголосовали за безопасность ОС, то разбираем её так, как обычно разбираем инфраструктуру: без теории ради теории и на реальных стендах.

За 8 живых занятий с Константином вы пройдёте харденинг Linux и Windows по CIS Benchmarks, разберёте права и привилегии, безопасный запуск процессов и контейнеров, шифрование и работу с секретами, изоляцию ядра и защиту от Container Escape, сетевую безопасность и Network Policies в Kubernetes, аудит через Falco и Sysmon.

На каждом занятии отдельный блок про LLM: как автоматизировать генерацию политик AppArmor и Seccomp, писать regex для поиска секретов в коде и первично разбирать логи на признаки компрометации.

Вас ждёт:

🟢 8 живых занятий с Константином Зубченко
🟢 7 практических заданий с проверкой
🟢 Практика на виртуальных стендах
🟢 Автоматизация безопасность с помощью LLM
🟢 Чат с Константином и участниками интенсива
🟢 Записи интенсива доступны только участникам


Программа интенсива:

10.08.2026 — Модели безопасности ОС и поверхность атаки
DAC/MAC в Linux и Securable Objects в Windows, эксплуатация дефолтных сервисов, харденинг по CIS Benchmarks.

13.08.2026 — Пользователи, группы, права и привилегии
SUID/SGID, Token Impersonation и Rotten Potato в Windows, аудит sudoers.

19.08.2026 — Процессы, службы и безопасный запуск приложений
Харденинг systemd-юнитов, атаки на автозапуск и Unquoted Service Path, non-root контейнеры.

26.08.2026 — Файловая система, секреты и безопасная работа с данными
LUKS, BitLocker, извлечение секретов из LSASS и слоёв Docker-образов, секреты через Vault.

31.08.2026 — Ядро, изоляция, контейнеры и механизмы ограничений
Namespaces, Cgroups, AppArmor и Seccomp, побег из контейнера, Pod Security Standards.

03.09.2026 — Сетевая безопасность ОС и контейнерных сред
iptables/nftables, Network Policies в Kubernetes, защита Metadata API и Kubelet API.

07.09.2026 — Аудит, мониторинг и безопасный жизненный цикл ОС
Auditd, Sysdig, Falco в Linux, Sysmon и WEF в Windows, детекция скрытной активности.

10.09.2026 — Q&A: архитектурный разбор и разбор кейсов
Сложные сценарии защиты гибридных сред Linux + Windows + Kubernetes.


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

🟢Какие есть форматы участия?

Только интенсив: 8 живых занятий с Константином Зубченко + практические задания с проверкой

Только практикум "Повышение привилегий в Linux": 10 заданий, 80% практики + автопроверки и проверка инженерами финального задания

Практикум + Интенсив
Практикум "Повышение привилегий в Linux"+ 8 живых занятий с Константином Зубченко

Кто ведёт интенсив

Константин Зубченко — ведущий инженер в компании BI.ZONE. За годы работы в отрасли прошёл путь от анализа защищённости промышленных систем до инженерных и экспертных ролей в крупных российских компаниях. Участвовал в сложных проектах на стыке разработки и информационной безопасности, усиливая команды и процессы. Его опыт — это сочетание практического пентеста, инженерного мышления и глубокого понимания современных ИБ-подходов.

🟡 Старт — 10 августа
🎁 Сейчас действует скидка до 10 000 рублей, в зависимости от формата участия.

↘️ Узнать подробности и занять место
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6