НАЦІОНАЛЬНИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ УКРАЇНИ «КИЇВСЬКИЙ ПОЛІТЕХНІЧНИЙ ІНСТИТУТ імені ІГОРЯ СІКОРСЬКОГО» Факультет інформатики та обчислювальної техніки Кафедра автоматики та управління в технічних системах

До захисту допущено: Завідувач кафедри ______Олександр РОЛІК «___»______20__ р.

Дипломний проєкт на здобуття ступеня бакалавра за освітньо-професійною програмою «Комп'ютеризовані системи управ- ління» спеціальності 151 «Автоматизація та комп'ютерно-інтегровані технології» на тему: «Система самообслуговування клієнтів на базі технології Amazon»

Виконав (-ла): студент (-ка) IV курсу, групи ІА-61 Абушек Дмитро Андрійович ______

Керівник: Доцент каф. АУТС, к.т.н., Дорогий Я. Ю. ______

Рецензент: Доцент, Цуркан Василь ______

Засвідчую, що у цьому дипломному проєкті немає запозичень з праць ін- ших авторів без відповідних поси- лань. Студент (-ка) ______

Київ – 2020 Національний технічний університет України «Київський політехнічний інститут імені Ігоря Сікорського» Факультет інформатики та обчислювальної техніки Кафедра автоматики та управління в технічних системах Рівень вищої освіти – перший (бакалаврський) Спеціальність – 151 «Автоматизація та комп'ютерно-інтегровані техноло- гії» Освітньо-професійна програма «Комп'ютеризовані системи управління»

ЗАТВЕРДЖУЮ Завідувач кафедри ______Олександр РОЛІК «___»______20__ р.

ЗАВДАННЯ на дипломний проєкт студенту Абушек Дмитру Андрійовичу

1. Тема проєкту «Система самообслуговування клієнтів на базі технологій Amazon», керівник проєкту Дорогий Ярослав Юрійович, к.т.н., доцент, затверджені наказом по університету від «07» травня 2020р. №1081-с

2. Термін подання студентом проєкту 09.06.2020

3. Вихідні дані до проєкту: Розуміння визначених команд людською мовою. Можливість синтезу людської мови. Автоматичне здійснення вихідних дзвінків без участі людини. Підтримка базового функціоналу кон- тактного центру (ручне здійснення вхідних та вихідних дзвінків, запис роз- мови, формування черги).

4. Зміст пояснювальної записки: зробити огляд існуючих рішень, обгрунтувати обрані технології, розробити архітектуру та спроектувати си- стему

5. Перелік графічного матеріалу: UML діаграма комунікації, UML діаграма послідовності, UML діаграма компонентів, UML діаграма викори- стання. 6. Дата видачі завдання 05.03.2020.

Календарний план

№ Назва етапів виконання дип- Термін вико- Примітка ломного проєкту нання етапів проєкту 1 Затвердження теми роботи 12.02.2020 2 Аналіз існуючих рішень 26.03.2020 3 Опрацювання літературних 10.04.2020 джерел пов’язаних з асин- хронними операціями 4 Розробка функціональної 17.04.2020 блок схеми 5 Розробка архітектури проєкту 24.04.2020 6 Розробка 23.04.2020 7 Розробка тестового за- 13.05.2020 стосунку 8 Оформлення матеріалів 22.05.2020 проєкту 9 Передзахист 25.05.2020 10 Захист 15.06.2020

Студент Дмитро АБУШЕК

Керівник Ярослав ДОРОГИЙ

АНОТАЦІЯ

Абушек Д.А. І. Система самообслуговування клієнтів на базі технологій Amazon. НТУУ «КПІ ім. Ігоря Сікорського», Київ, 2020. Проект містить 68 с. тексту, 19 рисунків, 4 кресленика, посилання на 27 літературних джерел та 2 додатки.

Ключові слова: діалоговий бот, контактний центр, обслуговування клієнтів, Amazon Web Services, AWS.

Об’єктом розробки є інтелектуальний діалоговий бот для обслуго- вування клієнтів. Метою розробки є автоматизація частини роботи операторів контакт- ного центру та зменшення витрат підприємства на обслуговування інфра- структури завдяки використанню хмарних технологій. У якості демонстра- ційної частини розроблено простий веб-додаток з інтегрованою в нього спро- ектованою системою.

SUMMARY Abushek D.A. Customer self-service system powered by Amazon. NTUU “Igor Sikorsky Kyiv Polytechnic Institute”, Kyiv, 2020. The project contains 68 pages of text, 19 figures, 4 design documents, refer- ences to 27 literature sources and 2 annexes.

Keywords: dialogue bot, contact center, customer service, Amazon Web Ser- vices, AWS.

The development object is a smart dialog bot for the customer service. The development purpose is to automate contact centre operators' part of work. Also, it has a task to reduce the costs of the enterprise infrastructure maintain- ing by using cloud computing.

As a demonstration part, a simple web application with a designed integrated system has been developed.

Пояснювальна записка до дипломного проєкту на тему: «Система самообслуговування клієнтів на базі технологій Amazon»

Київ - 2020

ЗМІСТ

ВСТУП ...... 4 1 Огляд існуючих рішень ...... 8 1.1 Хмарні контактні центри ...... 8 1.1.1 Аутсорсінговий контактний центр ContactCall ...... 8 1.1.2 Electronic Voice Services 7 (EVS7) ...... 10 1.2 Розпізнавання мови ...... 11 1.2.1 Google Cloud Speech-To-Text API ...... 11 1.2.2 Nuance speech recognition...... 13 1.2.3 IBM Watson Speech to Text ...... 15 1.3 Автоматичні телефонні станції ...... 17 1.3.1 Архітектура SIP ...... 18 1.3.2 Asterisk ...... 20 1.3.3 FreeSWITCH...... 22 1.3.4 SipXecs ...... 23 1.4 Безсерверна архітектура ...... 24 1.4.1 Azure Functions ...... 25 1.4.2 Google Cloud Functions ...... 27 1.5 Висновки ...... 28 2 Обгрунтування обраних технологій ...... 29 2.1 Amazon Lex ...... 31 2.2 Amazon Connect ...... 32

ІА61.010БАК.002.ПЗ Зм. Лист № докум. Підпис. Дата Розробив Абущек Д.А. Система самообслуговування Літ. Лист. Листів Перевірив Дорогий Я.Ю. 2 68 клієнтів на базі технологій Amazon КПІ ім. Ігоря Сікорсь- Н. контр. Пояснювальна записка Затв. кого ФІОТ

2.3 Amazon Lambda ...... 36 2.4 Amazon Virtual Private Cloud ...... 40 2.5 Amazon S3 ...... 41 2.5.1 Безпека і керування ...... 42 2.6 Amazon DynamoDB ...... 43 2.7 Amazon CloudWatch ...... 44 2.8 Amazon Kinesis ...... 46 2.9 Висновки ...... 47 3 Розробка архітектури та проектування системи ...... 49 3.1 Висновки ...... 62 ВИСНОВКИ ...... 63 СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ...... 65

Лист ІА61.010БАК.002.ПЗ Зм. Лист № докум. Підпис Дата 3

ВСТУП

У світі існує величезна кількість підприємств, що працюють в сфері об- слуговування. Всі вони так або інакше мають взаємодіяти зі своїми клієнтами. Актуальність проблеми. Для кожного підприємства вкрай важливо, щоб його клієнти були задоволені послугами. Це стосується не лише надання якісного продукту або послуги, але й спілкування з клієнтом. Клієнти можуть звертатися за додатковою інформацією або зі скаргами. В обох випадках вони мають залишитися задоволеними якістю обслуговування. Дослідження пока- зали, що 42% клієнтів починають більше користуватися послугами компанії після отримання якісного обслуговування при зверненні до компанії. В той час як 52% клієнтів зовсім припинили користуватися послугами компанії після по- ганого обслуговування[1]. Компанія повинна не лише надавати високоякісне обслуговування, а й бути готовою до звернення своїх клієнтів у будь-який час. Адже 57% спожи- вачів очікують отримати відповідь у неробочі часи та навіть у нічний час або вихідні дні [1]. Для забезпечення надання послуг високого рівня в напрямку обслуго- вування клієнтів компанії починають створювати контактні центри або колл- центри. Зазвичай це окремий підрозділ в організації, що займається обробкою звернень і інформуванням клієнтів по голосовим каналам зв’язку. Для забез- печення високої якості обслуговування і цілодобової роботи такі відділи ма- ють мати відповідний штаб операторів підтримки, що працюють позмінно. Ін- фраструктура, що буде включати в себе спеціальне обладнання має обслуго- вуватися спеціалістом для забезпечення відмовостійкості. Об’єкт дослідження – контактні центри. З ростом компанії постійно ви- никає проблема масштабування. Традиційна інфраструктура контактного цен- тра містить серверну апаратуру та робочі станції, які об’єднані в одну мережу. Якщо контактний центр розростеться то потрібно буде виділяти більше

Лист ІА61.010БАК.002.ПЗ 4 Зм. Лист № докум. Підпис Дата

приміщення та розгортати всі інфраструктуру наново. Зі зростанням наванта- ження необхідно докупляти нові сервери та наймати нових співробітників, при цьому необхідно підтримувати рівень комфорту робочих місць в приміщен- нях. Предмет дослідження – автоматизація роботи оператора контактного центру. Адже робота оператора доволі нудна і одноманітна. Особливо це сто- сується вихідних дзвінків, що мають за мету інформування клієнтів. Опера- тори повинні постійно говорити один і той же текст, а у відповідь клієнт не скаже нічого інформативного або навіть покладе слухавку. Вхідні дзвінки теж в значній кількості досить одноманітні і не потребують від оператора особли- вої активності та творчості. Така робота дуже важка емоційно, тому в колл- центрах дуже часто має місце плинність кадрів. Метою бакалаврського проекту є створення діалогового бота для само- обслуговування клієнтів. Так програмне рішення буде представляти собою ос- нову для контактного центру з функціями інтелектуального бота. Система має автоматизувати частину роботи операторів контактного центру та зменшити витрати підприємства на обслуговування інфраструктури контактного центру. Тож результатом виконання роботи має бути комплексна система, яка має вирішувати такі підзадачі:  дає можливість здійснювати вхідні та вихідні дзвінки операторам контактного центру;  розбирати та аналізувати людську мову за допомогою діалогового бота;  здійснює автоматичні вихідні дзвінки з використанням діалого- вого бота;  автоматично приймати вхідні дзвінки та оброблювати прості пи- тання клієнта без участі оператора контактного центру;  записувати та зберігати запис розмови;

 записувати в лог важливу інформацію під час здійснення дзвінка; Лист ІА61.010БАК.002.ПЗ 5 Зм. Лист № докум. Підпис Дата

 мати надійне сховище для даних.  формувати звіти по здійсненим та прийнятим дзвінкам.  візуально відображати на робочому місці оператора інформацію про дзвінок та про клієнта (у тому числі з використанням CRM системи).  статична та інтелектуальна маршрутизація звернення (організація черги). Ця система не буде змінювати схему роботи традиційного контактного центра – оператори підтримки будь здійснювати вихідні і приймати вхідні дзвінки. Дзвінки будуть записуватися і зберігатися в сховищі даних, якщо це необхідно. Але між оператором і клієнтом з’явиться проміжна ланка – діало- говий бот. Діалоговий бот зможе автоматично здійснювати вихідні дзвінки для ін- формування абонентів. Також він зможе обслуговувати клієнтів з простими питаннями без участі оператора. Якщо чатбот не в змозі обробити питання клієнта та вирішити його самостійно – він передає дзвінок оператору контакт- ного центру. Система буде підтримувати інтеграцію з іншими веб-додатками та CRM системами для забезпечення прямого зв’язку колл-центра з інформаційною ба- зою підприємства. Такий підхід підвищить зручність для оператора у користу- ванні системою. Адже під час дзвінка у оператора перед очима буде вся до- ступна інформація з бази про клієнта. При проектуванні системи було звернено увагу на сучасні технології, що мають зменшити вартість обслуговування та збільшити простоту налашту- вання та використання системи. Зокрема були вирішено використовувати хмарні сервіси та технології безсерверного обчислення. Практичне значення. Спроектована та розроблена система автоматизує процеси всередині підприємства пов’язані з обслуговуванням клієнтів. Вона зменшує навантаження на операторів контактного центру.

Лист ІА61.010БАК.002.ПЗ 6 Зм. Лист № докум. Підпис Дата

Слід відзначити, що система економить кошти підприємства на за- купівлі, встановленні та обслуговуванні спеціального обладнання, необхід- ного для реалізації автоматичної телефонної станції та сховищ для зберігання логів та записів розмов. Відсутність відповідної інфраструктури означає і від- сутність потреби наймати спеціалістів для обслуговування цієї інфраструк- тури. Бакалаврський проект складається з наступних розділів: вступ, огляд існуючих рішень, обгрунтування обраних технологій, розробка архітектури та проектування системи, висновки, список використаних джерел із 27 найме- нувань, 1 додатку. Графічна частина включає 4 кресленики формату А3: UML діаграма ко- мунікації, UML діаграма компонентів, UML діаграма послідовності, UML діаграма використання.

Лист ІА61.010БАК.002.ПЗ 7 Зм. Лист № докум. Підпис Дата

1 ОГЛЯД ІСНУЮЧИХ РІШЕНЬ

1.1 Хмарні контактні центри

Хмарні контактні центри – це сервіси, які надаються великими ком- паніями, що займаються виключно обслуговуванням клієнтів та мають великі потужності, як у кількості працівників, так і стосовно наявної інфраструктури. Опис структури їх систем та технічна документація відсутні, тому що це ко- мерційна тайна компаній. Тож було досліджено запропоновані ними послуги, щоб мати представлення, який функціонал надається на ринку таких послуг.

