Привет, Хабр! Меня зовут Иван, я DevOps‑инженер в ИТ‑холдинге Т1. В современной разработке автоматизация — это давно не «роскошь», а «базовый минимум». Однако многие команды до сих пор ограничиваются лишь простыми возможностями IDE (Integrated Development Environment), упуская потенциал генерации кода. В прошлом году я выступал с этой темой на конференции Импульс Т1. В статье расскажу подробнее, как перейти к генерации кода в масштабах проекта и зачем разбираться в синтаксических деревьях.

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

Как выбрать правильную платформу, особенно когда у вас нет отдельного штата ИТ‑инженеров и огромного бюджета?

В нашей статье мы разберём ключевые критерии, на которые стоит обратить внимание при выборе системы виртуализации.

…и почему это всё равно лучше, чем Excel

Когда говорят о базах данных, большинство людей представляет себе что-то скучное вроде таблиц Excel, индексов, SELECT * FROM и разработчика, который спорит с DBA о нормализации. Но на практике базы данных живут куда более разнообразной и интересной жизнью. Например, они управляют коровами, пишут музыку, отслеживают космический мусор и даже помогают археологам восстанавливать древние цивилизации.

Команда Т1 Облако собрала интересные примеры использования баз данных — от реально полезных до почти абсурдных, но весьма необычных. Что интересно, почти все они используют те же самые движки, которые стоят у нас в облаке.

Привет, Хабр! Меня зовут Динар, я один из разработчиков службы каталогов «Эллес» в ИТ-Холдинге Т1. Кратко о продукте «Эллес», откуда он взялся и что из себя представляет, писал мой коллега. Подробное описание и документацию можете найти на официальном сайте. Но если коротко, то «Эллес» — это служба каталогов (в основе которой лежит глубоко модернизированный код проекта Samba), функционально аналогичная Microsoft Active Directory, с возможностью работы в гетерогенной среде с бесшовной интеграцией и миграцией клиентов.

Привет, Хабр, я Анастасия Сапрыкина, работаю на стыке двух миров: академического и индустриального. Сейчас в России активно развивается программа найма стажёров (1, 2, 3, 4, 5, 6) — студентов старших курсов — в ИТ‑компании. Знаю не понаслышке, что и стажёрам, и бизнесу очень сложно друг с другом: стажёр не понимает отраслевой привязки и специфики решений, а бизнесу некогда его учить. В этот момент человек понимает: я проучился пять‑шесть лет, причём не в последнем по качеству вузе, но в ИТ и ИИ всё настолько поменялось, что я к ним всё ещё не готов… Поэтому крайне мало студентов бесшовно проходят все эти испытания и вскоре становятся успешными сотрудниками.

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

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

Для исправления подобных недостатков требуется не просто внести правки в код (вроде замены ссылок, начинающихся с «http» на «https»), а произвести целый ряд действий: перенастроить конфигурацию работы программы, понять суть безопасного логирования, найти баланс между необходимым и излишним. Ниже примеры таких решений, а также причины, почему это стоит вашего внимания. Сперва — общая теория, затем — обзор практик безопасного логирования, что будет, если вы его не настроите. Спойлер — сперва поймут, чем вы пользуетесь, затем подберут уязвимости для него, настроят эксплойты и применят.

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

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

Привет, Хабр. Меня зовут Владимир Бурмистров, я главный системный аналитик холдинга Т1. В этой статье хочу посмотреть на WebSocket глазами системного аналитика и архитектора: от конкретики протокола HTTP 101 и фреймов до архитектурных решений с API Gateway, sticky‑sessions и формата постановок задач.

Привет Хабр! Меня зовут Малышков Николай, я 15 лет в ИТ, был тестировщиком, аналитиком, frontend-разработчиком. Однажды я понял, что мне очень нравится строить процессы и организовывать команды. Последние лет 10 я занимал различные руководящие позиции. Сейчас работаю ведущим менеджером проектов в Т1 и готов делиться своим опытом с комьюнити.

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

Всем привет! На связи снова Никита Таскин и Анастасия Ильина. Продолжаем тему о контроле доступа применительно к системным интерфейсам, и на этот раз речь пойдёт об API. Напомним, что первая часть была про авторизацию UI, и ознакомиться с ней можно здесь. У нас всё так же разбор контекста ABAC-авторизации для управления задачами команд разработки в Сфера.Задачи. В этот раз мы глубже окунёмся в архитектуру и спроектируем решения для разных по сложности вариантов атрибутного контроля. Также посмотрим на другой вариант применения нашего экспериментального подхода «постанализ юзкейсов».

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

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

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

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

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

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

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

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

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

В РФ используют азиатскую модель регулирования. Поэтому, как только вам захотелось добавить в базу своей биометрической системы кого‑то, кроме себя, в дело вступают федеральные законы и вся цепочка тянущихся за ними ГОСТов, распоряжений и рекомендаций. Начинается всё с известного всем 152-ФЗ от 27.07.2006, продолжается 572-ФЗ от 29.12.2022 и далее по нисходящей (полный перечень нормативной документации ищите в конце статьи).

Попробуем построить гипотетическую систему сбора, обработки и передачи биометрических персональных данных населения (далее БПДн) в соответствии с этими нормативными актами РФ. В этой статье уделим внимание именно технической архитектуре такой системы.

Всем привет, меня зовут Сергей Сибара, я фронтенд-разработчик в ИТ-холдинге Т1. Эта статья — продолжение предыдущей: Мой справочник по Feature-Sliced Design. На этот раз я рассмотрю, как по моему субъективному мнению улучшить файловую структуру проекта, нарушая рекомендации FSD — архитектурной методологии для проектирования фронтенд-приложений.

В конце статьи есть ссылки на другие подходы к организации файловой структуры фронтенд-приложений.

Если у компании несколько продуктов, направлений или дочерних бизнесов, нужна система, по которой выстраиваются отношения между брендами внутри одной компании, у которой зачастую есть и платформы, и 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. Компания разрабатывает инструменты для организации и автоматизации процессов производства на всех этапах жизненного цикла ИТ-продукта. А делать востребованные решения без тесного общения с рынком невозможно. Поэтому в этих подкастах ведущие и гости честно рассказывают, как выбирают сценарии применения ИИ, считают эффективность, встраивают решения в производственные контуры и работают с сопротивлением изменениям.