Міграція 100 ТБ під обстрілами та «нобелівський лауреат на сортуванні цвяхів»: Петро Вавулін про хмари та штучний інтелект у «Київстар»

Про все це CEO dev.ua Станіслав Юрасов поспілкувався з Петром Вавуліним, керівником департаменту розвитку хмарних продуктів і сервісів «Київстар».

— Як змінилися зараз настрої клієнтів на ринку після нещодавніх обстрілів київської айтішної інфраструктури? Що зараз відбувається? Що кажуть клієнти про свої потреби? 

— Стосовно настроїв є невелика зміна фокусу на розміщення частини айтішних систем, навантажень та інфраструктури. Отже, є певний фокус саме на цьому напрямку. Чому не великий? Більшість клієнтів, яким ми допомагаємо, для яких впроваджуємо та яким підтримуємо роботу їхньої інфраструктури, ще з початку повномасштабного вторгнення мали резервні майданчики в хмарі.

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

Це не дуже велика хвиля, оскільки, повторюсь, здебільшого клієнти це зробили заздалегідь. Зараз вони шукають варіанти та сценарії оптимізації витрат. В цілому,  більшість клієнтів так чи інакше вже використовували ресурси Azure, Amazon, Google, Oracle. В нашому випадку — в Azure, тому що ми як партнер Майкрософт підтримуємо та допомогаємо клієнтам у питаннях, повʼязаних з використанням саме цієї хмарної платформи. Підсумую: кардинальних змін ми поки що не бачимо, адже більшість так чи інакше (в більшій чи меншій мірі) уже була в хмарі.

—  Чи має «Київстар» готові сценарії у разі підготовки компанії до disaster recovery (зробити копіювання або щось подібне)? Може, маєте якісь шаблони? 

— Це важко назвати шаблоном. Скоріше, це стандартизований підхід. Наша команда ще 5–7 років тому розробила сценарії використання хмарної платформи, які не обмежуються використанням disaster recovery сценаріїв чи, як це кажуть, BCDR (Business Continuity and Disaster Recovery). Вони включають і сценарії, коли частину обчислювальних ресурсів клієнт отримує саме у хмарі. Також ми час від часу оновлюємо сценарії з урахуванням поточних обставин та розвитку технологій і сервісів.

Сценарії враховують різні ситуації та задачі клієнтів. Наприклад, клієнти працюють з енд-юзерами, які знаходяться на інших континентах або в інших країнах. Тоді логічніше використовувати платформу Azure для масштабування свого бізнесу за кордоном.

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

Наша команда має високу кваліфікацію, що підтверджується партнерськими статусами (Microsoft Advanced specializations, Fortinet Select MSSP, тощо). Ми пропонуємо допомогу щодо вирішення питань безпеки всього, що розгортаємо в хмарах, використовуючи різні підходи в залежності від потреб та можливостей (Microsoft Cybersecurity Reference Architectures, Microsoft cloud security benchmark v2, Fortinet Security Fabric тощо).

— Які кастомні опції є для великих клієнтів? 

— Говорячи про великих клієнтів, хотів би зазначити, що у нас є навіть опція, яка дуже рідко може бути шаблонізована для клієнтів, що користуються різними сервісами та технологіями, — розробка Business Continuity Plan (BCP). Також ми розуміємо, що у кожного клієнта свої (часто унікальні) вимоги щодо відновлення.

Наприклад, є банк, який може втратити певну кількість транзакцій і даних в системах. А є клієнт (представник малого бізнесу), який відвантажує невелику кількість продукції щотижня, тож у нього інші вимоги щодо якості та виконання цього плану. Зважаючи на потреби та складність робочих процесів — маленький може більшу кількість годин бути у стадії відновлення своїх цифрових сервісів і на деякий час проводити необхідні операції в ручному режимі.

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

— Я розумію, що кейси різні, але все ж таки є якісь часові рамки щодо того, скільки може тривати міграція в Azure? 

