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

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

Я сделал его в 2002 году, выбрал хранить, и получил вместе со скоростью проблему на двадцать лет вперёд.

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

Причина оказалась не в триггерах и не в производительности. Она в том, что одно бизнес‑правило было записано в коде шесть раз в разных местах, а в седьмом его забыли написать.

В проекте периодически перезапускались PM2-воркеры. Сами рестарты сначала и были проблемой: процесс завершался, PM2 запускал новый, какое-то время всё работало нормально, затем ситуация повторялась.

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

И я пошёл искать причину.

Всего за несколько лет технологии ИИ заслужили популярность среди компаний – согласно отчёту McKinsey в 2025 году 88% компаний заявляли об использовании ИИ хотя бы в одной бизнес-функции.

Наряду с этим для злоумышленников ИИ становится и целью, и инструментом атаки. Такой факт подтверждается майским отчетом Google AI Threat Tracker – его обзор опубликован в моём канале.

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

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

Меня зовут Алексей Тиньков, я занимаюсь тестированием производительности уже 8 лет. В первой статье цикла хочу поделиться своим опытом организации процесса нагрузочного тестирования (НТ), рассказать о том, как правильно думать о тестировании производительности и чем оно принципиально отличается от привычного функционального тестирования.

Однажды в проде контейнеры одного из сервисов начали падать по OutOfMemory. Контейнерам было выделено по 4 ГБ оперативной памяти, нагрузка была вполне обычной: десятки страниц в секунду.

Расследование показало, что проблема была в JSON-конфиге.

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

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

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

Но всё оказалось интереснее…

Третья, заключительная статья об исследовании MiroFish, открытого стека мультиагентной симуляции общества. В первой части изложены методология и Silent Failure; во второй слепота отчёта, управляемая графом. В этой части: как одна фраза запроса превращается в конфигурацию запуска, что систему ограничивает на длинной дистанции, и общая карта находок серии.

Хабр, и снова здравствуй) На связи Алексей Боровиков, архитектор Astra Cloud. Тут такое дело, мы выкатили мажорный релиз нашей облачной платформы. Работа была проделана колоссальная, я не буду писать все изменения, иначе это будет не статья, а книга. Поэтому решил сфокусироваться на одном компоненте и рассказать, как мы его сделали и почему. Речь идет про IAM — Identity and Access Management. Он отвечает на главные вопросы облачной безопасности: кто, что сделал и имел ли на это право. Итаааак…

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

Каждая вторая статья про «алгоритм Threads 2026» держится на цифрах, которых никто не показывает. Я решила посчитать сама и заодно проверить, переживут ли выводы тест на случайность.

200 аккаунтов русскоязычных маркетологов, 16 724 поста. После чистки осталось 4 848 профессиональных постов от 103 авторов. Метод — нормализация внутри автора плюс перестановочный тест. На четырёх признаках из двенадцати это переворачивает знак эффекта относительно наивного подсчёта.

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

Дальше — сбор данных, метод с кодом и точными p-value, результаты и раздел про ограничения, которых тут хватает.

Threads принадлежит компании Meta, которая признана в России экстремистской организацией и её деятельность запрещена.

Релейная защита и автоматика (РЗА) является главным элементом безопасности любой энергосистемы. Сбои в работе питания, возникновение коротких замыканий, неселективная работа защит могут остановить не только работу предприятия, но и целых городов и даже стран, как было в истории с блэкаутом в Испании в 2025 году [1]. Поэтому, чтобы избежать таких случаев, от РЗА требуются максимального быстродействия, точности и надежности.

Модели REPEAT VISION позволяют подробно изучить структурные схемы и принципы действия защит, а также проводить эксперименты, моделирование аварийных случаев и подключение к терминалам защит. Ранее мы писали о моделировании электроприводов в REPEAT VISION [2]. Давайте разберем, как моделирование систем РЗА применяют для тестирования и предупреждения аварийных ситуаций на примере высокочастотной дифференциально-фазной защиты (ДФЗ) линий электропередач.

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

Всем привет! На связи команда BI-практики GlowByte.

