Представьте: сервис А звонит сервису Б, а тот зависает. Сервис А ждёт, занимает потоки, не освобождает ресурсы. Потом к нему приходит другой сервис — и тоже встаёт в очередь. Так один сбой разрастается по всей системе, как снежный ком. Этот эффект называется каскадным отказом.

Паттерн Circuit Breaker (предохранитель) решает эту проблему. В статье разбираем его на примере ассистента HR с зонтиком, показываем, как настроить Resilience4j, и делимся, какие ошибки стоит (а какие не стоит) учитывать в статистике.

 Описание

Паттерн Circuit Breaker (предохранитель) занимает важное место среди паттернов архитектуры приложений, особенно в микросервисных системах.

В чем его суть. Представим сервис А, который обращается к сервису Б. Сервис Б по каким-то причинам начинает плохо себя вести: долго отвечать на запросы или отвечать ошибкой — например, потерял соединение с базой данных. Тогда начинает «страдать» сервис А: он вынужден долго ждать на каждом запросе, занимая ресурсы — свободные потоки, соединения с БД, удерживая транзакции открытыми.

Проблема распространяется и умножается на всю систему. У сервиса А занимается всё больше потоков, которые ничего не делают, а просто ждут. Если будут заняты все потоки, сервис А станет полностью неработоспособен. Так проблема разрастается по цепочке — этот эффект называется каскадным отказом (cascading failure).

Чтобы решить проблему, сервис А должен иметь защитный механизм, который определяет, что сервис Б сейчас в аварийном состоянии, и временно не обращаться к нему. Этот механизм и называется Circuit Breaker (предохранитель).
 

В распределенной системе понять, что именно произошло во время выполнения запроса, бывает сложнее, чем исправить саму ошибку. Логи показывают события по отдельности, метрики — общую динамику, но без связки между ними картина остается фрагментарной. Мы решили выстроить наблюдаемость на базе OpenTelemetry и использовать Sentry для анализа трейсов.

Микросервисная архитектура решает проблему масштабируемости, но почти всегда создает новую — потерю прозрачности. Один пользовательский запрос может пройти через десяток сервисов, очереди, сторонние API и фоновые процессы. Если где-то возникает ошибка, найти ее источник без полноценной трассировки — задача на часы, а иногда и на дни.

Чтобы избежать этого, мы выстраиваем связку OpenTelemetry + Sentry. OpenTelemetry позволяет стандартизировать сбор телеметрии, а Sentry — централизовать ее анализ. В результате появляется целостная картина работы системы.

Введение в OpenTelemetry: traces, metrics, logs

OpenTelemetry объединяет три типа телеметрии — логи, метрики и трейсы — и задает для них спецификации.

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

Метрики отражают общее состояние системы: время отклика, количество запросов, долю ошибок, загрузку ресурсов. По ним видно, стабильна ли система и есть ли отклонения.

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

Описание архитектуры

Речь пойдет о системе, которая ежедневно обрабатывает большой объем данных, получаемых как единовременно в виде файлов скачиваемых с различных FTP обменников в установленные регламентом промежутки времени, так и данных, получаемых в онлайн режиме в виде асинхронного стриминга информации посредством Kafka\RabbitMQ.

Как организовать пакетную генерацию Excel отчетов на Java, чтобы пользователи могли запускать десятки и сотни документов за раз без зависаний и таймаутов? Разбираем архитектуру решения на Spring Batch, схему обработки, расчет прогресса и интеграцию с фронтендом.

Проблема генерации больших Excel отчетов

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

На практике пользователи могут запускать печать десятков или сотен документов одновременно. Если обрабатывать большой объем данных синхронно в рамках одного HTTP запроса, система неизбежно упирается в таймауты. Браузер ждет ответ, сервер удерживает соединение, ресурсы блокируются.

На Python бэкенде для подобных задач используется Celery с Redis в роли брокера и оркестратора. Для Java сервиса мы выбрали Spring Batch — фреймворк, предназначенный для пакетной обработки данных с поддержкой чанков, хранения состояния и восстановления после сбоев.

Архитектура Spring Batch: Job, Step, Tasklet

Spring Batch строится вокруг трех ключевых понятий (подробнее в официальной документации или в более коротком туториале на Baeldung):

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

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

В предыдущей части мы разобрали:

До этого мы говорили о том, где лучше не экспериментировать. Но интерфейсы все же меняются — и иногда довольно радикально. Это подтверждается современными UX-трендами и анализом развития интерфейсных решений.

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

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

Хороший пример — автосохранение. Когда-то закрыть документ без ручного сохранения означало потерять работу. Сегодня автосейв — базовое поведение системы, о котором пользователь даже не задумывается. Та же история с бесконечной прокруткой. Infinite scroll начинался как экспериментальная альтернатива пагинации, а сейчас это норма для лент, каталогов и социальных сервисов.

