Облачные сервисы

Когда клиент размещает свой сайт, почту или другой сервис в нашем облаке на базе VMware, то в 90% случаев в качестве граничного устройства используется виртуальный маршрутизатор NSX Edge. Это решение выполняет для виртуального дата-центра функции межсетевого экрана, NAT, DHCP, VPN и так далее.

Но если, например, клиент привык получать на межсетевом экране расширенную аналитику по трафику и более детальный мониторинг, то в облаке ему может понадобиться межсетевой экран нового поколения (Next Generation Firewall, NGFW). К тому же, такие решения предоставляют модули IPS и IDS, антивирус и другие фишки. Для клиентов c такими запросами в качестве одного из решений мы предлагаем NGFW как сервис на базе FortiGate. В статье покажу, как и для чего мы организуем переезд в этот сервис.

Когда стоит рассмотреть NGFW как сервис

Чаще всего наши клиенты рассматривают альтернативы NSX Edge, если на уровне межсетевого экрана нужно решать дополнительные задачи:

• обнаруживать и предотвращать вторжения с помощью модулей IPS и IDS;

• обеспечивать дополнительную антивирусную защиту;

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

• интегрировать политики безопасности с каталогами AD и IDM;

• отслеживать и расследовать сложные атаки и инциденты с помощью продвинутой аналитики.

Вместо сервиса можно выбрать и приватное решение закупить виртуальные или физические ресурсы в частное облако под нужды заказчика. К примеру, частное решение разворачивается, если нужен межсетевой экран, сертифицированный по требованиям ФСТЭК. Но у частного варианта есть минус: если проект живет в приватном облаке долго, рано или поздно может возникнуть проблема сайзинга. Например, мы закупили для проекта заказчика межсетевые экраны с небольшим запасом, под этот объем закупили лицензии. Через несколько лет трафик вырос сильнее ожидаемого. Заказчик захотел расширить пропускную способность и уперся в пакетную политику лицензирования вендора: докупить ровно необходимое количество лицензий было нельзя.

NGFW как сервис позволяет избежать проблем с сайзингом, если предсказать рост пропускной способности нельзя. В этом случае заказчику на одном из межсетевых экранов предоставляются выделенные сетевые сегменты виртуальные домены (VDOMы). Трафик предоставляется по принципу Pay-as-you-go: заказчик платит только за ту пропускную способность, которую потребил на виртуальном домене. Количество VDOMов можно увеличивать: в сервисе за это отвечает сервис-провайдер, заказчику достаточно сформулировать запрос.

Вот как упрощенно выглядит сегментация:

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

Как происходит переезд

При переезде из NSX Edge есть один нюанс: у клиента поменяется внешняя адресация. Мы заранее предупреждаем об этом клиента и затем идем пошагово по нашему плану.

Перенос "как есть". На первом этапе вся защита переносится в том виде, в котором ее настроил заказчик.

1. Общаемся с клиентом, выясняем его задачи и уточняем, какие модули NGFW нужны.

2. Запрашиваему клиента необходимую информацию:

   • как сегментирована сеть,

   • какие VLANы используются,

   • какие типы сетей: routed, isolated,

   • как клиент выходит в интернет,

   • какая полоса пропускания,

   • как все мониторится,

   • какие NAT-трансляции используются.

   Так мы выстраиваем архитектуру будущего решения.

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

4. Анализируем конфигурацию и заводим сети клиентов: создаем отдельный VDOM на FortiGate и подаем туда VLANы.

5. Переносим все правила доступа со старого оборудования.

6. Создаем NAT-трансляции с новыми адресами, составляем IP-план и отправляем его клиенту.

7. Преднастраиваем VPN-туннели.

8. Согласовываем время даунтайма во время миграции. Общее время зависит от количества VLANов.

9. Переводим трафик с минимальным простоем. Чаще всего делаем это ночью, чтобы влияние переезда было минимальным. Тушим интерфейс на Edge и поднимаем интерфейс с таким же адресом на FortiGate. Параллельно с этим клиент меняет DNS. На каждый VLAN достаточно несколько минут.

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

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

Включение модулей безопасности. Здесь мы настраиваем модули NGFW: IPS, контроль приложений, антивирус, всю работу делаем в тесной связке с клиентом. Сначала мы создаем профили безопасности в режиме мониторинга и только наблюдаем за срабатываниями, но не блокируем их. Например, у нас начал срабатывать модуль IPS. Сначала мы смотрим, что это за трафик, и сообщаем клиенту. Решение принимаем совместно: блокировать такие срабатывания, или это легитимный трафик и срабатывание оказалось ложным. Только после совместного обсуждения включаем правила в режиме блокировки.

Как решаются особые кейсы NGFW+

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

• система управления журналами безопасности,

• VPN-клиенты,

• сервис защиты веб-приложений (WAF),

• другие.

Кратко расскажу, как эти решения работают совместно.

Журналы событий FortiAnalyzer вместе с NGFW помогают видеть более детальную картину трафика. Например, есть модуль индикаторов компрометации: мы видим, что какие-то хосты ломятся на скомпрометированные IP-адреса. Этот трафик блокируется, а хосты мы проверяем антивирусом.

Отдельной политикой на NGFW можно настроить передачу трафика по syslogу в клиентскую SIEM-систему. Или можем просто передавать журналы в клиентский лог-коллектор через IPsec.

FortiAnalyzer также помогает организовать долговременное хранение журналов.

Дополнительный VPN-шлюз для доступа к внутренней инфраструктуре можно настроить с помощью FortiClient VPN. Это средство для защиты конечных точек (endpoint-защиты). С его помощью доступ на удаленный сервер настраивается определенным группам пользователей.

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

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

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

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

Единственный случай, когда лучше выбрать комплексный сервис в виде частного решения, необходимость сертификации NGFW или WAF по требованиям ФСТЭК. Администрировать такое решение тоже может сервис-провайдер, но это будет межсетевой экран или WAF под конкретного заказчика.

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

Каждый сервис использует свои решения для маскировки номеров клиентов и курьеров. В данной статье я расскажу, как сделать это с помощью key-value хранилища в Voximplant.

Как это будет работать

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

У нас будет только один нейтральный номер, на который будут звонить и клиент, и курьер. Номер мы арендуем в панели Voximplant. Затем создадим некую структуру данных, где клиент и курьер будут связаны между собой номером заказа (то есть ключом в терминологии key-value storage).

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

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

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

Перейдем непосредственно к реализации.

Вам понадобятся

• верифицированный аккаунт Voximplant, который можно создать здесь;

• приложение Voximplant со сценарием и правилом для сценария (их мы создадим вместе);

• телефонные номера для тестов: арендованный в панели номер, номер клиента, курьера и оператора (в тестовой реализации номер оператора можно не указывать).

1) Чтобы начать разработку, войдите в свой аккаунт: manage.voximplant.com/auth. В меню слева нажмите Приложения, затем Создать приложение в правом верхнем углу. Дайте ему имя, например, numberMasking и снова кликните Создать.

2) Зайдите в новое приложение, переключитесь на вкладку Сценарии и создайте сценарий, нажав на +. Назовём его kvs-scenario. Здесь мы будем писать код, но об этом чуть позже.

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

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

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

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

6) Далее необходимо верифицировать аккаунт, чтобы использовать этот номер для звонков.

Отлично, структура готова, осталось заполнить key-value хранилище и добавить код в сценарий.

Key-value хранилище

Чтобы сценарий заработал, нужно положить что-то в хранилище. Это можно сделать, воспользовавшись Voximplant Management API. Я буду использовать Python API client, он работает с Python 2.x или 3.x с установленным pip и setuptools> = 18.5.

1) Зайдем в папку проекта и установим SDK, используя pip:

python -m pip install --user voximplant-apiclient

2) Создадим файл с расширением .py и добавим в него код, при выполнении которого данные о заказе попадут в key-value хранилище. Применим метод set_key_value_item:

from voximplant.apiclient import VoximplantAPI, VoximplantExceptionif __name__ == "__main__":    voxapi = VoximplantAPI("credentials.json")        # SetKeyValueItem example.    KEY = 12345    VALUE = '{"courier": "79991111111", "client": "79992222222"}'    APPLICATION_ID = 1    TTL = 864000        try:        res = voxapi.set_key_value_item(KEY,            VALUE,            APPLICATION_ID,            ttl=TTL)        print(res)    except VoximplantException as e:        print("Error: {}".format(e.message))

Файл с необходимыми credentials вы сможете сгенерировать при создании сервисного аккаунта в разделе Служебные аккаунты в настройках панели.

APPLICATION_ID появится в адресной строке при переходе в ваше приложение.

В качестве ключа (KEY) будет использоваться пятизначный номер заказа, а в качестве значений телефонные номера: courier номер курьера, client номер клиента. TTL нам здесь необходимо для указания срока хранения значений.

3) Осталось запустить файл, чтобы сохранить данные заказа:

python3 kvs.py

Если мы больше не захотим, чтобы клиент и курьер беспокоили друг друга, можно будет удалить их данные из хранилища. Информацию о всех доступных методах key-value storage вы найдёте в нашей документации: management API и VoxEngine.

Код сценария

Код, который необходимо вставить в сценарий kvs-scenario, представлен ниже, его можно смело копировать as is:

