...

суббота, 28 апреля 2018 г.

Установка и настройка OpenVPN сервера с помощью docker-compose

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

OpenVPN одна из самых популярных программ для организации VPN туннеля, а docker-compose отличный инструмент для установки и настройки программ с помощью одного docker-compose.yml файла.

В статье я расскажу как быстро и просто настроить OpenVPN сервер на собственном VPS используя docker-compose. За основу возьмем образ kylemanna/docker-openvpn.

Заинтересовавшихся прошу под кат.


Установка OpenVPN сервера

Итак, для работы нам понадобятся: собственный VPS сервер, установленный docker и docker-compose.

Создаем новый docker-compose.yml

touch docker-compose.yml

Копируем следующие строчки в созданный docker-compose.yml

version: '2'  
services:  
  openvpn:
    cap_add:
     - NET_ADMIN
    image: kylemanna/openvpn
    container_name: openvpn
    ports:
     - "1194:1194/udp"
    restart: always
    volumes:
     - {path_to_save_openvpn_config}:/etc/openvpn

Меняем {path_to_save_openvpn_config} на путь где OpenVPN будет хранить свои настройки, у меня это /home/administrator/openvpn/.

Docker-compose файл готов. Запустим следующие команды для инициализации OpenVPN и создания сертификата сервера. Замените {vpn_server_address} на адрес вашего сервера,
это может быть как IP адрес (10.10.10.8), так и доменное имя (vpn.server.com).

docker-compose run --rm openvpn ovpn_genconfig -u udp://{vpn_server_address}
docker-compose run --rm openvpn ovpn_initpki

Во время генерации сертификата введите контрольную фразу (Enter PEM pass phrase) и имя сертификата (Common Name).

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

Генерирование серверного сертификата

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

Когда сертификат готов, можно запускать наш OpenVPN сервер.

docker-compose up -d openvpn

Создание клиентских сертификатов

Чтобы соединиться с вашим OpenVPN сервером понадобится клиентский сертификат.

Для создания клиентского сертификата используем следующую команду:

docker-compose run --rm openvpn easyrsa build-client-full {client_name} nopass  

Не забываем заменить {client_name} на имя клиента, например my_phone.

Во время создания сертификата вас попросят ввести контрольную фразу (Enter passpharse) из предыдущего шага.

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

Когда клиентский сертификат сгенерирован давайте экспортируем его в .ovpn файл и отправим клиенту

docker-compose run --rm openvpn ovpn_getclient {client_name} > certificate.ovpn  

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

Дополнительную информацию вы можете найти на официальном сайте образа kylemanna/docker-openvpn.

Let's block ads! (Why?)

[Из песочницы] Erlang кластер на коленке

Что мы читали в апреле: полезные статьи для Angular-разработчиков и подборка лучшего с ng-conf

Нынешний апрель был, конечно, не самым удачным месяцем для чтения о добром и вечном; все в мыле носились за разбушевавшимся РКН и клеили побитые блюдца. Однако жизнь за пределами зоны его ответсвенности не останавливалась. Наш фронтенд-разработчик Максим Попов даже в самый разгар боевых действий отслеживал интересные новости по Angular и делился ими с коллегами. Кроме того, он отсмотрел доклады прошедшей ng-conf и подготовил подборку наиболее ценного. С его любезного разрешения делюсь этой информацией с Хаброй — будет что почитать и, главное, посмотреть в длинные выходные.


RxJS: Избегаем багов с switchMap

О внимательности к используемым RxJS операторам, а конкретно switchMap. В целом можно не париться, но стоит иметь подобный кейс в виду (особенно случай когда отменённый запрос на бэкенде успел отработать).

Цитата:

Вкратце, когда вам требуется сглаживающий оператор в эффекте/эпике, вам стоит:
· Использовать concatMap для действий, которые не должны ни отменяться, ни игнорироваться, и для которых должен сохраняться порядок – также это консервативный выбор с предсказуемым поведением;
· Использовать mergeMap для действий, которые не должны ни отменяться, ни игнорироваться, но для которых порядок не важен;
· Использовать switchMap для действий чтения, которые должны отменяться, когда запускается другое действие того же типа;
· Использовать exhaustMap для действий, которые должны игнорироваться, пока в очереди находится другое действие того же типа.

В дополнение — небольшая заметка про использование switchMap с условием внутри. Нередкий кейс, когда надо по какому-то флагу зацепить дальше другой поток и при false значении флага этот дальнейший поток остановить. Это делается через switchMap и переключение на Observable.never() в фолс ветке.

Но тут есть один весёлый момент: если после такого свитча идут другие switchMap операторы, которые по логике относятся к тому потоку, на который переключаемся, то они не будут остановлены, несмотря на переключение на never() ветку.

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

Пример, чтобы было понятно о чём речь

Кнопка toggle wrong sequence запускает таймер в потоке с ошибкой, если ещё раз нажать на кнопку, то в консоли будет видно, что таймер продолжает работать:

toggle right sequence запустит корректную цепочку, при повторном нажатии таймер отключится:

Во втором случае вся цепочка операторов, которую надо использовать по enabled === true вынесена в отдельный поток и целиком переключается.


Примеры всего нового в ECMAScript 2016-2017-2018

Большая часть всем известна, но есть интересный момент в 2018: Shared memory and atomics.

Позволит шарить между потоками (вебворкерами) реальные куски памяти (объекты), а не гонять туда-сюда сериализованные куски (строки через postMessage, как сейчас). Должно дать нормальную многопоточность и очень многое ускорить (например, декодинг видео/аудио для тех же лайв стримов). Ну и ждём angular N, запускающий не связанный с домом код в вебворкерах.

Цитата:

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

Это достигается с помощью нового глобального объекта SharedArrayBuffer, который по сути хранит данные в общем пространстве памяти. Такие данные могут использоваться как основным потоком JS, так и потоками вебворкеров.


Все, что вы хотели знать о дереве инжектов в Angular

Отличный разбор того, как выглядит и работает дерево инжектов в ангуляре, а в конце небольшая заметка о новой фишке в v6 — treeshakeable tokens (возможность в Injectable у сервиса указать, к какому модулю он принадлежит).

Цитата:

Angular продолжает работать над сокращением размера фреймворка и с 6-й версии начнет поддерживать новый способ регистрации провайдеров.

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

Как только выйдет стабильная версия API, мы сможем конфигурировать декоратор Injectable так, чтобы он сообщал Angular, к какому модулю он относится и как его следует инстанцировать.


Подборка выступлений ng-conf

