суббота, 11 июня 2016 г.
vrf-table-label
per-prefix — одна метка — один клиентский префикс, то есть если у нас 100 клиентских vrf и у каждого клиента по 100 префиксов, то мы получим 100х100=10 000 меток, что очень расточительно по сегодняшним меркам. Данный метод распределения меток vrf по дефолту используется в маршрутизаторах Cisco.
per-next-hop — одна метка на все префиксы клиента, которые имеют один и тот же next-hop. Если клиентский маршрутизатор подключен к PE маршрутизатору одним линком, то все префиксы будут иметь один и тот же next-hop, а значит одну и ту же метку. Данный механизм распределения меток vrf по дефолту в JunOS.
per-vrf — одна метка на весь vrf. С точки зрения распределения меток этот режим очень экономичен: если у нас 100 клиентских vrf и у каждого клиента по 100 префиксов, то мы получим 100х1=100 меток. При таком распределении меток vrf маршрутизатор должен делать помимо mpls lookup еще и ip lookup.
Как было написано выше, по умолчанию JunOS использует распределение меток per-next-hop. Если вы хотите изменить это поведение, то вам придется дать команду vrf-table-label (для любителей замороченных конфигураций механизм распределения меток можно задать с помощью политики) либо использовать тоннельный PIC. Теперь разберем как все работает с данной командой и без нее. Будем использовать вот такую схему с Option C.
Без команды vrf-table label (и создания vt-интерфейса).
Конфигурация vrf на PE1 выглядит следующим образом:
bormoglotx@PE1> show configuration routing-instances CE1
instance-type vrf;
interface ge-0/0/3.10;
interface ge-0/0/3.20;
route-distinguisher 1:1;
vrf-target {
import target:2:100;
export target:2:100;
}
protocols {
ospf {
export ospf-export;
area 0.0.0.0 {
interface ge-0/0/3.10;
interface ge-0/0/3.20;
}
}
}
bormoglotx@PE1> show configuration interfaces ge-0/0/3
description "to SW1";
vlan-tagging;
unit 10 {
description "to CE1 site 1";
vlan-id 10;
family inet {
address 10.0.0.1/24;
}
}
unit 20 {
description "to CE1 site 2";
vlan-id 20;
family inet {
address 20.0.0.1/24;
}
}
Соответственно маршрутизатор начинает генерировать vpnv4 префиксы и передавать их на роутрефлекторы. В нашем случае роутрефлектор имеет адрес 10.0.10.10:
bormoglotx@PE1> show route advertising-protocol bgp 10.0.10.10
CE1.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.0.0.0/24 Self 100 I
* 10.1.1.1/32 Self 2 100 I
* 20.0.0.0/24 Self 100 I
* 20.1.1.1/32 Self 2 100 I
PE1 отдает на рефлектор четыре маршрута: две connected сети и два /32 (лупбеки CE маршрутизаторов), которые получает по ospf. Посмотрим, какие метки были сгенерированны для данных префиксов:
bormoglotx@PE1> show route advertising-protocol bgp 10.0.10.10 detail
CE1.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
* 10.0.0.0/24 (1 entry, 1 announced)
BGP group RR type Internal
Route Distinguisher: 1:1
VPN Label: 299888
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [1] I
Communities: target:2:100
* 10.1.1.1/32 (1 entry, 1 announced)
BGP group RR type Internal
Route Distinguisher: 1:1
VPN Label: 299888
Nexthop: Self
Flags: Nexthop Change
MED: 2
Localpref: 100
AS path: [1] I
Communities: target:2:100 rte-type:0.0.0.0:1:0
* 20.0.0.0/24 (1 entry, 1 announced)
BGP group RR type Internal
Route Distinguisher: 1:1
VPN Label: 299904
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [1] I
Communities: target:2:100
* 20.1.1.1/32 (1 entry, 1 announced)
BGP group RR type Internal
Route Distinguisher: 1:1
VPN Label: 299904
Nexthop: Self
Flags: Nexthop Change
MED: 2
Localpref: 100
AS path: [1] I
Communities: target:2:100 rte-type:0.0.0.0:1:0
Для наглядности выделим из выводов только значения меток:
bormoglotx@PE1> show route advertising-protocol bgp 10.0.10.10 detail | match label
VPN Label: 299888
VPN Label: 299888
VPN Label: 299904
VPN Label: 299904
Видно, что для префиксов из диапазона 10.0.0.0/8 сгенерирована метка 299888, а для префиксов из диапазона 20.0.0.0/8 метка 299904. Но есть один не очень приятный нюанс — в данном случае JunOS не производит ip lookup. Чем это грозит? Вы не сможете использовать фильтры, так как ip заголовок не анализируется.
Проверим это на практике.
Согласно представленному ниже выводу, PE1, получив пакет с меткой 299904 просто отправляет его в интерфейс ge-0/0/3.20:
bormoglotx@PE1> show route table mpls.0 label 299904
mpls.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
299904 *[VPN/170] 00:46:19
> to 20.0.0.2 via ge-0/0/3.20, Pop
а для пакетов с меткой 299888 — в интерфейс ge-0/0/3.10:
bormoglotx@PE1> show route table mpls.0 label 299888
mpls.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
299888 *[VPN/170] 00:46:25
> to 10.0.0.2 via ge-0/0/3.10, Pop
Как видите, маршрутизатор будет снимать метку и отправлять пакет в интерфейс в зависимости от входящей метки, не делая ip lookup-а, в чем мы сейчас и убедимся.
Проверим наличие vpnv4 маршрутов на PE2:
PE2#sh ip bgp vpnv4 rd 1:1 labels
Network Next Hop In label/Out label
Route Distinguisher: 1:1
10.0.0.0/24 10.0.10.1 nolabel/299888
10.1.1.1/32 10.0.10.1 nolabel/299888
20.0.0.0/24 10.0.10.1 nolabel/299904
20.1.1.1/32 10.0.10.1 nolabel/299904
Теперь посмотрим таблицу маршрутизации на CE2:
CE2#sh ip rou | b Ga
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
O E2 10.0.0.0/24 [110/10] via 10.0.1.1, 00:22:32, GigabitEthernet1/0.10
C 10.0.1.0/24 is directly connected, GigabitEthernet1/0.10
L 10.0.1.2/32 is directly connected, GigabitEthernet1/0.10
O E2 10.1.1.1/32 [110/10] via 10.0.1.1, 00:22:32, GigabitEthernet1/0.10
C 10.1.1.2/32 is directly connected, Loopback0
20.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
O E2 20.0.0.0/24 [110/10] via 10.0.1.1, 00:22:32, GigabitEthernet1/0.10
O E2 20.1.1.1/32 [110/10] via 10.0.1.1, 00:22:32, GigabitEthernet1/0.10
Все отлично — маршруты есть. Теперь можем запустить трассировку до 20.0.0.2 — адрес CE1-2:
CE2#traceroute 20.0.0.2
Type escape sequence to abort.
Tracing the route to 20.0.0.2
1 10.0.1.1 36 msec 32 msec 8 msec
2 10.1.3.2 [MPLS: Labels 20/18/299904 Exp 0] 56 msec 64 msec 60 msec
3 10.1.2.1 [MPLS: Labels 18/299904 Exp 0] 72 msec 108 msec 40 msec
4 10.2.0.1 [MPLS: Labels 299952/299904 Exp 0] 60 msec 88 msec 60 msec
5 10.0.3.2 [MPLS: Labels 299808/299904 Exp 0] 76 msec 68 msec 64 msec
6 10.0.2.1 [MPLS: Label 299904 Exp 0] 60 msec 52 msec 64 msec
7 20.0.0.2 60 msec 60 msec 56 msec
Все предсказуемо — стандартная трассировка через Option C.
А теперь запустим трассировку до 20.0.0.1 — это адрес интерфейса PE1 в сторону клиента (в самом начале статьи показана настройка интерфейса):
CE2#traceroute 20.0.0.1
Type escape sequence to abort.
Tracing the route to 20.0.0.1
1 10.0.1.1 40 msec 4 msec 16 msec
2 10.1.3.2 [MPLS: Labels 20/18/299904 Exp 0] 80 msec 64 msec 60 msec
3 10.1.2.1 [MPLS: Labels 18/299904 Exp 0] 56 msec 60 msec 72 msec
4 10.2.0.1 [MPLS: Labels 299952/299904 Exp 0] 48 msec 76 msec 112 msec
5 10.0.3.2 [MPLS: Labels 299808/299904 Exp 0] 68 msec 96 msec 64 msec
6 10.0.2.1 [MPLS: Label 299904 Exp 0] 80 msec 68 msec 4 msec
7 20.0.0.2 92 msec 72 msec 64 msec
8 20.0.0.1 96 msec 48 msec 88 msec
Сравнивая вывод с предыдущим, мы видим что до 20.0.0.1 на один хоп больше. Как так, ведь 20.0.0.1 — шлюз для сети 20.0.0.0/24? Если смотреть внимательнее, то мы видим, что пакет с PE-маршрутизатора (10.0.2.1 — core facing interface) был отправлен на CE маршрутизатор (адрес 20.0.0.2) и вернулся обратно на PE-маршрутизатор (20.0.0.1). Как я и сказал, JunOS не сделал ip lookup и просто переслал пакет в интерфейс клиента, а вот уже клиентский маршрутизатор проверил адрес назначения ip пакета и отправил его обратно на PE1 (см рисунок ниже):
То есть в нашем случае маршрутизатор принял пакет с меткой из ядра сети, посмотрел в таблице mpls.0 что необходимо сделать с пакетом, снял метку и отправил в интерфейс в сторону клиента.
Если мы повесим какой-либо фильтр на нашем PE маршрутизаторе на клиентский интерфейс или настроим qos, то ввиду вышесказанного трафик не будет обрабатываться согласно установленным фильтрам.
Повесим на интерфейс в сторону клиента фильтр:
bormoglotx@PE1# show firewall family inet filter To-CE1-2
term 1 {
from {
destination-address {
20.0.0.0/24;
}
}
then {
reject;
}
}
term 2 {
then accept;
}
[edit]
bormoglotx@PE1# show interfaces ge-0/0/3.20
description "to CE1 site 2";
vlan-id 20;
family inet {
filter {
output To-CE1-2;
}
address 20.0.0.1/24;
}
И теперь запустим пинг до сети 20.0.0.0/24 с CE2:
CE2#ping 20.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/69/72 ms
Фильтр есть, но он не работает. Изменим эту ситуацию, включив опцию vrf-table label:
[edit]
bormoglotx@PE1# set routing-instances CE1 vrf-table-label
Попробуем снова запустить пинг до сети 20.0.0.0/24 с CE2:
CE2#ping 20.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.0.0.2, timeout is 2 seconds:
UUUUU
Success rate is 0 percent (0/5)
Теперь хост недостижим — фильтр отрабатывает. Снимем фильтр и снова запустим пинг для проверки:
[edit]
bormoglotx@PE1# deactivate interfaces ge-0/0/3.20 family inet filter
[edit]
bormoglotx@PE1# show | compare
[edit interfaces ge-0/0/3 unit 20 family inet]
! inactive: filter { ... }
CE2#ping 20.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/88/148 ms
Все отлично. Теперь мы увидели наглядно, какие подводные камни нас ожидают при дефолтном механизме распределения меток vrf в JunOS. Так как выше мы уже дали команду vrf-table-label и деактивировали фильтр, то приступим к обсуждению работы маршрутизатора с включенной опцией vrf-table-label.
Посмотрим маршруты, которые PE1 анонсирует на роутрефлектор:
bormoglotx@PE1> show route advertising-protocol bgp 10.0.10.10
CE1.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.0.0.0/24 Self 100 I
* 10.1.1.1/32 Self 2 100 I
* 20.0.0.0/24 Self 100 I
* 20.1.1.1/32 Self 2 100 I
bormoglotx@PE1> show route advertising-protocol bgp 10.0.10.10 detail
CE1.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
* 10.0.0.0/24 (1 entry, 1 announced)
BGP group RR type Internal
Route Distinguisher: 1:1
VPN Label: 16
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [1] I
Communities: target:2:100
* 10.1.1.1/32 (1 entry, 1 announced)
BGP group RR type Internal
Route Distinguisher: 1:1
VPN Label: 16
Nexthop: Self
Flags: Nexthop Change
MED: 2
Localpref: 100
AS path: [1] I
Communities: target:2:100 rte-type:0.0.0.0:1:0
* 20.0.0.0/24 (1 entry, 1 announced)
BGP group RR type Internal
Route Distinguisher: 1:1
VPN Label: 16
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [1] I
Communities: target:2:100
* 20.1.1.1/32 (1 entry, 1 announced)
BGP group RR type Internal
Route Distinguisher: 1:1
VPN Label: 16
Nexthop: Self
Flags: Nexthop Change
MED: 2
Localpref: 100
AS path: [1] I
Communities: target:2:100 rte-type:0.0.0.0:1:0
Как видите, теперь у нас только одна метка на все маршруты из vrf CE1:
bormoglotx@PE1> show route advertising-protocol bgp 10.0.10.10 detail | match label
VPN Label: 16
VPN Label: 16
VPN Label: 16
VPN Label: 16
Снова запустим трассировку с CE2 до 20.0.0.1:
CE2#traceroute 20.0.0.1
Type escape sequence to abort.
Tracing the route to 20.0.0.1
1 10.0.1.1 32 msec 16 msec 20 msec
2 10.1.3.2 [MPLS: Labels 20/18/16 Exp 0] 76 msec 48 msec 68 msec
3 10.1.2.1 [MPLS: Labels 18/16 Exp 0] 68 msec 48 msec 56 msec
4 10.2.0.1 [MPLS: Labels 299952/16 Exp 0] 52 msec 48 msec 52 msec
5 10.0.3.2 [MPLS: Labels 299808/16 Exp 0] 52 msec 52 msec 52 msec
6 20.0.0.1 76 msec 52 msec 72 msec
Теперь icmp пакеты не идут петлей через CE1-2.
Сам маршрут на PE1 теперь выглядит несколько иначе:
bormoglotx@PE1> show route table mpls.0 label 16
mpls.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
16 *[VPN/0] 00:04:23
to table CE1.inet.0, Pop
Говоря обычным языком, при получении пакета с меткой 16 необходимо снять метку и сделать ip lookup в таблице CE1.inet.0. Почему же в Juniper данная функция не реализована при генерации меток per-nex-hop? Дело в архитектуре оборудования Juniper — PFE не может сделать и mpls и ip lookup одновременно. Для реализации двойного lookup-а нам понадобится так называемый Tunnel Services PIC, далее туннельный PIC (интерфейс vt-fpc/pic/port.unit-number ). Вот так выглядит PIC в составе шасси M120:
Примечание: О создании vt-интерфейса и добавлении его в vrf можно почитать тут
Теперь алгоритм обработки пакета будет изменен: маршрутизатор принял пакет с меткой из ядра сети, посмотрел в таблице mpls.0 что необходимо сделать с пакетом, снял метку и отправил в интерфейс vt, далее пакет из vt интерфейса снова попадает на PFE, но уже без метки и PFE может сделать ip lookup (и далее отправить в сторону клиента).
Но необходимость в туннельном PIC накладывает определенные ограничения на использование данной функции. Поэтому, если у вас нет такого PIC, то вы можете дать команду vrf-table-label и JunOS автоматически создает виртуальный интерфейс lsi (label switching interface) (поддерживается платформами ACX, M, MX, T Series), который выполняет точно такую же функцию, что и vt-интерфейс:
bormoglotx@PE1> show interfaces terse | match lsi
lsi up up
lsi.0 up up inet
Данный интерфейс не доступен для конфигурирования. На каждый vrf создается отдельный lsi интерфейс, который ассоциируется с генерируемой для данного vrf меткой. К примеру, создадим еще один vrf и посмотрим, сколько lsi интерфейсов теперь:
bormoglotx@PE1> show configuration routing-instances ?
Possible completions:
<[Enter]> Execute this command
<instance_name> Routing instance name
CE1 Routing instance name
CE2 Routing instance name
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
| Pipe through a command
bormoglotx@PE1> show interfaces terse | match lsi
lsi up up
lsi.0 up up inet
lsi.1 up up inet
Посмотреть какой lsi unit соответствует какой-либо routing instance можно командой: show interfaces lsi routing-instance instance-name, к примеру в нашем случае:
bormoglotx@PE1> show interfaces lsi routing-instance CE1 | match logical
Logical interface lsi.0 (Index 71) (SNMP ifIndex 524)
bormoglotx@PE1> show interfaces lsi routing-instance CE2 | match logical
Logical interface lsi.1 (Index 81) (SNMP ifIndex 525)
Интерфейс lsi создается и для vpls routing-instance (команда no-tunnel-services), трафик в таком случае обрабатывается как описано выше, за исключением того, что vpls оперирует исключительно mac адресами, не зная ничего о клиентских ip адресах, но это уже совсем другая история.
Спасибо за внимание!
пятница, 10 июня 2016 г.
IT Music Fest: гитара вместо клавы и музыка вместо кода
Как и положено рок-концерту, IT Music Fest начался на 50 минут позже времени, указанного в пригласительных. Предполагалось, что музыканты раздадут их друзьям и коллегам, но многие пригласили близких и родственников. Событие важное: почти все группы в этот день впервые выступали на настоящем открытом фестивале, а не на корпоративе своей компании.
— А где здесь сесть, чтобы не громко было? — спросили у меня на входе пара в возрасте: родители кого-то из музыкантов.
— Боюсь, сегодня везде будет очень громко...
Так оно и вышло. Люди потянулись на танцпол ещё до того, как первая группа вышла на сцену.
Группа Позитива Lucy’s First Job начала играть меньше года назад. Сейчас в составе восемь человек. Коллектив так увлёкся творчеством, что уже после первого концерта в Позитиве они решили организовать фестиваль музыкантов из IT-компаний. Пока созывали участников и искали место, отыграли на шестом PHDays.
Паб загрохотал под каверы System of a Down, Three Days Grace, The Offspring, а группа поддержки не переводила дух даже во время мелодичных Jungle Drum и History Repeating. К выходу Godcats танцпол и воздух в тесном пабе были раскалены.
Фото: Настя Козлова, VK.com
Костяк Godcats («Божественные котики»? «Котики от бога»?) — это художники из Mail.ru GROUP. Они нашли друг друга в пределах одного отдела. Креативщики оказались ещё и талантливыми музыкантами. Группа начала репетировать прямо в офисе, репертуар составляли из каверов на любимые песни.
На сцене Godcats и правда как котики: стильные и эмоциональные. Толпа перед сценой бушевала под мелодии Dani California, Personal Jesus, Enjoy the Silence, I Think I’m Paranoid.
Следом вышли брутальные Out of Office: две бороды на четверых разработчиков.
Группа «Касперского» оказалась старше всех выступающих: на корпоративах играют с 2011 года и уже несколько раз выступали на внешних площадках: в клубе «Дождь-мажор» и дважды в «Гластонбери пабе» на фестивале музыкальных команд «Касперского» Rock Around The K.
В свой репертуар они включили русскоязычные песни: «Хучи-кучи мэн» «Чижа и Ко» и «17 лет» «Чайфа». Сыграли трогательные Every Breath You Take и Knocking On Heaven’s Door. Публика не хотела их отпускать и просила добавки: увы, время выступления каждой из команд было ограничено, иначе фест мог растянуться на всю ночь. А утром понедельник.
После них выступали ABBYY Band.
Они собрались в 2011 году. Впервые выступили на новогоднем корпоративе ABBYY, последующие концерты тоже совпадали с внутренними событиями: Новым годом, днём рождения компании, летним корпоративом, 23 февраля и 8 Марта. Ребята на репетициях решают, что играть и как это будет звучать: точь-в-точь как в оригинале или в новой аранжировке. О себе они говорят, что, пожалуй, чаще остальных играют The Cranberries и Red Hot Chili Peppers.
С дебютом в пабе они справились отлично: после лиричных Time Is Running Out и Karma Police дали жару на Californication и Rock’n’Roll Queen.
Рок-фест закончился электроникой: на каверы Kraftwerk и Тома Йорка тоже нашлись фанаты, которые сильно горевали, что сет 4beatten оказался таким коротким.
Как и обещали, было очень громко пять часов подряд, а публика требовала ещё и ещё. Хотя каждая команда пришла со своей группой поддержки, на танцполе смешались все и горячо приветствовали выступавших независимо от того, где кто работает. Несколько коллективов рассказали мне, что с момента основания группы некоторые музыканты сменили место работы, но друзей не оставили: продолжали ходить на репетиции, выступать, обсуждать и поддерживать новые идеи. Короче, ребят, музыка вне конкуренции. Впрочем, слово самим музыкантам – вот что они думают о фестивале:
Огромное спасибо организаторам за уютное место, суперское проведение, достаточное время для проверки и настройки всего нашего сложного звука, звукорежиссеру — за очень внимательную и тонкую работу до и во время выступления, а слушателям — за то что «жгли» и не жалели ни себя, ни нас!— Максим Гапонов , дуэт 4beatten (бывший сотрудник Positive Technologies, сейчас работает в компании Luxoft)
Спасибо организатором за Фест! Получилось отлично, гости в восторге, мы — тем более! И выступление Lucy's First Job было отличным — барабанщику отдельный респект!— Сергей Аксенов, ударник ABBYY BAND
Мы также попросили поделиться впечатлениями одну из посетительниц фестиваля, обозревателя TADviser Наталью Лаврентьеву:
«Фестиваль IT Music Fest, на моей памяти, первое мероприятие, собравшее «ИТ-музыкантов» из разных компаний в одном месте. По-моему, идея организации такой площадки просто отличная: для творческих сотрудников это возможность показать и проявить себя перед достаточно большой аудиторией, а для их коллег и остальных, причастных к ИТ-отрасли, – возможность побыть в кругу «своих» в неформальной обстановке, послушать музыку и поддержать музыкантов, пообщаться. По сути, это один большой общий музыкальный ИТ-корпоратив. Чувствовалось, что творческий опыт у выступавших коллективов разный, но, на мой взгляд, все группы выступили достойно. Конечно, в этот раз присутствовали далеко не все музыкальные коллективы из ИТ-компаний, но так как это был только «первый блин», и вышел он вовсе не «комом», следующий фестиваль имеет все шансы приобрести большой размах».
P. S.
Если вас смущает слово «первый» рядом с «IT Music Fest», то уточняем: конечно же, это не первое мероприятие, на котором играли представители сразу нескольких IT-компаний. Такое бывало и раньше: достаточно вспомнить Medium Well 2009 года. Однако до сих пор такие события были разовыми. Поэтому в нашем случае выражение «первый IT Music Fest» — это заявка на то, что будет и второй, и дальше. Так что если вы работаете в IT-индустрии и у вас есть своя группа – присоединяйтесь!
Автор: Анна Давыдова, Positive Technologies
Комментарии (0)
DevConf::Go — 17 июня в Сколково, экслюзивный мастер-класс по Go 18 июня в ТАСС
Первый доклад "Prometheus мониторинг от души" представляет Евгений Пак — разработчик с 10 летним опытом работы, Senior Developer Go компании Lazada. Он расскажет об опыте переезда на Prometheus, и почему выбрали именно его, о процессе миграции и о том, как организована инфраструктура для сбора метрик Go приложений. Расскажет о тонкостях вычисления квантилей как на стороне клиента (тип метрик Summary), так и на стороне сервера (тип метрик Histogram). Также вы узнаете о тех нюансах, с которыми столкнулись при работе с Графаной, и как их решили.
О том, как приготовить Go микросервис к продакшену поведает Вадим Мадисон. Доклад о том, что считать готовым к продакшену микросервисом. Как должен быть реализован микросервис, какую функциональность он должен предоставлять, чтобы считать сервис надежным, прозрачным для поддержки и мониторинга. На примере Go-микросервиса будет дан перечень необходимого функционала и рассказаны основные подходы по разработке, деплою и поддержке микросервисов.
Как удается писать highload приложение на (не?)подходящем языке и про Golang в действии будет доклад от Даниила Подольского.
Алексей Соломонов расскажет про рассылку ~20K писем в минуту с помощью Go + SMTP + RabbitMQ = PostmanQ.
Про аудиоотпечатки для индексации всей музыки ВКонтакте поведает Алексей Акулович — Backend разработчик ВКонтакте. Он расскажет о о технических аспектах реализации вводимой сейчас системы аудиоотпечатков.
Фанатам Go будет интересен эксклюзивный мастер класс от мастеров Go — Даниила Подольского и Александра Чистякова
Написание веб-приложения на языке Golang
Расскажем о том, как сделать веб-сервис на языке Golang:
- Покажем как работать с длинными соединениями/вебсокетами
- Как организовать сбор и вывод статистики работы приложения
- Как профилировать приложение
- Как организовать сборку и деплой
- Организуем нагрузочное тестирование и посмотрим, на что способно наше приложение.
Регистрация на мастеркласс 18июня
Для тех кому не хватает функционала Go — после обеда посетителей конференции ждет доклад "Язык программирования Rust" от Шрамко Антона
После этого — тандем от хакеров Pentestit — атака vs защита
"Современные практики атаки веб-приложений" от Луки Сафонова, технического директора компании Pentestit.
"Защита веб-приложений от современных хакерских атак" от Романова Романа.
Партнерами в 2016 году стали: ТАСС, ВКонтакте, Badoo, Postgres Professional, Selectel, NetCat, ElbuzGroup, ItSoft, Reg.RU, CentosAdmin.ru, Joomla.ru, CMSMagazine,E-Lama.ru, IT-Summa, Ti-me.ru, 4Gophers.ru, TVM.ru, Sesmik CMS, Torarchuk.ru
Более 90 докладов — 9 потоков: http://ift.tt/1GIfWiq
Регистрация на конференции: http://ift.tt/26gAvMU
Комментарии (0)
[Из песочницы] Где взять логины или VoIP в помощь
Проводя аудит методом black-box, мы не знаем об инфраструктуре абсолютно ничего. Так и в этот раз: был предоставлен доступ только к внутреннему сегменту сети компании без какой-либо дополнительной информации. Просканировав сеть было обнаружено много доступных хостов, где требовалось ввести учетные данные для входа. Но их же у нас нет — это логично на начальном этапе. Где же брать логины для дальнейшего подбора паролей? Способов несколько, каждый выбирает по вкусу. Например, можно воспользоваться уже готовыми словарями или поискать информацию в общедоступных источниках — на сайте компании, вероятнее всего, размещаются некоторые почтовые адреса сотрудников. На их основе можно составить словарь логинов. Или, все же, заглянуть в корпоративный каталог телефонов?
На ресепшен у секретаря в свободном доступе стоял телефонный аппарат всеми известной компании «Cisco». Бегло полистав меню аппарата был обнаружен доступный корпоративный каталог телефонов. Оставив пустыми поля «Имя», «Фамилия» и «Номер» я выполнил поиск по каталогу и телефон послушно выдал информацию об абонентах. Доставать информацию с телефона, стоя на ресепшен — некомильфо, поэтому в меню был найден URL CUCM-сервера, откуда подтягивается каталог телефонов.
Вернувшись за ноутбук, я перешел по полученному URL
https://XXXXXXXXXXXXX:8443/ccmcip/xmldirectorylist.jspи получил XML-документ с именами абонентов и их внутренними номерами телефонов.
В качестве доступных параметров были «l» (lastname), «f» (firstname) и «n» (number). Параметр «start» позволяет переходить по каталогу. Всего за 1 запрос можно получить 30 значений.
Необходимая информация находилась в «Prompt», «Name» и «Telephone». Количество записей (отображаемых и всего):
Фамилия, имя и номер абонента:
Осталось дело за малым – вытащить все это из из каталога. Для этого был подготовлен небольшой скрипт на Python, который парсит XML-документ по заданным параметрам.
В результате работы скрипта я получил фамилии и имена пользователей, что позволило мне создать точный словарь логинов. Номера телефонов можно задействовать при генерации паролей.
Вишенка на торте: помимо фамилий и имен пользователей я также получил имена служебных учетных записей, которые каким-то образом оказались на другом (втором) CUCM-сервере, а это уже гораздо интереснее.
В качестве резюме
Общедоступный корпоративный телефонный каталог предоставляет злоумышленнику неплохой набор входных данных, с помощью которых он может скомпрометировать целевую систему.
Комментарии (0)
[Из песочницы] Балансировка трафика между несколькими [vpn-]интерфейсами в одной подсети
На момент написания статьи это balancing_v0.5.2-alpha.
Изначально задача формулировалась примерно так:
Есть пучёк armhf девайсов c Ubuntu Trusty на борту.
У них есть несколько подключений к интернету. Обычно это основное проводное подключение (eth0) и несколько HiLink usb-модемов Huawei E303 (eth1-eth5). Через каждое из этих подключений нужно поднять openvpn-клиентов к единственному серверу и через них уже балансировать трафик.
Всё бы ничего, но у этих модемов нет возможности изменения подсети и шлюза (гвоздями прибиты 192.168.1.1/24), причём прошивок с реализацией этой возможности тоже не нашлось (в отличии, например от E3272 для которого есть прошивки с таким функционалом). Кроме того даже если бы и нашлись, то vpn-подключения всё равно были бы в одной подсети и с одинаковым шлюзом. Т.е. без продвинутой маршрутизации (policy routing) не обойтись.
Ах, да, ещё надо мониторить каждое подключение и отключать/включать, если порвалось/возобновилось. Т.е. маршрутизацией нужно управлять динамически.
Готовых решений под «обычный» Linux не нашёл. Киньте в меня ссылкой если они есть. Обычно публикуют свои собственные велосипеды на базе ip route, вот и я туда же.
Есть парочка OpenWrt-специфичных:
Основной трафик будет адресован сервису на openvpn-сервере, и для него достаточно будет балансировать соединения. Имейте ввиду, что такой способ балансировки не очень хорошо подходит для веб-сёрфинга, т.к. некоторые соединения внутри https-сессии могут быть направлены в разные интерфейсы. Тут нужно балансировать сессии (несколько соединений кряду, flow-based), поправьте меня, если не прав. В планах реализовать этот способ, вкупе с per-packet- и hash-based.
Фичи этой реализации
- Может использоваться для балансировки трафика на интерфейсах в одной подсети с одинаковым IP шлюза. Это полезно не только для usb-модемов, но и для других подключений, доступа к перенастройке которых у тебя нет, или перенастройка не желательна;
- Поддержка балансировки поверх vpn;
- Мониторинг состояния подключения. Есть два типа:
- multi: connection-based балансировка;
- solo: redundancy mode, балансировка не используется, а используется только живой интерфейс с максимальным приоритетом.
Кроме этого, есть готовые инструкции как получить доступ в веб интерфейсу каждого из модемов (у них же у всех одинаковые IP): можно привязать браузер к конкретному интерфейсу.
Как это работает?
При поднятии или опускании интерфейса, который участвует в балансировке, автоматически должен рестартовать скрипт balancing (с помощью balancing_restart). Это обеспечивается соответствующей настройкой интерфейсов.
Скрипт инициализирует все упомянутые в настройках интерфейсы (и в то же время доступные) для балансировки: добавляет соответствующие правила маршрутизации (ip rule), маршруты (ip route), настраивает firewall (iptables).
В зависимости от настроек режима (solo или multi, которые, кстати, можно менять на лету записав соответствующее слово в balancing_mode), будет либо производиться балансировка между интерфейсами с указанным весом (multi), либо использоваться живой интерфейс с максимальным приоритетом (solo).
Через определённый период времени скрипт проверяет все интерфейсы на живость (а также сменился ли режим), и включает/отключает их соответственно посредством редактирования таблиц маршрутизации.
Примерные требования
- Ubuntu Trusty 14.04 LTS (другие linux также могут быть использованы, но все настройки и тесты проводились именно в этой ОС)
- Ядро Linux с поддержкой CONFIG_IP_ROUTE_MULTIPATH, CONFIG_IP_MULTIPLE_TABLES, CONFIG_IP_ADVANCED_ROUTER:
for conf in /proc/config.gz /boot/config-$(uname -r) /boot/config; do zgrep -e CONFIG_IP_ROUTE_MULTIPATH -e CONFIG_IP_MULTIPLE_TABLES -e CONFIG_IP_ADVANCED_ROUTER $conf 2>/dev/null; done - Пакеты:
apt-get install iproute2 iptables coreutils iputils-ping grep sed
Настройка
- Скопировать файлы в /etc/network:
mkdir temp && cd temp git clone http://ift.tt/1sybZaA cd balancing chmod +x balancing/balancing{_restart,} add_rt_table get_ovpn_by_base_ip bandwidth-measure cp balancing/balancing* get_ovpn_by_base_ip add_rt_table bandwidth-measure /etc/network/ cd ../../ && rm -rf temp - Отключить или снести к чертям свинячим NetworkManager, если наличествует, а то всё испортит:
apt-get install usb-modeswitch # Нужно для большинства usb-модемов apt-get purge network-manager network-manager-gnome apt-get autoremove # Аккуратно с этим, проверь точно ли всё это тебе не нужно. - Настроить параметры ядра в /etc/sysctl.conf:
- Если какие-либо интерфейсы находятся в одной подсети:
# ARP kernel settings for multiple interfaces in the same subnet net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.all.arp_filter = 1 net.ipv4.conf.all.arp_announce = 1 # Enable Loose Reverse Path net.ipv4.conf.all.rp_filter = 2 - Убрать routing cache для ядер <3.6 (в ядрах >=3.6 routing cache для ipv4 уже не используется):
# Remove routing cache if exists net.ipv4.route.max_size = 0 - Применить изменения:
sysctl -p
- Если какие-либо интерфейсы находятся в одной подсети:
- Настроить интерфейсы:
- Если настройка происходит локально, рекомендую положить все интерфейсы во избежание проблем с поднятием:
service networking stop
ну илиifdown eth1 eth2 ... ethN - Адаптировать примеры из interfaces.d/* под себя.
пример для eth0
auto eth0 allow-hotplug eth0 iface eth0 inet static address 192.168.1.10 network 255.255.255.0 dns-nameservers 8.8.8.8 208.67.222.222 pre-up /etc/network/add_rt_table eth0 # Gateway setup up ip route add default via 192.168.1.1 dev eth0 src 192.168.1.10 proto static table eth0 up ip route add default via 192.168.1.1 dev eth0 src 192.168.1.10 proto static table default metric 2000 # IP rules setup for separate routing table up ip rule add priority 10 from 192.168.1.10 lookup eth0 up ip rule add priority 110 from all oif eth0 lookup eth0 down while ip rule delete lookup eth0; do :; done || exit 0 # Start/stop OpenVPN up service openvpn start $(/etc/network/get_ovpn_by_base_ip 192.168.1.10) || exit 0 down service openvpn stop $(/etc/network/get_ovpn_by_base_ip 192.168.1.10) || exit 0 # Restart balancing up /etc/network/balancing_restart down /etc/network/balancing_restart # If it's WiFi interface #wpa-driver nl80211 #wpa-key-mgmt WPA-PSK #wpa-proto WPA2 #wpa-ssid SSID #wpa-psk PASSWORD
- Если настройка происходит локально, рекомендую положить все интерфейсы во избежание проблем с поднятием:
- Настроить OpenVPN клиентов, если используются:
- Установить OpenVPN:
## Repo for amd64 and i386 arch # wget -O - http://ift.tt/1pc6arH add - # echo "deb http://ift.tt/256e7VW trusty main" > /etc/apt/sources.list.d/swupdate.openvpn.net.list apt-get update apt-get install openvpn - Настроить OS:
adduser --system --no-create-home --home /nonexistent --disabled-login --group openvpn mkdir /var/log/openvpn chown openvpn:openvpn /var/log/openvpn - Отключить автозапуск всех клиентов при старте. В /etc/default/openvpn раскомментировать строку:
AUTOSTART="none" - Примеры конфигурации клиентов есть в openvpn/*:
пример клиентского конфига tun0 поверх eth0# OpenVPN-client config example for balancing
client
remote openvpn.example.com 1194
local 192.168.1.10 # bind to eth0
;nobind
dev tun0
proto udp
resolv-retry infinite
remote-cert-tls server
comp-lzo
log-append /var/log/openvpn/ovpn-client-example.log
verb 3
;daemon# Commented because balancing_restart require root permissions
;user openvpn
;group openvpn
;persist-key
;persist-tunup "/etc/network/balancing_restart tun0 start"
down "/etc/network/balancing_restart tun0 stop";ca /etc/openvpn/ca.crt
CA CERT HERE;cert /etc/openvpn/ovpn-client-example.crt
CERT HERE;key /etc/openvpn/ovpn-client-example.key
PRIVATE KEY HERE;tls-auth /etc/openvpn/ta.key 1
key-direction 1
<tls-auth>
STATIC TLS KEY HERE
</tls-auth>
- Установить OpenVPN:
- Отредактировать переменные под себя в balancing_vars (см. комментарии к файлу)
- Поднять интерфейсы для балансировки (/etc/network/balancing_restart должен запускаться при поднятии/опускании интерфейса):
- Проверить /var/log/balancing.log на наличие ошибок:
tail -f -n30 /var/log/balancing.log - Техническую информацию о текущем состоянии балансировки можно посмотреть с помощью такого вот однострочника:
echo ======Current state======; echo ===Addresses===; ip a; echo; echo ===Rules===; ip rule; echo; echo ===Routing tables===; for TBL in $(ip rule | rev | cut -d' ' -f2 | rev | sort -u); do echo ==$TBL==; ip r l t $TBL; echo; done; echo; echo ===IPTABLES===; for table in raw mangle nat filter; do echo ==$table==; iptables -vnL -t $table; echo; done; echo; echo ===MODE===; cat /etc/network/balancing_mode;
пример состояния для пары интерфейсов======Current state====== ===Addresses=== 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 1a:2b:3c:4d:5e:6c brd ff:ff:ff:ff:ff:ff inet 192.168.1.10/24 brd 192.168.1.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::182b:3aff:fe4b:5e54/64 scope link valid_lft forever preferred_lft forever 7: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 12:34:56:78:90:12 brd ff:ff:ff:ff:ff:ff inet 192.168.1.11/24 brd 192.168.1.255 scope global eth1 valid_lft forever preferred_lft forever inet 192.168.1.12/24 brd 192.168.1.255 scope global secondary eth1 valid_lft forever preferred_lft forever inet6 fe80::5a2c:80fb:fe13:9263/64 scope link valid_lft forever preferred_lft forever 8: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100 link/none inet 172.22.0.3/16 brd 172.22.255.255 scope global tun1 valid_lft forever preferred_lft forever 9: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100 link/none inet 172.22.0.2/16 brd 172.22.255.255 scope global tun0 valid_lft forever preferred_lft forever ===Rules=== 0: from all lookup local 10: from 192.168.1.10 lookup eth0 11: from 192.168.1.11 lookup eth1 110: from all oif eth0 lookup eth0 111: from all oif eth1 lookup eth1 1000: from all fwmark 0x6a lookup tun0 1001: from 172.22.0.2 lookup tun0 1002: from all oif tun0 lookup tun0 1003: from all fwmark 0x6b lookup tun1 1004: from 172.22.0.3 lookup tun1 1005: from all oif tun1 lookup tun1 20000: from all lookup main 30000: from all lookup balancing 32767: from all lookup default ===Routing tables=== ==balancing== default proto static metric 1 nexthop via 172.22.0.1 dev tun0 weight 18 nexthop via 172.22.0.1 dev tun1 weight 1 default via 172.22.0.1 dev tun0 proto static src 172.22.0.2 metric 2 default via 172.22.0.1 dev tun1 proto static src 172.22.0.3 metric 4 default via 172.22.0.1 dev tun0 proto static src 172.22.0.2 metric 1002 default via 172.22.0.1 dev tun1 proto static src 172.22.0.3 metric 1004 ==default== default via 192.168.1.1 dev eth0 src 192.168.1.10 metric 2000 default via 192.168.1.1 dev eth1 src 192.168.1.11 metric 2001 ==eth0== default via 192.168.1.1 dev eth0 src 192.168.1.10 ==eth1== default via 192.168.1.1 dev eth1 src 192.168.1.11 ==local== broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 broadcast 172.22.0.0 dev tun1 proto kernel scope link src 172.22.0.3 broadcast 172.22.0.0 dev tun0 proto kernel scope link src 172.22.0.2 local 172.22.0.2 dev tun0 proto kernel scope host src 172.22.0.2 local 172.22.0.3 dev tun1 proto kernel scope host src 172.22.0.3 broadcast 172.22.255.255 dev tun1 proto kernel scope link src 172.22.0.3 broadcast 172.22.255.255 dev tun0 proto kernel scope link src 172.22.0.2 broadcast 192.168.1.0 dev eth0 proto kernel scope link src 192.168.1.10 broadcast 192.168.1.0 dev eth1 proto kernel scope link src 192.168.1.11 local 192.168.1.10 dev eth0 proto kernel scope host src 192.168.1.10 local 192.168.1.11 dev eth1 proto kernel scope host src 192.168.1.11 broadcast 192.168.1.255 dev eth0 proto kernel scope link src 192.168.1.10 broadcast 192.168.1.255 dev eth1 proto kernel scope link src 192.168.1.11 ==main== 169.254.0.0/16 dev eth0 scope link metric 1000 172.22.0.0/16 dev tun1 proto kernel scope link src 172.22.0.3 172.22.0.0/16 dev tun0 proto kernel scope link src 172.22.0.2 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.11 ==tun0== default via 172.22.0.1 dev tun0 proto static src 172.22.0.2 metric 2 ==tun1== default via 172.22.0.1 dev tun1 proto static src 172.22.0.3 metric 4 ===IPTABLES=== ==mangle== Chain PREROUTING (policy ACCEPT 5473 packets, 631K bytes) pkts bytes target prot opt in out source destination 5473 631K CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 CONNMARK restore 19 1140 MARK all -- * * 0.0.0.0/0 0.0.0.0/0 ctorigdst 172.22.0.2 mark match 0x0 MARK set 0x6a 19 1140 MARK all -- * * 0.0.0.0/0 0.0.0.0/0 ctorigdst 172.22.0.3 mark match 0x0 MARK set 0x6b Chain INPUT (policy ACCEPT 4621 packets, 587K bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 3344 packets, 541K bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 3344 packets, 541K bytes) pkts bytes target prot opt in out source destination 590 92460 MARK all -- * tun0 0.0.0.0/0 0.0.0.0/0 mark match 0x0 MARK set 0x6a 590 92460 MARK all -- * tun1 0.0.0.0/0 0.0.0.0/0 mark match 0x0 MARK set 0x6b 3344 541K CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 CONNMARK save ===MODE=== multi
Известные «особенности»
- Если один из балансируемых интерфейсов лёг/исчез, а скрипт не перезапустился (с помощью balancing_restart), то скрипт падает;
- OpenVPN клиент должен быть запущен под root, чтобы позволять запускать balancing_restart от root;
- В момент перезапуска скрипта пакеты из установленных соединений могут пропасть, т.к. не будет существовать подходящих маршрутов в таблицах маршрутизации. Т.е. поднятие/опускание одного из балансируемых интерфейсов влияет на соединения в других, что не есть гуд. Возможно в дальнейшем это будет исправлено или хотя бы максимально минимизировано;
- При vpn-балансировке если на момент инициализации не удалось поднять vpn-интерфейс (кончился трафик, или не было сигнала, ...) на каком-то из базовых интерфейсов, он пропускается, и если в дальнейшем такая возможность появляется, vpn-интерфейс не будет поднят автоматически.
Планы на будущее
(если проект будет развиваться)- Позволить выбирать использовать ли для балансировки дефолтный маршрут или только определённую подсеть/IP (сейчас используется только маршрут по-умолчанию);
- Добавить маршруты scope link дабы была возможность общаться с хостами своей подсети минуя шлюз;
- Уточнить вычисления ширины канала (сейчас считается будто все проверки в скрипте мгновенные, а они секунды могут отъедать);
- Добавить типы балансировки: flow/session-based, hash-based (require kernels >=4.4 or patch), packet-based;
Комментарии/предложения/критика горячо приветствуются!
Комментарии (0)
[Из песочницы] DevOps — автоматизируй всё
Как такового, определения DevOps нет, и все понимают эту методологию по-разному. Декларируемая цель – убрать барьеры между DEVelopment и OPerations. Поэтому часто DevOps понимают как то, что operations, QA и development находятся в одной команде, сидят в одном помещении, проводят общие митинги, общаются. Само по себе сближение и неформальное общение членов команды всегда полезно и уже это может привести к улучшению результатов. Но есть и формальные практики, следование которым позволяет улучшить поставку релизов, а значит и удовлетворение бизнеса.
Здесь описаны следующие:
- Continuous Integration
- Automated Testing
- Infrastructure as Code
- Continuous Deployment
- Configuration Management
- Load Testing
- Application Performance Monitoring
Приведенные ниже практики взяты из серии роликов от Microsoft DevOps-Fundamentals. Очень интересные и полезные вебинары, правда, с акцентом на технологии Microsoft.
Структура статьи построена следующим образом: перечислены практики, дано их описание, приведено Бизнес-Значение практики (то, как внедрение этого подхода улучшит жизнь бизнеса) и Измеримость (как можно измерить улучшение). И Бизнес-значение, и Измеримость также взяты из презентаций «DevOps-Fundamentals».
Ну что же, приступим. Процесс разработки и поставки ПО состоит из следующих шагов:
Начинается все с планирования. Планирование релиза, разработки, тестирования, развертывания. Пропустим этот шаг, так как development и operations в этом шаге не задействованы. После того, как разработчик закончил реализацию некоторого участка кода, он сохраняет (check-in’ит) его в систему контроля версий. После этого вступает в дело первая практика:
Непрерывная интеграция (Continuous Integration)
Непрерывная интеграция (Continuous Integration) — это практика разработки программного обеспечения, которая заключается в слиянии рабочих копий в общую основную ветвь разработки несколько раз в день и выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. Wiki
Собственно, что такое Continuous Integration? Процесс происходит примерно так: разработчик, после того, как завершил свою задачу и отладился, сохраняет свои изменения в рабочюю копию (TFS, SVN, Git). Дальше в действие вступает некий робот (TFS, TeamCity, что-либо еще), отслеживающий изменение рабочей версии. Он видит, что рабочая копия изменилась и запускает сборку проекта. По результатам сборки, оповещается разработчик (и другие заинтересованные лица) о том, прошло все успешно или нет. Оповещение может быть через письмо, сообщение в трее, или отобразиться на web-странице. Таким образом, если сборка прошла с ошибкой, то разработчик сразу же узнает об этом.
Бизнес значение
- Ускорение поставки (Accelerate Delivery) – достигается тем, что мы сразу же узнаем об ошибке сборки и, соответственно, можем быстрее начать её исправлять.
- Повторяемость (Repeatability) — весь процесс повторяем, то есть если никаких изменений не произошло, то и сборка будет так же успешна (или не успешна). Нет такой проблемы как то, что у одного разработчика все собирается, а у другого – нет.
- Оптимизация ресурсов (Optimized Resources) — нет необходимости вручную запускать сборку, на компьютере человека или билд сервере, нет необходимости готовить сборку – выкачивать исходники из source control и т.п.
Измеримость
- Время развертывания (Deployment Lead Time) – время, необходимое на сборку проекта.
- MTTR (Mean Time To Repair — среднее время восстановления работоспособности). Можно измерить время, прошедшее от сообщения об ошибочной сборке, до исправления, убирающего ошибку.
- MTTD (Mean Time To Diagonise – среднее время диагностирования проблемы). измеряется время, которое прошло от внесения ошибки, до определения, что возникла проблема и в чем она заключается.
Автоматическое тестирование (Automated Testing)
Автоматизированное тестирование – это процесс верификации программного обеспечения, при котором основные функции и шаги теста, такие как запуск, инициализация, выполнение, анализ и выдача результата, выполняются автоматически при помощи инструментов для автоматизированного тестирования ©.
После того, как сборка собрана, её нужно проверить. Наиболее быстро это можно сделать с помощью автоматических тестов. Для этого используются различные инструменты: это могут быть Unit тесты, UX тесты, интеграционные тесты. Главное условие – они не должны требовать участия человека. С помощью авто-тестов мы сразу получаем информацию о том, есть ли ошибки в нашей сборке. И сразу же можем начать их исправлять, не дожидаясь результатов ручного тестирования.
Бизнес значение
- Ускорение поставки (Accelerate Delivery). Мы быстрее получаем информацию о том, валидна ли сборка и можно ли её выпускать.
- Повторяемость (Repeatability) – тест всегда запускается в одной и той же последовательности, по одному и тому же сценарию, поэтому и результат будет одинаков.
- Оптимизация ресурсов (Optimized Resources). Автоматические тесты дешевле ручного за счет того, что их выполнение гораздо дешевле, чем проверка с помощью ручного тестирования.
Измеримость
- Время развертывания (Deployment Lead Time) – время, необходимое на развертывание (сборку, проверку).
- MTTR – В данном случае, измеряется время от диагностирования ошибки до её исправления (успешного прохождения теста).
- MTTD – так как тесты автоматические, то можно измерить время от сборки проекта до получения отчета об ошибке по результатам тестирования.
Инфраструктура как код (Infrastructure as Code)
Инфраструктура как код — это процесс управления и подготовки вычислительной инфраструктуры (процессы, физические сервера, виртуальные сервера и т.п.) и их конфигурации через машиннообрабатываемые файлы определений, а не физическую конфигурацию оборудования или использование конфигурационных инструментов Wiki.
Подход к конфигурированию приложений должен быть таким же, как и к коду. То есть конфигурационные файлы, переменные окружения, что-то еще должны храниться в централизованном хранилище или системе контроля версий, возможно, в той же самой, что и хранится код. И при конфигурировании приложения браться они должны именно оттуда. Соответственно, в случае необходимости изменить конфигурацию на сервере, ответственный сотрудник не заходит на него и меняет, например, соединение к БД, а меняет нужную переменную в хранилище, и оттуда она уже автоматически появляется на сервере.
Для переменных, специфичных для различных сред (Dev, Stage, Production) используются синонимы, подменяемые при развертывании на реальные значения. Примером такой подмены может служить технология transform, используемая для изменения конфигурационных файлов .NET приложений.
Привычки (Habits)
- Production first mindset — в первую очередь — производство (производственное мышление). Производство является сердцем любой организации, поставщика программного обеспечения, и лучшие из них признают, что производство должно быть главным приоритетом каждого члена команды, каждой роли, а не только IT. Промежуточные артефакты, такие как документация и pre-Prod окружение недостаточно. Высоко мотивированные исполнители всегда отслеживают жизненный статус, устраняют жизненные проблемы и первопричины, а также активно выявляют проблемы в производительности и работе ПО.
- Инфраструктура как гибкий ресурс — Infrastructure as flexible resource.
Бизнес значение
- Оптимизация ресурсов (Optimized Resources) — оптимизация ресурсов за счет более быстрого развертывания: нет необходимости вручную править конфигурации, особенно если серверов много.
- Ускорение поставки (Accelerate Delivery). Компьютер быстрее изменит и настроит конфигурацию.
Измеримость
- Скорость развертывания (Deployment Rate). Измеряется время развертывания приложения.
- MTTR – (Mean Time To Repair). Время на восстановление.
Непрерывное развертывание (Continuous Deployment)
Непрерывная развертывание – объединение Continuous Integration (непрерывной интеграции) и Continuous Delivery (непрерывной поставки). Это следующий шаг после успешной сборки и успешного прохождения автоматических тестов (и, возможно, установки галочки «сборка готова к развертыванию» ответственным человеком). Если вы уверены в ваших тестах, их наборе и покрытии, при их успешном выполнении запускается автоматическая установка на соответствующую среду, тестовую или продуктовую. Разница между Continuous Integration, Delivery, Deployment хорошо описана тут: http://ift.tt/1j6YUKB
Бизнес значение
- Оптимизация ресурсов (Optimized Resources ). Участие человека сведено к минимуму.
- Ускорение поставки (Accelerate Delivery). Машина быстрее все установит, чем человек.
Измеримость
- Частота поставки (Deployment Frequency). Измеряется количество установок в единицу времени (день, неделя, месяц, год).
- MTTR
- Доступность (Availability).
Управление релизами (Release Management)
Управление релизом заключается в том, что мы определяем формальные критерии, готова ли сборка к установке на соответствующую среду. Примером критериев, по которым сборка готова, и, если они выполняются, автоматически запускается поставка (Continuous Deployment) могут быть:
- DEV среда – сборка прошла без ошибок.
- STAGE среда – сборка была установлена на DEV среде и unit тесты прошли успешно.
- PROD среда – сборка прошла тестирование на STAGE среде, есть не более 5% minor багов, major багов нет, QA Lead и Dev Lead поставили Confirm билду о готовности к PROD среде.
Полезная ссылка: Управление релизами в Visual Studio 2013.
Бизнес значение
- Оптимизация ресурсов (Optimized Resources). Ресурсы, требуемые для определения готовности сборки (и её установки) всегда известны и их можно оптимизировать.
- Ускорение поставки (Accelerate Delivery). Мы быстрее и штатно (по строго определенным правилам) можем определить, готова ли сборка к поставке.
Измеримость
- Частота поставки (Deployment Frequency).
- MTTR
- Доступность (Avaibility).
Управление конфигурациями (Configuration Management)
Управление конфигурациями (Configuration Management) — это детальная запись и обновление информации, описывающей ПО и оборудование предприятия. Такая информация обычно включает версии и апдейты, которые были применены к установленному ПО, а также местоположение и сетевые адреса оборудования. ©
Здесь к формальному определению добавить особо и нечего. Все должно быть записано и подсчитано.
Бизнес значение
- Faster Detection & Remediation – более быстрое определение проблемы и восстановление.
- Оптимизация ресурсов (Optimized Resources).
- Большая гибкость.
Измеримость
- MTTD
- MTTR
- Доступность
Нагрузочное тестирование (Load Testing)
Нагрузочное тестирование (load testing) — подвид тестирования производительности, сбор показателей и определение производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству) Wiki
Часто происходит так, что, например, для web приложений, когда пользователь один (разработчик или тестировщик) страница быстро открывается у и хорошо реагирует на работу с ней. Но как только изменения попадают на продуктовый сервер, и эту же страницу начинают смотреть сотни, тысячи человек одновременно, страница долго грузится и перестаёт реагировать.
Проводя нагрузочное тестирование мы и определяем наличие проблем на раннем этапе, еще до попадания проблемной сборки на продуктовый сервер. Нагрузочное тестирование реализуется генерацией большого потока запросов к серверу и анализа поведения сервера.
Бизнес значение
- Увеличение качества поставки (Improve deployment quality). Мы всегда можем быть уверены, что устанавливаемая сборка отвечает критериям производительности и не ухудшает их.
- Поиск «бутылочного горлышка» производительности (Find performance bottlenecks). Диагностирование, какое место является проблемным с точки зрения производительности и как её можно решить на ранней стадии, до жалоб клиентов.
- Cater for demand – удовлетворение заказчика от постоянного качества продукта.
- Поддержание качества приложения (Maintain application quality).
Измеримость
- Availability – доступность приложения.
- MTTD
- MTTR
Мониторинг быстродействия приложения Application Performance Monitoring
Мониторинг быстродействия приложения (application performance management) – это мониторинг и управление быстродействием и доступностью ПО. APM стремится выявлять и диагностировать проблемы быстродействия комплексно, для поддержания ожидаемого уровня обслуживания Wiki
Нагрузочное тестирование выявляет многие проблемы еще до того, как сборка попала на продуктовые сервера и с ней начали работать клиенты. Но, к сожалению, не всегда удается предугадать как действия пользователей, так и влияние разницы в ресурсах серверов на тестовой и продуктовой средах. Поэтому необходимо мониторить состояние и работу приложения на продуктовой среде. Этому и служит мониторинг быстродействия приложения.
Бизнес значение
- Faster Detection & Remediation- более быстрое определение проблемы и восстановление. Мы быстрее узнаем об узких местах, возникший в продуктовой системе.
- Optimized Resources – оптимизация ресурсов. Можем перераспределить вычислительные ресурсы со служб, где они мало задействованы, на загруженные службы.
- More Resilience – большая гибкость. То же самое, что и в предыдущем пункте: балансировка нагрузки.
Измеримость
- MTTD
- MTTR
- Availability
Надеюсь, данная статья дала вам представление, что такое DevOps и что нужно сделать для улучшения жизни developers, operations и business.
Комментарии (0)
[Перевод] Медленно, но верно: выбираем оптимальный вариант стратегии для торгового робота
Большинство трейдинговых систем создано по типу «срубить денег по-быстрому». Они обращаются к временным неэффективностям рынков, для того чтобы получить ежегодную прибыль в районе 100%. За такими системами нужен постоянный контроль. Их нужно адаптировать к условиям рынка. Но срок их жизни остается относительно небольшим. И, когда это время приходит, смерть системы сопряжена, как правило, с большими финансовыми потерями. Что если оставаться в выигрыше, но сделать работу с трейдинговой системой более комфортной и безопасной?
Предлагаем вам адаптированный перевод статьи в The Financial Hacker, в которой автор реабилитирует идею Марковица и его подход оптимизации среднего отклонения (Mean-Variance Optimization).
«Старый-добрый» подход к осуществлению инвестиций гласит: покупай активы с низкими рисками и жди. Каждый инвестиционный портфель имеет некий средний гарантированный доход и определенный уровень ценовых колебаний. Обычно мы стремимся минимизировать последний и увеличить первый показатель. Оптимальное распределение капиталов, как раз, и призвано решить эту проблему. Оно подразумевает неравноценное распределение вложенных средств по количеству N активов. Самый простой способ решить задачу увеличения средней доходности при минимизации рисков предложил 60 лет назад Гарри Марковиц. Это решение принесло ему Нобелевскую премию.
Устаревший Марковиц
К сожалению, о Марковице основательно забыли. Хотя проблема осталась: в любой трейдинговой системе приходится рассчитывать оптимальное распределение в ретроспективе. В реальном трейдинге оптимизированный таким способом портфель мистическим образом проваливается. Считается, что обычный доход на практике меньше 1/N капитальных вложений. Недавно появилась статья, автор котрой решил оспорить это утверждение. Вот, что говорится в первом параграфе этого исследования:
«Оптимизация среднего отклонения (MVO), введенная Марковицем в 1952 году, рассматривается сегодня как красивая, но бесполезная на практике теория. Ее называют нестабильной и ошибочной процедурой. Говорят, что, раз она основана на подсчете средних, волатильности и корреляциях прибыли активов, то малейшая ошибка на входе, делает применение этой оптимизации бессмысленным».
На самом деле, поставить верные данные на входе в систему – не такая уж большая проблема. Да и самих параметров расчета немного. Но почему-то такой оптимизированный портфель у критиков Марковица действительно не работает. Вероятно, они что-то делают не так. Например, используют слишком длинные периоды возврата к среднему для выборки. Или применяют алгоритм MVO неверно, смешивая короткие и длинные портфели. При корректном применении периодов моментума и исключительно длинных портфелях инвестиций, MVO выдает результат за пределами выборки намного превышающий показатель 1/N. Не верите? Смотрите пример тестирования данного алгоритма на R в блоге Ильи Киприса.
Реализация на R – редкая практика в реальном трейдинге. Следует опробовать MVO на другой платформе. Потом можно будет вложить деньги в оптимизированный портфель акций или одного из ETF, позволить платформе провести балансировку распределения средств на обычных интервалах, откатить, подождать и начать зарабатывать постепенно и вдумчиво.
Реализация MVO
Для реализации на Zorro автор берет раскладку Марковица из публикации 1959 года. В Главе 8 он описывает алгоритм MVO самым понятным и доступным способом. Для не самых продвинутых программистов здесь даже есть введение в линейную алгебру. Автор добавил к оригинальному алгоритму лишь ограничение по весу, как это предлагают сделать авторы вышеупомянутой статьи. В итоге оказалось, что это была отличная идея. Данное условие помогло стабилизировать алгоритм и улучшило его производительность за пределами выборки.
Предвкушая появление быстрых и умных вычислительных машин, Марковиц включил в описание набор примеров, по которым можно проверить, был ли алгоритм запрограммирован верно. Вот так выглядит эта проверка:
function main()
{
var Means[3] = { .062,.146,.128 };
var Covariances[3][3] = { .0146,.0187,.0145,.0187,.0854,.0104,.0145,.0104,.0289 };
var Weights[3];
var BestVariance = markowitz(Covariances,Means,3);
markowitzReturn(Weights,1);
printf("\nMax: %.2f %.2f %.2f",Weights[0],Weights[1],Weights[2]);
markowitzReturn(Weights,BestVariance);
printf("\nBest: %.2f %.2f %.2f",Weights[0],Weights[1],Weights[2]);
markowitzReturn(Weights,0);
printf("\nMin: %.2f %.2f %.2f",Weights[0],Weights[1],Weights[2]);
}
Здесь средние и ковариации выстроены в скрипт, взятый из набора примеров, предложенных Марковицем. Функция markowitz запускает алгоритм и возвращает значение отклонения, привязанное к лучшему коэффициенту Шарпа. Затем функция markowitzReturn рассчитывает весы (нагрузку) распределение капитала с максимальным возвратом среднего для предложенного отклонения. Значения весов для максимума, наилучшего и минимума отклонения выведены на печать. Если мы все сделали верно, эти значения должны совпадать с теми, что приведены в книге Марковица.
Max: 0.00 1.00 0.00 Best: 0.00 0.22 0.78 Min: 0.99 0.00 0.01
Выбор активов
Для долгосрочных портфелей вы не можете использовать инструменты Forex или CFD с высоким уровнем левереджа (плечом), которые годятся для краткосрочных стратегий. Вместо этого вы инвестируете в акции, ETF или другие похожие активы. Для алгоритмического трейдинга в них есть определенная польза:
- Исключается игра с нулевой суммой. На длинной дистанции акции и индексы ETF имеют положительное значение возврата к среднему, исходя из дивидендов и трендов рынка.
- Появляется больше надежных брокеров. Брокеров, работающих с акциями и ETF, регулируют, чего нельзя сказать про брокеров с Форекса и CFD.
- Больше данных для закачки в ваш алгоритм. Например, сведения об объемах и глубине рынка.
- Больше выбор активов в различных секторах рынка.
- Больше трейдинговых методов.
Очевидный недостаток этих инструментов – низкий уровень левереджа. Например, 1:4 вместо 1:100 на валютном рынке. Низкий левередж годится для долгосрочных инвестиций, но на нем нельзя заработать быстро. С долгосрочными портфелями связан еще ряд ограничений. MVO, очевидно, не сработает с вещами, у которых не будет положительного возврата среднего. Это не сработает, даже если доходы будут прочно коррелированны. Поэтому при выборе активов стоит обращать внимание не только на возвраты, но и на корреляцию. Вот пример скрипта Zorro для этой задачи:
#define NN 30 // max number of assets
function run()
{
BarPeriod = 1440;
NumYears = 7;
LookBack = NumBars;
string Names[NN];
vars Returns[NN];
var Correlations[NN][NN];
int N = 0;
while(Names[N] = loop(
"TLT","LQD","SPY","GLD","VGLT","AOK"))
{
if(is(INITRUN))
assetHistory(Names[N],FROM_YAHOO);
asset(Names[N]);
Returns[N] = series((priceClose(0)-priceClose(1))/priceClose(1));
if(N++ >= NN) break;
}
if(is(EXITRUN)) {
int i,j;
for(i=0; i<N; i++)
for(j=0; j<N; j++)
Correlations[N*i+j] =
Correlation(Returns[i],Returns[j],LookBack);
plotHeatmap("Correlation",Correlations,N,N);
for(i=0; i<N; i++)
printf("\n%i - %s: Mean %.2f%% Variance %.2f%%",
i+1,Names[i],
100*annual(Moment(Returns[i],LookBack,1)),
252*100*Moment(Returns[i],LookBack,2));
}
}
Для начала он устанавливает ряд параметров, затем запускает цикл с N активами. Здесь для примера даны самые популярные ETF. Есть сайт etfdb.com, который поможет вам заменить их на оптимальную комбинацию.
При первом запуске цены активов были скачены с Yahoo. Функция assetHistory сохраняет их в качестве исторических данных. Потом активы отбираются, подсчитываются их возвраты, и эти данные уже хранятся в сериях данных Returns. Эта процедура повторяется на каждый день из 7 лет тестового периода (на практике все зависит от того, когда выбранные ETF активы становятся доступными). В итоге скрипт распечатывает ежегодные значения возврата среднего и отклонений каждого актива. Они становятся, соответственно, первым и вторым moment каждой из серий. Функция annual и множитель 252 конвертируют ежедневные значения в годовые. В нашем примере результат получился следующий:
1 - TLT: Mean 10.75% Variance 2.29% 2 - LQD: Mean 6.46% Variance 0.31% 3 - SPY: Mean 13.51% Variance 2.51% 4 - GLD: Mean 3.25% Variance 3.04% 5 - VGLT: Mean 9.83% Variance 1.65% 6 - AOK: Mean 4.70% Variance 0.23%
Идеальный ETF будет иметь высокое значение возврата среднего, низкое отклонение и слабую корреляцию с другими активами в выборке. Корреляцию можно увидеть в корреляционной матрице, которая рассчитывается для всех собранных значений возвратов и рисуется в виде тепловой диаграммы N*N.
Матрица содержит корреляционный коэффициент каждого актива по отношению к каждому другому активу. В нашем случае их 6. Синий цвет – для слабой корреляции, красный, следовательно, для высокой. Из этой диаграммы видно, что некоторые активы не следовало выбирать.
Предел эффективности
После выбора активов в наш портфель, пришло время рассчитать оптимальное распределение капитала в нем через алгоритм MVO. При любом раскладе, «оптимальность» зависит от допущения рисков. Другими словами, волатильности портфеля. Для каждого из значений риска существует свое оптимальное распределение, которое генерирует максимальную прибыль. То есть оптимальное распределение – это не застывшая точка, а скорее кривая на графике возврат/отклонение. Ее еще называют предел или граница эффективности. Мы можем рассчитать ее и нарисовать в виде диаграммы, используя следующий скрипт:
function run()
{
... // similar to Heatmap script
if(is(EXITRUN)) {
int i,j;
for(i=0; i<N; i++) {
Means[i] = Moment(Returns[i],LookBack,1);
for(j=0; j<N; j++)
Covariances[N*i+j] =
Covariance(Returns[i],Returns[j],LookBack);
}
var BestV = markowitz(Covariances,Means,N);
var MinV = markowitzVariance(0,0);
var MaxV = markowitzVariance(0,1);
int Steps = 50;
for(i=0; i<Steps; i++) {
var V = MinV + i*(MaxV-MinV)/Steps;
var R = markowitzReturn(0,V);
plotBar("Frontier",i,V,100*R,LINE|LBL2,BLACK);
}
plotGraph("Max Sharpe",(BestV-MinV)*Steps/(MaxV-MinV),
100*markowitzReturn(0,BestV),SQUARE,GREEN);
}
}
Пропустим первую его часть, она идентична коду для создания теплокарты. Только в данном случае просчитывается матрица ковариаций. Ковариации и возвраты среднего заносятся в функцию
markowitz, которая снова делает возврат отклонения, исходя из лучшего коэффициента Шарпа. Тот в свою очередь обращается к markowitzVariance, происходит возврат высшего и низшего отклонения предела эффективности. Получаем границы графика. В итоге скрипт выдает 50 точек ежегодного возврата среднего от низшего до высшего отклонений:
Справа мы можем видеть, как портфель достигает максимального ежегодного уровня прибыли в 12,9%. Слева имеем значение 5,4%, но с числом ежедневных отклонений меньше 10. Зеленая точка на графике обозначает лучший коэффициент Шарпа (прибыль деленная на корень квадратный отклонений) с 10% ежегодного дохода при отклонении 0,025. Это оптимальный портфель. По крайней мере, в ретроспективе данных.
Эксперимент
Как наш оптимизированный по среднему/отклонению портфель ведет себя в пределах выборки и за пределами выборки в сравнении с показателем 1/N? Ниже приведен скрипт для экспериментальной проверки с по-разному скомпонованными портфелями, периодами отката, ограничениями по весу и отклонениями:
#define DAYS 252 // 1 year lookback period
#define NN 30 // max number of assets
function run()
{
... // similar to Heatmap script
int i,j;
static var BestVariance = 0;
if(tdm() == 1 && !is(LOOKBACK)) {
for(i=0; i<N; i++) {
Means[i] = Moment(Returns[i],LookBack,1);
for(j=0; j<N; j++)
Covariances[N*i+j] = Covariance(Returns[i],Returns[j],LookBack);
}
BestVariance = markowitz(Covariances,Means,N,0.5);
}
var Weights[NN];
static var Return, ReturnN, ReturnMax, ReturnBest, ReturnMin;
if(is(LOOKBACK)) {
Month = 0;
ReturnN = ReturnMax = ReturnBest = ReturnMin = 0;
}
if(BestVariance > 0) {
for(Return=0,i=0; i<N; i++) Return += (Returns[i])[0]/N; // 1/N
ReturnN = (ReturnN+1)*(Return+1)-1;
markowitzReturn(Weights,0); // min variance
for(Return=0,i=0; i<N; i++) Return += Weights[i]*(Returns[i])[0];
ReturnMin = (ReturnMin+1)*(Return+1)-1;
markowitzReturn(Weights,1); // max return
for(Return=0,i=0; i<N; i++) Return += Weights[i]*(Returns[i])[0];
ReturnMax = (ReturnMax+1)*(Return+1)-1;
markowitzReturn(Weights,BestVariance); // max Sharpe
for(Return=0,i=0; i<N; i++) Return += Weights[i]*(Returns[i])[0];
ReturnBest = (ReturnBest+1)*(Return+1)-1;
plot("1/N",100*ReturnN,AXIS2,BLACK);
plot("Max Sharpe",100*ReturnBest,AXIS2,GREEN);
plot("Max Return",100*ReturnMax,AXIS2,RED);
plot("Min Variance",100*ReturnMin,AXIS2,BLUE);
}
}
Цикл проверки составляет 7 лет исторических данных. Он сохраняет ежедневные возвраты в сериях данных
Returns. В первый день трейдинга каждого месяца (tdm() == 1) подсчитываются матрицы средних и ковариаций за последние 252 дня. На их основании измеряется предел эффективности. В нашем случае ограничение по весу составляет 0,5 по отношению к точке минимального отклонения. Если взять за основу этот предел эффективности, то мы получаем ежедневную общую прибыль с одинаковым весом (ReturnN), лучшим коэффициентом Шарпа (ReturnBest), минимальным отклонением (ReturnMin) и максимальным доходом (ReturnMax). Вес остается неизменным до следующей балансировки, когда мы будем проходить тест за пределами выборки. Прибыли за 4 дня добавляется к 4 разным кривым акций:
Из графика можно видеть, что MVO улучшил портфель для всех трех вариантов, несмотря на свою плохую репутацию. Черная линия отмечает 1/N портфеля с одинаковым весом для каждого актива. Синяя линия обозначает портфель с минимальным отклонением. Мы видим, что его отдача выше, чем 1/N, при гораздо меньшей волатильности. Красная линия – портфель с максимальной доходностью, но высокой волатильностью. Зеленая линия – лучший коэффициент Шарпа, это средний по всем показателям портфель. Состав портфеля может быть разный, но зеленая и синяя линии показывают наилучшие варианты.
Для проверки месячной балансировки распределения весов, можно отобразить их в виде тепловой карты.
Горизонтальная ось обозначает месячный период нашей симуляции. Вертикальная – номер актива. Высокие веса закрашены красным, нижние – синим. Это распределение весов для портфеля с максимальным коэффициентом Шарпа, состоящее из 6 активов ETF.
«Заносим» в систему деньги
После всех экспериментов можно кодировать долгосрочную систему. Для этого предлагается следующий порядок действий:
- Предел эффективности рассчитывается, исходя из ежедневной прибыли последний 252 трейдинговых дней. То есть одного года. Это лучший период, если верить статье, которую мы цитировали в начале. Так как большинство ETF демонстрируют годовой моментум.
- Балансировка портфеля производится раз в месяц. В тестах более короткие периоды показали свою бесполезность, и снизили доход из-за более высоких трейдинговых издержек. При более длинных периодах (3 месяца) работа системы ухудшается.
- Точку предела эффективности можно сделать плавающей в границах минимального отклонения и максимального коэффициента Шарпа. Так вы сможете контролировать уровень риска системы.
- Мы используем 50% ограничение по весу для минимального отклонения. Это не самый оптимальный портфель, но, опять же, в цитированной статье (и тесты автора это подтвердили), говорится, что это улучшает баланс за пределами выборки.
Вот так выглядит скрипт:
#define LEVERAGE 4 // 1:4 leverage
#define DAYS 252 // 1 year
#define NN 30 // max number of assets
function run()
{
BarPeriod = 1440;
LookBack = DAYS;
string Names[NN];
vars Returns[NN];
var Means[NN];
var Covariances[NN][NN];
var Weights[NN];
var TotalCapital = slider(1,1000,0,10000,"Capital","Total capital to distribute");
var VFactor = slider(2,10,0,100,"Risk","Variance factor");
int N = 0;
while(Names[N] = loop(
"TLT","LQD","SPY","GLD","VGLT","AOK"))
{
if(is(INITRUN))
assetHistory(Names[N],FROM_YAHOO);
asset(Names[N]);
Returns[N] = series((priceClose(0)-priceClose(1))/priceClose(1));
if(N++ >= NN) break;
}
if(is(EXITRUN)) {
int i,j;
for(i=0; i<N; i++) {
Means[i] = Moment(Returns[i],LookBack,1);
for(j=0; j<N; j++)
Covariances[N*i+j] = Covariance(Returns[i],Returns[j],LookBack);
}
var BestVariance = markowitz(Covariances,Means,N,0.5);
var MinVariance = markowitzReturn(0,0);
markowitzReturn(Weights,MinVariance+VFactor/100.*(BestVariance-MinVariance));
for(i=0; i<N; i++) {
asset(Names[i]);
MarginCost = priceClose()/LEVERAGE;
int Position = TotalCapital*Weights[i]/MarginCost;
printf("\n%s: %d Contracts at %.0f$",Names[i],Position,priceClose());
}
}
}
Сам скрипт только «советует», но не торгует. Для автоматизации процесса еще понадобится интегрировать торгового робота через API брокерской системы (например, у ITinvest такой интерфейс получил название SmartCOM). При этом, если позиции открываются и закрываются раз в месяц, а данные об акциях можно найти и в открытом доступе, то интеграция может быть и не нужна — нужно будет просто запускать его раз в месяц, и анализировать его вывод:
TLT: 0 Contracts at 129$ LQD: 0 Contracts at 120$ SPY: 3 Contracts at 206$ GLD: 16 Contracts at 124$ VGLT: 15 Contracts at 80$ AOK: 0 Contracts at 32$
Очевидно, что оптимальный портфель за этот месяц будет состоять из трех сделок по SPY, 16 по GLD и 15 VGLT. Теперь можно вручную открывать и закрывать позиции в своей брокерской платформе, пока портфель не будет соответствовать распечатанному списку. Левередж по умолчанию – 4. Но его можно поменять по желанию в начале скрипта (#define). Если хотите сделать так, чтобы скрипт самостоятельно торговал, замените команду printf командой для открытия и закрытия позиций.
MVO против OptimalF
MVO можно использовать не только для портфеля с определенным количеством активов, но и для разных трейдинговых систем. Автор блога Financial провел эксперимент, в ходе которого выяснилось, что MVO не превосходит результат, который можно получить при применении коэффициента OptimalF Ральфа Винса. Он используется в большинстве трейдинговых систем. OptimalF не осуществляет корреляции между компонентами, но учитывает глубину выборки средств. В то время как MVO работает только со средними и ковариациями. Идеальным решением было бы совместить оба подхода — но это дело будущих экспериментов.
Ссылки
- Momentum and Markowitz – A Golden Combination: Keller.Butler.Kipnis.2015
- Harry M. Markowitz, Portfolio Selection, Wiley 1959
Другие материалы по теме от ITinvest:
- Технологии фондового рынка: 10 заблуждений о нейронных сетях
Аналитические материалы о ситуации на финансовых рынках от экспертов ITinvest - Описание процесса создания архитектуры системы онлайн-трейдинга: подход аналитика хедж-фонда
- Как определить наилучшее время для сделки на фондовом рынке: Алгоритмы следования тренду
- ИБ-стартап Palantir поможет инвестбанку Credit Suisse создать систему для выявления недобросовестных трейдеров
- Эксперимент: Использование Google Trends для прогнозирования обвалов фондового рынка
- Эксперимент: создание алгоритма для прогнозирования поведения фондовых индексов
Комментарии (0)
четверг, 9 июня 2016 г.
А ты сдал свой гаджет на «Доброе дело»?
Год назад совместно с Правительством Москвы в рамках «Дарудара» мы запустили акцию «Доброе дело». Цель акции — подарить социально незащищенным гражданам Москвы (многодетным семьям, инвалидам, пенсионерам) электронные устройства, позволяющие общаться, учиться, быть в курсе текущих событий, а также помочь им воспользоваться электронными госуслугами (записаться к врачу, оплатить ЖКХ, записать ребенка в школу или детский садик и многое другое). Уникальность акции в том, что при желании можно самому выбирать одариваемого и получать подтверждение о передачи дара в виде публичной благодарности. За прошедший год в рамках акции было передано уже почти 1000 устройств (взгляните на список благодарностей).
И сегодня мы рады сообщить о том, что появилась возможность поучаствовать в акции, не выходя из дома. Если раньше это можно было сделать только самостоятельно — либо опубликовав свой дар на сервисе дарения «Дарудар», либо привезя его лично в пункт приёма на ВДНХ. То с 23 мая и в течение 2 месяцев свой гаджет можно будет также передавать с бесплатным курьером сервиса YouDo — он сам заедет в удобное для вас место и время и сам доставит его в наш пункт приёма на ВДНХ (павильон №9). После этого ваше устройство найдет нового хозяина среди подопечных акции, а вы получите благодарность на свою электронную почту.
Приглашаем сообщество «Хабрахабра» присоединяться к акции и дарить свои гаджеты тем людям, которые сами приобрести их не могут. Наверняка у вас в ящике стола лежит старенькая Моторолла или ваш первый коммуникатор. Вы уже никогда ими пользоваться не будете, а кому-то они еще смогут как следует послужить (= Узнать детали и заказать курьера.
Комментарии (0)
CodeRush for Roslyn: Part 1 — полезные фичи для разработки через тестирование
В этой статье расскажу о поддержке тестовых фреймворков в CRR. Почти во всех примерах будет использован проект http://ift.tt/25OxJxr. Этот проект использует NUnit framework, но мы так же поддерживаем xUniut, MSpec, MS Test Framework. Все рассмотренные ниже практики работают одинаково вне зависимости от того, какой тестовый фреймворк вы используете.
Если классифицировать разработчиков по способу использования рабочего пространства в Visual Studio, можно выделить тех, кто скрывает все дополнительные toolwindow и выделяет максимум свободного места окну с кодом, и тех, кто использует toolwindow в рабочей области.
Для первой группы мы поддерживаем прогон тестов прямо из редактора кода:
Как правило, тесты чинятся не за одну итерацию, и разработчик несколько раз повторяет последовательность действий: меняет код, запускает красный тест, проверяет результат. Сократить время выполнения этих рутинных операций можно с помощью пункта Repeat Last Test Run в контекстном меню. После прогона тестов можно посмотреть результат прямо в редакторе, также CRR умеет определять строчку, которая сломала тест.
Также доступна более детальная информация по сломанному тесту при наведении курсора на иконку проблемного теста.
Для тех, кто использует toolWindow, у нашего тестраннера есть окошко, которое можно прикрепить внизу окна Visual Studio, там где обычно
располагается Output. Testrunner toolWindow доступно через главное меню CodeRush->Windows->Test Runner.
Для тех, у кого широкий монитор, имеет смысл располагать окошко тестраннера слева или справа.
После прогона обычно работают с проблемными тестами. В testrunner toolwindow можно выставить фильтр, чтобы отображались только не прошедшие тесты.
Из toolWindow можно перейти к коду проблемного теста или фикстуры, выбрав пункт Goto XX в контекстном меню.
В дополнение к информации о последнем прогоне тестов, в testRunner toolWindow отображается время затраченное на прогон теста или фикстуры. Таким образом, всегда видно медленные тесты. Можно сделать их оптимизацию или запускать их отдельно. Для этого полезны сессии. Например, можно добавить медленные тесты в отдельную сессию.
После добавления Slow Tests сессии для тормозных тестов и Common Tests для всех остальных, окно тестраннера будет выглядеть так. Main — это сессия по умолчанию, которая всегда содержит все тесты.
CRR — новый удобный инструмент для запуска тестов непосредственно в Visual Studio. Кроме возможностей, показанных в статье, CRR поддерживает параллельный прогон тестов, разбиение консольного вывода по тестам и много чего еще. Скачать попробовать можно в Visual Studio Gallery.
Комментарии (0)