Привет, Хабр!

Я Владимир Колпаков, инженер-проектировщик СПД в центре сетевых решений

«Инфосистемы Джет». Сегодня расскажу, как работает система автоматизации сетевой фабрики, которую мы сделали для одного из заказчиков.

Автоматизация управления сетевым оборудованием давно превратилась в must-have для бизнеса. Если коротко, то это применение программных инструментов для автоматизации работы сетевых устройств. Цель — не просто упростить жизнь инженерам, а напрямую влиять на бизнес-метрики. В цифрах: развертывание новых сервисов ускоряется на 50–70%, а количество ошибок при конфигурировании снижается на 30–40%.

Почему White Box? Совокупный среднегодовой темп роста рынка White Box-коммутаторов составляет 16,2%. В первую очередь привлекательность White Box-коммутаторов обусловлена ценой, которая может быть ниже на 30–70% по сравнению с традиционными коммутаторами. Ответ на вопрос, за счет чего получается такая разница, раскрывается в идеологии White Box- оборудования.

White Box — это модель поставки сетевого оборудования, в которой аппаратная платформа и сетевое ПО поставляются отдельно. White Box («белый ящик») возник как ответ на классические программно-аппаратные комплексы (ПАК) от известных вендоров, которые представляют собой так называемый черный ящик — Black Box.

Благодаря концепции ONIE (Open Network Install Environment) White Box или baremetal- коммутаторы идут с минимальным набором ПО, который состоит из загрузчика и предустановленной минималистичной ОС ONIE, выполняющей функцию установщика основной сетевой операционной системы без доступа к аппаратной части коммутатора, отвечающей за data plane (плоскость данных).

Мы создали комплексную систему автоматического развертывания кластеров PostgreSQL, протестировали ее более 150 раз, внедрили у заказчика в изолированной инфраструктуре, и все заработало.

Никакого доступа к рабочей инфраструктуре, никакого интернета, никакого «скопировал — вставил». Даже буфер обмена отключен. Все тестируем у себя, воссоздав полностью среду заказчика. А это уже больше похоже на запуск марсохода.

Как YDB разворачивается «в бою», что происходит при сбоях, как работает восстановление, как ведет себя кластер под нагрузкой, с какими сюрпризами столкнется команда, которая будет ее администрировать. Весь анализ — с фокусом на уменьшение операционных затрат и повышение надежности.

«Собака BUGскервилей» и «Однажды в Bravera Capital» — вы, наверное, подумали, что это названия свежих детективных романов? На самом деле это заголовки заданий киберучений главного онлайн-кэмпа по практической кибербезопасности CyberCamp 2025.

Задания CyberCamp 2025 стали еще ближе к реальным вызовам. Некоторые из них позволили участникам почувствовать себя в роли современных ИБ-специалистов и прокачать свои профессиональные навыки — от поиска секретов в истории Git до расследования APT-атак. Разбираем самые запутанные и интересные задания — те, что помогли не просто «набрать баллы», а получить практический опыт.

Привет! 

Это снова IT Elements. Надеемся, вы скучали. 

3,5 тыс. участников офлайн, 110 тыс. онлайн-зрителей, 200 спикеров, 6 залов и 108 часов экспертного контента — это если кратко об итогах конфы, масштабы в этом году были нешуточные 🙂  

На мероприятии своим опытом делились все — от топ-менеджеров крупных банков и промышленных предприятий до опытных инженеров, имеющих занимательные кейсы. Кстати, если вы хотите стать спикером в следующем году, следите за обновлениями в нашем TG-сообществе, мы заранее откроем Call For Papers.

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

С 20 по 25 октября в четвертый раз прошел CyberCamp 2025 — главный онлайн-кэмп по практической кибербезопасности. В этом году мероприятие вышло на новый уровень: к эфиру подключились более 42 000 зрителей из 400 городов, а в командных киберучениях приняли участие 220 команд — почти вдвое больше, чем годом ранее.

