С 24 июня по 22 июля OTUS собрал серию открытых уроков и практических материалов по Linux, Docker, Kubernetes, CI/CD, сетям, PostgreSQL и защите инфраструктуры. Для тех, кто регулярно тушит пожары в проде, это не очередной список «полезных ссылок», а попытка закрыть инфраструктурные пробелы там, где сбои почти никогда не ограничиваются одним инструментом.
Подборка опубликована в блоге компании на Habr / Карьера и собрана вокруг простой, но болезненно знакомой для любой инженерной команды мысли: если деплой «просто сломался», дальше почти всегда всплывают лимиты Linux, настройки контейнеров, раннеры CI, сетевые маршруты, политики безопасности, базы данных и сам Kubernetes. Чем больше сервисов и команд в компании, тем дороже обходится фрагментарная экспертиза, когда каждый умеет чинить только свой кусок системы.
В практической части OTUS сделал ставку на открытые уроки с конкретными датами и прикладными темами. Уже 24 июня в 20:00 запланированы занятия по инцидент-менеджменту в SRE, сравнению RabbitMQ и Kafka, а также по отказоустойчивому кластеру RabbitMQ. На 25 июня вынесены день открытых дверей курса по продвинутому администрированию Linux, разбор IDS/IPS для защиты серверов, а также урок по кешированию в ASP.NET Core. Дальше расписание уходит в июль: 1 июля заявлены темы про классические методы перехвата управления в Linux и динамическую маршрутизацию с OSPF, 7 июля — балансировка трафика ЦОД, 15 июля — оптимизация GitLab Runners, 20 и 22 июля — проектирование адресного пространства и VLAN, а 21 июля — выбор между Serverless и Kubernetes для AI-нагрузок.
Сама логика этой подборки показательна. Инфраструктурные пробелы здесь описаны не как нехватка знания по одному стеку, а как разрыв между смежными зонами ответственности. Условный SRE не может бесконечно жить отдельно от сетевой инженерии, а DevOps-инженер — делать вид, что безопасность контейнера заканчивается флагом в docker-compose. Даже список тем это хорошо подсвечивает: рядом стоят GitLab CI и Linux-лимиты, Kubernetes и AppArmor, PostgreSQL и брокеры сообщений, OSPF и балансировка трафика в ЦОД. По сути OTUS продает не отдельные навыки, а привычку смотреть на инфраструктуру как на связанную систему, где один неверный параметр легко превращается в ночной инцидент для нескольких команд сразу.
Отдельный слой подборки — статьи для самостоятельного разбора. Здесь фокус уже не на расписании, а на типовых сбоях и инженерных антипаттернах. В список вошли материалы о ловушках Bash, из-за которых скрипты ломаются в самый неподходящий момент, о проблеме too many open files в Linux и Kubernetes, о пяти настройках в docker-compose.yml, которые часто забывают перед запуском на сервере, а также о переходе от Fail2Ban к CrowdSec для защиты Netbird и Caddy. Есть и сетевой блок: разбор форвардинга IP-пакетов на уровнях L2 и L3, где без лишней теории объясняются маршрутизация, коммутация, ARP и TTL. Для платформенных команд добавлен материал про self-service deployment, который убирает DevOps из роли ручного диспетчера релизов и переводит процесс в более внятную автоматизацию.
Не обошлось и без контейнерной безопасности. В подборку включен материал о том, как capabilities, seccomp и AppArmor работают не поодиночке, а как набор взаимодополняющих ограничений. Это важный акцент: в реальной эксплуатации безопасность контейнеров редко решается одной «правильной» настройкой. Такой же прикладной тон у текста про Kubernetes, где базовые сущности кластера — Control Plane, Worker Nodes, Pod, Service, Deployment и Namespace — разбираются не как словарь терминов, а как минимальный набор, без которого невозможно всерьез обсуждать продакшен-контур. Для команд, которые только выстраивают инфраструктурную зрелость, именно такие материалы обычно полезнее бесконечных разговоров о best practices без привязки к авариям и эксплуатационным компромиссам.
Третья часть подборки — уже не быстрые уроки, а системные образовательные треки. Среди них программа по DevOps-практикам и инструментам, курс по PostgreSQL для администраторов и разработчиков, обучение по проектированию сетей ЦОД и специализация для сетевых инженеров. Судя по описанию, OTUS здесь пытается закрыть сразу две аудитории. Первая — специалисты, у которых уже есть боевая зона ответственности и которым нужно за короткое время заткнуть конкретную дыру: например, разобраться, почему раннеры душат сборки или почему у контейнера нет нормальной защиты на уровне ядра. Вторая — инженеры, которые понимают, что инфраструктурные пробелы накопились системно, и без длинной программы с диагностикой уровня и практикой на близких к работе задачах они просто останутся теми же самыми пробелами, только аккуратно разложенными по закладкам в браузере.
Для рынка это еще и симптом зрелости спроса. Несколько лет назад большинство таких подборок строились вокруг одного модного инструмента: отдельно Kubernetes, отдельно Docker, отдельно CI/CD. Сейчас даже образовательный контент приходится собирать в связки, потому что у компаний нет роскоши держать команды, которые понимают только один слой стека. Бизнесу нужна предсказуемость сервисов, а не идеальный специалист по одной кнопке в GitLab. Разработчикам и платформенным командам, в свою очередь, все чаще приходится разбираться в том, что раньше считалось «чужой территорией»: сетях, лимитах ОС, кластерах очередей, правилах изоляции трафика, механизмах защиты контейнеров и поведении БД под нагрузкой.
На этом фоне сама идея закрывать инфраструктурные пробелы через набор коротких уроков, статей и длинных программ выглядит не маркетинговым украшением, а довольно точным ответом на состояние отрасли. Вопрос теперь не в том, нужен ли инженеру широкий инфраструктурный кругозор, а в том, насколько быстро команды смогут превратить разрозненные знания по Linux, Kubernetes, CI/CD и сетям в общую рабочую систему, где следующий инцидент не придется снова разбирать с нуля.