Чаще это происходит в B2C-продуктах, где аудитория легче адаптируется к новому. В B2B все иначе: интерфейс — рабочий инструмент. Любое изменение влияет на скорость работы и экономику процессов. Поэтому здесь особенно важно понимать, где нововведение действительно улучшает сценарий. 

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

Немного о проекте

Проект представляет собой распределенную систему, состоящую из двух web-порталов на React, порядка двадцати микросервисов на .NET и нескольких интеграций со сторонними системами. Все компоненты участвуют в одном сквозном бизнес-процессе, а релизы выходят регулярно — в среднем раз в две недели.

QA-инженер подключился к проекту уже после начала активной разработки. В этот момент мы осознанно отказались от наращивания объемной ручной тестовой документации и сделали ставку на E2E-автотесты.

Почему Е2Е?

Поддержание ручного регресса в актуальном состоянии задача важная для стабильного развития, но требует существенных затрат времени, вычитки и сверки с обновлениями. Часть кейсов теряют ценность, нужно время на их обнаружение. E2E-автотесты, напротив, становятся частью системы: они запускаются регулярно, отражают реальное состояние продукта и дают оперативный и понятный сигнал о готовности к релизу.

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

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

Интерфейс можно сделать «современнее» по-разному: поменять визуал, добавить анимацию, пересобрать навигацию. Но в процессе можно увлечься и забыть, что пользователю нужнее результат, а не обновление дизайна. Давайте поговорим о ситуациях, когда лучше ничего не менять.

Фразу «давайте сделаем современнее» можно услышать и от бизнеса, и внутри продуктовой команды. Обычно за ней стоит не конкретная задача, а ощущение, что интерфейс устарел и требует изменений.

Пользователь при этом не думает категориями «современно» или «устарело». Он открывает продукт с вполне прикладным ожиданием: выполнить действие и не задумываться о том, как именно устроен пользовательский интерфейс.

Интерфейсы, конечно, меняются, но пользовательские привычки и ожидания формируются годами и обновляются гораздо медленнее. Это хорошо подтверждается практикой UX-паттернов: устойчивые решения сохраняются именно потому, что снижают когнитивную нагрузку и помогают пользователю действовать на автомате. Эту же мысль хорошо раскрывает разбор Якоба Нильсена про AI-агентов и пользовательские ожидания.

Когда их ломают без необходимости, это почти всегда отражается на скорости работы, количестве ошибок и общем отношении к продукту.

Контекст здесь тоже играет решающую роль:

Сегодня мы сравним основные фреймворки: их плюсы и минусы, поделимся своим опытом работы с каждым и поможем понять, какой же лучше выбрать для своего проекта?  

Тестировать вручную увлекательно только в первый раз. Но потом это все больше превращается в рутину, ты устаешь от однообразия, а взгляд начинает замыливаться. Это естественно для человека. Что же с этим можно делать? Можно автоматизировать.

E2E — это тестирование сквозного бизнес-процесса глазами пользователя: от входа в систему до финального действия. В этой статье мы сравним три фреймворка — Selenium, Cypress и Playwright — на основе личного опыта и технических особенностей, чтобы помочь вам сделать осознанный выбор.
 
Зачем автоматизировать UI и почему не мобилку? 

Почему UI? Веб-интерфейсы — основной канал взаимодействия для большинства корпоративных и B2C-продуктов. Их стабильность критически важна.

А почему не мобильные приложения? Автоматизация мобильного тестирования — это дорого. Нужен «зоопарк» реальных устройств или сложные симуляторы, поддержка двух платформ (iOS/Android), а стоимость и сложность поддержки часто перевешивают выгоду. Для многих проектов ручное мобильное тестирование остаётся оптимальным. Поэтому сосредоточимся на вебе.

Selenium

Самый популярный фреймворк. Это как конструктор. То есть огромная система, которую ты сам строишь и сам делаешь как надо. Единственная ее проблема в том, что поддерживать и настраивать ее довольно непросто. И для того, чтобы она работала, нам нужны драйвера (Selenium WebDriver), которые нужно периодически обновлять. Конечно, это можно обойти с помощью драйв-менеджера, но это тоже требует определенных навыков.
 
Сейчас очень популярны два фреймворка: Cypress и Playwright

В современных условиях любая растущая компания рано или поздно сталкивается с необходимостью централизованного управления доступом сотрудников к информационным системам. Какое решение выбрать в такой ситуации?

В мире информационных технологий нет ничего постоянного. Стандарты меняются: если раньше стандартом было развертывание локальных серверов и отдельных учетных записей, то сейчас фокус сместился в сторону централизованного управления идентификацией. Современным базовым стандартом для любой развитой IT-инфраструктуры стал Единый Вход или SSO (Single Sign-On).

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

