Issuu on Google+

Cup Technical 2012 Обратная связь участникам 1 тура чемпионата

В данной презентации представлены образцы слайдов, присланные участниками Changellenge >> Cup Russia 2012

1


Содержание

Основное задание кейса

Содержание: полнота, наглядность и глубина решения Общие рекомендации Лучшие решения (Команда Leto)

Лучшие решения (Команда Rush Hour Team) Лучшие решения (Команда IQ)

2


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

Технические: * спроектировать оптимальную торговую площадку с минимальным уровнем задержек при прохождении торговой заявки (5 миллисекунд), • а также высоким уровнем надежности и отказоустойчивости (длительность простоя менее часа в год),

И Бизнес-задачи: • обеспечив при этом требования всех участников рынка. • придумать название площадки и идеи по поводу маркетинговых материалов, в частности связанных с преимуществами платформы для клиентов.

3


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

“Одна из лучших презентаций: кейс решен, самая лучшая продуманость архитектуры, в решении применена методология OOAD, которая зачастую используется при проектировании подобных систем. По слайдам: 2 - схема потоков данных, подробное описание, мощность в флопсах вычислена; 3 Sequence diagram OOAD с бенчмарком - это круто!; 4 - В идеале привести еще и расчет надежности; 5 - Интеграция рассмотрена, не глубоко, но дополнительный анализ;”

“Анализ есть, но не выведен из приложений!”

“Хорошая презентация с небольшими недостатками: решение кейса частичное, но недостаточная глубина анализа, отсутствует маркетинг. Есть интересные решения. По слайдам: 2 - процесс описан в нотации BPMN, хорошо; 6 – скудно”

“Хорошая презентация с небольшими недостатками: решение кейса частичное, отсутствует маркетинговая составляющая, бенчмарк "added latency". 5 - хорошая визуализация сравнительного анализа!”

“Одна из лучших презентаций: кейс решен, учтены как технические так и бизнес требования. Недостаток - отсутствие описания бенчмарка прохождения заявки (он есть только в приложении, а необходимо информацию выводить на слайды). По слайдам: 2 - так должен выглядеть правильный анализ; 3 немногие из команд ответили на один из вопросов кейса по анализу архитектур, по архитектуре написаны выводы; 4 детальное описание работы (жаль нет расчета прямо здесь); 5 без нагрузки и прогноза никак нельзя, большой плюс;”

“С Azure идея отличная, но врядли реализуемая!”

“Хорошая презентация: кейс решен, из плюсов прорисована структура сети, описаны альтернативы, увы отсутсвует бенчмарк по прохождению заявки. По слайдам: 4 - "** Java как самая производительная среда исполнения приложений" - да ну, источник?; 5 - структура коммуникационных каналов; ”

“Хорошая презентация: кейс решен, из плюсов - рассмотрены альтернативы, из недостатков нет алгоритма прохождения заявки с бенчмарком.;”

“Нормальная ровная презентация, из недостатков дизайн презентации не предназначен для чтения. 4 - глубокий бенчмарк скорости; 8 - клевый маркетинговый слайд +++” “Нормальная презентация, из недостатков - отсутствие описания выбора альтернатив, ориентация на один тип анализа, из плюсов - возможно одно из оптимальных технических решений, но решение не до конца обосновано.” “Нормальная презентация. По слайдам: 1 - бизнес требования +; 2 - до выбора далеко, но есть анализ +/-; 3 - нет описания как выполняются операции; 7 - бенчмарк это хорошо +”

4


Средняя оценка по баллам судей Для прохода в полуфинал в этом году потребовалось получить чуть больше 1,5 баллов из 3, при этом больше всего у участников «страдала» глубина анализа 3,00

3,0

Средняя оценка для тех, кто прошѐл в полуфинал или получил High Quality Award

2,83

2,5 2,08

2,0

1,89 1,73

1,85

1,90

1,90 1,50

1,5

1,00

1,0 0,5 0,0 Общая оценка

Широта анализа

Глубина анализа

Анализ При выставлении общей оценки берется средняя арифметическая от широты и глубины анализа

Структура/логика

Дизайн

Идеи

Максимально Максимально Оценка для возможная полученная полуфинала оценка оценка

Оценка для HQA

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

5


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

1

2

3 3

 

1.

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

2.

При постановке задач – проверьте, все ли задачи, поставленные в кейсе Вы учли. В образце №2 команда не учла бизнес-часть задания кейса, что является существенным недочетом в решении

3.

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

6


Содержание

Основное задание кейса

Содержание: полнота, наглядность и глубина решения Общие рекомендации Лучшие решения (Команда Leto)

Лучшие решения (Команда Rush Hour Team) Лучшие решения (Команда IQ)

7


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

1

3

2

