Мы все знаем, что Hashicorp Vault — это фактический стандарт для хранения секретов, а Kubernetes — для размещения приложений. Но как подружить их вместе? Существует множество инструментов для интеграции Vault с Kubernetes, и каждый из них имеет свои плюсы и минусы. Как выбрать подходящий?

В этой статье, созданной по мотивам выступления на DevOpsConf’25, вы узнаете о самых популярных инструментах доставки секретов из Hashicorp Vault в Kubernetes, таких как External Secrets Operator, Hashicorp Vault Secrets Operator, Hashicorp Vault Agent Injector, Hashicorp Vault CSI Provider, Bank Vaults-Vault Secrets Webhook. Для каждого инструмента будет приведён пример настройки, объяснено, как именно секрет попадает в приложение, а также мы с вами сравним их с точки зрения ротации секретов и удобства использования.

Меня зовут Михаил Кажемский, я Lead DevOps из Hilbert Team. Я в IT уже больше 10 лет и пришёл в DevOps из разработки, поэтому побывал по обе стороны баррикад. Соавтор ряда курсов для инженеров на Яндекс Практикум по направлениям DevOps, Security и Data. Hilbert Team — провайдер IT-решений для крупного и среднего бизнеса в области облачных технологий, DevOps, DevSecOps, DataOps, MLOps и FinOps. Партнёр Yandex Cloud со специализацией Yandex Cloud Professional по направлениям DevOps и Data Platform.

Привет, Хабр! Меня зовут Дмитрий Иванов, я начальник отдела эксплуатации IT-инфраструктуры RUTUBE, что на наши деньги переводится как SRE-тимлид. В этой статье разберу задачу доставки контента и расскажу и решениях, которые помогают нам в RUTUBE. 

Дано: с одной стороны у нас 17,7 млн ежедневных пользователей, а с другой — 400 млн единиц контента. Оба эти показателя постоянно увеличиваются, а география присутствия пользователей расширяется.

Требуется: показывать всем нашим пользователям видео из библиотеки быстро, надежно и эффективно.

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

Мы в Kinescope — те, кто эту магию делает. Видео, которое вы смотрите в интернете, вполне может идти через нашу инфраструктуру — пусть даже вы об этом не знаете. Под капотом у нас: высоконагруженные сервисы, сотни тысяч RPS, терабиты трафика и собственные технологии, написанные на Go.

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

Привет, Хабр! Меня зовут Кирилл Шваков. В Kinescope мы разрабатываем B2B-решение для хранения, обработки, защиты и доставки видео через CDN. Среди наших клиентов — как небольшие стартапы, так и крупные компании. Помимо CDN, у нас, само собой, есть и собственный DNS. А главное, множество инфраструктурных самописных компонентов на Go, которые мы развиваем и поддерживаем внутри команды.

Как связаны скидки, пользовательские пути и огромные массивы данных в Яндекс Рекламе? 

Привет, Хабр! Меня зовут Максим Стаценко, я работаю с базами данных и яростно в них копаюсь с 2010 года, а в Big Data — с 2016. Сейчас работаю в Яндексе в DWH поиска и рекламы.

Мы работаем с ОЧЕНЬ большими данными. Каждый день миллионы пользователей видят рекламу Яндекса, а наши системы обрабатывают огромные объёмы данных. Чтобы реклама работала эффективно, нам нужно в каждый момент времени иметь максимально полную информацию об истории жизни рекламного объявления, а значит нужно каким-то образом передавать данные от одного события к другому внутри рекламной воронки. Расскажу, как мы решали эту проблему.

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

Привет, Хабр! Именно так считает наш сегодняшний гость – Дмитрий Немчин, руководитель направления эксплуатации инфраструктуры данных в Т-банке и по совместительству член программного комитета Data Internals, профессиональной конференции
по инженерии, базам и системам хранения и обработки данных.

В беседе Дмитрий рассказал о своём пути в данные и программный комитет конференции, поделился интересными кейсами и проблемами, связанными с ростом объёмов данных и необходимостью управления ресурсами. А также объяснил, как дата-инженеру остаться востребованным в будущем, где ИИ может проникнуть абсолютно во все сферы жизни.

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

Привет, Хабр! Это интервью с Александром Капитановым. Саша руководит исследовательскими ML-командами в Сбере. Активный контрибьютор в Open Source. А ещё он член программного комитета AIConf X и Highload от «Онтико».

