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

IWANT - наш собственный fashion-магазин. Несколько лет он жил на InSales: на старте это правильный выбор: быстро, без разработки, всё из коробки. Но в какой-то момент мы уперлись в потолок платформы: каждый нужный модуль - это либо платное приложение, либо «так нельзя». Мы посчитали и решили перевезти магазин на собственный движок.

Это не история «платформы плохие, пишите своё». Это разбор конкретного переезда: что переносили, как устроен ETL из выгрузок InSales, на каком стеке собрали и почему именно на нём, какие модули пришлось писать самим, как прошёл катаут без простоя и кому такой переезд реально нужен, а кому нет.

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

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

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

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

Показана реализация на SQL в ClickHouse с применением паттерна Islands & Gaps для выделения инцидентов во временных рядах.

Бывает такое: времени в обрез, а нужно срочно сделать продажу или подготовиться к созвону по проекту. На что смотреть? Какие выводы делать? Без разговора с собственником всё кажется тёмным лесом, и непонятно, что вообще обсуждать.

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

В статье будет много практики, чёткий алгоритм и разбор реального кейса – фитнес-клуба из Тулы, который я выбрал для анализа случайно.

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

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

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

На протяжении более 80 лет основной принцип авиационной инженерии был прост: чтобы уменьшить аэродинамическое сопротивление, поверхность объекта должна быть гладкой. Эта предпосылка основывалась на результатах исследования 1940 года, проведённого японским учёным Ичиро Тани, который продемонстрировал взаимосвязь между шероховатостью поверхности (показателем состояния обработанной поверхности) и переходом к турбулентному течению, утверждая, что шероховатость поверхности, которая была неизбежна при технологиях производства того времени, препятствовала реализации ламинарного течения.

Однако в 1989 году Тани переосмыслил экспериментальные данные по трубам с шероховатой поверхностью, полученные инженером-гидродинамиком Йоханом Никуласе в 1930-х годах, выдвинув предположение, что «шероховатость не обязательно способствует только переходу к турбулентному течению и увеличению сопротивления потоку». Развивая эту идею, исследовательская группа под руководством Ясуаки Кохамы из Тохокского университета в 1990-х годах продемонстрировала, что волокнистые шероховатые поверхности, имеющие мелкие волокнистые неровности, при определённых условиях способствуют задержке перехода.

Если и закрывать весну, то только так: с ростом до 150 тысяч клиентов, увеличением числа агентов в четыре раза, новыми локациями и дата-центрами. 

При нынешнем масштабе решили говорить чаще про то, что под капотом: сети, переезды, железо. Релизов, впрочем, тоже хватило: CDN, агенты с поиском и генерацией, Docker Hub в App Platform и Нью-Йорк.

Все о прошедшем ласковом мае — в этом дайджесте ↓

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

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

Мы уже писали о том, как правильно смигрировать ЦОД: на что обратить внимание при планировании миграции и проектировании целевой архитектуры (тут и тут), как осуществить сам переезд максимально безболезненно (тут).

Теперь расскажем о том, как это бывает в реальной жизни – история одного проекта миграции глазами руководителя проекта. Человек с богатым, более чем 10-летним опытом, с сертификатом PMP и десятками реализованных проектов за плечами – казалось бы знает об управлении проектами все. Однако реальность показывает, что абсолютно все предусмотреть невозможно.

Пока вокруг AI все в основном обсуждают модели, бенчмарки и очередных «автономных агентов», параллельно растёт более прикладная часть экосистемы — готовые skills под конкретные задачи. И Hermes Skill Hub здесь особенно интересен.

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

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

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

Привет, Хабр. Меня зовут Василий Щитов. Я старший инженер в команде CI-инфраструктуры ВКонтакте. 

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

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

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

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

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

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

Формально BI появился. Но способ управления почти не изменился.

Я не пишу это как претензию к бизнесу или к конкретным BI-инструментам. Обычно причина не в одном неудачном решении, а в том, что техническая часть проекта и управленческая часть проекта существуют отдельно друг от друга. DataLens, Power BI, Tableau, Metabase или самописный фронт могут быть вообще ни при чём. Отчёт может быть быстрым, аккуратным и полезным для просмотра, но при этом так и не стать частью процесса, в котором принимаются решения.

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

Одна из главных автоматизаций в BIM – создание объектов. Разбираем создание объектов через Renga API шаг за шагом.

Я считаю, что попытки сделать линукс системой для любого - не лучшая идея. Она может погубить много проектов, и вот почему.

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

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

Меня зовут Руслан Рахимкулов, я отвечаю за развитие качества сервиса в YADRO. За годы работы в сервисном управлении я пришел к выводу, что сервис-менеджер — одна из самых недооцененных ролей в IT. Часто его воспринимают как координатора или владельца отчетности. На практике же сервис-менеджер становится человеком, который соединяет продукт, сервис, процессы и технические команды в единую систему эффективного взаимодействия и достижения результата для клиента.

В конце статьи расскажу, кого мы ищем в команду и какие вопросы задаем кандидатам на позицию сервис-менеджера.

Мы построили мультиагентную RAG-систему на open-source моделях, прошли путь от наивного RAG до ReAct-агента с собственным бенчмарком — и готовы рассказать, где набили шишки. Внутри: две итерации архитектуры, честное сравнение через RAGAS-метрики и ответ на вопрос, почему «просто взять фреймворк» не работает. Будет полезно всем, кто строит RAG для корпоративных знаний или только собирается.

Первую часть статьи вы можете прочитать тут - От Naive RAG до ReAct-агента: как мы строили корпоративного AI-помощника на open-source моделях (часть 1)

Написать эту статью, меня натолкнул другой пост на хабре: Как я перестал переключать VPN и разделил рабочий и личный интернет архитектурно

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

Вся суть статьи сводится к: установке Windows 10 на виртуальный сервер (VPS), настройка и подключение RDP. Возможность подключаться к серверу с мобильных устройств и в целом работать через RDP в дороге (если нужна Windows).

В статье представлен разбор создания CRM-системы, разработанной с применением искусственного интеллекта для ускорения кодинга и архитектурного планирования. Проект представлен как будущий полигон для построения хорошего фреймворка для автотестирования с помощью Python.

Я продолжаю освещать работу с USB на Raspberry Pi Pico. В текущей статье хочу привести пример, как можно использовать Raspberry Pi Pico в качестве загрузочного USB-устройства.

Каждый гордый обладатель 3D-принтера проходит через несколько этапов. Вначале эйфория вида «я напечатал кораблик!». Потом осознание того, что создавать получится лишь то, что уже выложено в Сети. На этом многие останавливаются, так как учиться моделировать самому долго и достаточно сложно. И вот именно это часто становится фактором покупки 3D-сканера. Бюджетных вариантов на рынке навалом — кажется, что дело простое: поводи девайсом вокруг предмета — получи готовую модель. Распечатай — и вот она, копия физического объекта у тебя в руках.

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

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