Основы архитектуры. Архитектурные характеристики

Начинают с разминки: ведущие спрашивают, с чего начинается день у человека, которого считают суперпродуктивным. Собака будит Александра в 6:30; после прогулки, пока домашние спят, он читает или пишет статью, потом кофе с семьёй, чтение по дороге на работу и в самолётах, вечером ещё пара часов. Работает это, по его словам, потому что дедлайны он ставит себе сам и объявляет вовне. Из чата спрашивают про очередь на чтение: она есть, книги заказаны на Amazon, к поездке в Екатеринбург ему пришла пара новых, одна — Тани Рейли. Дочитав книгу, Александр обычно делает из неё статью со своими схемами: авторы, по его словам, многое держат в тексте и картинок не прикладывают. Одной книге не хватило сводной таблицы по типам архитектур со звёздочками — он собрал её в Excel, посчитал суммы и подсветил красным и зелёным, где какой тип проваливается.

Взять четвёртую и седьмую главы разом, признаются ведущие, они не додумались: возможно, следующее обсуждение пройдёт сразу по нескольким главам. Коля объясняет, чем глава ценна: разработчик привык, что программу надо писать нормально и с меньшим числом багов, а став архитектором, вдруг слышит про масштабируемость, отказоустойчивость и десятки других слов; каждое по отдельности разбирается, но их огромное количество, и худшая реакция — решить, что теперь всё это надо реализовать. Дальше — спор о термине: авторы отказались и от «нефункциональных требований» (бизнес их не заказывал, продавать нечем), и от «атрибутов качества» (качество обычно проверяют постфактум), выбрав «архитектурные характеристики» как то, что критично для успеха системы. Александру цепочка рассуждений понравилась, он пересказывал её и в другом подкасте, но предупреждает: общепринятого термина нет, знать придётся все три и то, как они связаны. Один из ведущих признаётся, что для него это всегда были нефункциональные требования — он даже делал под этим названием конференцию.

Прежде чем перечислять, авторы задают три критерия: характеристика описывает соображение дизайна, не относящееся к домену, влияет на структуру системы и критична или важна для успеха приложения. Александр замечает, что почти все любят троицу, и напоминает про треугольник, на вершине которого балансирует дизайн; часть характеристик неявная (те, что влияют на структуру), часть явная. Списков он встречал много, и все разные, а групп у авторов три: операционные, структурные и сквозные, влияющие на всё. В другой книге, которую он тоже хотел упомянуть, те же вещи называют эмерджентными свойствами системы — тем, что получается, когда собираешь кубики вместе: надёжно или разваливается, безопасно или нет. К разбору Александр подготовил конспект и видео — ссылку кинули в чат — и шарит экран.

Операционные характеристики разбирают на примерах банка. Доступность — те самые девятки. Непрерывность бизнеса и восстановление после сбоев: есть внутренний инструмент, где эти показатели заводят и отслеживают, есть план восстановления, а реакция на инциденты важна и для регулятора: о сбое нужно сообщать в определённом формате. Производительность плотно связана с утилизацией: раньше можно было закидать ресурсами, теперь решения дорабатывают, чтобы перформанса хватало в ограниченных. Системы разделены на mission critical и остальные, требования и способ поддержки у них разные. Ошибки стараются обработать так, чтобы они не вылетали пользователю: где-то помогает асинхронность, где-то ошибка не блокирует основной путь. Масштабируемость нужна из-за сезонности распродаж, перепадов по времени суток и привязки к дням месяца, когда люди получают деньги; под акции нагрузку планируют заранее. Из структурных недавно вкатывали локализацию, рассчитывая не только на пользователей из СНГ, и ценят динамическую конфигурацию экранов и тоглы для постепенной раскатки; многие практики брали из отчёта Google про мобильную разработку.

Антон, который собирал требования как системный аналитик, добавляет прагматики: список в главе большой, но не полный — по разным источникам, как ему кажется, наберётся под сотню -ilities, и большей частью при первом сборе требований нужно сознательно пренебречь. Локализация критична для международного сервиса и почти не нужна внутреннему, если только не нанимать разработчиков за рубежом или не выходить в страну, где нужен испанский. Разумно выбрать 7–10 характеристик и зафиксировать их с заказчиком: каждая дополнительная стоит денег, а говорить лучше на языке SLA и SLI. Его байка из времён работы в интеграторе: на вопрос про процент доступности заказчик ответил, что 98 % вполне достаточно; когда систему поднимали два дня, он приехал ругаться — но 2 % от года — это, по подсчёту Антона, не меньше шести дней, и квоту не израсходовали даже близко. Так же и с производительностью: говорят «быстро», называешь 40 тысяч транзакций в секунду — соглашаются, хотя обрабатывают десять заявок в день.

Стоимость характеристики Антон оценивает по аналогии: взять три-десять похожих проектов и прикинуть, помня, что по девяткам зависимость точно не линейная; цены и требования публикуют в госзакупках, у интеграторов есть своя база проектов, а в сообществах проектных менеджеров попадаются калькуляторы в Excel на два десятка вопросов. Александр недоволен перечислительным стилем главы: инструмента, как понять, какие параметры вам нужны, после перечисления не появляется, — и показывает ещё одну книгу, уже не ту, откуда эмерджентные свойства: там идут от сценариев к важным в них характеристикам. Компромисс он описывает как игру в стулья — пять стульев на шестерых — и как ползунки при настройке персонажа: очков фиксированное число, можно быть умным или сильным, а можно сбалансированной посредственностью. По просьбе из чата доходят до сквозных характеристик — у одного из ведущих про security пять докладов на YouTube — и идут от противного: security выкидывается, если нет личных кабинетов или сервис живёт внутри VPN; архив не нужен сервису без персистентного компонента; а сложный процесс поддержки с тремя линиями не нужен, когда пользователей мало, пусть и крупных: их всё равно ведут руками. Заканчивают по традиции — фотографией с обложкой книги.