☀Объяснение:

Что произошло?
Разработчик изменил API (добавил новое поле в ответ), но не уведомил команду, которая пишет автотесты на клиентской стороне. Старые тесты ожидали старый формат ответа и упали. Это классический пример ломающего изменения (breaking change) в контракте между сервисами.

Что такое тестирование контрактов?
Это практика, при которой обе стороны (поставщик API и потребитель) договариваются о спецификации (контракте) и автоматически проверяют, что ни одна сторона не нарушает его. Инструменты: Pact, Spring Cloud Contract, Postman с коллекциями.

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

Потребитель пишет тест, в котором описывает ожидаемый формат ответа (поля, типы, обязательность).
Поставщик API запускает эти тесты в своём CI и не может выкатить изменение, которое их ломает, без согласования.
Пример контракт-теста на Pact (Python):

```python
from pact import Consumer, Provider

def test_order_contract():
expected = {
"order_id": 123,
"total": 1000,
"delivery_discount": 0 # новое поле
}
# Ожидаем, что API вернёт именно такую структуру
...
```
❌ Почему не другие варианты:

A (модульное) — проверяет функции изолированно, не поймает изменение API.
C (нагрузочное) — проверяет производительность, а не корректность формата.
D (юзабилити) — про удобство интерфейса.

Реальный кейс:
В микросервисной архитектуре компании из 20 сервисов каждый месяц происходило несколько инцидентов из-за несовместимых изменений API. После внедрения контракт-тестов с Pact число таких инцидентов упало до нуля.

Что должен сделать аналитик:

Включить в определение готовности (DoD) требование наличия контракт-тестов для всех публичных API.
Фиксировать в спецификации обязательные и опциональные поля, а также версионирование API.
Требовать, чтобы breaking changes вводились только с новой версией API (v1, v2).

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

#TESTING

Заработай за месяц от 50000₽ на входящих заявках

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

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

Все методы работают 💯. Начни делать продажи и ты

Все уже готово за тебя. Просто бери и делай https://t.me/addlist/yWaHGpxI5ethOGYy

Добавляй себе всю папку https://t.me/addlist/yWaHGpxI5ethOGYy и
Записывайся в подборку🫶

😁😆😁 Ты ведь тоже это замечаешь?

Пока одни «присматриваются» к нейросетям— другие уже зарабатывают на этом 💵

И самое интересное — порог входа сейчас минимальный.
Не нужно быть программистом.
Нужно только одно:
понимать, как именно использовать ИИ под свои задачи.

Я тут собрал папку с экспертами в этой теме.
Можешь добавиться и посмотреть, как это делают другие 👇

https://t.me/addlist/A0vy8zWBM1gyNTky

☀Объяснение:

Проблема: Если сервис склада тормозит, синхронный вызов (A) заставит пользователя ждать. Параллельные вызовы (C) тоже приведут к ожиданию самого медленного. 2PC (D) ещё медленнее и не масштабируется.

Решение — асинхронная сага (Saga):

Пользователь нажал «Оформить» → система сразу отвечает «Заказ принят в обработку».
Событие OrderCreated кладётся в брокер (Kafka/RabbitMQ).
Отдельные обработчики (часто воркеры) слушают события и выполняют шаги: резервирование, списание, уведомление.
Если шаг упал (например, товара нет), запускается компенсация: возврат денег, отмена резерва.
Пример кода (Kafka + компенсация):

```python
# Сервис заказов
def create_order(order):
save_to_db(order, status='PENDING')
kafka.send('order_created', order)
return {"status": "accepted", "order_id": order.id}

# Сервис склада
def on_order_created(order):
if reserve_stock(order.items):
kafka.send('stock_reserved', order)
else:
kafka.send('stock_failed', order)

# Сервис платежей
def on_stock_reserved(order):
if process_payment(order):
kafka.send('payment_succeeded', order)
else:
kafka.send('payment_failed', order)

# Компенсация
def on_stock_failed(order):
kafka.send('compensate_payment', order) # возврат денег
```
Почему это выигрывает:

Пользователь не ждёт — UX высокий.
Система не блокируется на тормозящем сервисе склада.
При сбое можно откатить через компенсации (eventual consistency).
Легко масштабировать обработчики.
Реальный кейс: В Ozon при оформлении заказа пользователь сразу видит подтверждение, а резервирование и оплата идут фоном. Если товар закончился — приходит push‑уведомление, а деньги возвращаются автоматически. Это и есть асинхронная сага.

Что должен заложить аналитик:

Асинхронность для длительных операций.
Идемпотентность обработчиков (чтобы дубликаты не ломали логику).
Компенсации для каждого шага (откат).
Мониторинг «зависших» саг.

Вывод: Асинхронная сага — стандарт для микросервисов, где важна скорость отклика и слабая связанность. Аналитик, предлагающий такое решение, спасает и пользовательский опыт, и надёжность. 🎯

