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

Последние недели внимание индустрии приковано к X: 13 августа Илон Маск выложил в открытый доступ веса ранжирования алгоритма «For You» и запустил инструмент «Under the Hood», который прямо показывает пользователю, есть ли ограничения на видимость его постов и почему.

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

Какие события произошли за последнее время с Meta?

26 августа 2026 года Meta заключила мировое соглашение с 47 штатами США на сумму до $18 млрд, закрыв иск о том, что компания намеренно проектировала аддиктивные платформы для детей. Соглашение обязывает Meta ввести конкретные технические меры для пользователей младше 18: лимит времени (2 часа/день), ночной режим, усиленную верификацию возраста. Соглашение вроде как уже вступило в силу и утверждено судьей.

В соглашении есть очень любопытный пункт, из $18 млрд Meta гарантированно платит только $12.7 млрд - оставшиеся $5.3 млрд перечисляются штатам, только если TikTok и YouTube присоединятся к тем же ограничениям и заплатят сопоставимую сумму. И тут очень интересная логика, если конкуренты не присоединятся - Meta экономит $5.3 млрд, а конкуренты выглядят компаниями, отказавшимися защищать детей. Но если присоединятся - Meta вроде как теряет большие деньги, но зато забирает у конкурентов их преимущество показывать детям все подряд и забрать трафик.

Как заново начать разрабатывать известный продукт с длинной историей и большим количеством пользователей.

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

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

Примерно полтора года назад мы в компании начали проводить еженедельные воркшопы по ИИ. Или, как мы сами их называем, ИИ-кружки. Сначала для разработчиков, а позже — для «чайников» не-разработчиков тоже. Как, зачем, и к чему это в итоге привело — в статье.

За много лет работы с MS SQL Server я много раз наблюдал одну и ту же последовательность событий.

Сервер под 1С устанавливается методом «далее — далее — готово». Полгода всё работает. Потом наступает пик, сезон продаж или закрытие года, и система встаёт. Отдел сопровождения ищет причину, находит десяток версий и ни одного ответа. Руководство нервничает. Решение рождается само собой, купить новый сервер, так как «этот уже не справляется».

Вопрос, который витает немым подтекстом, звучит просто. С чем именно он не справляется?

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

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

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

Сразу оговорюсь: я из команды LibreDB Studio, и статья — про наши собственные грабли. LibreDB Studio — это self-hosted IDE для СУБД, работающая в браузере: один инстанс разворачивается рядом с базами, а не устанавливается на ноутбук каждого разработчика. Команда открывает URL — и почти сразу упирается в вопрос, который сожрал у нас не один спринт: как показать результат из четырнадцати принципиально разных движков в одной таблице и при этом не начать выдавать пользователю выдумки за реальные данные.

eBPF‑программы проходят статический анализ до загрузки в ядро Linux. Верификатор должен доказать, что программа не выходит за границы памяти, не работает с неверными указателями и не нарушает ограничений, без которых код нельзя безопасно выполнять в ядре. Но если прогнать один объект через разные верификаторы, картина меняется. Один анализатор принимает BPF‑объект, а другой считает его небезопасным и запрещает загрузку.

Именно так и вышло...

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

Наивная формула «веса + KV < VRAM» промахивается по двум причинам, и обе стоят денег. Первая: движок (vLLM, SGLang, TensorRT-LLM) резервирует почти всю память под свой пул ещё до того, как вы посчитали KV — поэтому ответ «сколько запросов влезет» всегда мимо, в сторону «влезет», а потом OOM под нагрузкой. Вторая, которую в уме не посчитать: на DeepSeek-V2-Lite обычная формула завышает KV в 7–11 раз, и промах уже в обратную сторону — зря откажетесь ставить модель.

Я прогнал топ VRAM-калькуляторов из выдачи Google, показал на скриншотах, где ломается каждый (даже лучший), сверил числа с живым vLLM на A100/H100 — расхождение ~1% — и собрал ridgepoint: калькулятор, который считает как движок, а не как учебник. Ставится локально (pip install ridgepoint), GPU не нужен.