В апреле в Солт-Лейк-Сити прошла очередная ng-conf; вот видео выступлений, которые Максим считает наиболее достойными внимания.

Лучшее:
Elements от Rob Wormald
рассказ про то, какими будут @Angular/elements при релизе ng6.

Components development kit (@angular/cdk, бывший @angular-material/cdk)
куча полезных фишек вроде работы со скролом, оверлеями, прокидыванием кусков шаблона между компонентами (порталы), всякое для создания своих GUI компонентов (почти всё выступление — пример создания color picker'а с использованием cdk).

Отличное:
Пиар VS Code ide
почему вы ещё на тормозном PhpStorm, когда есть няшный и шустрый VS Code?..

Пишем чистый код от John Papa

Использование stackblitz.com для прототипирования
Восхитительная штука, вдруг кто ещё не знает: полноценная ide — vs code — вся js/ts экосистема в браузере, в проект ставятся любые либы (и очень быстро), есть готовые шаблоны под ангуляр/реакт/ещё что-то.

Годное:
Использование reactive forms со всякими извращениями
Reactive forms — очень крутая штука, даже не вспоминайте про ngModel.

Template refs в шаблонах
Template refs — это которые #smth на тегах в шаблоне. Что это, зачем, как готовить.

Довольно подробное описание того как работает ng-content и почему
Есть интересный хак с аттрибутом ngProjectAs.

Немного про bazel и то, как выглядят его работа и конфигурирование
Это то, чем мы будем в будущем (скорее всего) собирать ангуляр, т.к. гораздо быстрее сборка и пересборка.

rxjs с ангуляром для тех, кто ещё не особо разбирается
В основном базовые вещи.

Разбор того, как ангуляр работает с элементами в шаблоне
Примеры использования ElementRef, ViewChild/ViewChildren, TemplateRef, как устроена работа с вьюхами/домом.

Как работает роутер ангуляра и полезные советы, как его готовить
Базовые вещи: резолверы, гарды, вынос чайлд роутов, lazy loaded роуты.

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

Оптимизации производительности приложения
Базовые вещи по типу OnPush, pure pipe, immutable (достаточно просто не мутировать данные), мемоизация (редкий кейс), буферизация вывода (тоже редкий кейс).

Создаём свою билд систему по типу той что в @angular/cli
Только зачем?..

Что нового в rxjs6

Большие приложения с ангуляром
Как жить с кучей приложений, общих либ и почему (да, опять монорепа).

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

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

Let's block ads! (Why?)

[Перевод] Как Netflix эвакуируется из региона AWS за семь минут

Netflix уменьшил время аварийного переключения с 45 до 7 минут без каких-либо затрат



Изображение: Florida Memory. Доработано Opensource.com. CC BY-SA 4.0

Зимой 2012 года Netflix пережил длительный сбой, уйдя в отключку на семь часов из-за проблем с сервисом AWS Elastic Load Balancer в регионе US-East (Netflix работает на AWS — у нас нет собственных дата-центров. Всё ваше взаимодействие с Netflix происходит через AWS, кроме самого потокового видео. Как только вы нажмете Play, начинает загружаться видеопоток из нашей собственной сети CDN). Во время сбоя ни один пакет из региона US-East не доходил до наших серверов.

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


Мы расширились на три региона AWS: два в США (US-East и US-West) и один в Евросоюзе (EU). Зарезервировали достаточно ресурсов для переключения, если один регион выйдет из строя.

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

  1. Понять, что один из регионов испытывает проблемы.
  2. Масштабировать два спасательных региона.
  3. Проксировать трафик спасателям из проблемного региона.
  4. Изменить DNS из проблемного региона на спасателей.

Изучим каждый шаг.

1. Определить наличие проблемы


Нужны метрики, а лучше одна метрика, которая говорит о здоровье системы. В Netflix используется бизнес-метрика «запуски потоков в секунду» (stream starts per second, сокращённо SPS). Это число клиентов, успешно запустивших потоковую трансляцию.

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

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

Если падение SPS произошло только в одном регионе, то это отличный кандидат для аварийного переключения. Если в нескольких регионах, то не повезло, потому что мы в силах эвакуировать только один регион за раз. Именно поэтому мы разворачиваем микросервисы в регионах по очереди. Если возникла проблема с развёртыванием, можно немедленно эвакуироваться и исправить проблему позже. Точно так мы хотим избежать сбоя, если проблема сохранится после перенаправления трафика (как это происходит в случае DDoS-атаки).

2. Масштабировать спасателей


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

Что означает масштабирование в данном контексте? Шаблон трафика Netflix меняется в течение дня. Есть пиковые часы, как правило, в районе 6−9 вечера, но в разных частях мира это время наступает в разный момент. Пик трафика в регионе US-East наступает на три часа раньше, чем в регионе US-West, который на восемь часов отстаёт от региона EU.

При аварийном отключении US-East мы направляем трафик с Восточного побережья в регион EU, а трафик из Южной Америки — в US-West. Это необходимо для уменьшения задержки и наилучшего качества работы сервиса.

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

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

3. Прокси для трафика


Теперь, когда кластеры микросервисов масштабированы, мы начинаем проксировать трафик из пострадавшего региона в регионы спасателей. Netflix разработал высокопроизводительный межрегиональный пограничный прокси-сервер под названием Zuul, который мы выложили с открытым исходным кодом.

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

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

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

4. Смена DNS


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

Таково общее описание процесса, как происходит эвакуация Netflix из региона. Раньше процесс занимал много времени — около 45 минут (если повезёт).


Мы заметили, что бóльшая часть времени (примерно 35 минут) уходит на ожидание масштабирования спасательных регионов. Хотя AWS может предоставлять новые инстансы в течение нескольких минут, но в процессе масштабирования львиную долю времени отнимают запуск сервисов, разогрев, а также обработка других необходимых задач, прежде чем будет зарегистрирован UP в discovery.

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

Мы резервируем мощности во всех трёх регионах на случай отказа одного. Если мы уже платим за эти мощности, почему бы не использовать их? Так стартовал Project Nimble (проект «Шустрик»).

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

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

Во время эвакуации вместо традиционного масштабирования AWS мы внедряем инстансы из теневого кластера в рабочий кластер. Процесс занимает около четырёх минут, в отличие от прежних 35-ти.

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

Мы добавили фильтры в теневой кластер, чтобы эти инстансы не попадали в отчёты метрик. Иначе они загрязнят метрики и собьют нормальное рабочее поведение.

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

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

Let's block ads! (Why?)

Kotlin Playground

Привет, Хабр!

Совсем недавно мы выпустили 1.4.0 версию Kotlin Playground, о которой писал в нашем блог посте PMM Kotlin Рома Белов.

стоп… стоп...
Что еще за Kotlin Playground?

Kotlin Playground — полноценный редактор кода, написанного на Kotlin, который можно интегрировать на Вашу веб-страницу.

Как же это сделать?

Все до невозможности просто, стоит добавить одну script-строчку в header:

Аттрибут data-selector говорит нам о том, что все блоки code магически превратятся в исполняемый Kotlin код.

Давайте попробуем другие способы, например:

>

Либо через старый добрый советский npm:

npm install kotlin-playground -S

далее

import playground from 'kotlin-playground';

document.addEventListener('DOMContentLoaded', () => {
  playground('code');
});

Теперь мы научились "устанавливать" наш Kotlin Playground, давайте посмотрим как же он работает.

Из-за невозможности использования iframe на habr, будут представлены GIF-примеры. "Живые" примеры можно посмотреть на GitHub Pages, а также на различных сайтах, где playground уже завоевал сердца пользователей(об этом чуть позже).

Ну что ж, приступим.

Kotlin Playground поддерживает в данной версии 4 платформы, которые задаются с помощью аттрибута data-target-platform="platform" — это jvm, js, junit и canvas.

По умолчанию ставится платформа JVM. Вот самый простой пример:


Если вы хотите скрыть некоторые участки кода из-за их избыточности, то можно воспользоваться неким синтаксическим сахаром и поместить нужный Вам код между
//sampleStart и //sampleEnd.


Для того, чтобы воспользоваться автодополнением достаточно нажать Ctrl + Space или Cmd + Space.


Для исполнения тестов укажем платформу junit.


Вот один из примеров рисунка на канвасе с помощью Kotlin. Больше примеров можно посмотреть вот здесь.


Где же сейчас используется Kotlin Playground?


  1. Документация на официальном сайте Kotlin.
    Все новые части документации уже сопровождаются живыми примерами, например, What's new in Kotlin 1.2 или Kotlin Coroutines.
  2. Все примеры на Kotlin by Examples используют Kotlin Playground.
  3. На форуме Kotlin поддерживается playground. Достаточно использовать язык run-kotlin в markdown-синтаксиcе. Вот пример.
  4. С помощью WordPress plugin можно интегрировать наш playground в различные блоги, так мы и делаем в Kotlin Blog.

Где же мы рекомендуем использовать Kotlin Playground?
Без сомнений, данный компонент улучшает качество чтения и повышает выразительность примеров кода, поэтому мы призываем всех авторов к использованию этой библиотеки при написании:


  1. Учебных курсов.
  2. Сопроводительных материалов для слайдов или книг.
  3. Документаций для библиотек и фреймворков
  4. Примеров кода в блог постах

Более подробно почитать про все возможности Kotlin Playground можно тут, а сразу поиграть можно там.

Спасибо!
Have a Nice Kotlin :)