require(Modules.ApplicationStorage);/** * @param {boolean} repeatAskForInput - была ли просьба ввода произнесена повторно * @param longInputTimerId - таймер на отсутствие ввода * @param shortInputTimerId - таймер на срабатывание фразы для связи с оператором * @param {boolean} firstTimeout - индикатор срабатывания первого таймаута * @param {boolean} wrongPhone - индикатор совпадения номера звонящего с номером, полученным из хранилища * @param {boolean} inputRecieved - получен ли ввод от пользователя *  */let repeatAskForInput;let longInputTimerId;let shortInputTimerId;let firstTimeout = true;let wrongPhone;let inputRecieved;const store = {    call: null,    caller: '',    callee: '',    callid: '74990000000',    operator_call: null,    operatorNumber: '',    input: '',    data: {        call_operator: '',        order_number: '',        order_search: '',        phone_search: '',        sub_status: '',        sub_available: '',        need_operator: '',        call_record: ''    }}const phrases = {    start: 'Здр+авствуйтте. Пожалуйста, -- введите пятизначный номер заказa в тт+ооновом режиме.',    repeat: 'Пожалуйста , , - - введите пятизначный номер заказа в т+оновом режиме,, или нажмите решетку для соединения со специалистом',    noInputGoodbye: 'Вы - ничего не выбрали. Вы можете посмотреть номер заказа в смс-сообщении и позвонить нам снова. Всего д+обровоо до свидания.',    connectToOpearator: 'Для соединения со специалистом,, нажмите решетку',    connectingToOpearator: 'Ожидайте, соединяю со специалистом',    operatorUnavailable: 'К сожалению,, все операторы заняты. Пожалуйста,,, перезвоните позднее. Всего д+обровоо до свидания.',    wrongOrder: 'Номер заказа не найден. Посмотрите номер заказа в смс-сообщении и введите его в т+оновом режиме. Или свяжитесь со специалистом,, нажав клавишу решетка.',    wrongOrderGoodbye: 'Вы ничего не выбрали, всего д+обровоо до свидания.',    wrongPhone: 'Номер телефона не найден. Если вы кли+ент, перезвоните с номера, который использовали для оформления заказа. Если вы курьер, перезвоните с номера, который зарегистрирован в нашей системе. Или свяжитесь со специалистом,,- нажав клавишу решетка.',    wrongPhoneGoodbye: 'Вы ничего не выбрали. Всего доброго, до свидания!',    courierIsCalling: `Вам звонит курьер по поводу доставки вашего заказа, - - ${store.data.order_number}`,    clientIsCalling: `Вам звонит клиент по поводу доставки заказа, - - ${store.data.order_number} `,    courierUnavailable: 'Похоже,,, курь+ер недоступен. Пожалуйста,,, перезвоните через п+ару мин+ут. Всего д+обровоо до свидания.',    clientUnavailable: 'Похоже,,, абонент недоступен. Пожалуйста,,, перезвоните через пп+ару мин+ут. Всего д+обровоо до свидания.',    waitForCourier: 'Ожидайте на линии,, - соединяю с курьером.',    waitForClient: 'Ожидайте на линии,, соединяю с клиентом.'}VoxEngine.addEventListener(AppEvents.Started, async e => {    VoxEngine.addEventListener(AppEvents.CallAlerting, callAlertingHandler);})async function callAlertingHandler(e) {    store.call = e.call;    store.caller = e.callerid;    store.call.addEventListener(CallEvents.Connected, callConnectedHandler);    store.call.addEventListener(CallEvents.Disconnected, callDisconnectedHandler);    store.call.answer();}async function callDisconnectedHandler(e) {    await sendResultToDb();    VoxEngine.terminate();}async function callConnectedHandler() {    store.call.handleTones(true);    store.call.addEventListener(CallEvents.RecordStarted, (e) => {        store.data.call_record = e.url;    });    store.call.record();    store.call.addEventListener(CallEvents.ToneReceived, dtmfHandler);    await say(phrases.start);    addInputTimeouts();}function dtmfHandler(e) {    clearInputTimeouts();    store.input += e.tone;    Logger.write('Введена цифра ' + e.tone)    Logger.write('Полный код ' + store.input)    if (e.tone === '#') {        store.data.need_operator = "Да";        store.call.removeEventListener(CallEvents.ToneReceived);        store.call.handleTones(false);        callOperator();        return;    }    if (!wrongPhone) {        if (store.input.length >= 5) {            repeatAskForInput = true;            Logger.write(`Получен код ${store.input}. `);            store.call.handleTones(false);            store.call.removeEventListener(CallEvents.ToneReceived);            handleInput(store.input);            return;        }    }    addInputTimeouts();}function addInputTimeouts() {    clearInputTimeouts();    if (firstTimeout) {        Logger.write('Запущен таймер на срабатывание фразы для связи с оператором');        shortInputTimerId = setTimeout(async () => {            await say(phrases.connectToOpearator);        }, 1500);        firstTimeout = false;    }    longInputTimerId = setTimeout(async () => {        Logger.write('Сработал таймер на отсутствие ввода от пользователя ' + longInputTimerId);        store.call.removeEventListener(CallEvents.ToneReceived);        store.call.handleTones(false);        if (store.input) {            handleInput(store.input);            return;        }        if (!repeatAskForInput) {            Logger.write('Просим пользователя повторно ввести код');            store.call.handleTones(true);            store.call.addEventListener(CallEvents.ToneReceived, dtmfHandler);            await say(phrases.repeat);            addInputTimeouts();            repeatAskForInput = true;        } else {            Logger.write('Код не введен. Завершаем звонок.');            await say(inputRecieved ? phrases.wrongOrderGoodbye : phrases.noInputGoodbye);            store.call.hangup();        }    }, 8000);    Logger.write('Запущен таймер на отсутствие ввода от пользователя ' + longInputTimerId);}function clearInputTimeouts() {    Logger.write(`Очищаем таймер ${longInputTimerId}. `);    if (longInputTimerId) clearTimeout(longInputTimerId);    if (shortInputTimerId) clearTimeout(shortInputTimerId);}async function handleInput() {    store.data.order_number = store.input;    Logger.write('Ищем совпадение в kvs по введенному коду: ' + store.input)    inputRecieved = true;    let kvsAnswer = await ApplicationStorage.get(store.input);    if (kvsAnswer) {        store.data.order_search = 'Заказ найден';        Logger.write('Получили ответ от kvs: ' + kvsAnswer.value)        let { courier, client } = JSON.parse(kvsAnswer.value);        if (store.caller == courier) {            Logger.write('Звонит курьер')            store.callee = client;            store.data.sub_status = 'Курьер';            store.data.phone_search = 'Телефон найден';            callCourierOrClient();        } else if (store.caller == client) {            Logger.write('Звонит клиент')            store.callee = courier;            store.data.sub_status = 'Клиент';            store.data.phone_search = 'Телефон найден';            callCourierOrClient();        } else {            Logger.write('Номер звонящего не совпадает с номерами, полученными из kvs');            wrongPhone = true;            store.data.phone_search = 'Телефон не найден';            store.input = '';            store.call.handleTones(true);            store.call.addEventListener(CallEvents.ToneReceived, dtmfHandler);            await say(phrases.wrongPhone);            addInputTimeouts();        }    } else {        Logger.write('Совпадение в kvs по введенному коду не найдено');        store.data.order_search = 'Заказ не найден';        store.input = '';        store.call.handleTones(true);        store.call.addEventListener(CallEvents.ToneReceived, dtmfHandler);        await say(phrases.wrongOrder);        Logger.write(`Очищаем таймер ${longInputTimerId}. `);        addInputTimeouts();    }}async function callCourierOrClient() {    clearInputTimeouts();    Logger.write('Начинаем звонок курьеру/клиенту');    await say(store.data.sub_status === 'Курьер' ? phrases.waitForClient : phrases.waitForCourier, store.call);    const secondCall = VoxEngine.callPSTN(store.callee, store.callid);    store.call.startPlayback('http://cdn.voximplant.com/toto.mp3');    secondCall.addEventListener(CallEvents.Connected, async () => {        store.data.sub_available = 'Да';        await say(store.data.sub_status === 'Курьер' ? phrases.courierIsCalling : phrases.clientIsCalling, secondCall);        store.call.stopPlayback();        VoxEngine.sendMediaBetween(store.call, secondCall);    });    secondCall.addEventListener(CallEvents.Disconnected, () => {        store.call.hangup();    });    secondCall.addEventListener(CallEvents.Failed, async () => {        store.data.sub_available = 'Нет';        store.call.stopPlayback();        await say(store.data.sub_status === 'Курьер' ? phrases.clientUnavailable : phrases.courierUnavailable, store.call);        store.call.hangup();    });}async function callOperator() {    Logger.write('Начинаем звонок оператору');    await say(phrases.connectingToOpearator, store.call);    store.call.startPlayback('http://cdn.voximplant.com/toto.mp3');    store.operator_call = VoxEngine.callPSTN(store.operatorNumber, store.callid);    store.operator_call.addEventListener(CallEvents.Connected, async () => {        store.data.call_operator = 'Оператор свободен';        VoxEngine.sendMediaBetween(store.call, store.operator_call);    });    store.operator_call.addEventListener(CallEvents.Disconnected, () => {        store.call.hangup();    });    store.operator_call.addEventListener(CallEvents.Failed, async () => {        store.data.call_operator = 'Оператор занят';        await say(phrases.operatorUnavailable, store.call);        store.call.hangup();    });}async function sendResultToDb() {    Logger.write('Данные для отправки в БД');    Logger.write(JSON.stringify(store.data));    const options = new Net.HttpRequestOptions();    options.headers = ['Content-Type: application/json'];    options.method = 'POST';    options.postData = JSON.stringify(store.data);    await Net.httpRequestAsync('https://voximplant.com/', options);}function say(text, call = store.call, lang = VoiceList.Yandex.Neural.ru_RU_alena) {    return new Promise((resolve) => {        call.say(text, lang);        call.addEventListener(CallEvents.PlaybackFinished, function callback(e) {            resolve(call.removeEventListener(CallEvents.PlaybackFinished, callback));        });    });};

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

Вводим номер заказа

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

store.input += e.tone;

Если звонящий ввел #, сразу соединяем его с оператором:

if (e.tone === '#') {    store.data.need_operator = "Да";    store.call.removeEventListener(CallEvents.ToneReceived);    store.call.handleTones(false);    callOperator();    return;}

Если он ввел последовательность из 5 цифр, вызываем функцию handleInput:

if (store.input.length >= 5) {    repeatAskForInput = true;    Logger.write('Получен код ${store.input}. ');    store.call.handleTones(false);    store.call.removeEventListener(CallEvents.ToneReceived);    handleInput(store.input);    return;}

Ищем заказ в хранилище

Здесь мы будем сравнивать введенный номер заказа с номером в хранилище, используя метод ApplicationStorage.get(), в качестве ключа используем введенную последовательность:

store.data.order_number = store.input;Logger.write('Ищем совпадение в kvs по введенному коду: ' + store.input)inputRecieved = true;let kvsAnswer = await ApplicationStorage.get(store.input);

Если заказ найден, получаем для него номера клиента и курьера:

if (kvsAnswer) {    store.data.order_search = 'Заказ найден';    Logger.write('Получили ответ от kvs: ' + kvsAnswer.value)    let { courier, client } = JSON.parse(kvsAnswer.value);

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

if (store.caller == courier) {    Logger.write('Звонит курьер')    store.callee = client;    store.data.sub_status = 'Курьер';    store.data.phone_search = 'Телефон найден';    callCourierOrClient();} else if (store.caller == client) {    Logger.write('Звонит клиент')    store.callee = courier;    store.data.sub_status = 'Клиент';    store.data.phone_search = 'Телефон найден';    callCourierOrClient();}

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

else {    Logger.write('Номер звонящего не совпадает с номерами, полученными из kvs');    wrongPhone = true;    store.data.phone_search = 'Телефон не найден';    store.input = '';    store.call.handleTones(true);    store.call.addEventListener(CallEvents.ToneReceived, dtmfHandler);    await say(phrases.wrongPhone);    addInputTimeouts();}

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

else {    Logger.write('Совпадение в kvs по введенному коду не найдено');    store.data.order_search = 'Заказ не найден';    store.input = '';    store.call.handleTones(true);    store.call.addEventListener(CallEvents.ToneReceived, dtmfHandler);    await say(phrases.wrongOrder);    Logger.write(`Очищаем таймер ${longInputTimerId}. `);    addInputTimeouts();}

Звоним клиенту/курьеру

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

await say(store.data.sub_status === 'Курьер' ? phrases.waitForClient : phrases.waitForCourier, store.call);const secondCall = VoxEngine.callPSTN(store.callee, store.callid);store.call.startPlayback('http://cdn.voximplant.com/toto.mp3');

В этот же момент сообщим второй стороне о том, что звонок касается уточнения информации по заказу:

secondCall.addEventListener(CallEvents.Connected, async () => {    store.data.sub_available = 'Да';    await say(store.data.sub_status === 'Курьер' ? phrases.courierIsCalling : phrases.clientIsCalling, secondCall);    store.call.stopPlayback();    VoxEngine.sendMediaBetween(store.call, secondCall);});

Обработаем событие дисконнекта:

secondCall.addEventListener(CallEvents.Disconnected, () => {    store.call.hangup();});

И оповестим звонящего, если вторая сторона недоступна:

secondCall.addEventListener(CallEvents.Failed, async () => {    store.data.sub_available = 'Нет';    store.call.stopPlayback();    await say(store.data.sub_status === 'Курьер' ? phrases.clientUnavailable : phrases.courierUnavailable, store.call);    store.call.hangup();});

За все фразы, который произносит робот, отвечает функция say, а сами фразы перечислены в ассоциативном массиве phrases. В качестве TTS провайдера мы используем Yandex, голос Alena:

function say(text, call = store.call, lang = VoiceList.Yandex.Neural.ru_RU_alena) {    return new Promise((resolve) => {        call.say(text, lang);        call.addEventListener(CallEvents.PlaybackFinished, function callback(e) {            resolve(call.removeEventListener(CallEvents.PlaybackFinished, callback));        });    });};

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

Тестируем

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

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

Если все сделано верно, клиент и курьер смогут созваниваться и обсуждать детали заказа, не зная настоящих номеров друг друга, а значит, не нарушая прайваси. Круто, не так ли?) Желаем вам успешной разработки и беспроблемной доставки!