1.1.1 Аутсорсінговий контактний центр ContactCall

ContactCall - це організація, що надає послуги контактного центру як сервіс [2]. ContactCall є постачальником широкого спектру послуг для ре- алізації контактного центру поза межами підприємства. Нижче наведено їх пе- релік :  гаряча лінія;  віртуальний офіс;  аутсорсинг персоналу;  аутсорсинг прийому дзвінків;  телемаркетинг;  проведення телефонних опитувань;  автоматичний обдзвін;  голосове меню IVR (Interactive Voice Response);  розсилка голосових повідомлень;  прямий номер;  відстежування дзвінків; ContactCall одразу має готові конфігурації для потреб компаній з якоюсь направленістю. Так, наприклад, вони пропонують бізнес-рішення для:

Лист ІА61.010БАК.002.ПЗ 8 Зм. Лист № докум. Підпис Дата

 служб доставки;  служб таксі;  інтернет магазинів;  туроператорів;  провайдерів зв’язку;  банкам та страховим компаніям;  виробникам;  дистриб’юторам. До переваг такого постачальника послуг можна віднести: – Скорочення витрат. Компанія не потребує витрачати кошти на ор- ганізацію робочих місць, пошук і підготовку персоналу, організацію інфра- структури для телефонії; – Збереження часу. Штаб операторів зв’язку, яких компанія орендує на визначений строк, працює цілодобово; – Оцінка результатів. ContactCall надає результати поточної маркетин- гової кампанії і при необхідності змінити напрямок розвитку. Але головним недоліком такого підходу можна вважати відсутність за- цікавленості операторів в успіхах компанії, що їх наймає. У ContactCall всі оператори досконало вивчають продукт, з яким будуть мати справу, та, за необхідності, складають тести компанії-замовника. Не зважаючи на все це, оператори сидять в місці, недосяжному до менеджерів компанії. Це означає, що вони ніяк не залучені до внутрішніх процесів компанії і не зацікавлені в успішності компанії на ринку. З цього можна зробити висновок, що набагато краще мати своїх людей у якості агентів підтримки, проводити з ними постійну роботу для підвищення рівня зацікавленості і ентузіазму.

Лист ІА61.010БАК.002.ПЗ 9 Зм. Лист № докум. Підпис Дата

1.1.2 Electronic Voice Services 7 (EVS7)

EVS7 – розробник програмного забезпечення та обладнання для автома- тизації, прийому та здійснення телефонних дзвінків [3]. Їх система спроекто- вана для компаній у сфері продажу, великого та малого бізнесу. EVS7 надає три сервіси, кожен з яких можна використовувати для своїх цілей. Потрібно розглянути їх по порядку: – Cricket Click Dialer. Це софтфон, у якому можна здійснювати дзвінки з комп’ютера «за кліком мишки». Дозволяє відправляти до 5 голосових листів. Дзвінки передбачають можливу інтеграцію з CRM системами, що є дуже зруч- ним для бізнесу; – Dolphin Power Dialer. Цей сервіс автоматизує проведення кампаній з телемаркетингу. Він надає можливість здійснювати до 4-х разів більше дзвінків ніж звичайним ручним набором. Наприклад, якщо компанія-замовник займається продажом якихось речей або послуг, Dolphin Power Dialer буде здійснювати вихідні дзвінки сам по списку номерів, що є в базі компанії, та з’єднувати з оператором тільки тоді, коли клієнт вже взяв слухавку. Це дозво- ляє не витрачати час оператора на очікування абонента. Також сервіс іденти- фікує клієнта за номером для кращого індивідуального підходу. Більше того, він маскує номер, з якого ви дзвоните, щоб збити з пантелику клієнтів, які за- звичай не беруть слухавку. Таким чином підвищується відсоток так званого додзвону; – Parrot Predictive Call Center – це повноцінний контакт центр, що дозво- ляє кожному оператору одночасно спілкуватись на п’ятьох лініях, макси- мально підвищуючи свою продуктивність. Всередині цього центру можна створювати спеціалізовані групи людей та планувати кампанії. Також надається інформаційна сторінка з результатами моніторингу для виявлення активності та продуктивності кожного з операторів.

Лист ІА61.010БАК.002.ПЗ 10 Зм. Лист № докум. Підпис Дата

Досить суттєвою перевагою цього сервісу є не тільки можливість кори- стування через браузер, але й готову інтеграцію з такими великими CRM си- стемами, як Zoho, Salesforce, Less Annoying CRM, Leadmaster, Suite CRM, Mi- crosoft Dynamics та багатьох інших. Звісно, інтеграція не в усіх з них не буде потребувати додаткового налаштовування. Для вирішення цієї проблеми EVS7 надає відкрите API, що дозволяє більш гнучко налаштувати взаємодію CRM системи з обраним сервісом.

1.2 Розпізнавання мови

З розвитком робототехніки та сервісів, що керуються голосом, такі тех- нології, як Automatic Speech Recognition (ASR) та Speech-To-Text (STT), ста- ють все більш розвинутими. Вони можуть бути використані для проведення діалогу з чат-ботом, роботом або для автоматичного перетворення у текст аудіозаписів розмов, фільмів тощо. Концепція розпізнавання мови зародилася у 80-х роках, коли бельгійська компанія Lernout & Hauspie почала розроблюв- ати продукти у цьому напрямку. Через 15 років вони досягли перших успіхів у сфері розпізнавання та синтезу мови. В 1999 році вони відкрили техно- логічний кампус, який називався Flanders Language Valley, але у 2001 році ком- панія стала банкротом. Внаслідок чого технічний відділ перейшов до амери- канської компанії Scansoft, що наразі називається Nuance і є головним рушієм промислового розпізнавання мови. Наразі все більше і більше таких компаній, як Google, Apple, Amazon and IBM починають займатися дослідженнями в цій сфері та випускають свої сервіси, що в більшості орієнтовані на користувачів та ринок B2B (Business to business).

1.2.1 Google Cloud Speech-To-Text API

Google Cloud Speech-To-Text API надається платформою Google Cloud та надає можливість розробникам конвертувати аудіо в текст за допомогою

Лист ІА61.010БАК.002.ПЗ 11 Зм. Лист № докум. Підпис Дата

моделей нейронних мереж. Сервіс розпізнає 120 мов та діалектів, що забезпе- чує підтримку глобальної аудиторії. Розробник може впровадити голосове ке- рування, перетворювати у текст дзвінки з колл-центрів. Є можливість оброб- лювати аудіопотік у реальному часі і попередньо записане аудіо у вигляді аудіофайлу, використовуючи технології машинного навчання. Технології ма- шинного навчання включають в себе найбільш сучасні алгоритми глибинних нейронних мереж (deep neural network) для розпізнавання мови з великою точ- ністю. Нажаль, такі компанії, як Google, алгоритми, що використовуються у високотехнологічних продуктах, у вільний доступ не відкривають. Тож є мож- ливість тільки використовувати вже навчену модель нейронної мережі як чор- ний ящик, не знаючи її внутрішню архітектуру. Сервіс може повертати результати у вигляді тексту миттєво, як тільки слово було розпізнано з аудіопотоку або з голосової команди людини. Також Cloud Speech-to-Text може повертати розпізнаний текст з аудіофайлу та одразу зберігати його у текстовий фал. Це корисно для розпізнавання довготривалих аудіозаписів. Cloud Speech-to-Text має кілька різних підготовлених моделей нейрон- них мереж, щоб розробник міг вибрати необхідну та оптимізувати її під свої потреби. Наприклад, модель розроблена для відео-транскрипції, дуже добре справляється з індексуванням або створенням субтитрів для відео-контенту та використовує технологію машинного навчання, схожа на ту, що використо- вується в YouTube [4]. Сервіс може бути використаний трьома способами, що представлені нижче: – синхронне розпізнавання. Воно використовує REST та gRPC, та надси- лає дані з аудіо до серверів Google. Результат повертається тільки тоді, коли весь запис буде оброблений. Синхронне розпізнавання має обмеження та оброблює тільки аудіо з тривалістю менше 1 хвилини. – асинхронне розпізнавання. Воно використовує REST та gRPC, та ініціює так звану Long Running Operation. Під час виконання цієї операції

Лист ІА61.010БАК.002.ПЗ 12 Зм. Лист № докум. Підпис Дата

можна перевіряти стан розпізнавання та отримувати частково вже розпізнані дані. Асинхронне розпізнавання може бути здійснене над аудіофайлами три- валістю до 180 хвилин. – потокове розпізнавання. Воно використовує тільки gRPC та здійснює розпізнавання аудіо за допомогою дуплексного потоку gRPC. Потокове розпізнавання створене для розпізнавання у реальному часі. Наприклад, для аудіо з мікрофону при голосову керуванні. В цьому випадку розпізнаний текст доступний одразу, і може бути виведений на екран, поки користувач ще гово- рить. Загалом можна виділити такі переваги Google Cloud Speech-To-Text API: – підтримка 120 різних мов та діалектів; – можливість індивідуального налаштування – можна додавати власні слова у словник; – розпізнавання у реальному часі; – можливість чітко розпізнати мову навіть у зашумленому аудіо; – фільтрація небажаних слів або їх маскування при відображенні; – автоматична розстановка пунктуації; – можливість вибрати одну з моделей нейронних мереж: стандартну, для голосових команд та пошуку, для телефонних дзвінків, для ство- рення субтитрів для відео; – підтримка різних форматів кодування: FLAC, AMR, PCMU та Linear- 16.

1.2.2 Nuance speech recognition

Як було вже сказано, американська компанія Nuance займається розпізнаванням людської мови. Особливу увагу в своїх дослідженнях вона приділяє сфері охорони здоров’я [5]. В час, коли голосові асистенти розширю- ють своє застосування для більш природньої взаємодії людей з мобільними та побутовими пристроями пристроями, Nuance має витримувати конкуренцію. Лист ІА61.010БАК.002.ПЗ 13 Зм. Лист № докум. Підпис Дата

Тож компанія продовжує активно вкладати кошти у розвиток штучного інтелекту, нейронних мереж та машинного навчання щоб зробити людську мову простішою для розуміння машинами. У компанії доступні сервіси, направлені на різні ринки та галузі. Нижче наведений перелік деяких з них: – Nuance для побутових пристроїв впроваджує NLU (Nature Language Understanding) та предиктивні рішення в пристроях від світових брендів, що виробляють мобільні гаджети, автомобілі, телевізори та обладнання для інте- рнету речей; – Nuance для підприємств, завдяки десяткам років досвіду в галузі роз- пізнавання мови та штучного інтелекту, допомагає компаніям тісно спілкува- тися з клієнтами шляхом персоналізації та автоматизації обслуговування. Очікування клієнтів в останній час змінилися – вони хочуть отримувати ін- формацію майже одразу. При цьому вони будуть використовувати тільки ті шляхи спілкування, які забезпечують миттєві відповіді. Саме таким каналом для спілкування і є чатботи в контактних центрах. Наразі проекти для клієнтської підтримки на базі Nuance оброблюють 14 мільярдів користуваць- ких звернень щорічно; – Nuance для охорони здоров’я є лідером у голосовому розпізнаванню мови, специфічної для сфери охорони здоров'я. Цей сервіс полегшує процеси всередині медичних закладів: від фіксування проблем пацієнта до ведення клінічної документації. Більше десяти тисяч закладів по всьому світу викори- стовують цей сервіс. Загалом, технології від компанії Nuance, що стосуються NLU, глибоко інтегровані в продукти, сервіси та додатки від світових брендів та закладів охорони здоров’я. Нижче наведені приклади успішного співробітництва: – BMW. Довгострокове співробітництво для забезпечення природнього спілкування голосом з бортовим комп'ютером в автомобілях; – Samsung. Широкомасштабне співробітництво для впровадження новітніх технологій у широкий спектр електроніки від Samsung;

Лист ІА61.010БАК.002.ПЗ 14 Зм. Лист № докум. Підпис Дата

– Aldebaran. Технології компанії Nuance дали можливість роботам Nao та Pepper можливість слухати, розуміти та відповідати на мові людей; – Manulife. Міжнародна фінансова організація, що використовує IVR (interactive voice response) для забезпечення кращого обслуговування клієнтів. – Міністерство юстиції Германії використовує розпізнавання голосу для створення текстових документів з диктовки працівників міністерства.

1.2.3 IBM Watson Speech to Text

IBM Watson Speech to Text надає API для створення тексту з голосу в своїх додатках [6]. Він безперервно повертає оновлення по розпізнаному тек- сту впродовж прослуховування аудіо. Сервіс надає різні інтерфейси, що доз- воляє підлаштовуватися під будь-який додаток, де на вході є аудіо, а на виході потрібен текст. Наприклад, це можуть бути такі додатки: – додатки з голосовим керуванням, вбудовані пристрої та автомобільні системи. – перетворення в текст (транскрипція) дзвінків, конференцій тощо. – написання електронних листів та нотатків за допомогою голосу. IBM Watson Speech to Text надає можливість користуватися такими ін- терфейсами. – WebSocket – для постійного повнодуплексного зв’язку с сервісом. – HTTP REST запити – для безсесійних (sessionless) та сесійних (session- based) запитів до сервісу. – Асинхронні HTTP запити – для забезпечення неблокуючих запитів до сервісу. Сервіс надає можливість працювати з багатьма форматами: Ogg або Web Media (WebM), кодеки Opus та Vorbis, MP3 (або MPEG), Waveform Audio File Format (WAV), Free Lossless Audio Codec (FLAC), Linear 16-bit Pulse-Code Modulation (PCM).

Лист ІА61.010БАК.002.ПЗ 15 Зм. Лист № докум. Підпис Дата