Кейсы от ведущих экспертов, динамичные соревнования и активное вовлечение участников создали атмосферу настоящего фестиваля кибербезопасности.

Рассказываем о CyberCamp 2025 изнутри. 

Привет, Хабр!

Меня зовут Никита, я ML-разработчик в «Инфосистемы Джет». В этой статье хочу поделиться практическим опытом: как GPT + low-code помогает запускать прототипы и автоматизировать процессы без долгих циклов классической разработки.

Если вам нужно быстро проверить гипотезу, запустить внутренний инструмент или собрать простой прототип, длинные спринты и ожидание, пока IT‑отдел возьмет задачу, могут убить всю инициативу. Современные низкокодовые (low‑code) платформы в связке с генеративными моделями GPT позволяют собрать рабочий MVP буквально за выходные. Достаточно описать задачу обычным языком — и платформа генерирует бизнес-логику, сценарии интеграции и рабочие процессы.

Ниже разберёмся, как это устроено, на что действительно способен подход GPT + low-code и какие ограничения важно учитывать на старте. Статья пригодится техническим продукт‑менеджерам, аналитикам и разработчикам.

Привет, Хабр!

Знаете это чувство, когда оборудование есть, мониторинг есть, а их совместная работа — нет? Именно так мы ощутили себя, когда столкнулись с IBM Storwize в экосистеме Zabbix. «Из коробки» поддержка отсутствует, а костыли в виде скриптов и UserParameters работают так, что хочется плакать:

За последний год даже те, кто не связан с информационной безопасностью или ИТ-администрированием, узнали о хакерских атаках, в ходе которых уничтожаются или шифруются данные. Теоретически, массовая атака программ-вымогателей может временно парализовать важную инфраструктуру: остановить транспорт, лишить магазины, аптеки и АЗС возможности обслуживать клиентов. Хотя такая картина кажется гиперболизированной, она вполне возможна — особенно на фоне недавних событий и произошедших инцидентов.

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

Хабр, привет!

С мая 2025 года стала доступна новая версия Red Hat Enterprise Linux — RHEL 10. Одним из её главных новинок стала поддержка bootc-контейнеров — загружаемых контейнеров, которые можно запускать не только в привычном виде qcow, vmdk и raw-образов виртуальных машин, но и прямо на любимом Bare Metal.

Некоторые аналитики считают технологию крайне перспективной. В нашей практике мы с ней не сталкивались, но это только пока.  Для нас это отличный повод посмотреть на нее поближе.

Спойлер: bootc чем-то напоминает CoreOS и то, как Machine Config из OpenShift взаимодействует с ним. Но bootc применяется уже в отрыве от «родительского» окружения в «реальном мире». 

Меня зовут Антон Чикин, я руковожу отделом интеллектуального анализа в «Инфосистемы Джет». В статье я попробую показать на практическом примере, почему корпоративный ИИ нельзя свести к установке готовой LLM — и что именно приходится выстраивать вокруг неё, чтобы получить реальную ценность для бизнеса.

Этот материал будет полезен тем, кто отвечает за внедрение ИИ в компаниях среднего и крупного масштаба: ИТ-директорам, архитекторам корпоративных систем, специалистам по информационной безопасности и тем, кто рассматривает генеративный ИИ как инструмент автоматизации бизнес-процессов.

Представьте: вы садитесь в такси. У водителя есть права — значит, формально он умеет водить. Но сможете ли вы предсказать, как он поведет себя в экстренной ситуации? Вряд ли. С оценкой сотрудников то же самое: формальная проверка есть, но глубины часто не хватает.

Как понять, что специалист действительно хорош? Как его оценивать и развивать? И можно ли делать это не на глаз? Отвечаем на эти и другие вопросы. 

Привет, Хабр!

Сегодня расскажем не столько о решении — оно оказалось простым – сколько   о самом процессе его поиска. Он был настолько увлекательным, что в какой-то момент мы почти уверовали в существование магии. Но мы — инженеры, а поэтому как никто знаем, что чудес не бывает. Поэтому, откинув домыслы и иррациональность, мы шаг за шагом распутывали этот технический узел, докапываясь до первопричины проблемы. Приступим же к нашему расследованию. Приятного чтения!

