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

Меня зовут Руслан Махмудов, я — архитектор решений в Альфа-банке. Хочу рассказать, как мы в Альфа-Банке решали наши архитектурные проблемы, в результате чего создали своего монстра Франкенштейна (в хорошем смысле) — систему RSM, без которой в настоящий момент работа всего архитектурного подразделения фактически невозможна.

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

По словам Юрия Николаева, директора по продажам Битрикс24, компании ежегодно тратят на CRM миллионы рублей, но используют лишь часть возможностей. Для многих она остаётся интерфейсом, который красиво выглядит, но мало что меняет в работе. Чтобы понять, насколько система реально помогает бизнесу, стоит пройти честный чек-ап из десяти вопросов.

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

Привет, Хабр! В попытках отчаянно найти подработку, которую можно было бы совмещать с учебой, листал я агрегатор стажировок, где и наткнулся на набор от Яндекса. Решив, что терять мне всё равно нечего, я быстро кликнул по ссылке, заполнил анкету, и буквально через минуту мне на почту пришло письмо с приглашением решить тестовое задание. Я подумал, что вечер наконец-то обещает быть интересным, заварил чаёк и уже собрался спокойно чилить следующие несколько часов, аристократически посёрбывая и иногда тыкая пальцем по клавиатуре.

Боже, как я ошибался.

Woyax AI Process Auditor — ИИ-агент для автоматического аудита бизнес-процессов. Бот проводит серию интервью с сотрудниками компании через мессенджер, выявляет рутину и узкие места, извлекает структурированные инсайты и формирует отчёт с рекомендациями по ИИ-автоматизации. No-code AI-агент на базе n8n, RAG, Qdrant и нескольких LLM-провайдеров — построенный на одном VPS в Docker Compose.

Об этом проекте — две статьи. Эта, техническая — про архитектуру, стек, workflow и процесс разработки. Вторая, на vc_ru — про бизнес-задачу, результаты и практическое применение: Воякс - аналитик ИИ-автоматизации. Читать можно в любом порядке, статьи дополняют друг друга.

Obsidian давно перестал быть просто «заметочником» — для многих это полноценная рабочая среда, где живут задачи, проекты, люди и знания. Но как только дело доходит до структурированных данных — книг, контактов, курсов — пользователи неизбежно упираются в вопрос: чем это организовать? Долгое время единственным вменяемым ответом был плагин DB Folder. Затем Obsidian выкатил встроенный Bases — и сообщество разделилось. В этой статье я разберу оба инструмента на конкретном примере: создам базу данных книг в каждом из них, сравню возможности и расскажу, какой из них и для кого подойдёт лучше. Если тема управления знаниями в Obsidian вам близка — заглядывайте в мой тг-канал, там я разбираю подобные вещи регулярно.

Привет, Хабр! Меня зовут Виктория Мохирева, я консультант SAP MM. Сегодня расскажу о том, как мы с командой решили колоссальную задачу инвентаризации — пересортицу товаров — с помощью интеграции SAP с большой языковой моделью (ИИ).

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

В сообществе часто пишут о том что KV-cache hit rate - один из главных приоритетов при оптимизации стоимости. Manus в той-самой статье про context engineering и своего агента, TikTok в кейсе про оптимизацию AI-агента для тестирования, AiSDR в статье про перестройку шаблонов генерации писем.
Стало интересно стало: а как это считается у MaaS-провайдеров? Я знаком со скидкой за кэш токены, но никогда не садился детально разбирать экономику кэша у OpenAI, Anthropic, Gemini, DeepSeek - с цифрами, сценариями, сравнением.

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

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

Возможно вам знакома ситуация, когда отчеты по SLA 99,9%, заявки закрываются в срок, но при этом пользователи жалуются, что работать невозможно. Показатели в системе и реальность расходятся — это как мерить среднюю температуру по больнице. 

Меня зовут Авдей Мартынович, более 20 лет занимаюсь поддержкой ИТ-инфраструктуры. В статье расскажу, почему классического SLA недостаточно, как мы в ALP ITSM пришли к XLA и что из этого реально работает.

Привет! Меня зовут Владимир и я специалист по тестированию на проникновение. Зимние праздники и часть февраля я провёл за сдачей CPTS. Что это? Как это? сильно ли изменился экзамен после мая 2025? Разберёмся в этой статье.

Хранение данных в S3 часто воспринимается как нечто простое: загрузили объект, при необходимости обновили или удалили. Но на практике это хранилище обычно используется в сценариях, в которых цена ошибки слишком высока. Вы же хотите случайно удалить или перезаписать бэкапы, логи, артефакты сборки или данные, подпадающие под регуляторные требования. Чтобы защититься от подобных ситуаций, в S3 есть механизм Object Lock.

Всем привет! Меня зовут Клюев Алексей, я старший разработчик S3-совместимого объектного хранилища в Selectel. В этой статье мы разберем, как работает Object Lock, какие способы блокировки объектов он поддерживает, чем отличаются режимы удержания и какие ограничения важно учитывать при работе с ними. В качестве примеров будем использовать язык Go и aws-sdk-go v2.

