Хабр, привет! Сегодня выходной, а значит, можно отдохнуть от хардкора. Ежегодно в последнее воскресенье ноября в России отмечается День матери, и в честь этого дня мы решили поднять здесь нестандартную тему — работа в одной компании с родителями или детьми. Присаживайся поудобнее и поехали!

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

Мы тестировали около десятка российских VDI-решений — на базе ПО с открытым исходным кодом OpenUDS и написанных полностью «с нуля». У продуктов отличается функционал и ценовая политика. Характерная черта, которая объединяет все эти продукты, — отсутствие специализированного протокола подключения пользователей, сопоставимого по производительности и функционалу с VMware Blast и Citrix ICA/HDX. Нельзя сказать, что разработка протоколов не ведется совсем — они все-таки есть: RX от Etersoft, GLINT на основе проекта freerdp от «Даком М», модификация SPICE от ГК «Астра». Но все они пока далеки от того, чтобы стать реальным российским стандартом для VDI «на все случаи жизни». Пока российские решения не обладают целым рядом того функционала, который есть у зарубежных аналогов: динамическая оптимизация работы протокола под канал связи (работа с «хорошими» и «плохими» каналами), возможность управлять работой протокола (тюнинг протокола в ручном режиме), эффективные алгоритмы сжатия трафика, дополнительный функционал протокола — SSO, контроль USB-устройств, работа в HTML5-режиме, поддержка vGPU.

В 2021 году мы познакомились с коллегами из компании Loudplay, которые работают в области облачного гейминга. Оказалось, что у них есть свой собственный протокол, оптимизированный для работы на нестабильных каналах, выдающий максимально возможный User Experience для геймеров. С этого момента мы начали совместно с Loudplay и вендорами VDI работать над интеграцией и адаптацией этого протокола.

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

Для начала отметим, что VDI по своей сути — это система автоматизации двух ключевых процессов:

— Управление жизненным циклом виртуальных рабочих мест (ВРМ) (развертывание из шаблона с регистрацией в службе каталога, пауза, перезапуск, удаление, переразвертывание после внесения изменений в шаблоны и т. п.).
— Управление пользовательскими сессиями: авторизация пользователей, организация сессий, проброс пользовательских устройств на виртуальные АРМ.

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

В нашу лабораторию Jet RuLab на тестирование попали серверы бренда TTY, довольно успешно продающиеся на китайском внутреннем рынке, но малоизвестные в России. В этом посте рассказываем о моделях двух поколений, возникших проблемах и можно ли с этим жить. 

За курс операционных систем в моем институте мне всегда было обидно. На протяжении семестра раз в неделю к нам приходил лаборант с методичкой и полтора часа, иногда запинаясь, читал из своего пособия сначала общую информацию о том, что такое ОС и из чего они сделаны, а позже — что такое Linux и как с ним работать.

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

Наверняка с тобой случилась хотя бы одна удивительная история в сфере ИТ или ИБ, которую ты привез из командировки, которая произошла на очередном закрытом проекте или случилась в твоей компании. На CyberCamp 2023 мы попросили соревнующиеся команды и зрителей поделиться интересными байками из своего профессионального опыта. Всё, что под спойлером, — чистая правда 

P.S Если любишь байки — залетай в первую статью, которую мы выпустили в прошлом году.

В сентябре мы провели CyberCamp 2023, в рамках которого в том числе прошли самые масштабные в России командные соревнования на платформе киберучений. Мы разделили участников на две лиги: корпоративную и студенческую. И в каждой выбрали трех победителей.

Команда CyberNoobs заняла первое место в корпоративной лиге, в которой за приз сражались 66 участников из крупнейших российских компаний. Мы взяли интервью у Алексея, капитана команды. Под катом — его впечатления, обзор заданий и советы будущим участникам.

Мы продолжаем рассказывать просто о сложных решениях из мира ИБ в нашем Security Small Talk. Кто забыл – это короткие Youtube-ролики, которые будут полезны как прожженым ИБ-шникам и ИТ-специалистам, так и тем, кто только начинает свой путь в ИБ. Security Small Talk за 7 минут поможет освежить ваши знания, разобраться в каждой из областей и понять, куда копать для дальнейшего изучения.

