По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Сегодня бы хотелось рассказать об IVR (Interactive Voice Response). IVR – автоматическая система обслуживания клиентского обращения. С его помощью, повышается качество и скорость обслуживания клиентов, следовательно, растет лояльность по отношению к компании. IVR позволяет сегментировать клиентские обращения, тем самым, оптимизирует работу операторов и уменьшает время решения клиентского запроса. Безусловно, IVR – системы бывают разные. В крупном бизнесе, дорогие IVR - системы имеют возможность в реальном времени синтезировать речь (ASR), проговаривать текст (TTS), имеют интерфейсы к базам данных (DB), через которые «парсят» запрашиваемую информацию. Такие решения предлагают крупные игроки рынка контактных центров, такие как Cisco Systems, Genesys и Avaya. IVR – системы в таких случаях состоят из сложных скриптов, созданных в специальных графических редакторах. В малом и среднем бизнесе, зачастую, потребности в сложных системах нет. В большинстве случаев, голосовое приветствие с предложением нажать одну из кнопок на телефоне, чтобы соединиться с отделом, или ввести номер для соединения с конкретным сотрудником – является самым оптимальном в соотношение стоимости к результативности. Давайте рассмотрим технологию VXML (Voice eXtensible Markup Language). Язык программирования XML является гибким инструментом для решения ряда задач. Благодаря не сложному синтаксису, нашел повсеместное применение. VXML – это адаптация XML для голосовых приложений. Давайте взглянем на схему ниже. Этот пример реализован на базе технологий Cisco. На базе шлюза, функционирует телефонная платформа CME (Call Manager Express). Предположим, к нам приходит звонок из ТфОП c номера +7-495-2234567 (Телефонная сеть общего пользования), я входящий Dial-Peer видит совпадение. gateway#configure terminal gateway(config)#dial-peer voice 100 pots gateway(config-dial-peer)#description VXML-IVR-TEST gateway(config-dial-peer)#incoming called-number 74952234567 gateway(config-dial-peer)#service VXML-IVR Как только dial-peer совпал, шлюз обращается к flash памяти и запускает выполнение скрипта с названием VXML-IVR. При нажатии кнопок телефона события обрабатываются по DTMF. Ниже показан простейший пример: <?xml version="1.0" encoding="UTF-8"?> <vxml version="2.1" xmlns="http://www.w3.org/2001/vxml" xml:lang="ru-RU"> <form id=" Greeting"> <block> <prompt> Здравствуйте! Вы позвонили в компанию… </prompt> </block> </form> </vxml> Логика обработки входящего звонка диктуется только заказчиком. Стоимость такого решения гораздо ниже, чем серьезные голосовые платформы специально разработанные вендорами. IVR позволяет массово информировать клиентов о каких-либо изменениях, сокращает время обслуживания, повышает лояльность клиента. Мы с радостью поможем создать для Вашего бизнеса голосовое меню, составить техническое задание, написать VXML скрипты.
img
Привет! Сегодня в статье мы рассмотрим процедуру восстановления заводских настроек и сброса телефонов Cisco серии 7900 (7940, 7941, 7942, 7960, 7961, 7962, 7920). Процесс сброса При запуске процедуры сброса настроек к заводским настройкам некоторая информация с IP-телефона стирается, а для других данных устанавливается заводское значение по умолчанию. Информация удаляется: Файл CTL (Certificate Trust List) Файл LSC (Locally Significant Certificate) История телефонных звонков по IP (принятые, выполненные, пропущенные) Телефонное приложение (Phone application) Информация, которая будет сброшена до настроек по умолчанию: Настройки конфигурации пользователя (мелодия звонка, яркость экрана, уровень звука и так далее) Настройки конфигурации сети Что следует учесть перед сбросом IP-телефона Cisco При выполнении процедуры сброса к заводским настройкам, которую мы собираемся описать, важно иметь в виду, что IP-телефон потеряет все файлы конфигурации и приложений телефона. Это означает, что необходимо настроить CUCM или CME, чтобы IP-телефон мог получать новую информацию (файлы конфигурации и приложений) после завершения процедуры сброса, в противном случае наиболее вероятно, что IP-телефон нельзя будет использовать, пока эта информация не будет загружена в него. Эта подготовка также является необходимой процедурой обновления прошивки IP-телефона Cisco. Выполнение заводского сброса на IP-телефонах Cisco 7940 и 7960 Следуйте приведенным ниже инструкциям, чтобы успешно восстановить заводские настройки IP-телефонов Cisco 7940 и 7960: Отключите кабель питания от IP-телефона, а затем снова подключите его. Сразу нажмите и удерживайте кнопку # (решетка), и когда кнопки гарнитуры, отключения звука и динамика начнут последовательно мигать, отпустите кнопку #. В этот момент вы заметите, что кнопки «Headset», «Mute» и «Speaker» мигают последовательно, указывая на то, что IP-телефон ожидает ввода последовательности сброса. Наберите последовательности 123456789*0#, чтобы начать сброс. Если вы случайно нажмете клавишу в последовательности дважды, например, 1123456789*0#, то IP-телефон все равно примет код и начнет сброс. Если нажать недопустимую клавишу, телефон продолжит нормальную процедуру запуска. Как только правильная последовательность клавиш будет введена, на телефоне появится следующее сообщение: “Keep network cfg? 1 = yes 2 = no” Чтобы сохранить текущие параметры конфигурации сети для телефона при его сбросе, нажмите 1. Чтобы сбросить параметры конфигурации сети при сбросе телефона, нажмите 2. Если вы нажмете другую клавишу или не ответите на это сообщение в течение 60 секунд, телефон продолжает нормальный процесс запуска и не сбросится. Выполнение заводского сброса на IP-телефонах Cisco 7941 и 7961 Чтобы сбросить телефоны Cisco 7941 и 7961 необходимо выполнить следующие действия: Отключите кабель питания от IP-телефона, а затем снова подключите его. Сразу нажмите и удерживайте кнопку #, и когда кнопки гарнитуры, отключения звука и динамика начнут последовательно мигать, отпустите кнопку #. Кнопки «Headset», «Mute» и «Speaker» начнут мигать последовательно, указывая на то, что IP-телефон ожидает ввода последовательности сброса. Нажмите 123456789*0#, чтобы начать сброс. Также, если вы случайно нажмете клавишу в последовательности дважды, например, 1123456789*0#, IP-телефон все равно примет код и начнет сброс. Если нажать недопустимую клавишу, телефон продолжит нормальную процедуру запуска. После ввода правильной последовательности клавиш IP-телефон отобразит следующее сообщение и начнет процесс сброса: “ Upgrading” Сброс на IP-телефонах Cisco 7942 и 7962 Для сброса выполните моделях 7942 и 7962 следующие действия: Отключите кабель питания от телефона, а затем снова подключите его. Телефон начинает цикл включения питания. Во время включения телефона и до того, как кнопка динамика начнет мигать, нажмите и удерживайте #. Продолжайте удерживать #, пока каждая кнопка линии не начнет последовательно мигать желтым цветом. Отпустите # и наберите 123456789*0#. Вы можете нажать клавишу дважды подряд, но если вы нажмете клавиши не по порядку, сброс настроек не произойдет. После нажатия этих клавиш кнопки линий на телефоне замигают красным, и телефон начнет проходить процедуру сброса настроек. Не выключайте телефон, пока он не завершит процесс сброса к заводским настройкам и не появится главный экран. Сброс до заводских настроек на беспроводном IP-телефоне Cisco 7920 Для сброса Cisco 7920 IP-телефон должен быть запущен в режиме администрирования, используя следующие шаги: Нажмите программную клавишу “Menu” Нажмите * (звездочка), # (решетка) и * (звездочка) еще раз. Нажмите зеленую кнопку телефона (используется для ответа на звонок), чтобы открыть режим администрирования. Выберите Menu – Phone Settings – Factory Default. На телефоне отобразится сообщение “Restore to Default? ”. Нажмите программную клавишу ОК. Все настройки будут удалены. Выберите Menu – Network Config для перенастройки сетевой конфигурации для вашей WLAN.
img
Микросервисы – это шаблон сервис-ориентированной архитектуры, в котором приложения создаются в виде наборов небольших и независимых сервисных единиц. Такой подход к проектированию сводится к разделению приложения на однофункциональные модули с четко прописанными интерфейсами. Небольшие команды, управляющие всем жизненным циклом сервиса могут независимо развертывать и обслуживать микросервисы. Термин «микро» относится к размеру микросервиса – он должен быть удобным в управлении одной командой разработчиков (5-10 специалистов). В данной методологии большие приложения делятся на крошечные независимые блоки. Что такое монолитная архитектура? Если говорить простым языком, то монолитная архитектура – это как бы большой контейнер, в котором все компоненты приложения соединяются в единый пакет. В качестве примера монолитной архитектуры давайте рассмотрим сайт для электронной торговли. Например, онлайн-магазин. В любом таком приложении есть ряд типовых опций: поиск, рейтинг и отзывы, а также оплаты. Данные опции доступны клиентам через браузер или приложение. Когда разработчик сайта онлайн-магазина развертывает приложение, это считается одной монолитной (неделимой) единицей. Код различных опций (поиска, отзывов, рейтинга и оплаты) находится на одном и том же сервере. Чтобы масштабировать приложение, вам нужно запустить несколько экземпляров (серверов) этих приложений. Что такое микросервисная архитектура? Микросервисной архитектурой называется методика разработки архитектуры, позволяющая создавать приложения в виде набора небольших автономных сервисов для работы с конкретными предметными областями. Такой вариант структурированной архитектуры позволяет организовать приложения в множество слабосвязанных сервисов. Микросервисная архитектура содержит мелкомодульные сервисы и упрощенные протоколы. Давайте рассмотрим пример приложения для онлайн-торговли с микросервисной архитектурой. В данном примере каждый микросервис отвечает за одну бизнес-возможность. У «Поиска», «Оплаты», «Рейтинга и Отзывов» есть свои экземпляры (сервер), которые взаимодействуют между собой. В монолитной архитектуре все компоненты сливаются в одну модель, тогда как в микросервисной архитектуре они распределяются по отдельным модулям (микросервисам), которые взаимодействуют между собой (см. пример выше). Коммуникация между микросервисами – это взаимодействие без сохранения состояния. Каждая пара запросов и ответов независима, поэтому микросервисы легко взаимодействуют друг с другом. Микросервисная архитектура использует федеративные данные. Каждый микросервис имеет свой отдельный массив данных. Микросервисы и монолитная архитектура: сравнение Микросервисы Монолитная архитектура Каждый блок данных создается для решения определенной задачи; его размер должен быть предельно малым Единая база кода для всех бизнес-целей Запуск сервиса происходит сравнительно быстро На запуск сервиса требуется больше времени Локализовать ошибки довольно просто. Даже если один сервис сломается, другой – продолжит свою работу Локализовать ошибки сложно. Если какая-то определенная функция не перестает работать, то ломается вся система. Чтобы решить проблему, придется заново собирать, тестировать и развертывать приложение. Все микросервисы должны быть слабо связанными, чтобы изменения в одном модуле никак не влияли на другой. Монолитная архитектура тесно связана. Изменения в одному модуле кода влияет на другой Компании могут выделять больше ресурсов на самые рентабельные сервисы Сервисы не изолированы; выделение ресурсов на отдельные сервисы невозможно Можно выделить больше аппаратных ресурсов на самые популярные сервисы. В примере выше посетители чаще обращаются к каталогу товаров и поиску, а не к разделу оплат. Таким образом, будет разумнее выделить дополнительные ресурсы на микросервисы каталога товаров и поиска Масштабирование приложения – задача сложная и экономически не выгодная Микросервисы всегда остаются постоянными и доступными Большая нагрузка на инструменты для разработки, поскольку процесс необходимо запускать с нуля Федеративный доступ к данным, благодаря чему под отдельные микросервисы можно подбирать наиболее подходящую модель данных Данные централизованы Небольшие целевые команды. Параллельная и ускоренная разработка Большая команда; требуется серьезная работа по управлению командой Изменения в модели данных одного микросервиса никак не сказывается на других микросервисах Изменения в модели данных влияют на всю базу данных Четко прописанный интерфейс позволяет микросервисам эффективно взаимодействовать между собой Не предусмотрено Микросервисы делают акцент на продуктах (модулях), а не проектах Сосредоточены на проекте в целом Отсутствие перекрестных зависимостей между базами кода. Для разных микросервисов можно использовать разные технологии Одна функция или программа зависит от другой Сложности в работе с микросервисами Микросервисы полагаются друг на друга, поэтому необходимо выстроить коммуникацию между ними. В микросервисах создается больше модулей, чем в монолитных системах. Эти модули пишутся на разных языках, и их необходимо поддерживать. Микросервисы – это распределенная система, так что, по сути, мы имеем дело со сложной системой. В разных сервисах используются свои механизмы; для неструктурированных данных требуется больший объем памяти. Для предотвращения каскадных сбоев необходимо эффективное управление и слаженная командная работа. Трудно воспроизвести ошибку, если она пропадает в одной версии и вновь появляется в другой. Независимое развертывание и микросервисы – вещи слабо совместимые. Микросервисная архитектура требует большего количества операций. Сложно управлять приложением, когда в систему добавляются новые сервисы. Для поддержки всевозможных распределенных сервисов требуется большая команда опытных специалистов. Микросервисы считаются дорогостоящими решениями, поскольку для разных задач создаются и поддерживаются разные серверные пространства. Сервис-ориентированная архитектура (СОА) или микросервисы СОА-сервисы (SOA - Service-oriented architecture) поддерживаются через реестр, который считается перечнем файлов каталога. Приложения должны найти сервис в реестре и вызвать его. Иначе говоря, СОА похож оркестр: каждый музыкант играет на своем инструменте, а всеми артистами управляет дирижер. Микросервисы – это разновидность СОА-стиля. Приложения создаются в виде набора небольших сервисов, а не цельной программы. Микросервисы похожи на труппу артистов: каждый танцор знает свою программу и не зависит от других. Даже если кто-то забудет какое-то движение, вся труппа не собьется с ритма. Теперь давайте поговорим о различиях между СОА и микросервисах. Параметр СОА Микросервисы Тип проектирования В СОА компоненты приложения открыты для внешнего мира; они доступны в виде сервисов Микросервисы – это часть СОА. Такая архитектура считается реализацией СОА Зависимость Подразделения – зависимы Они не зависят друг от друга Размер приложения Размер приложения больше, чем у обычных программ Размер приложения всегда небольшой Стек технологий Стек технологий ниже, чем у микросервисов Стек технологий очень большой Сущность приложения Монолитная Полностековая Независимость и ориентированность СОА-приложения создаются для выполнения множества бизнес-задач Создаются для выполнения одной бизнес-задачи Развертывание Процесс развертывания растянут по времени Несложное развертывание, на которое тратится меньше времени Рентабельность Более рентабельно Менее рентабельно Масштабируемость Меньше, чем у микросервисов Высокая масштабируемость Бизнес-логика Компоненты бизнес-логики хранятся внутри одного сервисного домена. Простые проводные протоколы (HTTP с XML JSON). API управляется с помощью SDK/клиентов Бизнес-логика распределена между разными корпоративными доменами Микросервисные инструменты Wiremock – тестирование микросервисов WireMock – это гибкая библиотека для создания заглушек и сервисов-имитаций. В ней можно настроить ответ, который HTTP API вернет при получении определенного запроса. Также может использоваться для тестирования микросервисов. Docker Docker – это проект с открытым кодом для создания, развертывания и запуска приложений с помощью контейнеров. Использование такого рода контейнеров позволяет разработчикам запускать приложение в виде одного пакета. Кроме того, в одном пакете могут поставляться библиотеки и другие зависимости. Hystrix Hystrix – это отказоустойчивая Java-библиотека. Данный инструмент предназначен для разделения точек доступа к удаленным сервисам, системам и сторонним библиотекам в распределенной среде (микросервисах). Библиотека улучшает всю систему в целом, изолируя неисправные сервисы и предотвращая каскадный эффект от сбоев. Лучшие примеры использования микросервисной архитектуры Отдельное хранение данных для каждого микросервиса. Поддержание кода на едином уровне зрелости Отдельная сборка для каждого микросервиса. Заключение Микросервисы – это СОА-шаблон, в котором приложения создаются как набор малых и независимых серверных единиц. Микросервисная архитектура относится к стилям разработки архитектуры, позволяющим создавать приложение в виде небольших и автономных сервисов для определенных предметных областей. Монолитная архитектура похожа на большой контейнер, в котором все компоненты приложения собраны в один пакет. Каждый блок приложения в микросервисе имеет предельно малый размер и выполняет определенную функцию. Большая база кода в монолитной архитектуре замедляет процесс разработки. Выход новых версий может растянуться на месяцы. Поддерживать такую базу кода довольно сложно. Существует 2 типа микросервисов: Stateless (без сохранения состояния) и Stateful (с отслеживанием состояния) Микросервисы на Java полагаются друг на друга; они должны взаимодействовать между собой. Микросервисы позволяют в большей степени сконцентрироваться на определенных функциях или потребностях бизнеса. Сервисно-ориентированная архитектура, или СОА, – это усовершенствованные распределенные вычисления, основанные на проектной модели запроса/ответа в синхронных или асинхронных приложениях. Компоненты приложения в СОА открыты для внешнего мира и представлены в виде сервисов; микросервисы считаются частью СОА. Это реализация СОА. К популярным микросервисным инструментам относятся Wiremock, Docker и Hystrix.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59