Архитектура ломается не только от плохих решений, но и от ложной идеи, будто все важное можно решить один раз в начале проекта. Эта глава показывает противоположный подход: архитектура живет внутри потока поставки изменений и требует постоянной калибровки по мере изменений продукта.
Здесь особенно полезно то, как книга связывает качественные характеристики, отложенные решения, маленькие инкременты, архитектурное управление и обратные связи с реальным ритмом поставки. Такой взгляд помогает не откладывать важные решения бесконечно, но и не цементировать их раньше, чем появился нужный контекст.
На интервью и в архитектурных разборах по этой книге удобно обсуждать процесс, а не только схему: какие решения нужно принимать рано, какие стоит задержать и как проверять архитектурные гипотезы прямо в цикле поставки.
Практическая польза главы
Непрерывное мышление
Переводит архитектуру из разового этапа в непрерывный процесс внутри цикла поставки.
Атрибуты качества в первую очередь
Помогает держать нефункциональные требования в центре решений, а не добавлять их постфактум.
Время принятия решений
Учит откладывать дорогие решения до достаточной информации, но не терять контроль над рисками.
Зрелость на интервью
Показывает на интервью зрелый подход к архитектуре как к процессу, а не только к схеме.
Источник
Книжный клуб CoA
Материал главы опирается на разбор книги в книжном клубе Code of Architecture.
Continuous Architecture in Practice: Software Architecture in the Age of Agility and DevOps
Авторы: Murat Erder, Pierre Pureur, Eoin Woods
Издательство: Addison-Wesley Professional
Объём: 352 страниц
Шесть принципов непрерывной архитектуры: продуктовый подход, качественные характеристики, отложенные решения и архитектура в ритме поставки изменений.
предлагает смотреть на систему не как на набор решений, принятых один раз в начале проекта, а как на постоянную работу с , и внутри реального ритма поставки изменений.
Главный вопрос здесь — тайминг. Часть решений нужно принимать рано, потому что позже их цена резко вырастает; часть стоит сознательно переводить в разряд и держать открытыми, пока контекст не прояснится. Поэтому книга раз за разом возвращает архитектуру в плоскость автоматизации, эксплуатации и , а не оставляет её на уровне схемы на старте.
Связанная книга
Building Evolutionary Architectures
Функции архитектурной проверки, управляемая эволюция и архитектурные кванты.
Шесть принципов непрерывной архитектуры
Шесть принципов непрерывной архитектуры
Один из самых полезных принципов здесь организационный: архитектура и структура команд не должны жить врозь. Авторы связывают его с и с , где границы команд подстраивают под целевую архитектуру, а не наоборот.
Первый разбор: главы 1–2
Глава 1: Почему архитектура важна как никогда
Авторы объясняют, почему в мире Agile, облачной инфраструктуры и инженерной автоматизации архитектор больше не может работать как эксперт, который однажды выдаёт готовую схему. Непрерывная архитектура вводится как дисциплина, которая живёт вместе с продуктом и сопровождает сквозной пример из книги.
Глава 2: Архитектура на практике и ключевые виды деятельности
- Принятие и сопровождение архитектурных решений
- Качественные характеристики и технический долг
- Контуры обратной связи: функции архитектурной проверки и непрерывное тестирование
- Модели и нотации для описания архитектуры
- Архитектура как непрерывный поток решений
Гость разбора
Максим Смирнов — ИТ-архитектор и автор канала «Архитектура ИТ-решений». Ранее занимал позиции главного архитектора в билайне, Банке России и Бинбанк Диджитал.
Связанная книга
Learning Domain-Driven Design
DDD, ограниченные контексты, хранение состояния через события и интеграционные паттерны.
Второй разбор: главы 3–4
В блоке про данные и безопасность книга связывает , , и с архитектурой продукта. Со стороны безопасности акцент смещается на , и как на часть архитектурных решений, а не финальную проверку перед релизом.
Глава 3: Архитектура данных
- DDD: единый язык предметной области и ограниченные контексты
- Полиглотное хранение: SQL и NoSQL
- Модели согласованности и согласованность в конечном итоге
- Хранение состояния через события
- Владение данными и аналитический контур
- Эволюция схем в SQL- и NoSQL-системах
Глава 4: Безопасность как архитектурная задача
- Триада CIA: конфиденциальность, целостность, доступность
- Выявление и приоритизация угроз
- Моделирование угроз
- Раннее встраивание безопасности
- Архитектура нулевого доверия
Упомянутые материалы
Гости разбора
- Вацлав Довнар — независимый консультант по процессам безопасной разработки
- Дмитрий Гаевский — инженер решений для разработчиков, исследовательских инициатив и событийно-ориентированных систем
Связанная книга
Site Reliability Engineering
Целевые уровни сервиса, бюджеты ошибок, мониторинг и четыре золотых сигнала Google.
Третий разбор: главы 5–6
Глава 5: Масштабируемость
Архитектурные подходы к масштабированию:
- Нагрузки без сохранения состояния
- Нагрузки с сохранением состояния
- Горизонтальное и вертикальное масштабирование
Глава 6: Производительность
Производительность как архитектурная характеристика:
- Почему производительность становится архитектурным вопросом
- Какими сигналами её отслеживать
- Какие техники оптимизации подходят разным профилям нагрузки
Упомянутые материалы
Гости разбора
- Алексей Тарасов — развивает архитектуру Тинькофф Инвестиций
- Даниил Кулешов — архитектор новой системы авторизации
Связанная книга
Release It!
Паттерны устойчивости: размыкатель цепи, изоляция по отсекам и тайм-ауты.
Четвёртый разбор: главы 7–9
Глава 7: Устойчивость
Устойчивость как архитектурная характеристика. Паттерны: размыкатель цепи, изоляция по отсекам, повторные попытки и тайм-ауты.
Глава 8: Новые технологии
AI и блокчейн как факторы, меняющие архитектурные ограничения и компромиссы.
Глава 9: Выводы
Подведение итогов книги и рекомендации по внедрению непрерывной архитектуры.
Материалы по устойчивости
Гости разбора
- Евгений Пешков — техлид и основатель сообщества DDDevotion
- Сергей Баранов — архитектор и основатель конференции ArchDays
Источник
Telegram: Книжный куб
Пост Александра Поломодова об устойчивости как архитектурной теме.
Устойчивость как архитектурная характеристика
Здесь книга разводит и . Она показывает, как измеряются и , почему одного недостаточно и как уменьшать за счёт локального восстановления.
Практический вывод состоит в том, чтобы проектировать , использовать при повторных попытках и явно учитывать как часть пользовательского сценария.
Базовая терминология
Fault (сбой)
Случайное условие, которое может привести к отказу системы или её отдельного компонента.
Failure (отказ)
Ситуация, когда система отклоняется от ожидаемого поведения. Fault — причина, failure — следствие.
Доступность
Измеримая характеристика: отношение времени доступности к общему времени работы системы.
Надёжность
Вероятность безотказной работы за указанный период времени в заданном окружении.
Высокая доступность и устойчивость
Старый подход: высокая доступность
- Кластеры приложений и баз данных
- Межплощадочная репликация данных
- Горячий резерв для аварийного переключения
Проблемы: сложность, высокая стоимость, долгое переключение на резерв и полная недоступность во время восстановления
Новый подход: устойчивость
- Каждая часть системы сама отвечает за свою устойчивость
- Система адаптируется к частичным сбоям
- Ошибки не распространяются дальше локального контура
Преимущества: гибкость, плавная деградация и быстрое восстановление отдельных компонентов
Ключевой вывод: традиционные схемы высокой доступности выросли из монолитных локально размещённых систем. Для распределённых микросервисных систем, хоть в дата-центре, хоть в облаке, устойчивость чаще оказывается полезнее как архитектурная стратегия.
Отказ и восстановление
MTBF
Mean Time Between Failures
Среднее время между отказами. Подход высокой доступности пытается максимально растянуть интервалы между сбоями.
MTTR
Mean Time To Recover
. Подход устойчивости сокращает время возврата в рабочее состояние и ограничивает радиус поражения.
Сдвиг парадигмы: в современных системах локальные сбои происходят достаточно часто. Вместо попытки предотвратить каждый из них важнее научиться быстро восстанавливаться и не давать проблеме разрастись на всю систему.
Механизмы устойчивости
Повторные запросы
Повторные попытки с паузой по нарастающей
Автоматический перезапуск
Самовосстановление процессов и контейнеров
Размыкатель цепи
Временное размыкание цепи при сбоях зависимости
Изоляция по отсекам
Разделение ресурсов, чтобы локальный сбой не тянул всю систему
Тайм-ауты
Явные пределы ожидания и корректная работа с задержками
Fallback
Резервный сценарий ответа или деградированный режим
Дополнительные материалы
Авторы поддерживают сайт continuous-architecture.org, где собраны дополнительные материалы по подходу:
Манифест
Принципы непрерывной архитектуры на одной странице — с чего свериться, когда спор о подходе уходит в абстракции.
ОткрытьФреймворк
Набор инструментов, когда от принципов пора переходить к тому, как это устроить в организации.
ОткрытьС чего начать
Первые шаги, если внедрять подход хочется не целиком и сразу, а с одного управляемого участка.
ОткрытьСвязанные главы
- Что такое архитектура ПО и зачем она нужна в системном дизайне - задаёт общую рамку, в которой архитектура понимается как постоянная работа с границами, компромиссами и качественными характеристиками.
- Building Evolutionary Architectures: эволюционная архитектура (краткий обзор) - добавляет базу по функциям архитектурной проверки и управляемой эволюции, на которую опираются принципы непрерывной архитектуры.
- Эволюционная архитектура на практике - спускается на прикладной слой: инкрементальные изменения, управляемую связанность компонентов и сигналы, по которым видно, что архитектуре пора меняться.
- Архитектура в масштабе: как мы принимаем архитектурные решения - разворачивает организационную сторону темы: короткие документы решений, журнал решений и лёгкое архитектурное управление в работе команды.
- Эволюция архитектуры Т-Банка (2006–2024) - даёт длинный промышленный кейс, где архитектура перестаёт быть проектной фазой и становится постоянной инженерной дисциплиной.