Экономический рост
<<  Стратегии роста и пути развития региональных банков. Экспансия московских банков в регионы Сарань через 20 лет  >>
Проблема взрывного роста аудитории: что делать, когда не хватает
Проблема взрывного роста аудитории: что делать, когда не хватает
310k – онлайновая игра
310k – онлайновая игра
INFON Spike
INFON Spike
Diary
Diary
Когда становится очевидным, что железо не справляется
Когда становится очевидным, что железо не справляется
Когда становится очевидным, что железо не справляется
Когда становится очевидным, что железо не справляется
Когда становится очевидным, что железо не справляется
Когда становится очевидным, что железо не справляется
С чего начать переделку
С чего начать переделку
С чего начать переделку
С чего начать переделку
Прежде всего, плясать от пользователя
Прежде всего, плясать от пользователя
Прежде всего, плясать от пользователя
Прежде всего, плясать от пользователя
Прежде всего, плясать от пользователя
Прежде всего, плясать от пользователя
Проблема взрывного роста аудитории: что делать, когда не хватает
Проблема взрывного роста аудитории: что делать, когда не хватает
Найти и оценить проблемные блоки
Найти и оценить проблемные блоки
Найти и оценить проблемные блоки
Найти и оценить проблемные блоки
Только на этом этапе стоит нарисовать всю систему вцелом
Только на этом этапе стоит нарисовать всю систему вцелом
При рисовании и обсуждении системы полезно воспользоваться следущими
При рисовании и обсуждении системы полезно воспользоваться следущими
Пригласить эксперта со стороны
Пригласить эксперта со стороны
Пригласить эксперта со стороны
Пригласить эксперта со стороны
Эксперт должен говорить на одном с вами языке
Эксперт должен говорить на одном с вами языке
Эксперт должен говорить на одном с вами языке
Эксперт должен говорить на одном с вами языке
Проблема взрывного роста аудитории: что делать, когда не хватает
Проблема взрывного роста аудитории: что делать, когда не хватает
White Board
White Board
Проблема взрывного роста аудитории: что делать, когда не хватает
Проблема взрывного роста аудитории: что делать, когда не хватает
По результатам обсуждения просмотреть всем вместе все слайды и
По результатам обсуждения просмотреть всем вместе все слайды и
Разработчики системы
Разработчики системы
Планирование
Планирование
Важно не забыть о:
Важно не забыть о:
Какие части системы очень не хочется переделывать:
Какие части системы очень не хочется переделывать:
Какие части системы очень не хочется переделывать:
Какие части системы очень не хочется переделывать:
Какие части системы очень не хочется переделывать:
Какие части системы очень не хочется переделывать:
Какие части системы очень не хочется переделывать:
Какие части системы очень не хочется переделывать:
Просто требуется представить, как дальше будет развиваться проект
Просто требуется представить, как дальше будет развиваться проект
Проектирование
Проектирование
Общая архитектура системы
Общая архитектура системы
Типичные решения проблемы производительности
Типичные решения проблемы производительности
Более мощное железо
Более мощное железо
Написать более эффективный код
Написать более эффективный код
Оптимизировать запросы к БД
Оптимизировать запросы к БД
Оптимизировать структуру БД
Оптимизировать структуру БД
Оптимизировать структуру БД
Оптимизировать структуру БД
Оптимизировать структуру БД
Оптимизировать структуру БД
Использование репликации БД
Использование репликации БД
Кэшировать
Кэшировать
Кэшировать
Кэшировать
Использование множества зеркал и балансировщика между ними
Использование множества зеркал и балансировщика между ними
Очереди задач
Очереди задач
Очереди задач
Очереди задач
Очереди задач
Очереди задач
Очереди задач
Очереди задач
RPC (remote procedure calling)
RPC (remote procedure calling)
RPC
RPC
RPC
RPC
Использование аппликэйшн-серверов
Использование аппликэйшн-серверов
Использование аппликэйшн-серверов
Использование аппликэйшн-серверов
Применяйте следующие подходы:
Применяйте следующие подходы:
Применяйте следующие подходы:
Применяйте следующие подходы:
Пишите техзадание
Пишите техзадание
Озвучте отличие между версиями системы
Озвучте отличие между версиями системы
Планируйте перенос
Планируйте перенос
Переделка
Переделка
Изменение требований в процессе разработки
Изменение требований в процессе разработки
Тестирование в процессе разработки
Тестирование в процессе разработки
Тестирование
Тестирование
Выкатка
Выкатка
Вопросы
Вопросы