1. В решении необходимо рассмотреть проблему с нескольких сторон, предложить альтернативные варианты. Или, продемонстрировав анализ, доказать, что именно то решение, которое Вы предлагаете – оптимально. Просто констатация Вашего подхода не доказывает его оптимальность. 2. Очень важно не просто разработать оптимальный подход, но и представить его наиболее наглядным способом. На 2 слайде использован не удачный фон, но по структуре и содержанию информации он весьма неплох. 3. При планировании результата, необходимо не просто построить прогноз, но и подкрепить его расчетами. Оформление этого слайда оптимально.

8


Изложено последовательно и логично Хорошая презентация начинается с анализа ситуации, из которого вытекают предложения и методы реализации.

1

2

3

1.

Четкое обозначение проблемы

2.

Несмотря на то, что Архитектура на этом слайде представлена не очень наглядным способом, решение в целом (если смотреть на 1 – 3 слайды) представлено последовательно и логично, что дает ему хорошее преимущество.

3.

Это решение, несмотря на небольшие недочеты, выполнено логично и последовательно.

9


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

1

3

2

1.

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

2.

Очень важно поместить на слайд необходимое количество информации, при этом не сделав его сложно читаемым. Информацию с этого слайда воспринимать сложно.

3.

На одном слайде можно уместить необходимое и достаточное количество информации.

10


Содержание

Основное задание кейса

Содержание: полнота, наглядность и глубина решения Общие рекомендации Лучшие решения (Команда Leto)

Лучшие решения (Команда Rush Hour Team) Лучшие решения (Команда IQ)

11


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

1

3

2

1.

Текст должен легко восприниматься относительно фона.

2.

Не используйте более 3х цветов на одном слайде.

3.

Очень хороший, с точки зрения оформления, слайд.

12


И оптимально использованы На одном слайде можно отразить максимальное количество Важной информации; все виды анализы лучше убрать в приложение

1

3

2

1. Все виды анализа лучше убирать в приложения, а в основную презентацию включать только выводы. 2. Помните, что у Вас всего 7 слайдов на презентацию своего решения. Место на слайде стоит распределять более рационально 3. Идеальный вариант представления информации

13


Общие рекомендации И, наконец, хотели бы дать вам общие и суммирующие рекомендации

1.

Четко следуйте правилам кейс-чемпионата и заданию

2.

Смотрите на анализ как с точки зрения глубины, так и широты. И не забывайте про структуру решения! Каждый слайд должен вписываться в общую концепцию.

3.

Делайте свои решения как можно более наглядными. Разработанный Вами продукт очень сложно представить, если Вы описываете его только текстом.

4.

Оставляйте место на действительно важную информацию. Не пишите очевидные вещи или те, что были даны в кейсе.

5.

Всегда помните, что у Вас есть только 7 слайдов на презентацию своего решения. Старайтесь как можно более оптимально использовать это пространство.

14


Содержание

Основное задание кейса

Содержание: полнота, наглядность и глубина решения Общие рекомендации Лучшие решения (Команда Leto)

Лучшие решения (Команда Rush Hour Team) Лучшие решени�� (Команда IQ)

15


“Одна из лучших презентаций: кейс решен, самая лучшая продуманость архитектуры, в решении применена методология OOAD, которая зачастую используется при проектировании подобных систем. По слайдам: 2 - схема потоков данных, подробное описание, мощность в флопсах вычислена; 3 Sequence diagram OOAD с бенчмарком - это круто!; 4 - В идеале привести еще и расчет надежности; 5 Интеграция рассмотрена, не глубоко, но дополнительный анализ;”

16


17


18


19


20


21


22


23


Содержание

Основное задание кейса

Содержание: полнота, наглядность и глубина решения Общие рекомендации Лучшие решения (Команда Leto)

Лучшие решения (Команда Rush Hour Team) Лучшие решения (Команда IQ)

24


“Одна из лучших презентаций: кейс решен, учтены как технические так и бизнес требования. Недостаток - отсутствие описания бенчмарка прохождения заявки (он есть только в приложении, а необходимо информацию выводить на слайды). По слайдам: 2 так должен выглядеть правильный анализ; 3 немногие из команд ответили на один из вопросов кейса по анализу архитектур, по архитектуре написаны выводы; 4 - детальное описание работы (жаль нет расчета прямо здесь); 5 - без нагрузки и прогноза никак нельзя, большой плюс;”

Проектирование оптимальной торговой площадки для Deutsche bank

▪Фёдорова Анна ▪ Долгополов Александр

▪ Теплюк Антон

Rush Hour team Cup Technical 2012

▪ Чапчаев Александр

25


Проектирование торговой площадки Deutsche Bank

by Rush Hour

