Если у компании несколько продуктов, направлений или дочерних бизнесов, нужна система, по которой выстраиваются отношения между брендами внутри одной компании, у которой зачастую есть и платформы, и SaaS-продукты, и кастомная разработка, и консалтинг, и инфраструктурные сервисы. Без бренд-архитектуры всё это сливается в "мы делаем ИТ".  

И чем же это плохо? Такое позиционирование не продаёт и не масштабируется. Чтобы разобраться, клиенту нужно приложить усилия, в этот момент он невольно переключает внимание на тех, у кого всё разложено по use case.

Привет, Хабр. На связи Т1 Облако. Если вы интересуетесь генеративным ИИ, то наверняка знаете, что LLM давно превратились из хайповой игрушки в рабочий инструмент для множества бизнес‑задач: от создания небольших чат‑ботов для клиентской поддержки до крупных мультимодальных моделей для генерации текстов, изображений и видео.

И хотя обучение и инференс моделей остаются основной причиной роста спроса на GPU, для участия в этой «вечеринке» не всегда нужен суперкар уровня H100 или H200. Речь о том, чтобы оптимально подобрать GPU под конкретный сценарий, будь то обучение скромного чат‑бота на внутренних руководствах, проектирование или обработка терабайтов видео в 8K или создание корпоративной базы знаний для бигтеха. Под каждый сценарий — свой тип ускорителя, чтобы не ехать за хлебом на Феррари. Именно поэтому мы не стали ставить во все серверы исключительно флагманские видеокарты, а расширили линейку GPU различными моделями как для инференса, так и для гибридных сценариев.

Поделимся техническим обзором серверов с графическими ускорителями H200 и L40S, и их фотографиями прямо из ЦОДа. Расскажем не только о тензорных ядрах, Infiniband и видеопамяти, но и о том, как эти технологии помогают нашим клиентам развиваться.

Как рождаются финтех продукты в условиях регуляторики, импортозамещения и вечного дефицита сеньоров, и почему всё держится на одном человеке, который одновременно технарь, наставник и дипломат?

В ИТ среде финтех компаний давно не редкость услышать: «мы перешли на стримы». Но за этим модным словом скрывается не просто перестановка людей по полочкам. Это попытка совместить несовместимое: скорость стартапа, надёжность инфраструктуры и строгость регулятора. И в эпицентре этого сложного баланса — ИТ лидер команды. Он не Scrum Master, не техлид и не просто менеджер проекта. Он — операционный центр кросс функциональной команды. Тот, кто превращает бизнес идею в рабочий продукт, а хаос требований — в стабильный поток доставки.

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

Привет, Хабр! Меня зовут Ольга Косарева, я инженер данных команды «Прогнозирование финансового результата» Центра разработки решений ALM в ИТ‑холдинге Т1, мы занимаемся созданием современной ALM‑системы (подробнее тут ).

Полтора года назад я пришла в команду и получила задачу дописать и внедрить инструмент для DDL‑операций над данными в экосистеме Hadoop. Моя первая реакция была: «А зачем так сложно? Какой инструмент? Почему нельзя просто выполнить команду ALTER TABLE через Hive?»

В этой статье мы с коллегами Никитой Королёвым и Алексеем Пожар расскажем, в каких случаях целесообразно именно так и сделать, а в каких это приведёт к различным проблемам с данными, что такое Schema Evolution и как мы решаем задачу периодического изменения структур таблиц с нашими отчётами.

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

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

Привет, Хабр! Меня зовут Никита Трофимов, я старший менеджер Цифрового консалтинга Т1. Мы провели исследование российского стартап-ландшафта и хотим поделиться тем, что нашли. Не столько самим инструментом (хотя о нём тоже расскажу), сколько конкретными данными и технологическими решениями, которые обнаружили в процессе.

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

Привет, Хабр! Я - Михаил Персианов (Данила Мастер), я разработчик 1С в ИТ-холдинге Т1.

Сегодня мы с Оппонентом обсудим вечную тему. Конечно же, в контексте 1С, и с неожиданным выводом. Для тех, кто вдруг не в курсе, поясню:

/