В прошлом материале мы рассказали, с какой проблемой столкнулись, и проанализировали четыре СУБД в поиске рабочего решения. Мы оценили преимущества и недостатки каждого отобранного варианта и остановились на ClickHouse. Несмотря на то, что готовой интеграции этой БД с Zabbix не существует, CH отлично подходил как решение под наши инженерные задачи.

БД в Zabbix

Прежде чем мы перейдем к рассказу о реализации, расскажем о специфике работы БД в Zabbix. Вся ее логика вынесена в отдельную библиотеку — zbxhistory. Она используется сервером и прокси для сохранения данных мониторинга. В классе history описывается интерфейс, который имплементируется каждой реализацией подключения к хранилищу данных.

Хабр, привет! В сентябре мы провели второй онлайн-кэмп по практической кибербезопасности — CyberCamp 2023. Событие собрало в два раза больше участников в сравнении с прошлым годом — более 10 000 зрителей и 100 команд, сражавшихся в двух лигах: корпоративной и студенческой. 

Онлайн-кэмп объединил в себе несколько форматов: онлайн-конференцию с докладами, соревнования команд киберучений и интерактивы для зрителей. В рамках мероприятия функционировали две независимые платформы. На одной в течение трех дней участники киберучений со всей России боролись за призовые места и оттачивали свои навыки. А на второй зрители проходили викторины, задания и мини-игры, наблюдали за трансляцией и слушали 25 докладов от ИБ-экспертов из «Инфосистемы Джет», Positive Technologies, «Лаборатории Касперского», Yandex Cloud, АО «СОГАЗ», BI.ZONE, Qrator Labs и др.

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

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

На одном крупном проекте мы, инженеры компании «Инфосистемы Джет», столкнулись с типичной проблемой стандартных инсталляций Zabbix на больших объемах - производительностью и низкой отказоустойчивостью базы данных. Конфигурация Zabbix была следующей:

• один Zabbix-сервер;

• множество прокси;

• сервер БД PostgreSQL с расширением TimescaleDB;

• сервер Grafana для визуализации данных.

При обычной нагрузке (12000 NVPS) система работала стабильно, но стоило произойти массовой аварии на инфраструктуре или перезагрузке сервера/прокси, как производительности БД не хватало. В такие моменты очень быстро накапливались очереди обработки данных, заканчивались кэши – система фактически прекращала работу. Непростую ситуацию ухудшали еще ложные срабатывания (данные не всегда могли попасть в БД) и рассылка уведомлений ответственным администраторам, проверявшим состояние систем в WEB-интерфейсе. Для восстановления работы приходилось перезапускать компоненты друг за другом, контролируя нагрузку на БД.

Проблему оперативно решили при помощи снижения количества чанков для хранения трендов. Причина происходящего крылась в некорректном партиционировании трендовых данных. Детально о проблеме и методах решения можно почитать в баг-репорте производителя (ZBX-16347). Он помог нам в устранении аварии, но ограничиваться только им не стали – одного репорта, на наш взгляд, было недостаточно. Мы стали смотреть шире и задумались над альтернативными решениями.

А какие варианты есть?

Начнём с того, что наибольшая нагрузка на БД в Zabbix создается на операциях с историческими данными и происходящими в мониторинге событиями. Это таблицы: history, history_uint, history_text, history_str, history_log, events, problems. Производитель предлагает использовать следующие БД: MySQL, PostgreSQL и Oracle DB. Кроме того, исторические данные можно отправлять и в Elasticsearch.

Это случилось около пяти лет назад, когда я работал во внутренней службе поддержки «Инфосистемы Джет». Тогда на одном проекте мне удалось поработать с коллегами из центра сетевых решений, после чего я увидел только один возможный сценарий для своего развития — сети и всё, что с ними связано.  

Чтобы переход был плавным, а путь ярким, в свои 30 я решил понизить ранг до стажера. Хоть я был сильно погружен во внутренние процессы компании и имел за плечами 10-летний опыт в ИТ, моя область деятельности сильно отличалась от того, чем я занимаюсь сегодня.

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

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