— На думку приходить міграція одного з найбільших банків України з core-банківськими системами, сховищами. Свого часу процес відбувався 45 днів. Виходячи з цього кейсу, я б орієнтувався десь на 40–45 днів, якщо це надважкий кейс, тобто сотні терабайтів даних, складні додатки, системи інформаційної безпеки.

На початку повномасштабного вторгнення у нас був, наприклад, клієнт з базами даних близько 10–15 терабайтів. Тоді ми переносили його дані впродовж годин (дані були на декількох локаціях, і використовувались окремі канали звʼязку для кожного). Канали зв’язку витримали, ми були його провайдером. 

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

— Ви ще згадали штучний інтелект. Хотілося б дізнатися, які є запити у клієнтів на використання штучного інтелекту? Чого вони потребуть, який це бізнес, яка його специфіка? 

— Якщо перефразувати висловлювання колишнього директора ФБР стосовно кібербезпеки (він казав, що компанії діляться на два види: ті, яких зламали, і ті, які ще не знають, що їх зламали), то про штучний інтелект можна сказати так: всі компанії діляться на два види — ті, які використовують штучний інтелект, і ті, які не знають, що вони його використовують.

Можу розповісти про деякі типові запити на сьогодні.

Внутрішні помічники: дозволяють безпечно працювати з конфіденційними або сенситивними даними всередині організації (звітність, внутрішні документи), які в публічний чатбот з підпискою не хочеться відправляти, бо там є End-User License Agreement, який дозволяє моделі навчатися на відправлених даних і відповідати іншим з урахуванням цих даних. Компанії це не підходить, адже фінансова інформація може опинитися в публічному доступі. Ми допомагаємо безпечно розгортати окремі інстанси, ізольовані від публічних підписок, регламентовані платформою Microsoft (GDPR, ISO, з’явився ISO на безпечне використання ШІ). Перевага публічних хмар — це базова сертифікація сервісів. Співробітник замість того, щоб 3–4 години шукати, за якою формою повернути товар (бо є брак кадрів, взяли нову людину), запитує помічника — і той одразу відповідає.

Зовнішні помічники: також мають доступ до певної сенситивної інформації, але працюють з людьми за периметром компанії (клієнтами, підрядниками). Там по-іншому відбуваються процеси авторизації та валідації.

Розпізнавання зображень: наприклад, цінники на полицях. Промоутер приходить, фотографує, а ШІ обробляє та порівнює ціни.

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

— Чи можна зараз казати, що є тренд у бізнесі на те, що збільшується кількість запитів на рішення зі штучним інтелектом? 

— Так, у нас напрямок штучного інтелекту розвивається надзвичайно динамічно.

— Як у вас відбувається інтеграція хмари «Київстар» і хмари Azure? Коли приходить клієнт, що ви йому пропонуєте? 

— По-перше, наша команда виконує три основні дії: оцінює задачі клієнта, розробляє план імплементації та підтримує рішення.

По-друге — ми підходимо до кожного клієнта індивідуально. У когось бюджет практично необмежений, і головне завдання — зберегти бізнес-процеси. А комусь треба, вирішуючи питання відмовостійкості та безперервності бізнесу, знайти золоту середину між OpEx і CapEx, роботою інфраструктури та можливостями компанії в умовах обстрілів, дорогого страхування та невизначеності.

Варіантів інтеграції безліч. Найпростіший варіант: мінімальна інтеграція, використання сховища, розміщеного в датацентрах Європі чи США — простий, але надзвичайно надійний Storage. Запускається за 5 хвилин: встановлюємо спеціальну  програму, або використовуємо браузер. Ми консультуємо, разом з клієнтом налаштовуємо доступи — і далі просто drag-and-drop перетягування інформації зі свого сервера або сервера Kyivstar.Cloud, використовуючи наші канали звʼязку.

Інноваційний варіант: може включати перебудову інфраструктури з використанням інноваційних хмарних сервісів (наприклад з використанням підходів Rearchitect або Rebuild cloud native). За такого підходу ми оцінюємо віртуальні машини, бази даних, веб-сервіси, контейнери (Kubernetes) і дивимося, як все інтегрувати та потенційно замінити з використанням хмарних сервісів. Побічним результатом виконання цих дій часто є розробка BCP з реплікацією та резервним копіюванням.

