Привет, Хабр! Я — Денис Сохранный, ведущий инженер саппорта и старший одной из смен поддержки в 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 человек.

В сентябре 2024 года вышел релиз Valkey 8.0 — это key-value-хранилище также часто называют BSD-клоном Redis. В отличие от Redis, Valkey изначально создавался как опенсорс-проект. У него нет энтерпрайз-версии, а значит, развитие не сдерживается коммерческими ограничениями.

Весной 2024 года, когда началась активная работа над форком, команда разработчиков смогла принять и стабилизировать ряд патчей, которые заметно улучшили производительность по сравнению с Redis 7.2.

В этой статье Евгений Дюков, разработчик Managed Databases в Yandex Cloud, разбирает некоторые из изменений и делится результатами проведённых бенчмарков, которые позволяют оценить, как именно новые патчи повлияли на производительность — и в позитивном, и, в некоторых случаях, в негативном ключе. Особенно интересно будет тем, кто ждёт релиз Valkey 8.1 этой весной.

Если разработку под устройства можно сравнить с тёмным лесом, то как в нём не заплутать?

Привет, путник! Меня зовут Денис Малых, я работаю в Яндексе и руковожу разработкой общих компонент для платформы, на которой работают наши устройства. А ещё — я член программного комитета конференции AppsConf, где мы обсуждаем разработку под мобильные ОС. В этой статье поделюсь опытом разработки под нестандартные устройства: чем она принципиально отличается от привычной мобильной разработки, и что нужно уметь, чтобы разрабатывать «умные вещи».

Привет, Хабр! На связи Рафис Гатауллин, ведущий эксперт отдела фронт-энд, и Рамис Закиев, ведущий эксперт отдела аналитики в «Татнефть Цифровые Технологии». В этой статье по мотивам нашего доклада на Industrial++ расскажем, об опыте внедрения мобильного решения, которое позволило оптимизировать процессы в цехах нефтедобычи, где нет условий для работы обычных сетей связи.

Поговорим о том, как мы реализовали передачу данных с мобильных устройств к сервисам по каналу радиосвязи стандарта TETRA. Об опыте подключения и взаимодействия с SDK, написанном на Java, в мобильном приложении на Xamarin. И о подходах, которые использовали для оптимизации трафика при передаче данных приложения и данных геопозиционирования.

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

Алексей Бакин занимается разработкой внутренних продуктов. Один из них — это API-прокси, предоставляющее внешние API для внутренних сервисов. Для реализации этого решения использовали паттерн «Сага».

А вы знаете, как руда превращается в чугун? Даже на автоматизированном производстве многое зависит от ручной экспертизы. На производстве железорудных окатышей ещё недавно качество продукции измерялось буквально на ощупь. Дата-сайентисты помогли снизить зависимость от человеческого фактора. Как это получилось, что общего у окатышей с клетками и зелёным горошком, и как модели помешал кран с водой — читайте в этой статье.

Привет, Хабр! Меня зовут Андрей Голов. Я отвечаю за направление Data Science в «Северсталь Диджитал». Расскажу, как машинное обучение используется в тяжёлой промышленности, а именно — как устроена наша система управления процессом окомкования железорудных окатышей.

Привет! Я Лев Хакимов — техлид команды безопасности в Wildberries, а в прошлом — DevOps (хотя говорят, что бывших DevOps не бывает). А ещё я — организатор VrnCTF, CentralCTF, кубка CTF, MiaCTF, OmCTF. Автор дисциплин DevOps в ВГУ и ИТМО. В этой статье:

расскажу про Jenkins и его экосистему (для тех, у кого Jenkins нет, либо он мало с ним работал, это будет особенно полезно);

покажу, как мыслит и действует злоумышленник;. 

разберу проблемы безопасности и уязвимости в Jenkins;

научу, как защититься от угроз, выстроив тактику защиты; 

познакомлю с хорошими практиками по базовой конфигурации, если вы ещё не сталкивались с разворачиванием Jenkins;

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

Кому пришла в голову идея отправлять SQL запросы в data lake? Оказывается, это позволяет компаниям более гибко и эффективно анализировать свои данные за счёт уменьшения потребности в ETL и снижения нагрузки на корпоративное хранилище. Рассмотрим, какие популярные SQL-движки умеют это делать и как им это удаётся.