P.S. Также мой коллега недавно рассказал, как обезопасить общение клиента и курьера с помощью Voximplant Kit (наш low-code/no-code продукт). Если эта тема вас заинтересовала, переходите по ссылке :)

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

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

Очевидные причины: ограничения железа и бэкапов

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

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

Много лет назад мы предоставили клиенту квоту в 20 ТБ и предупредили про ограничение на диск в 16 ТБ. Резервное копирование данных делали с помощью Veeam Backup&Replication. Когда клиент вышел за пределы диска в 16 ТБ, все задачи на создание бэкапов просто зависли. Veeam не успевал забэкапить большую ВМ и на всякий случай оставлял неполный снэпшот, а затем создавал новый. Дерево снэпшотов стало расти слишком быстро, общая производительность диска тоже упала. Пришлось полночи заново создавать дерево снэпшотов, а затем переносить данные на диски поменьше.

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

Клиенту выделили квоту в 40 ТБ на СХД, а для диска ВМ прописали ограничение в 20 ТБ. Администратор клиента создал ВМ в 30 ТБ и разметил все дисковое пространство одним диском. Техподдержка обнаружила проблему, сообщила клиенту, что нужно пересоздать ВМ с дисками меньшего размера, но администраторы долго не выходили на связь.

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

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

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

Неочевидная работа гипервизора

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

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

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

Некорректный сайзинг приложения в облаке

К сожалению, переезд приложения с физических хостов не всегда возможен в лоб. Даже если все работало на физических 24 процессорах, столько же процессоров в облаке не всегда решают проблему.

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

У крупных производителей софта несовместимость с облаком сразу прописана в документах. Менее очевидно дело обстоит с самописным ПО.

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

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

Например, бывают ситуации, когда пользователь привык к быстрой работе на ноутбуке с высокочастотными процессорами, а в облаке сталкивается с низкой скоростью. Характеристики Enterprise-железа в дата-центре рассчитаны на долгосрочную работу в режиме 24/7 и не допускают пограничных состояний. Если такой пользователь разгонял процессоры на своем ноутбуке до опасного максимума, то в облаке он не сможет добиться тех же скоростей от похожего процессора.

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

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

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

Подозрительная активность на ВМ

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

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

Откуда берутся лимиты на ресурсы в облаке

Ограничения на диск

1. Есть технические ограничения СХД. Яркий пример: блочный том многих моделей NetApp не может быть более 16 ТБ.

2. Мы как провайдер провели тесты производительности СХД и рассчитали оптимальный размер дата-стора.

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

Ограничения на CPU и память

1. Ограничен размер физического хоста, на котором располагаются ВМ клиентов.

   При размере хоста 144 vCPU и 2 TБ памяти ВМ большего размера не получится создать при всем желании. (Cпасибо, кэп!)

2. Для оптимального обращения к памяти мы учитываем особенности работы мультипроцессорных систем. Мы уже рассказывали об этом в статье про первую виртуальную машину.

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

3. С помощью некоторых лимитов мы можем управлять виртуальной платформой и предоставлять предсказуемый сервис с соблюдением SLA.

Ограничения на IOPS

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

1. Клиент решил протестировать выделенные мощности на больших нагрузках.

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

3. Клиент установил высокопроизводительное приложение.

На любой из этих случаев мы задаем ограничения потребляемых дисковых мощностей, опираясь на результаты нагрузочного тестирования СХД. Сейчас можем ограничить каждый диск фиксированным значением IOPS или исходить из IOPS на ГБ.

Как новому клиенту вписаться в лимиты и обеспечить производительность

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

2. До переезда протестировать работу приложения в облачной инфраструктуре. Большинство провайдеров позволяют клиентам брать пробный период и запускать синтетические тесты.

3. Не стесняться обращаться в техподдержку. Инженеры могут оценить производительность со стороны гипервизора и дать рекомендации.

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

5. Расти не вертикально, а горизонтально. Например, не добавлять 8 процессоров на одну ВМ, а создать 4 ВМ по 2 процессора на каждой. Вдобавок это уменьшит площадь отказа.

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

"Неужели компании хотят так сильно экономить, что готовы терять в качестве и времени?"

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

Сразу прокомментирую, что в этой статье нет цели оклеветать или высказать своё негативное мнение о компаниях. Нет! Я опираюсь только на их опыт и на полученные результаты.

Я занимаюсь подбором IT-специалистов и для того, чтобы не быть "тем самым HR, который сливает , а не помогает, своими оценочными тестами и вопросами вне понимания специфики работы", мне приходится изучать гигабайты информации на habr и других ресурсах. И в первых рядах моего несогласия, есть такая профессия - Fullstack-разработчик.

Немного для общего понимания поясню, почему я выбрал подход собирать информацию об IT-специалистах.

С 2018 года я начал вникать в эту сферу более плотно. Освоил основы HTML/CSS, познакомился с Python, PHP, Swift. Естественно эти познания подтолкнули меня сменить компанию из обычной на IT. Мне повезло и меня взяли в достаточно перспективный на мой взгляд стартап (разглашать не буду его название из добрых побуждений). Первые месяца три, я работал на должности специалиста по работе с клиентами, но сейчас понимаю, что на самом деле выполнял функционал Project-manager и одновременно Product Owner. Ну и по совместительству еще продавец и support.

Мне реально нравился проект и я горел его улучшить. Хотите верьте, хотите нет, но в этом проекте я стал хуже спать. Я постоянно думал, что можно улучшить. Я стал предлагать идеи по улучшению своему непосредственному, а тот вообще не про IT и очень скоро я понял, что я ему говорю свои идеи, а он просто не правильно их "продает" генеральному. Я не хочу сказать, что этот руководитель плохой. Наоборот, он достаточно внимательно относился ко всем сотрудникам и реально хотел донести мои идеи генеральному, но просто не владея техническим восприятием, он не мог объяснить так, как это говорил ему я.

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

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

И вот мне все же пришлось упереться в стену, которую непроизвольно построили разработчики. Сейчас вы поймете о чем я. Проработав почти год в проекте и коммуницируя с Team Lead, я не знал, сколько в команде разработчиков. Мне пояснили, что проект новый на рынке (хотя я знал точно, что они не уникальны) и что не могут себе позволить разработчиков со стороны. Что есть команда, (как позже я все же выяснил, что она из 5 человек), в которой есть back&front и парочка как раз Fullstack-разработчиков. На них и держался весь проект.

Естественно они сильные специалисты и я и сейчас в шоке, как они все это стойко держали. Да, Scrum (Agile), Jira. Пользовались теми же инструментами, которые хвалил рынок. Но "бэклог" еженедельно рос. Спрос на продукт стремительно набирал обороты и я начал "кричать", пытаясь быть услышанным, что нам срочно нужно расширять команду разработчиков и причем принципиально , среди них не должны быть больше Fullstack. К тому моменту, когда негодование users начинало зашкаливать, из-за постоянных срывов обещанных дедлайнов, я явно видел, что для быстрого роста и своевременного исправления скопившихся багов, нужно брать людей на отдельные блоки. И вот тут-то мы и выяснили, что Fullstack-разработчики писали код так, что его нельзя пока что разделить на блоки. Что если пустить со стороны человека, то он будет видеть весь код. Увы, но такова была реальность. Приняли решение максимально срочно декомпозировать, но вы наверно знаете, что на практике это совсем не просто.

"Страсти" в этом проекте накалялись. Разработчики сутками пытались исправлять баги, про которые ежедневно менеджерам по работе с клиентами звонили клиенты. Все мы принимали еженедельно новые алгоритмы, которые полностью меняли структуру работы и максимально выводили из процесса разработчиков (я их нарисовал 5 в период 7 месяцев). Пытались максимально разгрузить разработчиков, сняли все, что можно получить временно внешними ресурсами (сайт на Битрикс, CRM и так далее). Но в итоге, это не дало нужных результатов. Спустя 2 года, я покинул проект.

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

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

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

Успешных вам проектов!

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

1. Перенос локальной инфраструктуры и данных

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

Во время мероприятия:

• Обнаружьте и оцените рабочие нагрузки в своей среде перед миграцией с помощью Azure Migrate и других инструментов.

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

• Перенесите традиционные локальные рабочие нагрузки идентификации Windows Server и защитите от угроз с помощью Azure Active Directory (Azure AD), доменных служб Azure AD, Azure AD Connect и контроллеров домена Windows Server IaaS.

• Перенесите свои локальные вычислительные нагрузки Windows Server в Azure, включая физические серверы и виртуальные машины, работающие на VMware или Windows Server Hyper-V.

• Изучите службы баз данных SQL Azure, включая миграцию рабочих нагрузок SQL в SQL Azure, а также способы выполнения миграции в оперативном и автономном режиме.

Подробности и регистрация.

2. Основы ИИ

Откройте для себя решения, которые можно создавать с помощью ИИ, и сервисы Azure, помогающие в разработке этих решений. Присоединяйтесь к нам на бесплатном мероприятии Microsoft Azure Virtual Training Day: основы ИИ, чтобы получить общее представление о том, что такое ИИ, и узнать, как начать работу с ИИ в Azure.

Посетите виртуальное обучающее мероприятие, чтобы:

• Изучить основные концепции и области применения ИИ.

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

• Подробнее узнать о разговорном ИИ, обработке естественного языка и компьютерном зрении в Microsoft Azure.

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

Вот, что мы вам предлагаем:

• Введение

• Введение в ИИ

• Машинное обучение

• Перерыв 10минут

• Компьютерное зрение

• Перерыв 10минут

• Обработка естественного языка

• Виртуальный собеседник

• Завершающий сеанс вопросов и ответов

Подробности и регистрация.

3. Microsoft Developers Meetup

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

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

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

Программа

Подробности и регистрация: регистрация приостановлена.

4. Основы Microsoft Azure

Чтобы представить будущее, вам необходимо понять, какие возможности перед вами и вашей организацией открывает облако сегодня. В рамках этого вводного курса День виртуального обучения Microsoft Azure: основы рассказывается о концепциях, моделях и сервисах облачных вычислений. Рассматриваются такие темы, как публичное, частное и гибридное облако, а также инфраструктура как услуга (IaaS), платформа как услуга (PaaS) и программное обеспечение как услуга (SaaS).

Во время обучения вы узнаете, как:

• начать работать с Azure;

• интегрировать Azure с существующими сетями;

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

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

Подробности и регистрация.

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

Из чего состоит сервисный процесс почти любой компании с мобильными сотрудниками

1. Персонал: поиск, обучение и работа с персоналом

2. Операционные процессы:

   1. диспетчеризация (приём и обработка клиентских обращений),

   2. выполнение заявок,

   3. закупка расходных материалов или запчастей,

   4. работа с подрядчиками,

   5. управление уровнем клиентского сервиса и сбор обратной связи,

   6. контроль перемещений сотрудников и контроль за расходом ГСМ

   7. в компаниях, обслуживающих оборудование, добавляется плановое обслуживание или выполнение регулярных (контрактных) работ (планирование и выполнение ППР)

Если говорить о первом шаге автоматизации в сервисных компаниях с выездным персоналом, то 25% компаний начинают автоматизацию с внедрения CRM системы, а 75% - автоматизируют работу по заявкам и контроль выездного персонала. И это не случайно, ведь операционка для b2b сервиса - это прежде всего ежедневная кропотливая работа с обращениями клиентов и их заявками.

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

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

1. снижение затрат на диспетчерскую

2. оптимизация затрат на фронт-офис персонал (сервисные специалисты)

3. снижение затрат на подрядчиков

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

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

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

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

1. Цель 1: Снижение затрат на диспетчерскую и процессы диспетчеризации

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

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

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

Ручной прием обращенийэто обычно телефон, мессенджеры или почта без средств автоматизации.

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

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

1. пообщаться с заказчиком по телефону или обработать обращение поступившее на почту / в мессенджер,

2. зарегистрировать заявку,