Привет, Хабр! Меня зовут Павел, я ведущий архитектор в «Инфосистемы Джет», и это мой дебют на этой площадке.

Привет, Хабр!

Эта история произошла в канун Нового года. Один из последних рабочих дней  медленно подходил к концу, мысли уже давно отмечали праздник. Идиллию нарушил звонок коллеги за два часа до окончания смены — мне предложили заняться проблемой функционирования массива Fujitsu AF650 S3. Попытки делегировать диагностику не увенчались успехом – я остался последним. Что ж, вот моя история.

Ни к чему нам лишние переживания за главного героя — Новый год я отметил с семьей за праздничным столом.

Привет, Хабр!

Когда речь заходит об отказоустойчивости между ЦОДами, метрокластер — почти всегда первое, что приходит в голову. Раньше это был стандарт: один ЦОД падает — второй подхватывает. Все работает, данные не теряются. Вместе с уходом западных вендоров их решения ушли вместе с ними либо появились огромные трудности с их конфигурированием и поддержкой.

С 2024 года у нас на тестовом стенде стоят системы хранения AQ440 от «Аэродиск». Мы их активно «мучаем»: имитируем отказы, нагружаем, меряем задержки, устраиваем испытания на выживание. Наш выбор связан с тем, что это единственное решение (на данный момент), у которого есть поддержка метрокластера. И основной фокус сегодняшнего рассказа — описать сценарии работы этой технологии. Не имитацию, не полумеру, а рабочую схему с реальным переключением между площадками, отказами и всем, что из этого следует.

В 2024 году мы — команда практического анализа защищенности «Инфосистемы Джет» — выполнили 130 проектов и выяснили, что в среднем достаточно 10 часов, чтобы вывести крупные суммы со счетов, остановить производство или слить критичную информацию. В работе мы используем сложные методы, но из-за низкой защищенности организаций часто хватает базовых техник[1] и общедоступного ПО. Наши наблюдения подтверждаются исследованиями кибератак[2]: в 83% случаев злоумышленники добивались успеха за счет «простых» методов — фишинг, эксплуатация уязвимостей по умолчанию или слабые пароли. State of art атаки с поиском 0-day — это скорее исключение. Обычно компании взламывают куда более прозаичными способами.

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

Привет, Хабр!

На связи сервисная команда «Инфосистемы Джет». Сегодня хотим рассказать про один из технических кейсов. На его решение должна была уйти пара часов. Вместо этого он съел четыре дня нашей жизни. Спустя почти десяток лет он регулярно вспоминается в обсуждениях за обедом как один из непростых в диагностике. На днях обсуждали его — почему бы теперь не рассказать о нем вам? :) Приступим.

Привет, Хабр!

Сегодня поделимся не историями грандиозных IT-побед, а скромными буднями борьбы с коварными, но редкими багами. Нам "повезло" столкнуться сразу с тремя такими на одном проекте. Спойлер: виноваты были забытые обновления Windows, коварный апдейт Касперского и упрямый PCI-райзер. Читайте, как мы их ловили, и берите на заметку наши шишки!

⚠️ Дисклеймер: Подвигов не будет, только серая, но поучительная реальность. Хотим напомнить, что путь настоящего самурая иногда состоит из мелких неудач и разного масштаба трудностей. Но самурай идет вперед.

Привет, Хабр!

Сегодня рассказываем об одном любопытном кейсе в крупном заказчике, который столкнулся со странным поведением при построении свой сети с NSX-T от VMware. Проблема была связана с реализацией Bridge между сегментом GENEVE и физической сетью. В целом, это известный и востребованный механизм, а также он помогает закрыть часть вопросов, когда нужно «подружить» Overlay и физическую сеть без роутинга. До решения докопались – об этом читайте ниже во всех подробностях.