-Поиск по дневнику

Поиск сообщений в rss_rss_hh_new

 -Подписка по e-mail

 

 -Статистика

Статистика LiveInternet.ru: показано количество хитов и посетителей
Создан: 17.03.2011
Записей:
Комментариев:
Написано: 51

Habrahabr/New








Добавить любой RSS - источник (включая журнал LiveJournal) в свою ленту друзей вы можете на странице синдикации.

Исходная информация - http://habrahabr.ru/rss/new/.
Данный дневник сформирован из открытого RSS-источника по адресу http://feeds.feedburner.com/xtmb/hh-new-full, и дополняется в соответствии с дополнением данного источника. Он может не соответствовать содержимому оригинальной страницы. Трансляция создана автоматически по запросу читателей этой RSS ленты.
По всем вопросам о работе данного сервиса обращаться со страницы контактной информации.

[Обновить трансляцию]

Для чего используется SBC на границе сетей

Среда, 09 Августа 2017 г. 14:32 + в цитатник
Постараемся в этой статье собрать и подытожить основные данные и факты, известные широкой и узкой общественности по поводу того, зачем же нужен Контроллер Пограничных Сессий (SBC) операторам и корпоративным заказчикам. Банальный запрос в поисковиках выдает не так много информации и она не всегда претендует на простоту и доступность изложения материала.

Растущая заинтересованность в виртуализации приложений и сетевой функциональности только добавляет вопросов типа «возможно ли развернуть SBC в виртуальной среде и не проиграть в функциональности».

Как видно из названия, SBC (Session Border Controller, пограничный контроллер сессий) – это оборудование (или ПО), устанавливаемое на границе сетей и что-то контролирующее.



Контроль, который обеспечивает SBC, в первую очередь касается именно голосового трафика (сигнального и медийного), объемы которого растут в силу перехода от TDM к IP, набирающего обороты день ото дня. Сразу отметим, что этот тип оборудования ничего общего не имеет с файерволами и системами безопасности, работающими на уровне IP в обычных сетях СПД. Скорее наоборот, он дополняет и покрывает те участки, где даже самый продвинутый файервол ничего проконтролировать и тем более защитить не сможет.

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

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

1. Скрытие внутренней топологии вашей сети от внешнего мира.
Под внутренней топологией понимается любая информация о сетевых настройках (IP адреса), устройствах и версиях ПО, пути прохождения голосового трафика, использовании трансляции адресов (NAT) и пр. Чтобы исключить вопросы и удивление, которое обычно испытывает руководство верхнего уровня операторов и корпоративных заказчиков, перефразирую так: да, такую деликатную информацию о вашей внутренней сетевой инфраструктуре, частично или полностью, достаточно легко можно получить путем простого анализа голосового трафика с помощью бесплатных анализаторов трафика. Это совсем не шутка. Такая информация по крупицам легко собирается из разных полей и заголовков сообщений сигнального и медийного голосового трафика. Часть специалистов инженерных служб заказчика на этом этапе успешно парируют: наши сетевые устройства (CPE, роутеры и тд и тп) используют функциональность ALG (Application Layer Gateway), которая помогает нам с этими проблемами. Отчасти это так, но только в совсем мизерной части. Чтобы завершить обсуждение различных ALG, которые исходя из моего многолетнего опыта работы в области пакетного голоса, зачастую только добавляют проблем в нормальной передаче трафика, приведу простую таблицу сравнения ALG и SBC.



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

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

3. Защита сетей
Скрытие топологии – это только один из многих аспектов, о которых приходится говорить во время обсуждения темы защиты голосовых сетей. В большинстве случаев, если не всегда, вопрос организации правильной стратегии защиты наталкивается на стандартную дилемму – защитить сеть и при этом не навредить сервису/бизнесу. Зажать в строгие правила обработки и анализа можно любой трафик, главное при этом обеспечить разумную и корректную работу всех сервисов и не дать повода абоненту/заказчику уйти к вашему конкуренту, который более грамотно настроил свою сеть и обеспечил возможность пользоваться расширенным набором сервисов. Я упоминаю здесь об этом потому, что на практике сплошь и рядом встречаются администраторы сетей, которые такой баланс не соблюдают либо в силу недостаточности знаний, либо по причине отсутствия достаточного внимания этому вопросу. Да и надо честно признать, что профессиональных специалистов в области передачи голоса не так много.
Обозначу основные моменты, на которые стоит обратить внимание при решении вопросов защиты.

a) Защита от взлома
Это самое первое, что приходит в голову при обсуждении вопросов защиты. Перечислю от простого к сложному несколько моментов, которые применяются сплошь и рядом при взломах.
  • Банальное сканирование используемых портов, причем специализированными сканерами голосовых приложений и решений;
  • проверка ответов вашего оборудования на стандартные сигнальные сообщения с целью выяснения деталей о вашей сети (даже минимальных данных достаточно, чтобы определить следующий шаг по взлому);
  • определение некоторых типов сервисов (например, переадресации);
  • подборы SIP логинов и паролей;
  • сканирование сетевого трафика и анализ пакетов;
  • попытки звонков от имени зарегистрированных/незарегистрированных абонентов;
  • спуфинг (маскировка под легитимного абонента);
  • подмена доверенных пакетов и попытка вклиниться в установленную легитимную сессию.

Наверное, достаточно для понимания серьезности проблемы. Любой нормальный SBC должен знать и уметь бороться с вышеперечисленным и не только с этим. А без детального анализа именно голосового трафика такая борьба бессмысленна. Надо понимать, что и администратор сети должен знать, как правильно настроить SBC для корректной работы. Для этого, кроме знаний, должны быть все возможности на SBC для настройки массы различных критериев, например, количество неуспешных попыток регистрации, обнаружение подозрительного трафика (не только вышеуказанные пункты, но например, анализ длины SIP сообщений) и много всего другого.

b) DoS/DDoS VoIP атаки
Задосить незащищенное голосовое оборудование можно легко, нужно только желание. И поверьте, есть масса способов сделать это, даже если применяется супер-пупер дата-файерволл. И снова проблема в том, что никакое СПД-шное оборудование не защитит, например, от безумного количества регистраций, посланных от имени корректного и легитимного абонента. Или от неимоверного количества попыток установления вызова на легитимного абонента. А все дело в том, что любой файерволл ОБЯЗАН пропусть весь этот трафик без ограничений, потому что он предназначается абсолютно легимному абоненту, а значит, должен быть обработан.

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

c) Некорректные голосовые пакеты
Под посылкой некорректных голосовых пакетов можно понимать несколько разных неприятных моментов, например:
— отправка длинного пакета и сигнального сообщения;
— формирование длинных полей и значений заголовков сигнальных сообщений;
— попытки вклиниться (и впоследствии перенаправить трафик не туда, куда нужно) в установленную сигнальную сессию, подменяя пакеты от легитимного абонента сторонними, но тоже легитимными пакетами;
— отправка сигнальных сообщений в измененном порядке

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

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

e) Звонки для незарегистрированных абонентов
Из вышесказанного становится понятно, что путем банального подбора и при разрешенных звонках на незарегистрированных пользователей организовать «слив» трафика за счет оператора становится не просто, а совсем просто. Комичность ситуации в том, что существует достаточно много решений, претендующих на серьезность и позволяющих делать такие вещи. Трагичность ситуации в том, что многие используют такие «решения» у себя, подвергая себя крайнему риску.

f) Возможность задавать произвольные правила анализа и проверки (классификация трафика)
Нормальный SBC должен уметь и позволять настраивать не только шаблонные часто использующиеся правила анализа трафика, но и любые разумные «хотелки/проверялки». В качестве примера, немного утрируя, приведу такое «идиотское» правило проверки: если входящий INVITE содержит более двух заголовков Via, а третий заголовок Via содержит IP адрес вида 172.х.х.100, и при этом поле From в части user part имеет набор букв XYZ, то разрешить (или запретить) обработку такого трафика. Надеюсь, понятно, что такая возможность добавляет гибкости при использовании SBC.

g) Динамические черные/белые списки и access листы
Достаточно стандартная функциональность. SBC должен уметь анализировать трафик и «автоматически» определять его легитимность. Любой подозрительный трафик, не удовлетворяющий заданным критериям, блокируется. В идеале должна поддерживаться защита по настраиваемым критериям, например, количество неуспешных попыток регистрации, количество попыток регистрации в секунду, превышение установленного количества посылаемых пакетов в секунду, обнаружение подозрительного трафика (например, длина SIP сообщений, попытки подделки SIP сообщений и вклинивания в установленную ранее активную SIP сессию)

h) Статические черные/белые списки и access листы
Ну а как же без этого? Пример: вы обнаружили злокачественный трафик, имеющий характерные признаки и причиняющий вред вашей сети. Например потому, что ваш администратор «забыл» или не подумал сконфигурировать и задать поведение SBC для какого-то сценария. Для быстрой блокировки просто закрываете поток зла, сразу весь, возможно и с частью полезного трафика. А потом начинаете думать и создавать то самое правило, которого не хватало.

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

4. Манипуляция с SIP заголовками, манипуляция с SDP
Способность модифицировать проходящие через SBC сообщения важны. В качестве самого простого примера, описывающего необходимость, вспомним о том, что уже обсудили выше – скрытие внутренней топологии сети. Модификация сигнальных сообщений на уровне SDP позволяет убрать из заголовков информацию, которую не нужно светить наружу. Другой пример – необходимость добавить или изменить информацию в сигнальных сообщениях, от которой зависит работоспособность сервиса. Вспомните, что в SIP бывают такие услуги, которые технически могут работать с использованием различных методов. И на ответной стороне вашего SIP транка метод может отличаться от того, какой применяется на вашей сети. Поэтому модификация необходимых полей позволяет обеспечивать работоспособность одинаковых сервисов, которые работают по-разному.
В добавление к вышесказанному остается сказать, что функциональность модифицировать сигнальные сообщения относится не только к заголовкам и содержимому SIP сообщений, то также и к SDP-части этих сообщений. Это важно, поскольку от SDP напрямую зависит корректность согласования и работоспособность передачи медийного трафика.

5. Нормализация SIP
Разные SIP клиенты, число которых бесконечно велико, могут иметь свои особенности работы. Зачастую эти особенности заключаются в том, что при работе этих клиентов используются нестандартные или некорректно сформированные заголовки и параметры SIP сообщений. Нормализация SIP сообщений при прохождении через SBC подразумевает приведение основных и обязательных SIP-заголовков к стандартному виду. Это означает стабилизацию работы при использовании разных SIP клиентов.

6. Обеспечение работы абонентов за NAT (NAT Traversal)
Эта тема заслуживает отдельного внимания. Во-первых, потому что использование и распространенность услуг так называемых виртуальных АТС значительно выросло. Во-вторых, в подавляющем большинстве случаев предоставление голосовых сервисов розничным абонентам (физлицам) происходит по схеме с регистрацией абонентов в ядре голосовой сети. Под ядром понимается оборудование, предоставляющее голосовые сервисы (софтсвитчи, SIP сервера, IMS и прочее). Регистрация SIP-клиентов в таких схемах включения в подавляющем большинстве случаев производится с устройств (роутеры, CPE, wifi точки доступа и пр), или из-за устройств, на которых включена функция трансляции адресов, потому что SIP-клиент имеет приватные немаршрутизируемые адреса типа 192.168.х.х и другие. Таким образом, NAT в таких схемах нельзя назвать методом, упрощающим предоставление голосового сервиса. Потому что трансляция адресов происходит на IP уровне, оставляя неизмененными адреса на более высоких уровнях. И согласование и прохождение SIP сигнализации от конечного SIP клиента до ядра сети в таких случаях подвержено трудностям. А кроме сигнального трафика есть еще и медийный. А IP адреса медийного трафика как раз передаются там, где никакой NAT их не заменит, да и не всякий ALG это умеет. Это приведет к тому, что медиа-трафик может быть направлен на немаршрутизируемые адреса. Последствия очевидны и крайне нежелательны – односторонняя слышимость как минимум, не говоря о других, менее очевидных особенностях и последствиях работы NAT. Поэтому способность SBC решать такие проблемы крайне важна. И важно, чтобы эти проблемы в идеале решались автоматически, не требуя индивидуального подхода в настройках к каждому конкретному подключению SIP абонента.

7. Совместимость с любыми сторонними решениями
Выше уже об этом упоминалось. Подключения и интерконнект с внешними сетями прогнозировано имеет дело с согласованием сигнализации SIP. Ну хотя бы потому, что несмотря на то, что SIP называют стандартом, свободную интерпретацию документов RFC разными производителями никто законодательно не отменял. Ну и вспомним, что самих «разновидностей» SIP RFC насчитывается сейчас более восьмидесяти. Теперь наверняка станет понятнее, что понимается под совместимостью. Совместить и возможность выполнить сопряжение оборудования разных производителей зачастую становится трудновыполнимой или невозможной задачей. Справиться с такими задачами могут далеко не все SBC, а только самые продвинутые.

8. Взаимодействие с сетями, имеющими стык с SS7 (поддержка SIP-I/SIP-T)
Тоже важная тема. Особенно сейчас, когда становится все более доступной возможность организации прямых межоператорских стыков с использованием SIP. Да и при подключении корпоративных клиентов тема тоже остается весьма актуальной, поскольку требуется конвертация SIP-I в обычный SIP.
Здесь речь идет о способности обрабатывать SIP трафик, в котором в SDP части передается контекст сигнализации ОКС-7, который может существенно повлиять на корректность отработки некоторых сервисов, например трансферов/форвардов, или даже прохождению базового вызова на границе двух операторов. Чтобы корректно решать эти проблемы, требуется возможность модификации некоторых полей в SDP части при прохождении транзитного вызова, или корректная конвертация SIP-I в обычный SIP. И это уже абсолютно точно функциональность профессиональных SBC, особенно если вспомнить количество различных вариантов и стандартов сигнализации ISUP. А как раз о ней и идет речь, когда мы говорим о передаче контекста ОКС-7 через SIP.

9. SIPREC для стыка с внешними система записи трафика
Тут вроде как все просто. Бывают задачи, когда требуется запись разговоров. Сразу оговоримся, что это не СОРМ (хотя иногда может применяться как workaround для СОРМ). Это запись разговоров. И речь тут о стыке со специализированными системами и решениями, которые такую задачу выполняют. Выполняется она посредством протокола Session Recording Protocol (SIPREC). Детали можно найти здесь.
Эта тема важна для части бизнес-задач. Сложность в том, что в задачах записи сессий существуют уникальные требования, которые не решены в существующих спецификациях протокола SIP. Речь идет о некоторых технических особенностях реализации решений, а также о вопросах безопасности и сохранения личных данных. Кроме этого, есть требование извещать абонента о том, что его разговор записывается. Для решения всех этих вопросов и был разработан SIPREC. Реализован далеко не у всех.

10. Разделение типов трафика по различным интерфейсам
Немного писал уже об этом. Сформулируем по-другому. Вариантов внедрения может быть много. Разделение внешнего и внутреннего трафика по различным физическим интерфейсам – это только часть. Порой нужно чтобы разный тип трафика был разделен по разным физическим интерфейсам. Например, сигнализация на одном, медиа на другом, управление на третьем. А может, нужно комбинировать. В общем, вариантов много. Полная поддержка добавляет гибкости.

11. Обеспечение взаимодействия IPv4 <-> IPv6
Тут все вроде бы просто, особых комментариев не требуется. Внедрения IPv6 уже есть, чем дальше, тем больше. Раз уж SBC стоит на границе голосовых сетей, то это его прямая обязанность – выполнять конвертацию.

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

a) Конвертация TCP <-> UDP, TCP <-> TLS, UDP <-> TLS, динамическое изменение протокола транспортного уровня.
SIP поддерживает не только UDP. Существуют и другие варианты. На стыке сетей сплошь и рядом встает задача такой конвертации. И конечно же удобно, если это выполняется не только в фиксированной конфигурации, которая чаще всего встречается при подключении SIP транка, а и динамически. Ну представьте хотя бы абонентов, которые регистрируются на вашей голосовой платформе. Одни используют UDP, другие – TCP или вообще TLS. Как вы заранее поймете, как поступать с конкретным абонентом? Конечно лучше выполнять эту задачу динамически.

b) Конвертация RTP <-> SRTP
Тут тоже понятно и достаточно часто встречается. Конвертация RTP в SRTP и наоборот нужна несомненно.

c) Конвертация T.38 <-> G.711
Классика жанра. Давно и долго кричат все про смерть факсимильной связи. Но это далеко от реалий. Этот вид связи как использовался, так и продолжает использоваться. Конечно, современные системы уже в большинстве случаев экономят бумагу и отправляют факс на электронную почту в виде файла. Но от этого механизм передачи факса не меняется. Два самых распространенных формата передачи несовместимы друг с другом и требуется преобразование, если два абонента посылают факс друг другу, используя разные методы.

d) DTMF транскодинг (RFC2833 <-> inband <-> SIP INFO)
Тоже классическая проблема. Сигналы DTMF могут передаваться по-разному. Это зависит от настроек и возможностей/функциональности конкретного абонентского оборудования и голосового решения, предоставляющего конечный сервис. Но факт, что DTMF должен дойти из конца в конец. А что на пути и какой метод используется, это больной вопрос. Конвертация между различными методами крайне важна.

e) Транскодинг кодеков
Современный мир телекома движется вперед очень быстро. Ну вот пример некоторых типов кодеков, которые достаточно часто встречаются в последнее время:
G.723; G.729; G.728; NETCODER; GSM-FR; GSM-EFR; AMR; EVRC-QCELP; G.727; ILBC; EVRC-B; AMR-WB; G.722; EG.711; MS_RTA; SILK; SPEEX; OPUS.
На межоператорском стыке вопрос транскодирования в основном ограничивается транскодингом G.711 и G.729, хотя бывают и более экзотические случаи. Но при подключении корпоративных заказчиков или небольших операторов зачастую возникает задача совсем нетривильная, связанная с использованием так называемых «тяжелых» кодеков, применяющихся в специфических услугах и сервисах. Использование современных веб-сервисов или некоторых мобильных приложений также предполагает использование кодеков, отличных от общепринятых.

f) Ptime транскодирование.
Его правильнее было бы назвать по-другому, поскольку собственно транскодинга тут и как такового нет. Есть изменение времени пакетизации в рамках одного и того же кодека. Ответ на вопрос «зачем» очень прост – экономия полосы в канале. Для некоторых применений это очень важная задача и решается таким способом, позволяя экономить полосу и вычислительные мощности оборудования.

13. Поддержка REST
Многим это не нужно и они даже не заморачиваются на эту тему. Однако поддержка REST API позволяет гибко и очень просто решать многие и многие задачи. Интеграция со сторонними решениями, управление и безболезненная переконфигурация системы проводится очень быстро и не вызывает сложностей. В технологии NFV (Network Function Virtualization) протокол REST используется подавляющим большинством оркестраторов для целей контроля и управления NVF-элементов (Network Virtual Function element).

14. WebRTC и поддержка так называемых web-кодеков (например, OPUS)
WebRTC – также отдельная тема, позволяющая добавлять оператору много новых современных услуг и захватывать те ниши, на которые ранее и даже мысли не приходило обращать внимание. В основе своей WebRTC — это бесплатная open-project технология выполнения звонков, видео, чатов, передачи файлов в интернет без установки дополнительного оборудования или программного обеспечения (типа flash плейра, плагинов и пр.), напрямую из браузера персонального компьютера, с помощью Javascript API. Привлекательность и применимость очевидна. Техническая реализация требует использования WebRTC шлюза, поскольку применяется тут вовсе не SIP. WebRTC шлюз сам по себе это возможность терминации WebRTC трафика и конвертация его из WebSocket (заменяющего HTTP), в обычный SIP. Да и передача медиа трафика требует проксирования медиа, поскольку два абонента за симметричным NAT не смогут поговорить друг с другом. Но такой шлюз не выполняет задачи по обеспечению безопасности такой конвертации, а также не решает задачи защиты от DoS/DDoS атак, применение разных полиси, Call Admission Control, accoutnting, биллинг, траблешутинг, диагностику и многое другое. Поэтому такая задача ложится на плечи SBC. Т.е. сам по себе SBC должен иметь встроенную функциональность WebRTC шлюза. Ну и поддержка OPUS, поскольку этот кодек основной для применения в WebRTC. Конечно, не забудем и G.711, он также специфицирован для применения. Но на практике не применяется, поскольку не дает никакого качества в открытом интернете, слишком восприимчив к потерям пакетов и другим параметрам, определяющим качество голоса.

15. Маршрутизация SIP трафика на основе IP адресов, А и Б номеров, времени суток, доступности оборудования, стоимости минуты трафика и т.д. и т.п
О необходимости выполнять гибкую маршрутизацию на SBC можно говорить долго. Она нужна, и чем гибче возможности, тем больше выгоды для оператора, особенно для тех, кто использует I-SBC для пиринга. Для A-SBC задача гибкой маршрутизации также важна, особенно в случае предоставления услуг виртуальной АТС.

16. Возможность перемаршрутизации трафика на основе ответа оконечного оборудования
Эту задачу выделил отдельно, для I-SBC при пиринге она критически важна.

17. QoS для приоритезации трафика на определенном IP направлении или для определенного пользователя/клиента
Функциональность тоже, на мой взгляд, не требует детального описания и обсуждения. Подключаемые клиенты и операторы вправе заботиться о качестве и часто просят его обеспечить. А некоторые, так вообще требуют отчетов по качеству передаваемого трафика. В итоге побеждает тот, у кого качество выше.
В идеале, конечно, выигрывает тот, чей SBC умеет сохранять статистику о качестве любого звонка, которые он обработал. Это такие параметры как джиттер, потери пакетов, задержки, эхо, MOS, причины завершения вызова, инициатор завершения вызова, и многое другое. Иными словами, SBC одновременно выступает в качестве пробника трафика на сети.

18. Call Admission Control, ограничения по количеству сессий, полосы пропускания, др. параметрам
Ну а эта функциональность очень часто граничит с задачей экономии денег. Ну потому что нужно и важно контролировать ресурсы своего решения, практически грамотно и рационально ограничивая вашего заказчика или абонента от «поглощения» всех или большей части доступных ресурсов, ограничивая и контролируя нагрузку на ядро сети (SIP сервер, софтсвитч и т.д.)

19. Балансировка трафика (load balancing)
Функциональность важна, когда сложность сети позволяет организовывать и выстраивать гибкие схемы отработки услуг и трафика. Причем работает в обе стороны. У кого-то есть, например, резервные каналы и их использование приветствуется для организации не только отказоустойчивых схем, но и для распределения нагрузки на сеть или распределения сервисов по элеменам ядра сети.

