Если бы кто-то создал кнопку «Сделать безопасно», то заработал бы миллиарды. Но увы — такой не существует, приходится всё делать вручную.

Привет, Хабр! Меня зовут Анна Лучник. Последние два десятилетия я реализую сложные и безопасные ИТ-проекты.

В этой статье расскажу:

От каких угроз может защитить внедрение Service Mesh в теории и на практике.

Какие конфигурации и решения обесценивают включение mTLS, на какие конфигурации стоит обратить внимание, чтобы всё корректно работало.

Поговорим о том, чем mTLS отличается от обычного TLS.

К каким сбоям и проблемам может привести режим strict mTLS. И что делать, чтобы безопасность на стала причиной того, что у нас ничего не работает. 

Как объединить по сети вычислители? Что происходит при компиляции кода для железа под капотом и какие есть нюансы при работе с AI в пространстве ядра? ИИ с ноги ворвался во все сферы разработки, работы — вагон и маленькая тележка. Но на чём и как она должна ехать? У каждой программы есть свои требования, универсальных советов нет.

О новых решениях можно будет узнать на конференции OS DevConf 25 — там будет целый трек, посвящённый железу для AI. Пул экспертов соберётся, чтобы показать, как устроен современный стек ИИ — от базового железа для инференса до системных рантаймов и объединения ферм GPU, чтобы обучить большие языковые модели. Участники не просто узнают об инструментах, но и ознакомятся с методиками, как программировать это железо до уровня «можно использовать в Pythorch».

Мы в Смартомато — супер продуктовые ребята. Со временем у нас скопились недовольство по поводу работы с Golang, захотелось залезть в технические дебри. Произошла гиперкомпенсация и мы придумали препроцессинг в Go. Да, несмотря на то, что этот язык официально не поддерживает препроцессоры —  мы всё равно сделали. А сейчас делимся результатами этой работы с вами.

Эта статья по мотивам моего доклада на Golang Conf X 2025 о болях шаблонного кода и вариантах их решения с помощью препроцессинга на базе стандартного тулчейна Go. В тексте не будет сравнения с препроцессорами в других языках и морально-этической оценки решения.

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

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

Привет, Хабр! Меня зовут Александр Коротков, я — тимлид продуктовой команды в Т-Банк и член программного комитета конференции DevOps Conf. Разрабатывал системы автоматизации тестирования, пять лет посвятил работе над IDP, лидировал разработку бизнесовой платформы. Эта статья родилась из моего доклада для DevOps Conf. Но, если честно, тема давно сидела в голове. Я много раз наблюдал в индустрии один и тот же сценарий: платформы начинают строить с амбициями, но потом что-то ломается — развитие замирает, платформа превращается в тяжёлую обузу или её и вовсе переписывают с нуля. Почему так происходит? Где те самые «невидимые грабли», на которые снова и снова наступают разные команды?

Будет полезно не только тем, кто строит платформы напрямую — CTO, Head of Platform, DevOps-инженерам и разработчикам платформенных решений, но и всем, кто сталкивается с инфраструктурой и хочет заранее видеть потенциальные проблемы.

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

Современный DNS — это не только соответствие доменов IP-адресам, но и целое распределенное хранилище различных метаданных (SVCB-, HTTPS-записи, всевозможные верификации и публичные ключи).

Сегодня расскажем, как проект стал одним из основных DNS-сервисов в мире. Статья написана на основе доклада технического директора AdGuard Андрея Мешкова и директора по инфраструктуре AdGuard Константина Замякина в рамках Профессиональной конференции разработчиков высоконагруженных систем Saint HighLoad++ (июнь-2025).

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

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

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

Чтобы закрыть эту проблему, в Авиасейлс решили внедрить ML-скоринг и ранжировать билеты по вероятности покупки. На практике задача оказалась гораздо сложнее: разные источники данных у аналитиков и бэкенда, training-inference skew, провалы в нефункциональных требованиях и неожиданный рост latency.

В Райффайзен Банке 14 профессиональных сообществ и 262 Agile-команды. Все эти люди взаимодействуют между собой, создают артефакты и проекты с разной скоростью, качеством и своими решениями. Чтобы все это не превратилось в хаос, в корпорации начали выстраивать инженерные практики — для унификации/стандартизации решений.

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

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