У нас прошел внутренний хакатон AI Seasons. Он вдохнул жизнь в корпоративное обучение и дал участникам ощутимую бизнес-ценность. Хочу поделиться этим опытом и подкинуть вам идею для масштабирования истории у себя. Ниже расскажу подробно, а пока вкратце опишу основную идею, как это реализовали у нас в GlowByte.

Итак, мы взяли вымышленную розничную сеть «МегаБайт» с сотнями магазинов и миллионами заказов. Поставили перед командами задачу реализовать DWH/BI-кейс, решать задачки нужно было с помощью ИИ. На старте участвовали 28 команд, до финиша добрались три: было по-спортивному напряжённо, горячо и энергично, так что не все смогли потянуть битву в таком темпе.

Под катом я расскажу:

● как устроен наш хакатон;

● как оценивались задания;

● какие ошибки мы допустили;

● что было ценного и что мы уже забираем в текущие рабочие процессы.

Будет здорово, если вам зайдет тема и организуете подобный «боевик» для специалистов у себя. Потом обязательно поделитесь в комментариях! 

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

Разберём, как воспроизвести такую просадку, найти её через perf c2c и исправить без лишнего раздувания структур.

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

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

Именно здесь возникает необычный психологический эффект. Социальная часть мозга уверенно сообщает: «Там кто‑то есть». Рациональная часть отвечает: «Нет, там вычисление на серверах». Обе реакции возникают одновременно — и обе по‑своему закономерны.

Когда речь заходит об оптимизации запросов в PostgreSQL, разработчики, как правило, сосредотачиваются на времени выполнения: индексы, планы запросов, настройки памяти и так далее. Время планирования остаётся в тени. А зря! Планировщик работает перед каждым выполнением запроса. Для OLTP-нагрузки с короткими транзакциями накладные расходы на планирование могут составлять значительную долю от общего времени ответа. Для запросов с большими IN-списками и высоким statistics_target планирование может занимать сотни миллисекунд, тогда как само выполнение укладывается в миллисекунды. Поэтому ускорение планировщика не менее важно, чем ускорение выполнения. Мы нашли и устранили одну из таких скрытых проблем, и сейчас патч проходит ревью на PostgreSQL Commitfest.

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

МЫ уже 15+ лет организуем масштабные ит-конференции – DUMP, PYCON, RUSTCON. А в прошлом году дебютировала наша новая конференция для разработчиков golang –  Let's GoConf. За это время через нас прошли сотни заявок, и одна вещь повторяется из года в год: сильные инженеры часто присылают слабые заявки, а средние на первый взгляд идеи иногда превращаются в отличные доклады.

Почему так происходит?

Летом 2020 года я написал на VC статью о том, как запускал агентство. Она собрала 14 000 просмотров, 119 комментариев и 1663 рубля донатов. С неё пришло 1670 человек на сайт, 31 заявка и 3 подписанных договора.

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

Как это? У вас есть аккаунт на хабре, есть своё мнение по каждой статье, есть желание этим мнением поделиться с дедушкой, но нет своего мессенджера чтоб это сделать? Срочно исправляем.

Lim (local ip messenger) работает в вашей локальной сети, на вашем CHR или ARM64 роутере Mikrotik, без внешних сервисов. Обмен текстовыми и голосовыми сообщениями, файлами до 50мб. Публичным ключом собеседника шифруются: сообщения, файлы и имена файлов. И кнопка "Отправить", тоже зашифрована.

Перед вами шестая и заключительная часть (а вот первая, вторая, третья, четвёртая и пятая) серии статей, посвящённых информационным технологиям в авиаперевозках. Сегодня мы поговорим об изменениях, происходящих в этой сфере. Системы, построенные на базе стандарта NDC, вот уже 14 лет пытаются вытеснить традиционные GDS. Этого до сих пор, в полной мере, не произошло. У такого положения дел есть определённые политико-экономические причины. Здесь же автор расскажет о том, что он, благодаря инциденту с птицей, узнал о системах, которые вот уже много лет пытаются заменить.