Привет Хабр! Меня зовут Евгений Калашников, я CPO «Инженерных инструментов» платформы «Сфера». И сегодня я хочу поговорить о том, как меняется ландшафт цифровой трансформации в России и какую роль в этом играет DevOps. Недавно мы с коллегами провели масштабное исследование российского рынка DevOps, и результаты получились очень любопытными. Мы убедились, что цифровая трансформация сейчас затрагивает буквально все аспекты бизнеса. Компании, которые не успевают адаптироваться к новым реалиям, рискуют безнадёжно отстать. И здесь на первый план выходит DevOps как ключевой фактор, обеспечивающий скорость и гибкость в разработке ПО.

Наше исследование охватило 817 IT-специалистов и руководителей из различных отраслей. Мы опросили представителей крупных компаний, таких как МТС, IBS, Яндекс, Лаборатория Касперского, а также привлекли экспертов из НИУ ВШЭ и других организаций. Интересно, как выглядит современный российский девопс? Заходите под кат.

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

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

Однако управлять микросервисной архитектурой в Kubernetes бывает весьма сложно. И здесь на помощь приходит Istio — мощная платформа, обеспечивающая сетевое взаимодействие, безопасность и наблюдаемость в кластере Kubernetes. В этой статье мы рассмотрим основы Istio и её начальную настройку.

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

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

Надеюсь, наш опыт будет полезен вам и поможет в ваших проектах.

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

Привет, меня зовут Елена Тихомирова, я работаю системным аналитиком в Платформе Сфера, разработке Холдинга Т1. Поделюсь своим опытом, полученным в одном из проектов, где я реализовала автоматизированную обработку входящей почты: пользователь отвечает на email-уведомление от help desk или трекера задач, обработчик извлекает из письма необходимые данные, обогащает их и передаёт соответствующему сервису для дальнейшей проверки и публикации.

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

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

Будучи DevOps-инженером и работая с масштабируемыми облачными решениями, мне часто приходится глубоко погружаться в механизмы работы потоковых платформ. Трудно переоценить важность подробного изучения архитектуры и оптимизации обработки данных, когда речь идёт о системах вроде Apache Flink. Эта технология стала неотъемлемой частью моего инструментария благодаря её возможностям по реализации потоковых приложений.

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

Ещё мы подробно рассмотрим использование Apache Flink в задачах, где требуется высокая скорость обработки и точность управления данными. Особое внимание уделим изучению архитектурных основ и методов разработки высокоэффективных потоковых систем.

Материал объёмный, и поэтому я разделил его на две части. Запаситесь чаем и печеньками =)

Привет, Хабр! По нашему опыту, при разработке интеграционного взаимодействия труднее всего даётся сопоставление различных форматов данных интегрируемых систем — «маппинг». Для этого нужно проанализировать много форматов, выявить корректные связи между элементами XSD- или JSON-схем и описать правила преобразования. Работа кропотливая, трудозатратная и не самая интересная. Раньше нам приходилось вручную сводить в таблицах поля, сидеть ночами. Думаю, все аналитики с этим сталкиваются и понимают, о чём я говорю.

Меня зовут Ярослав, я техлид в Т1 Иннотех. Наша команда занимается интеграцией всевозможных систем и разработкой ядра интеграционной платформы. За последние три года мы успешно заменили решение на стеке IBM MQ и IBM App Connect (бывший IBM Integration BUS) на open-source решение на основе ActiveMQ Artemis в качестве транспорта, с использованием Java и Kubernetes, и перенесли более 1500 различных способов взаимодействий на новую платформу. Хочу поделиться с вами нашим опытом по автоматизации этой работы и обсудить получившийся инструмент.

Привет, меня зовут Яков, я инженер-проектировщик в компании Т1 Интеграция. Мы с командой интегрируем у заказчиков новые почтовые системы — CommuniGate Pro, RuPost, VK WorkMail — и помогаем с миграцией данных (преимущественно из Exchange).

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

Так есть ли жизнь после Exchange? Есть! И довольно счастливая. Мы выяснили это на своём опыте: протестировали несметное количество российских почтовых систем, которые появляются как грибы после дождя, а также выполнили несколько проектов по миграции тысяч пользователей.

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

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

Добрый день, меня зовут Андрей, я специалист по администрированию баз данных в компании «Сервионика». За 2,5 года под моим контролем побывало около 700 кластеров баз данных, из которых 80 % — High Avaiability, треть из них — это трёхнодовые полноценные кластеры, где есть мастер, синхронная и асинхронная реплики. Также были успешно проведены проекты по миграции с Oracle и MSSQL на PostgreSQL.

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