Let's block ads! (Why?)

Как Qlean использует Machine Learning?

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

ОСНОВНЫЕ ПРОБЛЕМЫ


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

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

В день распределяется от 50 заказов вручную, в сезон случается и вовсе адище – может быть и 300. Это занимает много времени и ресурсов.

Другая проблема – невыполненные заказы. Каждый день мы не выполняем примерно 2% заказов потому, что не можем или не успеваем найти на них клинеров. Если мы их не выполняем, дарим клиенту бесплатную уборку. Каждый день мы дарим около 20 бесплатных уборок, а в сезон эта цифра может достигать 200-300.

Как мы решаем эти проблемы?

1. Клинерское приложение

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

image

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

image

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

2. Автоназначение

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

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

Взяли готовые библиотеки

import numpy as np
import pandas as pd
from sklearn.ensemble import GradientBoostingClassifier
from sklearn.model_selection import train_test_split
from sklearn.metrics import roc_auc_score

Загрузили фичи
features = pd.read_csv('train/train.csv', header = 0)
X = features.drop(['cancel'], axis=1)
y = features.cancel

Разделили выборку на обучающую и тестовую
X_train, X_test, y_train, y_test = train_test_split(X, y, train_size=0.8, random_state=1234)

Обучили градиентным бустингом
gb_clf = GradientBoostingClassifier(learning_rate=0.2, n_estimators=70, max_depth=3, verbose=False, random_state=241)
gb_clf.fit(X_train, y_train)

Проверили на тестовой выборке
y_true = y_test
y_pred = final_gb_clf.predict_proba(X_test)[:,1]
roc_auc=roc_auc_score(y_true, y_pred)

roc-auc: 0.881929812245

Сделали прогноз

features = pd.read_csv('predict_features.csv', header = 0, index_col='order_id')
y_predict = gb_clf.predict_proba(features)[:,1]
print(y_pred)

Получили неплохую roc-auc = 0.88. И закинули в продакшн.

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

Для разных тестов мы иногда её вырубаем, и это влияет на наши бизнес-метрики.
Например, 7 апреля словили кучу невыполненных заказов, потому что до этого выключили модель.

image

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

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

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

Алгоритм

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

Результаты

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

Выводы

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

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

Let's block ads! (Why?)

Финансовая революция: как ИТ-стартапы меняют правила игры на Уолл-стрит

Когда в прошлом году свое IPO провела компания Snap (управляет проектом Snapchat), ей удалось продать 200 млн акций, ни одна из которых не давала владельцам права голоса и возможности влиять на бизнес. В ходе недавнего выхода на биржу стриминговый сервис Spotify не привлек средств. В 2016 году, инвесторы, желающие вложиться в Uber, могли сделать это через специально созданный банком Morgan Stanley фонд New Riders LP — при этом они не получали никакой информации о выручке Uber, издержках компании. Они не могли понять, жизнеспособна ли бизнес-модель компании.

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

Закат IPO


При недавнем размещении акций Spotify на Нью-Йоркской бирже, CEO компании даже не прилетел ради проведения официальной церемонии (как это часто делало руководство крупных компаний ранее), оставшись на родине в Швеции. Более того, он опубликовал статью в блоге, в котором заявил о том, что ничего особенно примечательного не случилось и это «лишь еще один день в нашем путешествии».

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

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

Аналогично и Spotify провела свое революционное прямое размещение акций, которое не подразумевает продажу акций самой компанией — и комиссию банков с Уолл-стрит в 7% в таком случае тоже не нужно.