3. вручную классифицировать обращение,

4. рассчитать срок выполнения по SLA,

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

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

7. После выполнения заявки - собрать с исполнителя отчет о выполненных работах и запустить процесс по оплате работ, в случае b2b сервиса и при постоплатной схеме работ

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

Автоматизация процессов диспетчерской может снизить эти расходы до 90%.

Пример: в среднем по сервисной отрасли, один диспетчер обрабатывает до 500 заявок, с учетом неравномерности их поступления. Для отказоустойчивости или приема обращений 24x7, уже требуется 3-5 диспетчеров работающих посменно. А если заявок тысячи? Количество диспетчеров растет пропорционально.

В среднем, на 20-50 мобильных (выездных) сотрудников требуется два диспетчера (даже без круглосуточной поддержки). Зарплата диспетчера сравнима с зарплатой сервисного специалиста, а значит до 10% затрат на ФОТ сервиса уходит на обслуживание процессов диспетчеризации. Это может составлять до 20% недополученной прибыли всего бизнеса.

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

Динамику каких показателей следует контролировать для минимизации затрат на диспетчеризацию клиентских обращений?

1. Доля и количество заявок, полученных по электронным каналам связи, в которых не требуется участие диспетчера при получении, регистрации и распределении заявок

2. Соотношение исполнителей и диспетчеров

3. Скорость назначения заявок на исполнителей

4. Скорость закрытия заявок

5. Среднее время в пути

6. First Time Fix Rate - доля заявок, закрытых исполнителями с первого посещения объекта

7. Доля и кол-во заявок, закрытых с нарушением срока SLA

8. Оценка от клиентов

Цель 2: Оптимизация затрат на персонал сервисной службы

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

Повышение полезной загрузки исполнителей и оптимизация процесса оказания сервиса совместно позволяют оптимизировать численность персонала до 20-30%.

Контроль каких показателей, может позволить снизить затраты на персонал и оптимизировать сервис?

1. Количество закрытых заявок на сотрудника

2. Коэффициент полезной загрузки исполнителей

3. Отношение количества офисных сотрудников к мобильным

4. Среднее количество выполненных заявок на человека в день

5. Рейтинг эффективности персонала

6. Объем переработок

7. Пробег автотранспорта по сотрудникам

8. Пробег автотранспорта в расчете на заявку

9. Средняя полезная загрузка сотрудника в день в часах

10. Среднее количество открытых заявок по исполнителям

11. Равномерность загрузки исполнителей по дням недели/месяца

12. Суммарное время выполнения работ по исполнителям

13. Доля и количество заявок, выполненных с просрочкой

14. Доля и количество повторных выездов

15. В RCM контрактах - MTBF (среднее время между отказами оборудования), MTTR (среднее время на устранение неисправности), % оборудования, по которому были заявки

16. % выполнения плановых (профилактических) работ

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

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

Цель 3: Снижение затрат на подрядчиков

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

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

1. уровень сервиса (соблюдения SLA)

2. количество заявок, выполненные с просрочкой

3. фиксация факта присутствия на объекте при закрытии заявки

4. указание выполненных работ и фиксация объекта ремонта

5. контроль количества повторных ремонтов

6. В RCM контрактах - MTBF (среднее время между отказами обслуживаемого оборудования), MTTR (среднее время на устранение неисправности), % оборудования по которому были заявки

7. общее количество выполненных заявок

8. количество заявок выполненных по видам и единицам оборудования

9. скорость решения проблем

10. простои оборудования

11. рейтинг исполнителей подрядчика

12. рейтинги и сравнительная оценка уровня сервиса различных подрядчиков

13. количество заявок на согласовании у заказчика

14. время поставки запчастей

15. оборачиваемость запчастей и актуальная матрица запчастей

16. среднее время приема заявки подрядчиком в работу

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

Цель 4: Снижение затрат на административные функции и бэкофис.

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

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

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

1. Оптимизация первичного документооборота: переход на электронные первичные сервисные акты вместо бумажных

2. Переход на ЭДО по юридически значимым документам (бухгалтерские акты, СФ, договора и т.д.)

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

4. Внедрения систем систем электронного архива как входящих, так иисходящих документов с QR-кодированием и хранением всех бухгалтерских документов в компании в электронном виде

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

6. Электронные авансовые отчеты сотрудников по купленным в магазинах запчастям и расходным материалам

7. Автоматизированный GPS-контроль перемещения персонала и автотранспорта

8. Автоматизация планирования маршрутов по заявкам

9. Оптимизация матрицы запчастей и управление товарным запасом

10. Электронный склад запчастей в смартфоне мобильного сотрудника с поиском требуемых запчастей

11. Стандартизация стандартных или плановых работ через чек-листы или карты операций

12. Онбординг и обучение персонала через электронные помощники в смартфоне

Как правильно ставить цели в сервисной компании?

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

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

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

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

1. Определить верхнеуровневые стратегические цели (финансовые / клиентские (рынок) / процессные или цели, связанные с персоналом)

2. Декомпозировать цели до уровня отдела или функций в компании

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

4. Решить задачи по регулярному расчету и оценки выбранных показателей (показатели следует рассчитывать и оценивать не реже 1 раза в месяц. Нижнеуровневые - понедельно или даже ежедневно).

Тут часто встает вопрос о необходимости внедрения какого-либо ИТ-решения, позволяющего

• оцифровывать текущие сервисные процессы,

• измерять требуемые показатели

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

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

Для оцифровки сервисного бизнеса с выездным персоналом лучше всего подходят решения класса FSM (Field Service Management). В России этот класс систем представлен решением HubEx (мы - разработчики платформы HubEx FSM). Так что если при прочтении остались вопросы - спрашивайте в комментариях. И удачи в цифровизации в своих компаниях!

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

Forgotify

В библиотеке Spotify десятки миллионов треков, но согласно статистике площадки, пятую часть из них мало кто слушал. Все эти композиции собирает Forgotify. Чтобы погрузиться в неизведанные глубины стримингового сервиса, достаточно нажать на Start Listening.

Разумеется, есть причина, по которой у представленных треков счетчик прослушиваний не может оторваться от нулевой отметки. Многое из того, что предлагает Forgotify это любительские каверы и ремиксы, а также странная кантри-музыка и рэп, записанный где-то в гараже. Но не все так плохо, и порой даже попадаются настоящие hidden gems. Так, резиденты Reddit нашли интересный и расслабляющий фолк, а также пост-панк из 80-х годов прошлого века.

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

Camp Explorer

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

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

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

Vintage Obscura

Это тред на Reddite, участники которого публикуют песни, написанные более 25 лет назад. Обязательное условие число просмотров у записей на YouTube не должно превышать тридцати тысяч. Спектр жанров обширен дарквейв, джаз-рок, поп и даже фанк времен СССР. К последнему можно отнести Танец Шамана в исполнении вокального квартета Улыбка. Её много лет назад выпускали на виниловой пластинке Мелодия.

Существует и ресурс vintageobscura.net. Он собирает все музыкальные записи из треда на Reddit в удобном формате. Платформу можно использовать в качестве стриминг-сервиса.

Soundcloud Gems

SoundCloud изначально задумывалась как площадка для инди-музыкантов, поэтому неудивительно, что здесь можно найти огромное количество редких композиций. Поисками этих сокровищ занимаются пользователи Reddit в тематическом треде r/soundcloudgems.

Одним из исполнителей, работу которого недавно опубликовали, стал liltimbo of mokum. Он пишет треки в стиле environmental trap, чем-то напоминающим лоу-фай. Пока что у музыканта всего тридцать три подписчика, но все может перемениться благодаря реддиторам.

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

Разумеется, толику внимания удается завоевать не всем. Многие музыканты жалуются, что устали выкладывать свои работы в интернет, так как никто не хочет их слушать. Молодые композиторы спрашивают совета в социальных сетях, как им разорвать порочный круг, или иронизируют на эту тему, называя песни соответствующим образом например, Another Useless Minute of Music No One Listens To.

Сервисы подобные Forgotify и Camp Explorer, а также сообщества вроде r/soundcloudgems дают хотя и небольшой, но шанс быть услышанными и, возможно, дарят необходимую мотивацию дальше заниматься музыкой и творить несмотря ни на что.

Другие материалы из нашего Мира Hi-Fi:

• Блеск и нищета: как заработать на жизнь, если ты музыкант

• Музыка по умолчанию: какие треки можно было найти на плеерах и ПК

• Карты звуков как способ погрузиться в атмосферу незнакомого города

Недавно мы писали о противостоянии Apple и Spotify, в рамках которого компании продолжают мериться размерами роялти для музыкантов. Сегодня продолжим тему на повестке антимонопольное разбирательство и новые платные продукты.

Пожалуйся, и тебя услышат

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

Спустя год после начала разбирательства европейский регулятор наконец направил Apple уведомление о претензиях (statement of objections). Его цель получить официальный ответ на обвинения от организации, в отношении которой ведется расследование. Члены комиссии поставили под вопрос законность обязательного использования внутренних механизмов для покупок в музыкальных приложениях. Также на повестке оказался свод правил App Store, запрещающий разработчикам сервисов потоковой передачи музыки рассказывать юзерам об альтернативных способах оплаты.

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

Положение американской корпорации компрометирует и тот факт, что она подвергается серьезному давлению у себя на родине. В США уже несколько месяцев идут суды с компанией Epic Games, которая выступает против 30-процентной комиссии в App Store. При этом в начале года разбирательства переместились в европейскую юрисдикцию.

Чем и когда закончится антимонопольное расследование неизвестно, а пока стриминговый сервис теряет деньги. Несмотря на рост аудитории общее число пользователей уже перевалило за 150 млн платформа закрыла последний финансовый квартал с убытками в 125 млн евро. Чтобы компенсировать потери, сервис объявил о повышении тарифов на премиум-подписку практически по всему миру цена увеличилась на 1012%.

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

Свежие идеи и новая конкуренция

В то же время Spotify продолжает экспериментировать с новыми способами монетизации и привлечения аудитории. Недавно компания представила собственный hardware-аудиоплеер для автомобиля Car Thing. Это компактное устройство воспроизведения потоковой музыки для транспортных средств, не оснащенных современной инфотейнмент системой. Гаджет подключается к стереосистеме автомобиля по Bluetooth или AUX и позволяет переключать треки с помощью голосовых команд или сенсорного диска.

Устройство планируют продавать по цене 80 долларов, но пока приобрести его нельзя. Хотя ограниченную партию уже раздают бесплатно пользователям на территории США. Первые счастливые обладатели Car Thing довольны гаджетом он легкий и работает достаточно быстро. Однако ряж журналистов отнесся к новинке со скептицизмом. Некоторые даже назвали девайс бесполезным, так как он требует подключения к мобильному телефону. И здесь невольно задаешься вопросом, а зачем нужен Car Thing, если можно слушать музыку со смартфона? Очевидно, что стриминговая платформа только тестирует новый продукт и оценивает реакцию сообщества, поэтому остается вероятность, что оно так и не попадет в массовое производство.

Еще одним нововведением шведской платформы для передачи потоковой музыки стали платные подписки на подкасты. Контент-мейкерам разрешат устанавливать цену за прослушивание отдельных выпусков три, пять или восемь долларов в месяц. Согласно первым отзывам, сервис имеет некоторые шероховатости с точки зрения UX/UI, но предлагает выгодные условия для авторов. Подкастеров освободили от комиссий до 2023 года, после она составит 5%. Примечателен тот факт, что пару месяцев назад Apple запустила аналогичный сервис. Правда в этом случае сами контент-мейкеры должны будут платить двадцать долларов ежегодно, чтобы предлагать подписку своим слушателям.

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

Еще о подкастах и стриминге в Мире Hi-Fi:

• Стриминг становится основным источником дохода музыкантов

• Стриминговые сервисы хотели бы найти новые подходы в работе с музыкой

