Привет. Это статья-туториал про выбор технологии и реализацию проекта нагрузочных тестов для API REST микросервисов. Про себя и специфику продукта, над которым работаю, я подробно описывал тут, когда рассказывал о интеграционных тестах. Здесь этому уделять внимание не буду. Если решитесь продолжать, то Вас ждет длинное чтиво. Результатом потраченного времени и внимания будет понимание того, зачем нужно нагрузочное тестирование, с чего начать, куда двигаться дальше и шаблонный проект нагрузочных тестов, который Вы сможете адаптировать под себя. Все используемые мной технологии в этой статье несут печать Java экосистемы. Это тоже может повлиять на то, решитесь ли Вы продолжать. Поехали ...

Привет, Хабр!

Компания АльфаСтрахование, как и многие другие, столкнулась с необходимостью замены используемых инструментов в связи с санкциями. За последний год мы отказались от Slack в пользу open-source аналога Mattermost, а Jira не без сложностей была заменена на Kaiten.

В нашей команде, которая занимается системой электронного документооборота в части операционных процессов, часто на голосовых встречах и при обсуждении в мессенджере Mattermost возникала необходимость накидать черновики задач в таск-трекер, чтобы потом их дозаполнить. Эта потребность наложилась на мое желание попробовать написать что-то на python, связанное с Chat-Ops.

В процессе написания такого бота я столкнулся с рядом слабо описанных аспектов, о которых и хотел рассказать в статье.

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

По отзывам моих ревьюеров, эта статья ‑ «Инструкция по входу в автоматизированное тестирование и настройка фрейма».

В статье приведена информация о специфике, мотивации создания интеграционных тестов, обосновании выбранных технологий. Как бонус, в конце будет ссылка на обезличенный проект, который с минимальной адаптацией, запускается в работу в краткие сроки. Но «подпилить» его придется.

Привет, Хабр! На связи разработчик АО АльфаСтрахование. В этой статье я хочу рассказать о мультиаутентификации в ASP.NET Core приложениях.

Нам довольно часто нужно писать .NET Core приложения. Нередко они используются для интеграции крупных систем. А в этих системах частенько свой собственный набор учетных записей (далее УЗ) и инструментов по управлению доступа к ним.

При создании интеграции у нас часто возникает проблема, когда в рамках одного запроса нужно нужно аутентифицировать 2 и более учетных записей

Рассмотрим вариант добавления трейсов в Spring Boot 3 приложение с использованием Kafka в качестве транспорта и Zipkin в качестве инструмента для трассировки.

Функциональность соберем в автоконфигурацию для подключения к Spring Boot приложениям.

Всем, привет.  Для самых жаждущих и нетерпеливых эта в этой статье будет про:

• Типы анализа, используемые для/около информационных технологий;

• Систему координат типов анализа и для чего использовать каждый из них;

• Специальные артефакты для каждого типа анализа;

• То, как понять, что в компании/процессе/проекте нужно использовать конкретный тип анализа;

• Акценты и навыки, нужные при использовании каждого типа анализа;

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

Рассуждая, что такое анализ, какой он бывает, какой тип, в каких условиях использовать и какие навыки нужны для того, чтобы его выполнять, я предположил, что будет полезным систематизировать имеющийся опыт и результаты обсуждения с коллегами, слушателями профессиональных программ развития НИУ ВШЭ, МИСИС, интернет университетов. Так появился следующий обзор. Надеюсь, он принесет вам пользу. Рассчитываю на обсуждение. Присоединяйтесь :-)

Привет, Хабр! В этой статье я хотел бы поделиться опытом нашей команды в части интеграции .NET Core и выше приложений с корпоративным хранилищем секретов HashiCorp Vault.

Наши приложения, как и большинство приложений в компании, используют в процессе работы различные секреты (пароли, токены и т.д.). Их, с точки зрения информационной безопасности, нельзя хранить в коде или на компьютере, на котором запущено приложение. Поэтому в компании используется специальное ПО – хранилище секретов HashiCorp Vault.

В чем суть проблемы, с которой мы столкнулись: решение, используемое ранее для получения секретов из HashiCorp Vault в приложение, было не очень удобным и очевидным

По традиции, для самых жаждущих и нетерпеливых, эта статья будет о:

• С чего начинается построение любой архитектуры?

• За счет чего реализуются потенциальные бизнес возможности?

• Кто нужен для реализации намеченных возможностей?

• Как создать цифровые продукты, которые будут удовлетворять требованиям заказчиков, вписываться в намеченные сроки и бюджеты?

• Из чего должна складываться структура продукта и как он должен реализовывать функциональные требования?

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

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