Для більшості мов можна реалізувати транскрипцію аудіо, використову- ючи дві моделі на вибір: – широкополосну модель для аудіо з частотою 16кГц; – вузькополосну модель з частотою аудіо 8 кГц; Максимальний об’єм аудіо, що може обробити сервіс складає 100 мега- байтів. Аудіо можна відправити як потоком так і одним файлом водночас. У випадку роботи з потоком, сервіс застосовує часове обмеження для контролю за ресурсами. Нижче наведено основні функції IBM Watson Speech to Text: – мітки спікерів. Сервіс розпізнає різних спікерів по аудіо. Тобто у роз- мові багатьох людей, кожен учасник в тексті буде помічений своєю міткою; – знаходження ключових слів або фраз з певним рівнем співпадіння, який задає розробник; – можливість запитувати проміжні результати та альтернативні ре- алізації. У відповідь буде отримана альтернатива розібраного тексту та при- близна оцінка ідентичності тексту з оригінальним; – альтернативні слова. Можна запросити вставити в транскрипцію інші слова або словосполучення, що були б схожі за звучанням до оригінального слова; – відображається рівень точності для кожного розпізнаного слова; – відображається часова мітка початку та кінця розпізнавання кожного слова; – розумне форматування. Дозволяє конвертувати дату, час, числа, ва- люти, телефонні номери, інтернет адреси в більш читабельну та зрозумілу форму у транскрипції. Доступно тільки для англійської та іспанської мов; – розстановка знаків пунктуації в транскрипції.

Лист ІА61.010БАК.002.ПЗ 16 Зм. Лист № докум. Підпис Дата

1.3 Автоматичні телефонні станції

PBX (Private Branch Exhange) – англійський термін, що означає офісну телефонну станцію, що забезпечує встановлення, підтримання і розрив сполу- чення між апаратами, тобто комутацію. PBX надає можливість розділяти об- межені ресурси (міські лінії і номера) між обмеженим числом внутрішніх ко- ристувачів за допомогою таких функцій, як внутрішній номерний план, транс- фер дзвінків та постановка на утримання [7]. Традиційні системи такого плану комутують канали (лінії зв’язку), пе- ремикаючи ланцюги електричного струму. Нові системи PBX комутують па- кети в мережі TCP/IP і називаються IP PBX. Вони працюють на основі IP про- токолів телефонії. Гібридні IP PBX можуть підтримувати традиційні лінії зв’язку. IP-PBX (Internet Protocol Private Branch Exchange) – це автоматична те- лефонна станція на основі міжмережевого протоколу IP. Як і звичайна теле- фонна станція, IP-PBX виконує ті ж функції центрального вузла телефонного зв’язку в населеному пункті, регіоні, або внутрішній телефонній мережі ор- ганізації. Окрім можливості встановлювати з’єднання в автоматичному ре- жимі, IP-PBX можуть надавати інші розширені функції, оскільки майже всі можливості реалізовані програмно та можуть бути доповнені та налаштовані під потреби конкретної системи. В наш час тільки два протоколи IP телефонії отримали широке розповсюдження – H.323 та SIP. Стек протоколів H.323 був розроблений міжнародним союзом зв’язку (International Telecommunication Union). Протокол створювався для прове- дення аудіоконфверенцій та відеоконференцій з використанням сучасних те- лекомунікаційних мереж. SIP ( Session Initiation Protocol) – протокол встановлення сеансу, стан- дарт для способу встановлення і завершення користувацького інтернет-сеансу,

Лист ІА61.010БАК.002.ПЗ 17 Зм. Лист № докум. Підпис Дата

що включає в себе обмін мультимедійними даними (аудіо- та відеоконферен- ції, миттєві повідомлення, онлайн ігри тощо). Розробкою займалась Спеціальна Комісія Інтернет розробок (Internet Engineering Task Force) – відкрита міжнародна спільнота проектувальників, вчених, мережевих опера- торів та провайдерів, що займаються розвинення протоколів і архітектури Ін- тернету. Протокол H.323 має широкий стандартний набір засобів для роботи з відеоконференціям. Його створювали спеціалісти в галузі телефонії, а Інтер- нет – лише одне з його робочих середовищ. В свою чергу протокол SIP більше пристосований до роботи в мережах TCP/IP і більш універсальний, тому що його розроблювали спеціалісти з Інтернету, де аудіо і відео – лише два з ба- гатьох видів медіа контенту. З рештою Інтернет, через свою розповсюдженість, має перевагу, і в наш час стандартом де-факто для IP телефонії вважається SIP.

1.3.1 Архітектура SIP

Специфікація SIP протоколу визначає клієнт-серверну архітектуру. Клієнт створює запити з вказанням того, що хоче отримати від серверу. Сервер приймає і оброблює запити, створює відповіді, що містять сповіщення об успішності виконаного запиту, сповіщення про по милку або інформацію, що запросив клієнт. Обслуговування виклику розподілене між різними елемен- тами мережі SIP. Основним функціональним елементом, що реалізує функції керування з’єднанням є абонентський термінал. Інші елементи мережі відповідають за маршрутизацію викликів, а також надають додаткові послуги. Нижче розгля- нуто основні елементи мережі SIP: – термінал. Коли клієнт і сервер реалізовані як кінцеве обладнання і взаємодіють безпосередньо з клієнтом, вони називаються користувацьким агентським клієнтом – User Agent Client (UAC) та користувацьким агентським сервером – User Agent Server (UAS) відповідно. Якщо в пристрої присутні і Лист ІА61.010БАК.002.ПЗ 18 Зм. Лист № докум. Підпис Дата

UAC, і UAS, то він називається користувацьким агентом – User Agent (UA), а по своїй суті являє собою термінальне обладнання SIP. Прикладом можуть слугувати апаратний або програмний SIP телефон та SIP адаптер. – проксі-сервер. Він приймає запити, оброблює їх і виконує відповідні дії. Проксі-сервер також складається з клієнтської та серверної частин, тому може приймати виклики, ініціювати запити і повертати відповіді. Передбачено два типи проксі-серверів: із збереженням стану (stateful) та без збереження стану (stateless). Перший тип серверів зберігає в пам’яті всі отримані запити і зв'язані з ними нові сформовані запити до закінчення транзакції. Сервери дру- гого типу просто оброблюють запити. Тож на їх базі неможливо реалізувати складні інтелектуальні рішення; – сервер переадресації. Використовується для визначення поточного місцезнаходження користувач. Сервер переадресації не термінує виклики і не ініціює власні запити, а тільки повідомляє адрес необхідного терміналу або проксі-сервера. Для цих цілей він взаємодіє з сервером визначення місце- знаходження. Для здійснення з’єднання користувач може не використовувати сервер переадресації, якщо він сам знає поточну адресу потрібного користу- вача; – сервер визначення місцезнаходження користувачів. Оскільки користу- вач може переміщуватися в межах мережі SIP, існує механізм його визначення в даний момент часу. Сервер визначення місцеположення користувача слугує для зберігання поточної адреси користувача і являє собою базу даних адресної інформації. Таким чином, специфікація протоколу SIP не визначає нічого, окрім встановлення та розриву сесії між клієнтом і сервером, а також пошуком еле- ментів мережі. Тому SIP протокол використовується одночасно з іншими про- токолами, що реалізують користувацькі сервіси. Один з таких допоміжних протоколів – SDP (Session Description Proto- col), призначений для опису сесії передачі потокових даних, що включає в себе телефонію, інтернет-радіо, мультимедіа та потокові застосунки. SDP протокол

Лист ІА61.010БАК.002.ПЗ 19 Зм. Лист № докум. Підпис Дата

описує формат заголовків і полів, в яких SIP клієнти і сервери вказують свої сесійні можливості (наприклад, підтримувані алгоритми стискання – кодеки). Іншим необхідним протоколом є RTP (Real-time Transport Protocol), що використовується для безпосередньої передачі трафіка реального часу. Прото- кол RTP містить в своєму заголовку дані, необхідні для відновлення голосу або відеозображення в прийомному вузлі, а також дані про тип кодування ін- формації (JPEG, MPEG тощо) [8]. В заголовку даного протоколу передаються часова затримка та номер пакету. Ці параметри дозволяють при мінімальних затримках визначити порядок і момент декодування кожного пакету, а також інтерполювати втрачені пакети. В якості протоколу транспортного рівня за- звичай використовується протокол UDP. Встановлення та розрив зв’язку не входить в список можливостей RTP. Такі дії виконуються сигнальним прото- колом SIP. Таким чином, робота автоматичних телефонних станцій засновується на трьох протоколах: SIP, SDP, RTP. Звісно, є інші протоколи, що реалізують до- даткову функціональність, наприклад SIP TLS та Secure RTP. Вони додають шифрування сигналізації і медіапотоків. Але основними все ж таки вважа- ються SIP, SDP та RTP. Далі буде розглянуто найбільш популярні безплатні IP-PBX системи з відкритим кодом на сьогоднішній день.

1.3.2 Asterisk

Проект Asterisk був створений в 1999 році Марком Спенсером. В той час офісні PBX коштували досить дорого, тож він вирішив написати свою PBX на базі Linux. Згодом, заснувавши компанію Digium, став випускати плати спря- ження Asterisk зі стандартними телефонними мережами. Навколо Asterisk утворилася велика спільнота користувачів та розробників, проект став активно розвиватись. В наш час Asterisk є найпопулярнішою відритою IP-PBX у світі, займаючи майже 85% ринку автоматизованих телефонних станцій з відкритим кодом. Лист ІА61.010БАК.002.ПЗ 20 Зм. Лист № докум. Підпис Дата

Модульна архітектура Asterisk дозволяє легко підключати в комутаційне поле будь-яку бізнес-логіку, написану на різних мовах програмування, або ре- алізовану на власній мові діалплану Asterisk. Потрібно розглянути нижче ско- рочений список функціональних можливостей Asterisk: – підтримуються як протоколи IP телефонії, так і традиційні лінії зв’язку. В сервер з Asterisk можна вставити PCI плати Digium з аналоговими або цифровими портами в потрібній кількості і поєднанні; – напряму підтримується Skype через драйвер каналу chan_skype від Digium. Також є простий веб-додаток, що дозволяє дзвонити іншим користу- вачам Skype з кнопкових телефонів через короткі номери з записної книги; – підтримується відеозв’язок; – iснують додатки по розпізнаванню та синтезу людської. – підтримується шифрування розмови. – Asterisk має прості та добре документовані інтерфейси інтеграції з ін- шими сервісами (AGI та AMI), що дозволяє легко інтегрувати комунікації в бізнес-процеси і бізнес-застосунки. – iснує велика кількість графічних засобів адміністрування Asterisk, се- ред яких найбільш популярний WEB інтерфейс FreePBX [9]. Також є готові дистрибутиви, що дозволяють розгорнути на звичайному персональному комп’ютері сервер IP-PBX за лічені хвилини. Найбільш популярними дистри- бутивами є TrixBox та Elastix. – навколо Asterisk зібрана велика спільнота користувачів, розробників, інтеграторів, які допомагають один одному пізнавати і використовувати всю багатогранність можливостей Asterisk. В наш час Asterisk розвивається ще швидше. Тільки за 2010 рік кількість користувачів збільшилася вдвічі. Нажаль, така велика кількість можливостей Asterisk і активний розвиток створюють мінус цього продукту – новачкам складно швидко опанувати велику кількість інформації. А нові версії можуть бути нестабільними через величезну кількість оновлень і змін з попереднього випуску.

Лист ІА61.010БАК.002.ПЗ 21 Зм. Лист № докум. Підпис Дата

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

1.3.3 FreeSWITCH

FreeSWITCH – це програмний комутатор, створення якого біло ініційо- вано одним з колишніх розробників Asterisk в 2006 році [10]. Після багатора- зових спроб використання Asterisk під високим навантаженням, він висказав ряд зауважень до базової архітектури системи і запропонував її змінити. Однак автор Asterisk – Марк Спенсер – відмовився міняти ядро системи. Тому цей розробник вийшов зі складу команди Asterisk і створив свій власний продукт. При розробці архітектури FreeSWITCH авторами були взяти до уваги всі недоліки існуючих відкритих програмних продуктів для IP телефонії. Тому од- нією з переваг нового продукту стали стабільність роботи і масштабованість, а також кросплатформеність – FreeSWITCH працює під керуванням як Linux, так і Windows. Особливістю FreeSWITCH є використання SIP стека sofia-sip від Nokia, що вважається найкращою відкритою реалізацією SIP протоколу. Слід ска- зати, що в Asterisk цей стек реалізовано з неповним дотриманням стандартів. SIP є основним протоколом роботи FreeSWITCH, хоча також підтримуються драйвери PCI плат для інтеграції з традиційною телефонією, а також інші про- токоли IP телефонії. Сервіс може використовуватися як SIP проксі та SIP регістратор. Підтри- мує багато функцій IP-PBX, наприклад трансфер дзвінка, перехват, запис роз- мов, прослуховування та інші. Однак, на сьогоднішній день, список додатків IP-PBX, доступний для FreeSWITCH програє аналогічному для Asterisk. Для нього відсутні графічні інтерфейси для керування, що може ускладнити вико- ристання продукту. А основою конфігурування є текстові файли в форматі XML, на відміну від файлів конфігурації в Asterisk. Лист ІА61.010БАК.002.ПЗ 22 Зм. Лист № докум. Підпис Дата

Тим не менш, FreeSWITCH активно розвивається. Деякі експерти відкритих програмних продуктів телекомунікацій називають цей сервіс наступником Asterisk. Інші ж вважають, що для обох продуктів є місце на ринку, тому що в кожного є своя унікальна специфіка.