• Плейлистификация захватила умы паблишеров музыки и подкастов

• Обсуждение: почему индустрия подкастов все больше походит на стриминг сериалов

  ---

P.S. Что еще у нас есть в блоге на Хабре для дополнительного чтения пятерка экспертных обзоров аудиотехники: от внутриканальных наушников до напольной акустики.

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

Похоже, мы окружены значит, придётся разбираться. Что такое API, на Хабре уже рассказывали, а я предлагаю рассмотреть поподробнее реализацию API Gateway на облачных платформах.

Зачем вообще нужны Gateway API

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

Представьте себе: у вас есть интернет-магазин по продаже реплик молота Тора. Для удобства пользователя имеется как сайт под десктоп и мобильные устройства, так и приложения для Android и iPhone, которые взаимодействуют с сервером через REST API.

Чтобы на странице товара отображались верные данные, нам нужно обратиться к нескольким службам: в одной учитывается наличие молота, в другой записаны материал, вес и длина ручки, в третьей сохраняются отзывы клиентов, а цена вообще указана в четвёртой. API Gateway позволяет обойтись одним запросом.

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

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

Например возможность повторного использования компонентов, упрощение бэкенда приложения, обеспечение доступа к статическим веб-страницам и документам, удобная проверка авторизации и подбор оптимального для каждого типа клиента API как это делает Netflix API Gateway.

Что такое облачные API Gateway

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

Классический API Gateway представляет собой шлюз между пользователями и любым количеством сервисов (API), выполняющий функцию обратного прокси, как Nginx и HAProxy. В то же время облачная версия API Gateway уже полноценный сервис для разработчиков, который простым в исполнении не назовёшь.

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

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

Как облачные API Gateway облегчают жизнь

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

Для чего разработчики вообще выбирают облачные API Gateway?

• Чтобы сократить время разработки API Gateway создаётся в несколько кликов, а интеграция с облачными сервисами выбранной платформы занимает пару минут.

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

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

• Чтобы отлаживать API встроенными средствами меньше головной боли.

• Чтобы генерировать клиентские SDK.

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

• Чтобы контролировать доступ к API и управлять его жизненным циклом от создания до публикации.

• Чтобы уведомление приходило от сервиса, а не от разозлённого клиента, если что-то идёт не так.

• Чтобы настраивать авторизацию удобным методом с помощью средств Lambda или токенов OAuth.

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

• Чтобы платить только за количество запросов в месяц или пользоваться сервисами бесплатно, если не выходить за рамки определённой цифры.

Как используют облачные API Gateway

Виртуальная доска

Простое приложение, состоящее из двух конечных точек POST для записи сообщений и GET для извлечения трёх последних сообщений. Реализовано с помощью AWS Gateway, AWS DynamoDB, AWS Serverless Application Model и Lambda.

Голосовой сервиc

Рецепт сервиса записи к врачу и регистрации в поликлинике, разработанный коммуникационной платформой Voximplant и Yandex.Cloud.

Бот для телеграма

Запуск бота на Python внутри одного из облачных сервисов, а именно Yandex.Cloud.

Трекер пульсометрии

Один из вариантов решения для сбора данных пульсовой оксиметрии для нескольких пользователей, отслеживания этих данных и обмена ими. Фронт написан на VueJS, бэкенд реализован с применением Amazon API Gateway.

Статический сайт в облаке

Пошаговая инструкция по деплою статического сайта в облако, прикрутке к нему сертификата Lets Encrypt, домена второго уровня и настройке API-шлюза в системе Yandex.Cloud.

Блог

И снова приложение на микросервисах реализация клиентской части на VueJS, взаимодействие настроено через REST API и gRPC, а в качестве базы данных используется MongoDB.

Реализация на разных облачных платформах

Сервис API Gateway предлагают несколько облачных платформ и все они предоставляют более-менее схожий пакет услуг. Так в чём же разница?

Azure API Management

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

Amazon API Gateway

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

Документация включает подробные инструкции от развёртывания RESTful API при создании бессерверного веб-приложения до работы с HTTP API, поэтому не придётся искать примеры по всей Сети, чтобы разобраться.

Особенности:

• Создание API RESTful при помощи API HTTP или API REST.

• Интерфейсы API WebSocket для разработки приложений, которым требуется двусторонняя связь в режиме реального времени.

• Частная интеграция с AWS ELB и AWS Cloud Map.

• Ключи API для сторонних разработчиков.

• Генерирование клиентских SDK на многих языках, включая JavaScript, iOS и Android.

• Внедрение подписи четвёртой версии для API REST и API WebSocket при авторизации и проверке запросов API к другим сервисам AWS API Gateway.

• Авторизация с помощью AWS Lambda.

• Amazon API Gateway можно пользоваться бесплатно целый год пока ваши потребности не превышают один миллион вызовов API, полученных для API REST, один миллион вызовов API, полученных для API HTTP, и один миллион сообщений и 750 000 минут подключения для API WebSocket в месяц.

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

Oracle API Gateway

Сервис Oracle API Gateway стал доступен любому пользователю в конце 2019 года и уже пытается активно конкурировать с Amazon API Gateway. Получится ли у него отвоевать хотя бы часть аудитории у AWS, нам только предстоит увидеть а сравнивать всегда интереснее на собственном опыте. Почитать про создание своего Gateway API можно вот в этой статье.

Особенности платформы:

• RESTful API в комбинации с Oracle Functions, а также возможностями Kubernetes и Compute.

• Каждая служба в облачной инфраструктуре Oracle интегрируется с IAM для аутентификации и авторизации (консоль, SDK или CLI и REST API).

• Интеграция с системой управления доступом Oracle Cloud Infrastructure.

• Бесплатный период длительностью в тридцать дней, чтобы опробовать возможности широкого спектра сервисов Oracle Cloud, в том числе к Databases, Analytics, Compute, Container Engine for Kubernetes и т. д.

• Платформа Oracle Cloud позиционирует себя как более экономичное решение, чем AWS, и в качестве примера упоминает, что соотношение цены и производительности в 2 раза выше, а стоимость исходящей пропускной способности составляет только 1/4 от стоимости у AWS.

Google API Gateway

Сервис перешёл на стадию публичного бета-тестирования 18 сентября 2020 года, так что пока о нём известно довольно мало и тем интереснее пронаблюдать за его развитием.Сейчас Google API Gateway позволяет управлять API других сервисов облачной платформы Cloud Functions, Cloud Run, App Enginе, Compute Engine и Google Kubernetes Engine. Настроить работу с Cloud Run, к примеру, можно всего за несколько минут.

Особенности:

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

• До 2 миллионов запросов в месяц бесплатно.

• Наличие пробной версии. Google Cloud предоставляет виртуальный кредит в размере 300 долларов, который необходимо потратить в течение последующих трёх месяцев. После окончания бесплатного периода оплата не начинает взиматься автоматически на платный тариф необходимо перейти вручную.

SberCloud API Gateway

SberCloud API Gateway использует наработки Huawei, а информации об особенностях применении в Сети можно найти немного, но здесь вам поможет Хабр: после недавнего хакатона один из участников рассказал о впечатлениях от SberCloud и сравнил функциональность с более известным AWS.

Особенности:

• Доступ к облачным продуктам для физических лиц возможен только с помощью входа/регистрации через Сбер ID.

• Управление квотами и регулирование запросов пользователей.

• Встроенный инструмент отладки.

• Визуализированная панель мониторинга API.

• Создание каналов VPC для доступа к бэкенд-сервисам в сети VPC и управления нагрузкой путём отправки API-запросов на различные серверы.

• Цифровая подпись, которая вступает в силу только после привязки к API.

• Никакой минимальной или предварительной платы оплачивается только фактическое использование.

• Возможность монетизации API.

Yandex API Gateway

23 сентября 2020 года к четырём сервисам платформы Yandex.Cloud прибавились ещё два Yandex API Gateway и база данных Yandex Database в режиме Serverless.

Yandex API Gateway интегрирован с другими сервисами платформы, благодаря чему возможна отправка HTTP-запросов с помощью функций Yandex Cloud Functions, доступ к статическим данным осуществляется Yandex Object Storage напрямую из хранилища, а запуск произвольных HTTP-сервисов в облаке возможен с помощью Yandex Managed Service for Kubernetes. Так что спектр применения широк к примеру, внутри облака можно запустить приложение на Express.js.

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

Особенности:

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

• Поддержка OpenAPI 3.0.

• Обработка запросов только по протоколу HTTPS. Сервис автоматически перенаправляет все запросы к API-шлюзам по протоколу HTTP на их HTTPS-версии.

• Интеграция с системой управления доменами сервиса Certificate Manager. Для обеспечения TLS-соединения используется привязанный к домену сертификат.

• Система квот и лимитов. Максимальный размер спецификации 3,5 МБ. Количество API-шлюзов в одном облаке 10, но, в отличие от максимального размера спецификации, меняется по запросу в техническую поддержку.

Тарификация по количеству запросов к созданным API-шлюзам и исходящему трафику. При этом запросы к API-шлюзам до 100 000 запросов в месяц не тарифицируются. Как, кстати, и входящий трафик, а также передача данных между сервисами Yandex.Cloud. Больше подробностей можно узнать в сообществе Serverless в Telegram:Yandex Serverless Ecosystem. Мы регулярно встречаемся в виртуальном пространстве и похоже созревает потребность в очной встрече.

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

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

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

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

Как выбирал

Вы удивитесь, но поиском. Погуглил Kubernetes в облаке, пролистал пару страниц. Так и нашёл семь компаний, которые наиболее активно продвигают эту услугу: Mail.ru Cloud Solutions, Cloud4Y, CloudMTS, Yandex.Cloud, КРОК, DataLine, Selectel.

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

Про субъективность

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

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

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

Знакомство

Звонить и писать сразу всем компаниям гиблое дело, особенно если не готов покупать, а хочешь лишь проверить, как оно работает. Поэтому я потихоньку запрашивал тестовый доступ у каждой компании по очереди. Быстрее всех ответили Selectel, Cloud4Y и MCS, а вот Крок и DataLine оказались не столь быстрыми. Мне даже пришлось несколько раз ментально их пнуть напоминать о себе, чтобы получить какой-то ответ.

И уже на этом этапе круг подопытных кроликов провайдеров сузился. DataLine вообще никак не захотел со мной общаться. Письма ушли в молоко. Ну и ладно, подумал я. И нечего нас дёргать со всякими глупостями, подумал неизвестный мне менеджер DataLine. КРОК вежливо извинился и сообщил, что мелочь вроде меня им не интересна. Неприятно, но честно. Спасибо за это. Лучше честный отказ, чем игнор или затягивание времени.

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

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

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

Теперь давайте посмотрим, чего я натестировал.

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

Также провайдеры используют стек технологий виртуализации VMwarevSphereиNSX-T. NSX-T предназначен для гибридных окружений, как в смысле поддержки разных гипервизоров (ESXi и KVM), так и в плане поддержки облачных инфраструктур (например, AWS). VMware платный, но зато предлагает гарантированную поддержку от вендора с ответами на сложные вопросы и кейсы. И специалистов по VMware найти проще.

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

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

Облачные балансировщики нагрузки

Если говорить про балансировщик, распределяющий нагрузку, то в Selectel он создаётся вместе с кластером. Автоматическое создание балансировщика вместе с кластером предлагает Mail.ru, у него возможно автоматическое и быстрое масштабирование до 1000 узлов. А вот МТС удивил. Да, балансировщик создаётся автоматически при создании кластера. Но умолчанию открыты только 80 и 443 порты. Дополнительные порты можно открывать только через поддержку. Яндекс и Cloud4Y тоже предлагают создание дополнительного балансировщика. На этот случай есть специально написанные инструкции, ссылку на которые они мне заботливо прислали.

Управление

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