Т.к. речь шла о сервисе, который был написан довольно давно, и в него многие месяцы не вносились изменения, повинуясь принципу “работает - не трогай”, я решил постараться сделать это, не прикасаясь к самому коду сервиса.

В этой статье разберем вариант реализации функционала перезапроса сообщений из семейства resilience шаблонов. Мы поговорим о retry. Точнее обсудим:

1. Что такое устойчивость и какое влияние на нее имеет retry?

2. Анализируем, где применять retry;

3. Реализуем retry;

4. Пишем unit-тесты с wiremock;

5.Делаем starter;

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

Когда пишешь тесты на обширную модель (DTO), ловишь себя на мысли, что сосредоточен не на тестовых данных, а на том, как ловчее избавить себя от написания boilerplate-кода.

Как это сделать? Поискать готовое решение (плагин).

А если его нет? Тогда – написать плагин.

А если не умеешь? Стоит хотя бы начать :)

В первой части статьи мы обсудили стоп-факторы, которые блокировали возможность встраивания методологии CI/CD в процесс облачной разработки, а также способы, которыми они были устранены. Возможность безопасного и прозрачного управления Группами Безопасности командами разработки и используемые решения для осуществления контролей ИБ из библиотеки безопасности.

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

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

Часто эту проблему пытаются решить переписыванием продукта с нуля. Но переписывание с нуля кроет в себе отложенную проблему, так как можно потерять мелкие нюансы и в итоге переписанный продукт будет поначалу болеть "детскими болячками", которые много лет назад были вылечены в legacy. Мы, в АльфаСтраховании считаем, что все члены команды разработки должны понимать, что их материальный успех зависит от того, сколько компания зарабатывает, используя написанный ими продукт. А сколько денег принесет продукт, который постоянно спотыкается и плюется ошибками? И клиентов не удовлетворить ответами из серии: "Ну зато у нас тут микросервисы и неблокирующие стримы". Им важно, чтобы продукт работал быстро и стабильно. А написан ли он в виде скрипта на bash или в виде микросервисов на Scala, потребителям наплевать. Конечно, разработчикам не нужно забывать и о своём развитии — регулярно изучать новые технологии, получать опыт использования их в продуктиве, но не в ущерб бизнесу.

Что с этим делать? Мы нашли для себя ответ, успешно применили на одном продукте и надеемся что этот подход или его части помогут и другим.

Привет, Хабр! Я работаю разработчиком в АльфаСтрахование – в команде, которая занимается электронным документооборотом

В чем суть проблемы, с которой мы столкнулись: несмотря на то, что документооборот внутри компании полностью электронный, на «входе» документы могут поступать к нам в самых разных форматах: отсканированные с бумажных носителей, в «цифре» с ЭЦП или без электронной подписи – чтобы обеспечить сквозную обработку таких документов, в ряде процессов нам требуется распознавать наличие подписи.

У нас в команде есть пару проектов, для которых есть старые frontend. Написаны все они на разных технологиях, но объединяет их одно: нежелание кого-либо туда лезть и что-то править. Команде там кажется страшно, непонятно и неудобно. Любая доработка превращается в головную боль. В очередном проекте нам хотелось не допустить такого развития событий, и, кажется, у нас получилось.

Данная статья предназначена не для полноценных frontend разработчиков, а для членов команд, которым требуется реализовать небольшой frontend не имея должной экспертизы в этом вопросе. И сделать это так, чтобы каждый новый сотрудник без глубокого погружения мог сразу делать небольшие доработки.

При увеличении объёма использования облачных ресурсов возникла необходимость встраивания методологии CI/CD в процесс облачной разработки, так как в текущем варианте скорость раскатки приложений и сервисов хоть и стала быстрее, но по концепции не сильно отличалась от baremetal-инфраструктуры.

Жизненный цикл разработки корпоративного приложения в нашей компании привел меня к, по сути, банальной задаче - “прикручиванию” пользовательской авторизации к фронту приложения. Пользователями приложения должны быть сотрудники компании, а идентификационным провайдером должен стать корпоративный Active Directory (далее AD).

Было принято решение не работать с AD напрямую при авторизации сотрудников в корпоративных приложениях, а использовать для этого довольно удобный брокер авторизации – KeyCloak.

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

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

Изначальная структура сети и почему мы решили от неё отказаться.

Так получилось, что АО «АльфаСтрахование» был одним из первых клиентов, которые начали использовать облачную платформу Яндекс.Облако. Множество фич и функционала, которые сейчас присутствуют в платформе тогда отсутствовали, а перед нами стояла задача организовать крупную сеть с множеством изолированных сегментов.