Разработка

Привет, Хабр! На связи Николай Лузгин, DevSecOps Lead и Илья Шаров (@issharov), Head of DevSecOps из МТС Web Services. Те самые безопасники, которые приходят в каске, запускают сканеры и доводят разработчиков до слез (нет).

На самом деле DevSecOps — это не про страдания и бесконечные отчеты сканеров в PDF, а про здравый смысл и взаимодействие. У нас в MWS это полноценный процесс, состоящий не только из инструментов, пайплайнов, требований и Security Gate.

В своей работе мы учитываем особенности продуктовой разработки большого количества команд — от крупных до малых инженерных групп, создающих MVP. Вместе с ними боремся за Time-to-Market и оптимизацию расходов, но при этом делаем ставку на повышение безопасности выпускаемого продукта.

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

Звучит неправдоподобно? Из-за образа безопасников-церберов, который складывался в ИТ-тусовке десятилетиями, работа DevSecOps и правда представляется по-другому. Мы решили разобрать четыре главных мифа, которые встречаются при выстраивании отношений между ИБ и ИТ. Погнали рушить стереотипы!

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

Мы с вами разберем на примере, как аналитику проверить доработку с помощью матрицы трассировки.

Вы сняли требования, написали ТЗ, отдали разработчику. Он сделал. Теперь нужно проверить результат.

Вариант «просто потыкать в кнопки» — самая частая ошибка. Потыкали — вроде работает — отдали заказчику. А через день звонок: «А почему вот здесь не считается?» Потому что нужно проверить не только позитивный сценарий.

Начнем.

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

Вы пытаетесь разобраться, но переписка идёт на кривом английском, вопросы трактуются по-разному, а завод в итоге делает так, как ему удобнее.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мобильная разработка — довольно понятное направление в IT. Почти у каждого в кармане есть телефон с iOS или Android, и результат работы разработчика виден сразу: установил приложение — вот оно, работает. Ну, или не работает.

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

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

Команда «Нанософт» создала информационную модель исторического здания торговых рядов на Красногорской площади в Сергиевом Посаде Московской области. Здание, построенное в 1902–1903 годах по проекту А. А. Латкова в русском стиле, в 1920 году пережило пожар, а в 2014-м было полностью отреставрировано к 700-летию Сергия Радонежского.

На примере этой модели мы показываем, как создавать и настраивать пользовательские проемы в nanoCAD BIM Строительство – от базовых до более сложных методов.

Кому это будет полезно?

Архитекторам, конструкторам, руководителям проектов, студентам и всем, кто работает с nanoCAD BIM Строительство или изучает его, – для быстрого освоения программного продукта и решения реальных практических задач.

Привет, Хабр!
Меня зовут Игорь Шишкин, я руковожу отделом разработки облачной платформы Рег.облака. Несколько лет назад, пока облако росло, интеграционный слой между сервисами и брендами естественным образом усложнялся. Каждый новый сценарий требовал отдельного решения — и со временем стало понятно, что нужен общий подход.

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

Всем привет!

Я, Колядова Алиса, Senior дизайнер, работающая над B2B-системами внутри «одной из списка компаний, которые нельзя назвать».

В этой статье — мой путь через проектирование таблиц: от первых факапов до системных решений. Не будет чеклистов. Зато будут кейсы, выводы и немного боли. Некоторые мысли и инсайты в статье могут показаться для кого-то банальными. Ну тормоз я значит)

На Хабре десятки статей про вайбкодинг. Есть переводы сравнений v0 vs Bolt vs Lovable, есть манифесты «вы всё проспали», есть личные истории «навайбкодил сайт за три дня». Но ни одной статьи, где кто-то берёт одно конкретное ТЗ и прогоняет его через все доступные AI-генераторы — западные и российские — с честными скриншотами результатов.

Я это сделал. Одна бургерная, восемь платформ, ноль иллюзий.

«На автотесты нет времени — релиз через неделю!» говорит зарубежная компания со штатом 500+ человек, зарплатами 5 000 €, баг-репортами по ISO. Разбираю, откуда берётся эта фраза, почему разработчики не могут объяснить бизнесу очевидное.

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

Всем привет! Меня зовут Ира Карачакова, я тестировщик в сервисе бронирования отелей Отелло.

В этой статье рассказываю, как у нас в команде выстроился процесс работы с нестабильными фронтовыми e2e-тестами: от простых перезапусков в CI до системы алертов, карантина и отслеживания стабильности.

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

В 2013 году на Randomwire была опубликована интересная статья. В ней автор указал на интересные особенности японского дизайна. Японцы известны своим минимализмом, но в случае сайтов у них, почему-то, всё наоборот. Страницы пестрят всевозможными цветами, что уже нарушает 3 принципа дизайна, плюс на них используются мелкие иконки и мно-о-о-о-го текста.  Да вы и сами видите пример этого буйства фантазии на скриншоте выше, сделанном в ноябре 2022 года.

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

И вот мне стало интересно, как обстоят дела сейчас, и можно ли как-то количественно оценить дизайн японских сайтов? Собственно, этим я и занялся.