Привет, Хабр! Делюсь ниже статьей моего коллеги Игоря Резцова, ведущего системного инженера в К2 Кибербезопасность.

На связи Игорь Резцов. За 15 лет опыта в ИТ, из которых 8 лет в ИБ, я видел как требования к сетевой безопасности менялись и усложнялись. Одно можно сказать точно — NGFW давно стал базой. Согласно нашим данным, 88% российских корпораций активно используют его для защиты сетей. 

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

Привет, Хабр! Прошло 1,5 года с нашего первого разбора рынка оборудования для ЦОД. Тогда задачей было просто понять куда уходить с «циски» и дать заказчикам шорт-лист доступных производителей с ключевыми характеристиками железа. 

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

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

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

Привет, Хабр! В этой статье мы поделимся опытом инженерной команды практики контейнеризации К2Тех поговорим о том, какие решения позволяют автоматизировать ручной труд по масштабированию в Kubernetes. Начнём рассматривать инструменты с нижних уровней, постепенно продвигаясь вверх: от уровня подов до уровня всего кластера. В итоге придем к централизованному управлению всеми рабочими нагрузками в парке кластеров, без привязки к конкретному облаку или провайдеру инфраструктуры.

Привет! Меня зовут Юрий Силантьев, я руководитель практики «ERP и финансы» в К2Тех, отвечаю за проекты внедрения 1С.

Мы занимаемся крупными внедрениями уже 15 лет. В нашей практике — проекты со сложной архитектурой, высокой нагрузкой и широким функциональным объемом. В прошлом году, например, мы рассказывали, как за семь месяцев перевели крупное химическое предприятие ПАО «КуйбышевАзот» с Oracle на 1С:ERP. И в таких проектах быстро становится понятно, что успех зависит не столько от количества разработчиков, сколько от методологии. Если этапы не структурированы, роли не определены, а результаты не отделимы друг от друга, даже сильная команда будет постоянно «догонять» сам проект.

Это первая статья из цикла о нашем подходе к крупным внедрениям 1С. Берите на вооружение — наша методологию сэкономила нам сотни часов на реальных проектах.

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

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

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

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

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

Привет, Хабр! Я — Дмитрий Самохвалов, архитектор в компании К2Тех. Помимо этого пишу на GO и на Rust, и стараюсь делать жизнь наших инженеров и разработчиков интереснее и проще. В этой статье по мотивам доклада с Golang Conf я расскажу, как мы пришли к работе с eBPF и покажу на примере написания своего XDP-фильтра, как начать работу с eBPF, используя Go. 

Вы подписали договор с коммерческим SOC и думаете, что теперь можете выдохнуть? Не спешите. Многие компании покупают мониторинг безопасности как сервис — в надежде, что он решит все их проблемы. А получают долгие созвоны, неожиданные проблемы с инфраструктурой и звонки аналитиков в три часа ночи, в тот момент, когда отвечать просто некому.

Привет! Это Кирилл Рупасов, технический директор SOC. В этой статье мои коллеги из К2 Кибербезопасность — Ирина Леонтьева, старший аналитик SOC и Рамис Суляев, сервисный менеджер SOC — расскажут, почему SOC — это не продукт, который решит ваши проблемы, а партнер, с которым нужно работать совместно. И что будет, если к этому не подготовиться.

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

Мы в K2 Cloud решили провести исследование: как IT-специалисты относятся к ИИ в работе. Что это — благо или боль? Как часто искусственный интеллект внедряется там, где он не нужен? Бизнесу действительно нужно много ИИ, чтобы не отставать от конкурентов, или это превратилось в модное веяние? Давайте разбираться вместе. Сначала мы вас поспрашиваем, а результаты исследования опубликуем чуть позже, в очередной статье. Поехали!

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

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

Меня зовут Иван Звонилкин, я руководитель группы обеспечения сервисных проектов в центре экспертизы по комплексному сервису К2Тех. Вместе с моим коллегой Данилой Фохтиным, инженером входного контроля ЗИП, в этой статье объясним, чем рискуют компании при закупке запчастей сегодня и как мы справляемся с этими рисками.

Хабр, привет! На связи Михаил Косцов, руководитель практики вычислительной инфраструктуры и систем резервного копирования К2Тех. За последние годы у российских ИT-специалистов выработался «синдром недоверчивого покупателя». Когда презентуют очередную «полностью отечественную» разработку, машинально ищешь подвох: знакомый корпус под новым шильдиком, наспех перелицованный Open Source или иероглиф где-нибудь на плате. Устройство выглядит солидно, жужжит по-корпоративному, но все равно хочется заглянуть под капот. И мы заглянули. 