1.3.4 SipXecs

SipXecs був створений як один з перших продуктів, за допомогою яких успішно взаємодіяли SIP пристрої від різних виробників. Саме тому, наразі, SipXecs вважається найбільш повною та правильною реалізацією SIP стеку. Програмне забезпечення написано на мовах програмування C++ та Java і працює на операційній системі Linux. Це єдина IP-PBX система, в ядро якої був включений одразу WEB інтерфейс керування. Якщо Asterisk пози- ціонується як голосова платформа, то розробники SipXecs вважають свій про- дукт уніфікованим рішенням комунікацій, що працює «з коробки», тобто не потребує додаткового налаштування. SipXecs підтримує тільки SIP та являє собою чисте рішення для SIP. Весь телефонний функціонал реалізовано в рамках специфікації протоколу SIP, а також розділено на повністю незалежні компоненти, що взаємодіють між со- бою по протоколам SIP, HTTP, XML-RPC, і можуть працювати як на одному, так і на кількох серверах. Це забезпечує високий рівень надійності і масшта- бованості системи. Якщо Asterisk являє собою систему що підтримує багато протоколів і приймає дзвінки з різних каналів, через що мусить перетворити їх у свій внутрішній формат в цілях обробки та комутації, то SipXecs – це SIP проксі, що займається маршрутизацією SIP транзакцій, не пропускаючи через себе медіа-потоки. Він напряму передає їх між агентськими пристроями (IP теле- фонами). Однак, з сильних боків SipXecs випливають і всі його слабкості. Через те, що не проксуються медіа-потоки, неможливо реалізувати деякі важливі функції PBX, наприклад, запис розмов. Також, виникає проблема в тому Лист ІА61.010БАК.002.ПЗ 23 Зм. Лист № докум. Підпис Дата

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

1.4 Безсерверна архітектура

Використання безсерверної архітектури дає змогу не піклуватися про налаштовування і адміністрування серверів, на яких запущені програми що ке- рують системою. Вся інфраструктура розміщується в хмарі та підтримується сторонніми провайдерами, а необхідна функціональність надається у формі сервісів, що відповідають за процеси автентифікації, передачі повідомлень тощо. Безсерверні додатки широко застосовують сторонні сервіси, що викону- ють задачі, притаманні серверам в традиційній архітектурі. Ці сервіси можуть представляти собою цілісну екосистему (як наприклад Azure та AWS) або бути самостійними рішеннями (наприклад Parse або Firebase). Однією з головних задач серверних веб-додатків є контроль циклу за- питів і відповідей. Контролери на стороні сервера обробляють вхідні запити, запускають необхідні додатки та будують відповіді. У випадку з безсерверною архітектурою, контролери на стороні сервера замінюються процесами гене- рації динамічного контенту. Ще однією значимістю серверною архітектуру є бізнес-логіка – коли на сервері розміщується код, що виконує обробку запитів протягом всього часу роботи додатку. У безсерверних додатках спеціальні програмні компоненти активуються тільки тоді, коли поступає запит. Після обробки запиту компонент переходить в стан очікування. Цей код часто розміщується в керованій середі, яка контро- лює масштабованість коду і життєвий цикл. Передача керування частиною системи третій стороні створює свої недоліки. Наприклад, це може привести до втрати контролю – непередбачу- ване оновлення API. Таке розбиття одного застосунка на кілька частин з різно- манітними сервісами призводить до збільшення вузлів, на які потрібно звер- тати увагу при тестуванні. Лист ІА61.010БАК.002.ПЗ 24 Зм. Лист № докум. Підпис Дата

З іншого боку є економія від масштабу. Наприклад, дешевше виходить використання бази даних, тому що сервіс, що її надає, обслуговує ще велику кількість таких самих однотипних баз даних. Більше всього виграють з цього компанії з не стабільним трафіком: сервери не будуть працювати задарма при відсутності трафіку. Вони активуються тільки тоді, коли з’являється актив- ність. Безсерверні системи легко підтримувати. Сторонні компанії, що нада- ють послуги, прикладають багато зусиль для забезпечення їх доступності та масштабованості. Більше того, будь-яка оптимізація продуктивності такого додатку одразу зменшує операційні витрати. Наприклад, виконання якої-не- будь дії, що займала 1 секунду, після покращення стане виконуватися за 200мс. В наведеному прикладі, така оптимізація призвела до зменшення вар- тості послуги на 80 % без змін в інфраструктурі.

1.4.1 Azure Functions

Azure Functions – це рішення для простого запуску невеличких шматків коду в хмарі [11]. Необхідно написати тільки код для вирішення якоїсь про- блеми, не турбуючись про оточення або інфраструктуру додатку. Можна пи- сати функції на різних мовах: C#, F#, Node.js, Java або PHP. Запускати функції можна маючи підписки виду Consumption plan або Azure Services plan. Для Consumption plan обчислювальні потужності форму- ються тільки коли виконується код. Вони масштабуються для підтримання пропускної здібності під час підвищеного навантаження та згортаються, коли код не виконується. Для App Service plan функції виконуються на виділеній віртуальній машині, але вони не постійно доступні. При відсутності подій, функція переходить в стан очікування, тож її необхідно активувати через HTTP запит [12]. Контролер масштабування автоматично збільшує ресурси ЦП та пам'яті додаванням нових екземплярів функції. Кожен екземпляр максимально може використовувати 1.5 Гб пам’яті. Всі функції зберігаються на Azure Files. Лист ІА61.010БАК.002.ПЗ 25 Зм. Лист № докум. Підпис Дата

Для коректного функціонування обох планів необхідно мати підтримку Azure Blob, Queue, Files, та Table storage. Функції використовують Azure Storage для керування тригерами та збереження логів виконання функції. Azure Functions використовують так званий контролер масштабування (scale controller) для відслідковування кількості подій та визначення доціль- ності масштабування в поточний момент часу. Контролер масштабування ви- користовує евристику для кожного типу тригерів подій. Наприклад, якщо ви- користовувати Azure Queues як тригер, масштабування буде залежати від дов- жини черги та часу створення найстарішого повідомлення у черзі. Одиницею масштабування є екземпляр функції. Коли функція вичерпує свої ресурси, запускаються нові екземпляри тієї ж функції. Тому функції не повинні мати якогось стану. Одразу, як навантаження спадає, контролер зни- щує екземпляри функцій та вивільнює пам’ять. На рисунку 1.1 зображена схема роботи контролера масштабування.

Рисунок 1.1 – Схема роботи контролеру масштабування [13]

Лист ІА61.010БАК.002.ПЗ 26 Зм. Лист № докум. Підпис Дата

Масштабування залежить від кількох факторів, і виконується по різному в залежності від типу тригера подій та обраної мови програмування. Але можна виділити кілька аспектів масштабування системи: – додаток з однією функцією може використовувати максимум 200 екземплярів для масштабування. Один екземпляр може оброблювати більше ніж одну подію або запит одночасно. – новий екземпляр створюється лише раз на кожні 10 секунд.

1.4.2 Google Cloud Functions

Google Cloud Functions – це сервіс безсерверних обчислень від Google [13]. В ньому функції виконуються тоді, коли з’являється визначена подія. Ви- конання відбувається в повністю керованому середовищі, що не потребує від розробників забезпечення інфраструктурою та виділенням серверів. Функції можуть бути написані тільки на мові програмування Javascript та виконуватися в середовищі Node.js v6.14.0 на Google Cloud Platform. Cloud Functions надають логічний прошарок, що дозволяє розробникам писати код та доповнювати його можливості іншими хмарними сервісами. Цей сервіс повинен мати доступ до облікового запису Google Service і використо- вує такі інші сервіси Google Cloud Platform, як Datastore, Cloud Spanner, Cloud Translation API, Cloud Vision API. Події, що відбуваються в хмарі, можуть слугувати тригерами функцій. Наприклад, це можуть бути зміни в базі даних, додавання нового файлу в схо- вище або створення нової віртуальної машини. Функції можна налаштовувати так, щоб вони реагували на будь-яку подію в середині хмарних сервісів Google Cloud Platform. Використання цього сервісу може бути корисним для таких цілей: – обробка даних. Функція буде реагувати на зміни в Google Cloud Stor- age, оброблювати відео, проводити валідацію та трансформацію даних, викли- кати інші сервіси в Інтернеті. – API. Може слугувати як API для легких, ненавантажених додатків. Лист ІА61.010БАК.002.ПЗ 27 Зм. Лист № докум. Підпис Дата

– інтернет речей. Десятки тисяч пристроїв можуть посилати свої дані та активувати виконання безсерверних функцій, що будуть масштабуватися шля- хом створення нових копій та їх викликів.

1.5 Висновки

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

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

Лист ІА61.010БАК.002.ПЗ 28 Зм. Лист № докум. Підпис Дата

2 ОБГРУНТУВАННЯ ОБРАНИХ ТЕХНОЛОГІЙ

В останні роки, з метою позбавлення малих та середніх компаній від вит- рат на інфраструктуру для виконання конкретних задач, з’явився термін XaaS [14]. Xaas – це акронім від (X as a Service) та означає щось, що доступно ко- ристувачу як сервіс, наприклад: – BaaS (Backend as a Service) – знімає з користувача потребу мати влас- ний веб-сервер на якому розміщена логіка веб-додатку; – DBaaS (Database as a Service) – дозволяє використовувати хмарний сер- вер для розгортання на ньому власної бази даних. – SaaS (Software as а Service) – дозволяє користуватися програмним за- безпеченням через Інтернет, при цьому користувач платить не за володіння програмою, а за її використання (наприклад за користування API - Application Programming Interface). – IaaS (Infrastructure as a Service) – дозволяє використовувати віртуальні сервери з заданою обчислювальної потужністю, операційною системою та до- ступом до мережі. – LaaS (Logging as a Іervice) – забезпечує користувача централізованим збором, нормалізацією та колекціонуванням логів з будь-якого сервера, дода- тку. Ці дані зазвичай подаються на залежні системи, що вже оброблюють ін- формацію так, як треба користувачеві. Найбільшим постачальником таких послуг у світі є компанія Amazon зі своєю платформою Amazon Web Services (AWS). Це платформа для розроб- ників, що надає найширший перелік послуг для побудови хмарних рішень. Ве- личезна перевага використання хмарних сервісів є в тому, що компанії, які бу- дуть впроваджувати продукт, реалізований за допомогою подібних рішень, можуть не перейматися за створення і підтримку інфраструктури для забезпе- чення працездатності цього продукту. Все, що необхідно – це робочі станції з доступом до Інтернету та персонал, що буде взаємодіяти з продуктом.

Лист ІА61.010БАК.002.ПЗ 29 Зм. Лист № докум. Підпис Дата

Система, що проектується, має бути максимально гнучка. Тож для цього було вирішено використовувати сервіси саме з платформи Amazon Web Ser- vices. Тому що AWS надає можливість зробити вибір з десятків сервісів, що стосуються таких галузей інформаційних технологій:  хмарне обчислення.  хмарне сховище.  хмарна база даних.  сервіси моніторингу.  аналітичні сервіси.  інтернет речей.  машинне навчання. Саме за наявності такої великої кількості сервісів та можливості їх інте- грації між собою, багато великих компаній використовують екосистему AWS для побудови своїх корпоративних проектів. На рисунку 2.1 показано приклад архітектури системи контактного центру з чатботом.

Рисунок 2.1 — Приклад використання зазначених сервісів для побу- дови контактного центру з чат-ботом [15]

Лист ІА61.010БАК.002.ПЗ 30 Зм. Лист № докум. Підпис Дата

2.1 Amazon Lex

Для розпізнавання людської мови AWS надає можливість роботи з Amazon Lex. Amazon Lex – це сервіс для побудови діалогових інтерфейсів для будь- якого додатку, використовуючи голос або текст [15]. Amazon Lex надає роз- ширені функціональні можливості глибинного навчання, такі як автоматичне розпізнавання мови (ASR), призначене для перетворення голосового повідом- лення у текст, і розуміння природніх мов (NLU), призначене для визначення сенсу тексту та розуміння його семантики. Це дозволяє створювати застосунки зі зручним для користувача інтерфейсом та з можливістю природньої діало- гової взаємодії. Використання Amazon Lex відкриває всім розробникам про- грамного забезпечення можливості технологій глибинного навчання, на базі якого працює Amazon Alexa, що дозволяє з легкістю створювати складних ботів для взаємодії на природній мові. Розпізнавання мови та розуміння природної мови входять до числа найбільш складних задач інформатики. Для їх вирішення потребуються алго- ритми глибинного навчання з тренуванням на великих об’ємах даних. Для нав- чання моделі нейронної мережі потрібна відповідна інфраструктура з потуж- ними машинами. Amazon Lex максимально спрощує цей процес, надаючи ро- зробникам всю потужність Amazon Alexa. За допомогою цих технологій Ama- zon Lex дозволяє формувати абсолютно нові категорії продуктів, поява яких без діалогових інтерфейсів була б просто неможлива. Слід зазначити, що Amazon Alexa це віртуальний помічник від компанії Amazon, що використовується в розумних колонках для дому – Amazon Echo. Це невеличкий пристрій, що виступає в ролі інтелектуального помічника та керує всіма іншими пристроями інтернету речей в домі. Він розуміє людей, спілкується з ними. Можна сказати, що це головний мозок розумного дому.

Лист ІА61.010БАК.002.ПЗ 31 Зм. Лист № докум. Підпис Дата

