- Составь, пожалуйста, руководство по тому, как делать архитектуру.

С такой просьбой ко мне однажды обратились менеджеры по разработке софта в компании, где я работаю или работал (не хочу раскрывать время и место). И надо сказать, что сначала эта просьба меня здорово озадачила. На тему архитектуры софта написано много книг, и не самых тонких. Мне предлагается написать еще одну? Чем она будет отличаться от существующих? И зачем вообще им это?

Что касается "зачем", то здесь все было понятно. Цель у менеджеров была благая. Проектов в компании обычно больше, чем могут осилить штатные архитекторы. Идея была в том, чтобы архитектуру для небольших проектов делали либо сами менеджеры по разработке, либо старшие разработчики, а архитектор только проверял, направлял и помогал где нужно.

Цель хорошая, запрос хороший. Оставалось только понять, как оказать им конструктивную помощь, а не отправить читать книжки или не засесть писать свою.

В итоге, родилось что-то вроде чек-листа с пояснениями. Список того, что обязательно должно присутствовать в законченной архитектуре проекта. После появления такого чек-листа любой менеджер или старший разработчик, собравшийся самостоятельно поработать над архитектурой, открывал чек-лист, читал, шёл ко мне - задавал вопросы, затем работал над архитектурой, периодически возвращался ко мне посоветоваться, а когда у него все было готово, мы с ним садились и проводили финальный анализ.

Собственно, этот список я здесь и публикую.

Перед тем, как начать, я поясню, о какой архитектуре пойдет речь. "Архитектура софта" - очень широкое понятие, многоуровневое. Есть уровень отдельных компонент приложения, уровень приложения, уровень систем. Однако конкретно я, в основном, работаю на end-to-end уровне - там, где различные системы и приложения связываются в единый продукт, или "решение" (solution). Так что мой чек-лист больше относится к solutions-архитектуре, но многое из него справедливо для архитектуры любого уровня.

Теперь поехали!

1. Определите зоны ответственности всех новых компонент (сервисов, приложений и т.п.)

2. Убедитесь, что не изменяете зоны ответственности уже существующих компонент. Но если вдруг изменяете, то делайте это осмысленно. Явным образом определите и зафиксируйте новые зоны ответственности

3. Убедитесь, что для каждой новой/измененной компоненты у вас есть долгосрочное видение развития. Закрепленная за компонентой зона ответственности не должна противоречить этому видению

Если вы умеете хорошо справляться с тремя пунктами выше, то вы уже крутой архитектор. Ибо это 90% успеха. Если у вас есть эти 90%, то дела у вас уже идут очень даже не плохо. Даже если у вас в компании используются устаревшие или неоптимальные технологии. Даже если вы все еще разрабатываете монолиты, а не микросервисы. Даже если REST-протоколы в компании реализуют на чистом Си. У вас всё равно всё будет круто. Правда, с одной оговоркой: вы должны уметь быстро выводить в продакшн новый функционал либо исправления для уже имеющегося (мы поговорим об этом как-нибудь в другой раз). И когда я говорю про 90% успеха, то на 100% серьезен. Я видел правильные "монолиты", в которые легко добавлять новый функционал и можно выводить его в продакшн хоть каждые пару дней; и видел микросервисные архитектуры, в которых добавление незначительной фичи - боль на пару месяцев. Не так важны пункты ниже, как первые три, которые большинство архитекторов/директоров/менеджеров/разработчиков обычно игнорируют. Потому что работать над этими тремя вещами сложно. Потому что проще каждый раз жить в контексте конкретной фичи, "как-то прикручивая ее сбоку", нежели работать в контексте всего продукта, да еще и держа в уме его будущее развитие. Потому что проще сфокусироваться на менее приоритетных целях, типа переезда на новую технологию разработки. И тому подобное...

4. Дайте правильные названия компонентам. Название должно отражать область ответственности компоненты, а не быть именем персонажа из вашей любимой компьютерной игрушки, например

Тема правильных имён настолько большая и больная, что я посвящу ей отдельный пост. Здесь же пока отмечу, что проблема выглядит совершенно по-разному для разработчиков и менеджеров с одной стороны и архитекторов - с другой. На горизонте менеджеров и разработчиков находятся обычно несколько приложений/сервисов. И кажется, почему бы не дать им имена героев любимого мультфильма? Это же остроумно. К тому же "характер" персонажа можно каким-нибудь хитрым образом ассоциировать с характером самой компоненты. А теперь представим архитектора или аналитика, на горизонте которых находятся пара сотен таких компонент. И вот он оказывается в зоопарке из мультяшных героев, персонажей кельтского эпоса, блюд итальянской кухни, астрономических объектов и пр. Эмоции в этом случае наиболее точно можно описать только матом. Однако врожденная скромность и модератор Хабра не позволят мне этого сделать. В общем, это непозитивные эмоции. Именование приложений/сервисов/систем должно быть обязанностью архитекторов и никого больше. Если в вашей компании это не так, постарайтесь это изменить

