ݺߣ

ݺߣShare a Scribd company logo

Всему своё время Highload Junior 2016

•Download as PPTX, PDF•
•
Roman Ivliev
Roman Ivliev

Картинки к моему рассказу о том, что не всегда круто спешить и бежать впереди паровоза при оптимизации и внедрении новых модных решений. Тезисы тут: http://junior.highload.ru/2016/abstracts/2221.html

1 of 42
Download to read offline
Всему своё время Роман Ивлиев, CIO, Банки.ру
• Тестировщик • Разработчик • Руководитель разработчиков • Руководитель тестировщиков • Руководитель проектов • CTO • CIO С 2002 года до сих пор
• 11 лет в Интернете; • в среднем 400К уников в сутки; • 40 инженеров; • 70Тб трафика в месяц. О Банки.ру
О чем мы с вами поговорим • HighLoad или неHighload? • Хабрэффект – причина или следствие? • Про «костыли». • Когда начинать делать круто? • Что делать дальше, чтобы не окаменеть.
Всему своё время Highload Junior 2016
Highload или неHighload Так ли ваш проект нагружен?
Как понять, highload у вас или нет? • Можно ли понять это по числу серверов? • Можно ли понять это по числу пользователей? • Можно ли понять это по числу запросов? • Можно ли понять это по числу строк в БД?
Как понять, highload у вас или нет? • Сервера справляются с нагрузкой? • Есть необходимость в масштабировании? • Надо ли применять «нестандартные» решения?
Хабрэффект Конец или начало?
Реактивный рост • Скорее всего это какое-то событие • Может быть ожидаемый • Например, реклама • А может быть случайный • Например, реакция на пост на Хабре • Или происки конкурентов
Всему своё время Highload Junior 2016
Нужен анализ • Понятно, что сломалось первым? • Почему произошёл рост? • Есть шансы, что это повторится? • Что можно сделать сейчас, чтобы выстоять?
«Костыли» Или высокотехнологичное решение ?
Костыль • Это не всегда плохо; • Это «быстро» решает задачу, НО • Не всегда ловко; • Не всегда технологично; • Почти всегда в нарушение процессов (если они есть); • Теперь вы должны.
Технологичное решение • Это ловко (чаще всего); • Технологично (чаще всего); • Без нарушения процессов (чаще всего), НО • Не всегда быстро; • Не всегда вовремя.
Один из алгоритмов: • Имеет место: • Горит? • Нужен Proof Of Concept? • Шэф психанул? • Прочие факторы ускорения • Костыль! • Сняли боль, но не вылечили проблему • Или вылечили
Когда нужно начинать? Или когда можно начинать?
Как искать точку начала перемен? • Мониторинг с первого дня проекта • Аналитика с первого дня проекта
Рост нагрузки редко бывает линейным • Вот так • 10usr = 10%CPU • 20usr =20%CPU • …. • 100usr=100%CPU • не бывает почти никогда
Рост нагрузки редко бывает линейным • Может случиться вот так • 100usr = 10%CPU • 200usr=100%CPU • Или вот так: • 10usr=10%CPU • 200usr=10%CPU, но 100% IO
Можно найти закономерности? • Безусловно да, но не всегда вы угадаете • Дисковое пространство? - скорее всего да • Поведение СУБД? – скорее всего да • IO, CPU, Net – очень примерно • Помните, что есть про профиль нагрузки
Всему своё время Highload Junior 2016
Можно найти закономерности? • Безусловно да, но не всегда вы угадаете • Дисковое пространство? - скорее всего да • Поведение СУБД? – скорее всего да • IO, CPU, Net – очень примерно • Помните про профиль нагрузки • Бойтесь «среднего»
Всему своё время Highload Junior 2016
Преждевременная оптимизация • Возможно, вы угадаете; • Но может быть иначе • Лучше потратить время на • Автоматизацию; • Мониторинг; • Работу с технодолгом.
Компонентная оптимизация • Вместо «прокачки» всей системы; • Анализируем узкие места; • Исследуем возможность улучшения; • Улучшаем.
Время и деньги • Наверняка есть бюджет; • Наверняка есть ограничение по людям; • Наверняка у шэфа есть дэдлайн;
Есть ли лёгкий способ? «Список Бунина» подойдёт?
Список «Бунина»? • Сервисно-ориентированная архитектура; • Вертикальное масштабирование; • Горизонтальное масштабирование; • Отложенные вычисления; • Асинхронная обработка; • Конвейерная обработка; • Использование толстого клиента; • Кеширование; • Функциональное разделение; • Шардинг; • Виртуальные шарды; • Центральный диспетчер; • Репликация; • Партиционирование; • Кластеризация; • Денормализация; • Введение избыточности; • Нереляционные СУБД; • Параллельное выполнение • И так далее….
Всему своё время Highload Junior 2016
Список «Бунина»? • 20+ паттернов разработки и проектирования • Из них часть реально можно сделать на коленке • Из них ещё часть никогда не будут нужны в вашем проекте • Из них часть никогда не будут нужны во всех ваших проектах
Важно помнить • Нет стандарта на разработку высоконагруженных систем; • Не всё нужно здесь и сейчас; • Иногда простое решение самое эффективное; • То, что сделал Badoo, наверняка не для вас; • Hype – бойтесь его.
Hype – это • Интересно (почти всегда); • Полезно (почти всегда); • Риски (всегда!) • Много новой документации; • Проект может закрыться; • Баги продукта станут вашими проблемами; • Поддержка стоит денег и времени; • Сложности поиска людей; • Зоопарк.
Как работать с тех.долгом? Планомерно достаём «костыли»
Работа с тех.долгом • 1 «костыль» = 1 задача в долг; • Долг – полноправный участник планирования; • Долг - полноправный по приоритетам; • Регулярный просмотр и актуализация долга;
Важно! • Время не на вашей стороне; • Технологии не на вашей стороне; • Бизнес не на вашей стороне; • Вас ждёт «технический дефолт».
Заключение Необходимость и достаточность
Всему своё время Highload Junior 2016
Двигайтесь вперёд • Следите за системой; • Изучайте узкие места; • Оценивайте риски; • Пробуйте на кошках; • Внедряйте.
Прикрывайте тыл • Стабильность; • Прозрачность; • Гибкость; • Свежие версии того, что вы уже используете.
«Слова вы услышали, поиск пути за вами» Уильям Деминг
С удовольствием отвечу на Ваши вопросы @dumtest roman@ivliev.info roman.ivliyev

More Related Content

Всему своё время Highload Junior 2016

  • 1. Всему своё время Роман Ивлиев, CIO, Банки.ру
  • 2. • Тестировщик • Разработчик • Руководитель разработчиков • Руководитель тестировщиков • Руководитель проектов • CTO • CIO С 2002 года до сих пор
  • 3. • 11 лет в Интернете; • в среднем 400К уников в сутки; • 40 инженеров; • 70Тб трафика в месяц. О Банки.ру
  • 4. О чем мы с вами поговорим • HighLoad или неHighload? • Хабрэффект – причина или следствие? • Про «костыли». • Когда начинать делать круто? • Что делать дальше, чтобы не окаменеть.
  • 6. Highload или неHighload Так ли ваш проект нагружен?
  • 7. Как понять, highload у вас или нет? • Можно ли понять это по числу серверов? • Можно ли понять это по числу пользователей? • Можно ли понять это по числу запросов? • Можно ли понять это по числу строк в БД?
  • 8. Как понять, highload у вас или нет? • Сервера справляются с нагрузкой? • Есть необходимость в масштабировании? • Надо ли применять «нестандартные» решения?
  • 10. Реактивный рост • Скорее всего это какое-то событие • Может быть ожидаемый • Например, реклама • А может быть случайный • Например, реакция на пост на Хабре • Или происки конкурентов
  • 12. Нужен анализ • Понятно, что сломалось первым? • Почему произошёл рост? • Есть шансы, что это повторится? • Что можно сделать сейчас, чтобы выстоять?
  • 14. Костыль • Это не всегда плохо; • Это «быстро» решает задачу, НО • Не всегда ловко; • Не всегда технологично; • Почти всегда в нарушение процессов (если они есть); • Теперь вы должны.
  • 15. Технологичное решение • Это ловко (чаще всего); • Технологично (чаще всего); • Без нарушения процессов (чаще всего), НО • Не всегда быстро; • Не всегда вовремя.
  • 16. Один из алгоритмов: • Имеет место: • Горит? • Нужен Proof Of Concept? • Шэф психанул? • Прочие факторы ускорения • Костыль! • Сняли боль, но не вылечили проблему • Или вылечили
  • 17. Когда нужно начинать? Или когда можно начинать?
  • 18. Как искать точку начала перемен? • Мониторинг с первого дня проекта • Аналитика с первого дня проекта
  • 19. Рост нагрузки редко бывает линейным • Вот так • 10usr = 10%CPU • 20usr =20%CPU • …. • 100usr=100%CPU • не бывает почти никогда
  • 20. Рост нагрузки редко бывает линейным • Может случиться вот так • 100usr = 10%CPU • 200usr=100%CPU • Или вот так: • 10usr=10%CPU • 200usr=10%CPU, но 100% IO
  • 21. Можно найти закономерности? • Безусловно да, но не всегда вы угадаете • Дисковое пространство? - скорее всего да • Поведение СУБД? – скорее всего да • IO, CPU, Net – очень примерно • Помните, что есть про профиль нагрузки
  • 23. Можно найти закономерности? • Безусловно да, но не всегда вы угадаете • Дисковое пространство? - скорее всего да • Поведение СУБД? – скорее всего да • IO, CPU, Net – очень примерно • Помните про профиль нагрузки • Бойтесь «среднего»
  • 25. Преждевременная оптимизация • Возможно, вы угадаете; • Но может быть иначе • Лучше потратить время на • Автоматизацию; • Мониторинг; • Работу с технодолгом.
  • 26. Компонентная оптимизация • Вместо «прокачки» всей системы; • Анализируем узкие места; • Исследуем возможность улучшения; • Улучшаем.
  • 27. Время и деньги • Наверняка есть бюджет; • Наверняка есть ограничение по людям; • Наверняка у шэфа есть дэдлайн;
  • 28. Есть ли лёгкий способ? «Список Бунина» подойдёт?
  • 29. Список «Бунина»? • Сервисно-ориентированная архитектура; • Вертикальное масштабирование; • Горизонтальное масштабирование; • Отложенные вычисления; • Асинхронная обработка; • Конвейерная обработка; • Использование толстого клиента; • Кеширование; • Функциональное разделение; • Шардинг; • Виртуальные шарды; • Центральный диспетчер; • Репликация; • Партиционирование; • Кластеризация; • Денормализация; • Введение избыточности; • Нереляционные СУБД; • Параллельное выполнение • И так далее….
  • 31. Список «Бунина»? • 20+ паттернов разработки и проектирования • Из них часть реально можно сделать на коленке • Из них ещё часть никогда не будут нужны в вашем проекте • Из них часть никогда не будут нужны во всех ваших проектах
  • 32. Важно помнить • Нет стандарта на разработку высоконагруженных систем; • Не всё нужно здесь и сейчас; • Иногда простое решение самое эффективное; • То, что сделал Badoo, наверняка не для вас; • Hype – бойтесь его.
  • 33. Hype – это • Интересно (почти всегда); • Полезно (почти всегда); • Риски (всегда!) • Много новой документации; • Проект может закрыться; • Баги продукта станут вашими проблемами; • Поддержка стоит денег и времени; • Сложности поиска людей; • Зоопарк.
  • 34. Как работать с тех.долгом? Планомерно достаём «костыли»
  • 35. Работа с тех.долгом • 1 «костыль» = 1 задача в долг; • Долг – полноправный участник планирования; • Долг - полноправный по приоритетам; • Регулярный просмотр и актуализация долга;
  • 36. Важно! • Время не на вашей стороне; • Технологии не на вашей стороне; • Бизнес не на вашей стороне; • Вас ждёт «технический дефолт».
  • 39. Двигайтесь вперёд • Следите за системой; • Изучайте узкие места; • Оценивайте риски; • Пробуйте на кошках; • Внедряйте.
  • 40. Прикрывайте тыл • Стабильность; • Прозрачность; • Гибкость; • Свежие версии того, что вы уже используете.
  • 41. «Слова вы услышали, поиск пути за вами» Уильям Деминг
  • 42. С удовольствием отвечу на Ваши вопросы @dumtest roman@ivliev.info roman.ivliyev