Всем привет! Меня зовут Андрей Беляев, я бизнес-архитектор в компании «Инфосистемы Джет».

Как говорил Тирион Ланнистер в последней серии «Игры Престолов», в мире нет ничего сильнее хорошей истории. Особенно, если нужно было решить типовую задачу по сбору метрик на производстве, и ни на какую историю никто не рассчитывал. А в результате мы придумали архитектуру решения, придумали ее еще раз, поборолись с закрытой промышленной системой и сделали «мост» данных из изолированного цеха в корпоративную сеть.

Как это было, и что у нас в итоге получилось, расскажу под катом.

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

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

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

Так возникает необходимость вынести данные приложения на отдельную файловую систему, но традиционный подход требует полного копирования больших объёмов данных и длительного простоя сервисов. В этой статье мы покажем способ изменить разметку уже работающей Linux-системы без переустановки ОС и без копирования сотен гигабайт данных.

Всем привет! Я Светлана Забирова, лид аналитики в Центре разработки и машинного обучения компании «Инфосистемы Джет». В ИТ работаю уже больше десяти лет, из них половину – в заказной разработке.

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

По заданному контексту ИИ хорошо справляются с кодом, миграциями, OpenAPI, сценариями и документацией. Но агентная разработка быстро начинает буксовать, если входной артефакт остается большой постановкой в Confluence, Word или Jira без строгой структуры и трассировки. Модель теряет важные условия, смешивает уровни детализации, дублирует требования или додумывает недостающие связи.

ИИ не будет работать лучше, если аналитики просто «начнут промптить». Задача решается уровнем выше: требования должны стать инженерным артефактом. То есть относиться к требованиям нужно так же, как разработчики относятся к коду.

Спецификация должна жить в том же рабочем процессе, где живет код. Даже если физически код и требования находятся в разных репозиториях.

Мы решили проверить подход на одном из пилотных проектов, где было все: аналитика, архитектура, backend/frontend-разработка, тестирование и DevOps.

Как мы перевели аналитику из Confluence/Word в SDD-контур и что из этого получилось, рассказываю под катом.

Кому полезно: бизнес- и системным аналитикам, руководителям команд, архитекторам и разработчикам, которые уже обсуждают SDD, агентную разработку и новые требования к постановкам.

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

Чем больше растет инсталляция Zabbix, тем сложнее становится управлять ее конфигурацией. Особенно если речь идет не об одном сервере мониторинга, а о нескольких инсталляциях, десятках команд и сотнях инженеров, которым регулярно нужно что-то менять: пороги срабатывания, IP-адреса, триггеры, шаблоны или наборы метрик.

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

Тогда мы решили посмотреть на конфигурацию мониторинга как на отдельный объект управления и вынести ее в централизованную CMDB. Так появилась система, которая собирает конфигурацию из нескольких инсталляций Zabbix, предоставляет единый интерфейс для работы с настройками, поддерживает RFC-процессы, хранит историю изменений и позволяет откатывать их при необходимости.

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

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

В последнее время обсуждать миграцию с продуктов SAP – это база. Однако для многих компаний эти системы пока остаются ключевыми.

Типичная защита периметра: «свои» внутри, «чужие» снаружи. Но бывает инверсия. Заказчик открывает SAP NetWeaver AS Java в большой мир. SAML в этой системе активируется быстрее, чем вы моргнете — буквально в два клика. Но если на том конце провода не дремлет злоумышленник, а у вас нет 2FA… считайте, что ключи от дома вы спрятали под ковриком.

Мы столкнулись с этой болью на проекте у одного из заказчиков. Нужно было настроить двухфакторную аутентификацию. И вот тут начались нюансы.

В этом материале мы опишем настройку интеграции портала SAP NetWeaver AS Java с внешним Identity Provider (IdP) — Keycloak — с реализацией двухфакторной аутентификации (2FA). До нашего вмешательства аутентификация происходила напрямую в SAP-системе.

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

Далее кратко рассмотрим процесс настройки и разберем возникшие проблемы.

