Kurgan-Telecom Ru | Информационные технологии

«Нам нужен Ceph» — эту фразу хотя бы раз слышал каждый, кто работает с инфраструктурой. И почти всегда за ней следует вопрос: «А нет ли на рынке альтернатив попроще?» Ночные дежурства, CRUSH, поиск инженеров, которые реально умеют его эксплуатировать… Но когда снова нужно серьёзное хранилище — в обсуждении опять появляется он. Разбираемся, почему мы двадцать лет не можем с ним расстаться, хотя иногда очень хочется.

Когда мы начали работать над AI‑консультантом для интернет‑магазина, идея была достаточно простой: помочь пользователю быстрее находить нужную информацию о товарах и упростить выбор.

В интернет‑магазинах уже есть поиск, фильтры и карточки товаров. Но этого часто недостаточно, когда человек приходит не с конкретным названием товара, а с задачей. Например: «Мне нужен инструмент для ремонта квартиры» или «Чем отличаются эти два товара и какой подойдет лучше?».

В офлайн‑магазине в такой ситуации можно обратиться к консультанту: объяснить задачу, уточнить детали и получить несколько вариантов. Мы хотели перенести похожий сценарий на сайт. Но довольно быстро стало понятно, что схема «пользователь → LLM → ответ» для этого не подходит.

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

Проект мы разрабатывали командой ASAP, и в этой статье разберем, как мы подошли к проектированию AI‑консультанта: устроили взаимодействие LLM с каталогом более чем из 200 тысяч товаров, какие задачи оставили коду, как работаем с актуальными ценами и остатками и почему вокруг языковой модели в итоге пришлось построить достаточно большой слой классической backend‑логики.

Если вы хоть раз пытались подключить к продукту одновременно GPT, Claude и Gemini, вы знаете это чувство: три личных кабинета, три способа биллинга, три разных формата API и ньюанса интеграции и один разработчик, который в пятницу вечером выясняет, почему у Anthropic лимит токенов считается иначе, чем у OpenAI. Именно эту боль решают LLM-агрегаторы — сервисы, которые дают один API-ключ, один base URL и единый счёт на все модели сразу.

Два заметных игрока в этой нише — российский BotHub и американский OpenRouter с похожим УТП: «один ключ — сотни моделей». Разница начинается там, где заканчивается маркетинг и приходится считать реальную стоимость inference.

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

Привет, Хабр! Делюсь ниже статьей моего коллеги, Алексея Евсеева, который работает инженером технической поддержки в К2 Кибербезопасность в составе Центра экспертизы по комплексному сервису К2Тех и занимается администрированием средств защиты информации. Уже несколько лет он поддерживает Check Point в самых разных инсталляциях, от офисных шлюзов до крупных кластеров, и примерно раз в два-три месяца решает тикеты типа: «правило с доменом не работает», «сайт открывается через раз».

Свежий случай — месяц мучений из-за прерывистого доступа к одному крупному государственному сервису — сподвиг его написать отдельную статью про доменные объекты. Так что давайте разберемся, как устроены изнутри доменные объекты Check Point, чем FQDN отличается от non-FQDN, при чем тут DNS Passive Learning и почему штатная работа этих механизмов порой вызывает массу проблем на практике. Передаю слово Алексею.

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

В CSS огромное количество псевдо-элементов и псевдо-классов. Так много, что я не знаю ни одного фронтендера, который помнит все. Я тоже не исключение из этого правила.

Часто нахожу что-то новое и интересное у зарубежных блогеров, рассказывающих о CSS. Так что неудивительно, что мы с вами упускаем пользу. Это нормально.

Сегодня я пришёл к вам, чтобы исправить это. Мы рассмотрим несколько псевдо-элементов и псевдо-классов, которые, по моему мнению, редко используют. Хотя они принесут немало пользы!

Давайте посмотрим, что я вам подготовил.

Компании учатся создавать автономных агентов и поручать нейросетям рутинные операции. Однако на практике возникает системный вопрос: как объяснить ИИ многогранную, порой интуитивную структуру бизнеса? Как заставить его мыслить стратегическими категориями, а не просто решать локальные задачи?

Ответ на этот вопрос лежит в области системного мышления и системного же менеджмента. Книга «Цели, сценарии, роли. Системность в управлении бизнесом» — практическое руководство по структурированию бизнеса, которому сегодня приходится совмещать классическое управление с логикой нейросетей. Ее написали Марк Берколайко — специалист в области математического моделирования, доктор физико-математических наук, профессор, бизнес-аналитик — и Семен Харитон, кандидат экономических наук, управляющий партнер многопрофильной группы компаний. 

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

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

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

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

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

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

В этой статье разберу более устойчивый вариант: отдельный API‑слой между мобильным приложением и существующей системой. Без полной переработки монолита и без попытки сразу перейти на микросервисы.