Презентация: «Проблема взрывного роста аудитории: что делать, когда не хватает мощностей». Автор: . Файл: «Проблема взрывного роста аудитории: что делать, когда не хватает мощностей.ppt». Размер zip-архива: 5537 КБ.

Проблема взрывного роста аудитории: что делать, когда не хватает мощностей

содержание презентации «Проблема взрывного роста аудитории: что делать, когда не хватает мощностей.ppt»
СлайдТекст
1 Проблема взрывного роста аудитории: что делать, когда не хватает

Проблема взрывного роста аудитории: что делать, когда не хватает

мощностей?

Типичный случай интернет-проекта: он становится популярным и с каждым днём его аудитория растёт невиданными темпами. Каким образом наращивать мощность оборудования и ПО с учётом того, что останавливать проект нельзя?

2 310k – онлайновая игра

310k – онлайновая игра

Классическая LAMP система Прежде всего - чат со всеми сложностями в отдаче информации в реальном времени Быстрый (крайне быстрый) рост аудитории со 100 до 3000 человек [-] плохая оптимизация кода [-] проблемы с бюджетом

3 INFON Spike

INFON Spike

J2EE 365х24х7 миллионы запросов в сутки каждый абонент – это живые, уже заплаченные им деньги, поэтому запросы терять нельзя высокая нагрузка на биллинг

4 Diary

Diary

Ru

LAMP система рост аудитории опережал добавление мощностей был достигнут «потолок» архитектуры (добавление ещё одной машины ничего не решало) [-] MySQL и падение репликации мастер-мастер [-] узкое место – БД [-] экстенсивное наращивание БД и неоптимальная логика работы приложения (к примеру – JOIN’ы) [-] отсутствие кэширования выборок

5 Когда становится очевидным, что железо не справляется

Когда становится очевидным, что железо не справляется

6 Когда становится очевидным, что железо не справляется

Когда становится очевидным, что железо не справляется

Когда оно странно пахнет… и дымится.

7 Когда становится очевидным, что железо не справляется

Когда становится очевидным, что железо не справляется

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

8 С чего начать переделку

С чего начать переделку

9 С чего начать переделку

С чего начать переделку

С аудита системы!

10 Прежде всего, плясать от пользователя

Прежде всего, плясать от пользователя

11 Прежде всего, плясать от пользователя

Прежде всего, плясать от пользователя

Взять пользователя и очертить список его задач какие типы пользователей есть в системе (сайте)? Чем каждая группа отличается от других, что они делают на сайте? Какие задачи выполняют? Какой процент запросов приходится на выполнение той или иной задачи?

12 Прежде всего, плясать от пользователя

Прежде всего, плясать от пользователя

Внутренний путь пользователя по системе разделить виды запросов пользователя к системе (вызов френдленты, комментирование) взять наиболее часто встречающиеся виды запросов и нарисовать их, стрелочками показывая «а вот теперь он идёт туда» в сиквенс-диаграмме

13 Проблема взрывного роста аудитории: что делать, когда не хватает
14 Найти и оценить проблемные блоки

Найти и оценить проблемные блоки

15 Найти и оценить проблемные блоки

Найти и оценить проблемные блоки

Идти от внутреннего пути пользователя где больше всего теряется времени может сказаться на количестве свободных ниток где больше всего тратится процессорного времени может не хватить другим на обработку неразделяемые ресурсы, в очередях на обращение к которым стоят модули программ прежде всего - обращения к диску общая память приложений хранение сессий в частности и, вообще, хранение данных гэтвей на приём и отправку запросов инфраструктура, накладывающая ограничения на траффик

16 Только на этом этапе стоит нарисовать всю систему вцелом

Только на этом этапе стоит нарисовать всю систему вцелом

аудит внутреннего пути даст представление, с какой подробностью и какие блоки стоит рисовать Если начать рисовать раньше, то можно оказаться в ловушке «зашоренности сознания» - представляя всю систему вцелом, выделяются далеко не самые главные блоки, из-за которых происходят тормоза)

17 При рисовании и обсуждении системы полезно воспользоваться следущими

При рисовании и обсуждении системы полезно воспользоваться следущими

приёмами:

18 Пригласить эксперта со стороны

Пригласить эксперта со стороны

19 Пригласить эксперта со стороны