Если вам обещают, что ИИ ускорит разработку в 5 раз — скорее всего, вам пытаются что‑то продать. Особенно если «волшебство» сводится к установке плагина в IDE.

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

Статья будет полезна тимлидам, скрам‑мастерам и всем, кто устал от маркетинговых метрик без контекста.

Привет, Хабр! Я Дмитрий Киселев, руководитель группы сервисной поддержки решений по передаче данных в «Инфосистемы Джет» и создатель программы для стажёров в команде. И сегодня я расскажу вам о том, как мы придумали и уже несколько раз провели новые сетевые игры.

«Нужно построить зиккурат!» — знакомая фраза? А если нужно построить не зиккурат, а BGP-соседство? Именно этим и надо заниматься в первой стратегии, которую мы создали для сетевых инженеров — NetCraft.

После нашей первой игры для сетевиков — «Need for Speed: VXLAN EVPN. Гонки на коммутаторах» — мы поняли: инженерам мало просто настраивать скорость — интереснее придумывать сложный план действий. Так родилась идея стратегии в реальном времени, но с консолью вместо мышки.

Игра успешно зарекомендовала себя на Linkmeetup, Сетевом лете и IT Elements. Мы уже обновляем игры к Сетевому лету-2026, а пока я расскажу правила.

Всем привет! Меня зовут Никита Гусев, я руковожу направлением EPM в компании «Инфосистемы Джет».

Если вы когда-нибудь видели, как финансист или аналитик ставит себе ТРЕТИЙ монитор, чтобы формулы помещались на экране, то сложности работы Excel в крупных компаниях примерно представляете. В статье расскажу, почему еще планирование в табличках — это больно, и по какому пути идут наши заказчики.

Всем привет! Меня зовут Станислав Денисов, я ML-инженер в компании «Инфосистемы Джет».

Из-за вайбкодинга Хабр пережил уже не один холивар и переживет еще столько же, потому что, судя по всему, он с нами надолго.

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

Ситуация, когда ИИ сам пишет, проверяет и деплоит код по запросу разработчика, уже данность. Claude Code создаёт 4% всех публичных коммитов на GitHub, а в Google заявляют, что 50% их кода ー AI-generated. По прогнозам цифры будут только расти, и это само по себе не проблема.

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

Об инструментах как раз поговорим в статье, а именно о кодовом ассистенте Яндекса. Сегодня разберем оболочку агента, посмотрим, как он справится с деталями и нюансами разработки, и проведем черту между зонами ответственности ИИ и человека.

Спойлер: почти Cursor.

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

Из всего многообразия оборудования, которое встречается в ЦОДе, ленточные библиотеки — единственный вид, работу которого можно увидеть. Ленточные библиотеки ворочают петабайты данных на магнитных лентах в картриджах, которые отдают лёгкой ностальгией по VHS, и делают это с помощью роботов. А роботы — это (почти) всегда круто. И в одной библиотеке их может быть несколько!

Ленточные библиотеки стыкуются из модулей, как огромные орбитальные станции, а их производители в погоне за максимальной плотностью хранения картриджей находят очень изобретательные решения — от хранения картриджей в несколько слоёв в одном слоте до револьверных механизмов высотой с холодильник и шаттлов, которые передают ленты между разными библиотеками. Это ли не круто?

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

На связи центр компетенций VMware "Инфосистемы Джет".

В этой статье расскажем о тонкостях подключения LUN (логических номеров устройств) из системы хранения данных (СХД) к хостам ESXi, которые управляются через vCenter Server. За прошлый год мы не раз сталкивались с проблемами у заказчиков, которых можно было бы избежать при правильной настройке. Как именно — расскажем ниже, не забывая и про теорию.

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

В этой статье мы расскажем о заочной борьбе с разработчиками объектного хранилища Hitachi Content Platform. Сначала мы столкнулись с критическим заполнением файловых систем индексов, а в процессе лечения обнаружили вторую, гораздо более глубокую проблему — одна из нод кластера фактически выпала из схемы хранения данных, оставаясь при этом «зелёной» в консоли. Материал будет полезен инженерам, работающим с HCP и другими объектными СХД, а также всем, кто любит истории о нетривиальных расследованиях в недрах корпоративного ПО.

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

