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

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

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

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

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

OpenShift и Kubernetes (K8s) выбирают чаще всего для оркестровки контейнеров. Эти инструменты сложно сравнивать напрямую, поскольку Kubernetes — открытое решение (open source), а OpenShift — продукт (дистрибутив) на основе Kubernetes. В этой статье рассмотрены их основные функции и отличия, модели развёртывания и пригодность для различных вариантов использования.

Статья будет полезна тем, кто пока не знаком с этими инструментами и хочет узнать о них больше.

Привет, Хабр! Меня зовут Антон Мамичев, я исполнительный директор Департамента корпоративной архитектуры в Сбере и лидер Школы ИТ‑архитекторов.

ИТ‑архитектура для большой организации имеет исключительное значение. Компании очень важно, чтобы сотрудники обладали необходимыми компетенциями для успешного выполнения поставленных задач, а сотрудникам эти компетенции необходимы, чтобы чувствовать себя увереннее, быть успешнее и расти профессионально. Для достижения этой задачи в Департаменте корпоративной архитектуре (ДКА) была создана Школа IT‑архитекторов SberAX.

Управление таким объёмом уникального контента невозможно по наитию, поэтому мы разработали свой подход, о котором я и расскажу в этой статье.

Привет, Хабр! Меня зовут Станислав Савостин, в СберТехе я занимаюсь системой мониторинга «Маяк». Это наш внутренний сервис, который основан на Prometheus, но включает много доработок и «тюнинга» под наши условия и стандарты работы.

Основная задача мониторинга — быстро выявить проблему (до того, как что‑то упало) и отреагировать, чтобы пользователи не заметили. Из‑за высокого темпа уведомлений и реакций часто возникает риск пойти по неправильному сценарию. Например, перезагрузка брокера Kafka или Artemis занимает около 30 секунд, поэтому упустить такую ситуацию легко, хотя для нас это критически важная метрика. Ложная тревога или задержка передачи метрик — максимально неприятные события, так что мы постоянно дорабатываем систему и уже научились отслеживать перезагрузки сервисов.

Я расскажу, как мы дорабатывали мониторинг, как реагируем на действительно опасные ситуации и что помогает нам ловить дзен, когда все кричат: «Волк!»

Компании, что используют Jenkins в качестве CI/CD‑инструмента, обычно делают несколько экземпляров, если в разработке участвует множество команд или приходится работать с большим количеством проектов. При этом оркестрация Jenkins»ов в командах — не самая простая работа, а во многом ещё и рутинная. С одной стороны, сложно соблюдать все требования сборки и тестирования и вовремя находить согласующих. С другой, одним скриптом невозможно решить всю задачу от получения доступов до вывода релизов в эксплуатацию.

Есть правило, что если система становится слишком сложной, то люди чаще ищут способы обойти алгоритмы, а не следовать им. Чтобы не усложнять систему, а разложить всё по ролям и этапам, мы пришли к созданию собственного инструмента — Orchestra R. С его помощью мы хотели не только автоматизировать работу конвейера CI/CD, но и упростить жизнь всех DevOps‑инженеров. В этом материале поделимся особенностями работы инструмента и опытом эксплуатации в СберТехе.

Проблема наблюдаемости (observability) возникает во всех организациях. Я помогу вам научиться не на своих, а на моих ошибках, подскажу, как обойти грабли и подводные камни. Здесь вы найдёте подборку антипаттернов, которая поможет избежать проблем в будущем.

Меня зовут Кирилл Борисов, я в IT около 13 лет. Создавал DevOps-процессы и инфраструктуру в больших проектах, руководил группой сопровождения. Сейчас SRE-инженер в VK, в проекте VK Реклама.

Привет, Хабр! В прошлый раз мы с вами создавали «Игру жизни» на Godot. Движок показал себя отлично, но для такой простой задачи это всё равно что забивать микроскопом гвозди. Особенно когда речь идёт о веб‑экспорте.

В последнее время стоит заикнуться про генерацию изображений, как все сразу вспоминают про нейросети. Stable Diffusion, Midjourney и прочие модели впечатляют, не спорю. Но давайте взглянем на другую сторону генеративного искусства. Ту, где картинки создаются не гигабайтами весов нейронной сети, а несколькими килобайтами JavaScript-кода.

И кстати раз уж речь зашла про красоту в коде: мы как раз запустили «Конкурс красоты кода 2.0». Самое время показать, что даже простые алгоритмы могут создавать нечто впечатляющее. Именно такие работы, где за внешней простотой скрывается математическая элегантность, часто оказываются самыми интересными.

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

Кстати, сейчас у нас проходит «Конкурс красоты кода». Регистрируйтесь и покажите, как должен выглядеть по‑настоящему чистый код — лаконичный, эффективный и понятный. 

Мы, студенты из МИФИ, Даниил и Александр, пришли на стажировку в Сбербанк в департамент SberData, который занимается развитием внутренней корпоративной аналитической платформы (КАП).Это современная платформа с удобными инструментами созданная для закрытия полного спектра потребностей Сбера в работе с данными, таких как хранение, интеграция, разнообразная аналитика, отчетность, моделирование и контроль качества данных. Все эти направления было бы трудно развивать без отдельного R&D подразделения, в составе которого мы и работаем. Сегодня мы хотим поделиться нашим исследованием в области проектирования алгоритмов в выявлении «токсичных» SQL‑запросов с помощью машинного обучения. Почему же запросы называются именно «токсичные»? Они затрачивают на своё выполнение слишком большое количество ресурсов, а именно времени. На самом деле не только время, но для упрощения мы будем считать только время, так как это ключевой параметр.

Статья посвящена исследованию существующих подходов и их апробации на открытых данных. В качестве общедоступных данных были выбраны данные из таких бенчмарков, как TPC‑H и BIRD. Помимо этого, в статье рассматриваются некоторые трудности, с которыми мы столкнулись при работе над задачей, например, генерация данных и SQL‑запросов, а также миграция между диалектами SQL. В конце статьи мы опишем оригинальный подход, к которому по итогу пришли. В следующей статье мы расскажем о применении полученного опыта для реальной промышленной системы.

Привет, Хабр! Сегодня мы поговорим о том, как сделать код не просто красивым, но и живым. Звучит как научная фантастика, либо вы уже подготовились к очередной банальности про искусственный интеллект, но не в этом посте. В 1970 году британский математик Джон Хортон Конвей показал миру, что даже простейшие алгоритмы могут порождать сложные, живые системы, которые ещё и к тому же полные по Тьюрингу. И что код может быть не только красивым, но и живым.