Java-разработчики годами жили по принципу «Everything is an object». И всё бы хорошо, если бы за это нам не приходилось платить «налогом на объект»: каждый раз, когда вы создаёте простой класс из двух полей int, JVM бережно дописывает к нему тяжёлый заголовок, упаковывает в ссылку и разбрасывает по куче, заставляя процессор страдать от постоянных промахов кеша.

Мы привыкли к этому компромиссу. Мы научились использовать примитивные коллекции и костыли, чтобы выжать производительность там, где объектная модель Java начинает буксовать. Project Valhalla призван изменить сами правила игры.

История фронтенда хорошо показывает, что инструменты редко исчезают мгновенно. Чаще они проходят понятный цикл: сначала решают конкретную проблему и быстро набирают популярность, потом становятся привычной частью стека, а со временем уступают место следующему подходу. Примерно так развивается и CSS-in-JS. Когда он появился, это выглядело логичным шагом: стили рядом с компонентами, темы, токены и удобная интеграция с React. Со временем стало ясно, что у этой модели есть и ограничения — стили генерируются в рантайме, усложняется SSR, а в больших приложениях начинают накапливаться накладные расходы. Появились попытки сделать CSS-in-JS легче и быстрее. Одной из них стал Stitches: он сохранил удобный DX и заметно сократил рантайм. Но развитие проекта остановилось, а требования к фронтенду продолжают расти. Поэтому всё чаще обсуждают другой подход — перенос генерации стилей на этап сборки. В этой логике и появился StyleX.

Многие мои читатели называли меня циничным, когда я делал заявления наподобие «вам всегда нужно угождать своему менеджеру» или «большие технологические компании имеют право решать, над какими проектами вы работаете». Алекс Веннерберг привёл веские доводы того, что я циник, в своём посте Software Engineers Are Not Politicians («Разработчики — это не политики»). Вот некоторые выдержки из него:

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

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

Я понимаю, почему люди так думают. Но мне нравится работать в больших технологических компаниях! И я вижу в себе профессионала, решающего важные задачи. А ещё я считаю, что лавирование в компании с целью реализации для пользователей новых фич или улучшений — это превосходный (если не лучший) способ выполнять свою работу качественно.

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

Проект PhotoMentor создавался как ИИ-ментор для фотографов. Механика простая: пользователь загружает снимок, а под капотом Gemini выступает в роли арт-директора — анализирует композицию, работу со светом, цветовую гармонию и выдает детальный фидбек с оценкой.

С главной проблемой Vision-моделей я столкнулся в первый же день закрытых тестов. Я скормил Gemini свой тестовый снимок: крупный портрет собаки, положившей морду на лапы.

Модель уверенно выдала:

В поддержке было 148 инцидентов по одной проблеме, а в бэклоге разработки — всего 3 дефекта

Для разработки проблема выглядела редкой. Для поддержки — массовой

Разбираем, почему инциденты не доходят до продукта и как выстроить процесс от обращения пользователя до релиза исправления

Представьте: менеджер по продажам уходит из компании. Уходит со скандалом, забрав часть клиентской базы. Через три месяца он всё ещё состоит в рабочем Telegram-чате отдела, читает обсуждения новых сделок, видит, кто из клиентов недоволен. Использует эту информацию или просто злорадствует — неважно. Важно то, что компания об этом не знает.

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

Первое, к чему стоит привыкнуть: творить каждый день. Хоть по пять минут, хоть по часу, но творить. Ждать вдохновения не следует. Вдохновение - это для мажоров с большим количеством свободного времени. Придётся выдавливать из себя, по-чеховски, раба по капле. Для этого своё хобби придётся носить с собой в сумке/рюкзаке/клатче/редикюле (нужное подчеркнуть).

Платные модели embedding не гарантируют качество на малоресурсных языках. На задаче кроссязыкового сопоставления EPG-заголовков (EN/RU/HY) бесплатная LaBSE набирает R@1 = 0,83, а OpenAI text-embedding-3-large -- 0,21. Протестировано 19 моделей, код и данные открыты.

Представьте, что у вас в руках легендарный, но безнадёжно устаревший актив. 

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

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

Но они выбрали второй вариант.  

Дальше вскрылась проблема нагрузки. Новые бани требовали 20000 вёдер воды в час, а городской водопровод падал по тайм-ауту и блокировал других пользователей. Чтобы уйти от зависимости от внешнего вендора, пришлось строить собственную инфраструктуру — прокладывать водовод от Бабьегорской плотины и бурить скважины. Внедрили тройное резервирование: городская вода + своя труба + скважины. Внутри здания реализовали переход на мазут и установку гигантского теплоаккумулятора (12 тонн чугуна). Топка ночью обеспечивала отдачу тепла днём.

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

Сами бани давали лишь 60% выручки, допмонетизация шла через сервисы аренды жилья, ресторанов и медицины. Главным вызовом стала балансировка продукта: нужно было сделать так, чтобы «бесплатные пользователи» (отделения за пять копеек) не распугали «премиум-подписчиков» (нумерные бани) и при этом инфраструктура выдержала общую нагрузку.  

Оправдан ли был такой риск? История показала, что да.