Микросервисы *

Если тесты есть, а уверенности в них нет — 10 открытых уроков по тестированию (апрель‑май)

Тестирование в 2026 — это уже давно не только про «проверить, что работает». Это про архитектуру тестов, нагрузку, интеграции и всё чаще — про работу с AI.

Чувствуете, что текущего инструментария уже не хватает (или просто хочется систематизировать практику)? Собрали серию открытых уроков по тестированию — от базовых вещей до более инженерных подходов.

🔥 Что будет:

⓵ 28 апреля 20:00. «Первый нагрузочный тест в Apache JMeter»
_{открытый урок курса «Нагрузочное тестирование»}

⓶ 28 апреля 20:00. «Архитектура тестового фреймворка: от хаоса к стабильности»
_{открытый урок курса «Автоматизатор тестирования на Python»}

⓷ 28 апреля 20:00. «Контрактные тесты в Kotlin: как подружить фронт и бэкэнд»
_{открытый урок курса «Автоматизатор тестирования на Kotlin»}

⓸ 29 апреля 20:00. «Качество C#‑кода: от модульных тестов к системному подходу»
_{открытый урок курса «C#-разработчик. Продвинутый уровень»}

⓹ 7 мая 20:00. «Тестирование микросервисов на Go: почему ваш сервис ломается под 1000 RPS»
_{открытый урок курса «Микросервисы на Go»}

⓺ 19 мая 20:00. «Навыки нагрузочного тестирования и их роль в развитии инженера»
_{открытый урок курса «Нагрузочное тестирование»}

⓻ 19 мая 20:00. «Введение в OpenTelemetry и основы наблюдаемости»
_{открытый урок курса «C#-разработчик. Продвинутый уровень»}

⓼ 21 мая 20:00. «Суперсилы Kotlin для удобных UI‑автотестов»
_{открытый урок курса «Автоматизатор тестирования на Kotlin»}

⓽ 21 мая 20:00. «ИИ как ассистент QA: пишем API‑тесты с нуля»
_{открытый урок курса «Автоматизатор тестирования на Python»}

⓾ 21 мая 20:00. «API Gateway и не только: шаги к идеальной архитектуре внешних API»
_{открытый урок курса «Архитектор программного обеспечения»}

Подборка получилась разнообразной — и это как раз полезно. Можно точечно закрыть конкретный пробел: разобраться с нагрузочным тестированием, контрактами, API‑тестами или архитектурой фреймворка. А можно посмотреть шире — как меняется роль QA, когда тестирование всё теснее связано с разработкой, архитектурой, наблюдаемостью и AI‑инструментами.

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

📌 Посмотрите каталог курсов по тестированию: там уже не отдельные инструменты, а полноценные треки с практикой, архитектурой и реальными кейсами.

[Перейти в каталог]

Бэкенд «тормозит», API ломаются, а архитектура трещит: уроки, которые помогают закрыть эти проблемы

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

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

• 22 апреля 20:00. Bun + ИИ: создаём быстрый сервер нового поколения на JavaScript

• 22 апреля 20:00. Symfony Workflow: конечный автомат для реализации бизнес-логики

• 23 апреля 20:00. Многопоточность в C++: как писать быстрые и безопасные приложения

• 23 апреля 20:00. Паттерны RESTful API. Как проектировать удобные, масштабируемые и гибкие API?

• 28 апреля 20:00. Фоновые задачи в Django: работа с Celery

• 30 апреля 20:00. Поиск в базе знаний: где векторы ошибаются, а графы помогают

• 4 мая 20:00. Интерфейсы в Golang изнутри

• 5 мая 20:00. Postgres + JSON: реляционная мощь, документная гибкость

• 5 мая 20:00. Архитектурные решения в бэкенд-разработке

• 6 мая 19:00. Разработка проекта на Kotlin: коллаборация человека, архитектурных шаблонов и ИИ-команды

• 6 мая 20:00. Rust в деле: пишем многопользовательский чат с сервером, клиентом и CLI

• 7 мая 20:00. От кода до Kubernetes за полтора часа

• 7 мая 20:00. Тестирование микросервисов на Go: почему ваш сервис ломается под 1000 RPS

• 13 мая 20:00. Kafka Streams DSL

• 13 мая 20:00. ClickHouse для аналитики больших данных: практические кейсы и связь с NoSQL-экосистемой

• 14 мая 20:00. Взаимодействие с базой данных и миграции на Go

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

Конец микросервисного угара: как Amazon, Uber и Netflix внедряли монолиты

Весной 2023 года Prime Video (Amazon) выкатил кейс, который для многих стал страшным сном: они слили красивую микросервисную оркестрацию и снизили стоимость инфраструктуры более чем на 90%.

Что они сделали? Перестали гонять данные через S3 между десятком серверлесс-функций ради банальной обработки видео. Они собрали те же самые компоненты (медиаконвертер, детекторы) в один контейнер. Вызов функции в памяти оказался быстрее и на порядок дешевле, чем "облачная магия".

Шок-контент? Только для тех, кто перечитал умных книг. Остальные просто кивнули.

Скрытый налог, о котором не пишут в книжках

Мы все прочитали «Чистую архитектуру» и умеем рисовать квадратики. Мы научились резать монолиты вдоль и поперек. Но в лучших практиках почему-то обходят главный вопрос: во что это реально обходится бизнесу?

Распределенные системы — это не бесплатный апгрейд. Это класс расходов, которого физически нет в монолите.

Вы платите за:

1. Пересылку данных по сети вместо вызова method() в памяти.

2. Отладку ада, когда для исследования бага нужно поднять логи 7 разных сервисов.

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

В итоге мы получаем внешне технически совершенную систему, которую никто не может окупить. Бывает, что переход в микросервисы — это не инженерное решение, а следование вере.

Опыт Uber

У тебя 5 сервисов — ты держишь их в голове. У тебя 500 сервисов — ты не инженер, ты -- смотритель в зоопарке.

В 2016 году в компании Uber поймать баг означало пройти по 50 сервисам из 12 разных команд. Инженеры тратили больше времени на синхронизацию в слаке, чем на написание кода.

Решение Uber (DOMA) для многих стало интересным: они не стали переписывать код в монолит. Они сгруппировали этот зоопарк по реальным доменам и прикрыли их общими шлюзами.

Монолит 2.0: как было в Netflix

В 2012-м Netflix тушил каскадные отказы через Hystrix. Но для длинных бизнес-процессов (прием контента, кодирование, раскатка по CDN) это было как пластырь на переломе. Инженеры собирали логи руками.

В 2016-м они выкатили решение Conductor — оркестратор. По сути, это монолитный движок с UI для визуализации потоков своих микросервисов. В Netflix не побороли сложность, а переупаковали её. Теперь им нужна отдельная команда, чтобы поддерживать монолит который оркестрирует микросервисы.

Прежде чем пилить новый сервис или склеивать старый, ответьте себе на три вопроса.

• Может ли одна команда выкатить фичу без согласования с пятью другими? Если для баг-фикса нужна координация 10+ команд — границы проведены неверно. Вы строите самый худший в мире архитектурный паттерн: распределенный монолит. Вы получите все минусы микросервисов и все минусы монолита одновременно.

• Какая доля бюджета уходит на бизнес-логику, а какая — на то, чтобы сервисы могли просто "договориться"? Готовы ли вы содержать сложный слой оркестрации (как Prime Video) только ради того, чтобы система технически работала?

• Есть ли у вас цифры, по которым вы поймете, что архитектура перестала окупаться? Prime Video начали с серверлесса и слепили всё в один процесс под реальной нагрузкой.

Выводов не будет, вы сделаете их сами.
Послушать расширенную версию статьи как сказку на ночь без донатов и рекламы можно на Яндекс.Музыке, Звуке и Apple Podcasts.

tg https://t.me/i_am_analyst

Установка, настройка и использование NATS 

Брокер сообщений для микросервисов — звучит страшно, но только пока не разберешься. NATS написан на Go, запускается за минуты и не требует сложной инфраструктуры. 

В блоге разобрали, как установить NATS на Linux и Windows, настроить аутентификацию, TLS и JetStream — и сразу проверить всё это из консоли. 

Читайте полный разбор на сайте Рег.облака.

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

С некоторым опозданием предлагаем вам почитать обзор на переведённую нами книгу Диего Пачеко и Сэма Сгро "Принципы модернизации программных архитектур". Обзор сделали в своём корпблоге специалисты дружественной нам компании SSP-Soft. Книга появилась в продаже в начале декабря, пока только бумажная версия.

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

Приятного чтения!

Многие используют подход API First в проектировании систем, но зачастую даже не задумываются, что порождают таким образом сервисы с анемичными доменными моделями, проектируя по сути REST-обертки над базой данных с отсутствием какой-либо бизнес-логики.

API First и Богатая доменная модель не являются взаимоисключающими понятиями, если правильно выстроить процесс и архитектуру.

Главная проблема: API First фокусируется на контрактах внешнего мира, что часто приводит к созданию DTO/Model классов, которые являются чистыми структурами данных без поведения (анемичная модель).

API First — это про контракты, а не про реализацию. Не позволяйте инструментам кодогенерации диктовать структуру вашей доменной модели!

Правильный workflow:

1. API Design First: Создайте/обновите OpenAPI спецификацию.

2. Генерация DTO: Сгенерируйте или создайте классы для API‑контрактов.

3. Projection First: Спроектируйте доменную модель независимо от DTO, фокусируясь на поведении и инвариантах.

4. Создание Mapping Layer: Напишите преобразователи между DTO и Domain Objects.

5. Реализация Application Service: Тонкий слой, который координирует работу домена.

Стек технологий, который помогает:

— MapStruct: Для автоматизации маппинга между DTO и Domain
— JUnit 5: Для тестирования доменной логики
— OpenAPI Generator: Для автоматической генерации DTO из спецификации
— ArchUnit: Для проверки архитектурных правил (например, запрет на анемичные модели)

// ArchUnit тест, проверяющий, что в доменных классах есть поведение
@ArchTest
static final ArchRule domain_models_should_have_business_methods = 
    classes()
        .that().resideInPackage("..domain..")
        .and().areAnnotatedWith(Entity.class)
        .should().containAnyMethodsThat(
            DescribedPredicate.describe(
                "have business methods", 
                method -> !method.getName().startsWith("get") && 
                         !method.getName().startsWith("set")
            )
        );

Приглашаем на бесплатный вебинар «Микросервисы: 5 главных ошибок и как их избежать с самого начала». Обсудим, какие ошибки возникают при переходе на MSA: от не тех границ сервисов до хаоса и технического долга. Вы узнаете, как с самого начала проектировать архитектуру правильно и получите чек-лист «10 признаков здоровой микросервисной системы» чтобы не создать «распределенный монолит».

‼️ Обратите внимание, что чек-лист будет выдан только участникам эфира.

🕓 Когда: 25 ноября, 16:00–17:00 (Мск)

👨‍🎓 Спикер: Бурцев Николай — cпециалист по архитектуре ПО, проектированию MSA, .NET-разработке.

Разберём:

1️⃣ Неправильное выделение границ микросервисов: бизнес-декомпозиция против технической.

2️⃣ REST-зависимость: когда API превращается в паутину.

3️⃣ «Всё через брокер»: когда Kafka и RabbitMQ создают больше проблем, чем решают.

4️⃣ Архитектура без инфраструктуры: CI/CD, наблюдаемость, DevOps-влияние.

5️⃣ Архитектура без коммуникации: стандарты, код-ревью, управление качеством.

👉 Записаться

Минималистичные healthcheck-утилиты для Docker-контейнеров

Однажды я был маленький, и задавался вопросом - вот собираешь ты свое приложение, нежно помещаешь его в Docker-образ, заботишься о том чтоб и зависимостей было поменьше, и скомпилируешь его так чтоб итоговая каша из байт было погуще, но покомпактее; используешь scratch, статическую линковку, но чтоб "из коробки" был еще и healthcheck - приходится или писать свой мальний чекер каждый раз, или тянуть статичкски слинкованный curl/wget, если приложение работает как http сервер.

Потому что без healthcheck жизнь ну совсем не торт, даже при локальной разработке, когда запускаешь уже готовые образы, ставишь их в зависимость для других (в том же docker compose) - без него это все работать не будет так, как тебе хочется - демоны будут стучаться друг к другу без уважения и учета, готово оно в этому или нет.

Так родился microcheck - набор крошечных статически скомпилированных бинарников, созданных специально для healthcheck-ов. Они не имеют зависимостей от динамических библиотек, написаны на C, и работают даже в scratch и distroless образах, да умеют корректно возвращать exit-коды, понятные Docker’у (0 - здоров, 1 - приходи завтра).

В комплекте:

• httpcheck — проверка HTTP-эндпоинтов (~75 KB)

• httpscheck — то же самое, но с TLS и автоопределением протокола (~500 KB)

• portcheck — проверка TCP/UDP-портов (~70 KB)

У вас в продакшене наверняка Kubernetes, и все проверки делает kubelet - скорее всего, вам не нужно ничего менять. Но если вы запускаете контейнеры в «голом» Docker’е или других рантаймах без встроенных healthcheck-ов - такие инструменты могут здорово упростить жизнь.

Как выглядит в деле:

# Было (+~10MB)
RUN apt update && apt install -y curl && rm -r /var/lib/apt/lists/*
HEALTHCHECK --interval=10s CMD curl -f http://localhost:8080/ || exit 1

# Стало (+~75KB)
COPY --from=ghcr.io/tarampampam/microcheck /bin/httpcheck /bin/httpcheck
HEALTHCHECK --interval=10s CMD ["httpcheck", "http://localhost:8080/"]

Разница по размеру в десяток мегабайт против семи десятков килобайт, а в качестве бонуса - не нужен shell-процесс, всё работает напрямую и быстро (а еще и в переменные окружения умет).

Поддерживаются все популярные архитектуры (x86_64, ARM, ppc64le, s390x и др.), есть готовые образы в GitHub Container Registry и Docker Hub.

Посмотреть исходники, примеры Dockerfile и prebuilt-бинарники можно тут: github.com/tarampampam/microcheck

Пошаговый гайд по работе с RabbitMQ

RabbitMQ — брокер распределенных сообщений, разработанный на основе стандарта AMQP (Advanced Message Queuing Protocol). Этот инструмент собирает потоковые данные из нескольких источников, после чего распределяет и маршрутизирует их для дальнейшей обработки. Выбираем брокер сообщений и подробнее знакомим с его возможностями.

Бенефиты RabbitMQ, которые выделяют его на фоне других похожих сервисов: 

• надежность — все сообщения в RabbitMQ будут доставлены с соблюдением порядка, даже в случае технический сбой;

• масштабируемость — может работать с большими объемами данных. Также его можно развернуть не только на отдельном сервере, но и в распределенной среде;

• гибкость — поддерживает большое количество сценариев для маршрутизации и распределения сообщений. Это позволяет сочетать программу со многими приложениями.

Как настроить RabbitMQ на трех операционных системах: Ubuntu, Debian и CentOS Stream, а также об основных принципах работы этой технологии — читайте в подробном гайде в базе знаний Рег.облака.

Рецепт приготовления кролика от нашего Backend Lead U^ｪ^U

Брокеры сообщений, в частности RabbitMQ, широко применяются во всем IT. Однако это далеко не магическая коробка, а написать код так, чтобы не потерять свои сообщения — крайне нетривиальная задача.

Этим летом наш Backend Lead Витя Михайлов выступил на Saint HighLoad++ 2025, где рассказал, как же правильно готовить RabbitMQ, и поделился классными кейсами.  

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

Тестируем микросервисное приложение с кучей интеграций — четыре совета из практики  

На одном из финтех-проектов наша команда тестирования столкнулась с серьезными вызовами: нестабильные партнерские API, отсутствие тестовых сред у партнеров, лимиты на запросы и риски всё сломать одним обновлением.

В этом посте — примеры, как команда с этим справилась и как можно поступить в похожих ситуациях. Эта подборка может сэкономить кому-то часы (а то и дни) работы.

🛠️ Внешние сервисы без тестовых контуров

Решение: собственный мок-сервис на основе WireMock.

Как он работает:

• тестировщик задает нужный ответ и отправляет его через HTTP-запрос в БД;

• нужные вызовы подменяются в конфигурации;

• при тестировании запрос уходит не во внешний API, а в мок, который отдает нужный ответ.

Моки у нас кастомные, конфигурируются через Swagger, и не завязаны напрямую на CI/CD — это упрощает запуск и дает гибкость.

Плюс: так мы не зависим от внешних API, которые то работают, то нет.

💸 Платные вызовы и лимиты на тестовые запросы

Решение: изолированные стенды и замещение моками везде, где возможно.

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

Плюсы:

• не сжигаем бюджет;

• эмулируем ошибки и нестандартные ответы;

• ускоряем тесты без зависимости от внешней стороны.

🔄 Нестабильность интеграционных тестов

Решение: изоляция и моки как защитный слой.

Микросервисная архитектура — это боль, когда один упавший сервис ломает релиз. Поэтому мы:

• эмулируем нестабильные вызовы моками;

• изолируем свою часть и фокусируемся на ее стабильности;

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

🤝 Десятки команд, завязанных на общий процесс

Решение: интеграционные проверки и ревью на совместимость.

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

• общие тестовые фреймворки и единый подход к интеграционным тестам;

• сценарии, которые включают зависимости от других команд;

• проверка обратной совместимости: если что-то ломает чужой функционал — фича не проходит MR.

Подробнее о каждом из подходов читайте в статье QA-инженера AGIMA Святослава Волохова.

Что такое архитектура ПО и почему она не про красивые диаграммы

🏗️ Архитектура программного обеспечения — это не просто модное слово для повышения ставки на собеседовании. Это фундамент, на котором строится вся система.

Что это такое на самом деле?
Архитектура ПО — это структура компонентов системы, их взаимосвязи, взаимодействия с внешней средой и принципы разработки. Звучит скучно? А вот и нет! Это как план города: без него у вас получится не Москва, а какая-то деревня Гадюкино с кривыми улочками.

Зачем это нужно?

• Снижает сложность системы через декомпозицию

• Определяет рамки развития (чтобы не росло как раковая опухоль)

• Помогает команде говорить на одном языке

• Экономит нервы и деньги в долгосрочной перспективе

Под капотом архитектура отвечает за:
✅ Разбиение системы на модули (как LEGO, только для взрослых)
✅ Способы взаимодействия компонентов (REST, RPC, события)
✅ Распределение ответственности между модулями
✅ Выбор технологического стека

Простой пример:
Представьте интернет-магазин. Без архитектуры у вас будет один гигантский файл на 50,000 строк, где корзина покупок живёт рядом с логикой оплаты, а пользовательские данные перемешаны с каталогом товаров. С архитектурой — отдельные модули: UserService, CatalogService, PaymentService, каждый со своей зоной ответственности.

🔧 Давайте разберём базовые понятия архитектуры, без которых никуда. Это как алфавит — скучно учить, но без него читать не получится.

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

Пример компонентов:

• Authentication Service (следит, чтобы чужие не лезли)

• Notification Service (шлёт уведомления)

• Data Storage (хранит данные, очевидно)

Интерфейс — способ взаимодействия между компонентами. Это как протокол дипломатии: все знают правила игры, никто не лезет с кулаками.

Типы интерфейсов:

• REST API (классика жанра)

• Message Queue (асинхронные сообщения)

• RPC (удалённые вызовы)

• Database API (работа с данными)

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

Примеры связей:

• HTTP-соединения (веб-траффик)

• TCP/UDP сокеты (низкоуровневая связь)

• Message Brokers (Apache Kafka, RabbitMQ)

• Database connections (пул соединений с БД)

Модуль — логическая группировка компонентов по функциональности. Это как департаменты в компании: HR, IT, Бухгалтерия.

Примеры модулей:

• User Management Module (всё что касается пользователей)

• Payment Processing Module (платежи и транзакции)

• Analytics Module (метрики и отчёты)

Сервис — автономная единица бизнес-логики с чётко определённой ответственностью. Это как мини-приложение внутри большого приложения.

Примеры сервисов:

• Order Service (управление заказами)

• Inventory Service (управление товарами)

• Billing Service (выставление счетов)

Хранилище данных — компонент, отвечающий за персистентность информации. Это как склад или архив компании.

Типы хранилищ:

• Реляционные БД (PostgreSQL, MySQL)

• NoSQL (MongoDB, Redis)

• Файловые системы (S3, локальные диски)

• Кэши (Redis, Memcached)

SLA — характеристики работы сервиса. Это контракт: "обещаю работать 99.9% времени и отвечать за 200ms".

Зачем нужны SLA:

• Понимание ожиданий от системы

• Планирование мощностей

• Определение критичности сервисов

• Основа для мониторинга

Практический пример:
Сервис авторизации должен:

• Отвечать за 100ms в 95% случаев

• Быть доступным 99.95% времени

• Выдерживать 1000 RPS

Чеклист для правильного проектирования:
✅ Каждый компонент имеет чёткую ответственность
✅ Интерфейсы документированы
✅ Связи (способы взаимодействия) определены
✅ Деление на сервисы произведено
✅ Способ хранения данных определен
✅ SLA определены и измеряемы
✅ Зависимости между компонентами минимальны

Помните: хорошая архитектура начинается с понимания базовых элементов. Без этого ваша система превратится в спагетти-код корпоративного масштаба.

NotCVE-2025-0003 и NotCVE-2025-0004

Продолжаю по мере сил пополнять базу проекта NotCVE информацией о проблемах безопасности, которым разработчики не желают присваивать CVE (делал заметку об этом проекте). В этот раз одна проблема в компиляторе Go привела к регистрации сразу 2-х записей:

• NotCVE-2025-0003

• NotCVE-2025-0004

Т.к. помимо самого компилятора Go, пострадал и Kubernetes:

The Go team has released a fix in Go versions 1.21.11 and 1.22.4 addressing a symlink race condition when using os.RemoveAll. The Kubernetes Security Response Committee received a report that this issue could be abused in Kubernetes to delete arbitrary directories on a Node with root permissions by a local non-root user with the same UID as the user in a Pod.

Из сообщения в гитхабе Kubernetes видно насколько заразительна тенденция вместо регистрации CVE называть фикс проблемы безопасности хардерингом:

The Go team has not issued a CVE for this, as it is considered a hardening issue, and the SRC is following that decision as well.

Собственно, в случае с Docker в этом году было то же самое, для них это тоже хардеринг (моё обращение в MITRE так и не привело к появлению CVE, поэтому я зарегистрировал NotCVE-2025-001).

Как видно, ситуации, когда проблемы безопасности не приводят к появлению CVE случаются не редко. А некоторые разработчики даже пытаются оспаривать назначение CVE.

В обсуждениях тестирования микросервисов часто всплывает статья Мартина Фаулера Testing Strategies in a Microservice Architecture. Опубликованная в 2014 году, она опирается на концепцию тестовой пирамиды, сформулированную ещё в 2009-м. С тех пор ландшафт тестирования заметно изменился — в первую очередь за счёт появления и широкого распространения Docker и Testcontainers, которые существенно повлияли на практики и экономику тестирования.

Эта трансформация хорошо отражена в более современных источниках:

• The testing pyramid is an outdated economic model

• Testing of Microservices (Spotify)

• Гарри Поттер и методы прагматичного программирования / Кирилл Мокевнин (Hexlet)

Сам Мартин Фаулер также в более поздней статье On the Diverse And Fantastical Shapes of Testing отмечает, что трактовка "юнит-тестов" далеко не однозначна и зависит от контекста.

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

NotCVE-2025-0001

Прошёл месяц с момента моего обращения в MITRE про нежелание разработчиков  делать CVE из-за фикса в Docker Engine 28.0.0. От MITRE никаких новостей больше не было. Поэтому я обратился в NotCVE (об этом сервисе я делал заметку). Спустя буквально пару дней меня оповестили о создании идентификатора NotCVE-2025-0001.
Проект NotCVE пока ещё мало известен. По этой причине по запросу "NotCVE-2025-0001" пока далеко не во всех поисковиках что-то можно найти (в Гугл нашёл 1 запись, в Яндексе и DuckDuckGo - ничего). Да и идентификаторов в NotCVE пока всего лишь 6. Очень надеюсь, что проект обретёт популярность и количество идентификаторов увеличится. И в первую очередь - из-за повышения осведомлённости об этом проекте и увеличении обращений (из-за нежелания разработчиков признавать проблему и создавать CVE). В данном случае показательно, что идентификатор NotCVE-2025-0001 завели по моему обращению несмотря на то, что проблему нашёл не я. Я просто не смог пройти мимо, увидев нежелание разработчиков регистрировать CVE.

Чек-лист: как настроить мониторинг, который предупредит сбой до его возникновения

Шаг 1. Составьте карту сервисов и зависимостей

• Что включить: микросервисы, БД, очереди (Kafka, RabbitMQ), сторонние API (платежки, SMS).

• Зачем: чтобы понять, как падение одного компонента влияет на систему.

«Падение Redis "уронит" кэширование и увеличит нагрузку на БД».

Шаг 2. Разделите симптомы проблем: срочные vs важные

Срочные (реагировать немедленно!)

• БД: connections > 90%, replica lag > 10 сек.

• Платежный шлюз: 5xx errors > 1% за 5 мин, latency p99 > 3 сек.

• Kubernetes: pod restarts > 5/час, node CPU > 95%.

Инструменты: Grafana OnCall, PagerDuty.

Важные (требуют анализа)

• Рост ошибок 4xx > 5% за сутки.

• Увеличение времени ответа API на > 20% за неделю.

• Падение успешных сессий (Google Analytics).

Решение: алерты в Slack/Email.

Шаг 3. Автоматизируйте рутину

Сбор логов: стек EFK (Elastic + Fluentd + Kibana).

Kubernetes:

• Liveness-пробы → авто-перезапуск пода при сбое.

• Readiness-пробы → остановка трафика на проблемный под.

Redis: настройка политик очистки кэша.

Совет для ленивых:

«Используйте Coroot — он автоматически строит карту зависимостей и предлагает алерты»

Шаг 4. Тестируйте устойчивость

Chaos Engineering раз в месяц:

• Отключайте случайные ноды в кластере.

• Эмулируйте нагрузку в 10 раз выше обычной (Locust).

«Мониторинг должен не только сообщать о проблемах, но и подсказывать, что делать».

Шпаргалка о системном дизайне. Саму статью читаем тут: https://habr.com/ru/articles/915376/

ITFB Group совместно с BPMSoft приглашает на вебинар, посвященный теме организации правильной подготовки к выбору сложных ИТ-решений на примере CRM-платформы.

Вебинар будет полезен компаниям крупного бизнеса (включая Enterprise), планирующим внедрение с нуля или замену legacy-систем как в рамках импортозамещения, так и при смене самописных решений для широкого класса ИТ-систем, автоматизирующих различные бизнес-процессы (BPM, HRM, ATS, КЭДО, SRM, СЭД и др.)

Обсудим:

⏩ Как важно подготовиться к выбору сложных ИТ-решений для крупного бизнеса на примере выбора CRM-системы

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

⏩ Как методология предпроектного обследования (ППО) от ITFB Group помогает создать качественный RFP (запросы предложения)

⏩ Кейсы: ППО незначительно увеличивает сроки и бюджет, но сильно снижает риски

⏩ Как при помощи ППО и гибкого лицензирования вендора можно снизить ТСО в проекте CRM

⏩ Применение ППО для выбора других сложных ИТ-систем (BPM, СЭД, SRM, HRM, ATS, КЭДО)

Спикеры:
Николай Чекин — директор по развитию отношений с партнерами, ITFB Group
Максим Илюхин — директор по продажам, BPMSoft

Дата и время: 29 мая в 11:00

ЗАРЕГИСТРИРОВАТЬСЯ

3 ключевые метрики, которые спасут микросервисный проект

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

Инфраструктурные метрики

Базовые показатели вроде CPU и RAM уже не спасают. Для микросервисов важнее:

Статус подов в Kubernetes:

• Количество рестартов.

• Фейлы readiness/liveness проб.

• Используйте метрику kube_pod_status_ready в Prometheus, чтобы находить «битые» поды.

Трассировка запросов: время выполнения каждого этапа через Jaeger.

Пример: Если поды перезапускаются чаще 5 раз в час — это сигнал к немедленной проверке.

Бизнес-метрики

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

• Конверсию платежей (например, от корзины к оплате).

• Время обработки заказов.

Код для .NET-сервиса:

using App.Metrics;

public class PaymentService {
    private readonly IMetrics _metrics;
    public PaymentService(IMetrics metrics) => _metrics = metrics;
    
    public void ProcessPayment() {
        try {
            // Логика платежа...
            _metrics.Measure.Counter.Increment(MetricsRegistry.PaymentSuccessCounter);
        } 
        catch {
            _metrics.Measure.Counter.Increment(MetricsRegistry.PaymentFailedCounter);
        }
    }
}

Эти метрики интегрируются в Grafana, чтобы вы видели, как каждая транзакция влияет на бизнес.

Пользовательский опыт

Даже 1 секунда задержки может увеличить отток пользователей на 7%. Контролируйте:

• Время отклика API (p95, p99).

• Частоту ошибок 5xx/4xx.

• Структурированные логи с контекстом:

{
  "timestamp": "2023-10-05T12:34:56Z",
  "level": "ERROR",
  "userId": "a1b2c3",
  "operation": "process_payment",
  "message": "Failed to charge card: insufficient funds"
}

Теги вроде userId помогают быстро найти все связанные с ошибкой события.

Почему классический мониторинг не работает для микросервисов и облаков? Переход к Observability

Современные системы давно перестали быть монолитами — теперь это сложные экосистемы из микросервисов, облачных сервисов и распределенных баз. Но если ваш мониторинг всё ещё фокусируется только на CPU и RAM, вы рискуете пропустить критические сбои.

Главные проблемы классического подхода:

1. Невидимые бизнес-сбои: Сервер «живой», но конверсия платежей падает.

2. Поиск иголки в стоге сена: При ошибке в цепочке из 10 микросервисов метрики инфраструктуры не укажут на источник проблемы.

3. Ручная настройка: Часы на алерты для каждого сервиса вместо автоматизации.

Решение — Observability:

Объедините метрики (Prometheus), логи (EFK) и трейсы (Jaeger), чтобы система сама «объясняла» свои сбои.

Пример кода

Отслеживание конверсии платежей в .NET-сервисе:

// Отслеживание конверсии платежей  
using App.Metrics;  
public class PaymentService  
{  
    private readonly IMetrics _metrics;  
    public PaymentService(IMetrics metrics) => _metrics = metrics;  

    public void ProcessPayment()  
    {  
        try  
        {  
            // Логика обработки платежа...  
            _metrics.Measure.Counter.Increment(MetricsRegistry.PaymentSuccessCounter);  
        }  
        catch  
        {  
            _metrics.Measure.Counter.Increment(MetricsRegistry.PaymentFailedCounter);  
        }  
    }  
} 

Код автоматически фиксирует успешные и неудачные платежи. Эти метрики интегрируются в Grafana для анализа бизнес-показателей.

📖 Нужны подробности? Читайте статью на хабре: «Эффективная стратегия мониторинга: ключевые метрики для успешного наблюдения»