Пригласить эксперта со стороны

20 Эксперт должен говорить на одном с вами языке

Эксперт должен говорить на одном с вами языке

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

21 Эксперт должен говорить на одном с вами языке

Эксперт должен говорить на одном с вами языке

Желательно так же, чтобы эксперт имел опыт работы с подобными проблемами основное - даже не успешное разрешение, а знание «подводных камней» и практический опыт борьбы с ними

22 Проблема взрывного роста аудитории: что делать, когда не хватает
23 White Board

White Board

Рисовать всё слайдами подписывать каждый слайд и писать тезисы обсуждения фотографировать слайд, после чего его можно стирать или модифицировать

24 Проблема взрывного роста аудитории: что делать, когда не хватает
25 По результатам обсуждения просмотреть всем вместе все слайды и

По результатам обсуждения просмотреть всем вместе все слайды и

попытаться уложить это в какой-то документ рисовать диаграммы не нужно, достаточно использовать фотографии слайдов а вот расшифровать тексты тезисов с фотографий и написать к ним комментарии очень желательно очень-очень важно собирать все идеи, как по текущей системе

26 Разработчики системы

Разработчики системы

Прежде всего – сисадмин, который самый первый сталкивается с багами Дизайнер-юзабилист-программист клиента, который разрабатывает «морду сайта» Тестер, который знает все баги прошлой системы И тот парень, который даёт деньги на новое оборудование

27 Планирование

Планирование

28 Важно не забыть о:

Важно не забыть о:

Рабочих руках. кто чем может заниматься и сколько времени они могут потратить на проект немаловажно – в какой промежуток времени у них будет это время! Доступных ОС и языках программирования это может быть важно, в случае, если люди умеют писать на нескольких языках Материальных ресурсах прежде всего, количество серверов сетевая инфраструктура (хостинг) память производительность машинок лицензии на различные проприетарные модули системы т.д. Времени на переделку вообще тут полезно задуматься об этапах (милстоунах), к которым хотелось бы что-то получить и договориться, что это «что-то» будет

29 Какие части системы очень не хочется переделывать:

Какие части системы очень не хочется переделывать:

«Морда сайта» да и вообще дизайн, потому что долго и муторно, а дизайнер, который это делал давно уволился редизайн сайта в условиях, когда пользователям всё нравится, посещаемость активно растёт, а вот бэкэнда нехватает – странное дело

30 Какие части системы очень не хочется переделывать:

Какие части системы очень не хочется переделывать:

Интерфейсы интеграции и связи с внешними партнёрами потому что интерфейсы были утверждены давно, их формат – предмет договора, заключённого в позапрошлом году, да и партёры не собираются ничего менять

31 Какие части системы очень не хочется переделывать:

Какие части системы очень не хочется переделывать:

формат базы данных и вообще переделывать БД – долго и муторно, данные терять не хочется и т.д.

32 Какие части системы очень не хочется переделывать:

Какие части системы очень не хочется переделывать:

Какие-то куски бизнес-логики потому что они были написаны каким-то индусом из оффшорной конторы и как они работают без буддисткого мироощущения понять решительно невозможно

33 Просто требуется представить, как дальше будет развиваться проект

Просто требуется представить, как дальше будет развиваться проект

Какая посещаемость будет у него через год? А через два года? А через три?

34 Проектирование

Проектирование

Во время аудита системы и планирования становится понятен круг задач: что нужно будет переделать точно какие есть критические места (а значит и стоит подумать над этими вещами) от каких частей отказываться точно нельзя и что всё же делать с тем, что переделывать не хочется, но очень надо

35 Общая архитектура системы

Общая архитектура системы

Предлагаются все-все идеи новой системы, как она должна функционировать, из каких блоков состоять, как в ней разрешены указанные проблемы неплохо посмотреть на уже готовые примеры (хотя бы на уровне блок-схем) посмотреть достоинства и недостатки каждой предложенной архитектуры и кратко рассмотреть, чем это грозит в ближней перспективе количество работ по переделке время как решены проблемы того, что переписывать не хочется

36 Типичные решения проблемы производительности

Типичные решения проблемы производительности

37 Более мощное железо

Более мощное железо

Даёт быстрый рост производительности не нужно переделывать систему запас производительности быстро исчерпывается требует хорошей команды админов для переноса кода энергопотребление = проблемы со стойками

38 Написать более эффективный код

Написать более эффективный код

