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

Меня зовут Александр Борецкий, я архитектор в Т1 Облако. Поделюсь своим опытом работы с самыми популярными из брокеров сообщений — Kafka и RabbitMQ. Расскажу, как выбрать и настроить подходящий брокер, а также какие архитектурные особенности есть у каждого из них.

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

Сегодня расскажем об инструментах, которые мы предоставляем для управления Т1 Облако: API, веб‑интерфейсе управления и Terraform. Разберём их особенности, приведём примеры из практики и дадим рекомендации, как с их помощью управлять инфраструктурой.

Привет, Хабр! Меня зовут Алексей Грохотов, я разрабатываю продукт Сфера.Архитектура в ИТ‑холдинге Т1. Перед нашей командой стояла задача перенести документы из Orbus iServer в Сфера.Архитектуру. Iserver — это набор инструментов для описания, поддержки и трансформации архитектуры предприятия. Он в значительной степени интегрирован с Microsoft Office, например, все схемы в этом инструментарии создаются в Visio.

Я должен был проанализировать схемы Visio и извлечь необходимую информацию из этих документов. Объекты, соответствующие «прямоугольничкам и стрелочкам» Visio, уже хранились у нас в базе. Мне нужно было соотнести их с фигурами и стрелками схемы, записать для этих объектов геометрическое и текстовое содержание фигур, а также некоторые их специфические свойства. Ещё нужно было определить порты — «стыковочные места» по периметрам фигур, к которым присоединяются стрелки, а также найти надписи у стрелок и фигур. И после этого сохранить в базу данных всю найденную информацию.

Всем привет. Меня зовут Дмитрий Таратута, я руководитель направления аналитики и отчётности в коммерческом блоке НОТА (входит в Холдинг Т1). Мы развиваем B2B‑аналитику, автоматизируем отчётность и поддержку управленческих решений на основе CRM‑платформы НОТА Модус.

В этой статье я расскажу, как мы реализовали дашборды для НОТА Модус, которые стали универсальным инструментом B2B‑аналитики и помогли нам выстроить экспертизу в развитии аналитических решений для продаж.

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

рекомендации по выбору уровня детализации (FATAL, ERROR, INFO, DEBUG, TRACE);

почему контекст в логах не менее важен, чем сами сообщения;

методики сокращения объёма логов без потери полезности;

как обеспечить производительность и отказоустойчивость приложения при формировании логов;

тестирование логов как не менее важную часть процесса по сравнению с тестированием кода.

Всем привет! На связи команда Центра разработки решений ALM‑стримов «ALM 2.0 Платформа» и «Динамическое моделирование баланса». В этой статье расскажем, как в нашей компании создаётся современная ALM‑система: на основе импортонезависимых решений, с расчётным ядром на Spark/Hadoop и интуитивно‑понятной интерфейсной частью на React/Java/Postgres. Ещё расскажем, как устроены витрины, где живёт логика и как запускаются пользовательские расчеты.

В предыдущей статье мы рассмотрели, как система Документы способствует выстраиванию процесса управления документацией в административно-хозяйственном отделе (АХО). На этот раз мы рассмотрим отдел кадров.

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

• Отсутствие контроля структуры и содержания документа.

• Проблема совместимости файлов и форматов.

• Отсутствие единого хранилища и версионированию.

• Замедление согласования из‑за отсутствия интеграции с системами электронного — документооборота.

• Дублирование документов.

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

• Дополнительные затраты для обучения персонала и поддержке нескольких систем.

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

Рассмотрим конкретный бизнес‑сценарий, когда административно‑хозяйственному отделу (АХО) нужно закупить мелкое оборудование для ремонта офиса.

Привет, меня зовут Роман Поляков, я инженер по тестированию (QA-самурай) в Т1 Иннотех. В мире ручного функционального тестирования каждый день идёт битва за качество. Смена требований, пропущенные баги, плотные дедлайны и тонны тестовых сценариев могут сломить даже опытного специалиста. Но настоящий QA-самурай не сдаётся. Он превращает рутину в искусство, а стресс — в топливо для роста.

Если вы когда-нибудь думали, что работа QA — это просто сидеть и нажимать на кнопки в надежде, что баги сами обнаружатся, то… вы немного заблуждались! Добро пожаловать в увлекательный и порой весьма запутанный мир тестирования, где каждый день сулит встречу с новыми подводными камнями, ловушками и, конечно же, классическими граблями на пути к качественному продукту.

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