20. Сбор и хранение CDR
Тоже все понятно. SBC, поскольку стоит на границе сети, может применяться в том числе и как точка биллинга или стыка с биллинговой системой. Тут важно понимать, что наиболее предпочтительным является текстовый формат CDR записей.

21. Возможность обеспечения одновременной обработки трафика для режимов access (доступ с регистрацией для услуг типа виртуальной АТС) и peering (обеспечение стыка по SIP транкам)
Часто можно встретить такое ограничение, когда SBC может работать только в каком-то одном режиме. Или только пиринг, или только на доступе. Иногда применение только одного из режимов на самом деле обусловлено схемой и задачей применения SBC. Но возможность работы только в одном режиме накладывает существенные ограничения на планирование и работу сервисов на сети, вынуждая покупать второе устройство для реализации полной схемы для одновременного использования SIP транков и абонентского трафика с регистрацией абонентов на SIP сервере. Поэтому возможность работать одновременно в двух режимах важно.

Раз уж в самом начале статьи упомянут тренд на виртуализацию, давайте сразу говорить и о том, что все описанное в статье, касается и виртуальных решений в том числе. Таким образом вопрос о возможности виртуальных SBC заменять специальные аппаратные комплекcы должен отпасть сам собой. Конечно, в этом вопросе есть тонкие моменты, я планирую по этому поводу отдельную статью.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/335194/


Метки:  

Когда IP-адресов будет хватать всем?

Среда, 09 Августа 2017 г. 14:22 + в цитатник
Количество IP-адресов для устройств, доступных в глобальной сети по протоколу IPv4, достигло порядка 4,3 млрд и уже практически исчерпано из-за длины IP-адреса в 32 бита. В адресном пространстве IPv6 задействовано 128 бит, что делает практически бесконечным количество адресуемых устройств. Прямой и простой совместимости друг с другом у протоколов IPv4 и IPv6 нет. Именно из-за этого быстрого и дешевого перехода на IPv6 only не будет. Страшно? Да нет. Просто нужно вступить на эту дорогу — и рано или поздно мы войдем в эру «чистого» IPv6. Хорошо это или плохо?

image

Недавно у абонентов МТС Центрального федерального округа появилась возможность опробовать выход в интернет с использованием IPv6. За одну сессию по этому протоколу абоненту выдается адресация сразу в двух стандартах: IPv4 и IPv6. Такой режим называется Dual-Stack. Для того, чтобы ваше устройство работало с IPv6, необходимо подключить бесплатную услугу «Доступ к IPv6», а также произвести некоторые настройки на абонентском терминале. В этом посте подробнее о новой услуге расскажет наш специалист Олег Ермаков, его ник на Хабрхаб — eov. Передаем ему слово.

Всем привет! Мой рассказ будет состоять из двух частей. Первая описывает пользовательские настройки и способы контроля, что все у вас идет по плану. Вторая — уже дает краткий экскурс в технологию: как это сделано на сети сотового оператора в поле «3GPP-access». Сегмент «non-3GPP» затрагиваться не будет. Это тема для отдельной статьи.

Часть I

В результате перехода на новый протокол абонент имеет следующее:

1. Сервисы, которые работают с IPv6 адресацией, будут получать и передавать трафик БЕЗ использования NAT. Не знаю, все ли сталкивались с тем, что на поисковый запрос в Google иногда требуется ввести Captcha-код, или Google вообще отказывает в поиске. Причина в том, что Google считает, что с одного public IP идет слишком много запросов, и это воспринимается им как роботизированный опрос.

image image

2. Абонент получит public IPv6 адрес, и на него будет доступен «входящий» трафик из интернета. Сейчас же из-за применения NAT сделать это не просто.

3. Абонент, который «раздает» интернет, получит возможность на каждое устройство, которое находится за «раздающим», иметь свой IPv6 адрес. Предлагаю обсудить плюсы и минусы этого в комментариях…

Не скрою, что от перехода на IPv6 выигрываем и мы (оператор): чем больше абонентов перейдет на IPv6, тем меньше потребуется IPv4 адресов для NAT/PAT трансляций. Уверен, что 99% абонентов не задумывается о том, что в итоге финансовые затраты на закупку дополнительного пространства IPv4 понесут именно они.

Предвижу вопрос: «Когда данная услуга станет доступна абонентам всей страны»? Отвечаю. Мы работаем над этим и постараемся запустить на большей части сети доступ до конца лета этого года.

На нашем сайте есть инструкция настройки, там расписаны общие положения. Дополнительно хочу пояснить несколько моментов:

1. Пока Dual-Stack работает только на устройствах с ОС Android, Windows и на некоторых роутерах. В ближайшее время IPv6 можно будет включить и на мобильных устройствах Apple. Однако, для обеспечения работоспособности с устройствами на iOS нам нужно пройти ряд дополнительных тестов. Прошу отнестись к этому с пониманием и набраться терпения. Пока получить IPv6 на устройствах Apple можно путем подключения к «мобильной точке доступа» с работающей услугой IPv6 через Wi-Fi.

2. На текущем этапе услуга ориентирована в первую очередь на продвинутых пользователей, которые понимают, что и зачем делают. Вы приобщаетесь к высоким технологиям, а мы изучаем ваш клиентский опыт, что на данном этапе крайне важно. Мы рассчитываем получить отзыв пользователей, доработать и усовершенствовать услугу. В дальнейшем мы планируем упростить подключение и отказаться от «услуги» как таковой и сделать функционал IPv6 доступным в настройках телефонов по умолчанию «из коробки». В идеале переход на IPv6 в мобильных сетях МТС планируется бесшовным.

3. В настройках подключения в ОБЯЗАТЕЛЬНОМ порядке нужно указать APN internet.mts.ru и тип протокола IPv4v6 (это ВАЖНО). Основным признаком верного указания APN является то, что абоненту выдается IPv4 адрес из диапазона 10.0.0.0/8 RFC1918, а не из диапазона 100.64.0.0/10 RFC6598. Если же в настройках телефона выбран протокол IPv4 или IPv6, то сеть выдаст ровно то, что и запрошено (IPv4 ИЛИ IPv6). В первом случае все будет работать по IPv4, а во втором — бОльшая часть интернет-ресурсов станет недоступна просто потому, что далеко не все перешли на IPv6. Если все сделано правильно, то будет выдано два адреса IPv4 и IPv6 (Dual-Stack). Мы пока намеренно не планируем распространять решение на «неверные настройки» (с неверным APN). Поступая таким образом, мы исходим из принципа «не навреди».

4. Для доступа к интернет-ресурсам в IPv6-адресации необходимо, чтобы и система DNS работала как положено. Для абонентских сессий с IPv4v6 выдается и IPv6 DNS сервер. Наличие IPv6 DNS серверов не обязательно, потому что и IPv4 сервера успешно резолвят AAAA записи. При подключении к сети мы выдаем оба сервера исключительно для того, чтобы все было «по фэншую».

5. Обратите особое внимание на то, что абоненту выдается public IPv6 адрес (на самом деле блок адресов /64), который доступен из сети интернет! Не стоит пренебрегать элементарными мерами безопасности. Крайне желательно установить антивирус и Firewall.

Таким образом, абоненты имеют IPv4 и IPv6 адрес. Резолвинг интернет-ресурсов осуществляется и по IPv4, и по IPv6. Дело за приложениями. По нашему опыту, браузер Google Chrome в первую очередь использует протокол IPv6 для ресурсов, которые имеют возможность работать по IPv6. Например, такие популярные ресурсы как Yandex и Google уже давно работают по IPv6.

Для проверки можно использовать ресурс test-ipv6.com. Если все настроено верно, то тест покажет оценку 10 из 10.

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

image

Часть II

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

IPv6 как таковой появился в 1998 году и описан в RFC2460, поддержка IPv6 в мобильных сетях появилась в рекомендациях 3GPP Rel99 (2000 г). Широкого распространения технология не получила. Вероятно, тогда мало кто в мире знал, что такое IPv6, а недостатка в IPv4 адресах не предвиделось. Спустя 10 лет острой необходимости так и не возникло, поэтому мы проводили внутреннее тестирование, но внедрять не стали.

Начиная с 3GPP Rel8 для сетей LTE возникает эпоха Dual-Stack. Преимущества — налицо. Dual-Stack делает ненужными такие технологии как NAT64 и DNS64, при сохранении «обратной совместимости» с сетями на IPv4, по сути, делая плавный переход между технологиями.

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

image

Дальнейшее развитие Dual-Stack получило в 3GPP Rel9. В нем появилась поддержка для сетей 2G/3G и в нем же появилась возможность выдавать IPv4 и IPv6 адрес в рамках одного PDP контекста (bearer-а). Именно эта технология и применяется на сети МТС.

image

Если заглянуть чуть глубже, можно сказать, что 3GPP Rel10 описывает технологию DHCPv6 Prefix Delegation (DHCPv6-PD). Сейчас необходимость ее использования в мобильной сети неочевидна. Если есть конкретные предложения — пишите в комментариях или в личку.

Для того чтобы технология заработала, была включена поддержка необходимого функционала на сетевых элементах HLR/HSS, SGSN/MME, GGSN/PGW, PCRF, OCS, CDR-коллектор, ну и, конечно, на транспортной сети.

image

HLR/HSS
Подключение услуги приводит к тому, что в HLR и в HSS меняется тип протокола в настройках APN-а с IPv4 на IPv4v6 (или both). В спецификации TS 29.272 (Rel9) дословно говорится следующее:

7.3.62 PDN-Type...
7.3.62 PDN-Type
The PDN-Type AVP is of type Enumerated and indicates the address type of PDN. The following values are defined:

IPv4 (0)
This value shall be used to indicate that the PDN can be accessed only in
IPv4 mode.

IPv6 (1)
This value shall be used to indicate that the PDN can be accessed only in IPv6 mode.

IPv4v6 (2)
This value shall be used to indicate that the PDN can be accessed both in IPv4 mode, in IPv6 mode, and also from UEs supporting dualstack IPv4v6.

IPv4_OR_IPv6 (3)
This value shall be used to indicate that the PDN can be accessed either in IPv4 mode, or in IPv6 mode, but not from UEs supporting dualstack IPv4v6. It should be noted that this value will never be used as a requested PDN Type from the UE, since UEs will only use one of their supported PDN Types, i.e., IPv4 only, IPv6 only or IPv4v6 (dualstack). This value is only used as part of the APN subscription context, as an authorization mechanism between HSS and MME.

Как Вы уже догадались, мы используем опцию 2.

SGSN/MME
Настройка этих устройств для поддержки IPv6 несложная, она, по сути, ограничивается активацией соответствующей лицензии и включением поддержки dual-address-pdp для сервисов SGSN и MME, а также в настройках RNC, подключенных к SGSN.

PGW/GGSN
Уже не все так просто. Модернизации подвергаются:
— интерфейсы в сторону транспортной сети (поднимается address-family ipv6), и прописывается IP маршрутизация;
— прописываются ip-pool, из которых абонентам выдаются адреса;
— активируется поддержка IPv6 на APN;
— прописывается IPv6 DNS, который будет выдаваться абоненту при подключении.

PCRF/OCS
Обмен PGW c PCRF и OCS производится по протоколу Diameter (интерфейсы Gx и Gy соответственно). Особенность активации IPv6 только в том, что в этом сигнальном обмене появляется AVP Framed-IPv6-Prefix и добавляется еще одна AVP PDP-Address c IPv6 адресом. Соответственно, PCRF и OCS должны их принимать и учитывать (сохранять).

CDR-коллектор
Ожидаемо, что изменился формат CDR записей. Абонентский IPv4 адрес переместился в новое поле servedPDPPDNAddressExt, а IPv6 адрес будет записываться в servedPDPPDNAddress (это поле изначально поддерживало и IPv4 и IPv6).

recordType...
recordType PGWRECORD
servedIMSI 25001**********
p-GWAddress 213.87.x.x
chargingID 15934348563
servingNodeAddress 213.87.x.x
accessPointNameNI internet.mts.ru
pdpPDNType IPV4+IPV6
servedPDPPDNAddress 2a00:1fa0:800::5c:7ef:201
servedPDPPDNAddressExt 10.21.12.11
servinggNodePLMNIdentifier 250, 01
servedIMEISV 35915***********
rATType eUTRAN
mSTimeZone +03:00,

Транспортная сеть
Поднимается address-family ipv6 и прописывается маршрутизация.


В заключение я хочу задать вам вопрос.
Должны ли операторы закрывать доступ из сети интернет (в случае IPv6 и от других абонентов) к TCP/UDP портам диапазона 0-1023 к абонентским устройствам?

Проголосовало 123 человека. Воздержалось 24 человека.

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

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334610/


Метки:  

Разбор доклада Артёма Гавриченкова о масштабировании TLS

Среда, 09 Августа 2017 г. 14:08 + в цитатник
Сегодняшняя статья посвящена докладу про безопасность. Это рассказ Артёма ximaera Гавриченкова «Масштабируя TLS», который был представлен на Highload++ в ноябре 2016 года:




Слайды можно найти тут.

Disclaimer: про сертификаты и TLS только разбираемое выступление, а не сама статья.

Сюжет


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

Постановка задачи


Основная часть рассказа (та, из которой уже непосредственно можно делать выводы и извлекать рекомендации) начинается в районе 9:40. Мне кажется, что к этому времени зрителю всё ещё не вполне понятно, о чём конкретно в докладе пойдёт речь, и это проблема. Cрывы покровов про то, кому принадлежат центры сертификации и почему им до сих пор «доверяют», начинаются примерно там же историей про WoSign. После этого сюжет уже не отпускает, а вот вводную часть я предложил бы сократить.

В самом деле, в начале доклада изложена новейшая история шифрования, упомянуты влияние на ранжирование Гугла, статистика Mozilla и Let's Encrypt, обнаруженные уязвимости на уровне протоколов, а также есть критика в адрес OpenSSL и GNU TLS. Объединяющая идея — технологический долг, а его главная составляющая — недостаток базовой информации у пользователей, о чём вам и расскажет… Это выглядит не вполне логично: редко случается, чтобы просветительскую деятельность связывали с возвратом технологического долга.

Привести зрителей к теме ликбеза можно было иначе, в частности, после упоминания Гугла и заботы о пользователях можно сразу перейти к «допустим, вы в первый раз задумались о том, чтобы внедрить шифрование, какие же задачи вам предстоит решить?»

Многие элементы информации, упомянутые во введении, терять жалко, но они естественно переносятся в другие секции. В частности, про Let's Encrypt, рост числа тех, кто им пользуется и краудфандинговую кампанию можно отлично рассказать в конце пункта «у кого купить сертификат».

Примеры


Примеры — одна из тех вещей, которые делают этот доклад интересным и достаточно простым для восприятия. Хочу отметить, что тут Артём всё делает отлично, и призвать читателей брать с него, да, пример.

Обратите внимание, что истории конкретны и содержат детали. У каждой ошибки, как известно, есть имя, фамилия и отчество, и в докладе они по возможности приведены. GlobalSign в октябре 2016 года проводил технические работы по перекроссировке корневых и промежуточных сертификатов и случайно отозвал все свои промежуточные сертификаты — здесь довольно много деталей, и это хорошо. Конкретные детали, даже если они не принципиальны для понимания сути, придают рассказу убедительности. Если подробности не отнимают много времени, не надо раздумывать, включать их в рассказ или нет. Включать, однозначно.

Если пример масштабен (в случае с GlobalSign проблема коснулась таких сервисов, как Wikipedia, Dropbox, Spotify), это придаёт ему веса.

Парадоксальность примеров (когда первая мысль — WTF?) делает всё выступление более запоминающимся. В нашем случае истории про WoSign и про AES 128 / 256, пожалуй, укладываются в это определение. Последняя история ещё отлично ложится на стереотип о том, что «военные все тупые», который, независимо от реального положения дел, довольно крепко сидит в головах у многих из нас.

Поведение докладчика


Только не подумайте запятая что я читаю по бумажке


Имеет смысл прокомментировать листы с заметками, которые Артём держит в руках. Была пара отзывов от зрителей, которым это не понравилось, но я считаю, что тут всё хорошо. Многие люди с таким же успехом делают себе заметки докладчика в PowerPoint, Keynote или что у вас там. Кому-то удобнее бумажный носитель, некоторые люди до сих пор книжки читают бумажные. Важно лишь то, что докладчик должен обращаться к аудитории, а не к своим заметкам. Залипать в экране-суфлёре ничем не лучше, чем залипать в своих бумажках, зрители это замечают одинаково легко. Артём почти всё время смотрит в зал и говорит со зрителями, так что, на мой взгляд, распечатки докладу не вредят.

Слайды


Самодостаточность


Я исхожу из убеждения, что слайды — лишь сопроводительный материал, который помогает показывать то, что зрителям нужно именно увидеть, а также помогает не сбиться с мысли, если рассказ сложный. У Артёма явно прослеживается (подробнее об этом ниже) попытка сделать слайды самодостаточными, т.е. такими, которые можно просмотреть и получить примерно ту же информацию, что и от посещения живого выступления.

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

Рассмотрим несколько примеров того, что можно безболезненно сократить (список не исчерпывающий).

Слайд 26:



У WoSign грехов на три расстрела. Возможно, некоторые из них для сокращения объёма стоит опустить. Кроме того, я бы вынес ссылку на CA:WoSign_issues в заголовок слайда. Это применимо не только здесь, но и на некоторых других слайдах: если у нас есть только один буллет первого уровня, а под ним россыпь подпунктов, то лучше этот буллет вынести в заголовок.

Слайд 33:



Про банки точно достаточно сказать голосом.

Кстати, слайды 33-34 на видео отличаются от опубликованных на сайте конференции. Это нормально, но я хочу привлечь внимание к слайду 34 из ролика (появляется на 18:05):



Здесь, кроме банков, есть ещё и два экземпляра «more on that later», которые на слайде совершенно не нужны.

Слайд 59:



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

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

Последовательный показ и сохранение контекста


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



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

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

Регулярные разборы


Если вы хотите получить обратную связь по своему выступлению, то я с радостью вам её предоставлю.

Что для этого нужно?
  • Ссылка на видеозапись выступления.
  • Ссылка на слайды.
  • Заявка от автора. Без согласия самого докладчика ничего разбирать не будем.

Всё это нужно отправить хабраюзеру p0b0rchy, то есть мне. Обещаю, что отзыв будет конструктивным и вежливым, а также осветит и положительные моменты, а не только то, что надо улучшать.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/331186/


Метки:  

ИТ на стадионе «Открытие Арена». Когда адреналина в проекте не меньше, чем во время матча

Среда, 09 Августа 2017 г. 14:04 + в цитатник
В составе команды специалистов ЛАНИТ я участвовал в проекте создания ИТ-инфраструктуры стадиона «Открытие Арена». В этой статье я кратко расскажу о проблемах, с которыми мы столкнулись, как их решали, почему делали именно так, и как все это работает спустя три года после начала эксплуатации.




Игра навылет


Стадион «Открытие Арена» – нечто среднее между торговым центром, гостиницей и аэропортом. Он рассчитан на 45 тысяч болельщиков. Это сравнимо со средней пропускной способностью аэропорта Пулково в сутки. Чтобы попасть на стадион, эти 45 тысяч человек должны пройти через турникеты, оборудованные билетно-пропускной системой. Билетно-пропускная система работает через ЛВС. Сбои ЛВС или самой билетно-пропускной системы означают давку у турникетов и прочие неприятности.

Гости на стадионе бывают четырех типов: фанаты, более спокойные любители футбола (так называемая категория «Публика»), VIP и СМИ. Журналистам нужен Wi-Fi и проводной доступ в интернет. Им важно как можно быстрее отправить репортаж в редакцию, так что в случае малейших проблем с интернетом они сразу же устраивают скандал.


Места для СМИ

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

В VIP-зоне за дополнительную плату можно снять скай-бокс – отдельное помещение с видом на поле, баром, официантами и собственной ложей на трибуне. Там тоже работает Wi-Fi и висят телевизоры. Аренда скай-бокса стоит дорого, поэтому и здесь любые проблемы с Wi-Fi и телевизорами однозначно обернутся претензиями в адрес стадиона.


Статистика потребления интернет-трафика на стадионе «Открытие Арена» за месяц. Наиболее активные потребители — СМИ и офис футбольного клуба «Спартак».

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

Космос как предчувствие


В январе 2012 года стадион пригласил нас поучаствовать в конкурсе на СКС, ЛВС, АТС, серверную инфраструктуру, систему коллективного приема телевидения (СКПТ) и систему видеорекламы (Digital Signage). Туда же входил Wi-Fi, но этой теме мы посвятим отдельный пост. Чтобы победить в конкурсе, надо было выполнить два простых условия: предложить наиболее оптимальное по цене решение и доказать, что оно будет безотказно работать во время мероприятия.

Так выглядел стадион в декабре 2012 года, когда мы начали проектирование


В качестве исходных данных было техническое задание на три листа и куча проектной документации разной степени вменяемости. ЛВС и Wi-Fi были спроектированы на Cisco.

Запомнилось, что коммутатор Cisco Catalyst 6509 шел в спецификации без интерфейсных плат, трансиверов, лицензий, блоков питания и SMARTNETов. Cisco для этого проекта подходил, но не давал преимуществ в цене, так что решили заменить его на аналог от Huawei.

Результат получился дешевле и не уступал Cisco в надежности эксплуатации. Конечно, аналог от Huawei мог немножко покапризничать в ходе пуско-наладки и уступал Cisco в ассортименте доступных руководств по администрированию. Так и получилось, но в угоду оптимизации капитальных затрат с этим пришлось смириться.

Начали думать, как без ущерба для надежности сэкономить на серверах, СХД и оборудовании бесперебойного питания. Нам позвонили из российского представительства Huawei и предложили рассмотреть линейку ИБП UPS2000 с двойным преобразованием, X86-серверы Huawei Tecal и СХД OceanStor. В 2012 году для России это было совершенно незнакомое оборудование, особенно когда речь шла о UPS2000.

Так получилось решение с эксклюзивным железом, в котором ЛВС, Wi-Fi, серверы, СХД и даже ИБП были от одного вендора. В 2012 году ни с каким другим вендором осуществить эту идею было нельзя (сейчас из известных вендоров можно еще на HPE и DELL, но на DELL – вообще экзотика).


В двух дальних стойках — ИБП Huawei 2000 для серверных помещений. Фактически это три ИБП мощностью 15КВА каждый. Суммарная мощность составляет 45КВА. Oceanstor 5500С — слева.

Вопрос о надежности решили следующим образом. Поскольку опыта эксплуатации предлагаемого оборудования Huawei в России не было, ЛАНИТ пришлось поставить на кон свою 25-летнюю репутацию.