Mail.ru предлагает варианты управления кластером как через Kubernetes Dashboard, так и через kubectl. Web/API возможны в Cloud4Y и Selectel. У МТС только API. К тому же, управление docker-контейнерами из интерфейса не предусмотрено. В интерфейсе происходит управление кластерами Kubernetes. Яндекс пошёл своим путём. У них предлагается Web и Console Yandex.Cloud. Мне показалось не очень удобным и логичным, когда для работы требуется специальная яндексовая консоль. Может, есть и какой-то другой способ, только я его не нашёл.

Хранилища данных

Persistent Volumes можно считать аналогом нод в самом кластере Kubernetes. Зачем вообще нужна эта штука? Допустим, у вас есть несколько разных хранилищ. К примеру, одно быстрое на SSD, а другое медленное на HDD. Вы можете создать два Persistent Volumes в соответствии с этим, а затем выделять подам место в этих томах. Kubernetes поддерживает огромное количество подключаемых томов с помощью плагинов.

Вот тут у провайдеров используются разные решения. Cloud4Y и Selectel поддерживают как блочные, так и сетевые устройства NFS. И это хорошо. У Mail.ru блочное устройство накладывается на ограничения по ReadWriteMany(RWX). В документации указано, что механизм Persistent Volume позволяет подключить существующий Cinder Volume, находящийся на кластере Ceph в качестве постоянного хранилища данных к подам. Хранилище на базе Ceph обеспечивает сохранность данных за счёт трёхкратной репликации. У МТС Cloud Persistent Volumes тоже идёт через блочное устройство, что накладывается на ограничения по ReadWriteMany. Можно только одной ноде писать на него. В Yandex.Cloud блочные устройства могут работать только в ReadWriteOnce(RWO).

Контроллеры Ingress

У Selectel в версии Managed Kubernetes Ingress Controller не предустанавливаются в кластеры. Для создания объектов Ingress потребуется самостоятельно установить Ingress Controller. Обратите внимание, что при создании Ingress Controller у вас, вероятнее всего, будет создан Service с типом LoadBalancer помимо самого приложения Ingress Controller. В таком случае в вашем проекте будет автоматически создан дополнительный балансировщик нагрузки, который отобразится в разделе Балансировщики нагрузки.

Mail.ru позволяет выбрать Ingress при создании кластера. Кластеры Kubernetes, устанавливаемые в MCS содержат преднастроенный Ingress Controller на базе балансировщика нагрузки Nginx, который может обеспечить доступ к вашим сервисам, используя один и тот же выделенный балансировщик нагрузки OpenStack. МТС позволяет добавить/убрать Ingress при создании кластера. В документации МТС сразу говорится, что NGINXIngress разворачивается в стандартной настройке при запуске кластера при выборе соответствующего параметра. У Яндекса Ingress построен на базе LoadBalancer. Cloud4Y предлагает разворачивать Ingress в ручном режиме при необходимости.

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

У Селектела и МТС нет автоматического масштабирования. Работайте ручками, господа! Надо уточнить, что в МТС автоскейлинг будет добавлен в этом (2021)году. Яндекс и Майл предлагают более удобные условия. У них есть autoscaling по определенным параметрам загрузки нод, добавляется и убавляется автоматически. Cloud4Y предлагает автоскейлинг на уровне pod который определяется на основании конфигурации k8s. Autoscaling на уровне воркеров\нод на лету отсутствует, но можно зайти в vCloud и докинуть ноду или написать скрипты, которые делают то же самое, только запрограммированно

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

Мониторинг

Мониторинг это неотъемлемая часть любой инфраструктуры. Правильно настроенный мониторинг четко отражает здоровье ИТ-системы и про активно диагностирует её состояние. В данном случае все используют стандартное решение для VMware в виде плагина. У него есть свои ограничения, 1 мастер нода и 5 воркеров.

Cloud4Y по запросу прислал инструкции, как сделать 3 мастер ноды и добавить балансировщик. Ссылками и вложенными файлами с руководством поделились и другие провайдеры. Правда, Selectel и МТС очень долго раскачивались. Видимо, искали, где у них это всё написано.

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

Персональные данные

ФЗ-152 сейчас в тренде, и провайдеры активно развивают это направление. Selectel, Mail.ru Cloud, Cloud4Y обещают, что их решения соответствуют требованиям закона о персональных данных. С Yandex.Cloud я не понял, есть ли такая штука. Похоже, что нет, ведь иначе об этом где-нибудь, да говорилось бы. МТС Cloud пока лишь дорабатывает свою систему.

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

Оплата

Тут, наверное, и говорить нечего. Особых нововведений в плане оплаты нет.

Отличия от конкурентов

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

Mail.ru делает упор на тройную репликацию данных и отказоустойчивость, Selectel на привычный типовой формат работы с Kubernetes, Cloud4Y обещает мощную техническую поддержку и развитую документацию в базе знаний. МТС подчёркивает преимущества VMware в плане отказоустойчивости, а Яндекс порадовал формулировкой. Их сервис хороший, и это его ключевое отличие от остальных.

Выводы

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

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

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

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

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

Однажды мне понадобилось 1Tb облачного хранилища и выбор пал на Nextcloud, который и было решено развернуть на собственном домашнем сервере

В данной статье я опишу как быстро и безболезненно установить и настроить облако Nextcloud и облачный редактор Onlyoffice

Статья предполагает, что у вас уже установлен и настроен Ubuntu.

Все действия были проверены на Ubuntu Server 20.04

Что будем делать:
1. Установим Nginx, PHP и MariaDB
2. Добавим бесплатный SSL-сертификат Let's Encrypt
3. Развернем NextCloud
4. Произведем тонкие настройки сервера
5. Установим Onlyoffice

Бесплатные доменные имена в домене .tk можно получить на www.freenom.com

Первым делом, устанавливаем вспомогательные утилиты

sudo apt-get install nano mc zip -y

Этот пункт можно пропустить, если настраиваете облако на локальный диск, а не на отдельную машину с доступом по nfs, мне понадобилось сделать это именно на nfs

# Ставим nfs-clientsudo apt install nfs-common -y# -------------------# Монтируем папку nfs# Ставим nginxsudo mkdir -p /nfs/ncsudo mount your_host_ip:/папка_шары_nfs/ /nfs/ncsudo ls -l /nfs/nc/sudo df -hsudo du -sh /nfs/nc/# -------------------# Монтируем nfs при загрузкеsudo nano /etc/fstab# Добавим такую строку в конец файлаyour_host_ip:/папка_шары_nfs/  /nfs/nc  nfs auto,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0

Ставим nginx

sudo apt install nginx -ysudo nginx -Vsudo systemctl enable nginxsudo systemctl start nginx

Ставим php 7.4

sudo apt install php7.4-fpm php7.4-mysql php7.4 php7.4-curl php7.4-gd php7.4-json php7.4-mbstring php7.4-common php7.4-xml php7.4-zip php7.4-opcache php-apcu php-imagick -y

Настраиваем php 7.4

sudo nano /etc/php/7.4/fpm/pool.d/www.conf

снимаем комментарии со строк

env[HOSTNAME] = $HOSTNAME
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /tmp

# Настраиваем php.ini:

sudo nano /etc/php/7.4/fpm/php.ini

opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1

Разрешаем автозапуск php-fpm и перезапускаем его:

sudo systemctl enable php7.4-fpmsudo systemctl restart php7.4-fpm

Устанавливаем MariaDB:

sudo apt install mariadb-serversudo systemctl enable mariadbsudo systemctl start mariadb

Запуск сценария безопасности (здесь можно поменять пароль рута, убрать ненужные разрешения):

sudo mysql_secure_installation

Создаем базу данных для Nextcloud (в примере указан пароль nextcloud, его лучше заменить на свой) :

sudo mysql -u root -p

Вводим пароль рута для MariaDB

 >CREATE DATABASE nextcloud;CREATE USER 'nextcloud'@'localhost' IDENTIFIED BY 'nextcloud';GRANT ALL ON nextcloud.* TO 'nextcloud'@'localhost' IDENTIFIED BY 'nextcloud' WITH GRANT OPTION;FLUSH PRIVILEGES;EXIT;

Теперь надо создать файл конфигурации Nginx для Nextcloud

sudo nano /etc/nginx/sites-enable/nextcloud.conf

И вставляем в него следующий текст, естественно, заменив nc.myhost.com на свои сервера

server {    listen 80;    server_name nc.myhost.com;    return 301 https://$server_name$request_uri;}server {    listen 443 ssl;    server_name nc.myhost.com;    ssl_certificate /etc/nginx/ssl/cert.pem;    ssl_certificate_key /etc/nginx/ssl/cert.key;    root /var/www/nextcloud;    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;    client_max_body_size 10G;    fastcgi_buffers 64 4K;    rewrite ^/caldav(.*)$ /remote.php/caldav$1 redirect;    rewrite ^/carddav(.*)$ /remote.php/carddav$1 redirect;    rewrite ^/webdav(.*)$ /remote.php/webdav$1 redirect;    index index.php;    error_page 403 = /core/templates/403.php;    error_page 404 = /core/templates/404.php;    location = /robots.txt {      allow all;      log_not_found off;      access_log off;    }    location ~ ^/(data|config|\.ht|db_structure\.xml|README) {        deny all;    }    location / {        rewrite ^/.well-known/host-meta /public.php?service=host-meta last;        rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;        rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;        rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;        rewrite ^(/core/doc/[^\/]+/)$ $1/index.html;        try_files $uri $uri/ index.php;    }    location ~ ^(.+?\.php)(/.*)?$ {        try_files $1 = 404;        include fastcgi_params;        fastcgi_param SCRIPT_FILENAME $document_root$1;        fastcgi_param PATH_INFO $2;        fastcgi_param HTTPS on;        fastcgi_pass unix:/run/php/php7.4-fpm.sock;    }    location ~* ^.+\.(jpg|jpeg|gif|bmp|ico|png|css|js|swf)$ {        expires modified +30d;        access_log off;    }}

Теперь необходимо получить сертификаты для ssl

Устанавливаем Certbot и его плагин для Nginx:

sudo apt install certbot python3-certbot-nginx

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

Сначала с ключом --dry-run проверяем все ли в порядке

sudo certbot certonly --agree-tos --email you@mail -d nc.myhost.com-d www.myhost.com -d zabbix.myhost.com --nginx --dry-run --d

Если все хорошо, то получаем сертификаты

sudo certbot certonly --agree-tos --email почта@администратора -d myhost.com-d nc.myhost.com-d cloud.myhost.com-d zabbix.myhost.com-d www.myhost.com-d mail.myhost.com sudo certbot certonly --agree-tos --email your@mail -d nc.myhost.com-d www.33rus.com -d zabbix.33rus.com --nginx n 

Сертификаты появятся в папке /etc/letsencrypt/live/myhost.com cert.pem chain.pem fullchain.pem privkey.pem

Подключаем сертификаты к сайту

sudo nano /etc/nginx/sites-available/nextcloud.conf

ssl_certificate /etc/letsencrypt/live/myhost.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/myhost.com/privkey.pem;

Устанавливаем Nextcloud:

Скачиваем последнюю версию с сайте Nextcloud:

cd /tmp/sudo wget https://download.nextcloud.com/server/releases/nextcloud-21.0.0.zipsudo unzip nextcloud-21.0.0.zipsudo cp -R nextcloud /var/www/nextcloud/cd /var/www/sudo chown -R www-data:www-data nextcloud/sudo chown -R www-data:www-data /nfs/nc

Обратите внимание, в данном случае я использую папку на nfs, вам необходимо использовать папку в соответствии с вашими настройками

Почти все. Заходим на https://nc.myhost.com
Создаем пользователя, пароль, прописываем доступ к каталогу /nfs/nc/
Прописываем созданную ранее базу данных и пароль к ней.

Теперь тонкая настройка Nextcloud и установка Onlyoffice

Ставим Redis и APCu

sudo apt install memcached php-memcached -ysudo apt install php-apcu redis-server php-redis -ysudo nano /var/www/nextcloud/config/config.php

И добавляем следующие строки перед закрывающей скобкой )