Три часа ночи, воскресенье. «Пачка» уведомлений от системы мониторинга в почте и Telegram. Mission‑critical система «лежит», потому что истёк TLS‑сертификат, который упустили из вида и не включили в «эксельный» реестр.

Ситуация знакома? Тогда эта статья для вас. Разберём, почему вопросы управления цифровыми сертификатами резко обострились, какие классы решений есть на рынке, и почему «просто поставить cert‑manager» — это не всегда финал истории.

У нас в публичном облаке VK Cloud у каждого бакета Object Storage есть Bucket Access Policy. Это набор правил в формате JSON, который лежит на самом бакете и говорит, кому какие операции с какими объектами разрешены. Хранилище проверяет эти правила само на каждый запрос. Включается политика в личном кабинете и через S3 API, и я регулярно вижу проекты, где её не настраивали ни разу.

В статье разбираю состав бакет-политики, её отличия от AWS-руководства и что задавать областью действия ключа, а что политикой. Дальше три механизма проверки на endpoint и порядок между ними, перенос политики из AWS-руководства как есть с разбором, почему он не работает, и четыре итерации доводки (Resource, Principal, aws:SourceIp, явный Deny). Затем матрица из 16 запросов с ожидаемыми кодами и скрипт прогона, метрика доли отказов по Cloud Audit, регуляторика, чек-лист переноса между AWS S3, Ceph, MinIO и VK Object Storage.

Пригодится тем, кто держит прокси перед хранилищем и хочет перенести правила доступа в само хранилище, и специалистам по ИБ, которым нужно доказать разграничение доступа выгрузкой, а не скриншотом консоли. Для другого S3-совместимого хранилища применима основная часть: механика проверки и матрица тестов от платформы не зависят.

Привет, Хабр! На связи Сергей Бровкин, руководитель SOC в Рунити. Больше 15 лет я занимаюсь практической информационной безопасностью — расследованием атак, реагированием на инциденты и всем, что происходит вокруг доменов и инфраструктуры клиентов.

Одна из наиболее спорных тем в этой работе — abuse-запросы. Формально всё просто: поступает жалоба на фишинг, вредоносное ПО или взломанный ресурс — ее проверяют и принимают меры. На практике от качества самой жалобы зависит и результат, и скорость реакции.

По статистике за последние несколько лет, Руцентр, Рег.ру и R01 — все они входят в группу Рунити — получали в месяц около 4.5 тысяч abuse запросов от Компетентных организаций по зонам .ru и .рф через сервис Доменный патруль. И только 99% из них завершались блокировкой. Казалось бы, процент достаточно велик, но, учитывая количество поступающих обращений, цифра получается немаленькая. А если учесть, что статусом Компетентной организации до 1 сентября 2026 года обладали ключевые игроки рынка ИБ в стране (с перечнем можно ознакомиться на портале Доменного патруля), то каждый ресурс, на который готовилась жалоба, должен был быть тщательным образом проверен и соответствующее обращение должно было быть должным образом подготовлено и действительно содержать информацию о существенном нарушении со стороны наших клиентов.

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

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

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

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

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

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

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

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

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

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

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

18 августа 2026 года исследователи Hunt.io опубликовали разбор Operation CameraSwarm. За 35 дней один оператор получил доступ более чем к 14 500 камерам Dahua. 

Источник здесь необычно подробный: исследователи нашли открытый HTTP-каталог самого оператора и забрали 2 616 файлов общим объёмом 407 МБ: исходники, журналы запусков, результаты сканирования и служебные скрипты. Затем находки сверили с собственной сетевой телеметрией.

Здесь не было какой-то одной волшебной уязвимости, которая открывала доступ ко всем 14 500 камерам. В одной кампании сошлись старые пароли, непропатченные прошивки и служебная P2P-инфраструктура. Каждый из этих рисков по отдельности известен уже давно. Но когда они собираются вместе…это превращается в конвейер.

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

Код в этом проекте пишет ИИ. Целиком. Бэкенд на Go — язык, которого я не знаю: я не писал на нём ни строчки ни до, ни во время проекта. Фронт на TypeScript и Vue — тут я в теме и мог бы читать, но не читаю. В код я не смотрю вообще: ни в реализацию, ни в тесты, ни в диффы. Я пишу задачу и проверяю результат — всё.

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

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