В нашу лабораторию приехала система хранения данных YADRO TATLIN.UNIFIED Gen2. Мой коллега ранее делился в Хабра-статьях итогами тестирования решений от вендора YADRO: СХД начального уровня TATLIN.FLEX.ONE и системы TATLIN.BACKUP для хранения резервных копий.

Итак, мы не стали церемониться: дергали диски на горячую, рубили питание / сеть / контроллеры и все, до чего могли дотянуться, протестировали модный NVMe over TCP в сравнении с классическим Fibre Channel. А потом обнаружили, что реальные цифры производительности разошлись с даташитом — причем в неожиданную сторону. Сейчас все расскажу.

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

Поэтому, если письма доходят, клиенты не зависают, а отклик сервера не «плывёт» в течение дня — система считается здоровой. Пользователи не жалуются. Администраторы не дёргаются. Почта просто есть.

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

В какой момент фоновая нагрузка перестаёт быть фоном?

Начнут ли расти очереди сообщений?

Появится ли деградация отклика спустя несколько часов работы?

Всё останется предсказуемым, когда пользовательские сессии и поток доставки писем пойдут параллельно?

Привет, Хабр! Меня зовут Владимир Сергеев, я руководитель практики UC и ПО для совместной работы в К2Тех. Мы решили не гадать на кофейной гуще, а проверить это в измеряемых условиях, на сценарии, с которым почтовая система живёт каждый рабочий день, и протестировали наш почтовый сервер CommuniGate Pro под длительной смешанной нагрузкой, близкой к реальной эксплуатации.

Представьте библиотеку, где нет единого каталога, а все записи разбросаны по десяткам бумажных журналов и сотням файлов Excel с загадочными названиями вроде «версия_12_ФИНАЛЬНЫЙ_финал.xlsx». Поиск нужной информации превращается в квест, а за критически важным протоколом приходится идти к единственному сотруднику, который «помнит, где он лежит». К счастью, множество библиотек в России уже пережили этот этап. А вот лаборатории — нет. 

Меня зовут Иван Балашов, в К2Тех я руковожу направлением Цифровое производство. «Бумажный синдром» — хроническое заболевание многих лабораторий в стране. Данные живут своей жизнью в разных углах, порождая ошибки, бесконечное дублирование и тотальную зависимость от «ключевых» людей. Поправить положение может LIMS (Laboratory Information Management System, система управления лабораторной информацией). Но я предлагаю посмотреть на нее не как на «еще одну программу», спущенную сверху, а как на инструмент для фундаментальных изменений. И вот главный парадокс: самый сложный вызов при внедрении — это не технологии, не формулы и не интеграция с приборами. Самый сложный вызов — это люди, их привычки и естественное сопротивление переменам. Давайте разберемся на примере нашего кейса, как сделать внедрение полезным. 

Привет, Хабр! На связи Данила Лопатин, системный инженер в К2 Кибербезопасность. Этой осенью мы провели большое исследование рынка. Один из главных итогов — 88% российских корпораций активно используют NGFW для защиты сетей. Несмотря на эффективность этого класса решений, по ряду причин оно не может единолично обеспечить полную киберустойчивость сети. Поэтому сегодня при выборе NGFW одним из приоритетов становится его возможность интеграции с другими СЗИ (NTA/NDR, NAC, VPN и т.д.). В том числе в условиях мультивендорной архитектуры.

Как ИБ-интегратор мы тестируем лучшие продукты на рынке. В этой статье мои коллеги — системные инженеры — Алексей Зорин и Захар Пенчев описали возможности UserGate NGFW в сочетании с Efros DO, который является ярким примером решения, интегрируемого со смежными СЗИ.

Привет, Хабр! Я Даниил Салман, техлид по контейнеризации. Эта статья написана по мотивам моего доклада для конференции DevOops. Разберёмся, как сделать такую ML-«песочницу», где Data Scientist пишет код, а всё остальное (установка драйверов, выделение ресурсов, деплой и тренировка модели, сбор метрик) уже настроено на бэкенде. Написали максимально просто и доступно, чтобы понять смог даже человек с минимальным погружением в тему. Идеи из этой статьи можно применять в любой инфраструктуре — важно лишь понимать основы: как работает k8s-кластер, Docker и python-фреймворки. Итак, поехали!

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

Именно в такой ситуации сейчас оказались сотни российских компаний. Им приходится выбирать из десятков доступных решений, и первый порыв — открыть сравнительную таблицу, где напротив каждой функции VMware стоит галочка. Хочется сохранить привычную функциональность, да и сами российские вендоры позиционируют свои продукты как полноценную замену VMware. Но такой подход не работает: простое сравнение по набору функций редко дает точное представление о реальной альтернативе. И у Lada, и у BMW есть руль, но дьявол, как известно, в деталях.

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