'memcache.local' => '\OC\Memcache\APCu',
'memcache.distributed' => '\OC\Memcache\Redis',
'redis' =>
array (
'host' => '127.0.0.1',
'port' => 6379,
),
'memcache.locking' => '\OC\Memcache\Redis',

Переиндексация файлов (если вдруг вы скопировали файлы в папку nexcloud не через интерфейсы nextcloud, то их надо переиндексировать)

sudo -u www-data php /var/www/nextcloud/occ files:scan --all

Устанавливаем OnlyOffice DocumentServer

Первым делом устанавливаем версию PostgreSQL, включенную в вашу версию Ubuntu:

sudo apt install postgresql -y

После установки PostgreSQL создайте базу данных и пользователя PostgreSQL:

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

sudo -i -u postgres psql -c "CREATE DATABASE onlyoffice;"sudo -i -u postgres psql -c "CREATE USER onlyoffice WITH password 'onlyoffice';"sudo -i -u postgres psql -c "GRANT ALL privileges ON DATABASE onlyoffice TO onlyoffice;"

Установка rabbitmq и nginx-extras:

sudo apt install rabbitmq-server -ysudo apt install nginx-extras -y

Установка ONLYOFFICE Docs

Добавьте GPG-ключ:

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys CB2DE8E5

Добавьте репозиторий ONLYOFFICE Docs:

sudo echo "deb https://download.onlyoffice.com/repo/debian squeeze main" | sudo tee /etc/apt/sources.list.d/onlyoffice.list sudo apt update

Устанавливаем mariadb-client!

sudo apt install mariadb-client -y

Устанавливаем ONLYOFFICE Docs. Не ошибитесь с вводом пароля. Это должен быть onlyoffice

sudo apt install onlyoffice-documentserver -y

Переводим onlyoffice на https

sudo cp -f /etc/onlyoffice/documentserver/nginx/ds-ssl.conf.tmpl /etc/onlyoffice/documentserver/nginx/ds.confsudo nano /etc/onlyoffice/documentserver/nginx/ds.conf 

Меняем порт ssl не забыв пробросить его в роутере

listen 0.0.0.0:7443 ssl;
listen [::]:7443 ssl default_server;

Перезапускаем nginx

sudo service nginx restart

Настраиваем cron

sudo crontab -u www-data -e

# Добавляем строчку

*/5 * * * * php -f /var/www/nextcloud/cron.php

Ну, вот и все, останется через веб-интерфейс установить плагин ONLYOFFICE в вашем Nextcloud и прописать сервер https://myhost.com:7443

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

Ингосстрах обратилась к нам со следующей задачей: из-за огромного количества ручных операций параметр time-to-market их цифровых продуктов в некоторых случаях был достаточно высоким. Это не устраивало никого: ни разработчиков, ни тестировщиков, ни бизнес. Требовалось как можно сильнее сократить time-to-market, не стесняясь в ресурсах и средствах.

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

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

Подготовка к проекту

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

Выбор решения: open source против корпораций

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

• open source или OpenStack с последующей доработкой;

• сугубо коммерческое решение от VMware.

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

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

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

Как строился гибрид

На первом этапе инфраструктура не очень большая, но это компенсируется количеством работающих на ней сервисов. Здесь мы развернули все необходимое для облака, в том числе ряд продуктов vRealize: Automation, Operations Manager, Log Insight и NSX-T для сети.

Позже сюда добавился NSX Cloud: он позволяет удобно управлять сетями в публичных облаках, в том числе и в Azure, через NSX. Мы подключили подписку заказчика Azure к vRealize Automation и vRealize Operations Manager последнее нужно, чтобы отслеживать потребление ресурсов.

Общая архитектура гибридного облака

Чтобы обеспечить повышенный уровень сетевой и информационной безопасности, мы использовали CheckPoint. Файрвол заказчика интегрирован с облаком сразу в трех точках. Трафик инспектируется:

• между виртуальными машинами;

• на выходе из облака;

• на входе в сеть заказчика.

На стороне облака развернуты виртуальные аплайнсы для инспекции трафика.

Что касается связанности сегментов облака и локальных машин здесь существует два глобальных варианта. Первый оверлейные сети через NSX. Этим путем мы пойти не смогли, так как между площадкой заказчика и Azure стоит VPN от CheckPoint.

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

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

• Automation оркестрация и автоматизация, плюс портал самообслуживания;

• Operations Manager помимо мониторинга сервисов и использования ресурсов, он осуществляет постбиллинг, определяет стоимость потребленных ресурсов в рамках проекта или конкретного сервиса.

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

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

Сервисы

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

Каталог сервисов облака

Надо сказать, кое-что стало для нас серьезным челленджем: во время написания ТЗ актуальной была версия vRealize Automation 7.6. К моменту, когда пришло время приступать к работе, появилась новая версия 8.

Минутка истории: вплоть до седьмой версии vRealize Automation развивался так же, как и любой другой продукт. Одни функции добавлялись, другие переходили в статус deprecated и заменялись более совершенными. Фактически, это решение VMware еще в 2012 году приобрела у компании DynamicOps и развивала его под своим брендом. 8-я версия vRA это не логическое продолжение старой версии, а принципиально новый внутри продукт. Да, он стал функциональнее и гибче, но часть функций, присутствовавших в 7.6, попросту исчезла.

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

Биллинг

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

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

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

Предбиллинг позволяет в момент заказа сервиса рассчитать стоимость ресурсов (это может быть ВМ, MS SQL Server и т.п.) как на локальной площадке, так и в облаке. Изначально vRA не позволял делать расчеты для Azure. Конечно, можно было бы докупить SaaS-продукт CloudHealth, который позволяет считать постбиллинг для Azure. Однако он все равно не обеспечивает функционал предбиллинга, да и по бюджету уже не проходил. Пришлось дописывать.

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

Мы сделали так, чтобы можно было рассчитывать не только базовые вещи а-ля IaaS, но и произвольные.

Биллинг работает по двум классическим схемам: Pay-as-You-Go и prepaid.

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

Лирическое отступление: с точки зрения читателя вся эта история может выглядеть как пришли, сделали, протестировали, ушли. На самом деле, всё куда интереснее. Облако живет и развивается итеративно. Сначала реализуется самый важный функционал в случае с Ингосстрах это эффективное развертывание виртуальных машин. Затем прочие нужные и полезные вещи. Аппетит приходит во время еды это как раз про облако. Поэтому классические для сейлзов формулы заложим на разработку сто дней, авось, уложимся это уже дурной тон.

Следующие на очереди стандартные для облаков сервисы.

IaaS

Здесь речь идет о развертывании ВМ с определенными ОС и набором базовых настроек. В наборе заказчика присутствуют и различные версии Windows Server, и Linux (CentOS и RedHat).

Используемые версии Windows Server 2019, 2016 и 2012 R2. Часть систем заказчика до сих пор работают в 2012 R2. Это вызвало некоторые накладки: в Azure готовых образов этой ОС нет, т.к. Microsoft больше ее не поддерживает. Пришлось загружать свой образ. Так как речь идет о гибридной модели, сервисы предоставляются зеркально: можно создавать их как внутри локальной площадки, так и в Azure. При заказе пользователь сам определяет площадку размещения.

Дополнительно была реализована автоматическая регистрация в DNS. Соответственно, сразу после создания виртуальная машина становится доступна по DNS-имени.

Что касается развертывания машин здесь возможны два подхода:

• пользователь сам определяет параметры ВМ CPU, RAM, дисковое пространство;

• предварительно заданные конфигурации, между которыми может выбирать пользователь.

После обсуждения с заказчиком мы пришли к выводу, что использование заготовленных конфигураций удобнее. Во-первых, можно четче спланировать инфраструктуру. Мы четко знаем, что можно создать 10 машин типа А или, например 5 машин типа Б. Если давать пользователю полную свободу выбора, никакой стандартизации не выйдет. В конфигурации Ингосстраха изменить можно только объем дискового пространства: есть нижняя граница, есть верхняя, есть размер по умолчанию. Единственный нюанс в Azure минимальный объем диска составляет 127 Гб. Соответственно, и на vSphere нам пришлось в целях унификации сделать такой же нижний порог.

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

Форма заказа сервиса IaaS

У заказчика в облаке есть три контура безопасности, каждый со своим уровнем защиты: test, dev и prod. Соответственно, тот или иной сервис размещается в своем контуре по выбору заказчика, независимо от того, локальная ли это площадка или Azure.

PaaS

Переходим к PaaS, здесь тоже немало интересных моментов. В основе PaaS лежит IaaS, используются заранее подготовленные ОС. Все Windows-сервисы (SQL, Active Directory, IIS) могут быть развернуты в любой версии этой ОС, которая требуется пользователю. Кроме, разве что, Exchange.

Основная заточка сделана под версию 2012: более свежие версии включают новый функционал, но из соображений обратной совместимости ничего из legacy не удаляется. А если бы мы ориентировались на 2019, не исключено, что пришлось бы писать разные скрипты под разные типы ОС.

Веб-сервер как услуга

Заказчик использует IIS от Microsoft. Он представлен в нескольких вариантах, в том числе есть версия с балансировкой, которая автоматически настраивается на NSX.

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

• одноузловая конфигурация сервис с IIS.

• ферма множество веб-серверов IIS.

Пользователь может создать сразу множество серверов IIS и обеспечить балансировку подключений на базе NSX. Можно использовать стандартные порты, можно переопределить их вручную. Всё взаимодействие происходит в веб-интерфейсе.

Active Directory

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

Сервис можно развернуть в двух вариантах:

• standalone одноузловая конфигурация, когда контроллер домена и DNS совмещены;

• отказоустойчивая конфигурация два контроллера домена, между которыми в рамках развертывания настроена репликация (и самого домена, и DNS-зон).

СУБД как сервис

• MS SQL Server можно развернуть по двум типам: standalone и кластерная конфигурация always on, от 2 до 4 узлов. Присутствует возможность выбора версий. Под разные версии СУБД написаны разные скрипты установки.

Exchange как сервис

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

Казалось бы, зачем нужна вторая почтовая система в рамках облака? У заказчика была конкретная цель тестировать актуальную конфигурацию на предмет установки обновлений, масштабирования и прочих изменений. Мы сделали фактически полную (с точки зрения конфигурации) копию боевой почтовой системы. Важный момент продуктив работал на базе сразу 2-х ЦОДов. Мы сымитировали и это.

Часть дизайна сервиса Exchange

Автоматизация предоставления сервисов

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

К примеру, чтобы определить область, где пользователь может развертывать ВМ, администратор должен создать проект, назначить ресурсы и выдать пользователю доступы. Заказчику хотелось разгрузить руки администраторов и позволить пользователям через портал самообслуживания самостоятельно создавать проекты. Чтобы не выдавать права администратора направо и налево, необходим был сервис, который перед созданием проекта запрашивал бы аппрув. Пользователи ограничены квотами на количество ВМ, vCPU, RAM и дисковое пространство.

Всего для этой цели используется 4 связанных сервиса:

• создание проектной области;

• изменение можно добавлять облачные ресурсы к локальным или увеличивать их пул;

• удаление если проект больше не нужен, его можно удалить в целях экономии средств;

• архивация временная деактивация проекта и перенос его на самые бюджетные ресурсы.

Всем, кто задумывается о собственном облаке

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

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

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

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

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

• Автоматизация, инструменты самообслуживания, возможности интеграции через API позволяют существенно оптимизировать процессы предоставления ресурсов ИТ-инфраструктуры и, как следствие, сократить time-to-market ИТ-продуктов компании как для внутреннего, так и для внешнего потребления.

На этом все! Если у вас есть какие-то вопросы, буду рад пообщаться в комментариях.

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

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

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

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