Мы поговорили о том, какие реальные задачи решают мультимодальные LLM, зачем бизнесу модели, которые «умеют всё», и почему мультиканальность — это только шаг на пути, но ещё не конечная станция в развитии ИИ.

Как строить современный процесс работы с API и чем отличаются подходы CodeFirst и ContractFirst? Рассмотрим преимущества и особенности применения обоих, научимся увеличивать продуктивность команды и превентивно решать блокеры.

Привет, Хабр! Меня зовут Иван Поддубный, я CTO в «Вебпрактик». Эта статья написана по мотивам моего доклада для Techlead Conf.

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

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

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

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

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

· Библиотека — узкоспециализированная программа, основной потребитель разработчик.

· Command Line Interface — консольные утилиты, где пользователем может быть кто угодно, а даже если это программист, то он не обязан понимать как CLI устроен внутри.

· Сервисы — Worker, WEB/API/RPC-сервисы и др.

Несколько лет назад я решил испытать себя и поехал в горный массив Хибины, чтобы пересечь его в одиночку. Через четыре дня я оттуда вышел, но не там, где планировал, и не в том состоянии. Часть вещей была утеряна, я был мокрый, голодный, злой — своего рода аll-inclusive наоборот.

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

Привет, Хабр! Я Александр Фокин, лидер по стратегии в МТС и участник TeamLeadConf. Уже 15 лет работаю в IT-индустрии в управлении продуктами и проектами, выстраивании процессов, кризис-менджменте и траблшутинге.

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

В этом году Saint HighLoad++ снова собирает экспертов индустрии на берегу Невы. А я уже знаю, какие темы вызовут настоящий хайп среди инженеров и разработчиков. Ловите инсайдерскую подборку топовых статей самых ожидаемых докладов конференции: только практика, реальные факапы и технологические прорывы.

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

Меня зовут Алексей Волков. Я менеджер продукта Cloud Containers в VK Cloud. В этой статье я расскажу о кейсе одного из наших клиентов: с каким запросом он пришел и с какими сложностями сталкивался, как мы провели тюнинг etcd-кластера и какие настройки нужны, чтобы повысить производительность Kubernetes. 

Привет, Хабр! Меня зовут Виталий Кулиев и я Data Science Tech Lead из Wildberries. На конференции HighLoad++ 2024 поделился опытом своей команды в решении задачи матчинга товаров с помощью больших языковых (LLM) и визуально-языковых (VLM) моделей. 

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

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

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

Как Netflix научился читать мысли пользователей? Зачем собирает и анализирует сотни терабайт данных? Какой подход помогает обгонять конкурентов?

Привет, Хабр! Меня зовут Алексей Жиряков. Я руководитель направления в KION и член программного комитета конференции Data Internals. Давайте поговорим о том, зачем нужен Data-driven (и как он устроен в KION), его проблемах и том, нужен ли он вам.

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

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

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

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

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

Привет, Хабр! Меня зовут Александр Маркачев и я — Data Engineer команды Голосовой Антифрод в билайн. Расскажу, как борьба с мошенниками может обернуться личным вызовом.

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

Привет, Хабр! Сегодня поговорим про инфраструктуру как код. Почему Terraform уже не единственный игрок в мире IaC, а Pulumi становится всё более актуальным. Я расскажу, как эти инструменты работают, чем отличаются, и почему стоит присмотреться к Pulumi, особенно, если вы хотите гибкости и мощи в управлении облаками.

Невероятная история о том, как внедрить систему Feature Store в проект с огромным legacy и получить профит.

Привет, Хабр! Меня зовут Евгений Дащенко, я из компании «Домклик», которая решает все вопросы, связанные с недвижимостью, включая оценку стоимости недвижимости любого типа. Это статья по мотивам моего доклада на конференции Highload++ про интерфейс между данными и ML-моделями Feature Store: как мы сделали его с нашей командой, каких результатов добились и с какими подводными камнями столкнулись на пути.

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

Но почему столько хейта? Неужели всё действительно так плохо? Или дело не в Story Points, а в том, как именно их используют?

Меня зовут Семён, я тимлид в МТС Аналитике, бывший Java-разработчик, сертифицированный Scrum Master и преподаватель курса по Java в МФТИ. Веду блог. За годы работы много раз видел, как команды мучаются с оценками задач.

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

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