помогает разгрузить сервер может решить какие-то замеченные проблемы со стабильностью и безопасностью к сожалению плохо помогает с неразделяемыми и разделяемыми ресурсами чаще всего тормозит или нестабилен не плохой код, а используемые чужие библиотеки, сервера и БД уже в краткосрочной перспективе при увеличении количества народа быстродействия снова не хватит

39 Оптимизировать запросы к БД

Оптимизировать запросы к БД

правильно использовать возможности БД – это насущная необходимость от join’ов избавляться нужно – это однозначно не стоит забывать использовать выборки по индексам! Вспомнить SQL (к примеру, считать количество полей cout’ом, а не выборкой) хранимые процедуры позволяют существенно увеличить производительность уже в среднесрочной перспективе эффект от этого сойдёт на нет: БД всё же ограничена по вычислительным ресурсам, а возможности для оптимизации буду уже исчерпаны

40 Оптимизировать структуру БД

Оптимизировать структуру БД

Разделить поля по типу записи и чтения в них: статические (редко меняемые, такие, как user info), оптимизированные на чтение откроет возможности для кэширования поля на запись (к примеру, сообщения в чате) позволит более эффективно воспользоваться механизмом репликации выделение постоянно дополняемых таблиц позволит использовать механизм партишининга

41 Оптимизировать структуру БД

Оптимизировать структуру БД

разделение хранимой информации по схемам: к примеру, вынос информации пользователей, чьё имя начинается от A до D в одну схему, E-H – в другую и т.д. позволит легко переносить схемы между различными серверами БД, становится легче добавлять новые машины меньший объём информации = быстрые выборки!

42 Оптимизировать структуру БД

Оптимизировать структуру БД

Более эффективная структура БД позволит расширять поля для хранимой информации Оптимизация данных может помочь эффективному использованию индексов серьёзная переделка БД заставляет писать новую бизнес-логику доступа к ней хорошо, когда эта бизнес-логика отделена от программы, а если она находится в том самом коде талантливого индуса, куда лезть не следует?

43 Использование репликации БД

Использование репликации БД

Теперь выборки могут производиться сразу на нескольких серверах! Особенно эффективна репликация по типу: пишем в мастер, читаем со слейвов. Для многих серверов есть готовые решения для балансировки нагрузки, зачастую даже интегрированные с кэшем выдачи в долгосрочной перспктиве могут начаться отказы и ошибки репликации при определённой скорости записи при падении сети происходит рассинхронизация БД особенно губительно для реплик мастер-мастер требует переделки логики доступа к БД нужно вводить балансер, который равномерно распределяет нагрузку между зеркалами

44 Кэшировать

Кэшировать

Память всё дешевеет, а производительности на кэш не нужно (можно использовать старые машины) очень правильно выделить отдельные машинки под сервера кэша – это может быть MemCached или JBoss Cache для этого очень помогает выделение объектов, которые не меняются во время жизни сессии пользователя. К примеру – те же сессии или user info в блоге или форуме когда кэш является посредником к БД – эффективно писать интерфейсы доступа к данным Нужно получить какой-то объект – дёргаем интерфейс. Он лезет в кэш, нет объекта в кэше – лезет в БД, кладёт в кэш и отдаёт реквестеру. Таким образом в кэше всегда есть актуальный объект.

45 Кэшировать

Кэшировать

Основной минус: кэш неэффективен, когда объекты запрашиваются редко либо объектов так много, что они просто вытесняются более новыми нужно считать, где кэш будет эффективен для этого пригодится аудит системы, знание внешнего и внутреннего путей пользователя переделка объектов для эффективного кэша затрагивает структуру БД и бизнес-логику приложений см. многострадальный код индуса)

46 Использование множества зеркал и балансировщика между ними

Использование множества зеркал и балансировщика между ними

Более гладко распределяется нагрузка Можно за балансировщиком поставить различные машинки для разных типов запросов к примеру ngnix как балансер, один сервер – для отдачи картинок и прочей статики и пару серверов с ПХП приложениями если за разными серверами, балансированными балансером скрывается общий бэкэнд или неразделяемый ресурс (к примеру, БД), то эффективность этого механизма резко падает

47 Очереди задач

Очереди задач

Те вещи, которые выполняются периодически (например, рассылка комментариев по почте) неплохо выносить в специальные обработчики с очередями задач к ним. можно использовать готовый механизм очередей задач (например, Apache ActiveMQ – он имеет механизмы интеграции с большинством современных языков программирования) можно написать свой (как обёртку над кроном или другим планировщиком)