«Стандартний варіант» — гібридна інфраструктура: частина робочих нод знаходиться в хмарі «Київстар» чи дата-центрі клієнта, а частина — в Azure. В такому варіанті на стадіях планування та імплементації враховуються питання інформаційної безпеки та балансування навантажень між сайтами (автоматично чи автоматизовано).

Рішення для мережі: у 2022 році під час тотальних блекаутів у клієнта стояв один hardware appliance, який маршрутизував усю мережу. При відключенні світла, зникав звʼязок з віртуальним пристроєм, і всі віддалені клієнти переставали працювати. З клієнтом ми розробили рішення з перенесенням віртуального мережевого пристрою в хмару Microsoft, яка не вимикається. Усі лінки від клієнтів ми перекинули на цей віртуальний appliance в хмарі в Європі, а трафік, який проходить через інфраструктуру в хмарі, маршрутизували на той дата-центр, де є світло.

— Компанія X з ритейлу каже: хочу голосового помічника ШІ, але нічого не розумію в цьому. «Київстар» може створити його та розгорнути у своїй хмарі? 

— Саме з такими клієнтами ми здебільшого і працюємо! Коли ми починали у 2023 році, більшість компаній намагалися бігти з Copilot, а ми в свою чергу, окрім потенційного використання Copilot, вирішили фокусуватися на кастомних рішеннях. Коли клієнт казав, що хоче Copilot, ми казали: купити можеш, але давай подивимося на твої завдання.  Для внутрішнього чи зовнішнього користування? Чи треба додати розпізнавання голосу? Чи потрібно працювати з внутрішніми базами даних?

В більшості випадків ми з клієнтом опрацьовуємо це завдання і доходимо до MVP. Головна проблема проєктів із ШІ — це не зробити щось маленьке, що працює. Головна проблема — інтегрувати MVP в робочий ланцюжок всередині організації, бо на етапі тестування все добре, а на етапі повномасштабного впровадження зʼявляється legacy, вимоги інформаційної безпеки, поточні системи та сервіси, користувачі та багато інших відкритих питань.

Наступне важливе питання, яке ми обговорюємо — вартість використання рішення. Верхнерівнево тарифікація ШІ залежить від рівня моделі та кількості обробленої інформації (токенів). Причому у вартість враховується вхідна (те що питаємо) та вихідна (відповідь, або результат, який отримуємо) інформація.

Були приклади у знайомих, коли моделі почали ставити запитання не по темі (наприклад, продаєте каву, а студент замість доступних сортів зерен питає у вашої моделі, як вирішити рівняння третього ступеню). Модель намагається відповісти, з'їдає токени, компанії виставляється рахунок.

Тому ми розробляємо MVP разом із командою клієнта, розраховуємо економіку та бізнес-кейс.

У нас були приклади, коли для деяких завдань ШІ виходив дорожчим за очікування, і тоді клієнт приймав рішення відкласти це питання на майбутнє (коли потенційно нові моделі можуть зменшити вартість токену). 

Один клієнт почав використовувати ШІ для звичайного Q&A всередині організації, але замість стандартної моделі вибрав Claude Opus. Це умовно як поставити на сортувальний цех цвяхів нобелівського лауреата з доходами пів мільйона доларів на рік. Чи може він сортувати — розкладати квадратне до квадратного? Може, але вартість цієї роботи буде надто високою.

Ще один важливий момент при впровадженні — відповідність правилам відповідального використання ШІ. У Microsoft є 5 принципів відповідального використання (схожих на три принципи робототехніки Айзека Азімова). Деякі з цих принципів включать наступні вимоги — модель має бути чесною, відкритою, а фінальне рішення, якщо воно може завдати шкоди людині, має приймати людина. Обовʼязково мають бути передбачені механізми виключення критичних помилок. Адже ми не можемо повністю віддати автопілот ШІ, бо хто ж тоді відповідатиме за наслідки?

— Якщо компанія має неструктуровані дані, то ви допомагаєте їх структурувати чи це робота клієнта? 

