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

;{{SpeakerInfo}}: {{Speaker|Дмитрий Дзюба}}
<blockquote>
В данном докладе я поделился наиболее часто встречаемыми рисками в области программной архитектуры. Они относятся к самому процессу создания и ведения программной архитектуры, проектированию безопасности приложений и обеспечению высокой производительности работы. В докладе я рассказал на простых примерах какие бывают ошибки и как их можно решать. Конечно, все эти приемы кажутся достаточно очевидными, но мы с Вами знаем,
что процесс проектирования архитектуры – это постоянный выбор компромиссов.  И этим докладом я хотел напомнить о важности того,
что нужно делать правильный выбор при проектировании архитектуры.

* Исследование внутренних продуктовых команд. В следствие продуктовой трансформации мы получили большое количество продуктовых команд разной степени зрелости. Команды делают свои автономные продукты и вливаются в общую экосистему продуктов МТС. Мы решили построить механизм для переиспользования опыта друг друга, собрали группы, чтобы выяснить как команды работают, какой полезный опыт в этих командах есть.
* Организация процесса аудита. Как оценивать работу команд?! Первая идея «взять готовые стандарты» провалилась, потому что породила за собой массу вопросов «ко всем ли они применимы? в каких случаях применимы? как понять какой стандарт хороший, какой плохой?». Тогда мы посмотрели на вторую модель и решили идентифицировать риски, которые связаны с конкретными ситуациями.
* Как происходит деятельность:
** Общение с продуктовой командой (на 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. В качестве результата общения экспертов с командами мы формулируем набор рисков, которые команды могут использовать для построения плана своего развития.
</blockquote>

{{VideoSection}}
{{vimeoembed|240322288|800|450}}
{{youtubelink|oZZz6sRy380}}{{letscomment}}

{{SlidesSection}}
[[File:Checklist для архитектора (Дмитрий Дзюба, HelloConf MTS-2020).pdf|left|page=-|300px]]

{{----}}
[[File:{{#setmainimage:Checklist для архитектора (Дмитрий Дзюба, HelloConf MTS-2020)!.jpg}}|center|640px]]
{{LinksSection}}
<!-- <blockquote>[©]</blockquote> -->

<references/>





<!-- topub -->

[[Категория:HelloConf MTS-2020]]
[[Категория:Draft]]