В «Сколково» в Москве 6-7 ноября пройдёт крупнейшая IT-конференция HighLoad++. Это самая высокая концентрация профессионалов из отрасли в стране: мероприятие направлено на обмен знаниями о технологиях, позволяющих одновременно обслуживать тысячи и миллионы пользователей.

В прошлой части мы разобрались, что такое состязательные суффиксы и почему они так легко ломают модели. Но этими суффиксами атаки не ограничиваются. Им на смену пришёл AutoDAN — наследник состязательных суффиксов и популярного jailbreak-метода DAN (Do Anything Now). Разберёмся, чем он отличается от GCG-алгоритма, посмотрим на практические примеры атак и обсудим, как защищаться и тестировать модели.

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

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

Каждый год программный комитет FrontendConf начинает работу над программой не с гипотез, а с фактов. Для этого мы проводим глубокое исследование отрасли, чтобы понять, какие темы действительно волнуют фронтенд-разработчиков. Всё начинается с кастдевов — интервью с компаниями о текущих болях и потребностях. В этом году удалось собрать порядка 300 мнений — этого достаточно, чтобы увидеть устойчивые тренды. Так мы собрали целостную карту интересов сообщества, которая и легла в основу программы FrontendConf 2025. В статье рассказываем, как она устроена и почему именно эти темы вы увидите на сцене.

Привет, Хабр! Я — Денис Сохранный, ведущий инженер саппорта и старший одной из смен поддержки в Nexign. Много лет работаю в IT-индустрии, связанной с телекомом и биллингом, на разных позициях от инженерных до тимлидских.

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

Алексей Рыбак — основатель R&D-лаборатории devhands.io, сооснователь платформы автоматизации оценки Teamwork360, а ещё член программного комитета TechFounders — конференции про запуск, развитие и рост IT-стартапов. В прошлом — глава разработки в Badoo, участник команды Андрея Андреева, стоявшей у истоков Mamba, Begun, SpyLog. CTO, технарь, предприниматель, отец троих детей — и человек, который умеет говорить о стартапах без романтики, но с уважением к тому, что в них действительно важно.

Мы поговорили с Алексеем о том, как растут стартапы, зачем технарям становиться фаундерами и как выстраивать культуру в быстро растущих командах.

Что такое личная эффективность технического директора? Где проходит грань между «хорошо для бизнеса» и «хорошо для себя»? Как при этом не утонуть в бесконечных задачах и успевать развивать людей?

На круглом столе «Личная эффективность СТО» в рамках конференции CTO Conf X 2025 топовые технические лидеры обсудили, что помогает оставаться в строю, а что тянет вниз.

В обсуждении участвовали:
– Владимир Шульга (Cloud.Ru)
– Артём Елизаров (CTO розничной сети МТС)
– Иван Поддубный (CTO Вебпрактик)
– Александр Серпичев (Axenix)

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

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

Статья написана по мотивам выступления Максима Чудновского, лидера по продукту Platform V Synapse Service Mesh СберТех на Highload++, где он рассматривал кейс миграции с OpenShift на Platform V DropApp, но предложенные подходы могут быть использованы и для миграции на другие российские Kubernetes-платформы: Deckhouse, Штурвал, Боцман и так далее.

Помимо вариантов использования механизмов ETL, трансляции шаблонов в релизных конвейерах, рассматривается подход применения менеджера политик Kubelatte для того, чтобы мигрировать с OpenShift без единой правки кода.

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

Я, Константин Лапин, руководитель технической поддержки Nexign. Мы пишем софт для телекома, создаём международные продукты и платформы, ускоряющие работу внутри компаний. Моя команда поддерживает одного из крупнейших телеком-операторов России. Мы отвечаем за то, чтобы технических сбоев либо не было, либо, если сбой случился, то минимально влиял на абонентов. В отделе четыре команды по 8-10 человек в каждой, работающие в графике 2×2.

Расскажу, как мы создали и внедрили систему развития от инженера до главного эксперта в своей команде. Мы обсудим:

▪ что такое инженерный карьерный трек, кому он нужен, а кому нет;

▪ что влияет на продвижение по треку;

▪ как мы обосновываем повышения бизнесу и сотрудникам;

▪ как растим новичков и что получилось по итогу внедрения готовой схемы в команде из 40 человек.