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

Чтобы избежать подобного, в Сбере создали и развивают сервис АйболИТ+. Каждый день айтишники бигтеха работают над задачами с множеством зависимостей, в том числе в среде разработки, доступа к стендам, кибербезопасности, удалённой работы. Для простых случаев работает портал — оставляешь заявку и получаешь результат. А в нестандартных ситуациях как раз помогает АйболИТ+.

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

Доброго вам дня, уважаемые Хабражители! В связи с бурным ростом LLM и просто невероятным, прорывными результатами практически ошеломительного качества, всё острее мы погружаемся в вопросы о дальнейшем развитии: «Куда двигаться дальше с точки зрения данных? Где их брать? Какого качества они должны быть? Как их бесшовно встроить в общую канву текущего конвейера? Сколько их вообще надо генерировать?» Всё это порождает массу тревог, размышлений и проводимых тестов. 

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

Но обо всём по порядку. По традиции, всех заинтересованных любезно приглашаю под кат. Также приветствуются мнения, обсуждения и свежий взгляд ;) 

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

Напротив, команды с хорошей коммуникацией повышают свою продуктивность на 20–25 %. Пирамидальная структура речи помогает превратить поток мыслей в логически выстроенный текст. 

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

Привет, меня зовут Владимир Феофилактов, я занимаюсь Android‑разработкой мобильного приложения СберБизнес. Я хотел бы поделиться с вами историей поиска ответа на вечный вопрос: «когда и как чистить граф зависимостей?».

У нас было приложение‑монолит с главным ComponentManager, где строился весь граф зависимостей. Файл был немаленький. Также во всех фрагментах необходимо было вручную создавать DI‑компонент и следить за его чисткой, а разработчики то и дело забывали про это или чистили неправильно.

Потом началась кампания по выносу фичёвого кода в отдельные модули. С каждым новым модулем всё чаще выстреливала циклическая зависимость, и приходилось писать обвязку (прокси‑класс). Главный ComponentManager оставался связующим звеном между фичёвыми модулями, через которое происходил переброс зависимостей, так что он всё ещё был большим и сложным. Иногда рефакторинг, связанный с перемещением кода из одного модуля в другой, вызывал многочасовую борьбу за нахождение пути решения проблемы «почему сборка никак не соберётся?». Иногда, чтобы доставить зависимость из одного модуля в другой, нужно было строить сложные конструкции, как при игре в «Твистер».

Вся эта увлекательная и мучительная игра продолжалась довольно долго, пока на помощь, как бы странно это ни звучало, не пришёл новомодный Compose. Тогда мы только начинали его осваивать, и я решил сделать небольшой pet‑проект, состоящий из двух экранов, с применением Compose для его изучения. Естественно, в этот проект подключил всё самое современное из библиотек, включая Dagger 2. Как обычно, немного повозившись с настройкой DI, в голове всплыла вся та боль, которую мы испытываем в нашем проекте.

Привет, Хабр! Наша команда работает в Сбере и отвечает за развитие аналитического хранилища данных (АХД), а также обеспечение финансово‑аналитической информацией ключевых подразделений. В нашем технологическом стеке используются Greenplum на основе PostgreSQL и Hadoop, что позволяет эффективно обрабатывать большие объёмы данных, гарантируя их надёжное хранение и своевременную доступность для потребителей.

В этой статье мы расскажем об использовании ETL-потоков AUTOVACUUM в наших СУБД.

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

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

Сегодня я хочу рассказать о метриках. Но не о тех, которые обычно обсуждают, к примеру, на конференциях, где каждый рассказывает о своём продукте. Я буду говорить о командных метриках и о нашей команде Sber Data Exchange.

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

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

Привет! Эта статья предназначена для тех, кто хочет быстро освоить основы кибербезопасности, но не знает, с чего начать и куда двигаться. 

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

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

Эта статья — вводная. В ней мы разберём вызовы, с которыми может столкнуться компания в процессе переезда в облако, и возможные способы их решения.

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

Мы — команда, которая обеспечивает D‑People (data‑аналитиков, исследователей данных (data scientist) и data‑инженеров) Сбера удобными и функциональными инструментами для работы с данными. Наш департамент развивает внутреннюю корпоративную аналитическую платформу (КАП). В ней есть множество удобных инструментов, и в статье мы расскажем об одном из них — позволяющем работать с данными на естественном языке.

Привет! На связи снова команда LegalDocs правового департамента ПАО «Сбербанк». В прошлый раз мы рассказали вам о конструкторе извлечения для аналитиков, а сегодня хотим поделиться с вами, как мы сделали «RAG наоборот» — выработали методику автоматизации рутинных задач аналитиков.

Всем привет, меня зовут Максим Ажгирей, я руковожу в СберТехе командой разработки, которая занимается развитием инструмента нагрузочного тестирования (НТ) SyTester в линейке интеграционных решений Platform V Synapse.

У SyTester есть две редакции: Enterprise Edition (EE) и Community Edition (CE). Вторая — бесплатная, мы сделали её совсем недавно и разместили на GitVerse, то есть протестировать её может любой желающий. Сегодня расскажу о том, какие проблемы мы смогли решить благодаря этому инструменту, а также об особенностях каждой его версии. Статья будет полезна разработчикам, которым нужно быстро, не тратя время на сложные настройки, провести нагрузочное тестирование, а также специалистам, которым требуется тестировать приложения с очень большими нагрузками (от 100 000 ТПС) и для различных протоколов.

Привет, Хабр! Мы завершаем серию статей о миграции аналитического хранилища данных с платформы Teradata на GreenPlum. В предыдущих статьях мы рассказали о нашем опыте и результатах автоматизированного переписывания SQL‑скриптов с помощью реализованных сервисов миграции кода и переноса архива данных. В этот раз мы расскажем вам о нашем опыте и результатах кросс‑платформенной проверки качества данных во время и после миграции, а также о трудностях и решениях, связанных с этим процессом.

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

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

Статья предназначена для новичков, которым интересно узнать о задачах DevOps- и Cloud-инженеров, какими навыками им необходимо обладать, что между ними общего и в чём их различия.

Привет, Хабр! Меня зовут Вика. В СберТехе я занимаюсь разработкой продукта Platform V Works:Test Data Management (TDM). Инструмент помогает QA генерировать необходимые синтетические тестовые данные по клику, а не обращаться к смежным командам и тратить на это время. Менеджерам TDM помогает сокращать time‑to‑market продуктов, поэтому лететь на другую планету ради тестов больше не придётся. В этом материале я расскажу, как мы поняли, что нам нужен отдельный инструмент для генерации, какие показатели у нас были в начале пути и к чему пришли сейчас. Поехали!

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

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

Привет! Вы когда‑нибудь задумывались, как некоторые из крупнейших веб‑сайтов одновременно обрабатывают запросы миллионов пользователей без сбоев, или передают ваши данные, направляя вас на правильный сервер? В этой статье для начинающих сетевиков мы углубимся в три важнейших веб‑компонента: прямой прокси, обратный прокси и балансировщик нагрузки. Разбёрем эти концепции простым и понятным языком.