Оффтоп

Наш рассказ — это гид автостопщика, некое summary тех вещей, которых нам не хватало при знакомстве с Vault. В нем мы сделаем несколько остановок: поговорим в целом про управление секретами, о том, почему мы рекомендуем именно Vault; рассмотрим, как Vault работает; поделимся лайфхаками по работе с секретами и болью о том, чего нам не хватает в продукте.

Я родился, вырос и получил вышку в регионе. Оказалось, что это не уменьшает твои шансы на интересные задачи на работе и достойную оплату. Главное — быть заинтересованным и владеть английским языком (спасибо, бинго!). В остальном тебя мало что отличает от жителя столицы — такого же сервисного инженера, как и ты. За годы региональной карьеры я побывал во множестве стран мира, вырос до руководителя и не раз убедился, что переезжать в столицу не обязательно.

Но обо всём по порядку.

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

Про переход в ИТ, ML на производстве и гендерные стереотипы — смотри ниже.

Привет, Хабр! Мы уже как-то писали тут про аллокацию ИТ-затрат. Вкратце — это способ распределить стоимость затрат компании на ИТ между ее бизнес-юнитами. Мы считаем, сколько стоят наши ИТ-ресурсы, кто и сколько их потребляет, превращаем эти ресурсы в деньги и мапим их на бизнес-подразделения. Это помогает точнее планировать бюджет и контролировать потребление ИТ-ресурсов в компании.

Чтобы как-то оформить и в дальнейшем применить результаты сбора данных по всем ИТ-услугам, которые потребляют бизнес-юниты, мы строим модель, описывающую стоимость ИТ-сервисов компании. Но модель аллокации — это просто набор правил и формул расчета. Для удобства всю эту логику расчетов нужно перенести в калькулятор, зашить туда спецификации оборудования и ПО, стоимость поддержки, аренды и прочее. По итогу такого упражнения мы получим либо «простенький» Excel-калькулятор, либо средство автоматизации, либо и то и другое.

Посчитать стоимость услуги — лишь начало. Ее нужно предоставить, а после выставить счет. Аллокация — это часть общего процесса биллинга. Эту задачу мы решали через частное облако на ManageIQ. Об одном из таких проектов можно почитать в этом посте.

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

Недавно в нашу компанию «Инфосистемы Джет» пришел заказчик с проблемой долгой реализации создаваемых портов на NSX-T (до 2 минут до момента запуска трафика). Основная боль заключалась в том, что новые поды K8s не всегда укладывались в timeout Health Check'a и процесс начинался опять.

Исходные данные у нас были такие. NSX использовался для построения микросегментированной сети в кластерах Kybernetes + Kyverno. Взаимодействие K8s и NSX было реализовано при помощи плагина VMware NCP. Несмотря на большое количество объектов, в интерфейсе все метрики по утилизации были в «зеленых» значениях, но ощущалось сильное замедление работы UI.

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

На проектах мы часто сталкиваемся с различными интересными задачами и кейсами. Хочу поделиться одной из таких историй.

Беда пришла нежданно. Пару месяцев назад, в конце рабочего дня, когда я уже успел выключить комп и погрузился мыслями в вечерние планы, со мной связались коллеги из соседнего департамента. У их заказчика начал сбоить сервер баз данных Redis на Open Source: наблюдались дикие тормоза и потеря производительности.

Входные данные: есть три узла Redis, Standalone и две реплики, конфигурация по дефолту.

В какой-то момент Redis сильно «раздулся»: его дамп был огромен (исчислялся гигами) и на диск писался долго — показывал время запросов 2-3 секунды, не добегала репликация, видны были висящие в непонятном состоянии курсоры с тайм-аутом в час.

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

Что было дальше, описываю под катом.

Из этой статьи вы узнаете, почему важно проводить «лабораторные испытания» ML-моделей, и зачем в тестировании наработок «ученых по данным» должны участвовать эксперты из предметной области, а также — как выглядят тесты после того, как модель покинула датасайнтистскую лабораторию (и это не только мониторинг качества данных).

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