Частота DDoS-атак неуклонно растёт. Их количество в 2024 году в мире увеличилось на 108 % по сравнению с 2023 годом. Например, специалисты Центра мониторинга угроз в прошлом году отразили почти 11 тысяч DDoS-атак на российские организации. А самая длительная кибератака длилась более 108 часов. Ни одна компания не застрахована от потенциального ущерба, поэтому нужно знать как распознать DDoS-атаки и предотвратить их.

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

Здесь же мне захотелось сосредоточится исключительно на инструментальной части и предложить свой подход к анализу «синтетики». То есть посмотреть, как можно «развернуть» задачу, оптимизировав подход к ней более комплексно, так как уже поднадоело без конца «шить» лоскутное одеяло из множества тестов и метрик (Perplexity, BLEU, ROUGE, METEOR, BERTScore, GLUE, MMLU). Основной идеей было представление имеющихся данных через другие форматы, чтобы конвертировать и находить повторяющиеся паттерны, тренды, аналогии, элементы и возможные аномалии в данных. Ведь любой алгоритм, каким бы он сложным не был, не может выйти за пределы своей генерации, а следовательно, так или иначе будет создавать одни и те же «детектирующие» элементы.

В современных компаниях корпоративные хранилища данных (Data Warehouse) играют критически важную роль, обеспечивая централизованное хранение и обработку больших объёмов информации. Данные поступают из разнообразных источников: операционных систем, CRM, ERP, IoT-устройств, веб-аналитики, мобильных приложений и других платформ, отражая все аспекты деятельности организации. На основе этой информации компании формируют разного рода отчётность, отслеживают ключевые показатели эффективности (KPI), оптимизируют бизнес-процессы, прогнозируют рыночные тенденции и принимают стратегические решения.

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

Ошибки в SQL-запросах или недостаточное знание структуры данных приводит к потерям времени и снижению точности аналитики. Для решения этих проблем на помощь приходят технологии на основе больших языковых моделей (LLM), таких как GigaChat, GPT, BERT или DeepSeek. Обученные на исторических данных и журналах запросов, они способны автоматизировать подбор таблиц, JOIN-условий и шаблонов SQL. 

Привет, Хабр! Я — один из инженеров Сбера, и сегодня хочу поговорить с вами не о технологиях, которыми мы обычно делимся в корпоративном блоге, а о том, что волнует каждого айтишника, проводящего долгие часы за монитором — о зрении и способах его коррекции. И нет, это не очередной пост про то, как синий свет от монитора убивает наши глаза (хотя и убивает; вроде бы), и не про то, как сидеть ровно и моргать каждые 20 минут (хотя и нужно; но это не точно).

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

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

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

Доброго вам дня, уважаемые Хабражители! В связи с бурным ростом 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‑скриптов с помощью реализованных сервисов миграции кода и переноса архива данных. В этот раз мы расскажем вам о нашем опыте и результатах кросс‑платформенной проверки качества данных во время и после миграции, а также о трудностях и решениях, связанных с этим процессом.

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