Все потоки

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

К сожалению, это убеждение ошибочно, что убедительно доказывает совместное исследование Anthropic, Института безопасности ИИ Великобритании и Института Алана Тьюринга. Их вывод заключается в том, что небольшое, фиксированное количество вредоносных образцов может внедрить бэкдор (скрытую уязвимость) в большие языковые модели (LLM), независимо от их размера.

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

Важная деталь здесь - не бессмыслица, а метрики. До сих пор предполагалась система угроз, основанная на процентах: чтобы отравить большую модель, злоумышленник должен был контролировать ощутимый процент обучения, что на практике становится невыполнимым, когда речь идет о сотнях миллиардов токенов. Это исследование переворачивает все с ног на голову: модели обучались на объемах от 600 миллионов до 13 миллиардов параметров с использованием оптимального по правилу Chinchilla количества данных (больше для более крупных моделей), и было замечено, что атака не масштабируется вместе с размером: одни и те же 250 документов одинаково компрометировали все модели. По сути, яд не растворяется, как ожидалось: он учится выживать.

Бум генеративного ИИ требует всё больше вычислительных мощностей — а значит, новых центров обработки данных. В 2026 году в США работает более 5 000 ЦОДов, по миру — свыше 8 000. По прогнозам Министерства энергетики США, в ближайшие четыре года ежегодно будут вводиться около 450 новых объектов, а суммарная мощность их энергопотребления вырастет с 100 до 200 ГВт.

Но ИИ-инфраструктура — это не только серверы и чипы, а ещё и бетон. Дата-центры требуют массивных фундаментов и инженерных корпусов, а производство цемента даёт около 7–8% мировых выбросов CO₂. Чем быстрее растёт ИИ, тем больше строится ЦОДов — и тем выше углеродный след строительства.

При этом крупнейшие технологические компании — Microsoft, Google, Amazon — декларируют углеродную нейтральность и снижение выбросов. Возникает очевидный вопрос: можно ли масштабировать ИИ и одновременно сокращать углеродный след? В статье разберёмся, как индустрия пытается решить это противоречие.

Ровно 19 лет назад, 30 января 2007 года, Microsoft выпустила Windows Vista — систему, которую технологическое сообщество постаралось забыть как страшный сон. Медленный, глючный, требующий огромной вычислительной мощи, которой не было ни у кого, сон. Ну, во всяком случае так казалось тогда. Хотя, если честно, то и сейчас кажется. Мем про медлительность Vista по праву стал частью IT-истории – на одном уровне с KDE2 и FreeBSD. Но стоит копнуть чуть глубже, и начинаешь понимать, что все было не так однозначно.

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

Пришлось мне волею судеб искать в команду разработчиков нового сотрудника – Middle Frontend Developer. На вакансию было очень много откликов, собеседования шли по три штуки в день, но нужный человек никак не находился.

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

А почему советы бесполезные? Да потому что никто всё равно им следовать не станет.

В современном мире, где цифровые технологии развиваются стремительно, количество уязвимостей растет как снежный ком. Это создает серьезные проблемы для традиционных подходов к управлению уязвимостями (Vulnerability Management, VM).

В этой статье мы рассмотрим, как платформа Breach and Attack Simulation (BAS) может помочь автоматизировать проверку и расстановку приоритетов уязвимостей, значительно повышая продуктивность процессов VM. Подробно разберем технические аспекты BAS, варианты их внедрения, интеграцию с текущими процессами VM и покажем примеры применения.

Конкурс лучших статей Хабра «Технотекст-8» в разгаре. Подать заявку можно до 17 апреля 2026 года включительно. 

Уже третий год YADRO выступает хранителем номинации «Железо: проектирование и технологии производства». Сегодня расскажем, какие статьи ждем и что за призы подготовили для победителей (спойлер: на этот раз за 1 и 2 место вручим комплект из 3D-принтера, платы, цифрового осциллографа и не только). Заодно вспомним статьи, которые вышли в топ в прошлом году, — сможете посмотреть примеры и усилить свои работы. Погнали!

2026 год закрыл вопрос «а вдруг всё вернётся». Не вернулось — и рынок успел повзрослеть.

Если пару лет назад компании в панике мигрировали из Jira и искали временные замены, то сегодня задачи другие. Бизнесу нужны не «костыли», а инструменты, которые ускоряют Time-to-Market, дают прозрачность ресурсов и связывают разработку с финансовым результатом.

Главный вызов теперь — не нехватка решений, а их избыток. На рынке десятки систем: от лёгких планеров до тяжёлых Enterprise-платформ. Маркетинга много. Осознанного выбора — меньше.

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

Металлоорганические каркасы (МОК) на основе лантанидов имеют большие перспективы для применения в газосорбции, катализе, создании люминофорных материалов. Однако представлены они преимущественно урановыми и ториевыми материалами. Число же известных МОК на основе трасплутониевых элементов исчезающе мало, хотя для них уже найдено применение в качестве автолюминесцентных материалов для фотовольтаических источников тока.

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