Экономия на сборах при проведении IPO — лишь верхушка айсберга новой финансовой реальности. Гораздо важнее то, что сегодня компании, развивающиеся с привлечением венчурного капитала, вообще стремятся избежать выхода на биржу. Они «поднимают» деньги, постоянно продавая акции. Просто для этого им не обязательно использовать открытый рынок, а значит не нужно и сотрудничать с банками, которые являются единственной точкой входа на эти рынки. Только за первые три месяца 2018 года венчурные капиталисты вложили $28,2 млрд в акции частных компаний. За тот же период с помощью IPO компании привлекли лишь $17 млрд.

Кредиты тоже можно брать по-новому


Ситуация на долговом рынке весьма похожа. Привлечь заемный капитал без взаимодействий с банками невозможно: если компания хочет выпустить бонды, ей понадобится помощь банка, а если она хочет взять кредит, то выдает его тот же самый банк. При этом недавно Uber смогла занять $1,25 млрд у синдиката не-банковских фондов (Apollo, Bain, Blackrock и т.п.), избежав взаимодействий с Уолл-стрит. Банкиры привыкли очень внимательно оценивать риски, а компания постоянно генерирует убыток, а регулирующие органы не очень любят, когда банки дают деньги заемщикам, которые непонятно как их будут возвращать. Но теперь опыт Uber показывает, что подобные сделки можно проводить с помощью компаний, которые не подвержены столь жесткому прессу регулирования, но могут дать то же, что и банк, еще и без сопутствующих миллионных комиссий и сборов.

Но зачем тогда вообще выпускать акции? В ходе IPO Google компания привлекла $1,67 млрд, и чтобы получить эти деньги ей пришлось выпустить 19,6 млн акций по $85 каждая. Сегодня есть и другие способы привлечения сходных сумм. Пример — ICO мессенджера Telegram, который в ходе нескольких закрытых раундов продал отобранным инвесторам токенов на $1,7 млрд. При этом доли основателей проекта никаким образом не уменьшились, поскольку акций никто не продавал. Это еще один серьезный удар по Уолл-стрит.

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

Перспективы


Удивительно как раз то, что больше никто не стремится реализовать эту схему. Это серьезнейшая инновация, которая пока не вышла за пределы технологического сектора. Почему больше никто не проводит IPO по методу голландского аукциона, как сделала Google? Почему ничего не слышно о том, чтобы какая-то не-технологическая компания рассматривала вариант выхода на биржу «в стиле Spotify», привлечении займов «по методу Uber» или ICO «как у Telegram»? Ответ лежит в сложившемся балансе сил: за многие годы своей работы крупные компании стали слишком зависимы от банков и множества предлагаемых ими сервисов — а в не-технической сфере, чтобы бизнес серьезно вырос, чаще всего нужны годы, если не десятилетия. Напротив, технологические компании молоды и не живут в парадигме, при которой банки — единственный инструмент работы на финансовом рынке, поэтому они и не бояться действовать в обход.

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

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


Let's block ads! (Why?)

Разбираемся с понятием BPM

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

Определение по версии EABPM (Европейская ассоциация BPM) этого термина звучит следующим образом:

Управление бизнес-процессами (BPM) представляет собой системный подход для отражения, проектирования, выполнения, документирования, измерения, мониторинга и контроля как автоматизированных, так и неавтоматизированных процессов, для достижения целей и бизнес-стратегий компании. BPM охватывает осознанное, всеобъемлющее и все более технологичное определение, совершенствование, инновации и поддержание сквозных процессов. Благодаря этому системному и сознательному управлению процессами компании добиваются лучших результатов быстрее и гибче.
Я считаю, что это определение вносит больше путаницы, чем настоящего понимания BPM, особенно для людей, не изучавших глубоко эту тему.
В своей работе я постоянно пользуюсь графическими нотациями управления бизнес-процессов и BPMN. Считаю этот инструмент очень удобным, он помогает мне не только в разработке решений для бизнеса, но и в их обосновании. Ведь, как я уже много раз повторял, одна картинка стоит тысячи слов. Человек мыслит образами, и представить какой-то вид деятельности при помощи картинки (схемы) ему намного проще.

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

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

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

Как появилось BPM


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

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

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

  1. Описание рабочего места;
  2. Должностная инструкция сотрудника;
  3. Требования техники безопасности и т.д.

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

А что делать, если появляется необходимость быстро изменить работу целой организации? А если еще при этом внедряется автоматизация? Ответом на эти запросы и стало появление BPM.

О том, что такое бизнес-процесс, я уже писал («Что такое бизнес-процесс и описание бизнес процесса»), а потому повторять основные положения и определение самого бизнес-процесса не буду. А на понятии управление бизнес процессами давайте остановимся подробнее.

Об управлении бизнес-процессами простыми словами


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

Определение от меня:

Управление бизнес-процессами (BPM) – это управление действиями (автоматизированными и неавтоматизирвоанными) в коллективе посредством бизнес-процессов.
Чтобы управлять любыми бизнес процессами необходимо:
  1. Описать сами бизнес-процессы.
  2. Внедрить в работу; коллектива; описанный бизнес процесс
  3. Назначить людей, ответственных за бизнес-процессы, так называемых, стек-холдеров или владельцев бизнес-процессов.

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

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

Необходимо исходить из понимания: процессный подход — это управление целым через управление частями.

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

  • BPM – это методология. т.е. набор основных принципов и подходов к построению нотаций и самой организации работы при помощи бизнес-процессов.
  • BPMN – нотация(язык), в которой строятся нотации, в том числе, исполняемые;
  • BPMS – ;IT система исполнения, построенная по определенным правилам, заданных в методологии;

Если проводить аналогию с наукой, то BPM — это прежде всего подход, своего рода мировозрение. BPMN — это методы и алгоритмы решения конкретных задач. Например, доказательства для теорем или набор методов для создания проекта обеспечения электричеством объекта (производства, многоквартирного дома). А, в свою очередь, BPMS- это уже готовые прикладные решения, которые можно “включить” и они уже будут работать. Для математики это — готовые решения задач, имеющих практическое значение. Для физики — непосредственное реализации той самой электропроводки и подключение объектов. Для сферы айти — готовый программный код.

Исполняемые и неисполняемые бизнес процессы


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

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

Для исполняемой нотации требуется определенная IT-среда — BPMS. При этом даже неисполняемые я рекомендую выполнять в BPMN, так как здесь сама среда помогает выявлять возможные ошибки, противоречия, что повышает грамотность и точность описания бизнес-процесса.

Отличия процессного и функционального подходов


Еще один важный факт, который поможет понять, что же такое на самом деле «управление бизнес-процессом». Мы уже выяснили, что управление – это создание определенной последовательности действий сотрудников. Т.е. в результате каждая автоматизированная система работает определенным образом. А человек – обязан по инструкции также выполнять заданные по инструкции действия.