При построении высоконагруженных систем необходимо учитывать и архитектурные, и инфраструктурные требования Требования ▪ Задержка меньше 5 мс ▪ Время работы 99,99% ▪Масштабируемость в условиях ежегодно растущей нагрузки ▪Простота поддержки

Для принятия решения важно выбрать приоритетные требования к площадке.

Результат:

Подход

Архитектурный

Инфраструктурный

Платформа, которая позволит занять прочную позицию на рынке

Влияние на параметры платформы Архитектура

Инфраструктура

Производительность

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

Отказоустойчивость

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

Масштабируемость Обслуживание

● Архитектура на основе общей шины ● Уменьшено количество блоков без потери функциональности и надежности ● Схема прохождения запросов сильно упрощена ● Концепция учитывает прогнозируемый рост нагрузки ● Облегчено обслуживание платформы ● Сильно снижена нагрузка на основную базу данных

Подходы

Архитектура

Описание схемы

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

Нагрузка

Инфраструктура

Надежность

Приложения

26


Проектирование торговой площадки Deutsche Bank

by Rush Hour

В качестве базовой архитектуры будет использоваться общая шина Основные принципы построения схемы 1) Модуль проверки сделок(Order/Trade manager) является необходимым в системе* 2) На пути клиент<->биржа не должно быть медленных модулей (таких как модуль баз данных) 3) Чем меньше модулей, тем надежнее работает схема 4) Модули разделяются на критические и общие (без критических невозможна дальнейшая работа системы, без общих такая возможность есть). Пропорции между критическими и общими модулями должны быть максимально в пользу последних

Принципы построения схемы

В соответствии с приоритетными параметрами, наиболее подходящими являются:

Общая шина Общая база

VS Надежность Производительность Масштабируемость

Простота обслуживания и развертывания

Такой вариант построения архитектуры на базе шины является оптимальным.

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

Общая шина * - финансовое обоснование см. в приложении + excel Подходы

Архитектура

Описание схемы

Нагрузка

Инфраструктура

Надежность

Приложения

27


Проектирование торговой площадки Deutsche Bank

by Rush Hour

Механизм работы торговой платформы (1 на 20 клиентов)

FIX Gateway

Order/Trade Manager

FIX Gateway

EMS да

EMS

Заявки

нет

заявка корректна?

В любом случае

tmp

1 раз в день

Oracle

Заявку поступает по протоколу FIX на FIX Gateway. Этот модуль отвечает за шифрование, предварительные конфигурационные проверки заявки и добавляет необходимые атрибуты. Заявки, не прошедшие предварительную проверку, возвращаются клиенту.

Корректные заявки поступает через шину в модуль проверки сделок (Order/Trade Manager). На нем хранятся профили клиентов (баланс, история сделок за день), которые загружаются из базы в начале операционного дня. Заявка проходит валидацию (учитываются профильные данные клиентов и котировки, которые хранятся в оперативной памяти и в базе tmp) . Прошедшие валидацию заявки отправляются на биржу. Так же, информация о всех заявках записывается во временную базу (tmp). Из этой базы информация отправляется в основную (Oracle) (раз в день, в период наименьшей нагрузки на платформу 23:00). FIX Gateway

FIX Gateway

После выполнения сделок на бирже, отчеты идут по 2м направлениям. Один экземпляр отчета через шину направляется клиенту, а другой идет в Order/Trade Manager, где соответствующая заявка (ORDER) меняет тип на (TRADE) (в базе tmp). Прим. Для каждой биржи, в конце операционного дня, заявки с типом ORDER закрываются и получают статус EXPIRED

EMS

Отчеты о сделках

Изменение статуса заявки

tmp

Order/Trade Manager

FIX Gateway

1 раз в день

Oracle

FIX Gateway EMS

Котировки Order/Trade Manager Подходы

Архитектура

tmp

1 раз в день

Описание схемы

Oracle Нагрузка

В целях сокращения времени отклика, котировки проходят к клиенту по максимально короткому пути. Так же, для валидации сделок, на модуле Order/Trade Manager необходимо сохранять актуальные котировки. Прим. В начале операционного дня первым делом с каждой из фондовых бирж загружаются в O/T Manager обновленные котировки Инфраструктура

Надежность

Приложения

28


Проектирование торговой площадки Deutsche Bank

by Rush Hour

Долгосрочная перспектива: вычислительные мощности растут быстрее нагрузки на платформу Для расчета конфигурации торговой площадки, необходимо учитывать: Географическое расположение фондовых бирж

Увеличение интенсивности торгов в 3 раза, ближе к закрытию биржи

Увеличение числа заявок на 30% в год

London

New York

География крупнейших биржевых центров ~80% объема торгов приходится на 15 крупнейших фондовых бирж

Количество институциональных клиентов и объем информации по котировкам

Не изменяется

Объем базы данных в первый год

Количество заявок в год

+ 30%