Когда выходит новая версия инфраструктурного ПО, у инженеров всегда два вопроса: «Что там интересного?» и «Не сломается ли то, что работало раньше?». Релиз-ноуты отвечают только на первый, да и то с поправкой на маркетинг.

Мы решили закрыть оба вопроса сразу. Взяли zVirt 4.5 от Orion soft, развернули на тестовом стенде и проверили все ключевые изменения, которые могут повлиять на эксплуатацию. Рассказываем, что нашли: от реально полезных фич до нюансов, о которых стоит знать перед обновлением с 4.4. Ведь в даже в «тихих» изменениях часто появляются вещи, которые потом незаметно становятся частью рутины администратора.

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

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

Краткое содержание первой серии части (гиперссылка) нашего мануала:

мы развернули двухузловой кластер MySQL с асинхронной репликацией по GTID, улучшенной полу-синхронностью, и добавили два уровня отказоустойчивости: на уровне сервиса IP и роли БД.

Теперь пришло время рассмотреть, как происходит отказоустойчивое переключение пошагово в разных сценариях.

MySQL, который выживает: отказоустойчивый кластер с Orchestrator

Разбираем настройку HA-кластера с Keepalived и Orchestrator для тех, кто предпочитает контроль облачным black box-решениям.

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

Почему проблема отказа мастера в кластере MySQL до сих пор актуальна? Потому что сегодня 10 минут простоя у крупных заказчиков – это ЧП, а человеческий фактор в кризисной ситуации – главный источник риска. Многие проекты, мигрируя на MySQL 8.0, заново проходят путь настройки отказоустойчивости. И далеко не все готовы доверить свою основную базу данных облачным managed-сервисам, иногда нужен полный контроль на своей инфраструктуре.

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

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

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

Эта история — про локализацию московского офиса крупного международного банка. Она будет особенно близка тем, кто уже участвовал в «разводе» инфраструктур. А тем, кому это только предстоит, — может сэкономить пару нервных клеток.

Глава 1. Постановка задачи

Однажды меня вызвали на разговор и поставили задачу: помочь ИТ-подразделению московского филиала международного финансового института отделиться от «материнской» компании.

Сразу стало понятно: проект будет сложным, а никаких приятных перспектив на горизонте не маячит. Но отказаться было нельзя — такие задачи не выбирают, они выбирают тебя.

NB: В подобных проектах решающую роль играют отношения между командами заказчика и исполнителя.
Я ожидал атмосферы тотального недоверия. Но ошибся — команда заказчика оказалась профессиональной и адекватной. Пользуясь случаем, ещё раз передаю им респект.

Формально задача выглядела просто: в нужный день рубим кабель, режем трафик на firewall — и всё, офис независим.

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

При создании киберустойчивой инфраструктуры много внимания уделяется проверкам защищённости: пентестам, Red/Purple Teaming, программам Bug Bounty и кибериспытаниям. Оценка часто сводится к бинарному вопросу «Взломали / Не взломали?». Однако, даже если взломать пока не удалось, это ещё не говорит об устойчивом к атакам бизнесе, ведь в тени остается вопрос: «А что будем делать, когда всё-таки взломают?».

Когда большая часть систем остановлена, масштаб бедствия неясен, а СМИ уже публикуют инсайды, многие действуют реактивно и вслепую, полагаясь лишь на опыт и интуицию. При этом действия после инцидента тоже можно и нужно проверять заранее.

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

«Балансирование нагрузки», «ADC», «GSLB», anycast, ECMP, — много разных терминов и ещё больше разных сценариев реализации, как в постановке задачи, так и в методах и механике реализации. Итак, давайте попробуем для начала наметить основные критерии, по которым можно разделить разные типы балансирования нагрузки.

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

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

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

Автоматизация управления сетевым оборудованием давно превратилась в 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 (плоскость данных).