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

Привет, Хабр! Меня зовут Михаил Косцов, я руководитель практики вычислительной инфраструктуры, СХД и СРК К2Тех. Для нас серверное железо – рабочий инструмент, и мы обязаны знать его возможности. Когда к нам в лабораторию попали два сервера YADRO, мы гоняли их 24 часа под полной нагрузкой, выдергивали диски на ходу и до предела грузили вычислениями.

Под катом – разбор VEGMAN R220 G3 (2U-сервер с парой Xeon Max 9480 и встроенной HBM-памятью) и YADRO G4208P G3 (4U-платформа под ИИ-нагрузки с двумя видеокартами NVIDIA H100 и парой H200). Будут бенчмарки, стресс-тесты, проверка отказоустойчивости и много графиков.

Обычные тесты находят только ожидаемые ошибки. В статье разберём, как Hypothesis сам ищет контрпримеры и сокращает их до минимального сбоя.

Промтинг и постановка задачи

По данным Harvard Business Review 80% руководителей уверены, что ставят конкретные и измеримые цели. И по его же данным 16% линейных сотрудников понимают связь своих задач с инициативами компании. Агент учит нас четкой постановке задач с ожидаемым результатом и описанием пути его достижения. Он, как и человек, додумывает, иногда усложняет, у него своя картина мира. Это, в свою, очередь, учит фокусироваться на ценности для клиента — зачем я это делаю? почему именно таким способом? насколько ожидаемый результат важен для клиента и готов ли он за него заплатить? Сочетание принципов «без хорошего тз — результат хз» и «кто оплатит весь этот банкет?» 

Когнитивная нагрузка

В архитектуре генеративных сетей «контекстное окно» (context window) — это строго лимитированный объем токенов, который модель способна удерживать в активной памяти для обработки текущего запроса. Превышение этого аппаратного лимита неизбежно приводит к потере важных данных (феномен, известный в инженерии как «Lost in the Middle») и резкому падению качества логических выводов. Рабочая память человека функционирует поразительно похожим образом. И что мы имеем?

React остаётся стандартом фронтенда де-факто, но за последние пару лет вокруг SolidJS сложилась устойчивая репутация "фреймворка, который сделал реактивность правильно". У Solid нет виртуального DOM, компонент выполняется один раз, а обновления идут точечно — и это не маркетинговый лозунг, а следствие конкретной архитектуры. Разберёмся, в чём именно SolidJS технически превосходит React, что по этому поводу говорят актуальные бенчмарки и опросы 2025–2026 годов, и — без прикрас — где React по-прежнему выигрывает за явным преимуществом.

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

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

В Сбер2B Онлайн-Продажи мы развиваем интеграцию интернет-магазинов с МоимСкладом. Обычно она работает незаметно для пользователя. Но если обмен данными нарушается, начинаются проблемы: заказы не попадают в МойСклад, товары перестают синхронизироваться, а данные расходятся между системами.

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

Вот типичный пример из практики.

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

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

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

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

Привет! Меня зовут Саша Журавлев. Я основатель и управляющий партнер венчурного фонда. Мы инвестируем в технологические компании на стадиях Seed / Series A в США, Великобритании и Израиле.

Дон Валентайн (1932-2019) – основатель Sequoia Capital, один из первых инвесторов Apple, Oracle, Cisco, Nvidia. Сегодня эти компании стоят в сумме больше $3,5 трлн.

Ниже собраны двенадцать его принципов в инвестициях, опубликованные в блоге 25iq. Автор блога – Трен Гриффин, бывший стратег Microsoft, который много лет собирал и систематизировал мудрость великих инвесторов.

Формат статьи необычный: Гриффин собрал цитаты Валентайна из разных источников и выстроил из них 12 тематических блоков. Каждый пункт начинается с прямой цитаты Валентайна, а дальше Гриффин добавляет свой комментарий: объясняет мысль, связывает с идеями других инвесторов (Баффетт, Мангер, Говард Маркс), иногда вставляет личные истории.

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

Да, статье 11 лет, но что вы мне сделаете?

Одна из вещей, которые бросаются в глаза людям, переходящим в мир линукс‑систем из мира windows — это «странная» организация файловой системы. Почему вместо того чтобы выделить программе каталог, например /myprog, ее размазывают по /etc, /usr/bin, /usr/lib и тому подобное, «это же неудобно!»?

Мало того, нередко после этого человек берется сделать удобнее, как в Windows: эту программу мы положим в /opt/prog1, вон ту — в /usr/lib/prog2, третью в /prog3, четвертую в /home/user/prog4 — а потом думают, как сделать миграцию с диска на диск и ничего при этом не потерять.

На самом деле, в именно такой структуре есть практический смысл, вернее — он был когда‑то, пока его не забыли за давностью лет, и не разбавили опытом DOS.

В статье расскажу о PWA‑бенчмарке, который основан на задаче N тел. Физический движок написан на Rust/WebAssembly, визуализация через Three.js, и результаты запусков сохраняются в Supabase. Тут присутствует разбор архитектуры, сравнение алгоритмов расчета — прямой и Barnes‑Hut, а также тут расписаны проблемы, связанные с измерением производительности в браузере.

