Картинки к моему рассказу о том, что не всегда круто спешить и бежать впереди паровоза при оптимизации и внедрении новых модных решений. Тезисы тут: http://junior.highload.ru/2016/abstracts/2221.html
Картинки к моему рассказу о том, что такое фреймворки и с чем их едят, что лучше не есть и как выбрать приправы для приготовления. Тезисы тут: http://backendconf.ru/2016/abstracts/2123.html
Картинки к моему рассказу о том, как мы делаем Банки.ру. Некоторые слайды очень неоднозначны без текста. Тезисы тут: http://nastachku.ru/lectures?lecture_id=630#lecture_630
Видео тут https://www.youtube.com/watch?v=m5QuiTZwMrU
Поговорим о неотъемлемой составляющей большого числа современных веб-проектов — о фреймворках.
Рассмотрим следующие темы и поищем ответы на вопросы:
1) Что такое фреймворк, и зачем их пишут.
2) Почему для некоторых языков их десятки, а для некоторых — единицы.
3) В чём плюсы и минусы применения.
4) Наиболее распространённые мифы.
5) Использовать или нет — примеры из жизни.
6) Как выбрать из множества доступных вариантов, на что стоит обратить внимание.
Как сделать свой SDK и первые 50 расширений от подпольных технологий к интегр...Ontico
Выпуск коробочного продукта — это всегда компромисс между количеством новых фичей, их качеством и длиной релиз цикла. И всегда есть фичи для ограниченной аудитории или просто эксперименты. Популярное решение в такой ситуации — возможность написания плагинов к продукту. Но для написания плагинов нужно иметь мощное SDK у самого продукта. В Plesk мы назвали такие плагины расширениями (extension), реализовали SDK и создали свой каталог.
В докладе я расскажу:
- как мы разрабатывали свой SDK и каталог расширений;
- через что мы прошли, чтобы выйти на рынок;
- как мы публикуем расширения наших партнёров и вендоров, и какие расширения никогда не попадают в каталог;
- какими были наши первые расширения, и каким каталог стал после 2 лет от официального запуска;
- каким мы видим будущее нашего каталога расширений.
Алексей Трошин. Менеджер не нужен: быстрые шаблоны правильных коммуникацийScrumTrek
Алексей Трошин.
Первый коммерческий сайт создал в 2002 году, первый интернет-магазин вывел в плюс в 2005, участвовал в развитии крупнейших порталов Рунета - АВТО.РУ (www.auto.ru) и Банки.ру (www.banki.ru), развивал конструктор сайтов Сетап (www.setup.ru), создавал первый российский интернет-магазин, вышедший на IPO - Ютинет.ру (www.utinet.ru), поучаствовал в развитии SaaS-системы управления задачами Мегаплан (www.megaplan.ru). Успел нанести непоправимую пользу нескольким стартапам, запустить новые продукты в B2B-Center.ru. Сейчас в ФИНАМ. Выступал на AgileDays в 2012, 14, 15, 16, Agile с 2009-го года (CSM, CSPO), в работе и по жизни :)
Александр Сербул. Прикладное XP в «1С-Битрикс»: как развивать продукт более 1...ScrumTrek
В компании «1С-Битрикс более 10 лет успешно используется плеяда Agile методологий как для управления продуктом, так и для развития технологической платформы: от XP до Model Storming и Story Mappings, от глубокого проникновения всех «бойцов» общими командными целями и интенсивных визуальных коммуникаций без ТЗ, до выполнения топ-менеджерами компании интегрирующих ролей Scrum Master/ProductOwner, вплоть до парного программирования с генеральным директором. Самобытное и глубокое проникновение в культуру команды принципов Agile Manifesto, уважение клиента, возведенное в культ, с искренним желанием решить его технологические задачи, практическое стремление к техническому совершенству. Мы расскажем об этом, поделимся собственным опытом и инструментами, расскажем что работает лучше и когда, а что не взлетает ни при каких условиях. Особое внимание уделим особенностям применения Agile к задачам, требующим глубокого системного анализа и проектирования.
Евгений Джамалов. Agile в условиях мульти-вендорности и распределённых команд.ScrumTrek
Мы запустили 12 команд за 9 месяцев. У нас дружат 7 вендоров. Разрабатываем 4 больших продукта. Люди разбросаны по 7-ми локациям. В команде может быть до 4 представителей вендоров. Как минимум, по 1 человеку от другого вендора в команде. Сказка? Этот доклад о том, как мы их "дружили" и синхронизировали. Мой опыт и доклад интересны тем, что я столкнулся с проблемой, которой не было найдено никакого решения в свободном доступе. Мне хотелось бы в формате сказки, поделится с вами тем, как именно мы строили нашу работу и отношения для достижения результата, а так же рассказать, как и почему мы оказались в такой ситуации. К сожалению, много придётся оставить за кадром... так что - спрашивайте!
Картинки к моему рассказу о том, что такое фреймворки и с чем их едят, что лучше не есть и как выбрать приправы для приготовления. Тезисы тут: http://backendconf.ru/2016/abstracts/2123.html
Картинки к моему рассказу о том, как мы делаем Банки.ру. Некоторые слайды очень неоднозначны без текста. Тезисы тут: http://nastachku.ru/lectures?lecture_id=630#lecture_630
Видео тут https://www.youtube.com/watch?v=m5QuiTZwMrU
Поговорим о неотъемлемой составляющей большого числа современных веб-проектов — о фреймворках.
Рассмотрим следующие темы и поищем ответы на вопросы:
1) Что такое фреймворк, и зачем их пишут.
2) Почему для некоторых языков их десятки, а для некоторых — единицы.
3) В чём плюсы и минусы применения.
4) Наиболее распространённые мифы.
5) Использовать или нет — примеры из жизни.
6) Как выбрать из множества доступных вариантов, на что стоит обратить внимание.
Как сделать свой SDK и первые 50 расширений от подпольных технологий к интегр...Ontico
Выпуск коробочного продукта — это всегда компромисс между количеством новых фичей, их качеством и длиной релиз цикла. И всегда есть фичи для ограниченной аудитории или просто эксперименты. Популярное решение в такой ситуации — возможность написания плагинов к продукту. Но для написания плагинов нужно иметь мощное SDK у самого продукта. В Plesk мы назвали такие плагины расширениями (extension), реализовали SDK и создали свой каталог.
В докладе я расскажу:
- как мы разрабатывали свой SDK и каталог расширений;
- через что мы прошли, чтобы выйти на рынок;
- как мы публикуем расширения наших партнёров и вендоров, и какие расширения никогда не попадают в каталог;
- какими были наши первые расширения, и каким каталог стал после 2 лет от официального запуска;
- каким мы видим будущее нашего каталога расширений.
Алексей Трошин. Менеджер не нужен: быстрые шаблоны правильных коммуникацийScrumTrek
Алексей Трошин.
Первый коммерческий сайт создал в 2002 году, первый интернет-магазин вывел в плюс в 2005, участвовал в развитии крупнейших порталов Рунета - АВТО.РУ (www.auto.ru) и Банки.ру (www.banki.ru), развивал конструктор сайтов Сетап (www.setup.ru), создавал первый российский интернет-магазин, вышедший на IPO - Ютинет.ру (www.utinet.ru), поучаствовал в развитии SaaS-системы управления задачами Мегаплан (www.megaplan.ru). Успел нанести непоправимую пользу нескольким стартапам, запустить новые продукты в B2B-Center.ru. Сейчас в ФИНАМ. Выступал на AgileDays в 2012, 14, 15, 16, Agile с 2009-го года (CSM, CSPO), в работе и по жизни :)
Александр Сербул. Прикладное XP в «1С-Битрикс»: как развивать продукт более 1...ScrumTrek
В компании «1С-Битрикс более 10 лет успешно используется плеяда Agile методологий как для управления продуктом, так и для развития технологической платформы: от XP до Model Storming и Story Mappings, от глубокого проникновения всех «бойцов» общими командными целями и интенсивных визуальных коммуникаций без ТЗ, до выполнения топ-менеджерами компании интегрирующих ролей Scrum Master/ProductOwner, вплоть до парного программирования с генеральным директором. Самобытное и глубокое проникновение в культуру команды принципов Agile Manifesto, уважение клиента, возведенное в культ, с искренним желанием решить его технологические задачи, практическое стремление к техническому совершенству. Мы расскажем об этом, поделимся собственным опытом и инструментами, расскажем что работает лучше и когда, а что не взлетает ни при каких условиях. Особое внимание уделим особенностям применения Agile к задачам, требующим глубокого системного анализа и проектирования.
Евгений Джамалов. Agile в условиях мульти-вендорности и распределённых команд.ScrumTrek
Мы запустили 12 команд за 9 месяцев. У нас дружат 7 вендоров. Разрабатываем 4 больших продукта. Люди разбросаны по 7-ми локациям. В команде может быть до 4 представителей вендоров. Как минимум, по 1 человеку от другого вендора в команде. Сказка? Этот доклад о том, как мы их "дружили" и синхронизировали. Мой опыт и доклад интересны тем, что я столкнулся с проблемой, которой не было найдено никакого решения в свободном доступе. Мне хотелось бы в формате сказки, поделится с вами тем, как именно мы строили нашу работу и отношения для достижения результата, а так же рассказать, как и почему мы оказались в такой ситуации. К сожалению, много придётся оставить за кадром... так что - спрашивайте!
ChatOps на практике. Организация работы команды сопровождения / Евгений Потап...Ontico
1. Взаимодействие с командой сопровождения через чаты — преимущества и проблемы.
1.1. ChatOps — о чем это?
1.2. Преимущества взаимодействия и постановки задач через чаты.
1.3. Проблемы хаотичности взаимодействия.
2. Интеграция процессов технической поддержки в ChatOps.
2.1. Постановка задач.
2.2. Мониторинг.
2.3. Оперативное реагирование.
3. Наш опыт доработки Telegram для интеграции с системами постановки задач, мониторингом и мониторингом самого взаимодействия.
Когда код «убивает», или зачем нам тестировать наши продуктыОлег Стрекаловский
Доклад посвящен теме тестирования и надёжности ПО. Что вы получаете, когда забываете о качестве разрабатываемого продукта и "куда копать", если вы вдруг решите начать проверять то, что у вас разрабатывается.
Быстрое расширение Robot Framework под свои нужды с использованием Pythonautomated-testing.info
Быстрое расширение Robot Framework под свои нужды с использованием Python, Михаил Поляруш
Когда мы начинаем заниматься автоматизацией тестирования ПО, мы редко знаем и понимаем, что нам надо будет делать, а тем более, как это нужно реализовать. Потому, выбираем самые простые решения, которые иногда даже не подразумевают программирования. Вы считаете, что успешная автоматизация может быть без программирования? Я уверен, что НЕТ, и с уверенностью могу сказать, что процесс автоматизации с помощью python и RobotFramework может значительно упростить Вам жизнь. Убедитесь в том, что архитектура RobotFramework очень гибкая, а python – лучший друг автоматизатора. Вас ждет увлекательная теория и много практики в живую.
Фреймворк для регрессионного тестирования на основе WebDriver, Бордюг Иван
В этом докладе слушатели услышат об идее автоматизации для людей с разным уровнем знаний в этой области. Также слушатель увидит, как быстро могут создавать тестовые сценарии по технологии BDD, которые в будущем станут тестами для регрессионного тестирования. Доклад будет построен на уже существующей разработке докладчика, будут высветлены все позитивные и негативные стороны данного подхода, а также проблемы, которые удалось решить в процессе автоматизации и проблемы, с которыми столкнулась команда в процессе использования данного подхода.
Tech Talks @NSU: Рассказ о разных профессиях в IT-индустрии, или почему не вс...Tech Talks @NSU
http://techtalks.nsu.ru
20 февраля 2013. Рассказ о разных профессиях в IT-индустрии, или почему не все выпускники IT-специальностей пишут код (Семён Факторович, Noveo)
«Семен Факторович (Noveo, Новосибирск) рассказывает о разных профессиях в IT-индустрии и о вариантах карьерного роста IT-специалиста»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
User Stories - этот подход к описанию знаний о продукте просто понять и очень сложно использовать :) Кроме того, складывается ощущение, что при его использовании забывается самая главная часть - умение рассказывать истории о продукте и формировать общее понимание без необходимости подробного описания всех спецификаций, которые все равно никто никогда не читает. Мы постарались собрать все темы, которые необходимо осветить для беспрепятственной реализации задумок и разработали специальный инструмент для фасилитации обсуждений - User Story Canvas
RTB и его проблематика должны быть знакомы участникам конференции - мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
При первом подходе к снаряду задача выглядит довольно простой: вот запрос с критериями, вот база данных с ответами - выбирай по индексу и отвечай.
На самом деле все несколько сложнее. Начать с того, что некоторые критерии отбора - негативные. Затем мы имеем дело с выборкой по десятку индексов, каждый из которых обладает низкой cardinality. И, наконец, мы имеем дело с большими объемами: около 10М строк в исходных данных, около 10К строк в финальной выборке. Ах, нет, еще финальная выборка должна быть отсортирована по приоритету! И надо не забыть про атомарные блокировку и списание средств...
От идеи прототипа на perl пришлось отказаться еще на этапе постановки задачи :)
Итак, мы имеем задачу с интенсивным IO, высокой нагрузкой, высокими скоростями, сложными структурами данных и эвристическими алгоритмами.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие - нет, будет рассказано в докладе.
Также в докладе будет рассказано о том, как сортировка была заменена случайной выборкой, и чем пришлось заплатить за то, чтобы эта замена оказалась равноценной.
Будет показано, почему мы наплевательски отнеслись к гипотетической потере 20% возможностей поучаствовать в аукционе, и почему реальный процент потерь много ниже.
Будет раскрыта роль СУБД MySQL в этом проекте, со всем блеском высокой производительности и нищетой отказоустойчивости.
Вопросы геотаргетинга, использования PostGIS и кэширования результатов поиска региона по координатам будут затронуты вскользь, как неоднократно обсуждавшиеся на этой и подобных конференциях.
А вот анатомия производительности приложения на Go будет рассмотрена подробнейшим образом - с графиками и числами.
Также подробно будут рассмотрены наши победы и поражения в борьбе со статис
ChatOps на практике. Организация работы команды сопровождения / Евгений Потап...Ontico
1. Взаимодействие с командой сопровождения через чаты — преимущества и проблемы.
1.1. ChatOps — о чем это?
1.2. Преимущества взаимодействия и постановки задач через чаты.
1.3. Проблемы хаотичности взаимодействия.
2. Интеграция процессов технической поддержки в ChatOps.
2.1. Постановка задач.
2.2. Мониторинг.
2.3. Оперативное реагирование.
3. Наш опыт доработки Telegram для интеграции с системами постановки задач, мониторингом и мониторингом самого взаимодействия.
Когда код «убивает», или зачем нам тестировать наши продуктыОлег Стрекаловский
Доклад посвящен теме тестирования и надёжности ПО. Что вы получаете, когда забываете о качестве разрабатываемого продукта и "куда копать", если вы вдруг решите начать проверять то, что у вас разрабатывается.
Быстрое расширение Robot Framework под свои нужды с использованием Pythonautomated-testing.info
Быстрое расширение Robot Framework под свои нужды с использованием Python, Михаил Поляруш
Когда мы начинаем заниматься автоматизацией тестирования ПО, мы редко знаем и понимаем, что нам надо будет делать, а тем более, как это нужно реализовать. Потому, выбираем самые простые решения, которые иногда даже не подразумевают программирования. Вы считаете, что успешная автоматизация может быть без программирования? Я уверен, что НЕТ, и с уверенностью могу сказать, что процесс автоматизации с помощью python и RobotFramework может значительно упростить Вам жизнь. Убедитесь в том, что архитектура RobotFramework очень гибкая, а python – лучший друг автоматизатора. Вас ждет увлекательная теория и много практики в живую.
Фреймворк для регрессионного тестирования на основе WebDriver, Бордюг Иван
В этом докладе слушатели услышат об идее автоматизации для людей с разным уровнем знаний в этой области. Также слушатель увидит, как быстро могут создавать тестовые сценарии по технологии BDD, которые в будущем станут тестами для регрессионного тестирования. Доклад будет построен на уже существующей разработке докладчика, будут высветлены все позитивные и негативные стороны данного подхода, а также проблемы, которые удалось решить в процессе автоматизации и проблемы, с которыми столкнулась команда в процессе использования данного подхода.
Tech Talks @NSU: Рассказ о разных профессиях в IT-индустрии, или почему не вс...Tech Talks @NSU
http://techtalks.nsu.ru
20 февраля 2013. Рассказ о разных профессиях в IT-индустрии, или почему не все выпускники IT-специальностей пишут код (Семён Факторович, Noveo)
«Семен Факторович (Noveo, Новосибирск) рассказывает о разных профессиях в IT-индустрии и о вариантах карьерного роста IT-специалиста»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
User Stories - этот подход к описанию знаний о продукте просто понять и очень сложно использовать :) Кроме того, складывается ощущение, что при его использовании забывается самая главная часть - умение рассказывать истории о продукте и формировать общее понимание без необходимости подробного описания всех спецификаций, которые все равно никто никогда не читает. Мы постарались собрать все темы, которые необходимо осветить для беспрепятственной реализации задумок и разработали специальный инструмент для фасилитации обсуждений - User Story Canvas
RTB и его проблематика должны быть знакомы участникам конференции - мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
При первом подходе к снаряду задача выглядит довольно простой: вот запрос с критериями, вот база данных с ответами - выбирай по индексу и отвечай.
На самом деле все несколько сложнее. Начать с того, что некоторые критерии отбора - негативные. Затем мы имеем дело с выборкой по десятку индексов, каждый из которых обладает низкой cardinality. И, наконец, мы имеем дело с большими объемами: около 10М строк в исходных данных, около 10К строк в финальной выборке. Ах, нет, еще финальная выборка должна быть отсортирована по приоритету! И надо не забыть про атомарные блокировку и списание средств...
От идеи прототипа на perl пришлось отказаться еще на этапе постановки задачи :)
Итак, мы имеем задачу с интенсивным IO, высокой нагрузкой, высокими скоростями, сложными структурами данных и эвристическими алгоритмами.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие - нет, будет рассказано в докладе.
Также в докладе будет рассказано о том, как сортировка была заменена случайной выборкой, и чем пришлось заплатить за то, чтобы эта замена оказалась равноценной.
Будет показано, почему мы наплевательски отнеслись к гипотетической потере 20% возможностей поучаствовать в аукционе, и почему реальный процент потерь много ниже.
Будет раскрыта роль СУБД MySQL в этом проекте, со всем блеском высокой производительности и нищетой отказоустойчивости.
Вопросы геотаргетинга, использования PostGIS и кэширования результатов поиска региона по координатам будут затронуты вскользь, как неоднократно обсуждавшиеся на этой и подобных конференциях.
А вот анатомия производительности приложения на Go будет рассмотрена подробнейшим образом - с графиками и числами.
Также подробно будут рассмотрены наши победы и поражения в борьбе со статис
RTB DSP на языке Go укрощение buzzwords / Даниил Подольский (Qmobi.Com)Ontico
RTB и его проблематика должны быть знакомы участникам конференции — мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие — нет, будет рассказано в докладе.
13 октября, DEV {web} - конференция о Highload веб-разработке. "Грабли при ма...IT-Portfolio
13 октября, DEV {web} - конференция о Highload веб-разработке. «Грабли при масштабировании веб-приложения, на которые очень легко наступить», Евгений Коковихин (системный архитектор WapStart)
Аннотация
Что происходит при росте приложения с 1М до 50М хитов в сутки. С какими проблемами можно столкнуться, когда серверов становится больше одного. О чем важно помнить при проектировании приложения, способного масштабироваться.
Подробно
Когда мы сделали первую публичную версию plus1.wapstart.ru, она помещалась на один сервер и была соответствующим образом спроектирована. Потом нагрузка начала расти, а мы начинали наступать на грабли. В докладе будет рассказано о наиболее типичных "граблях", что возможно позволит избежать их другими разработчиками при проектировании приложения.
О чем пойдет речь (кратко):
* балансировка нагрузки;
* кеширование данных и прогрев кешей;
* работа с сетью;
* сессии;
* файлы, загружаемые пользователями;
* работа с СУБД.
Мы пишем на PHP, используем фреймворк OnPHP, СУБД Postgres.
Биография
Родился в несуществующем городе несуществующей страны. Первый мобильный телефон увидел в 1997 году. С детства любил программировать, последние 4 года посвятил развитию рекламы в мобильном веб. Своими глазами видел эволюцию мобильных устройств и предпочтений рекламодателей.
Распространенные ошибки применения баз данныхSergey Xek
Распространенные ошибки применения баз данных. Сергей Аверин, Badoo.
Выбор хранилища данных — сложная задача, с которой часто сталкиваются раз- работчики. Чаще всего результат этого выбора — это компромисс. Я расскажу о собственном опыте, набитых «шишках», рассмотрю важные, на мой взгляд, связанные с этой задачей проблемы.
• Зачастую в стартапе изначально проектируется архитектура вокруг БД, рассчитанная на огромные нагрузки, на большое масштабирование, ко- торые потом в реальной жизни никогда не понадобится.
• Или проектируется архитектура, которая якобы дает отказоустойчи- вость, но при этом проблемы нижних уровней абстракции во внимание не принимаются.
• При выборе основной БД для проекта выбирается БД, которая не дает большого запаса фич в будущем, появляется дороговизна и сложность изменения.
• Используйте инструменты, которые вы хорошо изучили. «Психологиче- ская» популярность NoSQL. Достоинства и недостатки SQL и NoSQL БД.
• Проблемы использования БД как хранилища/движка обработки собы- тий зачастую не оправдано. Альтернативы.
• Использование БД для поиска, плюсы и минусы.
• Eventual consistency рулит, и как из этого можно извлечь пользу.
Целевая аудитория:
Доклад будет интересен веб-разработчикам, особенно из стартапов и неболь- ших команд, техническим руководителям.
Индустрия меняется прямо на глазах. Технология, еще вчера проходившая по категории "модно, но не нужно", сегодня используется даже бомжами, а завтра выбрасывается на свалку. Что учить, куда смотреть, какие книги читать? Я попробую рассказать свой взгляд на серверное программирование сейчас, в 2016 году.
Семён Факторович (Noveo) рассказывает о карьерных лестницах и различных профессиях в IT-индустрии, 20.02.2013
Software Industry 101 — это серия обзорных лекций для студентов Новосибирского государственного университета о профессиях в IT и о реалиях коммерческой разработки софта.
Более подробную информацию, материалы лекций и раписание занятий можно посмотреть на http://bit.ly/industry101
Как мы помогаем тестировщикам делать их работу лучшеRoman Ivliev
Картинки к моему рассказу на QAMeetUp в нижегородском mail.ru про то, как мы помогаем тестировщикам и мешаем одновременно.
Тезисно: есть куча способов привлечь других членов команды (админов, саппорт, разработчиков) к тестированию и выявлению дефектов, но не всегда это здорово, потому что де-факто получается огромное количество наведённых эффектов, борьба с которыми перекрывает по затратам нормальный процесс тестирования. Доклад больше менеджерский, но и остальным он будет полезен имхо. Видео и аудио не снимали. В слайдах есть контакты - с удовольствием отвечу на вопросы и расскажу про то, как и что у нас.
2. • Тестировщик
• Разработчик
• Руководитель разработчиков
• Руководитель тестировщиков
• Руководитель проектов
• CTO
• CIO
С 2002 года до сих пор
3. • 11 лет в Интернете;
• в среднем 400К уников в сутки;
• 40 инженеров;
• 70Тб трафика в месяц.
О Банки.ру
4. О чем мы с вами поговорим
• HighLoad или неHighload?
• Хабрэффект – причина или следствие?
• Про «костыли».
• Когда начинать делать круто?
• Что делать дальше, чтобы не окаменеть.
7. Как понять, highload у вас или нет?
• Можно ли понять это по числу серверов?
• Можно ли понять это по числу пользователей?
• Можно ли понять это по числу запросов?
• Можно ли понять это по числу строк в БД?
8. Как понять, highload у вас или нет?
• Сервера справляются с нагрузкой?
• Есть необходимость в масштабировании?
• Надо ли применять «нестандартные» решения?
10. Реактивный рост
• Скорее всего это какое-то событие
• Может быть ожидаемый
• Например, реклама
• А может быть случайный
• Например, реакция на пост на Хабре
• Или происки конкурентов
11.
12. Нужен анализ
• Понятно, что сломалось первым?
• Почему произошёл рост?
• Есть шансы, что это повторится?
• Что можно сделать сейчас, чтобы выстоять?
14. Костыль
• Это не всегда плохо;
• Это «быстро» решает задачу, НО
• Не всегда ловко;
• Не всегда технологично;
• Почти всегда в нарушение процессов (если они есть);
• Теперь вы должны.
15. Технологичное решение
• Это ловко (чаще всего);
• Технологично (чаще всего);
• Без нарушения процессов (чаще всего), НО
• Не всегда быстро;
• Не всегда вовремя.
16. Один из алгоритмов:
• Имеет место:
• Горит?
• Нужен Proof Of Concept?
• Шэф психанул?
• Прочие факторы ускорения
• Костыль!
• Сняли боль, но не вылечили проблему
• Или вылечили
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 – очень примерно
• Помните, что есть про профиль нагрузки
22.
23. Можно найти закономерности?
• Безусловно да, но не всегда вы угадаете
• Дисковое пространство? - скорее всего да
• Поведение СУБД? – скорее всего да
• IO, CPU, Net – очень примерно
• Помните про профиль нагрузки
• Бойтесь «среднего»
24.
25. Преждевременная оптимизация
• Возможно, вы угадаете;
• Но может быть иначе
• Лучше потратить время на
• Автоматизацию;
• Мониторинг;
• Работу с технодолгом.
26. Компонентная оптимизация
• Вместо «прокачки» всей системы;
• Анализируем узкие места;
• Исследуем возможность улучшения;
• Улучшаем.
27. Время и деньги
• Наверняка есть бюджет;
• Наверняка есть ограничение по людям;
• Наверняка у шэфа есть дэдлайн;
29. Список «Бунина»?
• Сервисно-ориентированная
архитектура;
• Вертикальное масштабирование;
• Горизонтальное масштабирование;
• Отложенные вычисления;
• Асинхронная обработка;
• Конвейерная обработка;
• Использование толстого клиента;
• Кеширование;
• Функциональное разделение;
• Шардинг;
• Виртуальные шарды;
• Центральный диспетчер;
• Репликация;
• Партиционирование;
• Кластеризация;
• Денормализация;
• Введение избыточности;
• Нереляционные СУБД;
• Параллельное выполнение
• И так далее….
30.
31. Список «Бунина»?
• 20+ паттернов разработки и проектирования
• Из них часть реально можно сделать на
коленке
• Из них ещё часть никогда не будут нужны в
вашем проекте
• Из них часть никогда не будут нужны во всех
ваших проектах
32. Важно помнить
• Нет стандарта на разработку высоконагруженных
систем;
• Не всё нужно здесь и сейчас;
• Иногда простое решение самое эффективное;
• То, что сделал Badoo, наверняка не для вас;
• Hype – бойтесь его.
33. Hype – это
• Интересно (почти всегда);
• Полезно (почти всегда);
• Риски (всегда!)
• Много новой документации;
• Проект может закрыться;
• Баги продукта станут вашими проблемами;
• Поддержка стоит денег и времени;
• Сложности поиска людей;
• Зоопарк.
35. Работа с тех.долгом
• 1 «костыль» = 1 задача в долг;
• Долг – полноправный участник планирования;
• Долг - полноправный по приоритетам;
• Регулярный просмотр и актуализация долга;
36. Важно!
• Время не на вашей стороне;
• Технологии не на вашей стороне;
• Бизнес не на вашей стороне;
• Вас ждёт «технический дефолт».