48 Очереди задач

Очереди задач

главное достоинство – иметь возможность поместить какую-то задачу в очередь и как только для неё будут свободные ресурсы – она выполнится это серьёзно позволяет нормировать нагрузку на сервер синхронизацию каких-то частей тоже эффективно производить через очереди конвертация БД или перекладывание данных из одного формата в другой в обработку через очереди классно выносить те вещи, что не требуют немедленной реакции например, различные рассылки внутрисистемных уведомлений, внутренняя почта, рассылка уведомлений администратора, подсчёт пользователей на сайте, различная статистика

49 Очереди задач

Очереди задач

Полезное достоинство – связывание частей системы через общие серверы очередей класть в очередь могут одни части системы на одной машине, а выполнять – другие, на другой, что позволяет гибко нормировать нагрузку

50 Очереди задач

Очереди задач

Основной минус очередей – асинхронность выполнения, никто не гарантирует получения ответа в заданный промежуток времени

51 RPC (remote procedure calling)

RPC (remote procedure calling)

Использовать различные виды RPC, начиная с CORBA и RMI с JMX’ом, заканчивая Web Service и REST архитектурами.

52 RPC

RPC

Позволит вызывать процедуру на одной машине, а выполнять на другой, что сразу же делает архитектуру масштабируемой В случае применения кэширования и использования интерфейсов к доступу к различным структурам данных, легко позволит ввести кластеризацию Можно вынести и изолировать на машине ту самую пресловутую индусскую бизнес-логику

53 RPC

RPC

К сожалению, большие накладные расходы каждый запрос оборачивается каким-то специфичным контейнером, парсится как на стороне клиента запроса, так и на стороне сервера и т.д. – отсюда дополнительные издержки и время Сильно зависит от сетевой инфраструтуры проекта если что-то не так с роутингом, если есть потери пакетов, то время существенно увеличивается На программном уровне возникает целый ряд эксепшинов, связанных с обработкой отказов сети и потери целостности сетевого контейнера из-за чего приходится писать дополнительный код который в свою очередь требует тестирования, предусмотрения всех видов ситуаций и вообще, поправок к архитектуре выдачи запросов серьёзно усложняет отладку приложений – ошибки теперь призводится ловить не в одном месте

54 Использование аппликэйшн-серверов

Использование аппликэйшн-серверов

Не нужно думать о кластеризации самостоятельно, за тебя (по идее) сделает платформа Главный минус – в том, что кластеризация в аппликэйшн серверах производится за счёт того же RPC из-за чего наследуются все его проблемы, да ещё добавляются специфичные обёртки самого сервера Так же плохо, что сервера хорошо скрывают, как он производит распараллеливание запросов

55 Использование аппликэйшн-серверов

Использование аппликэйшн-серверов

Изучение логики платформы, особенностей администрирования и наличие подводных камней при разработке и эксплуатации требует подготовки кадров в случае ухода квалифицированного специалиста проблемы с поддержкой

56 Применяйте следующие подходы:

Применяйте следующие подходы:

Вынос, кластеризация и кэширование всех ранее неразделяемых ресурсов обращения к диску? – создание сервиса и RPC к нему обращение БД? Кластеризация, кэширование, общая точка входа через интерфейс. Всё через интерфейсы! оборачивайте старые блоки, которые не хочется менять интерфейсами в надежде, что когда-нибудь и до них руки дойдут к примеру, какая-то хитрая бизнес-логика? – оборачиваем, а потом, позже, - сервис и RPC к нему

57 Применяйте следующие подходы:

Применяйте следующие подходы:

В случае рефакторинга дизайна – глубокое последовательное и поэтапное разделение модели и представления зачастую в PHP проектах разделение идёт не совсем по паттерну MVC другой случай – модель для сборки страниц размазана по сессиям, кукам и запросам Задача рефакторинга дизайна: на первом этапе вынести всю бизнес-логику если не формирования модели, то, хотя бы, записи её в БД в интерфейсы На втором этапе - имплементить эти интерфейсы с помощью балансера доступа к БД или RPC Главное: на страницах не должно остаться никаких SQL запросов! На страницах должны дёргаться методы специальных классов, являющимися интерфейсами к бэкэнду системы.

58 Пишите техзадание