#SYSTEMDESIGN

Всё, можно выдыхать — мы собрали для вас идеальную папку Telegram-каналов 📱 по схеме ALL IN ONE 🔥

Серьёзно. Больше не нужно мониторить сотни источников в надежде найти адекватных авторов. Мы сделали это за вас и заодно попали в эту ПОДБОРКУ сами ✔️

Что внутри? Только лучшее:
* ИИ — не хайп, а реальные инструменты и внедрения
* Технологии — тренды, обзоры, инсайты от первых лиц
* Карьера — как найти работу, вырасти и не выгореть
* HR Tech — кто и как нанимает профессионалов прямо сейчас
* AI Life hacks — как выжить и зарабатывать за границей с помощью возможностей ИИ
Открываете вечером, завариваете что покрепче — и улетаете в чтение с пользой 📑
ПАПКА 👈 здесь, забирайте - там реально круто 👌

📌 Добавляйте в избранное и скидывайте ссылку коллегам. Отписаться можно в любой момент. Остаться — тоже ✔️ * Ссылка ➡️ https://t.me/addlist/g24qP0CEdUs5N2Jk

☀Объяснение:

Почему вертикальное масштабирование (A) не спасёт?
Рано или поздно упираемся в физические пределы (память, CPU, сеть). К тому же медиасерверы (WebRTC) требуют низкой задержки — один сервер физически не обработает миллион пользователей.

Почему B — правильное решение?

Горизонтальное масштабирование (добавление серверов) — каждую комнату можно отдать на отдельный сервер или группу серверов.
Шардирование по географическому признаку — пользователи из России идут на сервер в Москве, из Европы — во Франкфурт, что снижает задержку (latency).
WebRTC Selective Forwarding Unit (SFU) — сервер, который ретранслирует потоки между участниками, оптимизируя трафик. SFU могут быть объединены в кластер.
Пример схемы:

Балансировщик (например, HAProxy) по геолокации направляет запрос на создание комнаты на ближайший SFU-кластер.
База данных комнат шардирована по room_id или географическому региону.
При выходе из строя одного SFU, участники переподключаются к другому в том же регионе (failover).

❌ Почему не C (один сервер на Go)?
Не поможет, проблема в распределении нагрузки, не в языке.

❌ Почему не D (только Redis без репликации)?
Redis не подходит как первичное хранилище для метаданных комнат (нет персистентности, сложно масштабировать запись). Можно использовать Redis как кэш, но нужна основная БД с репликами.

Реальный кейс:
Zoom использует географически распределённые кластеры медиасерверов. При создании комнаты она назначается на ближайший дата-центр, внутри дата-центра — на конкретный сервер. Балансировка и шардирование позволили масштабироваться до сотен миллионов участников.

Что должен заложить аналитик:

Требование к географической маршрутизации (например, «время ответа не более 100 мс для 95% пользователей»).
Отказоустойчивость кластера — при падении одного сервера комнаты перераспределяются.
Мониторинг загрузки медиасерверов и автоматическое добавление новых узлов.
Шардирование БД по room_id или по региону.

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

#SYSTEMDESIGN

☀Объяснение:

Слово «аномалия» — субъективно. Для отдела продаж аномалия — падение продаж на 10% за день. Для отдела безопасности — попытка входа в 3 часа ночи. Для финансового отдела — платеж на сумму более 1 млн рублей. Без явного определения аналитик оставляет разработчику свободу, которая почти гарантированно не совпадёт с ожиданиями бизнеса.

Что должен был сделать аналитик:

Задать уточняющие вопросы:

«Что именно вы считаете аномалией? Приведите 3–5 конкретных примеров».
«Как часто нужно проверять? Раз в час, раз в день?»
«Как уведомлять? Email, SMS, телеграм, дашборд?»
«Кто получатель уведомлений?»
Перевести ответы в проверяемые критерии:

Аномалия = разница между фактическими продажами за последний час и средними за тот же час за последние 7 дней превышает 20%.
Проверка каждый час.
Уведомление в телеграм-бота менеджера по продажам.
Задокументировать примеры:

Пример аномалии: продажи упали с 100 до 70 (на 30%) → уведомление.
Пример не-аномалии: продажи упали с 100 до 92 (на 8%) → уведомления нет.

Реальный кейс:
В финтех-стартапе заказчик просил «автоматически находить подозрительные транзакции». Аналитик написал общее требование. Разработчик реализовал детектор по сумме > 1 млн рублей. На проде выяснилось, что подозрительными считаются мелкие транзакции в необычное время. Переделка стоила 2 недели. После внедрения чек-листа с вопросами к заказчику подобное не повторялось.

Вывод: Любое субъективное понятие должно быть разложено на измеримые бизнес-правила, пороги и примеры. Иначе система будет делать «не то», а вы будете переделывать. 🎯

#REQUIREMENTS

