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

Бывало у вас такое: дел в голове так много, что забывать их начинаешь как только вышел с очередной встречи? Через несколько дней надо принять решение, на основании того, что мелькало перед тобой 3 секунды. Через время ловишь себя на мысли «У нас 21 век, агенты, скилы, почему строить связи между встречами, записями и мыслями должен я?». У меня — бывало, и тут как раз об этом.

Привет! Меня зовут Дима, и я работаю руководителем команды web-разработки AI‑продуктов в R&D Яндекса. А ещё — я учусь в вузе на 4 курсе, люблю куда‑нибудь слетать, пытаюсь следить за здоровьем: и всё это, как я думаю, легко бустится агентами.

Лето — не время затишья, по крайней мере, не в Марфино. Рассказываем, чем были заняты эти месяцы на площадке будущего дата-центра.

Большинство разговоров о сетевой безопасности крутятся вокруг систем, которые стоят на пути трафика и должны принять решение здесь и сейчас: NGFW, WAF, IDS. Но есть и другой класс систем — те, что работают не с самим трафиком, а с его зеркальной копией, и потому могут анализировать происходящее сколько угодно долго. Эта статья — про то, что удаётся увидеть NTA/NDR-системам именно благодаря этому запасу времени: от восстановления цепочки атаки шифровальщика по сохранённым метаданным до обнаружения ботнета, для которого ещё не существовало сигнатуры.

В Next.js изображения, metadata и production build находятся в разных частях проекта. next/image занимается загрузкой и геометрией изображений. Metadata API формирует <title>, description, Open Graph и Twitter metadata. next build собирает production-версию приложения. Ошибки в этих местах часто не мешают работе next dev. Страница открывается, локальная картинка показывается, title есть. На другом домене внешний Image получает запрещённый URL, Open Graph содержит localhost, production build падает на конфигурации или импорте. Разберём эти три части отдельно на примере проекта Goods Finder.

Всем привет! Меня зовут Михаил Голубев, и я работаю в команде Kubernetes Security, MWS Cloud Platform. В этой статье я расскажу об одной попытке оптимизации: как мы залезли под капот CEL и Protobuf, чтобы научить интерпретатор читать данные из бинарного формата на лету без полной десериализации, и почему в итоге от этого кода пришлось отказаться.

Почему мы вообще этим озадачились: в одном из наших микросервисов реализовано сканирование приходящих событий по k8s-манифестам. Событий летит много, а обрабатывать их надо быстро, так что, чтобы минимизировать сетевой трафик и снизить нагрузку на инфраструктуру, в качестве основного формата передачи данных мы первоначально решили использовать Protobuf, он значительно компактнее JSON.

Далее эти данные проходят через различные валидации и проверки. Для описания и выполнения таких политик мы используем CEL — наподобие Kyverno или нативных k8s Validating (и Mutating) Admission Policies. Вот тут-то Protobuf и CEL встретились, и эта встреча оказалась не такой гладкой, как мы рассчитывали, — об этом подробнее ниже.

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

Тесты зелёные, линтер молчит, pull request одобрен. Можно выкатывать — главное, чтобы ничего не упало, но мы ведь 100 раз протестировали, изучили pull request, запустили линтер и уверены в качестве кода.

Но опасность поджидала там, где её совсем не ждали.

Недавно мне попалась статья, в которой автор разбирал JavaScript на чужом сайте — просто просматривал Source‑файлы, которые сайт отдаёт браузеру. Он обнаружил там API-ключи, хранящиеся прямо в JS. Меня поразило, насколько легко их можно найти. Если любой посетитель может открыть вкладку Source и изучить содержимое файлов, то что увидит он в файлах моего сайта?

О том, что я нашёл у себя, рассказывать не буду. Сегодня мы поговорим о том, что мало кто из разработчиков проверяет готовые чанки и исходники. А ведь именно там может скрываться много неожиданного. Вы уверены, что точно знаете, что содержится в вашем Production-артефакте? Не в .env.production и не в конфигах Vite, а в реальных строках и файлах, которые прошли минификацию.

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

Давайте посмотрим, что из этого утекло в итоговую сборку.

Microsoft рекомендует современный WinUI 3 в качестве официального фундамента для будущих Windows‑приложений. Однако, стандартный стек C++/WinRT + XAML встречает разработчика чудовищным временем компиляции, миксиновым адом вместо нативного наследования, тоннами шаблонной рутины и плохочитаемым кодом.

В этой статье мы разберем архитектуру wxl— тонкой надстройки, которая позволяет описывать GUI на чистом C++23 декларативно (как во Flutter или SwiftUI). Вы узнаете, как сжать заголовочные файлы проекции в 50 раз, сократить время пересборки с полуминуты до 4 секунд, победить накладные расходы QueryInterface с помощью ленивого кэширования интерфейсов на базе STA‑потока и превратить написание нативного GUI в чистое удовольствие.

Хабр, привет! На связи Алексей Постригайло, старший партнер интегратора «Энсайн».

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

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

«Просто арендую сервер помощнее». Так я думал, когда пет-проект внезапно оброс людьми.

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

Я изучил, как похожие проблемы решают крупные компании, и применил эти принципы на практике.

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

Когда компания растет, регламенты и инструкции быстро превращаются в «кладбище файлов», а новички всё равно идут с простыми вопросами к руководителям. Поэтому мы автоматизировали выдачу ответов на бытовые и организационные вопросы новичков, обкатав систему на сотрудниках бэк-офиса перед внедрением в IT-команды. В статье разбираем 5 шагов: от аудита реальных болей сотрудника до подключения умного ИИ-агента, который находит ответы за 30 секунд.

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

