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

Сколько не оптимизируй бизнес-процессы, в них всегда остается какое-то узкое место, которое может застопорить всю работу. Знакомая ситуация? Но самое неприятное, что этот «засор» иногда очень сложно найти. В обновлении 1.9 платформы BPMSoft, о нем мы рассказывали вот тут, появилась тепловая карта бизнес-процессов (БП). Это инструмент визуальной аналитики, позволяющий оценивать эффективность исполнения БП с помощью цветовой индикации: от «холодного» к «горячему». С его помощью можно анализировать всю ветку процесса или его отдельные элементы за выбранный период – по среднему времени выполнения, количеству ошибок и нагрузке на конкретные узлы. Я, Павел Копельман, product owner направления BPMS в компании BPMSoft (ИТ-холдинг LANSOFT) расскажу о том, как эта технология работает и где может реально помочь.

Привет! Меня зовут Руслан, я инженер в отделе развития процессов безопасности в YADRO. Сегодня поговорим об открытом исходном коде (open source). В мире современной разработки он используется практически в каждом приложении: open source-библиотеки, фреймворки и компоненты помогают ускорить разработку и сделать ее гораздо более удобной. 

Но есть проблема: каждая зависимость — это не только «плюшки», но и дополнительные риски. Если в open source, который вы используете, появится уязвимость, придется срочно ее устранять — и вряд ли на это уйдет пара минут. Еще есть юридические риски — например, автор open source может направить вам запрос на раскрытие той части кода, которую вы модифицировали, а для вас это может оказаться конфиденциальной информацией. В итоге предоставить часть кода вы не сможете, а другая сторона будет иметь полное право обратиться в суд.

Таких рисков как раз и помогает избежать анализ открытого исходного кода (Open Source Analysis, OSA). Давайте разбираться, что это такое и как его выполнять.

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

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

Команда VK Cloud перевела статью, в которой разбирается, как развернуть дезагрегированный инференс в Kubernetes. Здесь мы посмотрим на разные решения экосистемы, как они работают в кластере и что дают «из коробки».

Если вбить «как стать go разработчиком» в поисковую строку, можно найти миллион курсов по данному направлению. Проблема в том, что почти все курсы являются платными и, как правило, стоят несколько десятков, если не сотен тысяч рублей. 

Чтобы разбавить данную ситуацию, мы с Go-разработчиком Валерием Лаптевым подготовили для вас программу обучения «Go-разработчик с нуля», которая состоит только из бесплатных курсов.

Привет, Хабр! Сегодня мы поговорим о реализации базовой версии эмулятора консоли NES на отечественном микроконтроллере К1921ВГ1Т и даже поиграем на нём в игры.

В ML легко перепутать аккуратное число с честной вероятностью: модель выдаёт predict_proba = 0.9, и кажется, что событие произойдёт в 90% случаев. Но это не всегда так.

В статье разбираем, почему выход модели может быть просто внутренней оценкой уверенности, чем калибровка отличается от AUC, как увидеть смещение через reliability diagram и Brier score — и когда вероятности нужно обязательно калибровать, прежде чем использовать их в бизнес‑решениях.

Привет, Хабр! На связи Юрий Власенко, Senior DevOps инженер в РТЛабс. Сегодня я расскажу о том, как наша команда автоматизировала сложный, бюрократизированный и многоуровневый релизный процесс компании и превратила его в тестируемый объектно-ориентированный код на Groovy (Jenkins).

Когда пользователь на сервере-publisher логической репликации загружает данные через COPY, PostgreSQL вставляет строки компактно, много строк в одной вставке, задействуя механизм heap_multi_insert(). Это экономит потребление WAL, уменьшает количество взятий локов и пр. На подписчике же apply worker вставляет каждую такую строку отдельно через heap_insert() — по одной WAL-записи на кортеж. Результат — медленный catch-up и лишний дисковый I/O.

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

Код: github.com/danolivo/pgdev/tree/lr-multi-insert
Материалы и скрипты бенчмарков: github.com/danolivo/conf/tree/main/2026c-LR-Multi-Insert

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

Я Илья Борисов, старший специалист отдела экспертизы MaxPatrol EDR антивирусной лаборатории Positive Technologies.

В 2025 году команда аналитиков антивирусной лаборатории PT ESC провела исследование актуальных семейств ransomware (aka шифровальщиков), чтобы повысить эффективность их обнаружения нашим продуктом. Этот вид ВПО оказался одной из наиболее значимых и заметных разновидностей вредоносов, используемых в атаках в 2025 году.