Привет, Хабр! Меня зовут Ильнар Зайнуллин, я системный инженер в К2Тех. Сегодня хочу поговорить о балансировщиках. Пока всё хорошо, о них вспоминают разве что при плановом расширении, очередной миграции или когда нужно красиво разрулить сертификаты. Когда же внезапно начинаются жалобы «подтормаживает», «отваливается», «иногда долго открывается» — балансировщик быстро становится «главным подозреваемым», даже если на самом деле виноваты сеть, backend или конкретный клиент.     

В этой статье рассмотрим три решения для закрытия проблемы с «главным подозреваемым»: F5 BIG-IP, Citrix NetScaler и Termidesk Connect. Если решения от F5 и Citrix хорошо известны на рынке, то Termidesk Connect — достаточно молодое решение от «Группы Астра». Релиз версии 1.0 состоялся весной 2025 года, под конец года вышел релиз 1.2 — его-то я и разберу в статье.

Привет, Хабр! Я Виктор Беляев, эксперт по беспроводным технологиям компании К2Тех. Прошло больше года с момента нашего первого большого обзора рынка Wi-Fi-решений. 

За это время крупные российские вендоры сделали заметный рывок вперед, расширили модельный ряд, нарастили производительность, добавили новые фичи и даже пополнили реестр РЭП (мы, конечно, протестировали новинки в нашей лаборатории). 

В России разрешили использование диапазона 6 ГГц (правда, пока частично), на горизонте отчетливо замаячил Wi-Fi 7. 

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

Привет, Хабр! На связи Михаил Косцов, руководитель практики вычислительной инфраструктуры и систем резервного копирования К2Тех. Сегодня хочу поделиться с вами результатами нашего первого знакомства с системой резервного копирования «Береста». Этот продукт отличается высокой скоростью работы, поддержкой многопоточности и иерархической схемой хранения. Производитель позиционирует «Бересту» как систему, способную решать сложные задачи в области резервного копирования и восстановления данных. Мы не могли пройти мимо и не протестировать такое решение. На что в действительности способна «Береста» — читайте под катом.

Сегодня потребности бизнеса растут так стремительно, что решения для унифицированных коммуникаций (UC) просто не успевают за ними. Аплайнсы — выделенные «железки» под конкретную задачу — очевидно устарели: масштабировать их сложно, обновлять страшно, а добавление новых функций напоминает скорее тест на выносливость. Я Владимир Сергеев, руководитель практики UC и ПО для совместной работы в К2Тех. Регулярно я сталкиваюсь с тем, как очередной апдейт превращается в персональную головную боль для ИT-отдела.

Решением, которое буквально спасло UC-инфраструктуру, стал Kubernetes. Теперь вместо тяжелых проприетарных коробок — легкие микросервисы. Вместо многочасовых простоев — обновления за минуты. Вместо страха перед будущим — быстрая реакция на любые бизнес-задачи. И никакого даунтайма для всей компании.

Давайте погрузимся в детали этого перехода: от неповоротливых «кирпичей» к динамичным контейнерам. Разберемся, почему страдать от обновлений больше не нужно. И посмотрим, так ли все радужно на самом деле.

У меня дома стоит Bluetooth-колонка в ванной. Руки там вечно мокрые и мыльные, поэтому включить звук дождя или музыку проще по событию, например, по голосовой команде. Конечно, можно поднять Home Assistant или написать небольшой Python-скрипт, который слушал бы датчики и управлял колонкой. Но в тот момент я работал с NiFi и решил проверить, справится ли он с бытовой задачей.

Оказалось, что это не только «enterprise ETL» инструмент, а еще и гибкая платформа, которая умеет работать с MQTT-брокером. Поэтому я настроил через него простую цепочку, и колонкой начал управлять не самодельный скрипт, а NiFi.

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

В Big Data подключение нового источника часто превращается в мини-проект. Требуется неделя разработки, набор уникальных скриптов, собственные форматы, исключения и обходные решения. Но когда пять источников превращаются в пятьдесят, инфраструктура начинает рассыпаться: форматы скачут, API капризничают, схемы дрейфуют, а поддержка становится бесконечным бегом с препятствиями.

Мы проходили через это несколько раз и поняли, что нам нужен фреймворк, который позволит предсказуемо, быстро и без зоопарка самописных ETL-процессов подключать новые источники.

Привет, Хабр! Я ведущий инженер-разработчик направления BigData & BI К2Тех Кирилл Гофтенюк. В этой статье расскажу, как устроен наш фреймворк на базе ADS.NiFi и Arenadata Prosperity. Покажу, как он работает, зачем нужен такой подход и что нам дал переход от хаотичных скриптов к управляемой архитектуре.