5. Убедитесь, что у вас есть проработанная стратегия регионализации, то есть вы четко понимаете, каким образом ваше решение должно работать в различных регионах. Этот пункт не универсален. Справедлив только для тех решений, которые разворачиваются в нескольких географиях

6. Детальная деплоймент-диаграмма. Обязательно должно быть показано какие компоненты в каких географиях должны быть развернуты, а также как они коммуницируют друг с другом, в каких аккаунтах живут, на какой инфрастуктуре исполняются и тому подобное

7. На интеграционных диаграммах должны быть показаны интеграции между всеми компонентами, задействованными в решении

8. Нарисуйте детальные flow- и sequence-диаграммы для основных сценариев и для corner case-сценариев (то есть редких ситуаций, которые потребовали специальной проработки на этапе дизайна)

9. Если необходимо было выбирать какие-то сторонние технологии - например, базу данных - опишите, какие именно технологии были выбраны, какие кандидаты рассматривались и почему выбор был сделан так, как он был сделан

10. Задокументируйте основные технические "ходы" в вашем решении, альтернативы, которые рассматривались, и обоснуйте выбор. Например, в рамках решения вам нужно было встроить новые шаги по обработке каких-нибудь интернет-заказов в уже имеющуюся цепочку. И было несколько вариантов. Необходимо показать, что вы сделали осмысленный выбор, приняв во внимание текущее состояние дел и планы развития

11. Разработайте стратегию постепенного разворачивания решения. (Gradual roll-out, то есть процедура, в результате которой решение разворачивается не одним махом на весь бизнес, а постепенно, чтобы снизить цену возможных ошибок). Строго говоря, конкретно архитектор обычно разрабатывает не всю стратегию, а половину. Полная стратегия состоит из двух частей: бизнесовой и технической. В первой части задаётся порядок, в котором клиенты бизнеса получат новое решение, а также темп, в котором оно будет доставляться до всё большего количества клиентов. Например: сначала включить решение в Германии для 10% случайных клиентов из этой страны, и если всё пойдет хорошо, то через месяц бахнуть решение разом для всех остальных клиентов во всём мире. Конкретный технический способ, которым подобный план будет реализован – это уже техническая часть стратегии gradual roll-out. За эту часть, как раз, и отвечает архитектор. Ответственные за бизнесовую часть могут быть разными, в зависимости от типа продукта, который производит компания, и в зависимости от особенностей решения. Например, если компания производит системы хранения данных (СХД), то очень вероятно, что в случае радикальных обновлений, в работу над бизнесовой частью будут вовлечены специалисты по продажам. Именно они найдут "подходящих" клиентов, которые согласятся в обмен на какие-то плюшки испытать новую версию СХД на каких-нибудь некритичных нагрузках.
Стратегия gradual roll-out должна быть определена как для первичного релиза, так и для последующих изменений. Часто это два разных сценария, но ещё чаще – вообще три: для первичного релиза; для последующих изменений на уровне отдельных компонент, если контракты с вышележащими компонентами остаются прежними; и для последующих изменений на уровне отдельных компонент, если затрагиваются контракты.
Клиенты, попавшие в первые волны gradual roll-out, могут либо знать, либо не знать, что стали первыми, кто получил новое решение. Например, если в продукт была добавлена новая фича, то можно заранее привлечь какое-то количество клиентов, которые явным образом согласятся стать её первыми пользователями. Или же можно выбрать клиентов для первых волн случайно, но по умолчанию отключить для них новую фичу и дать возможность добровольно ее включить, допустим, через панель управления настройками продукта. При этом в панели можно указать, что фича находится на этапе ограниченного релиза, и её использование влечёт некоторые риски. В обоих приведенных примерах клиент так или иначе дает информированное согласие на участие в начальных этапах выкатки решения. Однако можно поступить иначе. Можно выкатить новое решение, не проинформировав клиентов о повышенных рисках.
Gradual roll-out по второму сценарию - то есть без явного предупреждения клиентов и получения их активного согласия - вызывает во мне смешанные чувства. С одной стороны, конечно же, нужно снижать риски и для поставщика решения, и для его клиентов. Если в решении есть ошибки, которые не были отловлены на тестовой инфраструктуре, то пусть в продакшене от этого пострадает 1% клиентов, нежели все 100%. С другой стороны, gradual roll-out по второму сценарию в каком-то смысле не очень честный по отношению к клиентам. Почему кто-то должен первым принять риски, не узнав об этом? (Забавно, что обратное тоже может быть верно: почему кто-то не стал первым и не получил бизнес-преимуществ, которые даёт новое решение?) Интересно, что олдскульный мир, в котором софт распространялся на комакт-дисках, в плане gradual roll-out был честнее, чем современный. Потому что в те давние времена весь софт проходил через альфа- и бета-самцовтестеров и ранних адоптеров. И эти люди/бизнесы знали, на какие риски идут, и делали это добровольно. Сейчас же клиент интернет-сервисов может не знать, что на нём обкатывают новое решение. И конечно же, для обкатки обычно выбирают наименее "жирных" клиентов, чтобы, в случае провала, поставщик не сильно пострадал от их ухода. На "жирных" клиентов решение распространяют уже в последнюю очередь. При таком подходе компания-поставщик решения обычно оптимизирует свои собственные риски, а не риски клиентов. Дело в том, что "жирный" клиент с большой вероятностью переживёт нештатную ситуацию, а вот у мелкого бизнес может закрыться. Справедливости ради, отметим, что здесь не всё однозначно, потому что клиенты могут не быть конечными потребителями. И если это действительно так, то проблемы на стороне одного "жирного" клиента могут стать проблемами сотен его собственных клиентов - вплоть до их краха.
Итак, скрытый от клиентов gradual roll-out может приводить к интересным этическим дилеммам. Для него не существует «абсолютно честной» схемы, потому что честность - понятие относительное. То же самое относится к A/B тестированию на реальных клиентах. При таком тестировании компания невидимо подкладывает некоторым своим клиентам (возможно, наименее жирным) альтернативный вариант услуг, который хочет сравнить по каким-то показателям с основным вариантом. И это в корне отличается, например, от тестирования препаратов в медицине, где клиент добровольно подписывает согласие на участие в эксперименте.
Впрочем, в случае с gradual roll-out, этические дилеммы обычно сильно смягчаются за счет использования комбинированного подхода: небольшие улучшения релизятся без активного согласия клиентов, а серьезные изменения сначала раскатываются только на клиентов, от которых получено согласие