По условиям контракта, если в течение 5 лет с момента ввода в эксплуатацию заказчика не устраивает надежность того, что мы предлагаем, мы забираем оборудование себе, ставим что-то другое и платим за это самостоятельно.

В принципе, с Huawei можно было зайти еще дальше — взять АТС eSpace, Digital Signage vSpace, и сделать на Huawei вообще все, кроме лотков и СКС. Но не сложилось. vSpace не подошло по функционалу (об этом – чуть ниже), а по АТС выбор в итоге пал на Ааstra (бывшая Ericsson, ныне Mitel Networks). Заказчик хотел использовать базовые станции IP DECT по всему стадиону, потому нужно было заложить в проект станцию со встроенной поддержкой этого функционала. Наиболее дешевой из рассматриваемых и соответствующих требованиям оказалась Aastra.

Телевизоры и ревность


Стадион – очень ответственный объект, и если вы думаете, что закладывать туда оборудование без опыта эксплуатации в России – большой риск, вы правы. Но давайте поговорим об IPTV/Digital Signage.

Несмотря на внешнее сходство, это совершенно разные по функционалу системы, и на стадионе «Открытие Арена» у меня от них до сих пор ощущение, как от езды на американских горках. Это потому, что по ходу проекта постоянно менялось и количество ТВ-панелей, и чуть ли ни каждый телевизор хотя бы раз перекочевал из системы IPTV в Digital Signage или обратно. Поэтому решили спроектировать обе системы на одной платформе.

Заказчику идея понравилась. Еще ему хотелось с помощью такой системы управлять всеми телевизорами удаленно, обеспечить возможность наложения на ТВ-поток текстовой бегущей строки, поддержку Adobe Flash, пользовательский портал для контента Video-on-Demand и много чего еще. Таким требованиям из известных нам решений соответствовали: Cisco Stadium Vision (Cisco Systems, США), Tripleplay (Tripleplay Services, Великобритания) и C-nario (YCD Multimedia, США/Израиль). Для всех троих стадион обещал стать первым проектом подобного масштаба в России.

Начали сравнивать архитектуру решений. Первым с дистанции сошел C-nario. У него фантастический функционал, но в качестве приставок Set-top-box, при помощи которой система подключается к телевизору, предлагались x86-неттопы на базе Windows, что вызывало вопросы к надежности. Еще система на C-nario получилась самой дорогой.

Stadium Vision оказался дешевле C-nario, использовал проприетарные приставки set-top-box с логотипом Cisco на лицевой панели, и это было плюсом, так как в теории они более надежны, чем неттопы на Windows. Однако Cisco немножко ревновала нас к Huawei и всячески намекала на то, что если ЛВС будет не на Cisco, то работать должно, но вендор ничего не гарантирует (до сих пор интересно, почему).

У Tripleplay была принципиально другая архитектура. Англичане гарантировали совместимость с ЛВС любого вендора, а в качестве приставок set-top-box использовали изделия производства компании Amino, которые, в принципе, можно было свободно приобрести в России и использовать не только с Tripleplay. При наличии достаточного количества лицензий любую приставку можно было перевести из режима IPTV в Digital Signage парой кликов мышкой в панели администрирования.

Все это настраивало на более позитивный лад и выглядело бы совсем шикарно, если бы не то, как в Tripleplay предлагалось решать задачу удаленного управления ТВ-панелями.

В принципе, Tripleplay мог управлять ТВ-панелями либо через HDMI (но без гарантии совместимости с конкретной моделью телевизора), либо по RS232, но через переходник USB-RS232 из-за отсутствия порта RS232 у приставки Amino. Нам не подходили оба варианта, поскольку переходников не хотелось, а заказчик утвердил спецификацию ТВ-панелей чуть ли не перед самой закупкой. В результате заказчик выбрал Tripleplay и решил организовать удаленное управление ТВ-панелями на отдельном решении в виде контроллера AMX, который взаимодействовал с телевизорами по ЛВС.

Архитектура IPTV/Digital Signage получилась вот такая:


Реакция на мороз


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


Вот так мы ходили к будущему стадиону зимой 2013 года. Коллеги рассказывали, что видели зайцев, которые прибегали с Тушинского поля.

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


Обстановка нашего проектного офиса на строительной площадке. Фотографировали летом.

С подобной спецификой организации работ приходится сталкиваться очень часто. Со временем ты привыкаешь и перестаешь понимать людей, которые тратят кучу времени на сводные планы прокладки инженерных сетей, BIM-модели, разводку коммуникаций в 3D и прочие вещи, которые совершенно бесполезны на объектах, где постоянно переделываются чертежи, меняются подрядчики, постоянно не хватает времени, и каждую неделю ты делаешь новый план-график.
Кабель мы начали прокладывать, только когда потеплело. Все равно хорошо, что мы заложили в проект кабели, которые рассчитаны на монтаж и эксплуатацию при морозе -40 градусов. Прокладка лотковых трасс по мосткам кровли стадиона оказалась не менее волнительной, так как там очень тесно, скользко и дует сильный ветер с Москвы-реки. Всего за 1 год было проложено 20 километров магистрального кабеля и 300 километров кабеля «витая пара».


Ходовые мостки кровли до начала монтажа слаботочных систем. Монтажники ежедневно проводили на них по 8-10 часов рабочего времени.

Компромисс


Когда закончились строительные работы в серверных помещениях и мы начали монтаж ИБП, всплыла одна пикантная конструктивная особенность UPS2000. В составе изделия шел распределительный щиток с автоматами, который включался между ИБП и блоками распределения питания (PDU) в стойках. Если сравнить номиналы этих автоматов, паспортные токи PDU, и номиналы автоматов вводного распределительного щитка серверного помещения, все это не соответствовало требованиям, прописанным в Правилах устройства электроустановок (они же «библия электриков», или просто ПУЭ). Мы написали об этом в Huawei, они ответили, что хотят посмотреть на все своими глазами. Так у меня состоялись самые странные деловые переговоры за всю мою карьеру.


Вот этот распределительный щиток шел в комплекте с UPS2000.

В серверной появился наш аккаунт-менеджер и три китайца. Мне их не представили, но было видно, что это не инженеры технической поддержки. Самый главный из них носил серый пиджак в клетку и был примерно полтора метра ростом. Два других носили черные пиджаки и были несколько выше главного, чего явно стеснялись. Шумел перфоратор. Воздух был мутным от строительной пыли, и мы стояли возле стоек с ИБП, потому что сесть было некуда. Мой рост – метр восемьдесят. Когда китаец в сером пиджаке говорил со мной, он смотрел на меня снизу вверх и все равно выглядел представительно. Его речь представляла собой смесь китайского и английского языка. Он искренне не понимал, в чем проблема. Я говорил о ПУЭ, принципах селективности автоматов, которые обязаны соблюдать все, кто находится в пределах границ Российской Федерации, но выражение его лица по-прежнему не менялось. Все, что он мне отвечал, тонуло в рокоте перфоратора. Когда перфоратор стих, китаец перешел на русский: «Мы можем поменять решение, но тогда мы за него не отвечаем». «По нашим законам вы и так за него не отвечаете, а отвечаю я как главный инженер проекта», – возразил я. В итоге мы договорились, что вендор приведет решение в соответствие с требованиями ПУЭ.

На самом деле практически все зарубежные вендоры, с которыми мы имеем дело, не всегда посвящены в тонкости российских ГОСТов и СНИПов. В некоторых случаях это грозит полной заменой технического решения. Хорошо, когда вендор это понимает и идет на конструктивный диалог без лишних препирательств и бюрократии.


Ведется монтаж оборудования

Грязные танцы


Чем меньше оставалось времени до окончания проекта, тем ярче становились трудовые подвиги строителей. Бригады маляров и штукатуров все чаще орудовали перфораторами в помещениях с работающими и сосущими пыль коммутаторами. Нависла угроза массового выхода из строя оборудования ЛВС и ЦОД по явно не гарантийной причине. Из положения пытались выйти продувкой «железа» баллонами со сжатым воздухом и даже заклеиванием интерфейсных портов оборудования.


Один из коммутаторов во время пуско-наладки. Порты бесхитростно заклеены малярным скотчем. Если приглядеться, виден слой строительной пыли на верхней панели устройства.

Борьба по SIP


Тем временем заказчик принял решение подключить АТС не по E1, как было в проекте, а по SIP, для чего потребовались пограничные контроллеры сессий. Через месяц после принятия решения на стадион были доставлены два маршрутизатора Huawei AR2240 с платами обработки голоса.

После запуска данные устройства категорически отказались дружить по SIP с Aastra. Смена прошивки не помогла, и мы написали обращение в сервисную поддержку (TAC) Huawei. Сначала инженеры Huawei подключались к AR2240 удаленно, а когда и это не помогло, начались паломничества специалистов вендора непосредственно на объект с целью припадания к консолям маршрутизаторов и тонкой настройки параметров SIP, общее количество которых превышало 100 шт. Все закончилось патчем для ОС AR2240, который был разработан персонально для нашего проекта. После патча SIP заработал, но не так, как хотелось бы. Особенно запомнился баг, из-за которого при звонках с Aastra на номера с автосекретарем (DISA) связь рвалась через 30 секунд. Проблема решилась очередным патчем ПО маршрутизатора.

Про серверы Tecal особо вспомнить нечего – обычные серверы X86. Работали стабильно, к качеству сборки нареканий нет. Заодно познакомились с аналогом iLO у HPE для мониторинга и удаленного администрирования сервера — у Huawei Tecal это называется iMana, и оно вполне неплохо работает.

Две СХД Oceanstor S5500T тоже заработали без особых проблем, в них разве что расстроило тогдашнее отсутствие поддержки кластеризации вроде HP Peer Persistence или NetApp MetroCluster, но нам оно и не пригодилось. В настоящее время Oceanstor кластеризацию поддерживает, технология называется HyperMetro. Про нее есть статья на Хабре вот тут.

Футбол на расстоянии


Под занавес строительства у «Спартака» был запланирован выездной матч. Матч должны были показывать по телевизору в прямом эфире. Заказчик загорелся идеей вывести картинку этой трансляции на видеотабло стадиона, звук – на систему звукоусиления и пригласить на трибуны болельщиков. ТВ-сигнал в прямом эфире предлагалось брать с нашей СКПТ Tripleplay. К этому времени мы почти закончили пуско-наладку.


Видеотабло стадиона «Открытие Арена» во время церемонии открытия. Вполне подходит для просмотра телепередач.

Встала задача интеграции СКПТ, за которую отвечали мы, с системой видеотабло, за которую отвечал один подрядчик, и системой звукоусиления, за которую отвечал другой. Решили интегрировать не напрямую, а через Media Control Room стадиона, за который отвечал еще один подрядчик.

Media Control Room – центральная аппаратная мультимедийных систем стадиона. В ней формируется контент, который выдается на все средства отображения стадиона.

Нужно было как-то снять сигнал с IP-телевидения, подать его на матричный коммутатор Media Control Room’а, отмасштабировать и разделить на видео- и звуковую составляющую. Затем видео отправлялось на контроллеры табло, а звук — на микшерный пульт системы звукоусиления. При этом видео и звук не должны отставать друг от друга.   

В итоге мы приобрели еще две приставки Amino A140, зарегистрировали их в системе Tripleplay и вывели на них ТВ-канал, по которому должны были транслировать матч. HDMI-интерфейс приставок через конвертеры HDMI-SDI включили в матричный коммутатор Media Control Room’а. И все заработало.

Было очень здорово сидеть на трибуне стадиона и смотреть матч по видеотабло площадью 172 кв.м.   

Настоящее продолженное


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

Проект строительства ИТ-инфраструктуры на стадионе «Открытие Арена» занял у нас 2 года. Было проложено 4500 портов СКС, сделана СКПТ на 180 ТВ-панелей, введены в эксплуатацию две СХД на 50ТБ каждая, четыре двухсокетных Rack-mount сервера для платформы виртуализации, 87 точек Wi-Fi, АТС на 250 абонентов и 36 базовых станций DECT.

Стадион стал одним из первых объектов в России, где были применены СХД Huawei Oceanstor, ИБП UPS2000, серверы Tecal и СКПТ/Digital Signage на базе решения Tripleplay. Сегодня ЛАНИТ занимается сервисной поддержкой этих решений. Это опорные решения. За время эксплуатации они успели обрасти другими ИТ-сервисами, в том числе депозитной клубной картой, которую можно использовать как для прохода на стадион, так и для оплаты покупок/дополнительных услуг на территории спорткомплекса.

Ведется активное дооснащение стадиона для приема матчей FIFA в 2018 году. Оно затрагивает и ИТ-инфраструктуру. Причем довольно серьезно, поскольку в 2011 году, когда мы вели проектирование, стадион «Открытие Арена» не планировал участвовать в этом мероприятии.


В руках ИТ-директора стадиона «Открытие Арена» Игоря Шестунова талмуд требований FIFA к стадионам (порядка 900 страниц)

Проект получился довольно успешным. В 2014 году компания Huawei обявила его «Проектом года», а написанный ее инженерами патч вошел в состав следующей версии ОС Huawei AR2240. О надежности оборудования Huawei заказчик также отзывается позитивно, в том числе об UPS2000. Нам так и не представилась возможность оценить работу сервисного центра Huawei по доставке нового оборудования взамен того, что мы обеспыливали, так как за все время эксплуатации ни одно устройство Huawei не вышло из строя.

Нет нареканий и к решению IPTV/Digital Signage от Tripleplay. Положительные рекомендации от ИТ-службы стадиона «Открытие Арена» позволили нам предложить похожее решение для реконструкции стадиона «Лужники», которая закончилась в мае 2017 года.

Приятно, что англичане также учли опыт стадиона «Открытие Арена» и за три года значительно улучшили и без того неплохую систему, в том числе в части архитектуры. На «Лужниках» приставки set-top-box уже не нужны, вместо них используются плееры MagicInfo, встроенные в ТВ-панели Samsung. Удаленное управление ТВ-панелями работает по ЛВС без внешнего контроллера и осуществляется через WEB-интерфейс администратора системы. Мы обязательно расскажем о Tripleplay в одном из наших следующих постов.

Этот проект научил нас не бояться предлагать заказчику новые решения, если они ему действительно подходят, и если вендор, который их производит, готов тебя поддерживать. Все, что мы предложили стадиону и внедрили в 2012-2014 годах, в 2017 году востребовано и работает. Пожалуй, это главный показатель успешности и эффективности данного проекта.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/335242/


Метки:  

Что может и чего не может нейросеть: пятиминутный гид для новичков

Среда, 09 Августа 2017 г. 13:40 + в цитатник
С момента описания первого искусственного нейрона Уорреном Мак-Каллоком и Уолтером Питтсом прошло более пятидесяти лет. С тех пор многое изменилось, и сегодня нейросетевые алгоритмы применяются повсеместно. И хотя нейронные сети способны на многое, исследователи при работе с ними сталкиваются с рядом трудностей: от переобучения до проблемы «черного ящика».

Если термины «катастрофическая забывчивость» и «регуляризация весов» вам пока ни о чем не говорят, читайте дальше: попробуем разобраться во всем по порядку.

/ Фотография Jun / CC-SA

За что мы любим нейросети


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

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

Обучение нейросетей 101


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

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

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

Существует несколько принципиально отличающихся подходов к обучению, в привязке к поставленной задаче. Первый — обучение с учителем. В этом случае входные данные представляют собой пары: объект и его характеристику. Такой подход применяется, например, в распознавании изображений: обучение проводится по размеченной базе из картинок и расставленных вручную меток того, что на них нарисовано.

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

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

Ну и третий вариант — обучение с подкреплением — стратегия, построенная на наблюдениях. Представьте себе мышь, бегущую по лабиринту. Если она повернет налево, то получит кусочек сыра, а если направо — удар током. Со временем мышь учится поворачивать только налево. Нейронная сеть действует точно так же, подстраивая веса, если итоговый результат — «болезненный». Обучение с подкреплением активно применяется в робототехнике: «ударился ли робот в стену или остался невредим?». Все задачи, имеющие отношение к играм, в том числе самая известная из них — AlphaGo, основаны именно на обучении с подкреплением.

Переобучение: в чем проблема и как ее решить


Главная проблема нейросетей — переобучение. Оно заключается в том, что сеть «запоминает» ответы вместо того, чтобы улавливать закономерности в данных. Наука поспособствовала появлению на свет нескольких методов борьбы с переобучением: сюда относятся, например, регуляризация, нормализация батчей, наращивание данных и другие. Иногда переобученная модель характеризуется большими абсолютными значениями весов.

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

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

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

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


Эффект от удаления аномального значения из тренировочного свода данных (источник)

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

Одна сеть – одна задача или «проблема катастрофической забывчивости»


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

Здесь исследователям или приходится тестировать разнообразные архитектуры сетей и выбирать из них лучшую, или использовать динамические нейронные сети. Последние «следят» за изменениями среды и подстраивают свою архитектуру в соответствии с ними. Одним из используемых в этом случае алгоритмов является метод MSO (multi-swarm optimization).

Более того, нейросети обладают определенной особенностью, которую называют катастрофической забывчивостью (catastrophic forgetting). Она сводится к тому, что нейросеть нельзя последовательно обучить нескольким задачам — на каждой новой обучающей выборке все веса нейронов будут переписаны, и прошлый опыт будет «забыт».

Безусловно, ученые трудятся над решением и этой проблемы. Разработчики из DeepMind недавно предложили способ борьбы с катастрофической забывчивостью, который заключается в том, что наиболее важные веса в нейронной сети при выполнении некой задачи А искусственно делаются более устойчивыми к изменению в процессе обучения на задаче Б.

Новый подход получил название Elastic Weight Consolidation (упругое закрепление весов) из-за аналогии с упругой пружинкой. Технически он реализуется следующим образом: каждому весу в нейронной сети присваивается параметр F, который определяет его значимость только в рамках определенной задачи. Чем больше F для конкретного нейрона, тем сложнее будет изменить его вес при обучении новой задаче. Это позволяет сети «запоминать» ключевые навыки. Технология уступила «узкоспециализированным» сетям в отдельных задачах, но показала себя с лучшей стороны по сумме всех этапов.

Армированный черный ящик


Еще одна сложность работы с нейронными сетями состоит в том, что ИНС фактически являются черными ящиками. Строго говоря, кроме результата, из нейросети не вытащишь ничего, даже статистические данные. При этом сложно понять, как сеть принимает решения. Единственный пример, где это не так — сверточные нейронные сети в задачах распознавания. В этом случае некоторые промежуточные слои имеют смысл карт признаков (одна связь показывает то, встретился ли какой-то простой шаблон в исходной картинке), поэтому возбуждение различных нейронов можно отследить.

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

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

Нейронные сети — это лишь инструмент


Само собой, искусственные нейронные сети активно помогают осваивать новые технологии и развивать существующие. Сегодня на пике популярности находится программирование беспилотных автомобилей, в которых нейросети в режиме реального времени анализируют окружающую обстановку. IBM Watson из года в год открывает для себя всё новые прикладные области, включая медицину. В Google существует целое подразделение, которое занимается непосредственно искусственным интеллектом.

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

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

При этом ученые до сих пор не до конца определились, в каком направлении следует развивать нейросети. Индустрия старается как максимально приблизить нейросети к модели человеческого мозга, так и генерировать технологии и концептуальные схемы, абстрагируясь ото всех «аспектов человеческой природы». На сегодняшний день — это что-то вроде «открытого произведения» (если воспользоваться термином Умберто Эко), где практически любые опыты допустимы, а фантазии – приемлемы.

Деятельность ученых и разработчиков, занимающихся нейросетями, требует глубокой подготовки, обширных знаний, использования нестандартных методик, поскольку нейросеть сама по себе — это не «серебряная пуля», способная решить любые проблемы и задачи без участия человека. Это комплексный инструмент, который в умелых руках может делать удивительные вещи. И у него еще всё впереди.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/335238/


Метки:  

Клиент у руля, или почему провайдеру следует передать штурвал

Среда, 09 Августа 2017 г. 13:36 + в цитатник
Изначально наша компания задумывалась как «магазин облачных решений», но затем курс был взят на IaaS. Это было сделано потому, что того захотел рынок — такую потребность выразили пользователи. Почему провайдеру стоит прислушиваться к суждениям клиентов, поговорим далее.

/ Flickr / Carla Wosniak / CC

Находим ориентиры


На одной из своих лекций Олег Тиньков сказал, что стартапам в России нужно просто копировать готовые решения. Такой подход дает возможность быстро вывести продукт на рынок, показать его клиенту, определиться с целевой аудиторией. Он эффективен, потому что позволяет сразу проложить нужный курс и начать движение.

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

Первый дизайн заглавной страницы

Сайт есть, можно начать работу и посмотреть, имеется ли спрос на услуги. Так получилось, что в первую очередь сервисом заинтересовались руководители компаний, хотя мы ожидали увидеть более разнородную аудиторию. Юридические лица стали нашей ЦА — мы перевели фокус с B2C на B2B-сегмент и начали обдумывать пути для улучшения взаимодействия с предпринимателями.

Как только мы разобрались с целевой аудиторией, было решено окончательно отойти от копирования любых UI-решений и «выкатить» что-то свое. Мы переработали внешний вид сайта и избавились от проблемы поиска информации о наших услугах.

Так, старый «штурвал» был брошен за борт за ненадобностью, а его место занял новый:

Один из этапов эволюции дизайна 1cloud.ru

Новый дизайн сайта 1cloud

Улучшаем решение «на ходу»


Чтобы сервис был максимально полезен, важно давать клиенту определенную свободу, возможность самостоятельно «править кораблем». Например, мы внедрили калькулятор для заказа нового виртуального сервера, чтобы пользователь мог самостоятельно настроить параметры системы под свои нужды.

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

Поэтому для переработки UI мы выбрали необходимый минимум, который позволит клиенту определиться с потребностями и ожиданиями по расходам. Последующие изменения дизайна мы производили уже на основе аналитики и внутренних исследований по использованию «железа» за все время работы сервиса. На основании этих данных шло эволюционное развитие нашего калькулятора.

Вариант дизайна калькулятора для заказа виртуального сервера

Новый калькулятор заказа виртуального сервера

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

Правим паруса по ветру


Юзабилити — это здорово, но для хорошего сервиса важно кое-что еще. Например, возможность показать клиентам, что сервис — это не просто «черный ящик». Контролировать происходящее пользователям помогает панель управления, где они могут в реальном времени наблюдать за нагрузкой на серверы: CPU, RAM, СХД и каналы связи.

Окно состояния серверов в панели управления

Анализируя нагрузку на серверы, клиенты самостоятельно «спускают или ставят паруса», подключая или отключая мощности в пару кликов. Сделать это можно и с помощью REST API. Чтобы запустить виртуальную машину достаточно отправить POST-запрос с желаемыми параметрами. Вот один из вариантов:

curl -X POST -H 'Content-Type: application/json' -H 'Authorization: Bearer 75bb9805c018b1267b2cf599a38b95a3a811e2ef7ad9ca5ed838ea4c6bafaf50' "https://api.1cloud.ru/Server" -d '{"Name":"testAPI","CPU":1,"RAM":1024,"HDD":40,"imageID":1,"HDDType":"SSD","IsHighPerformance":true}'

При этом мы тоже видим, в каких пропорциях клиенты используют ресурсы и как распределяют средства. По нашим данным, затраты пользователей на RAM составляют 48,46%, на CPU — 19,28%, а на резервное копирование — 3,39%. Эта информация позволяет находить новые точки роста и улучшения. Например, она используется для проработки параметров тарификации.

С недавних пор клиенты могут управлять и скоростью интернета. Раньше внешний канал, выделяемый серверам, имел гарантированную пропускную способность в 10 Мбит/с. Однако её можно было увеличить при обращении в службу поддержки. Сейчас клиенты могут сами изменять скорость соединения в диапазоне от 10 до 100 Мбит/с через панель управления.

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

Большому плаванию — большая флотилия


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

Развитие сторонних проектов с использованием решений 1cloud (например, API) позволяет оценивать предоставляемые нами услуги с разных ракурсов. Каждый из участников «флотилии» может предложить какие-либо изменения или решения. Это укрепляет взаимоотношения с заказчиками и всю систему в целом.

Исходя из собственного опыта разработки IaaS-провайдера 1cloud, мы можем сделать вывод, что не стоит бояться менять направление развития. Нужно прислушиваться к своим клиентам, давать им свободу, чтобы обеим сторонам было удобно. Например, если клиент понимает, что может управлять своей инфраструктурой самостоятельно, это снижает нагрузку на отдел технической поддержки. Улучшать сервис оказывается намного проще, когда в основе процесса лежит взаимное доверие — компании и клиентов.

P.S. Еще несколько материалов о разработке IaaS-провайдера 1cloud:

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/335246/


Метки:  

[Из песочницы] Практическое руководство по использованию CSS Modules в React приложениях

Среда, 09 Августа 2017 г. 13:15 + в цитатник

Публикация — свободный перевод статьи «Practical Guide to React and CSS Modules». Автор статьи Tatu Tamminen
В прошлом веб-разработчики тратили много времени и сил на создание повторно используемых компонентов. Оcобую проблему представлял собой CSS и природа его каскадов. Например, если разработчик создаёт компонент для отображения древовидной структуры, то как он может гарантировать, что CSS класс (например, .leaf), используемый в этом компоненте, не приведёт к побочным эффектам в других частях приложения? Были созданы различные методологии и соглашения, чтобы справиться с проблемами селекторов. БЭМ и SMACSS — широко используемые методологии, которые хорошо выполняют свои задачи, но в то же время далеко не идеальны. В этой статье рассказывается о недостатках таких методологий, основанных на соглашении об именах, о том, что представляют собой CSS Modules, и о том, как эти модули можно использовать в React приложении.

Проблема с каскадами


Давайте создадим повторно используемый компонент select в качестве примера, иллюстрирующего проблемы глобальных стилей. Стилизация элемента напрямую — это плохое решение, поскольку в других местах сайта нам может потребоваться или изначальный нестилизованный элемент, или совсем другая его стилизация. Вместо этого можно использовать синтаксис БЭМ для определения классов:

.select {}
.select__item {}
.select__item__icon {}
.select--loading {}

Если бы новый класс item был создан без префикса select__, то у всей команды могли бы возникнуть проблемы, если бы кто-нибудь захотел использовать такое же имя item. При этом неважно, разработчик ли пишет CSS или же его генерирует какая-то утилита. Использование БЭМ помогает решить эту проблему, вводя контекст для элемента select.

Синтаксис БЭМ является шагом вперёд по направлению к компонентам, так как «Б» в БЭМ расшифровывается как «Блок», а блоки можно интерпретировать как легковесные компоненты. Select — это компонент, у которого есть различные состояния (select--loading) и потомки (select__item).

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

CSS Modules спешат на помощь


«CSS модуль» определяется следующим образом:
CSS модуль — это CSS файл, в котором все имена классов и анимаций имеют локальную область видимости по умолчанию.

Ключевая идея здесь — локальная область видимости.

Чтобы проиллюстрировать эту концепцию, давайте создадим JavaScript и CSS файлы компонента.

/* select.css */
.select {}
.loading {}
.item {}
.icon {}

/* select.js */
import styles from "./select.css";

console.log(styles.select, styles.loading);

Это простой пример, который, однако, содержит много всего, происходящего за сценой.

Теперь CSS файл содержит намного меньше шума, чем в БЭМ версии, потому что в нём больше нет префиксов и специальных символов, задающих контекст. Почему же стало возможным удалить префикс .select--, не создавая при этом проблем?

Оператор import в JavaScript файле загружает CSS файл и конвертирует его в объект. В следующем разделе мы рассмотрим, как настроить рабочее окружение, позволяющее импортировать CSS файлы.

Каждое имя класса из CSS файла является свойством объекта. В примере выше это styles.select, styles.icon и т. д.

Если имя свойства — это имя класса, то какое же значение у этого свойства? Это уникальное имя класса, и уникальность обеспечивает то, что стили не «протекают» в другие компоненты. Вот пример хешированного имени класса: _header__1OUvt.

Вы можете подумать: «Какой ужас!» В чём смысл изменения осмысленного имени класса на непонятный хеш? Основная причина в том, что такой идентификатор гарантированно является уникальным в глобальном контексте. Позднее в этом руководстве мы изменим механизм создания идентификаторов, так что они будут иметь более осмысленный вид, но при этом останутся уникальными.

Вот ключевые преимущества использования CSS с локальной областью видимости:

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

К недостаткам можно отнести следующее:

  • сложнее читать и понимать DOM,
  • требуется некоторая начальная настройка окружения, чтобы заставить всё это работать.

CSS Modules требуют сборки проекта, но это не проблема, так как различные сборщики поддерживают CSS Modules для JavaScript как на клиенте, так и на сервере. CSS Modules также можно использовать совместно с большинством UI библиотек.

Для простоты в этой статье мы остановимся на сборщике модулей Webpack и библиотеке React.

React, Webpack и CSS Modules


Для быстрого создания приложения можно использовать Create React App.

Следуя инструкциям в документации, мы создадим и запустим новый проект практически мгновенно.

npm install -g create-react-app

create-react-app css-modules  
cd css-modules/  
npm start  

Вуаля, и у нас работающее React приложение:



Начальная страница сообщает нам, что нужно редактировать файл App.js.

import React, { Component } from 'react';  
import logo from './logo.svg';  
import './App.css';

class App extends Component {  
  render() {
    return (
      
logo

Welcome to React

To get started, edit {gfm-js-extract-pre-1} and save to reload.

); } } export default App;

Используются ли CSS Modules в Create React App? Это можно узнать, взглянув на файл App.js. CSS файл импортируется, но не присваивается никакой переменной, при этом во всех атрибутах className используются строки вместо динамических значений.

С этой точки зрения Create React App не поддерживает CSS Modules, так что нужно изменить конфигурацию, чтобы включить эту поддержку.

Настройка Create React App для поддержки CSS Modules


Чтобы получить доступ к скрытому конфигу сборки, нужно выполнить команду eject. Внимание: если вы сделали это, то вернуться обратно вы уже не сможете.
npm run eject  

Теперь можно открыть папку с конфигами для webpack:



Create React App использует webpack для сборки, поэтому webpack.config.dev.js — тот самый файл, который нужно изменить (а также webpack.config.prod.js для настроек продакшна — прим. переводчика).

Найдём раздел, задающий, что делать с CSS файлами (в оригинальной статье используется старый синтаксис конфигов webpack, здесь же я использовал новый — прим. переводчика):

{
    test: /\.css$/,
    use: [
        require.resolve('style-loader'),
        {
            loader: require.resolve('css-loader'),
            options: {
                importLoaders: 1,
            },
        },
        {
            loader: require.resolve('postcss-loader'),
            options: {
                // Necessary for external CSS imports to work
                // https://github.com/facebookincubator/create-react-app/issues/2677
                ident: 'postcss',
                plugins: () => [
                    require('postcss-flexbugs-fixes'),
                    autoprefixer({
                        browsers: [
                            '>1%',
                            'last 4 versions',
                            'Firefox ESR',
                            'not ie < 9', // React doesn't support IE8 anyway
                        ],
                        flexbox: 'no-2009',
                    }),
                ],
            },
        },
    ],
},

Когда мы изменим этот раздел, как показано ниже, то это на мгновение разрушит стилизацию сайта, поскольку будет включена поддержка CSS Modules, но требуются ещё изменения в самом компоненте. При изменении конфига webpack, можно изменить правило именования CSS классов, чтобы в них была и читаемая часть, и хеш для обеспечения уникальности:

{
    test: /\.css$/, 
    use: [
        require.resolve('style-loader'),
        {
            loader: require.resolve('css-loader'),
            options: {
                importLoaders: 1,
                modules: true,
                localIdentName: "[name]__[local]___[hash:base64:5]"
            },
        },
        {
            loader: require.resolve('postcss-loader'),
            options: {
                // Necessary for external CSS imports to work
                // https://github.com/facebookincubator/create-react-app/issues/2677
                ident: 'postcss',
                plugins: () => [
                    require('postcss-flexbugs-fixes'),
                    autoprefixer({
                        browsers: [
                            '>1%',
                            'last 4 versions',
                            'Firefox ESR',
                            'not ie < 9', // React doesn't support IE8 anyway
                        ],
                        flexbox: 'no-2009',
                    }),
                    require('postcss-modules-values'),
                ],
            },
        },
    ],
},

Что делают эти загрузчики loaders? В файле webpack.config есть закомментированная секция, описывающая загрузчики стилей и CSS:
postcss-loader применяет autoprefixer к CSS.
style-loader преобразовывает CSS в JS модули, которые инжектят теги

https://habrahabr.ru/post/335244/


Метки:  

Умные магазины, омниканальная аналитика и бесконечная лояльность: 6 трендов ритейла в 2017 году

Среда, 09 Августа 2017 г. 11:42 + в цитатник


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

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

CRM-based маркетинг и рекомендации


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

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

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

Описанная механика — хороший способ увеличения выручки магазина, ведь если покупателю картофеля понравится рецепт «запеченной картошки с курицей», то ему придется докупить и курицу, и необходимые специи.



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

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

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

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

«Умный» магазин


«Умная» торговля — важный тренд в мире и на российском рынке. Оборудование в современных российских магазинах представляет собой единую систему. При этом каждый ритейлер стремится вписать приобретаемое им оборудование в существующую инфраструктуру так, чтобы получить максимальный эффект от вложения средств.

Один из примеров такого «умного» оборудования — весы, интегрированные с электронными ценниками. При расфасовке взвешенного товара они отображают его стоимость сразу на витрине. Другой пример также связан с весами: использование торговых весов с встроенными экранами позволяет не только решить задачу взвешивания товара самими покупателями, но и в моменты простоя использовать их как маркетинговый инструмент, демонстрируя на дисплее рекламу магазина или информацию о проходящих акциях.



К этому же тренду можно отнести и получающие распространение «умные» прилавки, использующие технологии RFID, iBeacon, электронные ценники и кассы самообслуживания. Они позволяют отслеживать перемещение покупателей по магазину и создавать «карты нагрева». На основе этих данных ритейлер может сделать эффективной выкладку товара, планировать маркетинговые акции, оптимизировать покупательские потоки.

Бесконечная лояльность


Развитие систем лояльности является одним из наиболее популярных трендов. Сложно представить магазин, который не работает с дисконтной или бонусной системой. Особенно это касается non-food сегмента: для таких ритейлеров это едва ли не единственная эффективная возможность бороться с конкурентами за лояльность покупателей.

image

Статистика компании Fivestars говорит, что клиенты кофеен посещают заведения чаще, если те предоставляют им программы лояльности

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

Ритейлеры работают над повышением лояльности и другими способами — например, борются с очередями в часы пик. Для ускорения обслуживания клиентов могут использоваться специальные приложения — с их помощью сотрудник способен обойти покупателей в очереди и просканировать товары в их корзинах. Эти данные могут синхронизироваться с кассовой программой, в результате когда клиент подойдет к кассе, ему останется только оплатить покупку, не выкладывая товар на ленту. Таким образом очереди в магазине движутся быстро, и лояльность покупателей к ритейлеру растет.

Самообслуживание


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



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

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

Умный контроль персонала


Еще один тренд, способствующий повышению эффективности работы ритейлеров, заключается в применении специализированных средств контроля сотрудников. Для этого компании внедряют системы Mobile Workforce Management (MWM). После установки такого решения директору или администратору больше не придется искать сотрудника для постановки ему задачи.

Вместо этого задачи назначаются нужным людям с помощью специального интерфейса — в программе руководитель может дать задание мерчендайзерам — проверить или выложить новый товар, продавцам — оповещать покупателей о новой акции, а грузчикам — принять или погрузить продукцию. На терминалы сбора данных (ТСД) сотрудников будут приходить уведомление о новых задачах — в ответ они смогут отправить подтверждение того, что получили задание и начали работу над ним, а также сигнализировать о ее завершении.

Кроме того, в крупных магазинах актуальна проблема контроля перемещения сотрудников. При наличии сети Wi-Fi можно внедрить систему определения местоположения в режиме реального времени (RTLS). Она способна с точностью до 3-5 метров показывать, где находится тот или иной сотрудник — точнее его ТСД. При «расчерченных» границах рабочих зон при выходе сотрудника за их пределы на длительное время на дисплее администратора торговой точки будет появляться предупреждение.

Терминалы сбора данных полезны и для контроля добросовестности службы охраны. Не редки ситуации, когда сотрудники просто не делают регулярные обходы, хотя должны. Если же в ключевых точка маршрута такого обхода разместить контрольные штрих-коды и обязать охрану при обходе считывать мх терминалом, то схитрить не получится — система будет знать о том, что вместо двух положенных обходов за ночь было сделано меньше.

Аналитика


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

Почему омниканальная аналитика оказалась трендом именно сейчас? В 2016 году многие традиционные ритейлеры внедрили услуги доставки и схему «заказал онлайн — забери офлайн». Беда в том, что они пока не понимают всех выгод и недостатков такого решения. С другой стороны, в технологических решениях, создающихся для ритейла, стали активно использоваться когнитивные вычисления — сочетание искусственного интеллекта, обработки естественного языка и самообучающихся сетей.

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

image

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

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

Будущее: тотальная автоматизация


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

Один из таких проектов — «бета-магазин» компании Hointer, который появился еще несколько лет назад. Он специализировался на мужской одежде, но его главной фишкой стало интегрирование мобильных приложений в стандартный процесс покупки. Такой ход в своё время наделал много шума, что неудивительно, ведь Hointer полностью переосмыслил опыт розничной торговли.

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

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



Изображение: Wired

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



Конечно, в ближайшие несколько лет полностью автоматизированные магазины не вытеснят традиционные, но с каждым годом новые технологии все сильнее будут менять то, как мы совершаем покупки. Торговля будет становиться все более умной и эффективной, как для ритейлеров, так и для покупателей, и это — главная хорошая новость.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/335174/


Метки:  

Как сервис push-уведомлений помог нам сделать более посещаемым портал техподдержки

Среда, 09 Августа 2017 г. 11:38 + в цитатник
Всем привет. Инструмент push-уведомлений сегодня активно используется компаниями в разных целях — для рассылки новостей, оповещений о рекламных акциях и т.д. Мы решили использовать этот канал для коммуникации с пользователями нашего портала технической поддержки, с которыми мы общаемся в helpdesk системе. Сейчас я расскажу, как мы внедрили в тестовом режиме систему push-уведомлений для нашего портала ТП, и к чему в итоге это привело. Моя статья может быть полезна как техническим (сервисным) специалистам, так и руководителям.




Портал техподдержки: что могут пользователи, и как мы с ними контактируем
Для оказания технической поддержки нашего продукта мы используем сайт на основе Zendesk — облачную систему для регистрации тикетов. Пользователи (наши заказчики и партнёры) используют “Портал технической поддержки” не только как место для создания новых заявок, но и как место для обсуждения специфических проблем и своих вопросов.

Так выглядят топики:


Так переписка с пользователями:


Общаться с нами можно через E-mail и веб-приложение:
  • всего на портале зарегистрировано более 4500 пользователей
  • из них активных больше 1000
  • в среднем создается 70 заявок в неделю
  • постоянно в работе около 200 заявок

Новые топики на портале создаются не так часто, как заявки — примерно десяток за 2 дня.

Портал постоянно пополняется новыми материалами, особенно в разделах FAQ, Администрирование Docsvision, База знаний известных ошибок, Объявления, Центр разработчика. Сейчас уведомления о новых материалах приходят пользователям на почту, если они подписаны на соответствующий раздел, и, конечно, отображаются на самом портале. Нам показалось, что этого мало.

Рассматривая новые способы вовлечения аудитории в активности на портале, мы решили провести эксперимент с инструментом push-уведомлений. Он сейчас популярен, удобен и оперативнее других работает в плане оповещения (что и предстояло подтвердить на практике).

Пара слов о сервисе push-уведомлений


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