При этом также необходимо знать:

Для стратегического планирования и оценки работы компании “в целом” лучше использовать функциональное моделирование и нотации (например IDF0). Об этом я подробно писал в статье “Знакомство с нотацией IDEF0 и пример использования”. Здесь вы сможете исходить из желаемого результата и выстраивать последовательность функций “черных ящиков”, необходимых для его достижения.

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

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

Необходимо понимать:

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

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

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

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

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

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

Описание работы с BPM


Для лучшего понимания того, что такое BPM (управление бизнес-процессами), я приведу пример последовательности действий бизнес-аналитика в рамках этой методологии:

Опрос людей (сотрудников компании). Понимание того, каким образом производится работа в каждом конкретном случае.

Документирование бизнес-процесса на основе полученных данных. На этом этапе аналитик получает описание бизнес-процесса «как есть».

Изучение полученного бизнес-процесса с точки зрения слабых мест и возможности оптимизации:

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

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

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

Далее – снова проработка изменений в инструкциях и программных системах. И новый этап внедрения в эксплуатацию.

Жизненный цикл процесса в BPM


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

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

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

Плюсы и минусы BPM


К числу преимуществ использования BPM относятся:

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

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

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

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

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

Минусы BPM, как это часто бывает, находятся там же, где и преимущества:

Высокая степень детализации процессов мешает восприятию работы бизнеса для стратегического планирования.

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

Бизнес-процесс статичен и практически не подлежит корректировкам «изнутри». Исполнитель получает четкую последовательность действий и уже не может проявить инициативу. В результате, любую ошибку исполнители будут повторять из раза в раз, пока она не будет исправлена в самом бизнес-процессе.

Каким компаниям подходит BPM


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

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

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

Подробнее о том, как именно управлять бизнесом при помощи бизнес-процессов я рассказывал уже в прошлых статьях, и буду говорить еще не один раз. Здесь я постарался максимально просто пояснить различия между терминами BPM, BPMS, BPMN и описать само понятие «управление бизнес-процессами». Без этих базовых знаний разобраться в процессном подходе невозможно.

Вопросы и ответы


В чем отличие функционального моделирования от процессного?

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

Какие понятия входят в BPMN?

В первую очередь, это непосредственно система BPMN, а также описание нотаций BPMS. О них я писал в этой статье, и подробно — в предыдущих статьях (см. рекомендуемые ссылки в конце публикации). Кроме того, не так давно появились новые понятия — DMN и CMMN. На них я сейчас подробно останавливаться не буду. Постараюсь описать новые понятия и их особенности в будущих публикациях.

Зачем нужно в построении нотаций столько сложностей и разные подходы?

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

С чего начать работу с BPM?

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

Можно ли использовать BPM для неавтоматизированных систем?

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

Для лучшего понимания тематики рекомендую статьи:


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

Let's block ads! (Why?)

Когда компьютеры были людьми…


Практически любое изложение истории компьютеров начинается с упоминания изобретенного в древнем Египте абака. В зависимости от детальности изложения далее перечисляются изобретения китайского варианта абака, различных видов счетов с костяшками, вычислителей на основе зубчатых колёс, изобретения и промышленного выпуска арифмометров Тома де Кальмару, изобретения разностной машины Чарльзом Бэббиджем и т.д. вплоть до появления современных компьютеров. От абака до iPad история компьютеров представляется как цепочка изобретений изделий из дерева, металла и других материалов.
Однако, первые компьютеры (computers) были людьми! И эта статья о том, как они из людей превратились в то, что мы имеем сейчас.

Компьютеры — это люди


О первых компьютерах-людях можно почитать в Википедии в разделе об этимологии английского слова «computer».
Согласно Оксфордскому Словарю Английского Языка, первое известное использование слова «computer» обнаружено в книге английского писателя Ричарда Брейтвейта, изданной в 1613 году. Это использование термина относится к человеку, который выполнял некие расчеты. Слово использовалось в английском языке в том же значение вплоть до середины 20-го века. С конца XIX века слово стало приобретать более знакомое нам значение — машина, которая выполняет вычисления [1].
Итак, первые компьютеры были людьми. Но что же они вычисляли?
В книге Gleick, James. «The information: a history, a theory, a flood» я нашел интересное упоминание о них.
Начиная с 1767 года и вплоть до своего расформирования Совет Англии по Определению Долготы (Commissioners for the Discovery of the Longitude at Sea) выпускал ежегодный Морской Альманах (Nautical Almanac), в котором были представлены таблицы для определения положения Солнца, Луны, звезд, планет и спутников Юпитера. Совет был заказчиком таблиц альманаха. Подрядчиком же была знаменитая Гринвичская лаборатория.
Страницы из альманаха

В течение следующего полувека эти таблицы подготавливала команда примерно из тридцати профессионалов. Их профессия называлась computer. Команда состояла в основном из мужчин, но некоторое время в ней работала и женщина — Mary Edwards of Ludlow, из Шропшир.

Мемориальная доска в честь первой «женщины-компьютер»
Их кропотливый труд хорошо по тем временам оплачивался — 70 фунтов стерлингов в год.
Вычисление было «кустарным» (индивидуальным) производством. Для каждого расчёта был расписан пошаговый алгоритм. Больших математических познаний для работы не требовалось, однако требовалось высокая концентрация, внимательность и аккуратность. Способных к этому людей искали и отбирали по всей Англии.
В любом случае первые компьютеры, будучи людьми, делали ошибки, поэтому одно и то же задание обрабатывалась дважды и разными людьми.
Компьютеры-люди быстро сообразили, что можно сэкономить массу времени, если просто копировать (переписывать) результаты работы друг-друга. Когда виновники были пойманы за руку, руководство перешло (выражаясь современным языком) к распределённой архитектуре вычислений. Компьютеров стали специально набирать в удалённых друг от друга поселениях. Все члены команды стали работать исключительно на дому.
Для управления потоком информации в проекте существовал специальной сравниватель-корректор результатов (компаратор).
Связь между компьютерами и компаратором проходила по почте, или курьерами, передвигавшимися пешком или на лошадях. Пересылка одного сообщения занимала несколько дней.
Внедрение логарифмов в практику вычислений резко снизило трудоёмкость вычислений, однако потребность в них резко возросла.
Опыт «долготой команды» был использован позднее в больших коммерческих проектах по составлению и публикации самых разных таблиц. Компьютеры появились в штатах банков, страховых и торговых контор.
Вам это ничего не напоминает?
Кстати, в Америке первый компьютер был принят на работу относительно поздно, в 1892 году. Об этом свидетельствует (первое из подобных) объявление о приёме на работу в газете «Нью-Йорк таймс» от 2 мая 1892. Оно гласило: в ВМС США требуется компьютер (Computer wanted) со знанием алгебры, геометрии, тригонометрии и астрономии [2].