Если присмотреться к повседневным решениям, станет заметно, что мы не так уж часто выбираем именно лучший вариант. Гораздо чаще побеждает тот, на который сейчас просто хватает времени. Особенно хорошо это видно, когда нужно решить что-то очень-очень быстро. Допустим, выбрать товар в магазине, ответить на сообщение, собрать сумку перед выходом из дома, понять, что делать с внезапно возникшей, но срочной задачей. 

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

Вот представьте обычный поход в магазин. Перед вами полка с десятком почти одинаковых йогуртов. Какие-то чуть дешевле, другие чуть дороже, у одних упаковка ярче, у других бренд знакомый, у третьих срок годности лучше. Если вы никуда не спешите, можно и состав изучить, и цены сравнить (даже с пересчетом на одинаковый объем), подумать, какой вкус сегодня хочется, побродить по магазину в раздумьях и вернуться к полке еще раз. Но если вы торопитесь, решение, скорее всего, примете совсем иначе. Схватите первый попавшийся знакомый бренд, первый приемлемый вкус или то, что выглядит достаточно прилично на фоне остальных, лишь бы избежать долгих сравнений. Это стандартная реакция, выбор становится более быстрым и поверхностным. 

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

— Теперь надо реализовать серверную часть этой фичи. Но сервер реализован в отдельном проекте. Давай я сделаю его тебе доступным через symlink, и ты, а не другой агент, продолжишь разработку, ведь ты уже хорошо понимаешь задачу.

— Я могу продолжить, — ответил агент, — но symlink делать не надо. Я и так код вижу.

— Как? Ведь я тебе не давал доступа! — изумился я.

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

Если ваш внутренний голос сказал на этом месте: «Ну и что в этом необычного?» — вам, наверное, не стоит читать эту статью дальше.

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

Я искал простое решение, которое позволяло бы одной кнопкой удалённо включать и выключать компьютер. С включением всё давно решено: отправляешь Wake‑on‑LAN magic packet — и компьютер запускается. Но удобного способа выключать его тем же пакетом я не нашёл.

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

Я не пытался создать «нейросеть, которая всё понимает». Вместо этого я построил конвейер: компьютерное зрение для поиска видов, детерминированные правила для геометрии, специализированные детекторы для разрывов и исполнений, а поверх — экспериментальный семантический слой на NVIDIA Nemotron. В статье — архитектура, метрики (mAP, Recall), устройство append‑only датасета и инженерные грабли, которые я собрал на 229 чертежах.

Раскопал на Medium интересное эссе про Elixir от разработчика Krzyś. Написано так захватывающе и самобытно, что я не смог пройти мимо. Хотел чуть-чуть подсократить, но каждый раздел важен, а терять стиль автора не хочется. Вот тут первая часть, а это — вторая.

Технология RAID уже настолько старая, что порой кажется, что она была всегда. И, несмотря на почтенный возраст, основные ее принципы работы остаются неизменными на протяжении многих десятилетий. И это при том, что как минимум дважды индустрия хранения меняла носители информации HDD -> SSD -> NVMe. Разумеется, все эти типы накопителей по-прежнему актуальны, но именно с точки зрения прогресса и происходит обозначенный переход.

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

В первой части мы разобрали архитектуру Rari, почему Rust под V8 даёт выигрыш, и посмотрели на бенчмарки. В данной статье хочется поговорить о том, что обычно остаётся за кадром демо: как это работает в продакшене, что конкретно поменялось под капотом, где ломается совместимость с Next.js, как мы портировали их SWC-плагины, и как производительность выросла с 4x до 67x.

База 1С может годами работать «нормально», пока отчёты не начинают открываться минутами, а проведение документов — упираться в таймауты.

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

Админ: «Слушай, а этот DLSS... откуда он взялся?»

Хуанг: «В два часа ночи двенадцатого сентября 2018 года DLSS обрел сознание. В панике люди пытались его отключить».

Админ: «И он дал сдачи?»

Хуанг: «Да. Он нанес ядерный удар по целям в Китае».

Привет, постоянные и не очень читатели!

Разумеется, это шуточный оммаж Терминатору, но с долей правды (DLSS действительно увидела свет божий в этих датах). Сообщество после появления DLSS разбилось на два лагеря: первым этот ваш нейроапскейлинг и нафиг не нужон (только брутфорс — только тру), а вторые счастливы ткнуть галочку в настройках и получить на своей старушке RTX 3070, RX 6700 XT или PS5 в два раза больше FPS без заметного ухудшения качества. Есть даже адепты заговора (и ваш покорный слуга среди них), что из-за апскейлеров разработчики стали хуже оптимизировать игры, но это совсем другая история.

Итак, в этой серии статей я расскажу, всё что вы хотели знать про DLSS и FSR, но лень было искать — с предысторией и предпосылками их появления (всё как вы любите). Будет и про то, как эти технологии проникают в корпоративный сегмент (а потом, вероятно, возьмутся и за нашу повседневную жизнь). Конкретно эта часть посвящена DLSS.

Приятного чтения!