Вот ключевые характеристики пушей в 2017 году (вообще технология появилась в 2015) для тех, кто не знаком близко с этим сервисом:
Как это работает
  • каждый пуш содержит в себе заголовок и текст
  • пуш приходит пользователям даже при закрытом браузере (полноценная поддержка push notification была анонсирована ещё в 2015 году — мгновенные сообщения от веб-сайтов могут выводиться на рабочий стол даже когда браузер закрыт — (в Google Chrome для этого есть специальный режим, и отдельный режим для расширений и приложений)
  • целесообразно вставлять в пуш ссылку, дабы стимулировать пользователя кликнуть — перейти куда-то — и получить контент
  • многим такие сообщения уже интуитивно знакомы и понятны (например, MS Outlook)


Как подписаться на получение
  1. Пользователь заходит на сайт
  2. Через несколько секунд появляется диалоговое окно с предложением активировать пуш-уведомления с этого сайта
  3. Если получено согласие – при следующей рассылке пользователь получит пуш
  4. Profit!


Сегодня с момента, как мы используем эту технологию, прошло почти 5 месяцев. Мы видим первые результаты и готовы поделиться опытом — возможно, ваша компания тоже захочет воспользоваться этим инструментом и сможет взять из этого материала что-то полезное.

Реализация + цена вопроса


Push (aka web-push) уведомления работают в разных сценариях и платформах. Подписаться и получать уведомления можно из десктопного браузера или браузера мобильной ОС (со смартфона). В данный момент поддержка push-уведомлений реализована более чем на 70% устройств/браузеров.

Выбор платформы (сторонней реализации) или собственной API реализации зависит от ресурсов и времени, которыми вы располагаете.

Полная картина совместимости на данный момент (http://caniuse.com/#feat=push-api):


Вот, как выглядит уведомление в поддерживаемых браузерах (увы, Internet Explorer в пролёте):


Мы воспользовались готовым решением от SendPulse, чтобы посмотреть на технологию: быстро, с минимальными затратами на развёртывание и введение в эксплуатацию.

Что нас привлекло в этом сервисе:
  • в бесплатной версии он ограничен количеством подписчиков, которое нас устраивает
  • довольно простой и быстрый

На реализацию и знакомство с сервисом было потрачено несколько всего человеко-часов вебмастера, PR-менеджера, support-инженера.

Конкретные шаги по внедрению были стандартными:

1. Мы создали отдельный поддомен нашего главного домена docsvision.com, разместили на нём HTML-код по инструкции:


2. Оформили приветственным текстом и запустили в тестовом режиме на группу коллег:


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

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

3. В уведомлении нет ничего лишнего, кроме того, что нужно (плюс есть возможность использовать кнопки и Unicode emoji)


4. Уведомления можно получать (и подписываться на них!) в Windows/MaсOS/Ubuntu/Android

Так выглядит запрос подписки в Chrome на Android:


Уведомление в Android 6.0 из браузера:


В данном случае поддержка версий браузеров нас устраивала (ну а что делать?), основная часть пользователей портала техподдержки сидит на chrome, данные Google Analytics по нашему форуму:


5. Есть возможность A/B тестирования (на Хабре, кстати, была интересная статья про это)

Удобная аналитика


В приложении SendPulse уже есть аналитика из коробки — можно следить за количеством подписчиков по дням/неделям месяцам.

Каждое отправленное push-уведомление формируется в виде «кампании», по аналогии с кампанией рассылки в MailChimp:


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

Важен следующий момент: в отличие от почтовых сайтов или сайтов широкой тематики (техноблоги, развлекательные сайты, новостные порталы), мы на 100% знаем, кто наша аудитория (технические специалисты, инженеры) и готовы рассылать только релевантные для них посты.

Что push'им и когда


Мы решили рассылать push не чаще 2-3 раз в неделю. Для этого в начале недели собирается инициативная группа, которая накидывает свои варианты для рассылки (посты/+новости), и мы за них голосуем.
Пуши решили отправлять после 11 часов и до 14 часов — обычно фокус активности в течение недели/дня приходится на это время.

Разброс по регионам среди посетителей у нас вот такой, данные Google Analytics по нашему форуму на портале ТП:


Исходя из первых 3-х позиций, рассчитываем удобное время для отправки сообщений этим группам: С 11-00 до 14-00 по МСК.

Результаты первого push'a


Оформив все так, как нам нужно, и сделав несколько тестовых рассылок, мы пригласили всех активных пользователей портала ТП воспользоваться нашим сервисом. Как именно пригласили:
  1. Сверстали письмо
  2. Отправили
  3. Посмотрели на CTR (click-through rate)
  4. Отправили письмо тем, кто его не открыл/не перешёл по ссылке, ещё раз

Результаты первого push на пользователей были следующие:
  • 65% доставка онлайн-пользователям в течение 5 минут (общее время жизни push 24 часа)
  • 50% переходов по ссылкам (клик на push и переход на страницу форума)

Если взглянуть на средние показатели посещаемости портала до внедрения push и в момент первого push, то картина следующая:

Посещаемость портала в течение 2 недель июня за 2017 год и в течение 2 недель июня за 2016 год:


Итого:
2016 год – Returning Visitor 87% против 93% в 2017 году.
2016 год – New Visitor 12,3% против 6,1% в 2017 году.

Мы также проанализировали статистику нашего форума по посещениям, комментариям и просмотрам (к сожалению, статистики за 2016 год нет, т.к. у нашего support сервиса сменился движок, но мы сравнили активность форума в месяц с push'ами и в месяц до них).

В период использования push-сообщений:


До внедрения push-сообщений:


Количество просмотров и комментариев не сказать, что значительно увеличилось, но прирост есть.

Мы также заметили, что увеличилось время «удержания» пользователей на портале:


Во-первых, переходы с push-сообщений на портал находятся на 4 месте после прямых заходов и заходов через поисковые системы.

Во-вторых, время, проведённое пользователем портале при переходе по push-сообщению — от 6 до 15 минут (взяли среднее). Те, кто используют пуши, не уходят сразу с портала.

Статистика последних рассылок следующая:


В среднем 30% переходов — это успех для нас, гораздо больше, чем у стандартных почтовых уведомлений с портала, которым ещё надо пробиться через спам фильтры.

C чем мы столкнулись в процессе


Во-первых, мы не сразу заметили, что существуют очень «разные» версии браузеров, которые по-разному воспринимают попытку оформить подписку через push API:
Например, сейчас существует как Opera Stable, так и Developer версия (user agent у них одинаковый) — и у части наших пользователей были проблемы с подпиской на push.

Во-вторых, мы не сразу стали использовать функции авторассылки — эта функция позволяет всем новым подписчикам получать не realtime пуши, а заранее запланированную цепочку — так можно показать подписчикам свои самые популярные материалы.

Вот, как она выглядит:


Были выбраны временные отрезки:
5 минут, 14 часов, 2 дня, т.к. push мы отправляем 2 раза в неделю, и, если подписка случилась после этих двух раз, дабы не было большой паузы, подписчик получает сразу несколько полезных материалов на ознакомление. Отличная фича!

Советы


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

Во-первых: не стоит считать push гарантированным способом доставки информации — увы, пользователь в момент получения push может быть занят и не кликнуть по ссылке (по самому пушу), стоит дублировать все сообщения в других источниках.

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

Рекомендации


  • Сразу тщательно выбирайте поставщика push-сервиса. В случае проблем, переход на другого поставщика может быть затруднителен
  • Рассылайте push в релевантное время — представляйте себе точно, кто ваша аудитория, и в какое время она активна
  • Не рассылайте push слишком много и часто — это может вызвать недовольство
  • Получайте обратную связь

Сразу выбирайте правильного поставщика push сервиса
Этот пункт очень важен. Поставщик push/API/сторонний сервис/приложение для рассылки пушей — в первую очередь, в сервисе/поставщике будет храниться информация обо всех наших пользователях в виде токенов. В этом есть плюсы и минусы:

Плюсы:
Список устройств, на которые мы рассылаем пуши, хранится в виде зашифрованного токена. Токены нельзя импортировать/экспортировать в другие системы, следовательно, нельзя будет спамить пушами, рассылать пуши пользователям без их ведома, и никогда не случится ситуации, в которой человек подписывался на новости компании «Рога и Копыта», а стал получать новости «ООО Эдельвейс».

Минусы:
Если вы найдёте новый сервис для push-рассылок (например, с какими-то интересными для вас фичами), перетащить на него всех своих пользователей будет проблематично.
Придётся заново рассылать им приглашения на страничку подписи в браузере — некоторых это может запутать, или им будет просто лень, или использовать API, но это не всегда возможно.
Этот минус неактуален, если вы используете какой-то свой API для рассылки и храните токены у себя.

Рассылайте в правильное релевантное время

Рассылать пуши, конечно, лучше в «правильное» время, когда CTR будет самым высоким.
Нужно чётко представлять себе аудиторию, в частности, время их активности на вашем сайте/приложении, браузеры, которые пользователи используют.

Вообще по пушам в приложениях/сайтах есть небольшая статистика (по Северной Америке).
На графике (от Leanplum) показано время отправки/открытия пушей в течение дня:


Скачок в промежуток 15-18 часов. О чём это говорит? Лучше отправлять пуши в разгар рабочего дня, при этом многое зависит, конечно, от того, в каком секторе вы работаете.

Не рассылайте слишком много и часто

Push-рассылка должна носить максимально информационный характер и не быть надоедливой. Все в меру. В век всеобщей информатизации дайте своим пользователям немного расслабиться.

Будьте лаконичны, CTR по количеству слов в push сообщений: Источник.


CTR по времени дня:


Получайте обратную связь

Спустя 2 месяца после внедрения пуш-сообщений – мы озадачились вопросом «а все ли возможные пользователи подписались?» Составили опросник на тему использования сервиса с такими вариантами ответов:
  • Да, классный сервис, спасибо
  • Что это?
  • Нет
  • Да, и хочу чаще новостей
  • Нет, не понимаю, как им пользоваться, и что он даёт
  • Ваш вариант

Результаты опроса такие: 50% пользователей ответили «классный сервис», 25% из них же сообщили, что хотели бы получать новости чаще. 17% используют более традиционные средства коммуникации и привыкли к ним.

Можно использовать EMOJI

Для нас это стало открытием, но, например, один из больших игроков на рынке push-уведомлений Leanplum рекомендует использовать эмодзи (как в webpush, так и в push для приложений) — такие пуши открывают чаще.
По статистике компании Leanplum, процент открытия возрастает с 2,5% до 4,5% (мелочь, а приятно):


Помните, что на Android push более эффективен, чем на IOS:


Очевидно, это связано с некими ограничениями iOS устройств — браузеры в данной статистике не затрагиваются (просто, чтобы вы знали). Статистика представлена для мобильных операционных систем без привязки к веб-пушам. В целом, запуск пушей на Safari не поддерживается, но можно использовать его в браузере Chrome).

Анализируйте аудиторию

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


Люди в возрасте 13-24 лет примерно на 20% больше интересуются пушами, чем люди от 25 до 44 лет. Увы, данные актуальны по Америке — для России крупную аналитику найти не удалось.
Если смотреть на специфику именно наших рассылок — мы точно знаем, кто наши пользователи, и что им будет интересно. Не будет такого, что маркетолог получает новости техногика, и наоборот. Если вам понадобится рассылать непрофильные новости и сообщения, лучше для этого использовать другие средства коммуникации.

Что ещё можно улучшить

Когда наладите пуш-сообщения, подумайте, о том, что вы ещё не использовали в пушах, например:
  • большие картинки (часто делать не советуем, т.к. полезное экранное место теряется, да и это может отпугнуть пользователя)
  • кнопки для опросов (взаимодействие с пользователями) — на каждую можно повесить свой URL и емодзи

Наши планы


После получения благоприятных отзывов от наших пользователей мы планируем:
  • Перевести push-рассылки из тестового режима в боевой и предлагать подписку ВСЕМ новым пользователям портала helpdesk
  • Расширять аудиторию, нащупывать наиболее интересные темы, на которые наиболее активно реагируют пользователи



Буду рад услышать какие-то новые советы от коллег, у которых есть опыт применения (и получения!) push-уведомлений!
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/335180/


Эти токсичные, токсичные собеседования

Среда, 09 Августа 2017 г. 11:21 + в цитатник


Всё началось, когда автор Ruby on Rails признался миру:

Hello, my name is David. I would fail to write bubble sort on a whiteboard. I look code up on the internet all the time. I don't do riddles.

— DHH (@dhh) February 21, 2017


К нему присоединились и другие разработчики:

@dhh Hello, I'm Rebecca. Whiteboards suck. I can't hold a marker for over a few minutes, I can type nonstop. I wrote Bard's Tale III.

— Rebecca Heineman (@burgerbecky) February 28, 2017

Один из самых старших инженеров Google сказал, что ни черта не помнит как работает квиксорт:

Hi, I'm Yonatan. I'm one of Google's most senior engineers, and I'll be damned if I can remember how quicksort works. https://t.co/yvofJHgCvG

— (((Yonatan Zunger))) (@yonatanzunger) March 1, 2017

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

Подобный флешмоб может показаться вам глупостью, но служит он важной цели: продемонстрировать всем и каждому, что ни во что не ставить подобные собеседования — нормально. Это рвёт спираль молчания.

Как появилась эта статья


Для меня, как и для многих других, собеседования регулярно были болью. (А когда-то мне ещё и страшно было на них ходить.)

Я написал этот программный материал прежде всего из собственного опыта: приходилось много собеседоваться в своей жизни (стартапы, переезды). В процессе подготовки статьи много спорил с самыми разными разработчиками по обе стороны баррикад — как с кандидатами, так и интервьюерами. Сейчас я в том числе уже сам собеседую других людей в свои проекты и применяю полученный опыт. У меня сформировалась определённая позиция в этом вопросе, которой я хочу поделиться.

О каких именно собеседованиях речь


  • викторины («Какая функция библиотеки X обладает особенностью Y?»)
  • головоломки («Вас уменьшили до размеров 5-центовой монеты и бросили в блендер. Ваш вес уменьшился так, что плотность вашего тела осталась прежней. Лезвия начнут вращаться через 60 секунд. Ваши действия?»)
  • вайтбоардинг («whiteboarding» — когда код требуется писать на маркерной доске)
  • алгоритмические («Разверните бинарное дерево на бумажке»)

.@mxcl Didn't you know? Being able to memorize & recite your algo homework for the last 4 years is more important than building real things.

— Shayan Mohanty (@shayanjm) June 10, 2015

Чем вредны подобные собеседования


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


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

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

Самые замечательные разработчики, которых я встречал — нёрды и гики. Им нужны спокойные условия. Им нужно состояние потока. В лучшие свои времена такой человек за день закодит вам сложнейшую задачу. Если вы всё ещё хотите проверять его на стрессоустойчивость, может, стоит вместо того задуматься, как убрать стресс из своих процессов? (Это даст существенно больше профита.)

Не коррелируют с разработкой


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

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


Предположим, вы очень неплохо знаете некоторую тему, и вдруг по ней всплывает какой-то викторинный вопрос. Ответа вы не знаете. Люди замечают это, и, как правило, предполагают, что вы не знаете ничего по всей теме. (Много хуже, если вы поймали не один неудачный викторинный вопрос, а сразу несколько.)

Mastering the technical interview pic.twitter.com/14RlUgX0zU

— The Practical Dev (@ThePracticalDev) January 12, 2017

Или, скажем, вы пишете код на доске, а синтаксис вылетел из головы. Как это будет выглядеть со стороны — проблема с памятью или с навыками? Неизвестно.

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

Порождают ненужные элитизм и дедовщину


Айти как сфера деятельности по своей природе невероятно подвержена ряду дуростей:

  • культ сложности (Если решение недостаточно сложное или мне было недостаточно тяжело, то что-то не так)
  • элитизм (Я лучше них, я лучше них, я прошёл все искусственные барьеры!)
  • дедовщина (Меня гнобили, и я буду)

Причины здесь разные, и про них можно поспорить. Я рискну сказать, что дедовщина растёт из психологии, культ сложности — из инженерного характера нашего ремесла, элитизм же у айтишников исторический для стран СНГ. Всё это плохие штуки, ведущие к плохим решениям, значит, их стоит выдавливать из себя по капле.

Основные аргументы сторонников Google-style собеседований


«Ведь нужно проверять фундаментальные знания»


Вы так в этом уверены? Кому именно нужно? Здесь всё же не кафедра университета и не олимпиадный кружок, предлагаю вспомнить, зачем вы вообще ищете человека. Правильно. Писать API, проектировать инфраструктуру, рисовать кнопки, чинить баги, понимать задачу из общения с бизнесом, делать продукт дороже и круче. И делать всё это в срок и за деньги.

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

Проекты проваливаются не из-за того, что кто-то не может сделать RB дерево, а от того что люди не умеют общаться и работать вместе.

— Разработчик бэкенда (@backendsecret) April 10, 2017


«Вообще-то это требуется на практике»



Неа, не требуется. Более того: если я как тимлид увижу в репозитории мёрдж-реквест с наколеночным обходом графа или кастомной реализацией квиксорта, я с вероятностью 95% отклоню такой реквест с пометкой чувак, найди готовую библиотеку. Не говоря уже об истовом стремлении написать свою СУБД.

Что же касается каких-то особенностей языка или фреймворка, документация всегда к вашим услугам. (Для поездок на Кубу давно придумали Zeal/Dash).

Далее должна следовать обязательная ремарка про людей, пишущих поисковое ядро Google / Yandex. Но ваши разработчики в их число не входят (You Are Not Google), и прекрасно смогут прочитать про сложный алгоритм в момент, когда он действительно потребуется. Всё даже ещё интересней: в подобных хардкорных командах часто есть такой специальный парень с PhD по математике, который помогает разработчикам с алгоритмами.

«Если разработчик чего-то стоит, он это умеет»


Это вообще не аргумент в контексте проблемы, а скорее попытка утвердить себя во мнении, что вы хороший разработчик (и человек). Оставьте эту попытку, вы хороший разработчик! (Просто, скорее всего, страдаете от синдрома самозванца.) Идите сюда, я обниму вас ^_^

В минуту уныния рекомендую вспомнить Дэна Абрамова, который в своё время не прошёл во Вконтакте:

Я как-то к вам пробовался, но не прошёл ) Очень рад, а то всё по-другому сложилось бы.

— Dan Abramov (@dan_abramov) July 6, 2017


и сотни других подобных примеров (флешмоб #меняневзяли в фейcбуке).

Что важнее, все ваши суждения правильный разработчик должен знать XYZ, скорее всего, являются иллюстрацией ошибки выжившего:

The best software developers I know are always hacking over the holidays.

True story.

— Joe McCann (@joemccann) December 24, 2016

You can start a sentence with "All the best developers I know," as long as you end it with "& that's a great example of survivorship bias."

— Sarah Mei (@sarahmei) December 25, 2016


«Нам тут не тупо кнопки по вьюшке двигать»


Понимаю. Нам тоже. Но вы действительно переоцениваете значимость и уникальность ваших задач. (Я утверждаю это, даже не зная вашей компании: почти все переоценивают.)

«В нашей компании всё часто меняется, поэтому проверяем универсально»


Давайте будем честны: проверить человека универсально невозможно. (IQ-тест был красивой идеей, но провалился). И знание алгоритмов тут тоже слабо помогает.

Насколько часто и насколько сильно у вас всё меняется? Если ваши сотрудники регулярно и кардинально меняют специализацию, то либо вам это зачем-то требуется (допустим), либо стоит задуматься над процессами. В обоих случаях имеет смысл проверять людей на требуемые навыки, а не на абстрактные. (Если iOS-разработчик вдруг стал секретарём, ничего страшного — проверите его на скорость печати.)

Если же изменения не такие значительные и не такие частые — ну, делов-то, выучит человек новый фреймворк. Он же уже доказал вам за это время, что способен работать и учиться.

«У нас такой поток желающих на трудоустройство, что нужны серьёзные фильтры»


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

«Ты же сеешь невежество! Наверное, это из-за того, что ты не осилил алгоритмы!»


Напротив, я хочу принести вам разумное сомнение вместо слепой веры в деревья как работающий фильтр.
Переход на личности с «не осилил» вообще не аргумент, в данной статье я старался разобраться в проблеме по существу.

«Но так было всегда»


… и это ещё вовсе не означает, что существующий порядок вещей правилен.

«Я влёт считаю O(f(n)) и с удовольствием рисую графы на доске. Что же, всё это зря?»


Разумеется, не зря. Никто не отрицает полезность этих знаний. Я лишь утверждаю, что неосмысленно использовать их как интервью-фильтр.

«Но ведь в Google/Facebook/Zalando продолжают так собеседовать, как же туда пройти?»


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

«А что же тогда спрашивать?»


Now we're talkin'! Всё просто: спрашивайте те вещи, которые кандидату придётся у вас делать. Попросите разработчика спроектировать тиндер или убер. Обсудите с ним частые проблемы в работе с очередями, сериализацией, сокетами. Разрешите ему при этом использовать те инструменты, которые он привык использовать.

Valid response to any interview question: "can you tell me an example where you've run into this issue in day-to-day work at the company?"

— Justin Searls (@searls) July 18, 2017
И обязательно смотрите и обсуждайте код, будь то GitHub или нечто, написанное в процессе собеседования.

Кстати, можете добавлять и головоломок/алгоритмов, если очень хочется. Просто учитывайте всё, что написано в данной статье.

Как всё обстоит в EXANTE


Когда я только сюда устраивался, разработчики пригласили меня на продолжительный диалог. Угостили колой, обсудили мои прошлые проекты, подробно рассказали, чем занимается компания. Я задал ряд вопросов по технической части. Было много дебатов на тему «почему в данном случае было такое решение, а не иное». В том числе получил пару вопросов по моему коду в открытом доступе. В конце мне дали задачку из разряда «Как бы вы запроектировали X». Ещё мы периодически смотрели код на лаптопах.

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

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

Кстати, мы регулярно ищем людей: hh.ru/employer/597423. А ещё стараемся не терять их из виду, даже если не можем взять прямо сейчас. И можем по-дружески указать на пробелы, а затем пригласить спустя несколько месяцев.

Менять мир нелегко, но необходимо


Даже когда мы обсуждали проблему в твиттере, среди русскоязычной ветки диалога идея данной статьи была в меньшинстве: на её защиту встали лишь я и ещё один финский CTO. (Новые концепции вообще долетают до СНГ с традиционным запозданием.)

Был такой замечательный венгерский врач-акушер Игнац Филипп Земмельвайс. Ему первому пришла в голову мысль, что 30-50% смертность при родах вызвана инфекциями с немытых рук врачей. И он не просто не нашёл признания: его цензурировали, осмеивали, поместили в психушку. Он умер от избиений. Сейчас же Земмельвайс известен как основоположник асептики и «спаситель матерей».

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

Я хочу, чтобы сегодня вы задумались над тем, как собеседуете.

Материалы для размышления


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/335096/


Метки:  

Как мы ищем (и почему находим) крутых разработчиков. Опыт HR и советы соискателям

Среда, 09 Августа 2017 г. 11:03 + в цитатник


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


Максимальный «выхлоп»


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



Например, сейчас нам нужны спецы, знающие PHP и AngularJS: мы задаем фильтры по этим ключевым словам плюс опыт от 6 лет, находим всех людей, отвечающих нашему запросу, и рассылаем им красивое письмо про нашу крутую платформу Vimbox. Дело в том, что серьезных разработчиков отпугивает слово «школа», они думают, что у нас просто сайт-визитка, и ничего интересного для них, поэтому нам необходимо рассказать им о том, что у нас есть действительно сложные и интересные задачи. По такой рассылке процентов 20 адресатов приходят делать тестовое задание.

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

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

Вообще, выцеплять людей из рушащихся компаний – довольно конструктивно. Например, размещение вакансий на vc.ru необходимо для HR-имиджа компании, но редко дает прямой выхлоп; однако этот ресурс все отслеживают на предмет разоряющихся стартапов, и тут же начинают охоту за головами. Здесь важно вовремя среагировать и поймать нужного человека.


Пример новости на vc.ru, на которую стоит обратить внимание

Остальные источники


Выше перечислены основные, наиболее продуктивные способы поиска нужных людей. Но ограничиваться ими нельзя: другие источники могут обладать совсем маленьким «выхлопом», но и в них случается найти алмазы. Ниже – ресурсы, с которыми у нас есть опыт работы.

* Таргет на FB и во ВК. Запустили недавно, таргетируемся на Украину, Беларусь, Россию по интересам PHP • AngularJS • Symfony • PostgreSQL • Программирование • Стартапы • ИТ и т.п. на мужчин 23-40 лет. Пока поделиться результатами не можем, к тому же объявление ведет на нашу страницу на «Моем Круге», что не очень хорошо, поскольку мы не можем оценить эффективность этого способа. Надо делать свой лендинг.

* Получается найти сотрудников через сайты для фрилансеров типа upwork.com, но случается это нечасто. На этом и подобных ресурсах соискатели заточены на проектную работу; есть риск, что подходящий человек просто не понимает специфики глобальных коммерческих проектов. По таким людям приходится смотреть, работал ли человек в известных компаниях: если да, то ок, если всю жизнь был чистым фрилансером, не работал в команде – наверное, он не наш.

* Недавно разместились на платформе ustart.pro, пока не особо полезный ресурс, только запускается. Там можно разместить страничку с информацией о проекте, чтобы потом давать на нее ссылки, но как инструмент для привлечения сотрудников – не очень.



* Djinni – анонимный поиск работы для разработчиков. Это свалка резюме, мы пишем всем, кто нам подходит. Кто-то покруче здесь может обойтись в 500 евро, джуниора можно найти бесплатно. В целом выхлоп невелик, однако нам удалось найти здесь одного хорошего разработчика (потратили $400).

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

* Есть профильные каналы в Телеграм и Слэк, их кучи, но если туда приходит девочка-рекрутер и постит вакансию, ее сразу закидывают помидорами и грузят техническими вопросами. Лучше попросить разработчиков или тим-лидов закинуть удочки в своих каналах. Это не основной способ найма, но как дополнительный может иногда сработать.

* Мета-поисковик AmazingHiring собирает кандидатов и информацию о них отовсюду – LinkedIn, GitHub, StackOverflow и т.д. – и предлагает контакты; наша задача – писать им письма и добавляться в их соцсети. Несколько раз брали бесплатную тестовую неделю, пока выхлоп нулевой. Но сам проект очень интересный (этот поисковик – бывший внутренний продукт GMS, наиболее адекватного кадрового агентства на рынке IT), надо следить за его развитием и продолжать пробовать.

* Еще один метапоисковик getcoder.io – похоже на AmazingHiring, только дешевле и меньше соотечественников.



* Маловыхлопные ресурсы из ближнего зарубежья – dev.by (совсем печально) и украинский dou.ua (бывают хорошие отклики, но в целом не совсем для нас).

А еще мы выбираем потенциальных сотрудников среди учеников. Если студент указывает, что работает в IT, мы сразу ему что-нибудь предлагаем.

Плюсы и минусы удаленки


Удаленка – с одной стороны, громадное преимущество, ведь далеко не все хотят ездить в офис. Разработчики часто интроверты, легко переживают отсутствие коммуникаций. Но есть и минус: мы часто сталкиваемся с предубеждением, что удаленка – вранье, лохотрон и т.д. Помогают личные письма с разъяснениями задач, с упоминанием известных людей в нашей компании, с которыми предстоит работать. Мы, конечно, не Яндекс, в который часто идут работать из-за престижности имени, но тоже уже заработали какую-никакую репутацию.

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

Где искать работу программисту?


Надо понимать, что хорошие разработчики мало сидят без работы. На них налетает стая рекрутеров еще в тот момент, когда они только начинают задумываться о смене места применения своих талантов. Middle и Senior уровни могут просто спокойно сидеть – их найдут сами через знакомства, через линкед-ин, через лидов; не бывает ситуации, когда хороший разработчик не знает, куда податься.

Абзац выше – почти прямая цитата нашего HR. Из нее видно, что для асоциального разработчика Senior-уровня шанс найти работу, просто разместив резюме на hh.ru и не выполняя тестовое задание, невелик – его там никто не будет искать, а найдя, не поверит, если его имя не на слуху. Между тем, на свете есть крутые разработчики, которые не тусят на конференциях, не ведут блоги и не имеют тысячи подписчиков в Фейсбуке: они просто сидят и делают крутой продукт, например, в технологичной компании из стоматологической отрасли, известной в медицинских, но неизвестной в IT-кругах. Как быть им?

Ответ довольно прост: надо составить список компаний, в которых хотелось бы работать, и связаться с ними. Отправить резюме, а еще лучше постараться таки временно преодолеть свою асоциальность и найти через знакомых какие-то контакты за пределами HR-отдела. Например, в нашем случае можно смело писать со-основателю Харитону Матвееву в Фейсбук – он будет очень рад, и, если вы действительно круты, вы быстро договоритесь, минуя «испорченный телефон». С учетом нынешнего очень серьезного дефицита качественных кадров вероятность успеха такого подхода близка к 1.

Что касается менее опытных людей, то им, во-первых, стоит проследить, чтобы в их резюме, размещенных на сайтах типа hh.ru, содержались все релевантные ключевые слова для поиска и парсинга, а также очертить круг интересных вакансий и компаний и писать в их HR-отделы. Таким кандидатам нужно быть готовым к неоплачиваемому тестовому заданию, как правило, без объяснения ошибок, поскольку компании не хотят раскрывать критерии своих оценок. Кроме того, важно трезво оценивать свои квалификации. Как уже было сказано, рекрутеры общаются между собой, и если вы будете проваливать тесты, можете запороть себе репутацию прямо на старте карьеры. Только изучаете какую-то технологию или инструмент? Так и пишите – такие люди тоже часто бывают востребованы.

И еще пара советов по поводу резюме:



— не забудьте указать почту и занятость; также вы облегчите жизнь рекрутерам, если сразу обозначите желаемую зарплату. Очень полезна ссылка на гитхаб;



— при описании опыта: укажите длительность и компанию (проект). Обязательно напишите, что делали (какие задачи перед вами стояли), какие технологии использовали, какой инструментарий/среда;



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

Отдельная тема – поиск работы за рубежом. Мы думаем написать про это статью, благо среди наших учеников есть те, кто ставит перед собой именно эту задачу и справляется с ней. Оставьте, пожалуйста, комментарий внизу, если хотите прочитать такой текст!
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/335170/


Метки:  

[Перевод] Запросы GraphQL без подключения к сети с помощью Redux Offline и Apollo

Среда, 09 Августа 2017 г. 11:03 + в цитатник

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


А это… не просто.


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


Redux Persist и Redux Offline


За спиной Apollo Client все тот же Redux. А это значит, вся экосистема Redux с многочисленными инструментами и библиотеками доступна в приложениях на Apollo.


В сфере поддержки офлайн у Redux два основных игрока: Redux Persist и Redux Offline.


Redux Persist прекрасный, но дающий лишь основу, инструмент для загрузки хранилища redux в localStorage и восстановления обратно (поддерживаются и другие места хранения). По принятой терминологии, восстановление также называется регидрацией.


Redux Offline расширяет возможности Redux Persist дополнительным слоем функций и утилит. Redux Offline автоматически узнает о разрывах и восстановлениях связи и при разрыве позволяет ставить в очередь действия и операции, а при восстановлении – автоматически воспроизводит эти действия вновь.


Redux Offline – это «заряженый» вариант для работы без сетевого подключения.


Запросы в офлайн


Apollo Client и сам неплохо справляется с краткосрочными перебоями сетевых подключений. Когда сделан запрос, его результат помещается в собственное хранилище Apollo.


Если тот же запрос делается повторно, результат немедленно берется из хранилища на клиенте и отдается запрашивающему компоненту, кроме случая, когда параметр fetchPolicy имеет значение network-only. Это значит, что при отсутствии сетевого подключения или недоступности сервера повторные запросы будут возвращать последний сохраненный результат.


Однако стоит пользователю закрыть приложение, и хранилище пропадет. Как не потерять хранилище Apollo на клиенте между перезапусками приложения?


На помощь приходит Redux Offline.


Apollo держит свои данные в хранилище Redux (в ключе apollo). Записывая хранилище целиком в localStorage и восстанавливая при следующем запуске приложения, можно переносить результаты прошлых запросов между сеансами работы с приложением даже при отсутствии подключения к интернету.


Использование Redux Offline и Apollo Client не обходится без нюансов. Посмотрим, как заставить работать вместе обе библиотеки.


Создание хранилища вручную


Обычно клиент Apollo создается довольно просто:


export const client = new ApolloClient({
    networkInterface
});

Конструктор ApolloClient автоматически создает хранилище Apollo (и косвенно – хранилище Redux). Полученный экземпляр client подается в компонент ApolloProvider:


ReactDOM.render(
    
        
    ,
    document.getElementById('root')
);

При использовании Redux Offline необходимо вручную создавать хранилище Redux. Это позволяет подключить к хранилищу промежуточный обработчик (middleware) из Redux Offline. Для начала просто повторим то, что делает сам Apollo:


export const store = createStore(
    combineReducers({ apollo: client.reducer() }),
    undefined,
    applyMiddleware(client.middleware())
);

Здесь хранилище store использует редьюсер и промежуточный обработчик (middleware) из экземпляра Apollo (переменная client), а в качестве исходного состояния указано undefined.


Теперь можно подать store в компонент ApolloProvider:



    

Превосходно. Создание хранилища Redux под контролем, и можно продолжать с Redux Offline.


Основы персистентного хранения запросов


В простейшем случае добавление Redux Offline заключается в добавлении еще одного промежуточного обработчика к хранилищу.


import { offline } from 'redux-offline';
import config from 'redux-offline/lib/defaults';
export const store = createStore(
    ...
    compose(
        applyMiddleware(client.middleware()),
        offline(config)
    )
);

Без дополнительных настроек обработчик offline начнет автоматически записывать хранилище Redux в localStorage.


Не верите?


Откройте консоль и получите из localStorage эту запись:


localStorage.getItem("reduxPersist:apollo");

Выводится большой объект JSON, представляющий полное текущее состояние приложения Apollo.



Великолепно!


Теперь Redux Offline автоматически делает снимки хранилища Redux в сохраняет их в localStorage. При каждом запуске приложения сохраненное состояние автоматически берется из localStorage и восстанавливается в хранилище Redux.


На все запросы, результаты которых находятся в этом хранилище, будут возвращены данные даже при отсутствии подключения к серверу.


Конкуренция при восстановлении хранилища


Увы, восстановление хранилища происходит не мгновенно. Если приложение делает запрос в то время, как Redux Offline восстанавливает хранилище, могут происходить Странные Вещи(tm).


Если в Redux Offline включить логирование для режима autoRehydrate (что само по себе заставляет понервничать), при первоначальной загрузке приложения можно увидеть ошибки, на подобии:


21 actions were fired before rehydration completed. This can be a symptom of a race condition where the rehydrate action may overwrite the previously affected state. Consider running these actions after rehydration: …
Выполнено 21 действие прежде чем завершилось восстановление. Это признак конкуренции, из-за чего при восстановлении может быть потеряно ранее настроенное состояние. Рассмотрите возможность выполнять эти действия после восстановления: …

Разработчик Redux Persist признал проблему и предложил рецепт отложенного рендеринга приложения после восстановления. К сожалению, его решение основано на ручном вызове persistStore. Однако Redux Offline делает такой вызов автоматически.


Посмотрим на другое решение.


Создадим Redux action с названием REHYDRATE_STORE, а также соответствующий редьюсер, устанавливающий значение true для признака rehydrated в хранилище Redux:


export const REHYDRATE_STORE = 'REHYDRATE_STORE';

export default (state = false, action) => {
    switch (action.type) {
        case REHYDRATE_STORE:
            return true;
        default:
            return state;
    }
};

Подключим созданный редьюсер к хранилищу и настроим Redux Offline так, чтобы по окончанию восстановления выполнялось новое действие.


export const store = createStore(
    combineReducers({
        rehydrate: RehydrateReducer,
        apollo: client.reducer()
    }),
    ...,
    compose(
        ...
        offline({
            ...config,
            persistCallback: () => {
                store.dispatch({ type: REHYDRATE_STORE });
            },
            persistOptions: {
                blacklist: ['rehydrate']
            }
        })
    )
);

Превосходно! Когда Redux Offline закончит восстанавливать хранилище, вызовет функцию persistCallback, которая запустит действие REHYDRATE_STORE и в конечном счете установит признак rehydrate в хранилище.


Добавление rehydrate в массив blacklist гарантирует, что эта часть хранилища не будет записана в localStorage и восстановлена из него.


Теперь, когда в хранилище есть сведения об окончании восстановления, разработаем компонент, реагирующий на изменения поля rehydrate и визуализирующий дочерние компоненты, только если rehydrate равно true:


class Rehydrated extends Component {
    render() {
        return (
            
{this.props.rehydrated ? this.props.children : }
); } } export default connect(state => { return { rehydrate: state.rehydrate }; })(Rehydrate);

Наконец, поместим компонент внутрь компонента , чтобы предотвратить вывод приложения до окончания регидрации:



    
        
    

Уфф.


Теперь приложение будет беспечно ждать, пока Redux Offline восстановит хранилище из localStorage, и только потом продолжит отрисовку и будет делать все последующие запросы или мутации GraphQL.


Странности и пояснения


Есть несколько странностей и требующих пояснения вещей при использовании Redux Offline вместе с клиентом Apollo.


Во-первых, надо заметить, что в примерах этой статьи используется версия 1.9.0-0 пакета apollo-client. Для Apollo Client версии 1.9 заявлены исправления некоторых странных проявлений при работе с Redux Offline.


Другая странность этой пары в том, что Redux Offline, кажется, не слишком хорошо уживается с Apollo Client Devtools. Попытки использовать Redux Offline с установленным Devtools иногда приводят к неожиданным и, казалось бы, бессвязным ошибкам.


Такие ошибки можно легко исключить, если при создании Apollo client не подключать его к Devtools.


export const client = new ApolloClient({
    networkInterface,
    connectToDevTools: false
});

Будьте на связи


Redux Offline дает приложению на Apollo основые механизмы для выполнения запросов даже при перезагрузке приложения после отключения от сервера.


Через неделю погрузимся в обработку офлайновых мутаций с помощью Redux Offline.


Будьте на связи!


Перевод статьи. Автор оригинала Pete Corey.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/335210/


Метки:  

Игра с номерами: как алгоритмическая торговля изменит сферу финансов

Среда, 09 Августа 2017 г. 10:33 + в цитатник


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

Перемена в поведении биржевых игроков становится очевидной, если проследить историю от так называемого метода свечей, изобретенного торговцем рисом Хомма Мунэхиса в 18 веке, до Ричарда Шабакера, который опубликовал книги по техническому анализу в 20 веке. За это время возник новый тип инвестора, вооруженного техническим и фундаментальным анализом, обладающего коммерческой осведомленностью и вниманием к ценности.

В 21-ом веке произошли самые ощутимые изменения. С развитием данных и технологий старый шаблон был разрушен, и возникла новая финансовая экосистема. Действия и поведение людей изменились в ответ на новые рыночные условия. Финансист Глеб Пилипенко на страницах издания The market mogul рассуждает о том, к чему приведет дальнейшее развитие технологий в сфере финансов — мы подготовиоли адаптированную версию этого материала.

Человек против машины


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

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



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

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

«Сбои, подобные тем, что имели место в августе 2015 года, поколебали доверие отдельных инвесторов, которые полагаются на публичные рынки, чтобы диктовать фундаментальную ценность компании» – заявил бывший сенатор США Тед Кауфман.

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

Новый тип инвестора


Механизм защиты, который выбрали розничные инвесторы, оказался столь же передовым, как и сами алгоритмы. Такие сообщества, как Quantopian, WebSim и Quantiacs отказались от мнения о том, что высокочастотный трейдинг – это тайное и монополизированное машинами игровое поле. С тех пор Quantopian стал называться «краудсорсинговым хедж-фондом».

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

Сообщество, вероятно, расширится за счет увеличения финансирования со стороны знаменитого трейдера и владельца хедж-фонда SAC Capital Partners Стива Коэна, который пообещал вложить 250 млн долларов в Quantopian. Подход сообщества позволяет человеку с любым бэкграундом развивать навыки, необходимые для участия в алгоритмической торговле, конкурируя с хорошо зарекомендовавшими себя трейдерами HFT.

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

Недавний пример – 21-летний студент, который благодаря собственной торговой программе превзошел рынок, получив 1,5% прибыли по сравнению с падением индекса S&P на 8%. Такие события показывают, что среди трейдеров нового поколения растет технологическая осведомленность.

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

Основатель и исполнительный директор Quantopian Джон Фосетт заявил, что количество членов сообщества выросло с 35 000 до 60 000 меньше чем за год. По словам Джареда Брэда – основателя и CEO QuantConnect – число участников его ресурса резко выросло до 17 000 с 6 000 годом ранее.

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

Заключение


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

Количественный трейдинг набирает обороты из-за более сильных предпочтений в принятии научного и компьютеризированного подхода. В количественном сегменте, вероятно, будут процветать такие сообщества, как Quantopian.

Традиционные хедж-фонды работают на основе платы за управление активами инвестора, в то время как упомянутые сообщества исключают такие сборы и разделяют прибыль между разработчиком и инвестором.

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

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

Другие материалы по теме финансов и фондового рынка от ITinvest:


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/335230/


Метки:  

[Из песочницы] ML Boot Camp V, история решения на 2 место

Среда, 09 Августа 2017 г. 10:19 + в цитатник

В данной статье я расскажу историю о том, как решал конкурс ML Boot Camp V “Предсказание сердечно-сосудистых заболеваний” и занял в нём второе место.


Постановка задачи и данные


Данные содержали 100 000 пациентов, из которых 70% были в обучающей выборке, 10% для публичного лидерборда (public) и финальных 20% (private), на которых и определялся результат соревнования. Данные представляли собой результат врачебного осмотра пациентов, на основании которого нужно было предсказать, есть ли у пациента сердечно-сосудистое заболевание (ССЗ) или нет (данная информация была доступна для 70% и нужно было предсказать вероятность ССЗ для оставшихся 30%). Другими словами – это классическая задача бинарной классификации. Метрика качества – log loss.


Результат врачебного осмотра состоял из 11 признаков:


  • Общие – возраст, пол, рост, вес
  • Объективные – верхнее и нижнее давление, уровень холестерола (3 категории: норма, выше нормы) и глюкозы в крови (также 3 категории).
  • Субъективные – курение, алкоголь, активный образ жизни (бинарные признаки)

Так как субъективные признаки были основаны на основании ответов пациентов (могут быть недостоверными), организаторы конкурса скрыли 10% каждого из субъективных признаков в тестовых данных. Выборка была сбалансирована. Рост, вес, верхнее и нижнее давление нуждались в чистке, так как содержали опечатки.


Кросс-валидация


Первый важный момент – это правильная кросс-валидация, так как тестовые данные имели пропущенные данные в полях smoke, alco, active. Поэтому, в валидационной выборке 10% данных полей тоже были скрыты. Используя 7 фолдов кросс-валидации (CV) с изменённым валидационным множеством, я рассмотрел несколько различных стратегий улучшения предсказаний на smoke, alco, active:


  • Оставить данные в обучении как есть (в валидации 10% пропущенных значений в smoke, alco, active). Данный подход требует алгоритмы, умеющие обрабатывать пропущенные значения (NaN), например — XGBoost.
  • Скрыть в обучении 10%, чтобы обучающая выборка больше походила на валидацию. Данный подход также требует алгоритмы, умеющие работать с NaN.
  • Предсказать NaN в валидации на трёх обученных классификаторах
  • Заменить признаки smoke, alco,active на предсказанные вероятности.

Также была рассмотрена стратегия взвешивания обучающих примеров по близости к валидации\тестовым данным, которая, однако, не давала прироста ввиду одинакового распределения train-test.


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


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


Корреляция с лидербордом


Интересный вопрос, который всегда волнует участников, это корреляция между CV и тестовыми данными. Уже имея полные данные после завершения конкурса (ссылка), я провёл небольшой анализ данной корреляции. Почти для всех сабмитов я записывал в описание результаты CV. Имея также результат на public и private, построим попарные графики сабмитов для значений CV, public, private (Так как все значения logloss начинаются на 0.5, для наглядности я опустил первые цифры, например 370 – это 0.5370, а 427.78 – 0.542778):



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


Spearman rho CV Public Private
CV 1 0.723 0.915
Public - 1 0.643
Private - - 1

Можно сделать вывод, что введённая в предыдущей секции кросс-валидация хорошо коррелировала с private для моих сабмитов (в течении всего конкурса), когда как корреляция public с CV или private слабая.


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



Модели


В течении данного конкурса я использовал следующие модели с соответствующими библиотеками:


  • Regularized Gradient Boosting (библиотека XGBoost) – основная модель, на которую я опирался, так как в моих экспериментах показывала лучшие результаты. Также большинство усреднений было построено только на нескольких xgb.
  • Neural Networks (библиотека Keras) – экспериментировал с feed forward networks, autoencoders, но не получалось побить свой baseline от xgb, даже в усреднении.
  • Различные sklearn модели, которые участвовали в усреднении с xgb – RF, ExtraTrees, и т.д.
  • Стекинг (библиотека brew) – не получалось улучшить baseline усреднения нескольких различных xgb.

Поэксперементировав с различными моделями, и получая лучшие результаты путём смешивания 2-3 xgb (кросс-валидация занимала 3-7 минут), я решил сконцентрироваться больше на чистке данных, преобразовании признаков и тщательном тюнинге 1-5 различных множеств гиперпараметров xgb.
Гиперпараметры я попробовал искать с помощью Байесовской оптимизации (библиотека bayes_opt), но в основном опирался на случайный поиск, который служил инициализацией для Баейсовской оптимизации. Также, помимо банального оптимального количества деревьев, после такого поиска я старался попеременно подтягивать параметры (в основном регуляризационные параметры деревьев min_child_weight и reg_lambda) — метод, который некоторые называют graduate student descent.


Чистка данных I


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


  • Для давлений вида 12000 и 1200 – разделить на 100 и 10
  • Домножить на 10 и 100 для давлений вида 10 и 1
  • Вес вида 25 заменить на 125
  • Рост вида 70 заменить на 170
  • Если верхнее давление меньше нижнего, поменять местами
  • Если нижнее давление равно 0, то заменить на верхнее минус 40
  • и т.д.

Используя несколько простых правил для очистки, я смог добиться в среднем CV ~0.5375 и public ~0.5435, что показывало совсем средненький результат.
На рисунках изображён последовательный процесс обработки экстремальных значений и выбросов с приходом к очищенным значениям верхнего и нижнего давления на последнем изображении.






В моих экспериментах удаление выбросов не приводило к улучшению CV.


Чистка данных II


Предыдущая чистка данных вполне адекватная, однако, после долгих попыток улучшения моделей я её пересмотрел более тщательно, что позволило значительно улучшить качество. Последующие модели с данной чисткой показали прирост CV до ~0.5370 (с ~0.5375), public до ~0.5431 (с ~0.5435).


Основная идея – к каждому правилу есть исключение. Мой процесс поиска таких исключений был довольно рутинным – для небольшой группы (например, людей с с верхним давлением между 1100 и 2000) я смотрел на значения в train и test. Для большинства, конечно, правило “разделить на 10” срабатывало, но всегда существовали исключения. Данные исключения было проще изменить отдельно для примеров, чем искать общую логику исключений. Например, такие выбивающиеся из общей группы давления, как 1211 и 1620, я заменял на 120 и 160.


В некоторых случаях правильно обработать исключения удавалось, лишь включая информацию с других полей (например, по связке верхнего и нижнего давления). Таким образом, давления вида 1/1099 и 1/2088 заменялись на 110/90 и 120/80, а 14900/90 заменялись на 140/90. Самые сложные случаи были, например, при замене давления 585 на 85, 701 на 170, 401 на 140.
В сложных менее однозначных случаях я проверял, насколько исправления похожи на обучение и тест. Например, случай 13/0 я заменял на 130/80, так как он самый вероятный. Для исключений из обучающей выборки мне также помогало знание поля ССЗ.


Очень важный момент – это различить шум от сигнала, в данном случае – опечатку от настоящих аномальных значений. Например, после чистки у меня осталась небольшая группа людей с давлением вида 150/60 (имеют ССЗ в обучении, их давление вписывается в одну из категорий ССЗ) или ростом около 90 см с небольшим весом.


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


Пользуясь выложенным полным датасетом после соревнования, получаем, что данная очистка затронула 1379 объектов в обучении (1.97%), 194 в public (1.94%), 402 в private (2.01%). Конечно, исправления аномальных значений для 2% датасета была не идеальной и можно её сделать лучше, однако даже в этом случае наблюдался самый большой прирост CV. Стоит отметить только, что после чистки или работы с признаками необходимо находить более оптимальные гиперпараметры алгоритмов.


Работа с признаками и их дискретизация


Изначально возраст был поделён на 365.25, чтобы работать с годами. Распределение возраста было периодичным, где пациентов с чётными годами было гораздо больше. Возраст представлял собой гауссовскую смесь с 13 центрами в чётных годах. Если просто округлить по годам, то улучшалось CV в четвёртом знаке на ~1-2 единицы по сравнению с исходным возрастом. На рисунках показан переход от исходного возраста к округлённому до года.




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




BMI ( индекс массы тела = $inline$вес/(рост/100)^2$inline$) появлялся первым в важности признаков. Добавление исходного BMI улучшало результат, однако, наибольшего улучшения модели достигли после дискретизации его значений. Порог дискретизации был выбран на основании квартилей, а количество определялось на основании cv, визуальной валидации распределений. На рисунках показан переход от исходного BMI к дискретизированному BMI.




Аналогично, к росту и весу была применена дискретизация с малым количеством категорий, а давление и пульс были округлены c точностью до 5.
Поиск новых признаков и их отбор производился вручную. Лишь небольшое количество новых признаков смогли улучшить CV, причём все они показывали относительно небольшой прирост:


  • Pulse pressure — разница между верхним и нижним давлением
  • Нормальное ли давление (85 <= ap_hi <= 125 & 55 <= ap_lo <= 85)
  • Последняя цифра в давлении до округления + перестановка по вероятности ССЗ
  • Аналог чётности года (age — (age/2).round()*2) > 0

Итоговую важность признаков (с дискретизацией) для одной модели xgb можно увидеть на графике:



За час до окончания у меня была довольно простая модель из 2 xgb с использованием последней чистки данных и дискретизации признаков. Код доступен на github ( показывал CV 0.5370, public 0.5431, private 0.530569 — тоже 2 место).


Последний час соревнования


Имея усреднения двух или трёх xgb на последней предобработке данных, я решил попробовать усреднить результаты последних моделей с некоторыми предыдущими (различные преобразования и набор признаков, чистка данных, модели) и на удивление, усреднение с весами 8 предыдущих предсказаний дало улучшение на public с 0.5430-31 до 0.54288. Стратегия с весами была зафиксирована сразу — обратно пропорционально округлённой 4й цифре на public (к примеру, у 0.5431 вес 1, 0.5432 — 1/2, 0.5433 — 1/3), что вполне хорошо коррелировало с тем, что модели с последней чисткой данных показывали также лучшие значения CV. Эти 8 предсказаний были получены с помощью одного, двух, трёх (большинство), а также 9 различных моделей xgb. Все, кроме одной, были на основании последней чистки данных, различаясь набором новых признаков, дискретизацией или её отсутствием, гиперпараметрами, а также стратегией с NaN. Далее, с той же схемой весов добавление сабмитов похуже (с весами меньше 1/4) помогло улучшить public до 0.542778 (всего 17 предсказаний, описание можно найти на github).


Конечно же, по-хорошему необходимо было хранить результаты предыдущих кросс-валидаций, чтобы правильно оценить качество такого усреднения. Могло ли быть здесь переобучение? Руководствуясь тем, что более 90% веса в усреднении было у моделей со стабильными CV 0.5370-0.5371, можно было ожидать, что модели послабее могли помочь в экстремальных ошибках лучших простых моделей, однако в целом предсказания мало отличались от лучших моделей. Учитывая также, что public значительно улучшился, я выбрал в качестве финальных именно два этих усреднения, которое и вылилось в лучшую модель, показавшую 2 место с private 0.5304688. Можно заметить, что простое решение, описанное выше, и которое было базой в данном усреднении, показало бы тоже 2 место, однако оно менее стабильно.


Выученные уроки


Финальное усреднение показало, что использование комбинации относительно простых моделей на разных признаках/предобработке может дать лучшие результаты, чем использование множества моделей на одних и тех же данных. К сожалению, в течении конкурса я искал именно одну «идеальную» очистку данных, одно преобразование признаков и т.д.


Также, для себя я заметил, что кроме частых коммитов в git, желательно хранить результаты кросс-валидации предыдущих моделей, чтобы можно было быстро оценить, смешивание каких различных признаков\предобработки\моделей даёт наибольший прирост. Однако же, исключения к правилам бывают, например, если остаётся лишь час до конца конкурса.


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


В заключение, выступление автора доступно здесь, а презентация также на github.

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/335226/


Метки:  

Уязвимость в Альфа-Банк Украина: получение ФИО клиента по номеру телефона

Среда, 09 Августа 2017 г. 10:09 + в цитатник
Альфа-Банк Украина входит в ТОП-5 по количеству активных карт среди всех украинских банков и имеет довольно неплохой интернет-банкинг My Alfa-Bank.

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

Длительное время функция p2p-перевода по номеру телефона действовала при соблюдении определенных условий: если у получателя подтверждён телефон и оформлена зарплатная (именно зарплатная) карта в Альфа-Банке Украина.

Не так давно, в конце марта этого года, банк реализовал p2p переводы по номеру телефона в интернет-банкинге My Alfa-Bank уже для всех клиентов банка, а не только для «зарплатников».

Я решил протестировать функцию на предмет получения данных о клиенте по его номеру телефона.

Ввожу сумму и номер телефона родственника, у которого открыт счёт в Альфа-Банке, нажимаю «Далее».


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



Конечно, если средства перевести, я увижу полные ФИО получателя.
Но и получатель увидит мои – так что на этом этапе проверка закончена.

Перехожу в последние операции, чтобы посмотреть на детали этого теста:



Ничего интересного – при наведении курсора мыши на такую операцию нет интересующих меня данных.




Позже, в мае, функция переводов между клиентами Альфа-Банка по номеру мобильного телефона появилась и в мобильном приложении.

И я, зная, что работа с мобильными приложениями может быть реализована иначе, решаю проверить это на Android.

Ввожу данные (сумма и номер телефона), ввожу код из SMS и вижу ту же картину: ФИО маскируется.



Хорошо для клиентов, но жаль для меня. Отменяю операцию.

Однако иду проверить данный перевод в последних операциях в web-версии – и да, в деталях платежа, который я проверял в мобильном приложении, отображаются поля «Отправитель платежа» и «Получатель платежа»!



Да, уязвимость найдена.

Таким образом, проблема именно в отображении операций, созданных в мобильном приложении — по номеру телефона можно получать актуальные ФИО клиентов, даже не отправляя им деньги. Таких клиентов может быть до 1,15 млн. (количество активных карт по данным НБУ), но необходимо, чтобы клиент был зарегистрирован в системе.

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

Хронология событий:

30 мая — первое письмо, в котором я указываю ссылку на запароленный документ со скриншотами с детальным описанием проблемы;

07 июня — повторное письмо с вопросом о реакции, получаю ответ: «Опишите проблему в текстовом формате (при необходимости добавьте скрин) для решения вопроса», отправляю ответ;

26 июня — моё повторное письмо с вопросом о том, будет ли исправлена ситуация или нет, и когда. Получаю следующий ответ: «Зафиксированное предложение передается в профильное подразделение для рассмотрения и включения в план дальнейших действий. Реализация зафиксированного предложения зависит от разных факторов: ресурсов, сложности реализации, проектов, которые находятся уже в реализации. По предложениям, которые поступают на банк, обратная связь не предоставляется» – по предложениям? Я же ясно указал, в чём проблема, приложил скриншоты, подсказал решение;

07 июля – естественно, никакого движения, попытался уточнить вопрос через знакомых.
Во время проверки обнаруживается, что теперь ошибка не зависит от платформы и воспроизводится также и в web-версии: теперь для получения ФИО владельца по номеру телефона одновременно использовать приложение и сайт не нужно — узнать ФИО клиента без перевода средств можно просто в интернет-банкинге;

08 августа — пишу в банк, что хочу опубликовать информацию о том, как найденная ошибка не была исправлена банком за несколько месяцев; получаю ответ "Информация предоставлена Вами была передана в соответствующий отдел Банка и получен ответ, что она будет добавлена в backlog, но на данный момент изменения проводиться не будут" и "Отдел разработки не считает, что предоставленная Вами информация повлияет на уязвимость интернет-сервиса, но приняли ее во внимание. Спасибо, что помогаете нам стать лучше. С уважением, Альфа-Банк!".




Итог: с конца мая и на текущий момент уязвимость не исправлена — по номеру телефона можно получить ФИО клиента, не совершая перевода (просматривая детали незавершённой операции в интернет-банкинге).
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/334700/


Метки:  

Асимметричная криптография и криптография с открытым ключом — это не одно и то же?

Среда, 09 Августа 2017 г. 07:33 + в цитатник
В данной заметке я хотел бы поделиться своими соображениями, касающимися криптографической терминологии. Конечно, ответ на вопрос, который вынесен в заголовок (будь он положительным или нет) никак не повлияет на работоспособность и безопасность соответствующих криптоалгоритмов, но здесь своей целью я ставлю исключительно разобраться в их классификации.

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

В случае же асимметричной криптографии дело обстоит по-другому. Возьмем, например, такие алгоритмы, как «шифр Шамира» [ШШ] или «ментальный покер» [МП]. Они, несомненно, являются асимметричными, но назвать их шифрами с открытым ключом язык не поворачивается, поскольку открытых ключей в них вообще нет (за исключением общих для всех абонентов параметров, таких как модуль и генератор группы).

Более того, про асимметричные системы зачастую говорится, что это такие системы, где один из ключей передается по незащищенному каналу [АС]. На мой взгляд, это как раз и есть определение асимметричных систем, где асимметрия заключается в наличии разных, а не одинаковых (как в симметричной криптографии) ключей. В шифре Шамира и ментальном покере по незащищенному каналу ключи не передаются, следовательно, они являются асимметричными системами, но не системами с открытым ключом.

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

Литература
[ШШ] Шифр Шамира.
oplib.ru/elektronika/view/1232683_shifr_shamira
[МП] Ментальный покер. ru.wikipedia.org/wiki/%D0%9C%D0%B5%D0%BD%D1%82%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9_%D0%BF%D0%BE%D0%BA%D0%B5%D1%80
[АС] Криптосистема с открытым ключом. ru.wikipedia.org/wiki/%D0%9A%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0_%D1%81_%D0%BE%D1%82%D0%BA%D1%80%D1%8B%D1%82%D1%8B%D0%BC_%D0%BA%D0%BB%D1%8E%D1%87%D0%BE%D0%BC
«Асимметричная криптография» и «криптография с открытым ключом» — это…

Никто ещё не голосовал. Воздержался 1 человек.

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

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/335216/


Метки:  

Бесплатный аудит безопасности сети с помощью Fortinet. Часть 1

Среда, 09 Августа 2017 г. 07:03 + в цитатник
Относительно недавно мы опубликовали небольшой видео курс и несколько статей о том, как можно провести бесплатный аудит безопасности сети с помощью решений Check Point. В этот раз мы хотели бы описать подобную процедуру, но только с использованием решений Fortinet.

Fortinet



Fortinet — яркий представитель постоянных лидеров среди UTM/NGFW решений. Ранее мы публиковали соответствующий отчет Гартнер за 2017 год. Пожалуй флагманским продуктом данной компании является FortiGate — шлюз безопасности (его мы и будем рассматривать далее). Однако продуктовый портфель компании значительно шире, как можно заметить по картинке выше. Вот краткий список:
FortiGate — Межсетевой экран следующего поколения (NGFW);
FortiManger — Централизованное управление устройствами Fortinet;
FortiAnalyzer — Централизованный сбор данных о событиях (логи) со всех устройств Fortinet;
FortiSandbox — Защита от таргетированных атак (песочница);
FortiMail — Защищает от спама, вредоносного ПО во вложениях и прочих угроз электронной почты;
FortiWeb — Межсетевой экран для ваших Web-приложений;
FortiSIEM — Система сбора, анализа и корреляции событий;
FortiSwitch — Коммутаторы Fortinet;
FortiClient — Защита компьютеров пользователей;
FortiADC — Контроллер доставки приложений;
FortiDB — Защита баз даных;
FortiAuthenticator — Двухфакторная аутентификация (2FA) и доступ SSO;
FortiToken — Токены для двухфакторной аутентификации (2FA);
FortiAP — Беспроводная точка доступа;
FortiExtender — Усилитель сигнала 3G/LTE;
FortiPresence — Анализ посещаемости;
FortiCloud — Сохранение журналов в облаке;
FortiDDoS — Предотвращение DDoS-атак.

Более подробно о решениях Fortinet можно почитать здесь, либо поcмотреть наш предыдущий вебинар:



Здесь вкратце рассматриваются современные угрозы, история компании, продуктовая линейка, модели FortiGate, интерфейс устройств и так далее (очень рекомендую это видео для экспресс ознакомления с компанией Fortinet).

Cyber Threat Assessment Program (CTAP)


Компания Fortinet предоставляет бесплатную возможность провести аудит защищенности сети с помощью решения FortiGate. Данная программа носит название Cyber Threat Assessment Program (CTAP). Принцип аудита довольно простой — в вашу сеть устанавливается FortiGate, который анализирует трафик (позже мы рассмотрим что конкретно анализируется). При этом есть несколько вариантов такого “пилотного” проекта, который как правило длится от двух до четырех недель. Рассмотрим их.

1) Копия трафика (One-Arm Sniffer)


Самый простой и в то же время самый популярный способ — анализ копии трафика. FortiGate подключается к SPAN-порту коммутатора, который зеркалирует интересующий трафик. Как правило анализируется трафик между коммутатором ядра и интернет-шлюзом. Т.к. FortiGate работает только с копией трафика, то нет никакого риска для вашей сети. Мы подробно рассмотрим именно этот способ.



2) В режиме моста (Transparent mode)


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



