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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

20 4

21 4

22 4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

38 7

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

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

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

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

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

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

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

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

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

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

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

50 Вопросы?