На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Уже 2 года я делаю подробные обзоры на продукты класса ESB. Появилась идея детально разобрать решения, которые предлагают те или иные платформы, для интеграции с 1С. В этом материале про возможности «Интегры».

В последнее время генеративный ИИ все чаще становится частью корпоративных систем, и российский бизнес активно ищет способы его применения в CRM и ERP. Интерес к таким решениям за последний год вырос в два-три раза. Количество запросов «Битрикс24 ИИ» увеличилось на 600%, «CRM с нейросетью» — на 550%, «ИИ в 1С» — на 85%. При этом, по данным «СберАналитики» и «Сбер Бизнес Софт», 39% российских организаций уже используют ИИ-агентов и ассистентов в документообороте, финансах и HR. Тем не менее, ERP в этом смысле остается более консервативной областью. ИИ чаще подключают к ней в виде отдельных сервисов. Давайте разберем, в каких задачах ИИ действительно оправдан, как выбрать подходящий способ интеграции и почему в большинстве случаев корпоративную ERP разумнее не заменять, а постепенно дополнять.

Рынок созрел, но внедрения с ИИ точечные

Объем российского рынка ERP-систем по итогам 2025 года оценивается примерно в 100 млрд. рублей и продолжает плавно расти. При этом интерес к использованию встроенных ИИ-инструментов в корпоративных системах огромный. Но пока еще процент компаний, реально применяющих ИИ в ERP, остается небольшим. Сейчас начинают появляться ИИ-сервисы, которые могут встраиваться по API в ERP-системы.

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

В последнее время генеративный ИИ все чаще становится частью корпоративных систем, и российский бизнес активно ищет способы его применения в CRM и ERP. Интерес к таким решениям за последний год вырос в два-три раза. Количество запросов «Битрикс24 ИИ» увеличилось на 600%, «CRM с нейросетью» — на 550%, «ИИ в 1С» — на 85%. При этом, по данным «СберАналитики» и «Сбер Бизнес Софт», 39% российских организаций уже используют ИИ-агентов и ассистентов в документообороте, финансах и HR. Тем не менее, ERP в этом смысле остается более консервативной областью. ИИ чаще подключают к ней в виде отдельных сервисов. Давайте разберем, в каких задачах ИИ действительно оправдан, как выбрать подходящий способ интеграции и почему в большинстве случаев корпоративную ERP разумнее не заменять, а постепенно дополнять.

Рынок созрел, но внедрения с ИИ точечные

Объем российского рынка ERP-систем по итогам 2025 года оценивается примерно в 100 млрд. рублей и продолжает плавно расти. При этом интерес к использованию встроенных ИИ-инструментов в корпоративных системах огромный. Но пока еще процент компаний, реально применяющих ИИ в ERP, остается небольшим. Сейчас начинают появляться ИИ-сервисы, которые могут встраиваться по API в ERP-системы.

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

Представим обычную продуктовую задачу. Нужно добавить новую фичу. Команда описывает её через Specification-Driven Development и фиксирует сценарии, ограничения, API и критерии приёмки. Агент получает контекст, быстро пишет код, тесты и инфраструктуру. Через день, а то и раньше, почти готов результат. Но где здесь waterfall?

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

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

Привет, Хабр! На связи команда разработки Just AI. Хотим рассказать, как мы автоматизировали часть рутинных задач вокруг разработки с помощью LLM-агента. Не генерацию функций и не написание кода — нас интересовало то, что происходит с задачей до и после написания кода: создание merge request, сборка, обновление Jira, передача задачи на тестирование и другие повторяющиеся действия.

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

В статье расскажем, как разобрали эти действия на слои, какие ограничения добавили и что в итоге изменилось в работе команды.

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

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

В Инновационном центре «Безопасный транспорт» при ЦОДД интерактивную отчётность и дашборды создают в BI‑системе «Visiology». Платформа позволяет кастомизировать визуализацию, собирая из различных виджетов полноценные отчёты.

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