Привет, Хабр! Меня зовут Миняйлов Лев, я DevOps-инженер в ИТ‑холдинге Т1.
В этой статье предлагаю рассмотреть эволюцию методов развертывания в Helm от v2 к v4, и дополнительно уделить внимание порядку обновления ресурсов в кластере и возможностям влиять на него через хуки.
Начну с далёкой предыстории. В одном из чатиков нашего Холдинга аналитик задал вопрос: «Как по отчёту 1С получить список таблиц, из которых отчёт берёт данные?» Началось бурное обсуждение, много предложений. Пара человек предложила взять запрос из СКД отчёта и скормить его ИИшечке с умным промптом. Так как явно по тексту запроса все таблицы не выловишь (да и таблицы могут быть не только в СКД), я отнёсся скептически к возможности получить хороший результат. Но автор предложения быстренько сделал пример, и аналитик ушёл из чатика довольным. Я взял результат на заметку, особо его не разглядывая.
Потом в чатике начали гадать, а зачем всё это нужно. Оказалось — для назначения прав на таблицы. Уже позже обращается как-то пользователь: беда, расшифровка регламентированного отчёта не работает в ЗУПе.
Для тех, кто с ЗУПом не сталкивался, коротенько расскажу про одну особенность этой конфигурации. В ней часть базовых таблиц в запросах заменяются псевдонимами, называется это механизмом представлений. Это очень краткое и примитивное описание, если подробнее, то придётся писать отдельную статью.
Волею судеб мне по работе пришлось посмотреть несколько занятий по подготовка к сертификации 1С:Специалист. И от одного лектора вдруг услышал, что использование в условиях виртуальной таблицы массивов, когда можно применить таблицу, — это плохо и медленно. А на сомнения слушателя он ответил: «Я гарантирую это». Думаю, ошибается человек, чего не бывает. И тут в другом занятии другой лектор говорит то же самое. Тут уже волей-неволей задумаешься: а вдруг я чего не помню уже? Но ведь не раз ускорял запросы, меняя таблицы на массивы. И захотелось проверить. Чем не повод для первой статьи на Хабре?
Привет, Хабр! Меня зовут Денис, я аналитик в Юнион — системе автоматизации подбора персонала. Как и в любом процессе подбора через HR-системы, у нас постоянно возникает необходимость анализировать данные: чтобы оценивать эффективность рекрутинга, отслеживать ключевые метрики и принимать решения на основе фактов, а не ощущений.
В этой статье я кратко расскажу про Apache Superset, в целом про аналитику подбора, причины и процесс нашего переноса отчетов в новый BI-инструмент, а также поделюсь полезными лайфхаками, которые помогут сэкономить время при работе с дашбордами.
Большинство программ, сервисов и служб работают не сами по себе, а взаимодействуют друг с другом и внешними системами. Без такого «общения» не обойтись при построении больших и сложных приложений — маркетплейсов и интернет-магазинов, соцсетей и онлайн-кинотеатров, агрегаторов отелей и такси. Для передачи данных между различными компонентами распределённых систем придуманы специальные посредники — брокеры сообщений.
Меня зовут Александр Борецкий, я архитектор в Т1 Облако. Поделюсь своим опытом работы с самыми популярными из брокеров сообщений — Kafka и RabbitMQ. Расскажу, как выбрать и настроить подходящий брокер, а также какие архитектурные особенности есть у каждого из них.
При работе с MapStruct возникает соблазн добавлять небольшие вспомогательные методы прямо в ваш mapper и вызывать их через expression. Однако если такой метод оперирует довольно общими типами (например, String -> String), MapStruct может обнаружить его и применить к другим полям того же типа — даже если вы этого не планировали.
Представьте, как себя чувствуют отечественные производители ПО, когда приходят к корпоративным клиентам, а им говорят: «Ну вот у SAP всё давно работает, у Oracle – поддержка по всему миру, а у вас опять продукт упал после очередного обновления».
Мы живём в эпоху, когда относительно молодой отечественный софт оценивают по мировым стандартам с полувековой историей, как будто он должен был родиться со стабильной интеграцией. И это, пожалуй, главная ловушка нашего технологического развития.
Управлять облачной инфраструктурой можно с помощью разных инструментов. И хотя все они позволяют делать похожие вещи, но у каждого из них есть свои особенности. Если сравнивать с автомобилем, то можно сказать, что управление виртуальной инфраструктурой может быть ручным или автоматическим. Выбор зависит от вкусов и предпочтений, задач, уровня навыков сотрудников и масштаба компании.
Сегодня расскажем об инструментах, которые мы предоставляем для управления Т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. Ещё расскажем, как устроены витрины, где живёт логика и как запускаются пользовательские расчеты.
В одной из моих предыдущих статей я писал о фичах между LTS-версиями Java 17 и 21. Сегодня, два года спустя (Как?! Уже два года?!), выходит новый LTS-релиз — Java 25.
Подавляющее большинство проектов пропускают промежуточные релизы и используют только LTS-версии Java. Так что давайте посмотрим, какие возможности новая LTS-версия (Java 25) приносит по сравнению с предыдущей LTS-версией (Java 21).
Говорят, хорошая документация обычно начинается с простых примеров и продолжается постепенным наращиванием сложности. Меня зовут Матвей Крапошин, я ведущий системный архитектор Холдинга Т1, и в этом материале расскажу, как OpenSDN (ex‑Tungsten Fabric) пересылает пакеты между виртуальными машинами (или контейнерами) и как установить OpenSDN vRouter Forwarder в минимальной конфигурации и наладить его работу для пересылки пакетов между двумя контейнерами.
Эта статья — своего рода продолжение первого материала «Почему мы выбрали OpenSDN и как контрибьютим в этот проект»[1]. Одна из её целей — рассказать о виртуализации и сетевых технологиях под капотом Т1 Облако, поделиться знаниями и экспертизой с техническим сообществом и способствовать развитию проекта. Напомню, что виртуальная сеть в облаке Cloud Compute компании Т1 Облако построена на основе избранных компонентов проекта Tungsten Fabric, который потом переименовали в OpenSDN. Наработками по OpenSDN пользуются не только Т1 Облако, но и другие российские и зарубежные облачные провайдеры.
Вы сможете лучше понять, как на самом нижнем уровне работает виртуальный коммутатор OpenSDN — средства для работы с программно‑определяемыми сетями. Углублённое знание принципов работы этого модуля позволит лучше понимать причины ошибок, возникающих при настройке OpenSDN (а также Contrail, OpenContrail, Tungsten Fabric), повысить эффективность диагностики возникающих неисправностей и разобраться в нюансах настройки этого средства поддержки программно‑определяемых сетей.
В предыдущей статье мы рассмотрели, как система Документы способствует выстраиванию процесса управления документацией в административно-хозяйственном отделе (АХО). На этот раз мы рассмотрим отдел кадров.
Привет, Хабр! Меня зовут Александр Митин. Я Java разработчик в компании ИТ-холдинг Т1 с 15 летним опытом, из которых последние 5 лет работаю в финтехе. Мой любимый стек — Java Spring. Я хочу рассказать такое AsyncAPI, как работать со спецификациями, какие есть инструменты и поделюсь нашим опытом перехода на подход API First в наших системах.
В организациях зачастую можно наблюдать картину, когда разные отделы используют разные системы создания и ведения документации. Это ведет к нескольким проблемам:
• Отсутствие контроля структуры и содержания документа.
• Проблема совместимости файлов и форматов.
• Отсутствие единого хранилища и версионированию.
• Замедление согласования из‑за отсутствия интеграции с системами электронного — документооборота.
• Дублирование документов.
• Сложность с отчетностью и аудиторскими проверками — документы, в т.ч. архивные, не хранятся централизованно.
• Дополнительные затраты для обучения персонала и поддержке нескольких систем.
Как можно решить всю совокупность этих проблем? Лучшим вариантом является гибкая система документооборота с возможностью согласования документов прямо в системе, единым хранилищем документов (в том числе архивных) и возможностью отслеживания версий документов, которая может быть использована во всех отделах компании, чтобы не увеличивать количество используемых инструментов и затраты на поддержку систем в компании. И на рынке есть система, удовлетворяющая всем этим запросам — это Сфера.Документы.
Рассмотрим конкретный бизнес‑сценарий, когда административно‑хозяйственному отделу (АХО) нужно закупить мелкое оборудование для ремонта офиса.
Привет, меня зовут Роман Поляков, я инженер по тестированию (QA-самурай) в Т1 Иннотех. В мире ручного функционального тестирования каждый день идёт битва за качество. Смена требований, пропущенные баги, плотные дедлайны и тонны тестовых сценариев могут сломить даже опытного специалиста. Но настоящий QA-самурай не сдаётся. Он превращает рутину в искусство, а стресс — в топливо для роста.
Если вы когда-нибудь думали, что работа QA — это просто сидеть и нажимать на кнопки в надежде, что баги сами обнаружатся, то… вы немного заблуждались! Добро пожаловать в увлекательный и порой весьма запутанный мир тестирования, где каждый день сулит встречу с новыми подводными камнями, ловушками и, конечно же, классическими граблями на пути к качественному продукту.
В этой статье я расскажу вам, как стать настоящим QA-самураем — мастером терпения, наблюдательности и гибкости, который не сгорит от стресса, а, наоборот, прокачает свои навыки и выдержку до уровня дзен. Здесь вы найдёте секреты сохранения нервов, проверенные «пруфы» и простое, но действенное руководство по постановке целей и обретению гибкости, сравнимой с гибкостью одного из самых ловких творений природы — бамбука. Приготовьтесь к путешествию, где ошибки — не враг, а ценный урок на пути к профессиональному совершенству!
История ИТ представляет собой череду волн автоматизации, каждая из которых радикально меняла требования рынка и подходы к разработке. Эти волны не просто внедряли новые технологии, они трансформировали бизнес-модели, создавали новые профессии и переопределяли ценность специалистов. Предлагаю ретроспективно взглянуть на сферу ИТ и пофантазировать, что нас ждёт.
Привет, я Азат Хакимов, аналитик данных команды «ИИ для ИТ Поддержки» в Т1 Иннотех. Мы разрабатываем интеллектуальные системы помощи и автоматизации для команд поддержки. В этой статье я расскажу про одну из задач анализа текстов, с которой столкнулась команда в ходе разработки системы для нулевой линии поддержки.
Задачу, которую пытались решить - наполнение базы готовых решений для RAG сервиса простыми и легкими, с точки зрения ресурсоемкости, методами