Amazon Alexa на ринку вже кілька років, тож через цей сервіс пройшла вели- чезна кількість реальних даних. Це надзвичайна перевага – мати можливість використовувати таку навчену модель нейронної мережі у своїх проектах. До переваг Amazon Lex можна віднести: – простоту використання. Lex надає просту і зрозумілу веб-консоль, яка направляє розробника та дозволяє зручно створити свого власного бота і вбу- довувати в додатки діалогові інтерфейси. Оскільки модель нейронної мережі вже навчена, потрібно вказати приклади фраз та їх інтерпретацію для ство- рення повної моделі природньої мови, яка дозволить користувачам додатка взаємодіяти, використовуючи голос та текстові повідомлення: задавати пи- тання, отримувати відповіді і виконувати складні завдання. – ефективне розгортання та масштабування. Lex дозволяє створювати, тестувати та розгортати чатботів прямо з веб-консолі. Є можливість публіку- вати голосові або текстові чатботи для мобільних пристроїв, web-застосунків і сервісів обміну текстовими повідомленнями, такими як Facebook Messenger, Slack і Twilio SMS. Після публікації бот починає оброблювати інформацію, що поступає під час діалогу з кінцевим користувачем. Це повністю масштабова- ний сервіс, завдяки чому при збільшенні кількості користувачів не потрібно буде турбуватися про виділення додаткового обладнання або змінювати ін- фраструктуру для підтримки роботи бота. Це вкрай важливо для роботи з клієнтами в контактному центрі, бо саме через бота будуть йти всі дзвінки.

2.2 Amazon Connect

Amazon Connect –це сервіс хмарного контактного центру, який надає ба- зовий функціонал автоматичної телефонної станції (здійснення вхідних та вихідних дзвінків, маршрутизація, запис розмови) [16]. Саме на його основі буде працювати спроектована система. В основі Amazon Connect лежить тех- нологія роботи контактного центру, яку активно використовують підрозділи Amazon по роботі з клієнтами по всьому світу, оброблюючи

Лист ІА61.010БАК.002.ПЗ 32 Зм. Лист № докум. Підпис Дата

мільйони звернень щорічно вже протягом багатьох років. Amazon Connect надає графічний інтерфейс прямо з браузера. Адміністратор має можливість налаштувати профіль кожного оператора все- редині системи, обмежуючи доступ до чутливої комерційної інформації, та об’єднуючи у групи. Графічний інтерфейс спрощує самостійне обслуго- вування сервісу. Для того щоб створювати потоки оброки дзвінків, керувати операторами та відстежувати показники продуктивності не потрібні спеціальні навички та або досвід у технічній галузі. Сервіс не пропонує аван- сових платежів або довгострокових зобов’язань і не потребує обслуговування інфраструктури. Ключовим поняттям в Amazon Connect є потік дзвінка (contact flow). По суті, це є представлення дзвінка у вигляді набору блоків, кожен з яких визна- чає конкретну дію. Це може бути активація запису дзвінка, вибір голосу для чатбота, трансфер на іншу лінію, зачитування певного тексту тощо. На ри- сунку 2.2 показано приклад потоку дзвінка в Amazon Connect.

Рисунок 2.2 — Приклад простого потоку дзвінка

Для міжнародних компаній Amazon Connect є надзвичайно зручною ба- зою для побудови контактного центру, оскільки є можливість замовити но- мери різних країн, а оскільки операторам для роботи необхідно тільки мати доступ до Інтернету, то можна збирати команду операторів з різних куточків планети для більш звичного спілкування з клієнтами з різних країн.

Лист ІА61.010БАК.002.ПЗ 33 Зм. Лист № докум. Підпис Дата

Connect надає широкий список метрик та показників у реальному часі, що дозволяє оптимізувати маршрутизацію між операторами для найбільшої ефективності. Можна направляти більше трафіку на досвідчених операторів, а залишковий – для новачків. Як і для багатьох сервісів AWS, для Amazon Connect передбачена повна масштабованість. Для розгортання роботи контактного центра немає потреби в інфраструктурі та механізмі її керування. Моментально можна як скоротити, так і раптово збільшити кількість ресурсів аж до залучення десятків тисяч но- вих операторів. Вся інфраструктура Amazon Web Services має високу відмо- востійкість та надійність. Це забезпечують 42 зони доступності в 16 гео- графічних регіонах по всьому світу. Тому даний сервіс є найбільш надійним та стабільним серед інших варіантів контактних центрів на базі одного ЦОД (центру обчислювання даних). Amazon Connect – відкрита платформа, яка легко інтегрується з іншими системами, в тому числі з рішеннями по взаємодії з базою (CRM) або сервісами AWS. На рисунку 2.3 зображена взаємодія Amazon Connect , як відкрита платформа для взаємодії з іншими сервісами.

Рисунок 2.3 – Відкрита платформа Amazon Connect [17]

Нижче наведено список сервісів AWS, які можна інтегрувати з Amazon Connect та їх короткий опис: Лист ІА61.010БАК.002.ПЗ 34 Зм. Лист № докум. Підпис Дата

– AWS Directory Service – засіб взаємодії з Active Directory для корпора- тивних мереж. – Amazon S3 (Amazon Simple Storage Service) – це об’єктне сховище да- них з простим веб-інтерфейсом для завантаження і вивантаження необмеже- ного об’єму даних з будь-якої точки, під’єднаної до Інтернету. Використо- вується як первинне сховище даних для всіх записів дзвінків та звітів з метрик, що надходять від аккаунта Amazon. – Amazon Lambda – сервіс, що надає можливість писати та виконувати код швидко без створення та підтримування серверів. Потоки дзвінків (Contact flows) одразу інтегровані з AWS Lambda, тож розробник може створювати індивідуальний динамічну взаємодію з клієнтом. Розробникам відкривається можливість писати Lambda-функції, що звертаються до CRM або інших ре- сурсів з даними, що суттєво покращить якість IVR (interactive voice response). Lambda-функції можуть слугувати як механізм сповіщення для зовнішніх си- стем на певному етапі розмови. – Kinesis – платформа для трансляції CTR (contact trace records) та дій операторів. Дані передаються в форматі JSON та містять інформацію про дзвінки та дії агентів контактного центру. Розробники можуть опціонально оброблювати ці данні та надсилати до Amazon Redshift або до власних систем зберігання даних, що позволяють детально аналізувати дані та робити звіти з роботи колл-центру. Ці дані також можна направити до Amazon QuickSight (хмарний сервіс з бізнес-аналітики) або до власних сервісів з бізнес-аналітики для побудови візуального представлення синтезованої інформації. В решті ці дані можуть транслюватися до Elasticsearch, звідки вони бути доступні за до- помогою зручного інтерфейсу. – Amazon CloudWatch – сервіс логування, що надає оперативні метрики у реальному часі, наприклад, кількість дзвінків в секунду, прийняті або пропу- щені дзвінки та помилки. Є можливість налаштувати відстежування для цих метрик, щоб бути в курсі того, що відбувається в контактному центрі.

Лист ІА61.010БАК.002.ПЗ 35 Зм. Лист № докум. Підпис Дата

– AWS Identity and Access Management – сервіс для призначення прав і політик доступу до даних, використовується для створення вертикальної ієра- рхії доступу к ресурсам Amazon Web Services аккаунта, що використовуються системою.

2.3 Amazon Lambda

AWS Lambda – це сервіс безсерверних обчислень, що запускає програм- ний код у відповідь на визначені події і автоматично керує обчислювальними ресурсами, необхідними для його виконання. AWS Lambda можна використо- вувати для розширення можливостей інших сервісів AWS за допомогою спеціальної логіки або створення власних веб-сервісів, що використовують масштабованість, продуктивність та безпечність Amazon Web Services. На ри- сунку 2.4 зображена спрощена архітектура виклику Lambda функції. Функції Lambda можуть автоматично запускатись у відповідь на такі події, як HTTP запити, зміна об’єктів у корзині S3, оновлення таблиці у Amazon DynamoDB або зміна стану в AWS Step Functions.

Рисунок 2.4 — Спрощена архітектура виклику функції Lambda [18]

При створенні функції розробник задає необхідний об’єм пам’яті, і AWS Lambda автоматично виділить пропорційну кількість ресурсів ЦП, пропускної здатності мережі і операцій читання та запису.

Лист ІА61.010БАК.002.ПЗ 36 Зм. Лист № докум. Підпис Дата

Lambda запускає код у високопродуктивному обчислювальному середо- вищі і займається адміністративною підтримкою усіх ресурсів, включно з об- слуговуванням серверів та операційних систем, розподіленням обчислюваль- ної потужності та автоматичним масштабуванням, установкою ПО, виправ- ленням несправностей, а також моніторингом коду і веденням логів. Від ро- зробника потрібен тільки програмний код. Код, що запускається в AWS Lambda, називається функцією Lambda. Після того, як функція створена, вона перебуває у стані постійної готовності до запуску. Кожна функція містить створений розробником код і деякі конфігурації, включно з ім’ям функції і вимогам до ресурсів. Функції Lambda – це функції без зберігання стану, незалежні від інфраструктури. Тому Lambda може швидко завантажити стільки копій функції, скільки необхідно для мас- штабування згідно з кількістю вхідних подій. Після завантаження коду в AWS Lambda, можна зв’язати функцію з тими чи іншими ресурсами AWS, наприклад корзиною S3, таблицею Amazon DynamoDB, потоком Kinesis або сповіщенням Amazon SNS. При зміні стану ресурсу Lambda виконає функцію та налаштує обчислювальні ресурси для продовження обслуговування вхідних запитів. Для роботи за AWS Lambda не потрібно вивчати нові мови програ- мування, інструменти та інфраструктуру. Сервіс працює з будь-якими сторон- німи бібліотеками та навіть з деякими вбудованими. Розробники можуть пи- сати код на Java, Node.js, C#, Golang або Python [19]. Для кожної мови AWS надає дуже потужну SDK (Software Development Kit) з докладною документа- цією. У майбутньому планується підтримка і інших мов програмування. Завдяки ретельному управлінню інфраструктурою, програмний код ви- конується у високопродуктивному, відмовостійкому середовищі, що дозволяє зосередитися тільки на написанні різноманітних веб-сервісів. Немає потреби піклуватися про оновлення серверної операційної системи або розширенні існуючих та введені в експлуатацію нових серверів з ростом навантаження.

Лист ІА61.010БАК.002.ПЗ 37 Зм. Лист № докум. Підпис Дата

Дуже важливим є те, що Lambda володіє вбудованою відмовостійкістю, автоматично підтримуючи необхідний об’єм обчислювальних потужностей в різних зонах доступності в кожному з регіонів, захищаючи програмний код від несправностей окремих одиниць обладнання або збоїв в роботі центрів обробки даних. Функціонал веб-сервісу забезпечує передбачуваний та надій- ний режим експлуатації. Сервіс розроблений для забезпечення високої доступ- ності як самого веб-сервісу, так і для виконуваних їм функцій. Він працює без планових простоїв і перерв на обслуговування. AWS Lambda виконує код тільки тоді, коли це необхідно, і автоматично масштабує ресурси згідно з об’ємом запитів що поступають, без додаткових дій зі сторони розробника. Кількість одночасних запитів для обробки необме- жена. Lambda запускає програмний код протягом кількох мілісекунд після події, і оскільки масштабування проходить автоматично, продуктивність зали- шається стабільно високою при дуже високій частоті подій. Оскільки код не потребує збереження стану, можна створювати необхідну кількість інстансів без довгих процедур розгортання або затримок на налаштування. Для побудови складних та довготривалих задач є можливість коорди- нувати багато функцій , створюючи робочі процеси сервісом AWS Step Func- tions [20]. Він дозволяє визначати робочі процеси, які активують набор функцій за допомогою послідовних, паралельних, розгалужених кроків. Таким чином можна створювати структуровані довготривалі процеси для додатків та серверів. На рисунку 2.5 зображено простий приклад, як працює Amazon Lambda з іншими сервісами. Вся комунікація складається з 5 кроків, що наведені нижче: – користувач завантажує об’єкт до корзини Amazon S3. При цьому кор- зина налаштована на генерацію сповіщень для Lambda функцій. – сповіщення згенеровано. S3 його читає та визначає адресата (AWS Lambda).

Лист ІА61.010БАК.002.ПЗ 38 Зм. Лист № докум. Підпис Дата

– S3 відправляє сповіщення до адресата, таким чином активуючи функцію. – виконавча роль IAM, що була визначена для функції при її створенні, дає доступ до відповідних ресурсів AWS (для даного прикладу це читання з Amazon S3). – функція викликається, виконуючи певні дії над об’єктом, що був збе- режений користувачем на першому кроці.

Рисунок 2.5 – Приклад взаємодії Amazon Lambda з іншими сервісами [21]

Як вже було сказано, AWS Lambda дозволяє коду безпечно взаємодіяти з іншими веб-сервісами AWS через вбудоване AWS SDK і інтеграції з сервісом AWS Identity and Access Management (IAM). AWS Lambda запускає код в хмарі VPC (Amazon Virtual Private Cloud) за замовчуванням. Розробник може за- стосувати користувацькі групи безпеки і списки контролю доступу до мережі, для того щоб надати функціям Lambda доступ до ресурсів VPC.

Лист ІА61.010БАК.002.ПЗ 39 Зм. Лист № докум. Підпис Дата

2.4 Amazon Virtual Private Cloud

