Архитектура ломается не только от плохих решений, но и от ложной идеи, будто все важное можно решить один раз в начале проекта. Эта глава показывает противоположный подход: архитектура живет внутри потока поставки изменений и требует постоянной калибровки по мере изменений продукта.
Здесь особенно полезно то, как книга связывает качественные характеристики, отложенные решения, маленькие инкременты, архитектурное управление и обратные связи с реальным ритмом поставки. Такой взгляд помогает не откладывать важные решения бесконечно, но и не цементировать их раньше, чем появился нужный контекст.
На интервью и в архитектурных разборах по этой книге удобно обсуждать процесс, а не только схему: какие решения нужно принимать рано, какие стоит задержать и как проверять архитектурные гипотезы прямо в цикле поставки.
Практическая польза главы
Непрерывное мышление
Переводит архитектуру из разового этапа в непрерывный процесс внутри цикла поставки.
Атрибуты качества в первую очередь
Помогает держать нефункциональные требования в центре решений, а не добавлять их постфактум.
Время принятия решений
Учит откладывать дорогие решения до достаточной информации, но не терять контроль над рисками.
Зрелость на интервью
Показывает на интервью зрелый подход к архитектуре как к процессу, а не только к схеме.
Источник
Книжный клуб 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 и MTTR
MTBF
Mean Time Between Failures
Среднее время между отказами. Подход высокой доступности пытается максимально растянуть интервалы между сбоями.
MTTR
Mean Time To Recover
Среднее время восстановления. Подход устойчивости сокращает время возврата в рабочее состояние и ограничивает радиус поражения.
Сдвиг парадигмы: в современных системах локальные сбои происходят достаточно часто. Вместо попытки предотвратить каждый из них важнее научиться быстро восстанавливаться и не давать проблеме разрастись на всю систему.
Механизмы устойчивости
Повторные запросы
Повторные попытки с паузой по нарастающей
Автоматический перезапуск
Самовосстановление процессов и контейнеров
Размыкатель цепи
Временное размыкание цепи при сбоях зависимости
Изоляция по отсекам
Разделение ресурсов, чтобы локальный сбой не тянул всю систему
Тайм-ауты
Явные пределы ожидания и корректная работа с задержками
Fallback
Резервный сценарий ответа или деградированный режим
Дополнительные материалы
Авторы поддерживают сайт continuous-architecture.org, где собраны дополнительные материалы по подходу:
Манифест
Короткая формулировка принципов непрерывной архитектуры в духе архитектурного манифеста.
ОткрытьФреймворк
Практический набор инструментов для внедрения непрерывной архитектуры в организации.
ОткрытьС чего начать
Краткое руководство по первым шагам внедрения непрерывной архитектуры в компании.
ОткрытьСвязанные главы
- Что такое архитектура ПО и зачем она нужна в системном дизайне - задаёт общую рамку, в которой архитектура понимается как постоянная работа с границами, компромиссами и качественными характеристиками.
- Building Evolutionary Architectures (краткий обзор) - добавляет базу по функциям архитектурной проверки и управляемой эволюции, на которую опираются принципы непрерывной архитектуры.
- Эволюционная архитектура на практике - показывает прикладной слой: инкрементальные изменения, управляемую связанность компонентов и сигналы, что архитектуре пора меняться.
- Архитектура в масштабе: как мы принимаем архитектурные решения - разворачивает организационную сторону темы: короткие документы решений, журнал решений и лёгкое архитектурное управление в работе команды.
- Эволюция архитектуры Т-Банка (2006–2024) - даёт длинный промышленный кейс, где архитектура перестаёт быть проектной фазой и становится постоянной инженерной дисциплиной.