Пишите техзадание

Учитывая достоинства и недостатки различных подходов, а так же наличие критических мест устаканивайте архитектуру и так же слайдами рисуйте слайды фотографируются и оформляются в техническое задание, по которому уже можно начинать работу

59 Озвучте отличие между версиями системы

Озвучте отличие между версиями системы

нужно понять, являются ли изменения настолько большими, что потребуется этап перевода пользователей Такой этап может понадобиться в случае изменения формата БД Или изменения платформы, на которой написана система Нужно оценить объём изменяемой бизнес-логики. Оценивать нужно с точки зрения: количества изменяемых старых модулей (про которые известно, что они работают и работают давно) количества изменяемых новых модулей (ещё не до конца проверенных, оттого и ломать не жалко) какие модули новой системы можно внедрить без ломки старой схемы количество нового кода, который придётся написать, а потом - тестировать

60 Планируйте перенос

Планируйте перенос

При наличии существенных отличий новой системы от старой необходимо задуматься о разработке утилит переноса информации пользователей в новый формат!

61 Переделка

Переделка

Сама переделка начинается сразу же после проектирования, которое вместе с аудитом системы редко когда занимает более недели. Помощь эксперта во время переделки уже не требуется Рекомендую во время переделки назначить супервизора проекта, следящего за соответствием изменений в спроектированной архитектуре архитектор системы в процессе переделки не нужен, эта роль более подходит к ситуации создания системы более-менее с нуля, а вот человек, который отслеживает состояние работ, следит за документацией и в чьей отвествености будет формат интерфейсов между модулями системы, просто необходим Процесс переделки после стадии проектирования является типичной бизнес-задачей, вести её можно любыми методами, как XP, так и по RUP’у

62 Изменение требований в процессе разработки

Изменение требований в процессе разработки

Нужно выделять итерации разработки В процессе итерации требования фиксируются: они не могут изменяться Если необходимо кардинально изменить требования, то проще либо отменить итерацию, либо разбить её на несколько частей, для каждой из которой требования должны фиксироваться Если над душой стоит «некомпьютерный человек», то результатом каждой итерации должно быть что-то, что можно ему показать. И это должна быть не презентация

63 Тестирование в процессе разработки

Тестирование в процессе разработки

Вопреки каноническим правилам тестировать каждую итерацию не нужно итерации нужно группировать по общему признаку и выкатывать на тесты сериями отлично, если совершенно другая команда разработчиков пишет тесты, но, часто, - это недостижимый идеал поэтому очень хорошо взять вышеописанного супервайзера и заставить его написать по фиксированным требованиям каждой итерации тест-план после чего выпустить на модули альфа-тестеров. Выбор времени выкатки на альфа-тесты – та ещё задача: с одной стороны всё должно уже хотя бы иногда работать в ограниченной функциональности, с другой – всякие «рюшечки» ещё не должны быть написаны оптимально выкатывать код, когда делать больше нечего – т.е. во время простоев из-за синхронизации работы программистов использовать кросс-тестирование (тестирует не тот, кто писал этот модуль)

64 Тестирование

Тестирование

Все модули новой системы должны тестироваться! оптимально тестировать на реальных пользовательских данных сняв дамп текущих запросов пользователей, скажем, за день и прогнав их через тестируемый компонент моделирование поведения пользователя – отличный инструмент для создания автоматических тестов!

65 Выкатка

Выкатка

Новые модули системы, которые можно применить до окончания переделки нужно выкатывать как можно раньше чтобы отловить баги на реальных пользовательских данных Отличный вариант выкатки – зеркало с последующим переключением делается параллельный сервер импортируется БД со старого сервера на него отправляются копии запросов пользователей на боевую систему ловятся баги если всё в порядке, то происходит переключение вала запросов на новую систему, после чего старая умирает

66 Вопросы

Вопросы

Константин Андрюнин e-mail: ymi@ya.ru ICQ: #102100349 http://ymi.ya.ru

«Проблема взрывного роста аудитории: что делать, когда не хватает мощностей»
http://900igr.net/prezentacija/ekonomika/problema-vzryvnogo-rosta-auditorii-chto-delat-kogda-ne-khvataet-moschnostej-80112.html
cсылка на страницу
Урок

Экономика

125 тем
Слайды
900igr.net > Презентации по экономике > Экономический рост > Проблема взрывного роста аудитории: что делать, когда не хватает мощностей