FortiGate Appliance vs FortiGate VM


Для аудита можно выбрать два варианта исполнения FortiGate: Appliance (железка) и VM (виртуальная машина). У каждого метода есть свои плюсы и недостатки.

1) FortiGate Appliance


«Железное» устройство. На тест как правило выдается несколько вариантов (в зависимости от объемов обрабатываемого трафика):


Устройство на тест можно получить только по запросу к партнерам Fortinet.
Плюсы:
  • Не требуется выделение виртуальных ресурсов (которых часто не хватает);
  • Высокая производительность;
  • Тестируете реальное устройство и можете оценить его производительность (если рассматривать FortiGate, то чаще всего покупают именно “железное” решение).
Минусы:
  • Ожидание Appliance (железок почти всегда не хватает, все на тестах).

К тому же далеко не в каждом городе есть партнер, который сможет предоставить вам оборудование на тест. С виртуальными машинами все проще…

2) FortiGate VM


Виртуальная машина FortiGate. Поддерживаемые гипервизоры — VMware ESXi, KVM, Hyper-V,
XenServer
.



В виде виртуальных машин доступны не только FortiGate, как это видно из рисунка выше.
Плюсы использования FortiGate VM:
  • Простота развертывания (импортируется через ovf);
  • Скорость развертывания (получить у партнеров виртуальную машину гораздо быстрее, чем ”железное” решение).