Меня зовут Владимир Озеров, я руковожу компанией Querify Labs. Мы уже порядка 10 лет занимаемся распределённым SQL, делаем всевозможные SQL-движки, в частности CedrusData — коммерческий движок на основе опенсорс проекта Trino. Сегодня поговорим про то, каким образом устроен ряд SQL-движков, которые обрабатывают данные от data lake.

Привет, Хабр! Меня зовут Сергей Прилуцкий, я руковожу отделом исследований компании MixBytes. Мы занимаемся аудитами безопасности смарт-контрактов и исследованиями в области блокчейн-технологий. В числе прочего занимаемся и направлением zero-knowledge. Эта статья подготовлена по мотивам моего доклада на Highload про zkSNARKs. Это одна из самых горячих тем в современной криптографии. Они используются для обеспечения приватности и масштабируемости в децентрализованных системах. Поговорим, как масштабировать криптографические системы, какие проблемы существуют у снарк-алгоритмов и зачем они нужны.

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

Сегодня поговорим о техническом лидерстве, где оно может лежать в команде разработки, обязательно ли это тимлид или всё-таки не обязательно. А поможет нам в этом Анастасия Абрашитова, руководитель службы инструментов репозитория в Yandex Infrastructure.

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

Материал написан и дополнен по мотивам выступления Любови Гринкевич и Алексея Миртова из Yandex Cloud на DevOpsConf. Он будет интересен DevOps-инженерам, специалистам по безопасности, владельцам продуктов и всем, кто хочет:

Привет, меня зовут Олег Свидченко, я — Chief Data Scientist. Работаю в ассоциации «Цифровые технологии в промышленности». Если вы недавно перешли из крупной технологической компании в нефтегазовую или только планируете этот переход, либо слышали про машинное обучение только в теории, но у вас нет практики его применения в конкретных, особенно промышленных проектах, эта статья для вас.

Когда я искал новое место работы, сперва рассматривал крупные IT-компании, но решил, что мне неинтересно допиливать 0,1% к точности поиска. А в промышленности — непаханное поле, можно внедрять интересные технологии крупными мазками и решать задачи, которые еще не исследовались. Хотя меня пугали страшилками, что будет строгий дресс-код, жесткий график, неудобный офис и скучные проекты...

За последние пару десятилетий с ростом объёма данных на рынке СУБД сложился интересный ландшафт. Появились новые СУБД, при этом старые продолжали развиваться — и сориентироваться среди них становилось всё сложнее. 

В этой статье предлагаем рассмотреть эволюцию разных СУБД и сравнить их между собой. Поможет нам в этом Олег Бондарь, директор по продукту в Yandex Cloud, который отвечает за развитие YDB — это транзакционная реляционная база данных с открытым исходным кодом. Статья написана по материалам его доклада на Saint Highload++.

Привет, Хабр! Я — Алексей Диянов, технический директор Nedra Digital. Мы — IT в нефтегазовой отрасли. Компании чуть больше трёх лет. Мы быстро выросли как в численности персонала, так и в количестве проектов, но не избежали классических проблем в виде трудностей внутренней коммуникации, регулярного тушения пожаров и принятия управленческих решений на основе субъективного мнения.

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

Привет, Хабр! Меня зовут Дмитрий Архипов, я руководитель разработки в Сибур Диджитал. В IT 15 лет, занимаюсь цифровизацией почти 6 лет. Расскажу что это такое, какие задачи возникают в ходе цифровизации, какие бывают стратегии и способы реализации этих стратегий, а также какие проблемы из этого вытекают.

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

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

Статья подготовлена на основе доклада Владимира Дроздецкого о вопросах, методах, практиках и в целом подходе к Observability для инфраструктурной платформы Magnit Online Services. Внутри — о том, как пришли к идее нового процесса, о настройке мониторинга от helm upgrade до gitops-подхода, опыте интеграций с Grafana в работе с визуализацией и метриками и политике алертов, которая не пропускает критичные угрозы.

Статья будет полезна инженерам платформенных команд и эксплуатации, а также всем, кто внедряет у себя DevOps-практики.