Amazon VPC – це логічно ізольований розділ хмари AWS, де можна за- пускати ресурси AWS в віртуальній мережі [22]. Розробник може повністю контролювати оточення віртуальної мережі, у тому числі вибирати діапазон IP-адрес, створювати підмережі, а також налаштовувати таблиці маршрутиза- ції і мережеві шлюзи. Для забезпечення зручного і безпечного доступу до ре- сурсів у VPC можна використовувати як IPv4, так і IPv6. Можливість об’єднувати свої ресурси у віртуальну мережу суттєво підвищує захищеність системи. Жоден з сервісів, що відповідають за логіку роботи системи контактного центру, не буде відкритий для Інтернету, а всі вони будуть находитися формально у локальній мережі, що суттєво знижує ризик атаки зовні системи. Мережеву конфігурацію можна гнучко налаштувати. Наприклад, для веб-серверів можна створити публічну підмережу з виходом в Інтернет, а внутрішні системи, такі як бази даних, файлові сервери, розмістити в приват- ній підмережі без доступу до Інтернету. Можна використовувати багаторів- неву систему безпеки, що складається з груп та мережевих списків контролю (NACL), щоб контролювати доступ до інстансів Amazon EC2 у кожній підме- режі. На рисунку 2.6 зображена можлива конфігурація доступу до ресурсів у VPC з двома підмережами, в кожній з яких запущено по 3 віртуальні машини. Як видно з рисунку, тільки одна з двох підмереж (subnet 1) має доступ до Інтернету. Інша підмережа (subnet 2) – схована у цілях безпеки. Але обидві підмережі можуть взаємодіяти між собою без перешкод в межах VPC.

Лист ІА61.010БАК.002.ПЗ 40 Зм. Лист № докум. Підпис Дата

Рисунок 2.6 – Доступ до ресурсів у Virtual Private Cloud [22].

2.5 Amazon S3

Amazon S3 (Simple Storage Service) – це об’єктне сховище, призначене для зберігання та вилучення даних будь-якого об’єму з будь-яких джерел: веб- сайтів та мобільних додатків, корпоративних додатків, а також даних з дат- чиків та пристроїв інтернету речей. Сервіс гарантує надійність зберігання на рівні 99,9 % і використовується для зберігання мільйонами застосунків, що використовують лідери ринку в усіх галузях [23]. S3 відкриває широкі можли- вості для забезпечення надійності і відповідності згідно найсуворіших норма- тивних вимог. S3 надає функціональні можливості для виконання запитів к да- ним без їх вилучення, що дозволяє використовувати потужні аналітичні ін- струменти для безпосередньої обробки даних, що зберігаються в S3. Лист ІА61.010БАК.002.ПЗ 41 Зм. Лист № докум. Підпис Дата

Сервіс Amazon S3 надає дані у вигляді об’єктів, що зберігаються в так званих «корзинах» (bucket). Кожна корзина вміщує необмежену кількість об’єктів. Над ними можна виконувати операції запису та читання, а також ви- даляти. При цьому розмір одного об’єкту може досягати 5 терабайтів. Для зберігання даних доступні чотири класи сховищ: – стандартне сховище. Воно забезпечує надійність, доступність і про- дуктивність сховища об’єктів для зберігання даних, що часто використову- ються. – стандартне сховище неприватного доступу. Це сховище для даних, до- ступ до яких потрібен відносно рідко, але за необхідності має бути достопуним швидко. Підходить для довгострокового збереження даних, резервного копіювання, а також на випадок аварійного відновлення. – сховище неприватного доступу в одній зоні доступності. На відміну від інших класів сховищ, що зберігають дані як мінімум у трьох зонах доступ- ності, ця зберігає дані тільки в одній зоні доступності. Тому воно дешевше на 20% за стандартне сховище неприватного доступу. Об’єкти можна автоматично переміщувати між сховищами різних класів на основі політик керування життєвим циклом.

2.5.1 Безпека і керування

Доступ до створюваних ресурсів Amazon S3 мають лише власники кор- зин і об’єктів. Сервіс підтримує різні механізми керування доступом, а також шифрування даних при зберіганні і передачі. Amazon S3 забезпечує захист да- них від логічних та фізичних збоїв, а також від втрати внаслідок ненавмисних дій користувача, помилок додатків і інфраструктурних збоїв. За необхідності дотримання нормативних стандартів, таких як PCI DSS, HIPAA/HITECH, FedRAMP, функції захисту даних, можуть застосовуватися в

рамках спільної стратегії забезпечення відповідності цим стандартам. Amazon S3 забезпечує чотири різних механізми керування доступом: Лист ІА61.010БАК.002.ПЗ 42 Зм. Лист № докум. Підпис Дата

– політики AWS Identity and Access Management (IAM). Дозволяє ор- ганізаціям з великим штатом співробітників створювати профілі і гнучко нада- вати права та керувати через один AWS акаунт; – списки контролю доступом (ACL). Використовуються для вибіркового надання дозволу по відношенню до окремих об’єктів; – політики на рівні корзин. Використовуються для надання або відмови у доступі до деяких або всіх елементів корзини; – автентифікація строки запиту. Якщо обрати шифрування даних у стані спокою з серверним механізмом шифрування (SSE), Amazon S3 автоматично зашифрує дані при записі та де- шифрує при зчитуванні. При шифруванні використовуються алгоритм Ad- vanced Encryption Standard (AES) з симетричними ключами довжиною 256 біт. Особливо треба звернути увагу на те, що для забезпечення додаткового захисту даних, Amazon S3 надає механізм керування версіями. Він дозволяє зберігати, вилучати і відновлювати будь-яку версію об'єкта, що знаходився в корзині. Ця функція дозволяє легко відновити систему внаслідок ненавмисних дій користувача та збоїв систем. За замовчуванням, за запитом надається остання записана версія. Більш старі версії об'єкту можна вилучити, вказавши у запиті номер версії потрібного об'єкта.

2.6 Amazon DynamoDB

Amazon DynamoDB – це швидкий і гнучкий сервіс нереляційних баз да- них, що забезпечує високу продуктивність та автоматично масштабується. DynamoDB знімає навантаження з адміністрування розподіленої бази даних [24]. Тож не має необхідності піклуватися про закупівлю серверного обладна- ння, установку та конфігурацію, реплікацію та масштабування

кластерів. Сервіс пропонує вбудоване шифрування у стані спокою.

Лист ІА61.010БАК.002.ПЗ 43 Зм. Лист № докум. Підпис Дата

Розробники можуть створювати таблиці, які можуть містити нескін- ченну кількість даних і підтримують трафік будь-якого розміру. Можна регу- лювати пропускну здатність таблиці без зниження продуктивності. AWS надає потужний механізм моніторингу використання ресурсів та метрики продук- тивності. Доступна функція резервного копіювання даних за вимогою. Це дозво- ляє створювати повні копії таблиць на довгий час та архівувати звіти моніто- рингу. Для таблиць налаштовуються термін зберігання даних. Тоді DynamoDB автоматично видаляє записи, у яких сплив строк. Це зменшує кількість ре- сурсів, що використовуються під застарілі дані та допоможе економити кошти у довгостроковій перспективі. Всі дані зберігаються в декількох копіях на значній кількості серверів для оптимізації доступності та швидкодії. Наприклад, на запит з української IP адреси надасть відповідь якийсь з серверів, що знаходяться в Європі, а не у Південній Америці. Таким чином і швидкість отримання інформації зростає для користувача, і розподіляється навантаження на систему серверів. Всі дані зберігаються на твердотілих накопичувачах та автоматично реплікуються че- рез всі зони доступності в усіх регіонах AWS, що підвищує загальну доступ- ність даних да відмовостійкість серверів.

2.7 Amazon CloudWatch

Amazon CloudWatch – це сервіс моніторингу хмарних ресурсів AWS і веб-додатків, які працюють з використанням AWS. Amazon CloudWatch можна використовувати для збору та відстежування метрик, накопичення і аналізу файлів журналів, створення попереджень, а також своєчасного реагу- вання на зміну ресурсів AWS. Здебільшого він використовується для моніто- рингу наступних ресурсів AWS: інстансів Amazon EC2, таблиць Amazon DynamoDB, інстансів Amazon RDS DB, а також для моніторингу визначених метрик додатків і сервісів, будь-яких логів, що створює розробник. Лист ІА61.010БАК.002.ПЗ 44 Зм. Лист № докум. Підпис Дата

Наприклад, таким чином можна логувати події у процесі розмови в Amazon Connect. Amazon CloudWatch використовується для отримання загальної інфор- мації про систему, що в включає в себе інформацію про використані ресурси, продуктивність додатків і загальний стан. Ці дані необхідні для оперативного реагування і забезпечення стабільної роботи веб-додатків. На рисунку 2.7. показано принцип роботи сервісу Amazon CloudWatch.

Рисунок 2.7 - Принцип роботи Amazon CloudWatch [25].

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

Лист ІА61.010БАК.002.ПЗ 45 Зм. Лист № докум. Підпис Дата

2.8 Amazon Kinesis

За допомогою Amazon Kinesis можна зручно збирати, оброблювати і аналізувати потокові дані у режимі реального часу, щоб своєчасно отримати аналітичні результати і швидко реагувати на нову інформацію. Основні мож- ливості, що надає сервіс Amazon Kinesis, дозволяють економічно оброблювати потокові дані у будь-якій кількості, а також забезпечують гнучкість при виборі інструментів, які оптимально відповідають вимогам додатку. Amazon Kinesis дає можливість у режимі реального часу збирати такі дані, як відеопотоки, аудіопотоки, журнали додатків, події навігації користувачів по веб-сайтам і телеметричні дані з пристроїв інтернету речей для машинного навчання. Загалом, можливо безперервно отримувати і зберігати дані зі швидкістю декілька терабайтів на годину з сотень тисяч джерел одночасно. Дані з Kinesis можна також передавати в інші сервіси AWS, наприклад Amazon S3, Amazon Lambda, Amazon Connect. Одиницею даних в потоці Kinesis є запис (data record). Він складається з порядкового номеру, ключа та бінарного поля Binary Large Object (BLOB) роз- міром до 1 мегабайту [26]. Одиницею потоку даних Kinesis є так званий шард (shard). Це одно- значно ідентифікована послідовність записів даних (data records) у потоці. Потік складається з одного або більше шардів, кожен з яких надає фіксовану ємність до 5 транзакцій в секунду для читання зі швидкістю до 2 мегабайтів у секунду та до 1000 транзакцій для запису зі швидкістю до 1 мегабайту в се- кунду. Пропускна здатність всього потоку складається з кількості шардів, що в ньому задіяно. Максимальна їх кількість у одному потоці досягає 500 оди- ниць [23]. На рисунку 2.8 показана високорівнева архітектура Kinesis Data Streams, яку було вирішено використовувати в розроблюваній системі. Основні учас- ники у цій взаємодії:

Лист ІА61.010БАК.002.ПЗ 46 Зм. Лист № докум. Підпис Дата

 Рroducers – це генератор інформації. Наприклад, веб-сервер що надсилає дані з логів.  Streams – це і є власне потоки, що складаються з шардів.  Consumers – додатки та інші сервіси AWS, що зчитують дані з кон- кретного шарда.

Рисунок 2.8 – Високорівнева архітектура Kinesis Data Streams [26].

2.9 Висновки

В розділі було розглянуто кожен з компонентів, що будуть використані у проектуванні системи. Всі компоненти являють собою хмарні сервіси та надаються Amazon Web Services. Компоненти було підібрано так, щоб їх можна було інтегрувати хоча б з одним з інших сервісів. Кожен з обраних сервісів або виконує певну функцію або слугує з’єднуванням для двох інших. Наприклад, Amazon Cloud- Watch та Amazon Kinesis слугують тільки для доставки даних для функцій Am- azon Lambda.

Лист ІА61.010БАК.002.ПЗ 47 Зм. Лист № докум. Підпис Дата

Звісно, для кожного з них є аналогічне рішення зі схожим функціоналом. Але ключова особливість полягає в тому, що всі обрані сервіси розроблені і підтримуються однією компанією. AWS – найбільший постачальник хмарних послуг у світі. При розробці кожного сервісу, були передбачені випадки, в яких доцільно було б інте- грувати його з іншими, вже існуючими, сервісами. Починаючи з 2006 року пе- релік доступних сервісів все збільшується: додаються нові сервіси, оновлю- ються існуючі. Таким чином, більше ніж за десять років розробки, Amazon створив величезну екосистему для розробників, де в кожен сервіс закладена можливість інтеграції з рядом інших сервісів. Всі сервіси мають вичерпну до- кументацію, що підтримується та оновлюється разом з нововведеннями в си- стемі. Тож було вирішено, що найвдаліший варіант – використовувати сервіси з однієї екосистеми для створення власної системи. Це забезпечить стабіль- ність та підтримуваність кожного з модулів зі сторони провайдера. Слід зауважити, що AWS також забезпечує відмовостійкість та доступ- ність високого рівня для кожного з сервісів. Це забезпечується завдяки 42 зо- нам доступності в 16 географічних регіонах по всьому світу. Сервіси викори- стовують географічно найближчі сервери для своєї роботи, але якщо в поточ- ному ЦОД відбудеться аварія, то сервіси не перестануть працювати, а просто будуть доступні з найближчого працюючого ЦОД.

Лист ІА61.010БАК.002.ПЗ 48 Зм. Лист № докум. Підпис Дата

3 РОЗРОБКА АРХІТЕКТУРИ ТА ПРОЕКТУВАННЯ СИСТЕМИ