12. Стратегия отката решения на случай, если что-то пошло не так. Такая стратегия точно имеет смысл, если компания контролирует инфрастуктуру - физическую или виртуальную, - на которой работают ее решения. Но часто может иметь смысл и для других сценариев.
Раскатали вы, допустим, своё новое решение на 1% клиентов и вдруг обнаружили, что что-то идёт не так. Как будете возвращаться к старому варианту решения (если он был)? И как будете чинить то, что успели сломать? И как будете минимизировать ущерб для пострадавших клиентов? На все эти вопросы у архитектора должен быть хороший ответ. Причём заранее. До того, как начнётся пожар

13. Непрерывность бизнеса (business continuity). Отказоустойчивость, бэкапы, дублирование инфраструктуры, репликация, RPO, RTO, MTD - вот это вот всё

14. Убедитесь, что ваше решение на нарушает законодательства тех стран, в которых ваша компания ведёт бизнес. Например, китайские персональные данные не должны пересекать границу Китая. И даже если персональные данные не покидают пределов страны, при пересылке они должны быть зашифрованы.
Соблюдение стандартов, норм и законодательства - обычно не самая любимая тема технических специалистов. Потому что это не про технику. Но при этом учёт нормативных требований может существенно влиять на техническое решение, делая его обычно менее элегантным и более тяжеловесным

15. Чувствительная информация, которая сохраняется или передаётся в рамках вашего решения, не должна быть никому доступна внутри вашей компании, кроме тех, у кого есть легитимные основания для доступа к ней. Например, для устранения продакшн-инцидентов команде поддержки может понадобиться доступ к персональным данным. При этом будет здорово, если у них не будет возможности читать данные, не относящиеся к конкретному инциденту.
Заботясь о защите чувствительных данных, люди часто фокусируются на защите файлов и баз данных, но забывают про другие источники, например, логи. Хорошая практика - не создавать лишних копий чувствительных данных. В логах, на мой взгляд, чувствительным данным делать нечего.
Для некоторых типов данных текущий пункт является частью предыдущего. Это справедливо, например, для персональных данных. Законодательства большинства (всех?) стран запрещают использование персональных данных для "вторичных" целей. Например, нельзя использовать персональные данные для целей аналитики и "тюнинга" программных решений, если на это нет письменного разрешения от субъектов этих персональных данных