Мы проанализировали образцы, замеченные в период с конца 2024 года по конец 2025-го. Были разобраны как давно известные семейства шифровальщиков, такие как Black Basta, MedusaLocker и LockBit, и относительно недавно появившиеся Lynx, HellCat и BERT.

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

Топовый SMM hh.ru: как превратить отказы в инструмент поиска работы, получить фидбек, улучшить себя.

Для проведения очередной глитч-атаки на новом семействе процессоров Renesas возникла идея создания относительно универсальной глитч-машины на базе микроконтроллера Raspberry Pi Pico

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

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

С юридической точки зрения любые разногласия, возникающие в процессе учреждения компании, — это полноценные корпоративные споры, регулируемые статьей 225.1 Арбитражного процессуального кодекса РФ. Пункт 1 части 1 этой статьи прямо относит конфликты, связанные с созданием юридического лица, к подведомственности арбитражных судов, которые рассматривают их по специальным правилам главы 28.1 АПК РФ.

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

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

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

Что делать, когда внешние факторы ломают прогнозы, а вы лидер и как-то двигаться вперед нужно?

Анонимный вопрос участника: как держать веру команды и ЛПР в проекте, когда результаты и метрики из‑за внешних факторов почти непредсказуемы? Если «всё классно» — мотивирует, а если шатко-валко — как с этим жить и доносить до стейкхолдеров?

В течение последних двух лет мы проделали большую работу по изданию неустаревающих книг, связанных с проектированием и развитием API. Как известно, сам вопрос «Что такое API?» довольно многогранен, и в своё время на Хабре развёрнутый ответ на него дала одна из наших топовых авторов Ольга Назина @Molechka – к настоящему моменту её статья собрала почти 1 350 000 просмотров и 1555 закладок. Книги Ольги Назиной не относятся к этой статье напрямую, но, если вы их ещё не читали, рекомендуем посмотреть все четыре. Будем исходить из того, что API – это предоставляемый программой интерфейс-контракт, в котором заложены правила взаимодействия с ней, в частности, форматы принимаемых и выдаваемых данных. Нашим главным бестселлером в этой области является книга «Проектирование архитектуры API: Как правильно проектировать, развивать и эксплуатировать API» (вышла на русском языке в июне 2024 года), написанная великим Джеймсом Гофом в соавторстве с Дэниэлом Брайантом и Мэтью Оберном, а также ещё три крутые книги:

«API как искусство: разработка, поддержка, интеграция» Сергея Константинова (вышла в мае 2024 года)

«Архитектура бэкенда. API для надежных корпоративных приложений» Владислава Светлакова (вышла в августе 2025 года)

«Web API. Сборник рецептов: Повысьте уровень JavaScript-приложений» Джо Аттарди (вышла в сентябре 2025 года).

На этой  в продаже появилась следующая книга, наполняющая эту нишу: «Прикладные API для искусственного интеллекта и Data Science» Райана Дэя — оригинал вышел в издательстве «O’Reilly» в апреле 2025 года. Эта весьма оригинальная книга исследует работу с библиотеками Python и в качестве сквозного проекта рассматривает фэнтези-футбол. Для нас это первый опыт издания книги с серьёзным включением FastAPI, но в перспективе мы не теряем надежд издать и исходно русскоязычную книгу об этом фреймворке.

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

Если вы хоть раз разрабатывали SCADA-интерфейс, то знаете эту боль: унылые стандартные элементы, примитивная графика, дизайн уровня 90-х и никаких особо альтернатив, кроме как использовать свои изображения .png.

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

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

На тот момент на рынке вовсю хайповали генеративные модели (такие как «Nano Banana»). На первый взгляд казалось, что проблема решается в два клика. План был надежен, как швейцарские часы: получить API-ключ, отправить по эндпоинту фотографию интерьера и текстуру обоев, сопроводить это правильным промптом (с указанием учитывать перспективу, освещение и масштаб) и забирать готовый результат.

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

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

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

Привет! На связи Саша Мищенко, тимлид платформенной команды, и Света Чекунова, Senior QA Auto. Нам кажется, что мы нашли этот баланс.

В предыдущем разборе («О бедном луддите замолвите слово…») я разобрал по единой схеме одно из ключевых возражений против катастрофического прогноза кадрового разрыва — паттерн ткацкого станка. То возражение отбрасывается структурно: условия, при которых паттерн срабатывал, в текущей ситуации не выполнены.

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

Схема та же: