Требования к интернет-системам

Содержание

Слайд 2

Developers are most motivated to improve code that affects operations when they

Developers are most motivated to improve code that affects operations when they
feel the pain of operations, too. Operations must understand the development process if they are to be able to constructively collaborate.
— T.A.Limoncelli et al., The Practice of Cloud System Administration: DevOps and SRE Practices for Web Services

Слайд 3

Поговорим о целях

Цель архитектуры программного обеспечения – уменьшить человеческие трудозатраты на создание

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

Слайд 4

Бизнес-цели

Идеальная система полностью решает цели и задачи бизнеса.
Бизнес цели: планируемы, измеримы,

Бизнес-цели Идеальная система полностью решает цели и задачи бизнеса. Бизнес цели: планируемы,
автоматизируемы
Например: Продажа x товаров на сайте в месяц Предоставление сервиса 99,99% времени Обработка x миллионов заказов в месяц, с ростом 10% Вывод новых фич два раза в неделю Исправление мажорных багов за 24 часа
Предсказуемость и устойчивость целей бизнеса и проектной команды

Слайд 5

Поведение v Архитектура

Бизнес-цели максимально быстро с ущербом для качества Мы сможем навести

Поведение v Архитектура Бизнес-цели максимально быстро с ущербом для качества Мы сможем
порядок потом, нам бы только выйти на рынок!
надо пилить новые фичи;
нарастает технический долг;
беспорядок возрастает;
вместо исправления беспорядок переносится с места на место.
Грязный код может помочь быстро выйти на рынок, но в действительности он затормозит движение в долгосрочной перспективе

Слайд 6

Поведение v Архитектура

Поведение – удовлетворение бизнес-требованиям по функциональности
Архитектура – удовлетворение требованиям качества

Поведение v Архитектура Поведение – удовлетворение бизнес-требованиям по функциональности Архитектура – удовлетворение
(сопровождаемость, изменяемость, надежность, и т.д.)
– так что всё-таки важнее?

Слайд 7

Правильный ответ:

Если функциональные требования поменялись, а изменения вносить невозможно – правильно работавшая

Правильный ответ: Если функциональные требования поменялись, а изменения вносить невозможно – правильно
ранее программа становится бесполезна
Если программа работает неправильно, но легко поддается изменениям, то её можно сделать правильной
Архитектура.

Слайд 8

Что лучше для бизнеса?

Заинтересованные стороны:
Топ-менеджмент – ???
Маркетинг – за скорость в

Что лучше для бизнеса? Заинтересованные стороны: Топ-менеджмент – ??? Маркетинг – за
ущерб качеству
Продажи – за скорость в ущерб качеству
Разработчики – за правильную архитектуру и код
Эксплуатация – за правильную архитектуру и код

Слайд 9

Идеальная архитектура

Очевидный запланированный путь развития с ростом популярности и трафика реакция на изменяющиеся

Идеальная архитектура Очевидный запланированный путь развития с ростом популярности и трафика реакция
требования
Устойчивость к сбоям, избыточность и эластичность сбой не сюрприз, а естественная часть физики ИТ
Максимальная независимость подсистем масштабирование, апгрейд, замена
Электронное описание инфраструктуры, Infrastructure as a Code автоматическое воссоздание окружений

Слайд 10

Традиционный процесс релиза

Разработчик размещает готовый код в репозиторий Тестовые инженеры прогоняют код через

Традиционный процесс релиза Разработчик размещает готовый код в репозиторий Тестовые инженеры прогоняют
тесты Если тесты пройдены, выпускающий инженер строит пакеты для доставки ПО. Большинство файлов из репозитория, но некоторые – из сторонних источников, генерируемы и т.д. Создается тестовое окружение Тестовые инженеры тестируют взаимодействие подсистем Если тесты пройдены – код в продакшн Системные администраторы обновляют код систем, следя за сбоями При наличии сбоев – откат до предыдущей версии
Ошибки на любом этапе - возврат на предыдущий этап
Много изменений разрабатывается и тестируется одновременно
Пакетные мега-релизы несколько раз в год
Чем больше одновременных изменений – тем больше риски

Слайд 11

Релиз в идеальной системе

Сборка, тестирование, выпуск, доставка автоматизированы
Вместо мега-релизов – микро-релизы, хоть

Релиз в идеальной системе Сборка, тестирование, выпуск, доставка автоматизированы Вместо мега-релизов –
100 раз в день
Как только разработчик размещает код в репозитории, система запускает серию автоматических тестов основного функционала Если тесты пройдены, автоматически собираются пакеты Запускается создание тестового окружения без человеческого вмешательства (IaaC) Запускается серия автотестов на тестовом окружении При успешном прохождении пакеты выкатываются с продакшн Тестовые окружения строятся так же, как и продакшн, минимум различий
При обнаружении ошибки на любом из этапов – остановка других релизов до исправления ошибки
За счет минимального объема изменений – исправление ошибок быстрое, движение вперед не задерживается

Слайд 12

Идеальная эксплуатация

Измеримость всех показателей работы удовлетворение бизнес-требованиям
Вместо ручного контроля – автоматическая реакция масштабирование вверх

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

эксплуатация

разработка

релиз

Слайд 13

Эксплуатационные требования (иногда – нефункциональные требования)

Автоматизация конфигурирования
Корректный рестарт сервиса при перезагрузке или включении
Очистка

Эксплуатационные требования (иногда – нефункциональные требования) Автоматизация конфигурирования Корректный рестарт сервиса при
очереди перед выключением
Обновление ПО без отключения сервиса
Резервное копирование и восстановление, импорт данных
Избыточность и реплицирование БД
Переключатели отдельных фич
Постепенная деградация при перегрузках
Контроль доступа, мониторинг, аудит, средства отладки, сбор исключений, документирование эксплуатации,…

Что-нибудь там потом придумают

WTF??

Слайд 14

Дизайн для эксплуатации

Фичи, важные для эксплуатации, не берутся «ниоткуда», их необходимо реализовывать,

Дизайн для эксплуатации Фичи, важные для эксплуатации, не берутся «ниоткуда», их необходимо
а прежде – спроектировать.
Встраивание в продукт с самого начала Это круто. Так не бывает (почти).
Запрос разработки фич по мере идентификации их необходимости Часто. Необходимо определение приоритетов запросов.
Самостоятельное написание командой эксплуатации Слишком часто. Разработчики могут не принять код. Плохой прецедент.
Использование продуктов сторонних вендоров Необходимость адаптации процесса под продукт, а не наоборот
Имя файла: Требования-к-интернет-системам.pptx
Количество просмотров: 27
Количество скачиваний: 0