В этой статье расскажем, как сделали поиск по внутренней документации в таск-трекере и корпоративной wiki на порядок быстрее, не написав ни единой строчки кода бэкенда

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

( читать дальше... )

 network, networkmanager

Приветствую! На связи Антон Осетров, DFT-разработчик SoC в компании YADRO. В этой статье я хочу рассказать о вызовах в тестировании SoC, о том, как они изменялись со временем и как с этим связан переход от аппаратного интерфейса JTAG к IJTAG.

Это первая статья в серии про LoRa — технологию передачи данных, способную работать с сигналами ниже уровня шума. Протокол LoRa позволяют передавать данные на километры с очень небольшой мощностью передатчика — порядка 10 мВт или 10 дБм. При этом модули LoRa потребляют так мало энергии, что могут работать от одной зарядки аккумулятора год или больше.

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

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

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

Привет! Я Олег Лашинин, руковожу направлением рекомендательных систем в Т-Банке. Когда в экосистеме десятки сервисов — от покупки продуктов в супермаркетах до оформления ипотеки, хочется, чтобы модель понимала пользователя целиком, а не по кусочкам. Но каждая команда собирает свои данные, у событий разные схемы, а в новых сервисах нет истории. 

Большинство моделей было построено только на данных того сервиса, где они применяются. Мы решили эту проблему, объединив все действия пользователя в единую последовательность, и на ее основе построили фреймворк Perseus.  Он позволяет масштабировать ML персонализацию на разные продукты и сервисы компании, так как является гибким инструментов для работы с экосистемными данными. В разных задачах нам удалось сразу повысить бизнес-метрики от 3% до  17% — даже если у пользователя не было ни одной покупки.

Есть фраза, от которой у меня до сих пор дёргается глаз: «Да там ничего сложного — просто раскатим Scrum на все команды». Обычно её уверенно произносит человек, который пару недель назад сходил на двухдневный курс, получил красивый сертификат — и теперь искренне считает, что понял, как устроена разработка.

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

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

Ниже — три вещи, на которых я набил шишки лично: (1) откуда взялся миф о всемогущем Scrum и почему сам Scrum Guide с ним не согласен; (2) почему «голый» Scrum, натянутый на несколько команд с одним продуктом, — это заявка на провал; (3) что реально работает в этом контексте — от LeSS до Team Topologies — и как в эпоху AI выбор смещается в сторону лёгких, потоковых, адаптивных подходов. Без хайпа, с источниками и из практики.

Привет, Хабр! Меня зовут Максим, я инженер команды Нагрузочного тестирования в Ideco. Вместе с командой мы развиваем Ideco NGFW Novum и регулярно гоняем его под синтетической нагрузкой - и для проверки регрессии по производительности, и чтобы честно отвечать на вопрос заказчика «а сколько он у вас держит».

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

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

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

Кажется, что в процессорном мире все идет строго по плану: вышла Zen 5, готовится следующее поколение, а сокет AM5 постепенно становится основной платформой AMD. На этом фоне немного странно видеть в продаже процессоры с архитектурой 2019 года. И речь не о складских остатках, а о вполне новых моделях.

Вот наглядный пример — в марте 2026 года вышел Ryzen 7 4700LE. Восемь ядер, шестнадцать потоков, теплопакет 65 Вт, никакой встроенной графики и все тот же сокет AM4. В его основе лежит архитектура Zen 2 и кристалл Renoir, давно знакомый по мобильным процессорам. Теперь этот чип используют в недорогих игровых сборках с RTX 3050 с ценой примерно 800 долларов. Возникает закономерный вопрос: зачем AMD продолжает выпускать процессоры на архитектуре и платформе, которые, казалось бы, уже давно должны были уйти в прошлое?

Кампания с недельным бюджетом 10 000 ₽ в нише, где заявка стоит около 5 000, не обучится никогда — и автостратегия тут ни при чём. Ей просто не на чем учиться: за неделю она не наберёт даже двух заявок, а без набранных заявок look-alike нечем строить закономерность. Это школьная арифметика, и желание заказчика на неё не влияет.

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

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

Доброго дня, дорогие читатели. Знаете ли вы, что ксеноморф из «Чужого» мог выглядеть как… зефирный человечек с голубыми глазами? Именно такого монстра предлагали студии Fox, пока на сцену не вышел Ридли Скотт с ультиматумом. Эта заметка — о том, как швейцарский сюрреалист Ханс Рудольф Гигер, капризное отношение студии и одно «фаллическое» решение на 65-й странице «Некрономикона» навсегда изменили историю научной кинофантастики. Итак…

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

Но существует вероятностная структура данных, которая способна ответить на вопрос «видели ли мы этот URL?», занимая при этом в десятки раз меньше памяти, чем полное множество строк. Плата за такое — мизерная возможность ложноположительного срабатывания, где фильтр заявит что, хотя на самом деле URL новый. Зато на вопрос «не видели?» она не ошибётся никогда.

Это и есть Фильтр Блума, созданный Бёртоном Блумом аж в 1970 году. Более полсотни лет этому алгоритму! В принципе, никогда не помешает освежить знания и вспомнить, как писать реально оптимизированное ПО.