Минусы:
  • Необходимо выделять виртуальные мощности.

В целом это не такая большая проблема, т.к. для сети средних размеров (100-200 компьютеров) достаточно виртуальной машины с параметрами 2-4 ядра и 2-4 Гб оперативной памяти. Характеристики виртуальных машин:


Далее мы будем рассматривать именно этот способ аудита — с помощью виртуальной машины FortiGate VM.

Генерация отчета


Сам FortiGate при анализе трафика генерирует огромное количество логов. Пример:

Логи хоть и интересные (показывают используемые приложения, объемы трафика, посещаемые сайты, вредоносную активность и т.д.), но не предоставляют полную картину по защищенности сети. Гораздо интереснее комплексные отчеты, сгенерировать которые можно разными способами:
  1. Отправлять логи в облако Fortinet для последующего анализа. Функция доступна только для “железок”. Пожалуй это самый простой вариант. По окончанию аудита партнер предоставляет подробный отчет по безопасности вашей сети. Есть одно НО — не все готовы отправлять свои логи во внешний мир (даже в облако Fortinet). В этом случае есть компромиссные варианты.
  2. Собрать логи локально на устройстве, после чего передать их партнеру на анализ одним архивом. Есть ограничение в 100 Мбайт. Такой вариант используется весьма редко.
  3. Отправлять логи на локальный FortiAnalyzer. В этом случае все логи хранятся у вас и вы можете генерировать отчеты хоть каждый час, а не только в конце пилотного проекта. Единственное — придется дополнительно разворачивать FortiAnalyzer (это не сложно).

Мы рассмотрим именно третий вариант, где совместно с виртуальным FortiGate мы развернем виртуальный FortiAnalyzer. Кроме того, для виртуального решения нет возможности отправлять логи в облако на анализ.

Состав отчета


В случае использования локального FortiAnalyzer нам доступно большое количество видов отчетов:


Т.к. мы делаем комплексный анализ защищенности сети, то нас будет больше интересовать отчет Cyber Threat Assessment. Данный отчет содержит большое количество информации по состоянию сети:
Состав отчета


На первой же странице вы увидите общую сводку, что-то вроде:


Далее можно увидеть статистику по “опасным” приложениям:


Найденные уязвимости:


Статистика по скачанным вирусам:


Объемы трафика по конкретным приложениям:


Категории используемых сайтов:


И многое другое. Пример отчета можно скачать здесь.

Вывод


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

На этом первая часть заканчивается. Во второй части мы рассмотрим сам процесс настройки и генерации отчета.
Вы проводили подобный аудит безопасности сети?

Проголосовал 1 человек. Воздержавшихся нет.

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

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/335184/


«Паровозик, который смог!» или «Специализация Машинное обучение и анализ данных», глазами новичка в Data Science

Среда, 09 Августа 2017 г. 01:30 + в цитатник
Ранее в моей прошлой статье, посвящённой обучению Data Science с нуля, я обещал записаться на специализацию «Машинное обучение и анализ данных», на Coursera и поделится моими впечатлениями о доступности этих знаний для практически абсолютного новичка в области науки о данных. Сказано – сделано! Хотя безусловно, на Хабре уже есть упоминания об этой и аналогичных специализациях, но думаю мои «пять копеек» не помешают.

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





Часть 1. «Вспомнить все…» — немного о навыках



Думаю, в самом начале будет уместно напомнить с чего все начиналось, чтобы читатель мог примерить мой опыт на себя.
Итак, данная статья является завершающей в спонтанно возникшем цикле статей, о том, как я осваивал азы Data Since с нуля (статьи ниже приведены в порядке появления):

  • «Ловись Data большая и маленькая!» — (Краткий обзор курсов по Data Science от Cognitive Class) habrahabr.ru/post/331118
  • «Теперь он и тебя сосчитал» или Наука о данных с нуля (Data Science from Scratch) habrahabr.ru/post/331794
  • «Айсберг вместо Оскара!» или как я пробовал освоить азы DataScience на kaggle habrahabr.ru/post/331992


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

  • Самые начальные представления о Data Science (зачем нужна, что входит, немного о методах работы)
  • Почти нулевые познания в мат. анализе и статистике (матрицы от руки перемножал с ошибками, принцип доказательства статистических гипотез не воспринимал почти на генетическом уроне)
  • Почти нулевое знание Python, немного минимальных навыков программирования в других языках (например, C#), которые похоже только мешали освоить логику Питона.
  • Шило в «пятой точке» которое заставляло убить целый месяц на сверхинтенсивное прохождение курса


Именно с такой базой я подошел к началу обучения. В описании специализации честно сказано: «Intermediate Specialization. Some related experience required.» и признаться это меня настораживало, но поскольку в разработчиках специализации числится МФТИ и Яндекс я решил рискнуть.

Кстати, доложен отметить, что курс действительно заставил меня вспомнить все, в особо трудные минуты неожиданно начали всплывать в памяти, давно «прошедшие мимо ушей» знания, казалось бы, забытые за ненадобностью. Правда, как мне кажется, эта специализация в части статистики и мат. анализа все равно отложила у меня в голове больше чем предметы из программы специалитета и магистратуры ВУЗа вместе взятые.
Ну не буду вас больше томить, перейдем ближе к делу.

Часть 2 — «Начало» — знакомство с курсом



«Какой самый живучий паразит? Бактерия? Вирус? Кишечный глист? Идея. Она живучая и крайне заразная. Стоит идее завладеть мозгом, избавиться от нее практически невозможно. Я имею в виду сформировавшуюся идею, полностью осознанную, поселившуюся в голове» — Inception

Пока писал эту статью и вспоминал прохождение курсов, задумался, что единственной здравой причиной, по которой я вообще заинтересовался Data Science может быть, только то что мне эту идею внедрили во сне, или даже во сне внутри сна во сне внутри сна…
Причем это была не просто идея — пройти курс по Data Science на Coursera, это была идея пройти курс максимально быстро потому что лишних денег, да и времени растягивать на полгода не было.

Если кто-то не знаком с новой политикой Coursera, то сейчас на данный курс действует система подписки, а именно 7 бесплатных дней пробной подписки, потом каждый месяц платно. Специализация рассчитана примерно на 6 месяцев. Один месяц мне обошелся в 4 576 руб (сейчас стоит немного больше).
Таким образом система давала 1 месяц + 1 неделю, и я решил, что именно за этот отрезок должен пройти специализацию. Забегая вперед, скажу, что задача вполне посильная.

Перейдем к описанию программы специализации. Она состоит из 6 курсов, пять из них теоретические, а шестой это курсовой проект (Capstone Project), доступ к нему откроется только после прохождения первых пяти. Курсы желательно проходить в прямом порядке, вас конечно никто не заставляет, но очень настоятельно рекомендуют. Если вы решите в сжатый срок пройти специализацию, то иногда будет смысл немного проходить курсы не в прямом порядке (об этом позже), но скорей всего это вам «аукнется» и будет необходимо возвращаться к ранее пройденному.

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

Начнете вы с основ Питона, азов мат. анализа и теории вероятностей, потом рассмотрите обучение с учителем и без учителя (от базовых моделей из scikit learn до нейронных сетей), потом статистика, потом практическое применение. В принципе похоже, что это общераспространённый подход к обучению в области Data Science.

Может быть, для кого-то станет критичным, что курс заточен под Python 2, причем я бы от греха не советовал бы даже некоторые вещи импортировать «из будущего», ибо в некоторых задачах «грейдер», очень чуткий и могут возникать проблемы из-за, например, разницы в библиотеках, в том числе и при применении Python 3 (по крайней мере судя по отзывам на форумах).
На мой взгляд удобней всего настроить Anaconda. Если у вас уже установлена анаконда с окружением под Python 3, то не расстраивайтесь настроить второе окружение с Python 2 достаточно просто (я ставил через консоль conda по этой инструкции). Ставится она и под Windows и под Linux, под Mac OSX не пробовал, но думаю тоже ставится без проблем.

Кстати, судя по форумам специализации многие проходили этот курс пользуясь OS Windows, я рекомендую на всякий случай накатить второй системой Linux, но безусловно это не обязательно, хотя может быть полезно.
Я накатил себе Linux Mint второй системой, чисто для этой специализации, и не пожалел. Субъективно мне кажется, что местами расчёты под ним проходят быстрей, также было меньше проблем с установкой некоторых библиотек, которые требовались при прохождении курса.

Первый курс для новичка выглядит вполне дружелюбно: по-своему харизматичные ребята из МФТИ и Яндекс расскажут зачем это нужно и поначалу не будут вас пугать зубодробительными заданиями. А вот потом, уровень фрустрации зависит от вашей подготовки. У меня, и у некоторых людей на форуме бывали случаи, когда целыми днями не удавалось подобрать решении задачи или теста, с другой стороны если у вас есть способности и хорошая «база», то думаю вам все будет просто и понятно.

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

Отдельное слово надо сказать о лекторах курса и заданиях. Над курсом работала большая команда и соответственно есть свои плюсы и есть свои минусы, большую часть курса читают 4 ключевые специалиста, у каждого похоже своя специализация. По лекторам видно, что они опытные и толковые люди, но к некоторым по началу привыкнуть трудно. Я не буду раскрывать персоналии, чтобы никого не обидеть. Просто отмечу, что есть лекторы, которым хочется просто поклонится в ноги, за то, что они стараются разжевать материал даже новичкам, некоторые же лекторы могут немного нервировать и вызывать на первых порах жгучее желание совершить насильственные действия агрессивного характера. Это безусловно моя субъективная реакция, вызванная плохими базовыми знаниями и личным восприятием, в любом случае к концу специализации привыкаешь к манере каждого из лекторов и даже как-то жалко становится с ними заочно расставаться.

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

Я не хочу вдаваться в подробности обучения по каждому из курсов, думаю вы все постигните в процессе обучения перейду к полезным советам. Ну и еще раз повторюсь есть статьи на Хабре про эту специализацию, например, от самого МФТИ).

