Курс Технический менеджер продуктов · автор Stanislav Belyaev
EN RU

Радиус поражения (Blast Radius)

6 исходящих · 1 входящих · 7 всего связей

Карта Детали
МАСШТАБ КОМАНДЫ
Monorepo-Specific СПЕЦИФИЧНО ДЛЯ МОНОРЕПО УСИЛЕНО В РАСПРЕДЕЛЁННЫХ КОМАНДАХ

Радиус поражения (Blast Radius)

Радиус поражения shared-библиотеки в монорепозитории — количество проектов и команд, которых затрагивает изменение общего компонента. Большой blast radius означает долгий CI, сложное ревью и высокий риск неожиданных поломок. Управление этой метрикой включает версионирование библиотек, контрактное тестирование и постепенную миграцию потребителей.

Количество сервисов, затронутых изменением одной библиотеки. Уникальный риск масштаба монорепозитория.

КОНТЕКСТ МОНОРЕПО

Одна правка в утилите может затронуть 50+ сервисов. Без анализа влияния такие изменения становятся самым рискованным видом деятельности в монорепе.

КОНТЕКСТ РАСПРЕДЕЛЁННЫХ КОМАНД

УСИЛИВАЕТСЯ: Авария в общей библиотеке, когда эксперты офлайн в другом поясе, ведет к восстановлению, измеряемому сменами, а не часами.

Влияние масштаба
👤 Один / Пара (1–3)
0.1
👥 Команда (4–15)
0.3
🏢 Отдел (15–100)
0.7
🏛️ Организация (100+)
1

Влияние общих библиотек пропорционально количеству потребителей.

6
Влияет на
1
Зависит от

→ Влияет на

▲ Доля неудачных деплоев (CFR)

Изменение общей утилиты, затрагивающее 50 сервисов, имеет радиус поражения в 50× больше, чем изменение одного сервиса.

Google использует Rosie для автоматизированных Large-Scale Changes
Google SRE Book, DORA Research
Распределённые: Баг в общей библиотеке, задеплоенный пока эксперты домена спят в другой TZ, имеет организационное влияние без кого-либо доступного, кто понимает изменение.
▲ Время выполнения тестов

Изменения общей библиотеки запускают тестирование всех потребителей. Больше затронутых проектов = дольше выполнение тестов.

Пропорционально количеству потребителей
Meta Engineering Blog, Google Testing Blog
▲ Скорость Code Review

Изменения, затрагивающие много команд, требуют ревью от многих CODEOWNERS. Каждый ревьюер добавляет латентность.

Требование множественных одобрений
SmartBear Code Review Study, Google Engineering Practices
▲ Кросс-командная координация

Больший радиус поражения = больше команд нужно уведомить и скоординировать. Прямо пропорционально.

Линейная зависимость
Team Topologies, Conway's Law research
Распределённые: Больший радиус поражения + распределение по TZ = экспоненциально больше накладных расходов на координацию. Каждая затронутая команда может быть в разной TZ.
▲ Частота инцидентов

Баг в широко используемом коде может вызвать каскадные падения многих сервисов одновременно.

Риск единой точки отказа
Google SRE Workbook, Etsy Engineering
▲ Размер PR

Атомарные изменения общих библиотек + всех потребителей создают огромные PR.

Могут охватывать десятки файлов в разных сервисах
GitHub Engineering, GitLab Research

← Зависит от

▼ Ясность владения кодом

Четкие границы сокращают случайную связность. Команды не лезут во внутренности друг друга.

Модульные границы предотвращают разрастание
Microsoft Research on Code Ownership, Google Monorepo Study
Карта метрик — Stanislav Belyaev · Анализ — Anthropic Claude Opus 4.6 · Все данные проверены человеком