Механизация труда людей-компьютеров


Арифмометры значительно удешевили стоимость расчётов и, как это не странно, привели к появлению ещё большего числа людей-компьютеров во всех развитых странах.
В СССР учёт и контроль были краеугольными камнями плановой экономики. Профессия людей-компьютеров (расчётчиков или техников-расчётчиков) стала массовой. Людей этой профессии готовили в техникумах. Кроме того, эту специальность преподавали как дополнительную бухгалтерам, технологам и т.д.
Моя мать работала в районном Бюро Технической Инвентаризации в большом сибирском селе. В её задачу входило наряду с ведением бухгалтерии помогать техникам в вычислении стоимости строений и сооружений. Для проведения этих вычислений существовали объёмные справочники с разъяснениями, формулами и вспомогательными таблицами. Для ускорения вычислений использовался массовый советский арифмометр Феликс.

Арифмометр Феликс был назван так в честь легендарного основателя ЧК Феликса Дзержинского. Всего в СССР было выпущено несколько миллионов этого аппарата. Он стоил примерно десятую долю средней месячной зарплаты.

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

Машиносчетная станция ордена Ленина треста ЧМС: группа перфорации (машины перфораторы и контрольники) Январь 1965 Автор: В. Петров. Место съемки: г. Череповец и Череповецкий район. Источники: Череповецкое музейное объединение [3]

Такая станция существовала даже в нашем небольшом селе и производила в основном подсчёты трудовых успехов и расчёты зарплаты сотрудникам районных предприятий, колхозов и совхозов. Бухгалтера на этих предприятиях подготавливали первичные ведомости, которые сотрудницы МСС просчитывали на арифмометрах.
Как я узнал позже, вплоть до 70-х годов в СССР существовали и огромные Машиносчётные Центры, прототипы более поздних Вычислительных Центров, оснащённых уже ЭВМ.
В начале своей трудовой деятельности я познакомился с одним известным в узких кругах математиком. После окончания Московского Университета он был распределён на работу на одно очень закрытое предприятие на Урале (в народе такие предприятия тогда называли «ящиками»). Сотрудники огромного отделения, куда он попал, занимались расчётом «разных баллистических траекторий», как он выражался (не уточняя, каких). Алгоритмы расчёта были сложные, использовались итерационные методы. Задача моего знакомого состояла, выражаясь современным языком, в написании «программ» на языке, чем-то схожим с ассемблерным языком или байткодом.
Отдельные элементарные шаги алгоритма записывались в специальную таблицу в левую колонку. Результаты вычисления надо было записывать справа. Язык включал условия окончания вычислений и переходы на новое место алгоритма. Такой переход означал, как правило, что дальнейшие вычисления должны были проводиться другим специалистом, владеющим арифмометром другого типа или логарифмической линейкой

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

Вместо эпилога


Укоренившаяся в умах широкой публики и даже специалистов история ИТ в кратком изложении выглядит так: Да, древние греки и китайцы изобрели и пользовались абаком. И после этого разные изобретатели типа Бэббиджа изобретали разные курьезные, но мало полезные машинки для механического счёта. И только после того, как в середине 20-го века на ровном месте были изобретены первые ЭВМ, началось подобное взрыву развитие и применение информационных технологий на основе программирования.
В реальности всё было по-другому. Первыми компьютерами были люди. Эта профессия становилась все более массовой. За счёт механизации вычислений производительность труда людей-компьютеров постоянно росла, расширялись и появлялись новые области применения их труда. Среди них происходила специализация. На определенном этапе среди людей-компьютеров появились люди, занимавшиеся тем, что стало потом называться программированием. Когда появились первые промышленные ЭВМ, рынок для их использования был уже сформирован. Замена людей-компьютеров (в СССР — расчётчиков) на ЭВМ и потом на персональные компьютеры растянулась на несколько десятилетий.

Ну и под конец — одно пожелание. Если Вы, дорогой читатель, в очередной раз разозлитесь почему-либо на свой компьютер, успокойтесь и перестаньте злится. Вспомните, что ещё совсем недавно компьютеры были людьми.
Первое изображение: geralt

Let's block ads! (Why?)

Ищем спикеров на Java MeetUp

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

Мы знаем, как важно общаться с людьми из других команд и проектов, иметь возможность спросить совета, обсуждать только что появившиеся технологии и поделиться опытом. Поэтому 16 мая, в московском офисе Райффайзенбанка, мы организуем наш первый открытый Java MeetUp.
Подробности под катом.
Мы выступим с одной, но очень обширной темой. Виктор Цветков (avessal0m), Senior Architect RBO Team, расскажет про CRDT: отношения на расстоянии. Как улаживать конфликты в распределенных системах

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

Нам интересны доклады:

  • По функциональному и реактивному программированию
  • Java Core наше все
  • Использование Kotlin
  • Автотестирование и использование инструментов тестирования
  • Применение паттернов и «велосипедостроение»
  • BigData

Расскажите о своей работе! Предложите тему, которой хотели бы поделиться, а мы поможем вам в подготовке. Структура доклада должна предполагать 20-25 минут на сам доклад и 5 минут на вопросы. Презентации на этапе подачи заявки отправлять не обязательно.
Чтобы отправить заявку, заполните форму! Заявки принимаются до 4 мая включительно

Let's block ads! (Why?)

[Перевод] Комиксы Даниэля Стори (часть 3)

Let's block ads! (Why?)

Как испортить полезный сервис (на примере Яндекс.Карт)

У Яндекса есть замечательный продукт — Яндекс.Карты. Значение этого инструмента уже, наверное, трудно переоценить: многие из нас пользуются Картами каждый день.

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

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

Это трасса М4. Наверное, лучшая трасса в России. Действительно мировой уровень: можно прямо после МКАД поставить машину на круиз-контроль и без лишнего напряжения за 4 с небольшим часа доехать, например, до Воронежа. Дорога сделана по всем стандартам. В частности, пешеходные переходы видно издалека. Знаки везде есть, они выполнены со светоотражающим покрытием.

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

Скорее всего, чья-то чугунная голова во исполнение Высочайшего повеления о снижении смертности на дорогах, додумалась привести мероприятия, направленные на снижение, и прочая, и прочая… Вышло дико. Водитель, который хочет узнать, нет ли впереди ничего непредвиденного — аварий, пробок, перекрытий — вынужден много-много раз прочесть, что впереди будет пешеходный переход. Зачем?? На местности, повторюсь, переходы и так отлично видны, дорога построена по всем правилам.