Часть 3 «Автостопом по галактике» — что делать чтобы не было мучительно больно.


«Галактика суровая штука. Чтобы в ней выжить, надо знать, где твое полотенце» — Автостопом по галактике

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

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

2. Также не смотря на основной посыл статьи, я не рекомендую проходить специализацию галопом как я. Да может быть 6 месяцев это объективно, много, но думаю месяца три это вполне комфортные условия для размеренного поглощения знаний. Изучение же курса за месяц + одну неделю помимо бессонных ночей и отсутствия нормальных выходных приведет к тому, что возможно ваш мозг просто не переварит то что вы, выучили. Так, например, я обнаружил забавный эффект к моменту, когда я уже проходил 4-й курс, я вдруг, не осознанно просто так занимаясь совсем другими делами начал понимать некоторые моменты из первых курсов. К моменту прохождения финального проекта специализации у меня ни с того ни с сего в голове начало возникать понимание самых основ статистики из 4-го курса, видимо мозгу нужно время. В качестве совета частично компенсирующего недостаток времени на прохождение курса при быстром изучении, рекомендую через пару курсов после начала обучения начать параллельно читать, какой-нибудь самоучитель по теме. Я, например, выбрал книгу: А. Мюллер, С. Гвидо —«Введение в машинное обучение с помощью Python. Руководство для специалистов по работе с данными» — 2017 г. Там мало теории, но зато материал книги наглядно повторяет приемы, освоенные в рамках курса.

3. Используйте форумы курсов и slack, вы удивитесь, сколько людей столкнулись с теми же проблемами, что и вы. Поскольку я очень спешил, то практически каждое задание я начинал сразу с изучения тем на форуме связанных с трудностями, которые возникают во время его решения. Не редко на форуме можно встретить, прям куски кода, или формат ответов, которые ждет «грейдер», а в особо сложных случаях прям целые инструкции от пользователей, в которых разжевано, что же хотел от вас автор задачи (у которого видимо есть трудности в общении с неспециалистами). Slack меня выручил на самом последнем этапе, когда было необходимо скооперироваться с людьми для взаимной проверки заданий, народу на шестом курсе мало и чтобы не ждать долго, полезно искать людей которые уже прошли этот этап и просить их об оценке или наоборот помогать советом (в рамках правил) людям которые вас догоняют, чтобы они быстрее вас догнали и смогли оценить работу. Также маленький «лайф хак», если вы не наберёте достаточно заданий для того чтобы оценить сокурсников и не хотите ждать, то всегда можете поискать ссылки от людей на форуме, где люди просят их проверить (пусть и пару месяцев назад), правда из чувства солидарности я все же советую не останавливаться на трех минимально необходимых оцененных работах, а помочь с проверкой большему числу людей. Кроме форума на первых курсах помогает просто поиск в Интернет, там вы вполне можете найти подсказки для решения ваших задач (например, одна из задачек в первых курсах базируется на научной статье, которую можно найти и подглядеть куски кода), а вот дальше Интернет уже менее полезен.

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

5. Запись на сессии. Тщательно прикиньте ваш прогресс. Если вы хотите закончить в сжатые сроки, то не имеете права ждать впустую. Некоторые задания невозможно сдать, пока не начнется сессия, ну, например, вы закончили 2й курс 14 числа, а сессия не третий курс начнется только 21 числа, это значит, что вы 7 дней не сможете сдавать некоторую часть заданий (как правило связанную со взаимной оценкой). Поэтому есть смысл записываться на сессии чуть раньше, чем вы закончили прошлый курс.
Приведу пример, допустим какой-то курс уже начался, но первые 3 недели не содержат заданий с проверкой другими пользователями, тогда есть смысл записаться на эту сессию и потом наверстать, чем ждать пока начнется новая сессия и пока ваши сокурсники дойдут до третей недели. Второй пример на один из курсов мне пришлось записаться с опережением графика, получилось, что я закончил второй курс и сразу записался на пятый, быстро сдал задание, оцениваемое пользователями на самой первой неделе и вернулся спокойно к третьему и четвертому курсу по порядку. Таким образом я не потерял момент, когда люди были готовы оценить работу и потом наверстал упущенное. Из минусов первую неделю пятого курса потом пришлось учить заново потому что из головы все вылетело.

6. Не все знают и явно это похоже не прописано, так что на всякий случай напишу — Coursera по крайней мере на текущий момент на Capstone проект дает полгода, то есть срок моей подписки (месяц + бесплатная неделя ) истекали 08.08.17, но как сказала поддержка доступ к Capstone проекту сохранится полгода с момента начала 6 курса в моем случае до конца января, ибо начал я в конце июля. Так что зная это, вы можете сберечь себе нервы.

7. Capstone проект делится на 4 ветки, для завершения специализации достаточно пройти одну из них, при этом местами системы оценок не очень справедливые. Ну, например, в 5-м задании 1-го проекта (идентификация интернет пользователей) будет очень тяжело достигнуть высокой оценки в связи с необходимостью попасть в топ соревнования на kagle, с другой стороны в 5-м задании проекта по сантимент анализу, предлагают написать примитивный парсер сайта, задание можно сделать за пол часа даже не вдаваясь в предыдущие задачи курса, а оценку хорошую получить проще (учтут в итоге лучший бал). Таким образом вы можете в каких-то моментах где владеете навыками лучше, кроме основной ветки выполнить еще здания и в других, совместите приятное с полезным.

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

9. Ну и пусть это банально, но рассчитайте свои силы, серьезно, за прошедший месяц мне порой приходилось спать за ночь по 2 часа, не видеть друзей и близких, забывать поесть, все выходные гробить на решение задач, да и много еще чего. Поэтому если вы действительно хотите, не имея спецподготовки осилить курс за месяц подумайте готовы ли вы на это.

Кстати, фраза из Автостопом по галактике вспомнилась по тому что в курсе периодически предлагают выставить random seed в значение = 42

Ну думаю есть смысл подводить итоги.

Часть 4 «I' ll be back» — заключение.



Давайте по порядку ответим на вопросы:

1. Пригодились ли мне навыки, которые я получил из обучения до этого (см. первые три статьи цикла)?

— Да, но не сильно, с одной стороны хорошо, когда имеешь представление о том что примерно тебя ждет (Курсы от Cognitive Class), также местами пригодился и самоучитель про «Data Science с нуля» там я перечитывал теорию вероятности (там немного материала, но то что есть написано понятней), ну и опыт с kagle вам тоже пригодится, когда будете делать Capstone проект, Однако суммарно все три прошлые статьи по навыкам с точки зрения практики и близко не лежат с прохождением специализации, так что если вы уже твердо решили что хотите, можете начинать «без прелюдий».

2. Страдал ли я от недостатка базовых знаний?

— Да, местами очень, особенно когда 2.5 дня не мог написать простейшую функцию, или тупо не мог воспринять какие-то монеты статистики и теории вероятности. К счастью есть форум и slack там много таких же людей, и можно найти помощь, ну и менторы курса, а иногда и сами разработчики стараются помочь. Если все совсем плохо, можете взять персонального тьютора, но думаю, что любой человек в состоянии справится сам.

3. Узнал ли я что-то новое?

— Да, во-первых, я первый раз в жизни написал программу, которая работала 9.5 часов подряд, потом накрылась выдав memory error (потом я конечно это все поправил), у меня несильный компьютер, но даже игрушки с нормальной графикой не могли конкурировать с моим творением в части пожирания ресурсов. Это очень хороший опыт, я навсегда теперь запомнил о важности и пользе разряженных матриц. Ну и во-вторых другие моменты полезные тоже есть: это курс все же немного учит Python(у), я по прежнему его знаю очень плохо и не освоил «Pythonic way», но это намного лучше чем вообще никак, курс неплохо объясняет базовые принципы высшей математики и статистики (не вдаваясь в подробности), фактически я их для себя открыл заново. Курс действительно показывает многие интересные фишки, часть из которых при желании можно перенести в свою повседневную жизнь. Да, есть проблемы с усвоением информации думаю 3/4 материала прошли мимо моего осознания, но даже оставшегося хватит, чтобы догадываться в каком направлении копать, если где-то понадобится анализ данных.

4. Может ли этот курс освоить каждый?

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

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

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

Что же дальше? Ну может применю полученные навыки для своего хобби и потом скину материал на Хабр, может быть посмотрю, как обстоят дела с машинным обучением на .net и тоже отпишусь. Но это всё будет сильно позже.

Так что желаю всем удачи в освоение данной интересной области знаний!

Ну а, чтобы статья не казалось совсем уж серьезной ловите «бонус»:

В качестве бонуса.


Еще одним крутым плюсом этой специализации, стало то, что я выучил слово корреляция и теперь буду его везде пихать к месту и не очень.

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

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

Давайте посмотрим, а есть ли какая-то КОРРЕЛЯЦИЯ?!

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

1. Статья №1: слов = 2575, шуток =5, дней обучения — 2
2. Статья №2: слов = 2098, шуток =3, дней обучения — 3
3. Статья №3: слов = 2667, шуток =4, дней обучения — 2
4. Статья №4: слов = 3051, шуток =2, дней обучения — 37

Далее код на Python 3, для Python 2 уберите скобки перед print и убедитесь, что делите на float, также можно убрать list () перед zip()

import pandas as pd
humor_rate=[(5/2575),(3/2098), (4/2667),(2/3051)]
days=[2,3,2,37]
df=pd.DataFrame(list(zip(humor_rate, days)), index=None, columns=['Humor rate', 'Days of study'])
print ('Таблица данных: \n', df)
print ('Корреляция между humor rate и days of study = ', df.corrwith(df['days of study'])[0])


вывод:
Таблица данных:
.....Humor rate.....Days of study
0....0.001942............2
1....0.001430............3
2....0.001500............2
3....0.000656............37

Корреляция между humor rate и days of study = -0.912343823382



Ну что в итоге? А в итоге мы имеем ярко выраженную отрицательную КОРРЕЛЯЦИЮ (коэф. КОРРЕЛЯЦИИ Пирсона), которая говорит нам что, как правило, чем меньше число дней, потраченных на обучение тем больше юмора в статье.

Конечно это шуточный пример КОРРЕЛЯЦИИ. Данных безусловно мало, да и у меня возникли сложности с определением однозначного количества шуток в статье, но будем считать это маленьким примером того, как вы сможете применить полученные после специализации навыки на практике, в том числе и для расчёта КОРРЕЛЯЦИИ.

P.S. сколько раз я упомянул это слово в бонусном фрагменте статьи? Правильно — восемь с учетом, вывода print ().

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/335214/


Метки:  

Алгоритм для запоминания иностранных слов

Среда, 09 Августа 2017 г. 00:32 + в цитатник
На данный момент создано множество приложений для запоминания слов. Из тех что мне запомнились могу выделить такие Android приложения как Lingualeo, Английские слова, СловоУч.

Главным недостатком этих приложений для меня был платный аккаунт для добавления своей базы слов. Поэтому встал вопрос о написании своего приложения для запоминания слов. Главной идеей было подключения внешнего API словаря и переводчика для переводов слов на родной язык. В качестве такого API было выбрано Yandex API (API Переводчика и API Словаря).

Первым делом необходимо было получить ключи разработчика. Для переводчика и для словаря.

В качестве языка и платформы разработки был выбран JavaScript и библиотека JQuery.

Для получения перевода слова на нужный язык я использовал следующий код:

            var oneWord = function() {
                $.post("https://dictionary.yandex.net/api/v1/dicservice.json/lookup",
                    {
                        key: apiKey, 
                        lang: lang, 
                        text: words[index].text
                    }, function(data) 
                    {
                        words[index].tr = "";
                        words[index].ts = "";
                        for (var j = 0; j < data.def.length; j++) {
                            var def = data.def[j];
                            for (var k = 0; k < def.tr.length; k++) {
                                var tr = def.tr[k];
                                words[index].tr += tr.text + "; ";
                            }					
                            if (def.ts)
                                words[index].ts = def.ts;
                        }
                        if (words[index].tr == "") {
                            translateWords();
                            tsWords();
                            return;
                        } else {
                            var str = words[index].tr;
                            words[index].tr = str.substring(0, str.length - 2);
                        }
                        complete();
                    }, 
                "json");
            };
            var tsWords = function() {
                var text = words[index].text;
                var tsText = "";
                var tsWords = text.match(/\S+/gi);
                var tsIndex = 0;
                var tsPost = function() {
                    $.post("https://dictionary.yandex.net/api/v1/dicservice.json/lookup",
                        {
                            key: apiKey, 
                            lang: lang, 
                            text: tsWords[tsIndex]
                        }, function(data) 
                        {
                            var ts = "";
                            for (var j = 0; j < data.def.length; j++) {
                                    var def = data.def[j];
                                    if (def.ts)
                                            ts = def.ts;
                            }
                            tsText += ts + " ";
                            if ((tsIndex < (tsWords.length - 1)) && (tsIndex < 5)) {
                                tsIndex++;
                                tsPost();
                            } else {
                                words[index].ts = tsText.trim();
                                complete(false, true);
                            }
                        },
                    "json");
                };
                tsPost();
            };
            var translateWords = function() {
                $.post("https://translate.yandex.net/api/v1.5/tr.json/translate",
                    {
                        key: apiKeyTranslate, 
                        lang: slang, 
                        text: words[index].text
                    }, function(data) 
                    {
                        words[index].tr = "";
                        for (var j = 0; j < data.text.length; j++) {
                            var text = data.text[j];
                            words[index].tr += text + "; ";
                        }
                        var str = words[index].tr;
                        words[index].tr = str.substring(0, str.length - 2);
                        complete(true, false);
                    },
                "json");
            };
            var qu = function() {
                if (!words[index].tr) {
                    oneWord();
                } else {
                    complete();
                } 
            };
            qu();

Тут функция oneWord переводит одно слово, tsWords находит транскрипции первых пяти слов в выражении (если дано не слово, а предложение), translateWords переводит предложение.

Результирующая функция complete вызывается для заполнения формы слова с транскрипцией и переводом:

        var complete = function(tr, ts) {
            if (ts == undefined) ts = true;
            if (tr == undefined) tr = true;
            var word = words[index];
            if (tr) $("#text").html(word.text);
            if (ts) $("#ts").html("[" + word.ts + "]");
            $("#tr").hide();
            $("#attempt").hide();
            $("#show").show();
            $("#tr").html(word.tr);
            $("#tts").show();
        };

В массиве слов words index отражает текущее слова для запоминания. Следующее слово выбирается по следующему алгоритму:

        var words = [],
            patternCount = 5,
            indexMemory = {},
            indexMemoryCount = 0,
            patternIndex = [],
            lastIndex = -1,
            lastIndexs = [],
            lastIndexsCount =  2,
            wasAttempt = false,
            wasMemory = false,
            deep = 0,
            deepMax = 100; 

        var index = nextIndex();

        var nextIndex = function() {
            deep++;
            if (lastIndexsCount - words.length >= 0) {
                lastIndexsCount = 0;
            } 
            if ((patternIndex.length < patternCount) && (indexMemoryCount < words.length)) {
                if (deep > deepMax) {
                    
                    var index = maxAttemptsIndex(true);
                    return index;
                }
                var index = Math.floor(Math.random() * words.length);
                if (indexMemory[index]) {
                    return nextIndex();
                }
                indexMemory[index] = "do";
                indexMemoryCount++;
                patternIndex.push(index);
                lastIndex = index;
                pushIndex(lastIndex);
                return index;
            } else {
                var index = Math.floor(Math.random() * (patternIndex.length + 1));
                if (index == patternIndex.length || (patternIndex.length == 0)) {
                    wasMemory = true;
                    var ind = maxAttemptsIndex();
                    if (inArray(lastIndexs, ind)) 
                    {
                        if (deep > deepMax) {
                            ind = Math.floor(Math.random() * words.length);
                            lastIndex = ind;
                            pushIndex(lastIndex);
                            return ind;
                        }
                        return nextIndex();
                    }
                    lastIndex = ind;
                    pushIndex(lastIndex);
                    return ind;
                }
                if (inArray(lastIndexs, patternIndex[index])) return nextIndex();
                lastIndex = patternIndex[index];
                pushIndex(lastIndex);
                return patternIndex[index];
            }
        };

        var maxAttemptsIndex = function(notAttempts) {
            var arr = sortMemoryIndexes(indexMemory);
            var index = getRandomFishIndex(arr, notAttempts);
            return index;
        };

       var pushIndex = function(index) {
            if (lastIndexsCount == 0) return;
            if (lastIndexs.length < lastIndexsCount) {
                lastIndexs.push(index);
            } else {
                lastIndexs[0] = lastIndexs[1];
                lastIndexs[1] = index;
            }
        };

        var inArray = function(arr, elem) {
            for (var i = 0; i < arr.length; i++) {
                if (arr[i] == elem) 
                    return true;
            }
            return false;
        };

        function getRandomFishIndex(arr, notAttempts) {
            var fishForLevel = arr;
            var fishTotalWeight = 0, fishCumWeight = 0, i;
            // sum up the weights
            for (i = 0; i < fishForLevel.length; i++) {
                fishTotalWeight += fishForLevel[i].attempts;
            }
            if (notAttempts) {
                fishTotalWeight = 0;
            }
            var random = Math.floor(Math.random() * fishTotalWeight);
            // now find which bucket out random value is in
            if (fishTotalWeight == 0) return fishForLevel[Math.floor(Math.random() * fishForLevel.length)].index;
            for (i = 0; i < fishForLevel.length; i++) {
                fishCumWeight += fishForLevel[i].attempts;
                if (random <= fishCumWeight) {
                    return fishForLevel[i].index;
                }
            }
        }

        function sortMemoryIndexes(indexMemory) {
            var arr = [];
            for (var key in indexMemory) {
                if (indexMemory[key] == "do") {
                    var word = jQuery.extend(true, {}, words[key]);
                    word.index = key;
                    arr.push(word);
                }
            }
            var sAttempt = function(first, second) {
                if (first.attempts < second.attempts)
                    return 1;
                else if (first.attempts > second.attempts)
                    return -1;
                else
                    return 0;
            };
            return arr.sort(sAttempt);
        }

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

Именно кнопка «Неправильно» реализует перестановку вероятностей показа слов.

        $("#attempt").click(function()
        { 
            words[index].attempts++;
            wasAttempt = true;
            $("#attempt").hide();
        });

Данный метод запоминания слов показался мне наиболее эффективным. В остальном программный код приложения реализует события и действия элементов интерфейса. HTML и сопутствующий JavaScript код был обернут в Cordova для платформы Android.

Приложение «EnglishWords» позволяет учить английские слова и слова многих других языков. В программе имеется базовый набор слов для изучения. Главной особенностью программы является возможность создавать свои наборы слов для изучения. ИНФОРМАЦИЯ НА ЭКРАНЕ * Процент. Означает процент изученных слов в словаре. КАК ЭТО РАБОТАЕТ. Процесс изучения слов начинается с того, что программа набирает из выбранных словарей 5 случайных слов и начинает их показывать в случайном порядке. После того, как слова выучены из словаря извлекаются следующие 5 случайных слов. Если вы отвечаете не правильно на слово, то слово будет показываться чаще. Когда все слова выучены показываются только те слова на которые чаще всего давался не правильный ответ. СЛОВАРЬ Базовый набор слов содержит около 1000 наиболее употребляемых английских слов.

Приложение использует yandex и google api для получения перевода, транскрипции и звукового воспроизведения. Для работы приложения необходим доступ в интернет.

Приведу скриншоты приложения:

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/335212/


Метки:  

[Из песочницы] Аутсорсинг: за и против

Вторник, 08 Августа 2017 г. 21:47 + в цитатник
Аутсорсинг – процесс, прорвавшийся в наши экономические реалии с кризиса, условно названного «кризисом 2008 года». В базовом определении – это название операционной деятельности целиком и полностью принятого от английского слова «outsourcing», подразумевающей процесс заимствования ресурсов необходимых компании из вне на основании соответствующих договорных обязательств.

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

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

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

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

По мере заполнения рыночной ниши, перехода отрасли в стадию насыщения, уровня конкуренции в совершенную, цен в мультипаки и скидки, нормы прибыли компаний снижаются, а операционные постоянные издержки остаются практически неизменными. Значительным драйвером снижения норм прибыли коммерческих организаций стал и «кризис 2008 года», когда накопленное перепроизводство и снижение покупательской активности привело к резкому ухудшению экономических показателей практически во всех отраслях.

На одном из очередных витков снижения общей прибыли компании собственники бизнеса принимают решение об изменении операционных процессов или оптимизации. Одним из элементов оптимизации и является «аутсорсинг».

Какие цели преследует компания?

  1. Фактический перевод постоянных операционных затрат в переменные, т.е. «аутсорсинг» максимально привязывают к объему реализации;
  2. Уменьшение числа штатных сотрудников, что является одним из измеряемых показателей эффективности компании. Особенно актуально для компаний акционерного типа;
  3. Повышение качества конечных товаров/услуг за счет привлечения в операционную цепочку специалистов/профессионалов, имеющих лучшие компетенции чем развиты внутри компании.

В цели 3 заложен основной принцип «аутсорсинга»: «Передать в управление часть бизнес-процессов/операций/функций/ресурсов можно в том случае, если компания, которая их принимает имеет более развитые компетенции в управлении выделенным сегментом, чем компания, которая их передает».

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

Другой пример, часто встречающийся в рынке товаров FMCG, передача полных прав на дистрибуцию в регионе дистрибуционной компании или дистрибуционным логистам. Все, кто проходил на опыте такое решение сразу перечислят его минусы:

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

Неправильно не вспомнить о базовом техническом инструменте принятия решения об аутсорсинге – Матрица Аутсорсинга (см. рис).

image

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

Но, в этом решении есть и обратная сторона для специалистов, которых выделили в отдельные подразделения и вывели за контуры компании. В бизнес-практике есть много примеров создания новых бизнесов освободившимися сотрудниками и заключение договоров с бывшими работодателями. Но это уже совсем другая глава, как и глава о том, как меняется психологический климат и мотивация персонала в ожидании аутсорсинговой реструктуризации.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/335206/


Метки:  

Поиск сообщений в rss_rss_hh_new
Страницы: 1437 ... 1087 1086 [1085] 1084 1083 ..
.. 1 Календарь