— Поки що ми не стикалися з ситуаціями, коли нічого не могли зробити. Дані бувають структуровані та неструктуровані, але є інструменти, які дозволяють працювати ШІ як зі структурованими даними, так і не структурованими, наприклад, із зображеннями.

— Чи є у вас заготовлені, шаблонні ШІ-помічники для бухгалтера, фінансиста або фахівця у сфері продажів? 

— Загалом так. ШІ не обмежується чатботами (до речі, перші розробки ШІ з’явилися ще в 60-х роках минулого століття). Є готові помічники загального призначення в Azure AI Foundry, для яких просто редагуєш системний промпт. Також, використовуючи хмару Azure, ти можеш докрутити різними параметрами, типом моделі, системними промптами, вагами та штрафами якість відповідей.

Окрім помічників, не варто забувати про інші сервіси з використанням штучного інтелекту. Наприклад, в Azure Machine Learning Studio, де можна обрати модель для прогнозування продажів, або в Azure AI — модель для optical character recognition (розпізнавання тексту). Для однієї задачі із шаблонними документами, які не входили до стандартних європейських чи американських документів, в «два кліки» вирішити задачу не вдалося. Тому ми взяли стандартну модель, зробили правильну розмітку на трьох семплах для навчання, і вона почала з точністю 96%+ розпізнавати ці не типові для Європи чи США шаблонні документи.

— А чи може з’явитися в майбутньому маркетплейс, де керівник заходить, вибирає потрібні ШІ-функції, кидає в кошик, оплачує та юзає з хмари? 

— За певної кількості типових реалізованих проєктів це з’явиться. Зараз це виглядає так, що потрібні функцію у кошику, умовно, виконують фахівці «Київстар», налаштовуючи ШІ під потреби клієнтів.

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

Зазвичай помічників створюють під кожен департамент: маркетинг, ІТ, юридична функція, бухгалтерія, тощо. Це робиться для того, щоб функції не бачили даних одна одної (фізичне розділення) та для керування та обліку витрат на використання ШІ (модель та споживання токенів). Ми робимо інтеграції таких ботів одразу в Microsoft Teams. Тобто, готового маркетплейсу як сайту, де все можна замовити, поки що немає, але сам процес уже працює.

Один із гарних прикладів неочікуваного використання ШІ: у клієнта було недостатньо знань із кібербезпеки, а саме з налаштування обладнання. Ми допомогли йому безпечно розгорнути модель GPT для ІТ, і вона допомагала йому конфігурувати файерволи та писати політики для Site-to-Site VPN і Point-to-Site VPN під конкретний пристрій. Це тимчасово вирішило питання відсутност необхдного фахівця.

— Щодо навчання: керівнику краще самому вчитися на курсах і ставати CTO чи користуватися послугами таких компаній, як «Київстар»? 

— Другий шлях простіший, бо людина не витрачає часу на те, щоб ставати CTO. Але хто відповідатиме, якщо щось зламається?

Коротка історія: один знайомий працював з Google Drive, умовно купував за $5 диск на 10 ТБ і надавав цей простір невеликим ФОПам під збереження бухгалтерської документацію. В один момент 10 ТБ даних зникли. З його слів, служба підтримки сказала: «Ви не прочитали EULA, це акаунт для персонального використання, гарантій збереження даних ніхто не давав, ось ваше сховище на 10 ТБ».

— Чи є обмеження законодавства на зберігання даних за кордоном? 

— В цілому для комерційних клієнтів таких обмежень немає. Але, певне регулювання також діє — на сьогодні дозволяється на період дії воєнного стану використовувати хмари з певними обмеженнями, наведеними у Постанові КМУ № 154. Зараз є також 99-та постанова НБУ, яка регламентує використання хмарних послуг банками та фінансовим сектором. Але повертаючись до малого та середнього бізнесу — прямих заборон немає.

— Щодо тарифних планів «Київстар»: як вибрати план і що туди включено? 

— У нас є тарифні плани, які включають сервіси Office 365/Microsoft 365. Деталі про комерційні пропозиції, вартості та «Суперсили» завжди можна актуалізувати на сайті «Київстар» або через B2B-менеджерів.