Розроблювана система будується з хмарних сервісів, злагоджена взаємодія яких забезпечує виконання задач результат, а саме:  здійснення дзвінків на будь-які номери.  прийом дзвінків.  автоматичне здійснення вихідних дзвінків (для сповіщень або роз- силки).  запис у лог інформації про дзвінок.  зберігання даних (логів та записів розмов).  моніторинг діяльності системи. Платформою для побудови системи було обрано Amazon Connect. Він одразу забезпечує можливість здійснення вхідних та вихідних дзвінків. В про- цесі дзвінка деяка інформація одразу потрапляє до Amazon CloudWatch, де її можна продивитися, зайшовши у консоль Amazon CloudWatch. Як тільки ін- формація потрапила до CloudWatch, створюється подія у форматі JSON з цими даними всередині. Функція AWS Lambda підписана на події, що створюються у CloudWatch, тож створюється екземпляр цієї функції і на вхід подається JSON з даними. Функція трансформує дані до зручного вигляду і зберігає їх у DynamoDB. Оскільки дзвінки можуть бути не однаковими, і протягом розмови можуть з’являтися нові дані – цей процес може повторитися. Тому Lambda функція при кожному виклику перевіряє, чи була по цьому дзвінку вже збере- жена інформація, і в цьому випадку доповнює існуючий запис новими даними. Після завершення дзвінка Amazon Connect передає дані у потік Kinesis. Ана- логічно, Kinesis створює подію, на яку підписана інша Lambda функція, яка приймає об’єкт з даними, приводить їх до зручної форми, після чого отримує всі записи з DynamoDB, які були зроблені під час дзвінка, об’єднує ці дані та надсилає на сервер. Описана поведінка системи представлена на креслениках ІА61.010БАК.003 Д1 та ІА61.010БАК.003 Д2.

Лист ІА61.010БАК.002.ПЗ 49 Зм. Лист № докум. Підпис Дата

Більшість компонентів розташовано в центрах обчислювання даних Am- azon Web Services та не потребують обслуговування зі сторони підприємства. Єдине, що необхідно налаштувати для користування системою – робоча станція з веб-браузером та доступом до мережі Інтернет. Структура модулів та їх інтерфейси представлені на кресленику ІА61.010БАК.003 Д3. Amazon Connect став базовим вузлом, на якому будується вся система. В процесі розробки було виявлено такі ключові поняття:  інстанс (instance) Amazon Connect.  Contact Control Panel (CCP).  консоль Amazon Connect. Інстанс Amazon Connect можна вважати за робочий кабінет оператора або адміністратора контактного центру. У ньому адміністратор може замов- ляти нові номери телефонів, налаштовувати маршрутизацію між операторами, надавати їм права доступу, дивитися історію дзвінків. На Рисунку 3.1 зобра- жено зовнішній вигляд інстансу Amazon Connect.

Рисунок 3.1 – Зовнішній вигляд інстансу Amazon Connect.

Лист ІА61.010БАК.002.ПЗ 50 Зм. Лист № докум. Підпис Дата

В системі була налаштована стандартна маршрутизація – виклик транслюється на всіх підключених операторів, відповідає той хто перший зможе прийняти дзвінок у Contact Control Panel. Не було введено спеціальної черги для особливої категорії клієнтів, але така можливість є. Для задання сценарію дзвінка в Amazon Connect існують потоки дзвінків (Contact Flows). Було створено потік, що призначався для стандартного вхід- ного дзвінка у систему. Він виглядає як послідовність блоків з певними діями. На рисунку 3.2 показано його вигляд в інстансі Amazon Connect. Перші два блоки відповідають за активацію логування подій під час дзвінка та активації функції запису розмови відповідно. Коли дзвінок дохо- дить до блоку Get customer input робот проговорює привітальний текст та пи- тає, що хоче клієнт. У відповідь клієнт щось говорить. До блоку прив’язується бот Amazon Lex, який розпізнає те що сказав клієнт. Даний бот створений для прийому заказу піци, тобто якщо клієнт сказав щось що стосується піци, то бот його зрозуміє і продовжить роботу автоматично. Детально роботу цього бота буде розглянуто далі. Після прийому замовлення, в наступному блоці міститься текст подяки за замовлення, яке бот вимовляє і закінчує дзвінок. Якщо клієнт каже щось інше (не зв’язане за замовленням піци), то значенням на виході буде default і виконуються наступні блоки, де робот повідомляє клієнта про те що зараз підключиться оператор і перенаправляє дзвінок у спільну чергу. Був створений ще один потік для автоматичного обдзвону клієнтів. Наприклад, сповіщення про якусь акцію, нове термінове повідомлення тощо. Вигляд потоку показано на рисунку 3.3. У цьому випадку використовується Amazon Connect API, що була відкрита у публічний доступ тільки в квітні 2018 року. З допомогою цього API ініціалізовувати та переривати дзвінки. Аналогічно сценарію з вхідного дзвінка, перші два блоки активують логування та запис розмови. Блок Set voice визначає голос, яким робот буде розмовляти. Тепер до блока Get customer input

Лист ІА61.010БАК.002.ПЗ 51 Зм. Лист № докум. Підпис Дата

прив’язаний бот, що тільки розпізнає підтвердження людиною якоїсь інфор- мації. На підставі цього він робить відповідну дію, і генерується запис у лог.

Рисунок 3.2 – Вигляд вхідного потоку дзвінка

Рисунок 3.3 – Вигляд потоку автоматичного вихідного дзвінка

Боти, що були спроектовані для даної системи та використані в описа- них вище сценаріях, були створені за допомогою сервісу Amazon Lex. Перш за все при створенні будь-якого бота в Amazon Lex, потрібно чітко визначити, до яких ресурсів він може мати доступ. Це вкрай важливо, адже у

Лист ІА61.010БАК.002.ПЗ 52 Зм. Лист № докум. Підпис Дата

корпоративному аккаунті AWS компанії можуть використовуватися дуже ба- гато сервісів для різних задач. Тож рекомендовано на кожного нового бота створювати нову роль в Identity and Access Management (IAM) [27]. Боту, який приймає замовлення піци, було створено роль в IAM, яка на- зивається AWSServiceRoleForLexBots. На рисунку 3.4 представлені політики що використовуються в цій ролі.

Рисунок 3.4 – Політики для ролі AWSServiceRoleForLexBots

Як видно х рисунку, цей бот може звертатися лише до сервісу Amazon Polly, що використовується для синтезу мови. Ключовими поняттями при подуві бота Amazon Lex є інтенція (Intent) та тип слоту (Slot type). Інтенція представляє собою дію або намір з яким клієнт звернувся до бота. В даному випадку це замовлення піци. Бот може розрізняти кілька намірів. Наприклад можна реалізувати замовлення піци та напоїв через одного бота, а не створювати двох різних. Для кожної інтенції, необхідно за- дати фрази та слова, які б сигналізували про те, що клієнт хоче здійснити саме цю дію. На рисунку 3.5 показана реалізація опису інтенції OrderPizza, що була створена для бота у консолі Amazon Lex.

Лист ІА61.010БАК.002.ПЗ 53 Зм. Лист № докум. Підпис Дата

Рисунок 3.5 – Реалізація цілі (Intent) OrderPizza для бота

Наведені на рисунку фрази не є вичерпним списком того, на що бот буде реагувати. Це можна вважати за невеличкий датасет, на основі якого вже навчена модель нейронної мережі, що взята з Amazon Alexa, розуміє, чи мав клієнт на увазі саме замовлення піци. Проводиться семантичний аналіз, що порівнює запит клієнта з існуючими прикладами, і робиться висновок. Якщо бот розуміє, що клієнт не хоче замовити піцу, а каже щось інше, то він закінчує свою роботу та переходить у режим очікування. У реалізації спроектованої си- стеми, після відмови бота, клієнта інформують про те, що його з’єднають з оператором, а дзвінок переходить до загальної черги. Якщо ж клієнт сказав щось схоже на одну з наведених фраз, і бот його зрозумів, то алгоритм залежить від того, наскільки повну інформацію дав клієнт. Як можна бачити на рисунку 3.5, є слова, що взяті в дужки та відмічені різним кольором. Це доступні слоти. Вони являють собою важливу інфор- мацію, наприклад розмір піци. В розробленому боті було закладено три слоти: вид тіста (crusts), розміри (sizes), вид піци (pizza kind). На рисунку 3.6 наведено приклад створення та налаштування одного слоту. Аналогічним чином у

Лист ІА61.010БАК.002.ПЗ 54 Зм. Лист № докум. Підпис Дата

цьому вікні визначаються різні варіанти ключових слів та їх синоніми, що в купі створюють словник, на який опирається бот при виділенні ключових слів.

Рисунок 3.6 – Вигляд налаштування слоту

Маючи слоти, розробник може оперувати ними у прикладах для визна- чення інтенції. Якщо клієнт тільки дав зрозуміти що він хоче піцу (без уточ- нень розміру, тіста тощо), то бот буде задавати уточнюючі питання, що наве- дені на рисунку 3.6 для кожного слоту. Отримуючи відповіді, бот виділяє для себе ключові слова та поступово заповнює уявну форму замовлення. Таким чином, коли всі слоти будуть заповнені, у бота буде вся необхідна інформація для оформлення заказу. Для підвищення рівня обслуговування, та приско- рення роботи, в бота закладені шаблони, за якими клієнт першим же реченням і активує бота, і дає йому певні ключові слова. Тоді у бота немає

Лист ІА61.010БАК.002.ПЗ 55 Зм. Лист № докум. Підпис Дата

потреби задавати уточнюючі питання. Так, наприклад, якщо клієнт скаже «Хочу замовити середню піцу на тонкому тісті з сиром», то бот одразу запов- нить всі слоти відповідними значеннями і перейде до наступного етапу. Завершальним етапом у роботі бота є заповнення інтенції(intent fulfill- ment). Зазвичай це робиться за допомогою Lambda функції. Тож була створена функція PizzaOrderProcessor. В неї теж повинна бути своя IAM роль, яка зге- нерується автоматично при підключенні цієї функції до бота у консолі Amazon Lex. Як видно з рисунку 3.7, ця функція записує в CloudWatch логи, тож ро- зробник може проаналізувати діяльність функції, результати її викликів та зге- неровані помилки. Це дуже зручно, оскільки для безсерверних середовищ ро- зробки налагоджувач не передбачений, а в процесі написання програмного коду помилки обов’язково виникають.

Рисунок 3.7 - Політики для ролі PizzaOrderProcessorRole

Функція PizzaOrderProcessorRole слугує мостом між даними, що ввів клієнт та сервісом, що має потім їх обробити. На виході вона видає JSON об’єкт, який містить всю необхідну інформацію для створення замовлення. Можна одразу ж, всередині функції, створювати HTTP запит і в ньому переда- вати всі дані на сервер додатку. Але, оскільки цей бот проектувався виключно Лист ІА61.010БАК.002.ПЗ 56 Зм. Лист № докум. Підпис Дата

для інтегрування у потік Amazon Connect, а не як окремий сервіс для месен- джеру, то дані записуються у лог розмови. Таким же чином було спроектовано і бот, що призначається для вияв- лення підтвердження клієнта. В ньому наявний один слот, з двома можливими варіантами («так» або «ні»), для кожного з яких задано багато можливих си- нонімів. Нажаль, на даний момент синтезатори мови не зовсім здатні визна- чати мугикання та відносити його до якоїсь категорії. На такий випадок, в бо- тах закладається можливість перезапиту. Бот просить клієнта повторити більш чітко та ясно. Зазвичай, люди після першого перезапиту дають зрозумілу для бота відповідь. Протягом всього дзвінка у CloudWatch лог пишуться дані по кожному блоку з потоків на рисунках 3.2 та 3.3. CloudWatch одразу викликає Lambda функцію CloudWatchLogProcessor та передає їй на вхід об’єкт, що містить у собі ці дані. Цій функції були надані права зчитування логів з Amazon Cloud- Watch та повний доступ (читання та запис) до Amazon DynamoDB. Функція CloudWatchLogProcessor виконується на серверній стороні у хмарі Amazon, тож було обрано середу виконання Node.js 4.3. В процесі написання програм- ного коду було вирішено використовувати проміси (promises) замість колбеків (callbacks), що суттєво підвищує підтримуваність коду та покращує його ро- зуміння для розробників, що будуть його використовувати. У функції для ро- боти з базою даних використовується Amazon DynamoDB API, що теж підтри- мує роботу з промісами, що спрощує структуру коду. Під час дзвінка гене- рується в середньому 4 логи, тому під час виконання функції спочатку пе- ревіряється, чи наявні в базі дані по цьому дзвінку. Якщо ні, то створюється новий запис в базі, але якщо наявні, то до існуючого файлу додається новий запис. В цьому і полягає зручність NoSQL бази даних: швидка обробка даних та масштабованість, відсутня жорстка прив’язка до структури даних – у об’єкта може бути як одне, так і багато полів. Після завершення дзвінка створюється потік Kinesis Data Stream, що несе у собі додаткову узагальнену інформацію про здійснений дзвінок. Для

Лист ІА61.010БАК.002.ПЗ 57 Зм. Лист № докум. Підпис Дата

розуміння всієї картини цю інформацію теж вкрай необхідно враховувати ра- зом з усіма даними що на поточний момент зберігаються у DynamoDB. Так, наприклад у об'єкті даних, що несе в собі Kinesis є номери телефонів з обох сторін, дані про поточний статус оператора, його ідентифікатор. Прив’язка йде до системи взагалі. В той час як дані, які пишуться у лог під час дзвінка, нічого не містять у собі про зовнішнє оточення , а містять тільки те, що відбулося в результаті виконання конкретного блоку в сценарії дзвінка. Lambda функція KinesisStreamProcessor була спроектована для того, щоб зчитати дані з потоку Kinesis Data Stream. Одним з полів отриманого об’єкту є однозначний ідентифікатор дзвінка, по якому функція робить запит у Amazon DynamoDB та отримує всі записи що були створені під час проведення дзвінка. В результаті запиту функція отримує об’єкт. Завершальним етапом в роботі функції є створення заключного об’єкту, який у собі матиме всю корисну ін- формацію з двох наявних об’єктів та відправка даних HTTP запитом на визна- чену адресу. Це буде сервер веб-додатку, який потім збереже цей об'єкт у кор- поративну базу даних. Розглянута вище реалізація системи не є дуже ефективною для бізнесу сама по собі, адже набагато більшу користь вона може принести з інтеграцією у CRM систему або веб-додаток компанії. Amazon Web Services надає єдиний варіант інтеграції, який з’явився не так давно. Але для базових потреб його цілком вистачає. Це бібліотека Amazon Connect Streams. Був створений простий веб-додаток за допомогою технології ASP.NET MVC, який слугує прототипом для веб-додатку компанії-замовника інтелекту- ального контактного центру. За допомогою менеджера пакетів NuGet було підключене AWSSDK.Core та AWSSDK.Connect – збірки, що надає Amazon Web Services для розробників в середовищі .NET. У них містяться класи та методи, за допомогою яких можна викликати Amazon Connect API. Метод, який потрібен для автоматичного вихідного дзвінка називається StartOut- boundVoiceContact, він формує HTTP запит, вигляд якого показаний на ри- сунку 3.8.

