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

Всем привет! Меня зовут Михаил Голубев, и я работаю в команде 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С с ограниченными правами и показывает, на какие фактически полученные данные он опирался.

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

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

«Привет! А как у нас оформляется возврат? Я в базе смотрел, но там как-то сложно...» «О, а ты не помнишь, какой регламент по списанию продуктов?»

Для кого-то это звучит знакомо.

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

Проблема в том, что из-за этого разнобоя ожиданий Threat Intelligence очень часто внедряют неправильно. Формально TI в компании есть, бюджеты освоены, отчёты формируются — а реальной пользы почти ноль. В итоге появляется устойчивое ощущение, что TI «не работает», «переоценён» или «нужен только большим корпорациям».

TI — это не просто «база индикаторов», но и не магия

Начнём с самого важного. Да, современный Threat Intelligence давно ушёл дальше примитивных списков IP-адресов, доменов и хэшей. Сегодня существуют TI-платформы, в которых на основе данных об угрозах строятся корреляции, сценарии, гипотезы, а иногда и полноценные обнаружения. В том числе это относится к коммерческим решениям — например, в продукте Security Vision TIP индикаторы используются не сами по себе, а как часть логики анализа и детекта.

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

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

История компании Tata Motors довольно показательна. Изначально она производила локомотивы, а теперь владеет брендом Land Rover. Посмотрим, чем так примечательна эта корпорация.