Первого сентября OpenAI опубликовала документ под названием «Path to Astra: critical capabilities and frontier safeguards». Я открыла его между делом, за чаем, примерно с тем же интересом, с каким читают уведомления об обновлении пользовательского соглашения.

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

Формально в документе написано следующее. Astra, следующая крупная модель OpenAI, признана достигшей уровня Critical по кибербезопасности в рамках внутренней системы оценки рисков компании. Первая модель в истории OpenAI с такой классификацией. Релиз задержан, защита усилена. И еще одна строчка, которую в новостях пересказывали реже всего: Astra стала первой моделью, прошедшей формальную предрелизную проверку по кибербезопасности со стороны правительства США.

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

Через два дня модель вышла. Президент OpenAI Грег Брокман закрыл брифинг словами «Welcome to the AGI era», и почти вся пресса вынесла в заголовки именно их. Про предрелизную проверку не написал почти никто.

SRE‑инженер Mindbox Дима Рыбалка рассказывает, как команда за два месяца перенесла 40 кластеров ClickHouse в Yandex Cloud. Внутри — как выбирали стратегию миграции, связывали кластеры без VPN, переключали клиентов через cutover без даунтайма и с какими столкнулись проблемами после миграции. Материал будет полезен SRE‑, DevOps‑ и DBA‑инженерам, которые работают с ClickHouse в Kubernetes.

Представьте, что с завтрашнего дня вы перестали оплачивать все сервисы, которыми пользуетесь. Что из них спустя какое-то время останется вашим?

Что изменится?

 Музыка ещё какое-то время будет лежать в кэше смартфона. Потом пропадёт доступ к каталогу. Фильмы и сериалы останутся где-то на серверах стриминговых сервисов. Облачное хранилище начнёт напоминать, что бесплатного места вам уже недостаточно. Какая-нибудь программа сообщит, что лицензия больше не активна. AI-сервис внезапно «вспомнит», что без подписки вы ему не настолько дороги.

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

И тут возникает довольно простой вопрос:

сколькими вещами и технологиями, которыми мы пользуемся каждый день, мы действительно владеем?Мн

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

Тем более на рынке уже есть кейсы, как команды до 30 человек с ИИ собирают и запускают целые облачные платформы. Например, мы в H3LLO Cloud. Эта модель называется tiny teams.

Разница в том, что мы умеем думать, знаем, зачем применять и для чего НЕ применять LLM. И у нас нет KPI на использование токенов. При этом в корпорациях они обычно есть, и часто там мидлы гоняют бессмысленные запросы, просто чтобы дойти до лимита по KPI.

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

Их минимум 5, и каждая со временем обойдётся дороже, чем весь сэкономленный фонд оплаты труда джунов. Ну, например, то, что найм сломан, а система резюме не работает.

Цифры и истории дальше — в основном от моего знакомого, предпринимателя и преподавателя Даниила Пилипенко, который с 2014 года занимается подбором и оценкой айтишников в своей компании SymbioWay. Он и его команда принципиально не делают выводов на резюме.

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

Начнём с того, как кончилась сказка про то, что в ИТ всё хорошо и всех ждут золотые горы.

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

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

Привет, Хабр! Меня зовут Елена Бабенко, я QA lead в одной из продуктовых команд Pangolin в Сбертехе. Мы разрабатываем СУБД, процесс это сложный и интересный, ведь помимо теории программирования и тестирования нам нужно разбираться и в работе PostgreSQL. Но здесь я хочу рассказать не про ежедневные задачи тестирования, а про релизы и роль выпускающего QA-инженера (обычно эту роль у нас берёт на себя один из QA‑лидов). Эта статья будет интересна тестировщикам, которые работают с крупными продуктами, чьи релизы занимают не час, а обычно пару недель.

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

От релиза к релизу мы улучшаем наши процессы и ускоряем разработку. У нас есть много Quality Gates для проверки — помимо стандартных юнитов, мы запускаем регрессы в различных вариациях (состояние сборки по умолчанию, кастомные комбинации, например с разными типами лицензий), обновления с предыдущих версий (здесь же и откаты), совместимость с разными ОС и другое.

Для многих запуск всех проверок — это муторная и неинтересная работа, которая ещё и занимает порядочно времени. А ведь потом надо все эти проверки сверить, проанализировать падения тестов, разобраться с багами (если такие будут), починить флакающие тесты... И в конце концов запустить это всё ещё раз для финального сбора отчётов.

Игра стоит в Steam 3299 ₽, ключ на маркетплейсе — 843 ₽. Вывод очевиден: ключ выгоднее вчетверо.

Я тоже так думал, пока не начал считать всерьёз. Оказалось, что при таком сравнении ответ неверен примерно в трети случаев, а иногда неверен катастрофически: есть игры, где «выгодный» ключ дороже Steam на 67%.

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

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

На дашборде такого ответа может не быть. Он показывает заранее выбранные метрики, а новый виджет ради одной проверки никто не станет проектировать, согласовывать и поддерживать. Можно открыть 1С, найти документ, сверить реквизиты, потом вернуться в рабочее место. Если вопрос возникает редко, этот путь кажется терпимым — пока таких редких вопросов не становится много.

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

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