Лист ІА61.010БАК.002.ПЗ 58 Зм. Лист № докум. Підпис Дата

Рисунок 3.8 - формат запиту для автоматичного вихідного дзвінка.

У тілі запиту треба вказати наступні параметри: – Attributes. Це атрибути, які будуть вставлені як динамічні змінні у con- tact flow дзвінка. Наприклад, номер замовлення стосовно якого здійснюється сповіщення клієнта. – ClientToken. Це унікальний ідентифікатор що визначає ідемпотент- ність запиту. Він залишається актуальним 7 днів після створення. – ContactFlowId. Це ідентифікатор сценарію дзвінка, який буде здійснено. – DestinationPhoneNumber. Це номер клієнта, якому здійснюється дзвінок. Його необхідно вказати у форматі E.164. – InstanceId та QueueId. Це унікальні ідентифікатори інстансу Amazon Connect та черги відповідно. – SourcePhoneNumber – номер, з якого буде здійснено дзвінок. Це має бути один з номерів, що зарезервовані для даного акаунта Amazon Connect. Його необхідно вказати у форматі E.164. Таким чином можна здійснювати автоматичні дзвінки на будь-які но- мери з будь-яким визначеним сценарієм. Очевидно, що тільки спеціально ро- зроблені варіанти потоку дзвінка доцільно використовувати для автоматичних

Лист ІА61.010БАК.002.ПЗ 59 Зм. Лист № докум. Підпис Дата

вихідних дзвінків. Наприклад такий, що був продемонстрований на рисунку 3.3. Використання бібліотеки Amazon Connect Streams дало можливість ін- тегрувати контактний центр з браузером. Оскільки кожен оператор спроекто- ваного контактного центру користується лише браузером, то туди потрібно виводити якомога більше корисної інформації. Перш за все, це Contact Control Panel(CPP), що є софтфоном (softphone) в Amazon Connect. На рисунку 3.9 показано, яку інформацію надає бібліотека Amazon Con- nect Streams під час вхідного дзвінка. Оператор ще не прийняв дзвінок, а вже має доступний для читання номер абонента. Тож на стороні клієнта робиться запит у базу даних по номеру, і повертається корисна інформація по абоненту.

Рисунок 3.9 – інтегрований CPP у веб-браузер з інформацією про вхідний дзвінок.

У такий спосіб оператор контактного центру заздалегідь має інформацію про абонента. Він може привітати клієнта по імені та бачити історію замовлень або інші значимі параметри, залежно від системи, у яку інтегрується контакт- ний центр. Це значно підвищить задоволення клієнтів від обслуговування та спростить роботу операторам, тому що їм не потрібно буде витрачати час на те щоб дізнатися якусь базову інформацію у клієнта.

Лист ІА61.010БАК.002.ПЗ 60 Зм. Лист № докум. Підпис Дата

На кресленику ІА61.010БАК.003 Д4 представлено UML діаграму преце- дентів, що описує варіанти використання користувачами інтегрованої си- стеми. На рисунку 3.10 показана сторінка у веб-браузері, у якій реалізовано ба- зову інтеграцію розробленого контактного центру з простим веб-додатком.

Рисунок 3.10 – веб-сторінка з інтегрованим контактним центром.

Ключові елементи цієї сторінки: софтфон, що дає змогу здійснювати дзвінки як зі звичайного контактного центру та форма, заповнення якої дає можливість зробити автоматичний дзвінок на вказаний номер за обраним сце- нарієм.

Лист ІА61.010БАК.002.ПЗ 61 Зм. Лист № докум. Підпис Дата

3.1 Висновки

В даному розділі було описано архітектуру системи інтелектуального бота для обслуговування клієнтів. Було розглянуто побудову системи з обра- них компонентів, їх зв'язок та принцип взаємодії. В архітектурі системи закладено та реалізовано необхідний функціонал, а саме:  гнучка модульна структура.  відсутність у потребі розгортання серверів на базі підприємства.  розуміння та синтез людської мови.  підтримання функціоналу автоматичної телефонної станції. Було продемонстровано налаштовування обраних сервісів так, щоб вони взаємодіяли між собою та складали собою злагоджену систему. Також було реалізовано просту інтеграцію системи з веб-додатком.

Лист ІА61.010БАК.002.ПЗ 62 Зм. Лист № докум. Підпис Дата

ВИСНОВКИ

Згідно зі статистикою, рівень якості обслуговування споживачів безпо- середньо впливає на розвиток підприємства, що працює з клієнтами. Якість послуг, що надаються, зростає з кожним роком. Це стосується і якості підтримки клієнтів. Необхідно мати цілодобово доступний канал зв’язку з клієнтами для надання відповіді якомога швидше. В даному дипломному проекті було розроблено інтелектуального діало- гового бота для обслуговування клієнтів. Бот працює на основі хмарного кон- тактного центру. В процесі проектування та розробки було проаналізовано найсучасніші технології, що призначені для вирішення описаної проблеми. В розробленій системі використані хмарні сервіси з екосистеми Amazon Web Services, які націлені на створення комплексних рішень для рішення ре- альних задач шляхом взаємної інтеграції та компонування. В результаті виконання дипломного проекту було отримано інтелекту- ального діалогового бота на базі контактного центру, що характеризується ви- сокими параметрами відмовостійкості, доступності та масштабованості. Си- стема відповідає вимогам сучасних контактних центрів та підтримує надає ба- зовий функціонал, а саме:  дає можливість здійснювати вхідні та вихідні дзвінки операторам контактного центру.  здійснює автоматичні вихідні дзвінки з використанням діалого- вого бота.  записує та зберігає запис розмови.  записує в лог важливу інформацію під час здійснення дзвінка.  має надійне сховище для даних.  формує звіти по здійсненим та прийнятим дзвінкам.  відображає на робочому місці оператора доступну інформацію про дзвінок та про клієнта (у тому числі з використанням CRM системи).  підтримує організацію черги та маршрутизацію вхідних дзвінків. Лист ІА61.010БАК.002.ПЗ 63 Зм. Лист № докум. Підпис Дата

Завдяки застосуванню в системі інтелектуальних технологій, вдалося ре- алізувати діалогового бота, що розуміє визначені людські команди та здатний синтезувати людську мову. Впровадження такого бота значно зменшить навантаження на операторів колл-центру. Адже бот може автоматично здійснювати вихідні дзвінки з метою інформування абонентів, що є монотон- ною та виснажливою працею для людини. Також він може самостійно оброб- лювати прості запити під час вхідних дзвінків та вирішувати їх без залучення оператора. Впровадження такої системи на підприємстві не тільки зменшить наван- таження на персонал, а й дозволить операторам працювати з будь-якого місця де є доступ до мережі Інтернет: для повноцінного функціонування необхідно мати лише браузер. Розроблена система не потребує розгортання інфраструктури на підприємстві та технічного персоналу для її обслуговування. Всі сервери знаходяться в центрах обчислювання даних, які спеціалізуються на наданні та- ких послуг. Отже, таку систему можуть впровадити в себе навіть невеликі ком- панії, які не мають відповідних приміщень для утримання необхідного облад- нання.

Лист ІА61.010БАК.002.ПЗ 64 Зм. Лист № докум. Підпис Дата

СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ

1. The Impact of Customer Service on Purchase Decisions [Електронний ресурс]. – Режим доступу: https://www.providesupport.com/blog/the-impact-of- customer-service-on-purchase-decisions/. – 01.05.2020. 2. Аутсорсинговый контакт, колл, call центр. Услуги контакт центра [Електронний ресурс]. – Режим доступу: https://contact-call.com/. – 01.05.2020. 3. Phone Dialer Software Solutions EVS7 [Електронний ресурс]. – Режим доступу: https://www.evs7.com/. – 01.05.2020. 4. Cloud Speech-to-Text Basics, Cloud Speech-to-Text API [Електронний ресурс]. – Режим доступу: https://cloud.google.com/speech-to-text/docs/basics. – 01.05.2020. 5. Artificial Intelligence in Healthcare Makes a Difference Nuance [Електронний ресурс]. – Режим доступу: https://www.nuance.com/healthcare/ar- tificial-intelligence.html. – 01.05.2020. 6. Speech to Text - IBM Cloud [Електронний ресурс]. – Режим доступу: https://console.bluemix.net/docs/services/speech-to-text/index.html#about. – 01.05.2020. 7. Notes on the Network / AT&T // AT&T, 1980. – p.3 8. Alan B. J. SIP: Understanding the Session Initiation Protocol / B. Johnston Alan // O'Reilly Media, 2004. – p. 800. – (Second Edition). 9. Bryant R. Asterisk: The Definitive Guide / R. Bryant, M. Leif, V. Jim // O'Reilly Media, 2013. – (4th Edition). 10. Smith J. Beyond Asterisk: The Future of Telephony. / J. Smith, M. Leif, V. Jim // O'Reilly Media, 2009. 11. Azure Functions – Serverless Architecture – Microsoft Azure [Електронний ресурс]. – Режим доступу: https://azure.microsoft.com/en-us/ser- vices/functions/. – 01.05.2020.

Лист ІА61.010БАК.002.ПЗ 65 Зм. Лист № докум. Підпис Дата

12. Azure App Service plan overview – Microsoft Docs [Електронний ре- сурс]. – Режим доступу: https://docs.microsoft.com/en-us/azure/app-service/az- ure-web-sites-web-hosting-plans-in-depth-overview. – 01.05.2020. 13. Cloud Functions - Event-driven Serverless Computing – Google Cloud [Електронний ресурс]. – Режим доступу: https://cloud.google.com/functions/. – 01.05.2020. 14. Robin H. Making the Most of the Cloud: How to Choose and Implement the Best Services / H. Robin // Scarecrow Press November, 2013. – p. 3. 15. Amazon Lex – Build Conversation Bots – Amazon AWS [Електронний ресурс]. – Режим доступу: https://aws.amazon.com/lex/?nc1=h_ls. – 01.05.2020. 16. Amazon Connect – Cloud-Based Contact Center – Amazon AWS [Електронний ресурс]. – Режим доступу: https://aws.amazon.com/con- nect/?nc2=h_m1. – 01.05.2020. 17. Maximising the Customer Experience with Amazon Connect and AI Ser- vices [Електронний ресурс]. – Режим доступу: https://www.slideshare.net/Ama- zonWebServices/maximising-the-customer-experience-with-amazon-connect-and- ai-services. - 01.05.2020. 18. Serverless Architectures with AWS Lambda. Overview and Best Practices [Електронний ресурс]. – Режим доступу: //https://d1.awsstatic.com/whitepa- pers/serverless-architectures-with-aws-lambda.pdf. – 01.05.2020. 19. Programming Model – AWS Lambda – AWS Documentation [Електронний ресурс]. – Режим доступу: https://docs.aws.ama- zon.com/lambda/latest/dg/programming-model-v2.html. – 01.05.2020. 20. What Is AWS Step Functions? – AWS Documentation [Електронний ре- сурс]. – Режим доступу: https://docs.aws.amazon.com/step-functions/la- test/dg/welcome.html. – 01.05.2020. 21. AWS Lambda Tutorial for AWS Solution Architects [Електронний ре- сурс]. – Режим доступу: https://www.edureka.co/blog/aws-lambda-tutorial. – 01.05.2020.

Лист ІА61.010БАК.002.ПЗ 66 Зм. Лист № докум. Підпис Дата

22. Amazon Virtual Private Cloud (VPC) – Amazon AWS Documentation [Електронний ресурс]. – Режим доступу: https://aws.amazon.com/vpc/. – 01.05.2020. 23. Amazon S3, Cloud Computing Storage for Files, Images, Videos. [Електронний ресурс]. – Режим доступу: https://aws.amazon.com/s3/. – 01.05.2020. 24. Amazon DynamoDB – a Fast and Scalable NoSQL Database Service De- signed for Internet Scale Applications. All Things Distributed blog by Werner Vo- gels [Електронний ресурс]. – Режим доступу: https://www.allthingsdistrib- uted.com/2012/01/amazon-dynamodb.html. – 01.05.2020. 25. Creating Amazon CloudWatch Alarms – AWS Documentation [Електронний ресурс]. – Режим доступу: https://docs.aws.amazon.com/Amazon- CloudWatch/latest/monitoring/AlarmThatSendsEmail.html. – 01.05.2020. 26. Amazon Kinesis Data Streams Key Concepts – AWS Documentation [Електронний ресурс]. – Режим доступу: https://docs.aws.ama- zon.com/streams/latest/dev/key-concepts.html. – 01.05.2020. 27. Understanding How IAM Works – AWS Identity and Access [Електронний ресурс]. – Режим доступу: Management https://docs.aws.ama- zon.com/IAM/latest/UserGuide/intro-structure.html. – 01.05.2020.

Лист ІА61.010БАК.002.ПЗ 67 Зм. Лист № докум. Підпис Дата