Checklist для архитектора (Дмитрий Дзюба, HelloConf MTS-2020)

Короткая ссылка: 202002077

Докладчик: Дмитрий Дзюба

В данном докладе я поделился наиболее часто встречаемыми рисками в области программной архитектуры. Они относятся к самому процессу создания и ведения программной архитектуры, проектированию безопасности приложений и обеспечению высокой производительности работы. В докладе я рассказал на простых примерах какие бывают ошибки и как их можно решать. Конечно, все эти приемы кажутся достаточно очевидными, но мы с Вами знаем, что процесс проектирования архитектуры – это постоянный выбор компромиссов. И этим докладом я хотел напомнить о важности того, что нужно делать правильный выбор при проектировании архитектуры.

Исследование внутренних продуктовых команд. В следствие продуктовой трансформации мы получили большое количество продуктовых команд разной степени зрелости. Команды делают свои автономные продукты и вливаются в общую экосистему продуктов МТС. Мы решили построить механизм для переиспользования опыта друг друга, собрали группы, чтобы выяснить как команды работают, какой полезный опыт в этих командах есть.

Организация процесса аудита. Как оценивать работу команд?! Первая идея «взять готовые стандарты» провалилась, потому что породила за собой массу вопросов «ко всем ли они применимы? в каких случаях применимы? как понять какой стандарт хороший, какой плохой?». Тогда мы посмотрели на вторую модель и решили идентифицировать риски, которые связаны с конкретными ситуациями.

Как происходит деятельность:
Общение с продуктовой командой (на 1 команду – 1 месяц, за год 20 продуктовых команд)

15 экспертов проводят аудит

187 рисков, которые мы идентифицировали в рамках деятельности

Проблема №1 Организация процесса проектирования

1. Как проектировать – выбираем способ «сверху вниз» или «снизу вверх»

2. Что нужно для начала проектирования: варианты использования, требования, документирование.

Проблема №2 Безопасность - Разберем пример: Аутентификация по паролю
1. Веб-приложение позволяет пользователям создавать простые пароли.

2. Веб-приложение не защищено от возможности перебора паролей.

3. Веб-приложение само генерирует и распространяет пароли пользователям, однако не требует смены пароля после первого входа (текущий пароль где-то записан)

4. Веб-приложение допускает передачу паролей или session token-ов по незащищенному HTTP-соединению либо в строке URL&

5. Веб-приложение не использует безопасные хэш-функции для хранения паролей пользователей.

6. Веб-приложение не предоставляет пользователям возможность изменения пароля, либо не нотифицирует пользователей об изменении их паролей.

7. Веб-приложение использует уязвимую функцию восстановления пароля, которую можно использовать для получения несанкционированного доступа к другим учетным записям

8. Веб-приложение не требует повторной аутентификации пользователя для важных действий: смена пароля, изменения адреса доставки товаров и т.п.

9. Session tokens могут быть подобраны или предсказаны для других пользователей; веб-приложение уязвимо для session fixation-атак; веб-приложение не устанавливает флаги HttpOnly и Secure для browser cookies, содержащих session tokens.

10. Веб-приложение не уничтожает сессии пользователя после короткого периода неактивности.

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

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

Компания МТС, как и многие другие компании создающие цифровые продукты организована по принципу «продуктовых команд» - автономных групп. Такой подход очень удобен с точки зрения эффективности развития бизнес-направлений, но обладает некоторыми недостатками с точки-зрения распространения знаний между этими командами. Действительно, каждая команда сконцентрирована на своей задаче и у нее просто нет повода взаимодействовать с коллегами из другой продуктовой команды.
Мы решили этот недостаток исправить. Так родилась идея собрать команду экспертов, которая будет анализировать работу продуктовых команд и делиться своим опытом (а также воспринимать опыт этих команд). Фактически у нас родилось некоторое сообщество энтузиастов. Внутри мы поделились на различные специализации от продуктового менджмента и архитектуры, до контроля качества и devops. В качестве результата общения экспертов с командами мы формулируем набор рисков, которые команды могут использовать для построения плана своего развития.