В этом обзоре мы собрали ключевые идеи и практические инсайты из серии подкастов, записанных на конференции Industrial++.

Привет, Хабр! Пока рынок обсуждает новые модели и копайлоты, промышленный IT живёт в другой реальности: там AI должен снижать простои, повышать безопасность и приносить измеримый экономический эффект.

Партнёры из «Сферы» как никто другой знают изнанку промышленного IT. Компания разрабатывает инструменты для организации и автоматизации процессов производства на всех этапах жизненного цикла ИТ-продукта. А делать востребованные решения без тесного общения с рынком невозможно. Поэтому в этих подкастах ведущие и гости честно рассказывают, как выбирают сценарии применения ИИ, считают эффективность, встраивают решения в производственные контуры и работают с сопротивлением изменениям.

Привет, Хабр. В этой статье мы разберём ключевые различия между отечественной службой каталогов «Эллес» и её основой — Samba, и расскажем, почему для создания российского аналога Active Directory выбрали именно этот проект с открытым кодом.

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

Как сделала героиня нашей истории Оля. О том, как она посетила все конференции «Импульс Т1» и что из этого вышло, читайте под катом.

Привет, Хабр, на связи команда Т1 Облако. Продолжаем делиться с вами необычными историями из жизни инженеров data-центров. Если вам любопытно, читайте первый и второй выпуски баек, а сегодня расскажем о том, как природные стихии, огонь и вода, устроили суровые испытания для серверов, а отключение электричества и соседские «шалости» превратили рутину в незабываемые удивительные события. Если вы тоже верите, что ЦОДы — это нескучно, то добро пожаловать под кат.

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

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

А я сажаю рядом Оппонента и даю ему возможность пару раз оспорить каждое правило.

Всем привет, меня зовут Сергей Сибара, я фронтенд-разработчик в ИТ-холдинге Т1. Так как при использовании Feature-Sliced Design (FSD) возникает много вопросов и разные люди понимают её по-разному, я решил написать статью-справочник, раскрывающий некоторые подробности методологии.

Привет, Хабр! Меня зовут Миняйлов Лев, я DevOps-инженер в ИТ‑холдинге Т1.

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

Начну с далёкой предыстории. В одном из чатиков нашего Холдинга аналитик задал вопрос: «Как по отчёту 1С получить список таблиц, из которых отчёт берёт данные?»  Началось бурное обсуждение, много предложений. Пара человек предложила взять запрос из СКД отчёта и скормить его ИИшечке с умным промптом. Так как явно по тексту запроса все таблицы не выловишь (да и таблицы могут быть не только в СКД), я отнёсся скептически к возможности получить хороший результат. Но автор предложения быстренько сделал пример, и аналитик ушёл из чатика довольным. Я взял результат на заметку, особо его не разглядывая.

Потом в чатике начали гадать, а зачем всё это нужно. Оказалось — для назначения прав на таблицы. Уже позже обращается как-то пользователь: беда, расшифровка регламентированного отчёта не работает в ЗУПе.

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

Волею судеб мне по работе пришлось посмотреть несколько занятий по подготовка к сертификации 1С:Специалист. И от одного лектора вдруг услышал, что использование в условиях виртуальной таблицы массивов, когда можно применить таблицу, — это плохо и медленно. А на сомнения слушателя он ответил: «Я гарантирую это». Думаю, ошибается человек, чего не бывает. И тут в другом занятии другой лектор говорит то же самое. Тут уже волей-неволей задумаешься: а вдруг я чего не помню уже? Но ведь не раз ускорял запросы, меняя таблицы на массивы. И захотелось проверить. Чем не повод для первой статьи на Хабре?

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

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

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

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

При работе с MapStruct возникает соблазн добавлять небольшие вспомогательные методы прямо в ваш mapper и вызывать их через expression. Однако если такой метод оперирует довольно общими типами (например, String -> String), MapStruct может обнаружить его и применить к другим полям того же типа — даже если вы этого не планировали.

Представьте, как себя чувствуют отечественные производители ПО, когда приходят к корпоративным клиентам, а им говорят: «Ну вот у SAP всё давно работает, у Oracle – поддержка по всему миру, а у вас опять продукт упал после очередного обновления».

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