Наша команда на практике прошла путь интеграции с различными SSO. Мы работали с такими решениями, как WSO2 и ADFS, и каждый раз убеждались в том, насколько SSO важен для инфраструктуры.

Этот опыт позволил определить требования к Identity Provider’у: открытость, масштабируемость и возможность адаптации под быстро меняющиеся бизнес-задачи. И здесь на первый план выходит Keycloak.

Почему именно Keycloak?

В отличие от многих аналогов, Keycloak — это решение с рядом преимуществ:

Практический гайд по внедрению requirements testing: процессы, чек-листы и измеримые результаты с реального проекта.

Знакома ли вам такая ситуация: задача прошла аналитику, разработку, даже тестирование — и на приемке заказчик говорит: «Это не совсем то, что я хотел»? Доработки, сдвиг сроков, перепланирование спринтов. Корень проблемы часто лежит не в коде, а в требованиях.

В этой статье мы расскажем о практике тестирования требований (requirements testing) — методе, который позволяет находить противоречия, неоднозначности и логические дыры еще до начала разработки. На реальных проектах это дает снижение количества багов в 2-5 раз и экономию до 30% бюджета.

Что такое тестирование требований и зачем оно нужно?

Тестирование требований — это ранняя проверка и валидация требований до начала разработки. На этом этапе оценивается их полнота, логическая целостность, непротиворечивость и проверяемость.

Основная цель — убедиться, что требования:

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

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

Параллельно изменился пользовательский трафик: заметно выросла доля Safari на планшетах. Но автотесты были написаны на Cypress, а он технически не позволяет полноценно проверять работу в Safari на разных устройствах.

Все свелось к трем задачам:

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

Причина такого поведения оказалась в самом фундаменте: автотесты опирались на статичные, «зашитые» данные, созданные еще при первом покрытии кода. Они были разработаны более трех лет назад и для скорости были объявлены в виде констант непосредственно перед кодом теста.

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

Процесс разработки

Выбор между классическим подходом и Expo – одно из первых архитектурных решений в проекте. Разберем оба варианта.

Bare React Native

Процесс требует настройки окружения (Xcode для iOS, Android Studio для Android). В упрощенном виде процесс запуска приложения для разработки выглядит следующим образом:

React Native прошел путь от решения с фундаментальными архитектурными ограничениями до платформы с современным, производительным ядром. В этой статье мы разберем, как работала старая архитектура на основе Bridge, как ее заменили JSI, Fabric и Hermes, и в каких случаях React Native - оптимальный выбор для проекта.

Старая архитектура с Bridge

В основе этой архитектуры лежат асинхронный Bridge. Нативный код и JavaScript работали в отдельных потоках. Общение между ними происходило через Bridge, который передавал сообщения в формате JSON.

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

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

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

Таблицы в отчетах — это обычно строгие строки, столбцы, цифры, статусы. Их сила в структуре и предсказуемости. Но как только появляются вложения (PDF, сканы, договоры), возникает дилемма:

Делимся практическим кейсом рефракторинга автотестов учетной системы: от линейных скриптов к архитектурному подходу, который ускорил написание тестов в три раза.

Технический долг в автотестах — это катастрофа, которая нарастает незаметно. Сначала «простые и быстрые» линейные скрипты кажутся хорошим решением, но с ростом продукта они превращаются в «спагетти-код», где любое изменение в интерфейсе вызывает часовую рутину правок. Мы прошли этот путь в проекте по разработке учетной системы и нашли выход через внедрение архитектурного паттерна Page Object Model (POM).

Состояние «до» с линейными автотестами

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

Современные комплексы бизнес-приложений отличаются высокой сложностью, из-за чего могут происходить сбои - сообщения теряются, consumer’ы падают, очереди переполняются. Поделимся реальным кейсом, в котором Eventual Consistency удалось обеспечить без серьезной переработки существующих систем.

Обеспечение Eventual Consistency в сложных системах

Уже давно стандартом де-факто стали микросервисы, поэтому практически любая система представляет собой набор компонентов, взаимодействующих между собой как синхронно (например, по REST), так и асинхронно — через шины сообщений (RabbitMQ, Kafka).

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

Где именно все может сломаться

Предположим, у нас две системы:

В каждой крупной компании со временем накапливается огромное количество ценной информации — инструкций, регламентов, технологических карт, аналитических отчетов. Однако в большинстве случаев эти данные висят «мертвым» грузом в архивах и папках. Все необходимое где-то есть, но найти вовремя невозможно. Чтобы знания действительно начали работать на бизнес, нужен инструмент, который сможет оперативно доставить их тем, кому они нужны. И именно такую задачу решает ИИ чат-бот на основе технологии RAG (Retrieval-Augmented Generation).

Когда знаний много, но они не работают

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

Проблема не в нехватке данных — проблема в доступе к ним. Как итог: