Download to read offline
Uploaded byOntico
Всему своё время / Роман Ивлиев (Банки.ру)
Роман Ивлиев обсуждает аспекты разработки высоконагруженных систем, включая определение highload, анализ роста нагрузки и выбор между временными решениями и технологичными подходами. Он также подчеркивает важность мониторинга, автоматизации, работы с техническим долгом и осторожности по отношению к модным трендам в разработке. В заключение автор призывает к стабильности, прозрачности и гибкости в разработке, а также к постоянному обучению и совершенствованию системы.
More Related Content
Similar to Всему своё время / Роман Ивлиев (Банки.ру)
Всему своё время / Роман Ивлиев (Банки.ру)
- 1. Всему своё время РоманИвлиев, CIO, Банки.ру
- 2. • Тестировщик • Разработчик •Руководитель разработчиков • Руководитель тестировщиков • Руководитель проектов • CTO • CIO С 2002 года до сих пор
- 3. • 11 летв Интернете; • в среднем 400К уников в сутки; • 40 инженеров; • 70Тб трафика в месяц. О Банки.ру
- 4. О чем мыс вами поговорим • HighLoad или неHighload? • Хабрэффект – причина или следствие? • Про «костыли». • Когда начинать делать круто? • Что делать дальше, чтобы не окаменеть.
- 6. Highload или неHighload Такли ваш проект нагружен?
- 7. Как понять, highloadу вас или нет? • Можно ли понять это по числу серверов? • Можно ли понять это по числу пользователей? • Можно ли понять это по числу запросов? • Можно ли понять это по числу строк в БД?
- 8. Как понять, highloadу вас или нет? • Сервера справляются с нагрузкой? • Есть необходимость в масштабировании? • Надо ли применять «нестандартные» решения?
- 9.
- 10. Реактивный рост • Скореевсего это какое-то событие • Может быть ожидаемый • Например, реклама • А может быть случайный • Например, реакция на пост на Хабре • Или происки конкурентов
- 12. Нужен анализ • Понятно,что сломалось первым? • Почему произошёл рост? • Есть шансы, что это повторится? • Что можно сделать сейчас, чтобы выстоять?
- 13.
- 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. Важно! • Время нена вашей стороне; • Технологии не на вашей стороне; • Бизнес не на вашей стороне; • Вас ждёт «технический дефолт».
- 37.
- 39. Двигайтесь вперёд • Следитеза системой; • Изучайте узкие места; • Оценивайте риски; • Пробуйте на кошках; • Внедряйте.
- 40. Прикрывайте тыл • Стабильность; •Прозрачность; • Гибкость; • Свежие версии того, что вы уже используете.
- 41. «Слова вы услышали,поиск пути за вами» Уильям Деминг
- 42. С удовольствием отвечуна Ваши вопросы @dumtest roman@ivliev.info roman.ivliyev