16. Убедитесь в защищенности вашего решения от внешних и внутренних атак. Обсудите решение с security-командой. Безопасность есть безопасность, здесь и добавить особо нечего. Единственное: старайтесь всегда использовать стандартные и проверенные решения от надежных поставщиков. Не пытайтесь ничего придумывать, если вы не супер-пупер эксперт в информационной безопасности или у вас в напарниках нет такого человека. Тем более, что еще не было ни одного супер-пупер решения по безопасности, которое не было бы взломано

17. Явным образом задокументируйте все неэффективности и технический долг, которые есть в вашем решении. Возьмите обязательство с себя и других ответственных устранить технический долг в ближайшем будущем. У этих обязательств должны быть четкие даты, и в пайплайне должны быть запланированы соответствующие проекты. Иначе технический долг останется с компанией навечно. Вообще технический долг - это то, что должно случаться в разработке достаточно редко. Если у вас каждый проект идет с техническим долгом, то у вас большие проблемы с разработкой. И я знаю одну такую компанию. Технический долг там никогда не устраняется и только копится. Много еще чего хочется написать на эту тему. И я даже чуть было не написал, но вовремя стёр. Оставим эту тему для отдельного поста

18. Проделайте анализ затрат на реализацию, внедрение, использование и поддержку решения. Посчитайте выгоду, которую оно принесет. (Расчет выгоды - обычно не задача архитектора, но исключения возможны. Например, если речь идет о технической оптимизации уже существующих решений). В расчетах необходимо учесть все географические регионы и все среды, в которых будет развернуто решение. Часто люди, делающие такой анализ, фокусируются только на продакшн-средах и совсем забывают про тестовые окружения. Однако иногда затраты на тестирование решения могут быть сопоставимы с затратами на его эксплуатацию в продакшене. Обычно такое случается, когда само решение или процесс его тестирования имеют изъяны.

После вывода решения в продакшн неплохо бы посмотреть на реальную выгоду и на реальные издержки и сравнить их с прогнозом. Но это не всегда делается. Особенно, если у компании много денег. Финансисты могут просто посмотреть на интегральную цифру капитальных и операционных издержек, понять, что на фоне текущей выручки она их устраивает, и решить, что заниматься оптимизацией расходов им лень

19. SLA, или соглашение об уровне услуг. SLA должно быть определено как для всего решения, так и для каждого компонента, входящего в решение. Например, если решение - это новый интернет-сервис, то в SLA может входить верхняя граница времени отклика, количество запросов от одного клиента в секунду, доступность сервиса и т.п. В цифрах это может выглядеть примерно так: сервис достепен 99.99% времени круглогодично, независимо от времени суток и дня недели; если количество запросов от конкретного клиента не превышает 10 в секунду, то 95% запросов этого клиента будут выполнены в течение 0.4с, а 5% могут выполняться дольше, однако не более, чем за 1с.

Все SLA должны быть обоснованы: почему они именно такие, а не другие? (При этом обоснование интегрального SLA всего решения - не задача архитектора, это бизнес-требование). Для каждого SLA должно быть понятно, как именно оно будет обеспечиваться технически

20. Обработка ошибок и таймаутов. Необходимо обсудить с командами разработчиков, как именно должны обрабатываться ошибки и таймауты. Нестандартные и неинтуитивные сценарии должны быть задокументированы

21. Логгирование и мониторинг. Что именно и куда логгируем. Какие метрики собираем и куда складируем. Какие параметры мониторим и как на них реагируем. Какие дэшборды настраиваем

22. Если кто-то из разработчиков, архитекторов, менеджеров по разработке, продуктовых менеджеров, аналитиков задал при обсуждении архитектуры вопрос, который показался вам значимым, задокументируйте его. Высока вероятность, что этот вопрос может возникнуть впоследствии не раз и не у одного человека. Важно отобразить, как этот вопрос решался и в каких предпосылках

Вот, пожалуй, и почти всё на сегодня. Остаётся добавить, что всё перечисленное выше (или то, что входит в понятие "архитектуры решения" именно в вашей компании) желательно отразить в шаблоне архитектурной документации. Чтобы каждый проект был задокументирован унифицированно, с указанием всей важной информации. И еще не помешает руководство по тому, как работать с шаблоном и как правильно прорабатывать наиболее сложные темы.

Теперь точно всё. Успешного нам всем архитекторства! Ведь все разработчики софта в каком-то смысле архитекторы.

Ссылка на английскую версию статьи: https://fuckdomains.wordpress.com/2021/10/28/checklist/