Firefox 157 представил новый интерфейс Nova, который включен по умолчанию. Обновление интерфейса считается крупнейшим за многие годы для браузера. Новый дизайн включает изменения в вкладках, панелях и настройках для упрощения восприятия. Некоторым пользователям новый интерфейс не понравился, и они хотят вернуться к классическому виду.
Для отключения интерфейса Nova необходимо:
зайти в настройки about:config.
найти параметр browser.nova.enabled и изменить его назначение с true на false.
после изменения браузер вернется к классическому интерфейсу.
также можно отключить новую боковую панель, которая отображает доступные разделы. Для этого нужно изменить значение sidebar.revamp с true на false.
Импортозамещение по частям: бэкап один, а Linux у всех разный
Увидел новость о том, что «Киберпротект» выпустил «Кибер Бэкап Старт» – бэкап Windows и Windows Server для физлиц и малого бизнеса.
Бэкап уже российский, а операционная система всё ещё Microsoft
Ничего необычного. В небольшой компании инфраструктура вполне может состоять из нескольких рабочих станций на Windows и одного Windows-сервера. Службы каталога нет. Задача простая: сломался компьютер – вернуть данные и систему.
А что происходит, когда инфраструктура становится больше и в ней появляется Linux?
Windows перестаёт быть единственной платформой
Российский Linux сегодня – скорее лоскутное одеяло, чем одна платформа.
В рейтинге российских ОС CNews 2026 перечислены Astra Linux, Альт, РЕД ОС, РОСА Хром, ОСнова, UBLinux, АльтерОС, Platform V SberLinux OS Server, ОС «Атлант» и EcoRouterOS.
Поэтому совместимость СРК приходится проверять точнее, чем «Linux – да/нет». «Кибер Бэкап» 18.6, к примеру, поддерживает не все российские ОС. Заявлены Astra Linux, Альт, РЕД ОС, РОСА «КОБАЛЬТ» и «ХРОМ», AlterOS и ОСнова, а также ряд зарубежных дистрибутивов. При этом UBLinux, SberLinux, ОС «Атлант» и EcoRouterOS в этой матрице не указаны.
Это не значит «не работает». Наличие слова Linux в описании продукта ничего не гарантирует для конкретного контура. Матрицу совместимости проверяют руками под свою ОС, версию и сценарий.
А что со службой каталога?
Для небольшого офиса централизованный каталог скорее не нужен. В крупной организации это базовый элемент инфраструктуры: через него проходят пользователи, группы, права и доступы.
Проблема не обязательно в падении сервера. Каталог может оставаться доступным, пользователи продолжают входить в систему, но у нескольких сотен человек изменились атрибуты, членство в группах или права из-за неправильно отработавшего скрипта.
Классическая СРК восстанавливает машину, сервер, виртуальную среду или каталог после аварии. Но если из 10 000 пользователей неправильные данные получили 500, полный откат каталога – слишком грубо.
Поддержка каталога ≠ умение вернуть одного пользователя, группу или атрибут. Здесь нужны уже специализированные средства гранулярного восстановления, которые работают по другой логике: сравнить каталог с бэкапом и вернуть только нужные объекты и атрибуты.
С ростом инфраструктуры меняется задача защиты
Для одного компьютера достаточно вернуть Windows и файлы. Для корпоративного Linux нужно проверить совместимость СРК с конкретным дистрибутивом, и техническими ограничениями. А для службы каталога – заранее понимать, что именно восстановится, если каталог жив, а данные уже сломаны.
Классическая СРК и гранулярное восстановление – не конкуренты, а два уровня защиты одной инфраструктуры. Они решают задачи разного масштаба и могут быть двумя уровнями защиты одной инфраструктуры.
Представим обновление нашего флагманского продукта — системы резервного копирования Кибер Бэкап 19.
В этой версии мы расширили возможности защиты PostgreSQL и СУБД на ее основе, обеспечили интеграции с новыми отечественными системами виртуализации и корпоративных коммуникаций. Также повышена масштабируемость и расширены возможности защиты уже поддерживавшихся отечественных почтовых сервисов. Реализованы интеграции с распространенной системой централизованного ИТ-мониторинга и решениями, обеспечивающими неизменяемость резервных копий. Разработана новая система уведомлений, включающая возможность их отправки в популярный отечественный мессенджер. Кроме того, мы переработали систему лицензирования и внедрили ряд других изменений.
25.10.2026в 13:00 МСК проведем онлайн вебинар, на котором обсудим следующие темы:
Расширенная интеграция с PostgreSQL и СУБД на ее основе: развитие многопоточности и новые механизмы защиты
Интеграция с VMmanager и снижение нагрузки на сеть при защите ВМ под управлением VMware
Интеграция с RuPost
Развитие возможностей защиты Mailion и Exchange
Повышенная масштабируемость защиты Почты VK WorkSpace
Интеграция с Zabbix, MAX и новая система уведомлений
Интеграция с решением для неизменяемого хранения резервных копий
Для большинства сценариев прокрутки JavaScript вообще не нужен. CSS умеет сделать скролл внутри отдельного блока, горизонтальную ленту карточек, плавный переход по якорям, Scroll Snap и даже остановить ситуацию, когда после конца прокрутки модального окна внезапно начинает ехать вся страница.
Но обычно проблемы начинаются с нескольких базовых свойств. Вот что полезно знать:
Overflow — основа скроллинга. Если у контейнера ограничена высота, overflow: auto добавит прокрутку только тогда, когда контент перестанет помещаться. Через overflow-x и overflow-y можно отдельно управлять каждой осью.
Горизонтальный скролл удобен для карточек. Вместо уменьшения элементов или переноса на новую строку можно оставить фиксированную ширину карточек и разрешить контейнеру прокручиваться по оси X. Особенно полезно на мобильных интерфейсах.
Плавные переходы по якорям делаются одной строкой: scroll-behavior: smooth. Но есть нюанс с доступностью: если пользователь включил prefers-reduced-motion, плавную анимацию лучше отключить.
Scroll Snap может заменить простой JS-слайдер. scroll-snap-type и scroll-snap-align позволяют фиксировать карточку или секцию после прокрутки, а scroll-snap-stop: always — не перескакивать через элементы при быстром свайпе.
Фиксированный header не должен перекрывать якорь. Вместо дополнительных скриптов можно задать scroll-padding-top для страницы или scroll-margin-top для отдельных секций.
Вложенный скролл тоже можно контролировать. Если внутри страницы есть модальное окно или боковая панель, overscroll-behavior: contain не даст прокрутке после конца блока автоматически перейти на родительскую страницу.
Есть и менее очевидные детали. Например, scrollbar-gutter: stable помогает избавиться от горизонтального «прыжка» страницы при появлении полосы прокрутки, а кастомный scrollbar лучше не делать слишком узким или малоконтрастным — это уже влияет на доступность интерфейса.
JavaScript понадобится уже там, где скроллинг запускает дополнительную логику: Infinite Scroll с подгрузкой данных, синхронизацию нескольких областей, аналитику или сложные интерактивные сценарии. А вертикальный и горизонтальный скролл, Scroll Snap, плавные якоря и управление вложенной прокруткой вполне можно оставить браузеру.
Если хотите посмотреть готовые HTML/CSS-примеры и разобрать типичные ошибки, читайте полное руководство в блоге Рег.облака.
У нас у всех есть куча проектов. Мы работаем над фичами. Каждая фича — отдельная локальная ветка. Мы её делаем, пушим, открываем PR, PR мержат, ветку на сервере удаляют.
А локальная ветка остаётся. И так каждый раз. Через полгода у тебя в git branch тридцать восемь веток:
feature/login
feature/login-fix
fix/typo
topic/auth
topic/auth-v2
...
main
И ты такой сидишь и думаешь: «Какая из них ещё живая? Какие уже смержены? Можно ли что‑то удалить или я что‑то потеряю?».
И вот ты уже пишешь скрипт на коленке, который тебе должен всё почистить. Запускаешь его и вуаля, ты слегка ошибся и больше в твоей репе нет бранчей, паника и судорожный поиск решения на ohshitgit.com.
В общем, короче. Harald Nordgren походу сам задолбался с этим и ребята только что релизнули Git 2.56, в котором запилили опцию delete‑merged.
Самое классное, что команда супер простая и простая как полено (хоспадепрости patch‑format с 100 500 аргументами).
$ git branch --delete-merged 'origin/*' --dry-run
Would delete branch feature/login (was abc1234).
Would delete branch feature/login-fix (was def5678).
Would delete branch fix/typo (was 9876fed).
Посмотрел. Всё выглядит нормально. Запускаешь без --dry-run:
Всё. Ветки, которые уже влиты в свой origin, снесены. Ветки, где есть неотправленная работа, — остались. Ветки с deleteMerged = false — остались. Ветки, которые ты вычеканил в другом worktree, — остались.
Это безопасно. Свои скрипты можно выкинуть. Также можно точечно чистить категориями topic-*, feature/*, origin/*.
В общем, если git branch уже не помещается в терминал — обновляемся на 2.56 и теперь вы знаете что делать.
Открытый проект Unofficial search plugins позволяет искать торренты прямо в qBittorrent. Это каталог поисковых плагинов, которые подключают торрент-сайты к самому клиенту. Можно выбрать нужные источники и искать по нескольким местам сразу с помощью одного запроса. В списке проекта есть Rutor, Nyaa, The Pirate Bay и даже Academic Torrents с научными данными.
Представлен открытый проект Terminal Velocity (tvty) — двадцать агентов ИИ, работающих в циклах (loop). В центре внимания — задачи (тикеты). Одно окно. Никаких поисков нужной вкладки.
«tvty — для тех, кто хочет вести разработку с Claude на максимальной скорости. Это нативный терминал для одновременного запуска множества агентов Claude Code: терминалы сгруппированы по проектам, а тикеты каждого проекта находятся прямо рядом с ними — агент задаёт вопрос, вы принимаете решение, работа продолжается. Почему это удобно Одно окно вместо двадцати вкладок. Видны все проекты, все агенты и то, что требует вашего внимания: принятие решения, непрочитанный ответ или тикет, блокирующий остальные задачи. Терминал каждого агента работает в реальном времени. Прямая привязка к сессии, высокая скорость, никаких лишних прослоек вроде tmux. Переключение одним нажатием клавиши или выбор из миниатюр, отображающих текущее состояние всех окон. Тикеты — рядом с терминалом. Планы, решения, эскалации, изображения: принимайте, отклоняйте или отвечайте, не отрываясь от клавиатуры», — пояснил автор решения.
Все мы любим htop - цветастый, кликабельный, удобный топчик. Но не смотря на то, что в большинстве случаев хватает варианта из коробки, в нем большие возможности для кастомизации.
Я не хочу долго расписывать как и что настраивать, а просто дам вам однострочник который сделает всю магию. Он по сути он просто бекапит текущий конфиг (если он вообще был) и забирает из https://gist.github.com/itcaat/45ea5994d66378fc4bd647cab860a05f новый.
Подоспела новость: MONT и Avanpost договорились о партнёрстве.
На первый взгляд - обычная дистрибьюторская новость. Но для компаний, которые работают с MONT и рассматривают миграцию с Microsoft AD на Linux-каталог, появляется интересный вариант службы каталога — Avanpost DS. Сейчас многие возразят: на рынке же полно российских решений-аналогов MS Active Directory — ALD Pro, РЕД АДМ, Роса Dynamic Directory, Альт Домен и другие. Зачем нам ещё один? Копнём поглубже, чтобы понять, а действительно нужен ли нам этот "ещё один".
Российские Linux-каталоги собраны по-разному: одни вокруг FreeIPA, другие на Samba DC. Вместе с каталогом заказчик выбирает его архитектуру, зависимости и инструменты администрирования. Поэтому два продукта с одной задачей в эксплуатации ведут себя по-разному.
Avanpost пошёл другим путём
Ядро Avanpost DS — LDAP-сервер и Kerberos — написано на Go с нуля, без использования open-source-компонентов. По заявлению вендора, их служба каталога протестирована под нагрузкой до 30 млн объектов.
Что это даёт?
Типичный Linux-каталог собран из нескольких компонентов. Каждый зрелый и проверенный, но со своей архитектурой и зависимостями. Вендору приходится развивать свой продукт и одновременно считаться с чужим кодом.
Своя собственная разработка даёт больше контроля над ключевыми компонентами. Их можно менять, искать узкие места и оптимизировать под нагрузку, а не подстраиваться под архитектурные решения, которые принимали без тебя. Avanpost среди плюсов своего подхода называет производительность и масштабируемость.
Но производительность важна не только в штатном режиме
Проблема начинается, когда нужно быстро исправить ошибку в каталоге. Неудачный скрипт, сбой интеграции или массовое изменение могут затронуть множество объектов. Контроллеры при этом доступны, пользователи аутентифицируются, мониторинг зелёный – но у части сотрудников уже изменены атрибуты, членство в группах или права доступа. Формально всё работает, а данные внутри — уже нет.
Мало обслуживать миллионы объектов в штатном режиме. Нужно ещё быстро понять, что именно сломалось, и исправить это, не откатывая миллионы корректных данных вместе с ошибочными.
При больших объёмах узким местом может стать уже сам каталог. В компании, где я работаю (другой ИТ-вендор), был похожий опыт при нагрузочном тестировании одного из Linux-каталогов, построенных на open-source-компонентах: массовые операции на сотнях тысяч объектов выполнялись критически медленно, а удаление нескольких тысяч учётных записей заняло несколько дней. Во время нагрузки возникали ошибки, а репликация между контроллерами некоторое время не восстанавливалась.
Поэтому производительность каталога при больших объёмах – это не вопрос комфорта администратора. От неё напрямую зависит, сколько времени займёт исправление массовой ошибки.
И здесь у Avanpost есть ещё одна полезная связка
С августа Avanpost DS Pro совместим с Granulex Recovery. Granulex сравнивает текущее состояние каталога с резервной копией, показывает, что изменилось не туда, и позволяет выборочно вернуть нужные объекты и атрибуты — без полного отката каталога.
Так что при выборе замены Microsoft AD важен не только список функций. Сколько объектов реально выдерживает каталог? Как ведёт себя под нагрузкой? И насколько быстро можно найти и исправить ошибку, если она затронула тысячу объектов из миллиона?
Когда от каталога зависят доступы всей компании, это уже не мелочи.
Когда в Kubernetes что-то сломалось: как ИИ-агент помогает искать проблемы в кластере
Иногда проблема в Kubernetes находится за несколько минут. Иногда — после долгого просмотра логов, проверки ресурсов и попыток понять, что именно изменилось перед сбоем.
Чем сложнее становится инфраструктура, тем больше времени уходит на задачи вроде анализа состояния кластера, поиска отклонений и проверки типовых проблем. В этот момент возникает вопрос: можно ли часть такой работы передать ИИ?
На практике ИИ-агент для инфраструктуры — это уже не просто чат с подсказками. Он может получать данные о состоянии Kubernetes, работать с ресурсами кластера и помогать инженеру быстрее разобраться в ситуации.
На открытом уроке 1 октября в 20:00 разберём связку Kagent + Ollama: как подключить локальную LLM к агенту, какие возможности это даёт для работы с Kubernetes и какие DevOps-сценарии можно автоматизировать уже сейчас. Присоединяйтесь.
Больше разборов и практических материалов по инфраструктуре собрали в тематическом дайджесте — там можно найти другие полезные темы для DevOps и системных инженеров.
Как управлять разработкой, если процессы и данные распределены по разным системам?
Руководителям становится сложнее видеть общую картину: оценивать стоимость инициатив, контролировать соблюдение единых требований и понимать, где процессы теряют эффективность. Разработчики при этом зависят от DevOps-инженеров в типовых задачах и ждут предоставления окружений и ресурсов.
2 октября в 12:00 на вебинаре представим новый этап развития Deckhouse Development Portal.
Покажем, как Development Portal встраивается в разнородный ИТ-ландшафт и объединяет управление разработкой. Руководители получают больше прозрачности и инструментов контроля, а команды — портал самообслуживания для работы с инфраструктурными сервисами, инструментами и данными.
Разберём:
расчёт стоимости инфраструктуры разработки отдельных бизнес-инициатив;
стандартизацию процессов и требований безопасности;
упаковку согласованного стека в готовые шаблоны;
заказ окружений и баз данных по кнопке без ручной обработки заявок;
адаптацию портала к процессам компании и интеграцию с используемыми системами.
Бонус: для участников вебинара проведём чекап процесса SDLC вашей команды.
Почему мониторинг, SRE и автотесты перестали работать по отдельности?
Digital Immune System (DIS) или Цифровой Иммунитет — это способность инфраструктуры почувствовать, что с ней что-то не так, и починить себя раньше, чем это заметит пользователь.
В новом выпуске «В SREду на кухне» Андрей Волхонский, Андрей Колесников и Василий Осипенко разбирается что такое DIS, из чего он состоит и почему это не просто модное словосочетание, а способ пересобрать подход к надёжности.
Гость выпуска: Михаил Савин, руководитель отдела SRE в H3LLO CLOUD
На вебинаре раccкажем, как застраховаться от потери данных даже в случае физического отказа ЦОД и как выстроить защиту инфраструктуры с помощью Evolution Disaster Recovery и Evolution Agent Backup. Вспомним, чем отличаются DRaaS, BaaS, репликация и аварийное восстановление. Вы получите полное представление о том, как подобрать решение с учетом требований к непрерывности, скорости восстановления данных и безопасности.
🧑💻 Для кого: CISO и руководителей отделов информационной безопасности, ИТ-директоров, архитекторов, DevOps-инженеров и специалистов, отвечающих за непрерывность работы ИТ-сервисов.
Выделенный сервер на Xeon E3: разбираем варианты переезда
Часто при выборе выделенного сервера, многие сразу смотрят на топовые мощные конфигурации. Но на практике веб-проекту редко нужен последний Xeon, а чаще важнее предсказуемость и правильный баланс ресурсов.
В SpaceWeb мы держим линейку на Xeon E3-1270 v3 — процессоре не новом, но зато проверенном годами. Варьируя лишь объем RAM и тип накопителей, можно решить почти любую задачу: от легкого сайта до файлового хранилища на терабайты.
Какую выбрать конфигурацию:
Сайт или несколько веб-проектов. 16 ГБ RAM и пара SSD — база для Битрикса, WordPress или интернет-магазина. Если проектов больше, тогда берем 32 ГБ.
Интернет-магазин или портал с контентом. Тот же процессор, но диски побольше: под базы, картинки и логи.
Бэкапы, архивы, почта. Здесь скорость SSD не нужна, поэтому ставим HDD на терабайты. Дешевле, а задачу решает.
Сайт и файлы на одном сервере. Гибрид: SSD под приложение, HDD под документы. Удобно для корпоративных порталов и Bitrix24.
Посмотреть полные характеристики и заказать нужную конфигурацию можно на сайте SpaceWeb. А если не нашли подходящий вариант — просто напишите нам на почту dedic@sweb.ru, мы поможем подобрать решение вручную.
Индустрия сейчас совершает ту же ошибку, что и во времена взрывного перехода на микросервисы. Тогда все бросились дробить монолиты, не умея в автоматизацию. Сегодня все бросились внедрять AI, забыв про банальную инженерную гигиену.
Внедрить AI сегодня стало слишком просто. Достаточно взять любимый язык программирования, импортировать пару библиотек, дернуть API OpenAI или развернуть локальную модельку из Hugging Face — и вуаля, у вас готов «инновационный» фичер. Но именно эта доступность порождает самый опасный вид «people‑долга» — культуру одноразового кода и брошенных интеграций.
Когда первая эйфория от работающего прототипа проходит, в недрах компании обнаруживается не только промпты, зашитые хардкодом прямо в середину бизнес‑логики, но и зомби‑интеграции. Брошенные инструменты, которые изначально планировались просто как эксперимент жрут деньги на инфраструктуру и поддержку. Эксперимент на пазуе, но «инновационный» тул лежит просто мертвым грузом.
И мое самое любимое — коллега придумал как автоматизировать работу целого отдела, накрутил туда из говна и палок AI‑MVP и удачно продал это руководству как супер‑инновацию. А через какое‑то время свалил в закат. И вот сидят коллеги и думают — а что с этой инновацией делать и как вообще оно работало, как вносить изменения, поддерживать это добро и почему оно стало столько стоить.
Реальность AI‑долга: Накрутить AI‑автоматизацию или тул — это 10% усилий и пара дней работы. Поддерживать её в проде, обновлять базы эмбеддингов, следить за версионированием промптов и очищать код от следов неудачных тестов — это 90% времени, к которому команды вообще могут быть не готовы.
Так вот чтобы не пришлось потом с лопатой заниматься ликвидацей этого AI‑долга — нужно менять паттерны поведения людей в компании:
Платформенный подход вместо анархии. Не позволяйте каждой команде изобретать свой велосипед для интеграции с LLM. Выделите Core‑команду (Platform Engineering), которая создаст единый внутренний API‑шлюз для AI, стандартизирует логирование, аутентификацию и кеширование запросов.
Вводить AI‑гигиену. Эксперименты должны быть изолированы. Создайте жесткое правило: под каждый пилот выделяется изолированная песочница с ограниченным сроком жизни. Эксперимент завершен? Песочница уничтожается со всеми потрохами (базами, ключами API, пайплайнами). Чтобы перенести код в прод, он должен пройти тотальный рефакторинг и аудит.
Главный риск AI‑трансформации сегодня — это не то, что ваши конкуренты внедрят AI быстрее. Главный риск — это захлебнуться в поддержке сотен полурабочих, грязных AI‑инструментов и брошенных интеграций, которые вы или ваши коллеги нагенерировали в порыве энтузиазма.
Как снизить стоимость хранения данных с помощью комбинаторики и линейной алгебры? Узнаете на GoCloud Tech 2026
При проектировании систем хранения приходится искать баланс между тремя параметрами: производительностью, надежностью и стоимостью инфраструктуры. На практике улучшение одного показателя нередко требует пожертвовать другим. Разберемся, из чего складывается стоимость хранения данных и как снизить ее с помощью продвинутых алгоритмов отказоустойчивого кодирования. Поговорим о математике нового кодировщика, принципах его работы и сложностях production-ready реализации. А еще покажем на графиках, как решение влияет на скорость работы и потребление ресурсов. Доклад поможет архитекторам, инженерам и системным администраторам подобрать оптимальный баланс между производительностью, надежностью системы и затратами на инфраструктуру.
Спикер: Сергей Баширов — ведущий разработчик R&D, Cloud.ru.
Демонстрационная БД Marketplace: Реалистичный полигон для проверки РЕД Базы Данных на практике
Как превратить СУБД из «шкафа с таблицами» в надежный отказоустойчивый бэкенд на примере современного E-commerce.
Демонстрационные базы данных – неотъемлемая часть экосистемы любой серьезной СУБД. Мы создали MARKETPLACE – уникальный полигон, который предоставляет готовую и продуманную среду для экспериментов с РЕД Базой Данных 5. Это не просто база на 100 строк, а миниатюра торговой площадки, на которой покупатели ищут товары, продавцы управляют складами, а система обрабатывает заказы и платежи.
Из вебинара вы узнаете:
● Как спроектировать архитектуру, которая не упадет под нагрузкой, и использовать современные возможности SQL.
● Как извлекать данные из полуструктурированных JSON-полей.
● Как безопасно изменять данные в условиях высокой конкуренции и не продать один товар дважды.
● Как строить сложные отчеты: от анализа маржинальности до предиктивной аналитики закупок.
Спикер: Андрей Совцов – эксперт-консультант РЕД Базы Данных
Дата и время: 1 октября в 14:00 по московскому времени
14 уроков для системных администраторов, которым мало просто «чтобы работало»
Привет, Хабр. Стабильная инфраструктура редко держится на одном удачном конфиге. Сегодня нужно разобраться, почему сервер тормозит, завтра — настроить отказоустойчивость, послезавтра — автоматизировать развёртывание или понять, что именно показывает мониторинг.
И чем сложнее становится система, тем важнее не просто устранять последствия, а понимать, что происходит внутри инфраструктуры, быстрее находить причины проблем и сокращать количество ручной работы.
В этом посте собрали 14 бесплатных уроков для тех, кто хочет увереннее работать с серверами, сетями, Kubernetes, мониторингом и безопасностью.
Linux и Windows
22 сентября в 20:00. «Топ GPO, которые помогут тебе». Записаться
23 сентября в 20:00. «Linux на практике: безопасный доступ к серверу и автоматизация через SSH». Записаться
24 сентября в 19:00. «Сможет ли ИИ починить Linux‑сервер: где заканчиваются подсказки и начинается инженерная диагностика». Записаться
Диагностика и наблюдаемость
23 сентября в 20:00. «eBPF: рентгеновское зрение для production». Записаться
14 октября в 20:00. «ИИ для мониторинга: что Prometheus и Grafana могут рассказать агенту». Записаться
20 октября в 20:00. «OpenTelemetry в.NET: от чёрного ящика к наблюдаемой системе». Записаться
Kubernetes и автоматизация инфраструктуры
1 октября в 20:00. «Kagent + Ollama: ИИ‑агент для работы с Kubernetes». Записаться
7 октября в 20:00. «GitOps‑практики: развертываем сервис через ArgoCD». Записаться
15 октября в 20:00. «Поднимаем кластер Kubernetes с помощью Terraform и Ansible». Записаться
Трафик, отказоустойчивость и веб‑инфраструктура
22 сентября в 20:00. «Автоматизация управления трафиком с mitmproxy». Записаться
23 сентября в 20:00. «Узнайте, как использовать Patroni для управления высокодоступными кластерами PostgreSQL». Записаться
5 октября в 19:00. «Автоматические TLS‑сертификаты: модуль ACME (Angie)». Записаться
20 октября в 19:00. «Балансировка HTTP и L4 сервисов в Angie». Записаться
Безопасность инфраструктуры
21 октября в 20:00. «Пентест инфраструктуры: поиск слепых зон IDS/IPS». Записаться
Полный список бесплатных уроков сентября смотрите в дайджесте.