Привет, Хабр! Меня зовут Олег, я работаю в VK Cloud в команде Key Management Service. Есть у меня такая привычка: когда пользуюсь каким-то инструментом изо дня в день, то рано или поздно хочется залезть внутрь и посмотреть, как оно там устроено. С контейнерами так и вышло: docker run, docker build — всё это прекрасно работает, но что именно происходит, когда мы «запускаем контейнер»?

В этой статье разберём контейнеры не на уровне «вот вам YAML, отправляйте в прод», а чуть глубже — на уровне системных вызовов Linux. По ходу дела напишем свой примитивный контейнер на Go, используя буквально четыре syscall'а, а в конце посмотрим, куда эта история развивалась дальше (сети, файловые системы) и почему виртуальные машины всё ещё живы.

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

Торговля кажется чем-то неотделимым от компьютеров, сетей и алгоритмов. Будто до них были только ярмарки и натуральный обмен, а всё остальное появилось совсем недавно.

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

13 февраля 2026 года ушёл из жизни 75-летний Хидэки Сато, легендарный инженер, а позже и топ-менеджер корпорации Sega. Именно он подарил миллионам миллениалов огромное количество впечатлений и тысячи часов за играми на приставке Sega Mega Drive — ибо Хидэки Сато был её главным разработчиком. При этом в самой Японии приставка не слишком «взлетела», оставшись в тени NES и SNES от Nintendo. А вот в США, Европе, а через пару лет и в России, уже Super Nintendo с большим трудом пыталась конкурировать с Sega Mega Drive, она же Sega Genesis на американском рынке. Как и почему Sega Mega Drive от Хидэки Сато и его коллег осталась вне Японии главной легендой 90-х среди 16-битных приставок?

Пролог: день, когда изменился рынок

15 декабря 2025 года. Для большинства соискателей обычный вторник. Но для тех, кто зарабатывает на жизнь автоматизацией поиска работы, этот день стал «чёрным понедельником». HeadHunter, крупнейшая российская платформа рекрутинга, перекрыл кислород: доступ к API резюме был заблокирован.

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

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

В высоконагруженных системах балансировка трафика быстро перестаёт быть просто задачей распределения запросов. Сегодня на реальном опыте разбираем путь от BGP Anycast к L4-балансировке и XDP: зачем она понадобилась, как помогла справиться с ограничениями Anycast, повысить отказоустойчивость и производительность, а также почему балансировщик стал точкой входа для защиты от L4-DDoS. Статья будет полезна инженерам, которые проектируют и развивают инфраструктуру под высокий трафик и пиковые нагрузки.

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

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

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

«Я всегда отвечаю сразу: люди не должны меня ждать».
«Эту задачу лучше сделаю сам: так будет быстрее».
«Мне несложно отвлечься и помочь: тут дел на пять минут».

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

Редакция чем-то похожа на небольшой, но очень оживленный муравейник: все куда-то спешат, суетятся, торопятся. Здесь постоянно что-то происходит — звонят телефоны, кто-то залип в мессенджере прямо посреди коридора, кто-то носится из кабинета в кабинет со стопкой распечаток подмышкой и очумелым выражением на лице. Но постоянных сотрудников на самом деле не так уж и много — гораздо больше внештатных авторов и переводчиков, которые периодически меняются: одни уходят, другие появляются, и с каждым нужно побеседовать, ввести в курс дела, обсудить текущие задачи, разобрать накопившиеся вопросы. Это постоянный и хорошо отлаженный процесс. Был, пока одним прекрасным утром наш коллега, плотно работавший с кандидатами и потенциальными авторами, впервые за пять лет не собрался зачем-то в отпуск. «Фигня», — решили мы, — «сами проведем парочку интервью и введем новичков в курс дела». В теории это и вправду выглядело несложной задачей, а вот на практике ситуация очень быстро скатилась в форменный хаос. И главная первопричина этого хаоса — техническая, что, впрочем, неудивительно для творческого коллектива, специализирующегося в области IT.

Привет, Хабр! Меня зовут Игорь Березняк, и мы с командой делаем Техплатформу Городских сервисов Яндекса. Я уже писал на Хабре про архитектуру платформы, рассказывал на «Хайлоаде» (и на Хабре) про шардирование и миграцию на YDB.

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

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

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

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

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

Именно поэтому в новом выпуске подкаста CrossCheck эксперты обсудили класс решений IDM (Identity Management) — система централизованного управления учетными записями и доступами.

Появляются результаты анализа образцов, доставленных китайской миссией «Чанъэ-6» с обратной стороны Луны. Они дают нам первое подробное представление о её геологии и истории, а недавняя статья, опубликованная в журнале Science Advances исследователями из Китайской академии наук, содержит очень интересные выводы об истории столкновений на Луне и даже в Солнечной системе в целом.

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