Привет, Хабр! Меня зовут Анжелика Захарова, я руководитель практик 1С и кибербезопасности K2 Cloud. Мы занимаемся инфраструктурными проектами, и значительная часть подразумевает подбор и развертывание серверных платформ под 1С.

В конце 2025 года к нам пришел заказчик из среднего бизнеса, который мигрировал с SAP на 1С, но не знал, что выбрать: облако или выделенный сервер, Intel или AMD, и, главное, сколько это будет стоить в эксплуатации. Мы взяли две платформы — Intel Xeon Gold 6548Y и AMD EPYC 9274F — и прогнали тест Гилева. Intel показал 60 баллов, AMD — 58. Казалось бы все, можно брать Intel и начинать развертывание…

А потом мы запустили закрытие месяца на реальной базе 1С:ERP. И AMD, который по Гилеву не сильно, но проиграл, оказался на треть быстрее.

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

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

Для тех, кто работал с ПО для управления бизнес-процессами, укажу на важный нюанс. В SAP есть встроенный инструмент сайзинга: по параметрам бизнеса (количество пользователей, объем транзакций, характер операции), который позволяет рассчитать, сколько именно железа нужно еще до старта проекта.

NAC-системы долгое время ассоциировались с “монстрами” вроде Cisco ISE или Aruba ClearPass. Но что, если собрать российский NAC из модулей «Медведь», «Лиса» и «Заяц», поставить их на страже сети и попробовать закрыть те же сценарии?

Привет, Хабр! С решениями NAC наша команда работает больше 19 лет. Последние годы особенно интересны: российский сегмент NAC заметно вырос, новые продукты появляются регулярно, а интерес со стороны заказчиков подталкивает нас на постоянный анализ рынка. 

Эта статья — часть цикла о NAC-решениях, которые мы разбираем в нашей сетевой лаборатории. На этот раз в фокусе Eltex NAICE — новичок в области контроля доступа, но далеко не новичок в мире сетей.  Разберёмся, как он устроен, какие задачи реально закрывает и насколько уверенно чувствует себя на фоне более привычных NAC-систем. 

Привет, Хабр! На связи Владислав Пермяков, ведущий пресейл-инженер К2 Кибербезопасность.

Давайте честно: в картине мира среднестатистического инженера любой человек с приставкой Sale скорее вызывает легкое раздражение, чем симпатию. Не потому, что «сейлы плохие», а потому, что красивая коммерческая идея слишком часто не выдерживает столкновения с реальностью. Вот, например, приходит радостный сейл, кладет на стол подписанный контракт со словами: «Мы продали им весь наш портфель!» Ты открываешь спецификацию, смотришь на инфраструктуру заказчика и понимаешь, что такие костыли не взлетят. Устаревший парк серверов, каналы связи не потянут трафик, а совместимость с легаси-софтом никто не проверял. Но сейл уже оформляет новую сделку, а тебе нужно заставить работать решение, которое технически не подходит под задачи клиента.

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

Я год экспериментировал с on-premise Copilot — прямо над нашими разработчиками, — чтобы проверить: а правда ли эта штука разгоняет разработку на десятки процентов? Делюсь реальными метриками скорости и точности, разбираю, как оно работает на примере нашей инсталляции, и показываю результаты. По пути расскажу про все подводные камни: где ИИ стал турбоускорителем, а где подставил подножку и превратился в скрытую ловушку.

Привет, Хабр! На связи Владимир Симонян, эксперт по развитию мультимедиа-решений К2Тех.

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

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

Иногда разговоры о технологиях начинаются не с выхода новых девайсов или очередного релиза, а с фразы: «А помнишь BlackBerry?». Сегодня эту компанию знают не все, но в начале 2000-х она была стандартом, а не мемом. Смартфон BlackBerry ценили за предсказуемость, надежность и контроль. Почта доходила всегда,а связь работала даже при слабом сигнале.

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

«Где мои логи — в /var/log/messages, /var/log/syslog или только в journalctl?» — этот вопрос рано или поздно задает себе каждый инженер, который вынужден переключаться между разными дистрибутивами: Ubuntu, CentOS, Alpine, корпоративные Unix системы. 

Типичный сценарий: вы заходите на сервер, ищете /var/log/messages, а его или нет, или он есть, но journalctl показывает гораздо больше событий, чем файл. 

Иногда сервер внезапно начинает сильно использовать CPU, и в итоге причиной оказывается агрессивное логирование. 

Если к этому добавить разнородный парк, где рядом с Ubuntu живут динозавры на AIX и Solaris, путаница приобретает глобальный характер. 

Сейчас мы живем в эпоху «двоевластия»: systemd‑journald уже стал стандартом де‑факто, но rsyslog все еще присутствует во многих дистрибутивах по инерции или ради совместимости. Эта статья для инженеров, которые хотят понимать, кто именно пишет логи в Linux, почему они дублируются, где теряются CPU и I/O, и как настроить логирование так, чтобы диск не превращался в помойку. 

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