Вот ещё пример. Москва:

Такой дурью маются уже достаточно давно. «Аварийно-опасный участок», сразу 4 предупреждения, налепленные почти что на одно и то же место. Какую конструктивную информацию дают эти предупреждения, которыми буквально утыкан весь МКАД на Яндекс.Картах? Водитель что должен сделать? Memento mori?

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

И вот ещё какой вред от такого подхода. Например, это действительно полезное предупреджение:

может быть проигнорировано другими участниками движения, потому что все уже привыкли, что за восклицательным знаком на карте скрывает спам от ЦОДД.

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

Пример краткого и максимально понятного сообщения:

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

Здесь тоже всё понятно: ответ на вопрос «что случилось и почему затор» считывается пользователем мгновенно

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

***

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

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

И жаль, что Яндекс пускает этот процесс на самотёк.

Let's block ads! (Why?)

Генератор статических сайтов metalsmith

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

  • Прототип web-интерфейса
  • Блог с редко обновляемым контентом
  • Отдельная статическая часть другого web-приложения
  • Сайт-визитка или landing-page
  • Онлайн-документация

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

Metalsmith


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

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

function plugin() {
  return (files, metalsmith, done) => {
    Object.keys(files).forEach(name => console.log(name));
    done();
  };
}


Хотя, если вам необходимо (например для отладки), вы можете воспользоваться моим плагином — metalsmith-inspect-files, который визуализирует дерево файлов и каталогов в момент своего использования в цепочке плагинов.

Делаем простой блог


Для того, чтобы продемонстрировать возможности инструмента мы сделаем с его помощью простой статический блог, весь код доступен в репозитории. Конфигурация для сборки находится либо в metalsmith.json файле, либо непосредственно в скрипте, причем последнее, на мой взгляд наиболее предпочтительно, потому что позволяет более гибко конфигурировать процесс сборки:
const Metalsmith = require('metalsmith');
const timer = require('./plugins/timer');
const jade = require('metalsmith-jade');
const layouts = require('metalsmith-layouts');
const permalinks = require('metalsmith-permalinks');
const collections = require('metalsmith-collections');
const less = require('metalsmith-less');
const ignore = require('metalsmith-ignore');
const cleanCss = require('metalsmith-clean-css');
const metalsmithInspectFiles = require('metalsmith-inspect-files');
const partial = require('metalsmith-partial');

Metalsmith(__dirname)
    .source('./source')
    .metadata({ // глобальные переменные доступные в каждом шаблоне
        title: 'Example blog',
        layout: 'index.jade',
        menuLinks: [
            {title:'Home', url: '/'},
            {title:'Articles', url: '/articles/'},
            {title:'About', url: '/about/'}
        ]
    })
    .destination('./build')
    .clean(true)
    .use(collections({ // коллекции страниц определяемые шаблоном
        articles: {
            pattern: [
                'articles/**',
                '!articles/index.jade'
            ],
            sortBy: 'title'
        },
    }))
    .use(partial({ // шаблоны вставки внутри других шаблонов
        directory: './partials',
        engine: 'jade'
    }))
    .use(jade({ // шаблонизатор
        useMetadata: true
    }))
    .use(permalinks({ // красивые url /about.html => /about/index.html
        relative: false
    }))
    .use(layouts({ // шаблон-каркас одинаковый для всех страниц
        engine: 'jade',
        default: 'index.jade',
        pattern: '**/*.html'
    }))
    .use(less()) // компиляция less в css
    .use(cleanCss()) // сжатие css
    .use(ignore([ // фильтрация файлов
        '**/*.less'
    ]))
    .use(metalsmithInspectFiles())
    .build((err, files) => {
        if (err) { throw err; }

        timer('Build time: ')();
    });


Наш блог состоит из нескольких отдельных обособленных страниц и одной коллекции однотипных страниц. Структура исходных директорий (без внешних директорий layouts и partials):
      |-articles
      |   |-article-one.jade
      |   |-article-three.jade
      |   |-article-two.jade
      |    -index.jade
      |-assets
      |   |-images
      |   |    -favicon.png
      |   |-js
      |   |    -turbolinks.min.js
      |    -stylesheets
      |        -main.less
      |-about.jade
       -index.jade


А так выглядит результат работы(содержимое папочки build):
      |-about
      |    -index.html
      |-articles
      |   |-article-one
      |   |    -index.html
      |   |-article-three
      |   |    -index.html
      |   |-article-two
      |   |    -index.html
      |    -index.html
      |-assets
      |   |-images
      |   |    -favicon.png
      |   |-js
      |   |    -turbolinks.min.js
      |    -stylesheets
      |        -main.css
       -index.html