Итак, программное обеспечение разработано и протестировано внутри компании. Даже, возможно, неплохо протестировано. Появляется и заказчик, который заинтересован в продукте. И тут наступает великий и ужасный Процесс Внедрения. Расскажу о том, что он собой представляет и какие сложности таит.

Привет, Хабр. На связи команда Т1 Облако. Не так давно мы рассказали несколько необычных историй из жизни наших инженеров: что им удалось отремонтировать по фото, как получилось справиться с кармической несовместимостью и найти «хвост». Сегодня поделимся новыми байками о том, кто живёт на дне океана под фальшполом в машзале и почему носить галстук в ЦОДе может быть небезопасно. Спойлер: все остались живы.

Процессная аналитика (Process Mining) — это методология сбора и анализа информации о бизнес‑процессах. Она помогает составить реальную схему процессов, разобраться в их работе и найти узкие места, требующие вашего внимания. Также процессная аналитика помогает выявлять «нетипичные» пути прохождения и прогнозировать работу бизнес‑процессов.

Мы рассмотрим подробнее эту методологию и особенности её применения. А также на нескольких примерах из практики М.Видео‑Эльдорадо и Т1 покажем, чем процессная аналитика может быть полезна в компании.

В этом обзоре мы собрали ключевые идеи и инсайты из серии подкастов «Первый день в будущем», где эксперты из крупнейших российских компаний делятся опытом внедрения современных DevOps-подходов. Они обсуждают не только вопросы автоматизации и безопасности, но и роль искусственного интеллекта в трансформации процессов, влияние Open Source на развитие инфраструктуры, а также практические кейсы из промышленности, ритейла и финансового сектора.

Привет, Хабр!

В этом году Т1 совместно с ВТБ организовал соревнование Data Fusion Contest 2025 — ставшее ежегодной традицией событие, которого с нетерпением ждут и участники, и мы сами. Фотографии.

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

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

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

Сразу отмечу, что решения и оценки, о которых пойдёт речь, подбирались для работы с большими данными на стеке технологий Apache Hadoop, где для обработки данных использовали фреймворк Apache Spark, СУБД — Apache Hive для анализа данных, оркестратор — Airflow, данные хранятся в колоночном формате Parquet.

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

Вас не удивило, что проблема 1970-х — высокая сцепленность кода — дожила до 2010-го и способствовала изобретению микросервисов? Если так, то вы не удивитесь и узнав, что микросервисы тоже её не решили. Сегодня индустрия относится к ним скептически. За последние десять лет мы поняли, что они не стали панацеей. Архитекторы в мире IT — это не учёные, и даже не художники. Это шаманы. Удачно разбить систему на несцепленные части было сложно в 1970-е, сложно и сейчас.

При этом микросервисы привносят проблемы, которых не было в монолитных приложениях.

Первая часть

Вторая часть

Сейчас, когда мы более-менее представляем, что такое микросервисы, самое время переходить к конкретике. Мы в курсе, что нам предстоит разрабатывать веб-приложения, так что надо узнать, какие средства для этого предлагает .NET.

Первая часть.

Привет, Хабр. На связи команда Т1 Облако. Если вы следите за новостями в мире серверных видеокарт для ML, то точно знаете об Nvidia H100 — вычислительной молотилке на GPU, даже не имеющей видеовыхода. Она играет важную роль в области машинного обучения, анализа больших данных, 3D‑моделирования и много другого. Устройство корпоративного уровня, то есть домой себе такое купят разве что полтора энтузиаста.

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

В любой сфере деятельности есть знаковые фигуры. Признанные эксперты. Лидеры мнений. Программирование не является исключением. Всем нам знакомы имена Кернигана, Кнута, Торвальдса, Скита. Не последним в этом ряду будет и имя Мартина Фаулера. Он написал книгу «Рефакторинг», которую обязан прочитать любой профессиональный программист. Он предложил термин Dependency Injection. Он участвовал в подготовке каталога действительно полезных паттернов проектирования. Он был одним из авторов Манифеста Гибкой Разработки Программ.

В 2014-м вместе с Джеймсом Льюисом Фаулер написал статью о микросервисах, которая начинается словами: «Термин „микросервисная архитектура‟ уже несколько лет применяется, чтобы описать способ проектирования программ»… Очевидно, теме микросервисов без малого десять лет. Можно ли добавить что-нибудь к тому, что уже было сказано и написано за это время?

Оказывается, можно.