'

О чем стоит подумать, приступая к разработке высоконагруженной системы.

Понравилась презентация – покажи это...





Слайд 0

О чем стоит подумать, приступая к разработке высоконагруженной системы. Артем Вольфтруб


Слайд 1

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


Слайд 2

Цикл разработки интернет-проекта разработка аналитика тестирование t


Слайд 3

Три месяца – минимальный цикл разработки интернет системы К моменту релиза требования поменяются процентов на 40 Если N разработчиков сделают систему за три месяца, то 2*N разработчиков сделают систему за… Основная работа начинается после релиза Важно понимать, что три месяца


Слайд 4

Передача проекта другой команде Передавать код другой команде сразу после релиза – плохая идея Передавать код в виде дампа svn - очень плохая идея Личное VS профессиональное


Слайд 5

Чтобы не было мучительно больно Решение о передаче проекта не должно быть спонтанным Решение должно быть известно заранее Привлекайте разработчиков к процессу Приготовьтесь заплатить дважды


Слайд 6

Способы облегчить процесс Совместная работа над проектом Постепенный ввод новой команды


Слайд 7

В первую версию системы должно войти N фич. У нас есть еще несколько минорных пожеланий, но их можно будет реализовать после выпуска первой версии.


Слайд 8

Формирование требований Анализ рынка Формирование ключевых пользовательских групп Формирование стратегии Интервьюирование ключевых пользователей Прототипирование Тестирование, получение обратной связи Коррекция


Слайд 9

Формирование требований Наличие аналогичного продукта или сервиса Видение системы, изложенное на листе А4 Идея в голове начальника


Слайд 10

Из опыта На момент релиза, востребованными оказываются около 60% фич 40% фич, которые оказались не востребованными – самые сложные с точки зрения реализации Наиболее ценные фичи не попадают в первую версию


Слайд 11

Старайтесь включать в первую версию только то, без чего реально нельзя жить. Экономьте время! Основной источник требований – пользователь Бета-версия – главный инструмент аналитика Бета-версия – полностью функциональный продукт, а не «отмазка» для разработчиков Разработка не заканчивается релизом Рамки проекта


Слайд 12

Система должна быть масштабируемой. Нам нужен подробный план того, как мы будем справляться с нагрузками, когда система вырастет со 100 000 пользователей до 10 000 000.


Слайд 13

Цели планирования План для начальства или план для разработчиков Узкие места возникают совершенно не там, где это предполагалось А кто будет писать?


Слайд 14

Анализ нагрузки Оцениваем трафик Оцениваем объем данных Фантазируем («если – то»)


Слайд 15

Слайд не для менеджеров! У «Веселого фермера» тоже был первый пользователь Когда у вас будет 10 000 000 пользователей, у вас будут деньги, чтобы все переписать


Слайд 16

Производительность системы будет проверяться проведением полноценного нагрузочного тестирования перед сдачей проекта.


Слайд 17

Проблемы нагрузочного тестирования Смоделировать реальные действия пользователя очень сложно Влияние внешних компонентов Тепличные условия тестирования Заказчик считает, что нагрузочное тестирование позволит оценить качество системы


Слайд 18

Хроники нагрузочного тестирования


Слайд 19

Хроники нагрузочного тестирования


Слайд 20

Хроники нагрузочного тестирования


Слайд 21

Хроники нагрузочного тестирования


Слайд 22

Обобщаем Другое железо Другой объем данных Другой канал Влияние окружения на работу приложения Интерполяция не работает


Слайд 23

Выводы Нагрузочное тестирование инструмент анализа, а не критерий приемки Проверять лучше отдельные сценарии, а не полноценную работу приложения


Слайд 24

Что значит приемлемый уровень отказоустойчивости? Система должна работать безотказно!


Слайд 25

Виды простоев Отказ в результате выхода из строя Остановка на плановое обслуживание


Слайд 26

Оценка отказоустойчивости Внешние зависимости Прагматичный подход (99.99% - это 1 час в год) Выделение критических компонентов


Слайд 27

Кому нужна отказоустойчивость Компоненты, которые используются внешними системами Компоненты, от которых зависит бизнес компании Компоненты, простой которых связан с репутационными потерями компании


Слайд 28

Зачем нам система мониторинга? Если система сломается, это и так все увидят!


Слайд 29

Проблемы Мониторинг не является частью проекта Систему мониторинга должен кто-то эксплуатировать Запуск высокнагруженной системы без мониторинга не имеет смысла!


Слайд 30

Что дает мониторинг Прогнозирование нагрузки Диагностика проблем на ранней стадии Выявление типовых проблем разработка универсальных решений Может использоваться, как инструмент аналитика


Слайд 31

Виды мониторинга Физический уровень (сеть, доступность сервера, CPU, место на диске, память, IO) Уровень приложения (HTTP Errors, Response time, Exceptions) Бизнес уровень (основан на бизнес критериях)


Слайд 32

Методы измерений Критериальная система Тренды


Слайд 33

Система мониторинга


Слайд 34

Согласно последним обзорам, производительность фреймворка XYZ выше, чем ZYX. Давайте разрабатывать систему с использованием XYZ


Слайд 35

Причины ограничения выбора Корпоративный стандарт Расширения существующей системы Собственная команда разработчиков


Слайд 36

Сравнение фреймворков Самый быстрый фреймворк - это тот, которым умеют пользоваться разработчики Программа «Hello world» всегда работает быстро


Слайд 37


Слайд 38

Как выбирать Исходите из текущих задач и задач на ближайшую перспективу (время написания первой версии + поддержка) Смотреть на профиль команды


Слайд 39

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


Слайд 40

Откуда растут ноги Конфиденциальная информация Корпоративные стандарт безопасности Нежелание разбираться в новых системах


Слайд 41

Разделение ответственности Человек, который отвечает за систему, должен иметь всю полноту власти Можно разделить роли, но не обязанности Коллективной ответственности не бывает. Коллективной бывает только безответственность (Валерий Лобановский)


Слайд 42

Мы нашли баг в системе, вы можете прислать нам последнюю версию, мы выложим ее сегодня ночью


Слайд 43

Очень важно Сложность исправления бага определяют разработчики Тестирование может занимать намного больше, чем сам фикс Может потребоваться значительное обновление системы


Слайд 44

Обновление системы План работ Сценарий проверки План В (если все плохо) Сценарий проверки плана В


Слайд 45

Формальные процедуры Версионность Разные ветки для активной разработки и релиза Разделение уровней допуска Процедуры утверждения релизов


Слайд 46

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


Слайд 47

Типичные ситуации Программисты всегда занимаются бессмысленным украшательством, система и так неплохо работает Улучшение кода это замечательно, но у нас пока есть более важная работа


Слайд 48

Важно Расставить приоритеты на каждый этап проекта Убедиться, что все разработчики правильно понимают приоритеты каждого из этапов Понимать, что рефакторинг – неотъемлемая часть любой разработки Доверять разработчикам


Слайд 49

Вопросы? artem@gramant.ru


×

HTML:





Ссылка: