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

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

Мы в 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 под длительной смешанной нагрузкой, близкой к реальной эксплуатации.