Привет, Хабр! На связи Аскар Добряков, ведущий эксперт направления защиты данных и приложений в К2 Кибербезопасность. Мы занимаемся всеми направлениями кибербезопасности, в частности защитой веб-приложений. За годы работы я насмотрелся на всякое: конфиг валиден, reload прошел, мониторинг зеленый, а на контрольном прогоне прилетает 502 на проде, auth_request сыпет пятисотками при живом бэкенде, или браузер закэшировал ошибку и упорно показывает 403 спустя часы после фикса. Причем не всегда это можно быстро исправить на уровне приложения.

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

Я собрал три таких кейса из своей практики, разобрал симптомы и диагнозы, показал рабочие конфиги. А чтобы читалось легче, завернул все в сквозную метафору. Итак, давайте смешаем коктейль.

Привет, Хабр! На связи Александр Усов, системный инженер в K2Tex. В своей предыдущей статье я уже делал подробный обзор фич ALD Pro и их особенностей, с которыми регулярно сталкиваюсь. Сегодня хочу поделиться тем, чему мы учим администраторов заказчиков: как реально эксплуатировать эту систему, а не просто развернуть и оставить на холостом ходу. Разберу, как устроены «расширенные атрибуты» и почему следует избегать одинаковых названий отделов в оргструктуре, какую функциональность ALD Pro унаследовал от FreeIPA, а в чем превзошел, и каким образом эффективнее организовать журналирование событий.

Привет, Хабр! Эту статью пишет авторский коллектив Центра экспертизы по комплексному сервису К2Тех: я, Пётр Михнюк, руководитель группы инженеров по поддержке системного ПО, и мои коллеги Александр Овчинников, старший инженер по поддержке вычислительного оборудования, и Алексей Яковлев, руководитель практики ИТ‑мониторинга. У нас на поддержке около 550 клиентов из сегмента enterprise, многие с географически распределенной инфраструктурой, и практически все они так или иначе опираются на Zabbix или его наследников.​

По нашему опыту, главная угроза для эффективного мониторинга — иллюзия контроля. Часто бывает так, что система развернута, графики рисуются, алерты шлются, но команда тонет в сотнях уведомлений и не успевает ловить действительно важные события: вместо одного «критического инцидента» получаются десятки разрозненных тикетов. При этом проблемы с лавиной оповещений, тарированием порогов и общей логикой мониторинга почти не зависят от того, используете ли вы «голый» Zabbix или его форки вроде «Пульс», Glaber или UDV ITM. Учитывая, что в большинстве случаев «наследием» наших клиентов является именно Zabbix, мы будем опираться на конкретные примеры из работы с ним. Под катом — не теория, а наши подходы и примеры: как перестать тонуть в алертах и превратить Zabbix в инструмент, которому можно доверять.

В больших инфраструктурах Kubernetes не живёт сам по себе: вокруг него выстраивается экосистема со своими дефолтами, ограничениями и точками отказа. В нее входят CNI, ingress-контроллеры, системы мониторинга, бэкапов, политики безопасности, GitOps и десятки других компонентов.

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

Инженеры практики контейнеризации, виртуализации и частного облака К2Тех изучили особенности эксплуатации четырех российских платформ: «Штурвал», Nova Container Platform, «Боцман», Deckhouse Kubernetes Platform. Результаты сравнения разложили по полочкам в таблицах – их вы найдете в статье.

Мы отказались от формального деления команды на L1, L2 и L3. Разрешили инженерам брать задачи независимо от грейда. Не паникуем, если SLA горит красным. И знаете что? Это работает.

У нас в К2Тех есть собственный Центр экспертизы по комплексному сервису, который объединяет все направления техподдержки. От инженерных систем до инфраструктуры и ПО. Ну и конечно же, поддержку ИБ. Меня зовут Олег Лунгу, я руководитель группы инженеров технической поддержки К2 Кибербезопасность (входит в К2Тех). Сегодня расскажу, как вырастил команду с нуля до 30+ спецов, эффективно решающих задачи, которые мучают клиентов месяцами.

Представьте: вы закрыли периметр межсетевыми экранами, поставили антивирусы на все хосты, но вдруг понимаете, что любой человек с ноутбуком может прийти в офис, воткнуться в розетку и оказаться в вашей внутренней сети. Или сотрудник возвращается из командировки с просроченными обновлениями Windows, становясь идеальным вектором для атаки. Контроль доступа (NAC) закрывает именно эти бреши в защите сети. 

Тема NAC сейчас сильно актуализировалась. Его ставят уже не только для защиты Wi-Fi (как наиболее уязвимой среды), но и в проводных сетях. А значит пришло время обновить наш первый обзор российских NAC-решений. 

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

Привет, Хабр! Делюсь ниже статьей моего коллеги Игоря Резцова, ведущего системного инженера в К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 — это не продукт, который решит ваши проблемы, а партнер, с которым нужно работать совместно. И что будет, если к этому не подготовиться.