315 Тб

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

Частота обновления котировок

Объем данных в год (Тб)

20/сек

Коэф. Роста объема СХД ~1,4

Отклик 1мс ВНУТРИ системы (см. приложение 4+ excel)

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

Нагрузка на сетевое оборудование по годам (Гбит/с)

Коэф. Роста пропускной способности коммутаторов ~1,41

Величина задержки в построенной схеме не превышает 1мс источники: WFE, анализ команды Rush Hour, Wikipedia Подходы

Архитектура

Описание схемы

* -имеется в виду прогресс технологий. Подробнее в приложении 1 и excel файле

Нагрузка

Инфраструктура

Надежность

Приложения

29


Проектирование торговой площадки Deutsche Bank

by Rush Hour

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

Модуль

FIX Gateway Шифрование Добавление атрибутов Преобразование протоколов

Шина

Связь между модулями Асинхронный обмен данными

EMS

O/T Manager Проверка сделок Хранение в оперативной памяти котировок и баланса клиентов

Ведение суточной базы данных

tmp

База данных Хранение информации о сделках

Oracle

Сеть Передача информации между модулями

Техническое решение*

Горизонтальная масштабируемость Простота обслуживания

Rack форм-фактор серверов (ProLiant DL360 G7 ) Характеристики памяти и процессоров не играют решающей роли (1 FIX Gateway на 20 клиентов) Производительности должно быть достаточно для шифрования Большое количество портов на коммутаторах

Производительность Вертикальная и горизонтальная масштабируемость

Шина не хранит никакой информации, дисковая система не нужна. Blade форм-фактор серверов (ProLiant BL680c G7). Максимальный объем оперативной памяти (512Гб/сервер) и самые производительные процессоры (E7-8870). TIBCO EMS в качестве сервиса организации очередей

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

Максимальный объем оперативной памяти (512Гб/сервер) и самые производительные процессоры (E7-8870). Дублирование всех компонентов модуля в целях безопасности Blade форм-фактор серверов (ProLiant BL680c G7) позволяющий осуществлять горячую замену компонентов. Объединение в кластеры

Производительность Надежность Вертикальная масштабируемость

SAN архитектура. Использование SSD накопителей Oracle в качестве базы данных (более производительное решение с лучшими возможностями вертикального масштабирования)

Горизонтальная масштабируемость Надежность Скорость передачи данных Горизонтальное масштабирование

SAN архитектура. Использование HDD накопителей, объединение их в raid массивы Oracle в качестве базы данных (лучшие возможности горизонтального масштабирования) Сетевая подсистема не является “бутылочным горлышком” платформы 8Gb/s FC в сетях хранения данных и 10Gb/s Ethernet во внутренней сети FCoE соединяет их между собой

* - подробная конфигурация оборудования по каждому модулю см. Приложение 5 Подходы

Архитектура

Описание схемы

Нагрузка

Инфраструктура

Надежность

Приложения

30


Проектирование торговой площадки Deutsche Bank

by Rush Hour

Надежность будет одним из основных конкурентных преимуществ созданной платформы Исходя из специфики клиентов (B2B) можно сделать вывод, что созданная платформа займет прочные позиции на рынке, без серьезных затрат на маркетинг*

На долю шины приходится большая часть рисков Финансовые риски (1 час простоя)

Меры по повышению надежности и безопасности

2-9 Тыс. $

0$

Общие Полное резервирование системы на удаленной площадке Резервирование питания (на случай отключения электроэнергии)

Инфраструктура

FIX Gateway

Дублирование интернет каналов (разные провайдеры) и сетевого оборудования Организация шифрования между клиентом и FIX Gateway

EMS

Oracle O/T Manager

Oracle

Oracle

Объединение серверов в кластеры Дублирование коммутаторов и остальных стандартных узлов Зеркалирование жестких дисков (raid) Регулярное создание копий базы на удаленном сервере

EMS O/T Manager

шина FIX Gateway

FIX Gateway – репутационные риски со стороны клиентов Oracle – риски со стороны регулирующих органов

* - см. приложение Подходы

шина

FIX Gateway

Репутационные риски

Объединение серверов в failover кластеры Дублирование всех промежуточных узлов Использование SSD накопителей как более надежных O/T Manager База tmp использует raid массивы EMS

38-185 Тыс. $

8-37 Тыс. $

Архитектура

Описание схемы

Нагрузка

Инфраструктура

Надежность

Приложения

31


Содержание

Основное задание кейса

Содержание: полнота, наглядность и глубина решения Общие рекомендации Лучшие решения (Команда Leto)

Лучшие решения (Команда Rush Hour Team) Лучшие решения (Команда IQ)

32


33


34


35


36


37


38


39


Спасибо за ваши решения! До новых побед!

40


CLT2012 Feedback on 1st round