✅AI | НЕЙРОСЕТИ | IT✅

Привет, собрали с коллегами новую папку каналов

Тут и программирование — Python, библиотеки, подготовка к собеседованиям IT-сферы

И новости AI — тренды, апдейты, новые инструменты

И нейросети в бизнесе — автоматизация, идеи заработка для разных сфер

Подписаться тут ➡️ https://t.me/addlist/mrj5tRDW8Os1NDA6

(Успей за 48 часов)

💬 НЕ УПУСТИТЕ ВОЗМОЖНОСТЬ ПОЛУЧИТЬ ДОСТУП В ИНТЕРЕСНЫЕ КАНАЛЫ:

🔖 Экспертные материалы от специалистов по ИИ — без воды, только суть и рабочие инструменты

🔖  Актуальные изменения в мире ИИ, новости — чтобы быть в курсе

🔖 Аналитика, кейсы и разборы ситуаций — всё, что помогает глубже понимать рынок Искусственного Интеллекта и принимать грамотные решения

🤩 Егор Никитин | Event | Нейросети - Нейросети в event сфере, практика использования ИИ. Отделение «ИИ для бизнеса» РЭУ им. Плеханова.
📲 Мы в MAX

В ПАПКЕ ЕЩЕ БОЛЬШЕ УНИКАЛЬНЫХ КАНАЛОВ:

📌 Знатоки Рынка
📌 Новые Предложения
📌 Новые ИИ инструменты

🖥 Забрать папку

Организаторы: 🤩Green.Papka

☀Объяснение:

Почему возникла проблема?
Фраза «изменение статуса» — это неоднозначность. Разработчик интерпретировал её как «любое изменение»? Нет, он решил, что достаточно одного ключевого изменения — финального статуса «Доставлен». Бизнес же подразумевал все статусы: «Принят», «Оплачен», «Передан в доставку», «Доставлен». Без явного перечисления каждый понимает по-своему.

Что такое матрица отслеживания требований (RTM) и критерии приемки?

RTM (Requirements Traceability Matrix) — таблица, которая связывает каждое требование с конкретными проверяемыми пунктами, тест-кейсами и реализацией.
Критерии приемки (Acceptance Criteria) — это список условий, которые должны быть выполнены, чтобы пользовательская история считалась готовой. Они пишутся на понятном бизнесу языке и часто в формате Given-When-Then.
Как должен был выглядеть правильный артефакт?

Пример критериев приемки (Gherkin):

```gherkin
Feature: Уведомление об изменении статуса заказа

Scenario Outline: Отправка уведомления при переходе в конкретный статус
Given заказ находится в статусе "<начальный_статус>"
When статус заказа меняется на "<конечный_статус>"
Then клиенту отправляется push-уведомление
And текст уведомления содержит "<текст>"

Examples:
| начальный_статус | конечный_статус | текст |
| Черновик | Принят | Ваш заказ принят |
| Принят | Оплачен | Заказ оплачен, спасибо |
| Оплачен | Передан в доставку | Заказ передан курьеру |
| Передан в доставку | Доставлен | Заказ доставлен, приятного аппетита! |
| * | Отменён | (уведомление не отправляется) |
```
Что даёт такой список?

Разработчик точно знает, на какие статусы реагировать.
Тестировщик может проверить каждый переход.
Бизнес видит полную картину и может скорректировать до начала разработки.
Никаких «сюрпризов» на приёмке.
Почему не подходят другие варианты?

A (Use Case Diagram) — показывает только общие сценарии (акторы, цели), но не детализирует статусы.
C (ER-диаграмма) — описывает структуру данных (таблицы, связи), а не бизнес-правила.
D (Диаграмма последовательности) — показывает обмен сообщениями между объектами, но тоже не перечисляет статусы.
Реальный кейс из практики
В одной логистической компании заказчик потребовал уведомления «на каждом этапе движения посылки». Аналитик не уточнил этапы. Разработчик сделал уведомления только при смене города (3 этапа). Бизнес же хотел 12 этапов (прибытие на сортировку, убытие, прибытие в регион и т.д.). Переделка стоила двух спринтов. После внедрения практики «явный список в критериях приемки» подобное прекратилось.

Что должен сделать аналитик, чтобы предотвратить проблему?

Перечислить все возможные статусы (взять из модели данных или из общения с бизнесом).
Для каждого статуса указать, нужно ли уведомление (да/нет) и какой текст.
Оформить это в виде таблицы или сценариев Gherkin.
Согласовать таблицу с заказчиком до передачи в разработку.
Включить эти сценарии в тест-план и критерии приемки.
Вывод: Избегайте общих фраз. Любое требование, которое содержит слова «изменение», «различные», «некоторые», «в зависимости от ситуации» без конкретики — это мина замедленного действия. Явный список значений или таблица — дешёвый способ спасти команду от переделок. 🎯

#REQUIREMENTS