Привет, Хабр! Меня зовут Александр Митин, я работаю в Т1 на проектах одного крупного банка. Занимаюсь развитием продкутовых сервисов компании (проект по обслуживанию и проведению ЧДП/ПДП клиентов). Опыт разработки 13 лет, последние 5 лет — в финтехе.

Сегодня микросервисная архитектура используется во многих проектах. Зачастую в таких системах применяют журналирование, авторизацию и прочие служебные сервисы, общие для всех приложений. А при разработке возникает огромное желание не дублировать одну и ту же логику, а вынести её в отдельную библиотеку, тем самым переиспользовав код. Что мы имеем в итоге? В лучшем случае одну библиотеку «common», которая разрастается до огромных размеров и становится ядром распределённого монолита. В дальнейшем новые версии этой библиотеки теряют обратную совместимость, а каждое её обновление в проектах сильно осложняет поддержку. Более того, становится невозможным разобраться, где и какие классы используются, что делает архитектуру хрупкой и уязвимой.

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

Меня зовут Ксения Бирюкова, я владелец продукта Платформы Сфера, разработанной холдингом Т1. В одном из моих проектов мы с командой пытались проводить нагрузочное тестирование. Тогда это казалось очень сложным: пробовали тестировать каждый модуль отдельно, связь с legacy-монолитом не помогала, возникали проблемы с написанием генератора псевдо-уникальных персональных данных и многое другое. И хотя результат был достигнут, ресурсов мы потратили гораздо больше, чем планировали. В итоге собрали список ошибок и задумались, как сделать нагрузочное тестирование менее болезненным. Разберём на своих и чужих примерах.

В моей роли DevOps-инженера, специализирующегося на Kubernetes, я регулярно сталкиваюсь с задачами, требующими глубокого понимания множества аспектов этой технологии. Особое внимание уделяется безопасности — критически важному условию для эффективного функционирования и защиты приложений в Kubernetes. Хотя безопасность часто может оставаться вне поля зрения при рассмотрении других операционных задач, её роль в успешном развёртывании и поддержке приложений нельзя недооценивать. Мой опыт и знания в этой области легли в основу данной статьи.

Мы сосредоточимся на двух ключевых элементах безопасности в Kubernetes: Role-Based Access Control (RBAC) и Pod Security Admission. Эти механизмы играют важную роль не только в обеспечении безопасности приложений и данных в кластере, но и в управлении доступом и сетевыми взаимодействиями.

Элементы безопасности, такие как RBAC и Pod Security Admission, играют ключевую роль в обеспечении стабильности и эффективности работы приложений в Kubernetes, особенно при обработке больших объёмов данных и высокой нагрузке. Например, в ситуации с масштабируемым веб-приложением, которое управляет значительными объёмами пользовательских данных и транзакций, настройка этих механизмов может существенно улучшить управление доступом и сетевую безопасность. Это, в свою очередь, помогает предотвратить потенциальные угрозы и атаки, что критически важно для поддержания производительности и доступности данных. Таким образом, эффективно настроенные компоненты безопасности обеспечивают надёжный доступ к данным и минимизируют риски, связанные с увеличением нагрузки на приложение, улучшая общий пользовательский опыт.

Теперь давайте рассмотрим каждый из этих элементов более подробно.

Привет, Хабр! Меня зовут Марат Цконян, я из солнечной Испании, университет Аликанте. Компьютерный инженер по образованию, по опыту работы — системный администратор.

В прошлом году я наткнулся на исследование отечественного DevOps-рынка за 2022 год: там Холдинг Т1 проводил аналитику трендов, а также формализовал проблематику индустрии. Теперь же благодаря Хабру мне предоставилась возможность обсудить накопившиеся вопросы непосредственно с авторами этой работы. 

Я поговорил с Евгением Калашниковым, соавтором исследования и директором по продуктам инженерных инструментов платформы «Сфера». Мы обсудили исследование, поняли, что такое DevOps и кто такие девопсеры, порассуждали, существуют ли DevSecOps и зачем компаниям облака. Заодно заглянули в будущее, узнав, что нас ждёт в исследовании за 2023 год.

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

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

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

Меня зовут Татьяна Сеземина, я директор по управлению проектами Холдинга Т1.

Я вырастила команду с 40 до более чем 150 человек и не потеряла управляемости.

Сейчас расскажу, как мне удалось этого добиться.