1. uXprice

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

Одной из фишек сервиса есть разделение способов мониторинга на автоматический поиск конкурентов на рынке (до 100 конкурентов на каждый товар) и отслеживание конкурентов по ссылкам. Можно использовать оба способа вместе для получения максимального количества данных. Для структурирования последних есть несколько разных видов отчетов, графики и дашборды.

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

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

Недостатки

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

2. Scrapy

Это один из лучших (если не лучший) фреймворк для создания собственного парсера данных. Для установки требуется Python 3.6+, CPython или PyPy 7.2.0+.

В Scrapy есть полный функционал, чтобы написать паука с такими возможностями:

• извлекать необходимую информацию из HTML и XML документов с использованием регулярных выражений;

• сохранять очищенные данные в нескольких форматах (JSON, CSV, XML) и их хранение в нескольких бэкэндах (FTP, S3, локальная файловая система);

• осуществлять переходы по ссылкам;

• выполнять POST запросы, поддерживать куки и сессии, аутентификации;

• подменять пользовательских агентов (user-agent) и др.

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

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

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

3. Octoparse

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

Для работы можно использовать локальное извлечение данных или облачное (в этом случае скорость увеличится в 4-10 раз за счет использования серверов системы). Кроме того, есть функция Smart Mode, которая сведет настройки к минимуму.

Преимущества:

• простота использования

• возможность парсинга контента почти с любых сайтов

• настройка графика извлечения данных

• загрузка и структурирование собранных данных в формате Excel или CSV

• смена IP-адресов как защита от возможной блокировки.

Чтобы обеспечить стабильность своей работы, Octoparse имитирует поведение пользователей на сайте, повторяя популярные человеческие модели взаимодействия с его интерфейсом. Но сейчас уже этого недостаточно, поэтому и прибегают к возможности смены IP-адресов.

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

4. E-Trade Jumper

Программа для сравнения цен конкурентов E-Trade Jumper является одним из решений украинской компании Elbuzgroup позволяет ежедневно отслеживать цены на нужных сайтах и получать мгновенные уведомления при их изменении. Среди аналогов эту программу выделяет наличие дополнительного функционала:

• анализ закупочных прайсов;

• правила переоценки.

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

Этапы мониторинга цен с E-Trade Jumper

1. Загрузить свои товары в программу

2. Добавить 1-го конкурента и настроить парсинг его сайта

3. Проверить достоверность полученных данных

4. Повторить пункты 2-3 для каждого следующего конкурента

5. Проанализировать собранные программой данные

6. Настроить правила переоценки так, чтобы не продавать в минус

7. Установить модуль программы на свой сайт (если он подойдет к вашей cms)

8. Поменять свои цены

Недостатки

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

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

5. Excelvba

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

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

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

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

Недостатки

Чтобы представить масштаб ручной работы на этом этапе, возьмем магазин на 5 000 товаров. Для эффективной оптимизации цен целесообразно отслеживать минимум 3 конкурента на каждый товар. По несложным подсчетам и при минимальном количестве отслеживаемых конкурентов это уже 15 000 ссылок (5 000*3 = 15 000), которые нужно вводить вручную. При этом ссылки на сайтах конкурентов могут меняться, что тоже нужно будет регулярно исправлять.

Кроме того, 100% пересечение ассортимента с магазином конкурента вряд ли возможно. А значит, чтобы добиться отслеживания хотя бы 3-ех конкурентов на товар, придется подключить и настроить 10+ сайтов конкурентов.

6. Datacol

Эта программа для сравнения цен конкурентов одна из старейших в русскоязычном интернете работает с 2007 года. До сих пор продолжает свое существование она не потому, что выдерживает конкуренцию с современными сервисами мониторинга цен. А потому, что является собранием из разно функциональных парсеров: сайтов магазинов, досок объявлений по типу Avito, Google, Яндекс, соцсетей, контента, ключей для SEO и др.

Годовая лицензия на каждый из таких парсеров стоит до 2000 рублей без доработок и при условии, что сайт конкурента есть в списке доступных. Добавление же нового конкурента или внесение изменений в стандартный функционал это еще от 2000 рублей. Для заказа такой доработки нужно составить подробное ТЗ (любые изменения мимо него оплачиваются дополнительно) и внести предоплату. Если стоимость доработки менее 3000 рублей, то предоплата составляет 100%.

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

• какую именно информацию следует извлекать из сайтов?

• в каком виде и объеме она должна собираться?

• как часто нужно парсить сайты?

• должны ли собранные данные храниться (в каком виде, объеме, как долго)?

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

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

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

Недостатки

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

7. Pricetraxer

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

• зарегистрироваться и скачать программу;

• установить программное обеспечение на свой ПК;

• проверить работу на тестовом примере;

• добавить ссылки на товары конкурентов, которые вы хотите отслеживать;

• запустить мониторинг.

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

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

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

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

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

Недостатки

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

8. Konkurenta.net

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

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

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

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

Недостатки

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

9. QuadCRM.X

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

• сбора и сравнения цен конкурентов

• автоматизации добавления товаров на сайт

• удобной работы с прайсами

Сравнивая QuadCRM.X с конкурентами, приятно удивляет наличие веб-интерфейса для работы и достаточного количества обучаемых материалов, которые включены в стоимость (работать в программе без обучения не получится). Использование стационарной программы предполагает неограниченное количество прайсов и обновления, которые входят в стоимость 690$.

В тариф входит настройка парсинга специалистами для 4 сайтов. Каждый конкурент свыше этого лимита это плюс 50$. Или парсинг нужно настраивать самостоятельно. Общение с технической поддержкой будет доступно до 6 месяцев.

Софт для сравнения цен конкурентов будет работать с вашего ПК (он должен быть достаточно мощным) и может собирать следующую информацию:

• стоимость товара;

• акционные предложения;

• наличие товара;

• рейтинги и отзывы конкурентов.

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

Недостатки

Сюда можно отнести необходимость покупки двух программ (QuadCRM.X и QuadPrice), маленький лимит по настройке парсинга специалистами (всего 4 сайта) и сложный интерфейс (для программиста). Ну а также проблемы с прокси, банами и ложными данными.

10. Модуль 1С 8

Предназначен для оперативной переоценки своих товаров в программе с более или менее знакомым интерфейсом (для некоторых сотрудников). К преимуществам этого варианта относится:

• быстрое добавление товаров для мониторинга с 1С;

• удобный поиск товара по названию, артикулу и даже свойству;

• возможность сортировки по цене (min, max, average);

• выбор валюты (руб, грн, $).

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

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

Недостатки

Если вам нужна программа для сравнения цен в интернете, Модуль 1С 8 это только ее половина. Дополнительно необходимо приобрести еще один модуль Анализ цен в 1С. Что умножает на 2 и стоимость, и все приложенные усилия. Система предусматривает защиту от попадания в бан, устанавливая ограничения на количество запросов, выдавая себя за поисковую систему и т.д. Но это не гарантирует 100% защиты от таких ситуаций и неточности данных.

11. Анализ цен в 1С

Это еще один специальный модуль для 1С, который предназначен для анализа данных, собранных Модулем 1С 8 и упрощения работы с прайсами поставщиков. Установка сулит такие преимущества:

• сравнение нескольких прайсов;

• качественный сравнительный отчет;

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

• переоценка на основе данных о ценах конкурентов;

• формирование заказов товаров у поставщиков.

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

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

Благодаря наглядному выделению цветом, эта программа для сравнения цен в интернете позволяет быстро находить позиции, требующие переоценки в первую очередь. Формула для изменения стоимости содержит данные на основе таких метрик как average, min или max, с возможностью установить определенную наценку и округления.

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

Недостатки

Если переоценку товаров будете осуществлять вы, а с 1С вы не работаете, лучше выбрать другой вариант. Модуль Анализ цен в 1С не является полноценным инструментом для сравнения цен в интернете без Модуля 1С 8, который эти цены собирает. Соответственно, необходимо покупать два модуля, учиться их настраивать под себя и использовать.

12. Netpeak Spider

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

Когда программа для мониторинга цен конкурентов запущена на сканирование, этот процесс длительный по времени. Конечно, это зависит от объема скачиваемой информации. В большинстве случаев прерывать процесс нельзя, так как информация будет утеряна. На Netpeak Spider есть возможность поставить парсинг на паузу и продолжить его позже.

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

Недостатки

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

13. Content Downloader X1

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

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

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

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

• OS Windows не ниже 7 версии (желательно Windows10 64-bi);

• наличие прав сисадмина;

• на оборудовании должен быть Диск C (обязательно C!);

• наличие и работоспособность библиотек DLL;

• установленный Internet Explorer 11 или выше;

• бесперебойный интернет от 512 кбит/с;

• экран с разрешением от 1366х768 до 1920х1080.

Content Downloader X1 продается с разными типами лицензий:

1) Start упрощенная версия для парсинга небольших объемов информации и годичным обновлением (2 000 руб).

2) Standard средняя версия программы с 20 потоками парсинга с годичным обновлением (2 500 руб).

3) Ultimate hard версия с возможностью парсинга в 50-200 потоков, эмуляцией действий пользователей, макросами для парсинга таблиц с характеристиками товаров и 2-ух годичным обновлением (3 000 руб).

Чтобы использовать парсер Content Downloader X1 как программу для анализа цен конкурентов, нужно покупать hard версию Ultimate. Учитывайте, что в стоимость не входит настройка парсинга сайтов, техподдержка отвечает только на вопросы, связанные с активацией продукта, а работать в программе можно только на 1 ПК.

Недостатки

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

14. МС:Мониторинг цен 2.0

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

Преимущества МС:Мониторинг цен 2.0:

• высокая скорость выполнения запросов;

• автоматический поиск конкурентов (только в Яндекс Маркете);

• отправка отчетов с результатами мониторинга на почту;

• переоценка товаров через связывание с 1С.

Интересно, что если вы являетесь продавцом на Яндекс Маркете, то мониторить конкурентов на нем можно и совершенно бесплатно. Такую возможность предоставляет сама площадка. Но есть ограничения не более 10 товаров за 1 день. Если вам такого количества недостаточно (что очень вероятно), вы можете использовать МС:Мониторинг цен 2.0 или его аналоги среди специализированных сервисов. У последних функционал на порядок выше.

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

МС:Мониторинг цен 2.0 это программа для сравнения цен, доступ к которой предоставляется по подписке. В стоимость 10 000 рублей входит настройка мониторинга двух любых товаров с не более чем 20 конкурентами, техподдержка 3 месяца и полугодичные обновления. Обязательное требование действующая лицензия на 1С.

Можно заказать подписку на определенное количество запросов (товаров) в Яндекс Маркете:

• 100 товаров 700 рублей;

• 1 000 товаров 6 000 рублей;

• 10 000 товаров 30 000 рублей.

Недостатки

Чтобы начать использовать МС:Мониторинг цен 2.0 нужно быть пользователем 1С и никак иначе. Еще один существенный недостаток это высокая стоимость. На данный момент она значительно выше, чем у специализированных сервисов: от 3 до 7 рублей за 1 товар. При этом сам поиск конкурентов проводится только на одной площадке (Яндекс Маркет), а возможности по анализу полученных данных и оптимизации цен ограничены.

15. TradesMan

Программа для сравнения цен конкурентов TradesMan может выполнять обработку прайсов и автоматическое сравнение цен в них для мониторинга цен поставщиков. От аналогов софт отличается наличием общего и индивидуального справочника замены, благодаря которому несколько прайсов приводятся к единому виду быстрее и проще. Формат загружаемых документов CSV MS Excel.

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

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

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

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

Недостатки

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

Вывод

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

• проблемы с прокси (трудно найти, работа не стабильная, необходимо постоянно проверять);

• бан парсера на сайте конкурентов (данные не собираются);

• ложная информация (намерено дается парсящим информацию ботам).

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

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

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