Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

562 views

Published on

  • Be the first to comment

  • Be the first to like this

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

  1. 1. О чем стоит подумать, приступая к разработке высоконагруженной системы. Артем Вольфтруб
  2. 2. У нас есть своя IT команда, но она сильно загружена в ближайшие три месяца. Мы рассчитываем, что за это время вы напишите первую версию системы, которую мы будем развивать своими силами. 1
  3. 3. Цикл разработки интернет-проекта разработка аналитика тестирование t 1
  4. 4. Важно понимать, что <ul><li>Три месяца – минимальный цикл разработки интернет системы </li></ul><ul><li>К моменту релиза требования поменяются процентов на 40 </li></ul><ul><li>Если N разработчиков сделают систему за три месяца, то 2 *N </li></ul><ul><li>разработчиков сделают систему за … </li></ul><ul><li>Основная работа начинается после релиза </li></ul>три месяца 1
  5. 5. Передача проекта другой команде <ul><li>Передавать код другой команде сразу после релиза – плохая идея </li></ul><ul><li>Передавать код в виде дампа svn - очень плохая идея </li></ul><ul><li>Личное VS профессиональное </li></ul>1
  6. 6. Чтобы не было мучительно больно <ul><li>Решение о передаче проекта не должно быть спонтанным </li></ul><ul><li>Решение должно быть известно заранее </li></ul><ul><li>Привлекайте разработчиков к процессу </li></ul><ul><li>Приготовьтесь заплатить дважды </li></ul>1
  7. 7. Способы облегчить процесс <ul><li>Совместная работа над проектом </li></ul><ul><li>Постепенный ввод новой команды </li></ul>1
  8. 8. В первую версию системы должно войти N фич. У нас есть еще несколько минорных пожеланий, но их можно будет реализовать после выпуска первой версии. 2
  9. 9. Формирование требований <ul><li>Анализ рынка </li></ul><ul><li>Формирование ключевых пользовательских групп </li></ul><ul><li>Формирование стратегии </li></ul><ul><li>Интервьюирование ключевых пользователей </li></ul><ul><li>Прототипирование </li></ul><ul><li>Тестирование, получение обратной связи </li></ul><ul><li>Коррекция </li></ul>ТАК НЕ БЫВАЕТ 2
  10. 10. Формирование требований <ul><li>Наличие аналогичного продукта или сервиса </li></ul><ul><li>Видение системы, изложенное на листе А4 </li></ul><ul><li>Идея в голове начальника </li></ul>ТАК БЫВАЕТ 2
  11. 11. Из опыта <ul><li>На момент релиза, востребованными оказываются около 60% фич </li></ul><ul><li>40% фич, которые оказались не востребованными – самые сложные с точки зрения реализации </li></ul><ul><li>Наиболее ценные фичи не попадают в первую версию </li></ul>2
  12. 12. Рамки проекта <ul><li>Старайтесь включать в первую версию только то, без чего </li></ul><ul><li>реально нельзя жить. Экономьте время! </li></ul><ul><li>Основной источник требований – пользователь </li></ul><ul><li>Бета-версия – главный инструмент аналитика </li></ul><ul><li>Бета-версия – полностью функциональный </li></ul><ul><li>продукт, а не «отмазка» для разработчиков </li></ul><ul><li>Разработка не заканчивается релизом </li></ul>2
  13. 13. Система должна быть масштабируемой. Нам нужен подробный план того, как мы будем справляться с нагрузками, когда система вырастет со 100 000 пользователей до 10 000 000. 3
  14. 14. Цели планирования <ul><li>План для начальства или план для разработчиков </li></ul><ul><li>Узкие места возникают совершенно не там, где это предполагалось </li></ul><ul><li>А кто будет писать? </li></ul>3
  15. 15. Анализ нагрузки <ul><li>Оцениваем трафик </li></ul><ul><li>Оцениваем объем данных </li></ul><ul><li>Фантазируем («если – то») </li></ul>3
  16. 16. Слайд не для менеджеров! <ul><li>У «Веселого фермера» тоже был первый пользователь </li></ul><ul><li>Когда у вас будет 10 000 000 пользователей, у вас будут деньги, </li></ul><ul><li>чтобы все переписать </li></ul>3
  17. 17. Производительность системы будет проверяться проведением полноценного нагрузочного тестирования перед сдачей проекта. 4
  18. 18. Проблемы нагрузочного тестирования <ul><li>Смоделировать реальные действия пользователя очень сложно </li></ul><ul><li>Влияние внешних компонентов </li></ul><ul><li>Тепличные условия тестирования </li></ul><ul><li>Заказчик считает, что нагрузочное тестирование позволит </li></ul><ul><li>оценить качество системы </li></ul>4
  19. 19. Хроники нагрузочного тестирования 4
  20. 20. Хроники нагрузочного тестирования 4
  21. 21. Хроники нагрузочного тестирования 4
  22. 22. Хроники нагрузочного тестирования 4
  23. 23. Обобщаем <ul><li>Другое железо </li></ul><ul><li>Другой объем данных </li></ul><ul><li>Другой канал </li></ul><ul><li>Влияние окружения на работу приложения </li></ul><ul><li>Интерполяция не работает </li></ul>4
  24. 24. Выводы <ul><li>Нагрузочное тестирование инструмент анализа, а не </li></ul><ul><li>критерий приемки </li></ul><ul><li>Проверять лучше отдельные сценарии, </li></ul><ul><li>а не полноценную работу приложения </li></ul>4
  25. 25. Что значит приемлемый уровень отказоустойчивости? Система должна работать безотказно! 5
  26. 26. Виды простоев <ul><li>Отказ в результате выхода из строя </li></ul><ul><li>Остановка на плановое обслуживание </li></ul>5
  27. 27. Оценка отказоустойчивости <ul><li>Внешние зависимости </li></ul><ul><li>Прагматичный подход (99.99% - это 1 час в год) </li></ul><ul><li>Выделение критических компонентов </li></ul>5
  28. 28. Кому нужна отказоустойчивость <ul><li>Компоненты, которые используются внешними системами </li></ul><ul><li>Компоненты, от которых зависит бизнес компании </li></ul><ul><li>Компоненты, простой которых связан с репутационными потерями </li></ul><ul><li>компании </li></ul>5
  29. 29. Зачем нам система мониторинга? Если система сломается, это и так все увидят! 6
  30. 30. Проблемы <ul><li>Мониторинг не является частью проекта </li></ul><ul><li>Систему мониторинга должен кто-то эксплуатировать </li></ul>Запуск высокнагруженной системы без мониторинга не имеет смысла! 6
  31. 31. Что дает мониторинг <ul><li>Прогнозирование нагрузки </li></ul><ul><li>Диагностика проблем на ранней стадии </li></ul><ul><li>Выявление типовых проблем разработка универсальных </li></ul><ul><li>решений </li></ul><ul><li>Может использоваться, как инструмент аналитика </li></ul>6
  32. 32. Виды мониторинга <ul><li>Физический уровень </li></ul><ul><li>(сеть, доступность сервера, CPU , место на диске, память, IO) </li></ul><ul><li>Уровень приложения </li></ul><ul><li>(HTTP Errors, Response time, Exceptions) </li></ul><ul><li>Бизнес уровень </li></ul><ul><li>( основан на бизнес критериях) </li></ul>6
  33. 33. Методы измерений <ul><li>Критериальная система </li></ul><ul><li>Тренды </li></ul>6
  34. 34. Система мониторинга 6
  35. 35. Согласно последним обзорам, производительность фреймворка XYZ выше, чем ZYX. Давайте разрабатывать систему с использованием XYZ 7
  36. 36. Причины ограничения выбора <ul><li>Корпоративный стандарт </li></ul><ul><li>Расширения существующей системы </li></ul><ul><li>Собственная команда разработчиков </li></ul>7
  37. 37. Сравнение фреймворков <ul><li>Самый быстрый фреймворк - это тот, которым умеют </li></ul><ul><li>пользоваться разработчики </li></ul><ul><li>Программа « Hello world » всегда работает быстро </li></ul>7
  38. 38. 7
  39. 39. Как выбирать <ul><li>Исходите из текущих задач и задач на ближайшую </li></ul><ul><li>перспективу (время написания первой версии + поддержка) </li></ul><ul><li>Смотреть на профиль команды </li></ul>7
  40. 40. Наши IT-шники не разбираются в вашей системе. Напишите нам максимально подробную пошаговую инструкцию, как ее устанавливать и поддерживать. 8
  41. 41. Откуда растут ноги <ul><li>Конфиденциальная информация </li></ul><ul><li>Корпоративные стандарт безопасности </li></ul><ul><li>Нежелание разбираться в новых системах </li></ul>9
  42. 42. Разделение ответственности <ul><li>Человек, который отвечает за систему, должен иметь </li></ul><ul><li>всю полноту власти </li></ul><ul><li>Можно разделить роли, но не обязанности </li></ul>Коллективной ответственности не бывает. Коллективной бывает только безответственность (Валерий Лобановский) 9
  43. 43. Мы нашли баг в системе, вы можете прислать нам последнюю версию, мы выложим ее сегодня ночью 9
  44. 44. Очень важно <ul><li>Сложность исправления бага определяют разработчики </li></ul><ul><li>Тестирование может занимать намного больше, чем сам фикс </li></ul><ul><li>Может потребоваться значительное обновление системы </li></ul>9
  45. 45. Обновление системы <ul><li>План работ </li></ul><ul><li>Сценарий проверки </li></ul><ul><li>План В (если все плохо) </li></ul><ul><li>Сценарий проверки плана В </li></ul>9
  46. 46. Формальные процедуры <ul><li>Версионность </li></ul><ul><li>Разные ветки для активной разработки и релиза </li></ul><ul><li>Разделение уровней допуска </li></ul><ul><li>Процедуры утверждения релизов </li></ul>9
  47. 47. Зачем переписывать код, который был написан всего пару месяцев назад. У нас еще куча фич, которые нужно реализовать. 10
  48. 48. Типичные ситуации <ul><li>Программисты всегда занимаются бессмысленным </li></ul><ul><li>украшательством, система и так неплохо работает </li></ul><ul><li>Улучшение кода это замечательно, но у нас пока есть более </li></ul><ul><li>важная работа </li></ul>10
  49. 49. Важно <ul><li>Расставить приоритеты на каждый этап проекта </li></ul><ul><li>Убедиться, что все разработчики правильно понимают </li></ul><ul><li>приоритеты каждого из этапов </li></ul><ul><li>Понимать, что рефакторинг – неотъемлемая часть любой </li></ul><ul><li>разработки </li></ul><ul><li>Доверять разработчикам </li></ul>10
  50. 50. Вопросы? [email_address]

×