Сразу заметно работу плагина metalsmith-permalinks, который преобразует файлы *.html, чье имя отлично от index.html, в соответствующие директории с index.html, для того, чтобы url этих страниц выглядел более приятно. Основными особенностями любого генератора статических сайтов являются шаблоны (layouts и partials), как средство для соблюдения принципа DRY(Don't repeat yourself). В качестве языка шаблонизации использован jade(или pug), популярный среди представителей javascript-коммьюнити. Так в нашем случае выглядит основной layout, представляющий каркас страницы:
doctype html
html
    head
        meta(charset='utf-8')
        meta(name='description' content='Simple metalsmith blog')
        meta(name='viewport' content='width=device-width, initial-scale=1.0')
        title=title
        link(href='/assets/stylesheets/main.css', rel='stylesheet')
        link(rel="icon" href="/assets/images/favicon.png")
    body
        .container
            nav!=partial('menu.jade', {menuLinks, currentPath: path})

            section.page-content!=contents

            footer!=partial('footer.jade')

    script(src='/assets/js/turbolinks.min.js')


Он в свою очередь использует шаблоны-вставки (partials), функциональность которых реализуется плагином metalsmith-partial (обратите внимание на явную передачу переменных для отрисовки шаблона). Включаемый шаблон меню выглядит следующим образом:
ul.menu
    each page in menuLinks
        - isActive = ('/'+currentPath+'/').startsWith(page.url) && (page.url != '/' || page.url === currentPath + '/')
        li(class=(isActive ? 'active' : ''))
            a(href=page.url)=page.title


Для итерации по страницам коллекции (articles) используется плагин metalsmith-collections, сами страницы для генерации списка доступны в переменной-массиве с именем коллекции.

Turbolinks


Библиотека turbolinks позволяет 'оживить' содержимое, отдаваемое сервером со статикой, добавив SPA-поведение при переходе по ссылкам внутри нашего сайта, загружая посредством AJAX содержимое каждой новой страницы и заменяя им текущее. В случае, если по какой-то причине запрос оказался долгим (более 500мс), будет показан progress-bar, который сообщит пользователю о том, что переход на другую страницу происходит (стандартные средства, с помощью которых браузер показывает это при обыкновенном переходе по ссылке, не будут задействованы по причине отсутствия перезагрузки страницы), хотя и медленно. Turbolinks в данном примере подключается в виде минифицированного файла-дистрибутива, так сказать «for the sake of simplicity». В случае, если javascript-часть сайта не такая простая, следует использовать что-то в духе metalsmith-webpack-2 или gulp-metalsmith.

Полезные ссылки и выводы


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

Let's block ads! (Why?)

Как IaaS помогает компаниям в сфере торговли: ритейл-кейсы

Недавно мы рассказали, как меняется бизнес по доставке товаров — рост сегмента e-commerce ставит перед ним новые вызовы, со многими из которых позволяет справляться IaaS. Сегодня мы продолжим говорить о ритейле и посмотрим, кто и как использует виртуальную инфраструктуру.


/ Фото jenny.nash712CC

Сегодня IaaS идет в своем развитии рука об руку с e-commerce. Согласно аналитическим данным Accenture, объем инвестиций в эту сферу с 2011 по 2016 год вырос в 4 раза — до 15 млрд долларов. Крупнейшие ритейлеры не просто делают ставки на виртуальную инфраструктуру, но перестраивают свои бизнес-модели на основе внедрения IaaS. На то есть несколько причин.

Уровень доступности


Ян Бристоу (Ian Bristow), основатель онлайн-магазина Internet Fusion — одного из старейших британских онлайн-ритейлеров в сегменте спортивной одежды и аксессуаров, — рассказал, как его компания переехала в «облако». По мере роста клиентской базы компания самостоятельно наращивала мощности ИТ-инфраструктуры, но столкнулась с проблемой доступности площадок магазина для различных сегментов аудитории.

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

Большая часть ИТ-инфраструктуры Callaway Golf, крупного производителя и продавца премиальных продуктов для гольфа, до 2009 года была физической. ЦОДы располагались в разных штатах, обслуживать их и работать с данными было сложно. При этом компания ведет бизнес и за рубежом. Еженедельное обслуживание серверов приводило к простою некоторых иностранных офисов.

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


/ Фото PolycartCC

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

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

Еще один процесс, в котором важен высокий уровень доступности, — бэк-офис. Ритейлер спортивного питания FitnessBar.ru долгое время управлял только одним складом и интернет-магазином, но однажды решил вырасти в розничную сеть. До открытия магазинов компания обходилась одним серверным помещением. С выходом в офлайн и ростом нагрузки появлялись новые вызовы вроде обеспечения совместного доступа к системам учета товаров. Вместо покупки дополнительного оборудования FitnessBar.ru выбрал облачную среду ИТ-ГРАД. Миграция была проведена за один вечер, и ритейлер продолжил масштабировать бизнес, сохраняя высокий уровень доступности всех сервисов и бесперебойную работу магазинов.

Работа с рекомендательными сервисами


Крупный онлайн-магазин одежды и аксессуаров ASOS работает с 2000 года. В 2016 году его руководство приняло решение перенести часть задач в виртуальную инфраструктуру. Одна из них — сбор и обработка данных для рекомендательных сервисов.

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


/ Фото perzon seoCC

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

Глава Lesara Роман Кирш (Roman Kirsch) говорит: «Мы не просто знаем, какие новые стили популярны сейчас, но и можем определить, какие ретро-тренды возвращаются, какие стили перестают быть актуальными, и это помогает нам четко управлять своей продукцией». Со всеми этими задачами Lesara помогает справляться IaaS.

Операционная деятельность


Рост сегмента онлайн-ритейлеров сказывается на работе обычных магазинов. Продажи в американских универмагах с 2000-го по 2016 год снизились на треть. Поэтому многие традиционные магазины превращаются в омни- и мульти-канальные — то есть присутствуют и в онлайне, и в офлайне одновременно. Это влечет за собой принятие новых технологий. В частности ожидается, что к 2020 году проникновение облачных технологий в ритейл составит 70%. Уже сейчас многие компании используют IaaS в своем бизнесе. И вот как:
  • Платежные системы. Американская сеть универмагов Nordstrom, управляющая сотнями магазинов в большинстве штатов, в прошлом году запустила облачную POS-систему. Такой подход позволяет быстрее обслуживать клиентов и эффективно использовать данные — сведения о товарных запасах и популярности товарных групп, информацию о клиентах. IaaS в данном случае позволяет покупателям работать с любой платформой — веб-версией сайта ритейлера или мобильным приложением.
  • Коммуникация. Крупная сеть российских магазинов детских игрушек «Мир Hamleys» работает с использованием виртуальной инфраструктуры. Десятки торговых отделов соединены в рабочие группы вокруг единой IaaS-платформы. В облако ИТ-ГРАД вынесено и несколько каналов коммуникации: почта, облачная телефония, линия поддержки, внутрикорпоративная связь. Это устраняет проблему географической разрозненности магазинов — все сотрудники остаются на связи — и позволяет централизованно контролировать процессы.

В сети товаров для домашних животных Pets at Home в «облако» решили вынести приложение Sales Assist для общения продавцов и консультантов с клиентами. Оно связывает данные нескольких сотен магазинов с приложением. Так покупатели могут получить точную информацию об ассортименте и выбрать подходящую точку продаж.

Масштабирование бизнеса


Dixons Carphone, крупнейший в Европе телекоммуникационный ритейлер и продавец электротехники образовался в 2014 году после слияния Dixons Retail и Carphone Warehouse.

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

/ Фото JD HancockCC

Еще один пример «виртуализации» сложной системы — электронная торговая площадка «Биржа вагонов» RailCommerce. Ключевой фактор в этом кейсе — вновь масштабирование. Оно приобретает большое значение в случае с маркетплейсами товаров и услуг.

Облако позволяет бирже динамично наращивать узлы системы для различных функций, когда возникают такие требования. Кроме того, RailCommerce работает на территории двух стран — России и Казахстана, — поэтому компания должна соблюдать фактически два закона о защите данных. ИТ-ГРАД помог RailCommerce решить эту задачу.



P.S. О чем мы пишем в Первом блоге о корпоративном IaaS:
P.P.S. Пара постов по теме из блога на Хабре:

Let's block ads! (Why?)