— Через швидку еволюцію ШІ кібербезпека змінюється. Чи бере на себе «Київстар» або Azure гарантії безпеки? 

— Працює Shared Responsibility Model (модель розподіленої відповідальності). Якщо коротко — клієнт відповідає за самі дані, налаштування доступів і вмикання багатофакторної автентифікації (MFA). Якщо MFA вимкнули і акаунт зламали — це відповідальність клієнта. Провайдер відповідає за фундаментальні речі, платформу (IaaS, PaaS, SaaS) і доступність інфраструктури. Більш детально з цією моделю можна ознайомитися на сайті.

— Якщо компанії раптово треба розширити хмару втричі — наскільки швидко це можливо зробити? 

— Якщо це планувалося заздалегідь — максимально швидко. Використання Azure йде за моделлю Pay-as-you-go. Наприклад, при бекапі з реплікацією клієнт не платить одразу за всі 15 віртуальних машин, 10 вебзастосунків і 100 ТБ даних. Він платить лише за службу бекапу та підтримку. А за всю інфраструктуру починає платити лише тоді, коли вмикає її під час надзвичайної події.

Тобто неважливо, чи планували ви збільшувати кількість ресурсів (як у випадку з Scale sets) чи ні (використання платформи, як резервного сайту) — масштабуватися можна дуже швидко і, що важливо, в географічно різні регіони (від Європи до США чи Азії).

Виняток — дефіцитні машини з GPU для ШІ (вартістю $10 000–20 000 на місяць). Їхнє розширення через підвищений на сьогодні попит треба обговорювати заздалегідь, але в більшості випадків вдається знайти рішення, яке задовольняє потреби бізнесу.

— Як щодо SLA та підтримки 24/7? 

— Перша та друга лінії підтримки в 99,9% випадків знаходиться на боці «Київстар». Клієнт звертається до свого менеджера, інженера або архітектора. Команда підтримки розподілена по всій країні. В окремих випадках ми погоджуємо та прописуємо з клієнтом severity (рівні критичності інцидентів): для низького рівня — це робочі години, для критичних інцидентів — це цілодобове реагування 24/7. Типові питання можна вирішити і через лінію підтримки.

— Чи є реальний Vendor Lock-in у разі використання Azure? Чи потрапляє клієнт у пастку? 

— За правильного та виваженого підходу вендор-локу немає. Якщо ви хоч трохи розумієте, що у вас працює і як, ви завжди зможете мігрувати.

Для розрахунку вартості існує Cloud Economics. Наприклад, у Microsoft є Azure Hybrid Use Benefit, що дозволяє економити за наявності раніше придбаних ліцензій.

Вендор-лок виникає тоді, коли вас підсадили на специфічний SaaS, який доступний виключно у одного з багатьох провайдерів або коли у вас є Legacy Line of Business Application. Якщо розробники щось кодували під MS-DOS у 90-х роках і все захардкодили, ви навіть з DOS не зможете безболісно мігрувати. Але в таких випадках можна використати різні підходи для забезпечення безперервності та відмовостійкості бізнесу — провести рефактор, виконати Re-Architect та замінити застаріли технології, або в деяких випадках Rehost чи Replatform з додаванням нової функціональності.

В цілому, на сьогодні, найбільш правильним виглядає наступний підхід — залишати частину експертизи в себе. Саме тому ми навчаємо всіх наших клієнтів (від ознайомчих матеріалів та сесій до сертифікованих курсів з лабораторними роботами на 3-5 днів — від адміна до архітектора рішень).

Крім того, для покращення сервісів «Київстар» розвиває партнерства з різними вендорами (наприклад, статус Select partner MSSP від Fortinet). Поєднання комплементарних рішень різних вендорів, таких як Microsoft чи Fortinet, дозволяє вирішувати складні клієнтські задачі (від розгортання окремої віртуальної машини до сервісів інформаційної безпеки) і оптимізуючи витрати, комбінувати сервіси без прив’язки до єдиного вендора.