Latest / M365.FM – подкаст про Microsoft 365, Copilot і ШІ українською / Корпоративний ШІ з Power Platform і Azure OpenAI: архітектура, безпека й управління поза межами демо-чат-бота (ШІ-дубляж)

Transcript

Корпоративний ШІ з Power Platform і Azure OpenAI: архітектура, безпека й управління поза межами демо-чат-бота (ШІ-дубляж) · M365.FM – подкаст про Microsoft 365, Copilot і ШІ українською

• 0:00
  Готові до 10-х днів Microsoft 365, Co-Pilot, She, Azure та людей, що формують майбутні роботи.
• 0:07
  У січні М365 кон повертається, і ми стаємо ще масштабнішими.
• 0:12
  Приєднуйтесь до нас на живі сесії, реальні демонстрації та практичні знання від MVP та експертів галузі з усього світу.
• 0:18
  Жодних загальних слайдів, жодних нескінчених модних слів.
• 0:22
  Ми беремося за реальні виклики Co-Pilot Studio, She-агенти, Fabric, безпека, управління та автоматизація.
• 0:29
  Незалежно від того, чи ви і те фахівець, розробник чи бізнес-лідер, для вас знайдуться спеціальні сесії.
• 0:35
  За 10 повних днів ви зможете дослідити різні технології та поспілкуватися з глобальною спільнотою.
• 0:40
  Дивіться наживо та приносте практичні ідеї у свою організацію.
• 0:44
  Січень 2027 року, 10 днів, одна спільнота Microsoft. Реєстрація вже відкрита.
• 0:52
  Забронюйте своє місце сьогодні.
• 0:54
  Це M365.con.net
• 0:59
  Приєднуйтесь зараз на M365.con.net і побачимось наживо у січні.
• 1:05
  Ви коли-небудь замислювалися, чому так багато демо-версійщів Pava Platform обмежуються чат-ботами
• 1:10
  і не приживаються в реальних бізнес-процесах?
• 1:13
  Це відео показує те, чого не показують інші, як насправді підключити Azure OpenAI до Pava Apps та Dynamics 365
• 1:19
  з урахуванням усіх вимог безпеки, продуктивності та управління для професійного впровадження.
• 1:25
  Якщо ви завжди хотіли менше магії та більше конкретики, ви в правильному місці.
• 1:29
  Поза межами коннектора, справжня анатомія шів Pava Platform завжди починається однаково.
• 1:35
  Бізнес-користувачі бачать круту демо-версію, можливо, чат-бот для продажів,
• 1:39
  що відповідає за секунди, або додаток для клієнтської підтримки, що магічно сортує тікети.
• 1:44
  І вони думають, чудово, додамо це прямо в Pava Apps.
• 1:47
  Коннектор на місці екрани оживають, і люди починають уявляти, як щі виконує їхню рутинну роботу.
• 1:52
  Але реальність настає швидко.
• 1:54
  Коннектор працює для двох людей під час демо, а потім, коли здається, що ви створюєте щось визначне,
• 1:59
  з'являються проблеми з продуктивністю, чат-боти починають верстіні-сенітниці
• 2:03
  або випадково витікають конфіденційні дані клієнтів.
• 2:06
  Саме тут більшість щі інтеграцій зупиняються.
• 2:09
  Всьому виною міф, що додавання щі до Pava Platform – це просто натиснути,
• 2:12
  плюс додати коннектор і зв'язати його зежур-опенай.
• 2:15
  Такий підхід закріплюється, бо на папері ці інструменти виглядають майже занадто простими.
• 2:19
  Якби ж тільки це було найскладнішою частиною.
• 2:21
  Отже, що насправді під капотом, коли ви хочете створити щось серйозніше, ніж іграшковий проєкт.
• 2:25
  Розуміння того, де насправді відбувається магія щі – це вирішальна різниця між марним демо та реальним запуском бізнес-процесу.
• 2:31
  Отже, майже в кожній серйозній системі щі на Pava Platform є чотири гравці.
• 2:35
  По-перше, це самі Pava Apps або Dynamics 365, з якими взаємодіють кінцеві користувачі
• 2:40
  і які є справжнім тригером для кожного запиту до щі.
• 2:43
  Вони збирають дані, можливо, повідомлення клієнта, результати опитування, відгук про продукт,
• 2:48
  будь-яку інформацію, яку ви хочете проаналізувати.
• 2:50
  Однак Pava Apps не спілкуються з Azure OpenAI напряму.
• 2:53
  Ось тут у гру вступає Pava Automate, що координує весь процес.
• 2:56
  Щоразу, коли користувач натискає кнопку або надсилає форму, потік Pava Automate підхоплює дані,
• 3:01
  надає їм потрібного формату і спрямовує за призначенням.
• 3:04
  Третій елемент – це кінцева точка Azure OpenAI.
• 3:07
  Це справжній інтелектуальний центр, що забезпечує аналіз тональності,
• 3:10
  підсумовування тексту або навіть генерування відповідей клієнтам.
• 3:14
  І тихо захований у стеку є Azure Arie Management, який несправедливо ігнорують, поки щось не вибухне.
• 3:20
  Це елемент безпеки та регулювання навантаження, різниця між стабільним потоком і перевантаженням системи.
• 3:25
  Розберімося, як ці фрагменти пазла взаємодіють між собою.
• 3:28
  Візьмемо тригер, наприклад, момент, коли користувач у Dynamics 365 реєструє дзвінок із продажу.
• 3:34
  Це запускає потік Pava Automate.
• 3:36
  Потік не просто переміщує дані з точки, а в будинок він може очистити текст, об'єднати контекст з інших джерел або приховати конфіденційні поля перед відправленням запиту до Azure OpenAi.
• 3:47
  Цей шлях має значення.
• 3:49
  Якщо потік працює повільно через те, що інша автоматизація споживає ресурси, у вашому застосунку виникне затримка.
• 3:56
  Якщо Pava Automate неправильно підготує дані, скажімо, відгук про продукт не матиме контексту або надійде з дивним форматуванням, кінцева точка опина й видасть нелогічні результати або, що гірше, почне галюцинувати.
• 4:08
  Отже, ніякого інтелекту не буде, якщо налаштування вище за течією зроблені не дбало.
• 4:12
  Зежур Arie Management ситуація стає ще цікавішою.
• 4:15
  Хоча всі захоплені можливостями щі, мало хто замислюється, хто повинен мати доступ і як часто.
• 4:21
  Arie Management діє як контролер на вході. Він перевіряє кожен запит, застосовує автентифікацію та гарантує, що використання не вийде з-під контролю.
• 4:29
  Якщо ви не налаштуєте політики обмеження запитів, один несправний застосунок може надсилати тисячі запитів на годину і миттєво перевантажити ваш екземпляр опинай або, що не менш, приємно, забезпечити космічний рахунок відежур.
• 4:40
  Він також фіксує, хто і що зробив, а це означає, що коли щось ламається або хтось порушує правила, ви маєте контрольний журнал.
• 4:47
  Демонстрації ніколи не показують цих проблем. У таких коротких оглядах усе оптимізовано для кількох користувачів та майже ідеальних мережевих умов.
• 4:55
  Але в реальному бізнесі є справжні угоди про рівень обслуговування SLA, питання приватності даних і порогові показники продуктивності, які неможливо ігнорувати.
• 5:02
  Наприклад, припустімо, ви запускаєте Pava App для зворотного зв'язку з продажу з вбудованим аналізом тональності.
• 5:07
  Якщо користувачів лише 10, потік працює гладко і ви отримуєте корисні результати менш ніж за секунду.
• 5:12
  Але в той день, коли це число стрибне до 10 тисяч, можливо, після імейл-кампанії чи злиття, ви почнете помічати 30-секундні очікування або помилки, бо кінцева точка не встигає обробляти запити.
• 5:21
  Гірше того, ви можете виявити, що половина даних відгуків раптом перестає оброблятися, бо розмір корисного навантаження перевищив ліміти Ежур, або ж політики безпеки Varie Management ніколи не були належно налаштовані.
• 5:32
  Тепер, замість того, щоб допомагати відділу продажів, ваш конвейер ЩІ блокує їхню роботу і служба підтримки не в захваті. Це і є момент істини.
• 5:40
  Підключення конектора – це лише запрошення на вечірку архітектури.
• 5:44
  Справжня подія – це розуміння того, як взаємодіють усі рівні та наскільки крихкими стають речі, коли ви намагаєтеся масштабуватися.
• 5:51
  Розуміння того, як Pava Apps запускає оркестрацію, як потоки обробляють і захищають дані, як кінцеві точки ЩІ інтерпретують їх і як Arie Management працює як запобіжник,
• 6:00
  Саме це відрізняє бота, що застряг у пісочниці від рішення, готового до корпоративного використання.
• 6:05
  Якщо ви розумієте лише конектор, ви завжди граєте в азартні ігри зі стабільністю та безпекою.
• 6:10
  Будь-хто може перетягнути новий щій демо в Pava Apps.
• 6:13
  Створення чогось, що витримає контакт із реальними користувачами та реальними даними, означає заглиблення в деталі, а не просто використання готових конекторів.
• 6:21
  Отже, коли запит змінюється з «Зроби», щоб це повторювало текст на «Дійсно виріши мою бізнес-проблему», інтелект має стати значно розумнішим.
• 6:28
  Ось як налаштовуються мізки для реального бізнес-результату.
• 6:32
  Налаштування щі для бізнесу, аналіз настроїв, узагальнення тощо.
• 6:36
  Якщо ви хоч раз працювали з Azure Openai U Pava Platform, ви, мабуть, помітили дещо дивне.
• 6:41
  Одна кінцева точка може виявити негативні настрої в реченні, узагальнити ланцюжок листів або створити опис нового продукту, іноді за один день, і все це за допомогою одного ще ящика.
• 6:53
  Але це не магія, і є причина, чому чимало проєктів руйнуються, щойно ви намагаєтеся зробити щось справді корисне.
• 6:59
  Люди часто припускають, що можна просто змінити промп, і справу зроблено.
• 7:02
  Яка реальність?
• 7:03
  Кожен бізнес-кейс потребує різного підходу, і саме тут ілюзія, підключи та працюй, руйнується.
• 7:09
  Давайте поговоримо про різницю між аналізом настроїв і генерацією тексту.
• 7:13
  Припустимо, ви хочете, щоб ваш додаток Dynamics 365 позначав скарги клієнтів.
• 7:17
  Аналіз настроїв – це очевидний перший варіант.
• 7:19
  Короткі вхідні дані, швидкі відповіді, низька вартість і майже жодного контексту, який потрібно відстежувати.
• 7:25
  І це працює, тому що Pava Otamite потрібно передати лише базові дані на кінцеву точку опеней речення або два разом із правильним промптом, що вказує моделі, на що звертати увагу.
• 7:34
  Ви можете швидко опрацювати десятки записів без ризику, що модель вийде з-під контролю або вичерпає ваш бюджет.
• 7:41
  Цими потоками легко керувати, їх просто регулювати, і вони майже ніколи не потребують переробки.
• 7:45
  Тепер перейдемо до створення підсумків, що вже вимагає серйозніших зусиль.
• 7:49
  Якщо ваш Pava App дозволяє менеджерам вставляти детальні нотатки з нарад і миттєво отримувати зрозумілі резюме,
• 7:56
  запит для опеней має бути чітко сформулюваним і витриманим у правильному тоні.
• 8:00
  Навіть у такому разі підсумки не завжди однаково якісні.
• 8:04
  Якщо обсяг даних за великий або вихідний текст не структурований,
• 8:08
  модель може почати перефразувати замість того, щоб узагальнювати або навіть вигадувати деталі, яких не було.
• 8:15
  Все зводиться до налаштування.
• 8:17
  Pava Otamite має структурувати дані, прибрати підписи, видалити форматування та, можливо, розбити документ на частини, якщо він занадто довгий.
• 8:23
  І це все ще до того, якщо і почне виконувати свою роботу.
• 8:25
  Але найскладніше – це повноцінна генерація тексту або класифікація у великих масштабах.
• 8:30
  Припустимо, ваш відділ продажів хоче створювати індивідуальні відповіді на листи на льоту,
• 8:35
  або служба підтримки потребує класифікації тікетів за типом проблеми.
• 8:38
  Більшість людей не розуміють, що запуск таких щі потоків для тисяч завдань зовсім не схожий на ідеальну демонстрацію.
• 8:44
  Потік Pava Otamite повинен обробляти величезні масиви даних.
• 8:48
  Кінцева точка OpenAi отримує шквал запитів, пропускна здатність падає,
• 8:52
  а рахунок Azure починає зростати іноді настільки швидко, що доводиться втручатися бухгалтерії.
• 8:59
  Головна пастка – це сприйняття цих щі процесів як взаємозамінних.
• 9:04
  Аналіз настроїв може коштувати мізерні частки цента за запит,
• 9:07
  але генерація довгих текстів підвищує складність моделі, споживає сотні токенів і потребує більше часу на відповідь.
• 9:14
  Додайте до цього потребу в індивідуальних інструкціях, різний тон чи формулювання для різних клієнтів,
• 9:20
  кожне коригування вимагає точного промпінженірингу.
• 9:23
  Люди чують термін промпінженіринг і думають, що це просто краще написані інструкції,
• 9:26
  але це більше схоже на налаштування пошукового алгоритму.
• 9:29
  Ви тестуєте, отримуєте дивні результати, а потім переробляєте.
• 9:32
  Кожна зміна впливає не лише на вихідний результат, а й на час, вартість та безпеку вашого робочого процесу.
• 9:38
  Це не просто теорія. Існує надто багато реальних прикладів, щоб їх ігнорувати.
• 9:43
  Одна компанія створила потік Pava Platform, який використовував опенай для сортування тікетів підтримки,
• 9:48
  класифікації за настроєм та пропонування готових відповідей.
• 9:52
  На етапі тестування все виглядало ідеально.
• 9:54
  Проблеми почалися, коли потік надали всім працівникам підтримки,
• 9:57
  і кінцева точка раптово почала отримувати запити на кожен тікет щохвилини.
• 10:02
  Модель була налаштована на загальну генерацію тексту, а не просто на просту класифікацію.
• 10:06
  Отже, він проаналізував усю історію тікетів і щоразу писав чернетки на кілька абзаців.
• 10:11
  Витрати стрімко зросли за ніч, робочі процеси сповільнилися,
• 10:14
  а ще почав вигадувати інформацію у своїх пропозиціях.
• 10:17
  Ніхто не зупинився, щоб запитати, навіщо для простого завдання сортування потрібен кінцевий пункт,
• 10:22
  налаштований на генерацію тексту, а не на коротку класифікацію.
• 10:25
  Знадобилися години розслідування, перш ніж хтось зрозумів,
• 10:28
  що кілька налаштувань у Pava Automate та конфігурація кінцевого пункту спричинили весь цей безлад.
• 10:33
  Якщо хочете контролювати процес, почніть зі встановлення квот на використання потоків Pava Automate
• 10:38
  та постійно відстежуйте кількість запитів і токенів через портал Azure.
• 10:42
  Для швидких завдань, як от класифікація чи аналіз тональності,
• 10:45
  налаштуйте паралельні потоки та використовуйте найменшу модель, яка справляється з роботою.
• 10:50
  Для створення довгих текстів обмежте максимальну кількість токенів
• 10:54
  і частоту звернення користувачів до цих функцій.
• 10:57
  Регулярно переглядайте журнали.
• 10:59
  Виявляйте сплески або збої, якомога раніше.
• 11:02
  Якщо ви пропустите ці кроки, платформа повідомить вас про це рахунком із запізненням,
• 11:06
  або ще гірше, користувачі відчують це через повільну роботу додатків.
• 11:09
  Отже, правильна конфігурація щі – це не лише про те, щоб рішення працювало.
• 11:13
  Це про те, щоб бізнес рухався вперед, витрати були передбачуваними, а результати – логічними.
• 11:18
  Неправильне налаштування за лічені хвилини перетворює щі з помічника на проблему.
• 11:22
  Тепер, коли ви впровадили інтелектуальні можливості у свої додатки,
• 11:25
  потрібно визначити, хто може ними користуватися
• 11:28
  і як захистити кінцеві пункти та дані в масштабах системи.
• 11:31
  Забезпечення безпеки потоку.
• 11:32
  Чому у Azure Arie Management ваш захисний щит?
• 11:35
  Ви могли помітити, що в більшості демо-версій щі для PAVA платформ безпеку
• 11:39
  сприймають як формальний пункт, який можна відзначити наприкінці.
• 11:42
  Але коли пілотні проєкти переходять від внутрішніх тестів до реального використання,
• 11:46
  швидко виникають нові ризики.
• 11:48
  Раптом цей кінцевий пункт OpenAi перестає просто відповідати на безневинні тестові запити.
• 11:53
  Він стає потенційним вікном до всього, що відкриває ваш додаток.
• 11:56
  Уявіть процес обслуговування клієнтів, що тихо передає дані через незахищений Arie або чат-бот,
• 12:02
  що працює на основі ключа, який передається відкрито.
• 12:05
  Кілька помилок можуть відкрити бізнес для несанкціонованого доступу,
• 12:09
  витоку даних або шквалу Arie запитів від сторонніх осіб.
• 12:13
  Це не гіпотетична загроза.
• 12:15
  Щойно ви підключаєте кінцеві пункти Azure OpenAi до Pava Apps або Dynamics 365,
• 12:19
  ви відкриваєте доступ до потужного інструменту.
• 12:21
  Якщо хтось сторонній отримає ваш Arie ключ, що може зберігатися в скрипті або тестовому потоці,
• 12:26
  він зможе надсилати запити, отримувати відповіді та накопичувати витрати.
• 12:29
  Дос-атаки стають реальною загрозою.
• 12:31
  Навіть без зловмисників неправильно налаштований додаток, що зациклюється на невірному записі,
• 12:36
  може безперервно перевантажувати ваш кінцевий пункт.
• 12:38
  В обох випадках ви отримуєте не лише головний біль із керуванням,
• 12:41
  а й потенційно неконтролювані витрати.
• 12:43
  І залежно від того, які дані передаються мережею,
• 12:45
  виникають реальні ризики порушення відповідності вимогам.
• 12:47
  Саме тут Azure Arie Management стає невідомим героєм.
• 12:51
  Більшість сприймає це як черговий ресурс Azure для налаштування,
• 12:54
  але насправді це межа між порядком і хаосом.
• 12:56
  Arie Management виконує функції, які не під силу Pava Otamite та самим конекторам.
• 13:01
  Він забезпечує автентифікацію та авторизацію кожного разу, коли надходить запит,
• 13:04
  а не лише тоді, коли ви не забули це запрограмувати.
• 13:07
  Він обмежує кількість запитів до вашої кінцевої точки,
• 13:09
  що означає, помилка розробника чи безконтрольний скрипт
• 13:12
  не загрожуватимуть вашому бюджету чи репутації.
• 13:15
  А ще він веде детальні журнали, створюючи слід,
• 13:17
  коли вам потрібно відповісти на запитання, хто до чого і коли звертався.
• 13:21
  Давайте поговоримо про реальний інцидент.
• 13:23
  Організація впровадила по TKI класифікації для клієнтських листів у Dynamics 365
• 13:28
  і передала ключ Arie у Pava Otamite.
• 13:30
  Ключ потрапив у спільну папку документації і завзятий,
• 13:33
  але ненавчений співробітник випадково створив рекурсивний цикл у своєму тестовому додатку.
• 13:38
  За лічені години тисячі викликів Arie спрямувалися до кінцевої точки опенай,
• 13:42
  багато з яких повторювали одні й ті самі записи.
• 13:44
  Рахунок Azure несподівано зріс, і лише після ретельного вивчення журналів
• 13:48
  команда зрозуміла, що сталося.
• 13:50
  Найгіршим був не сам рахунок, а невпевненість у тому,
• 13:53
  чи не потрапила конфіденційна інформація не в ті руки.
• 13:56
  Якби був Arie Management, цикл викликав би помилку обмеження швидкості задовго до того,
• 14:01
  як ситуація вийшла з-під контролю, а краще логування миттєво виявило б потік запитів.
• 14:06
  Політики Arie Management – це справжня система безпеки.
• 14:09
  Ви можете налаштувати ліміти швидкості, скажімо, максимальну кількість звернень за хвилину на користувача.
• 14:13
  Ви можете обмежити виклики за діапазоном IP, щоб дозволити лише запити, що надходять із відомих шлюзів Pava Platform.
• 14:20
  Для організацій із суворими правилами відповідності можна вимагати заголовки або токени,
• 14:25
  унікальні для вашого бізнес-процесу, що робить випадковий доступ зовніпомітним і легким для блокування.
• 14:31
  Усі ці засоби контролю створені не для того, щоб дратувати кінцевих користувачів,
• 14:35
  а щоб гарантувати, що стрімке розширення AI-додатка не зупинить вашу роботу або, що гірше, не скомпрометує дані клієнтів.
• 14:42
  Тут важливо знайти баланс. Політики безпеки мають бути достатньо суворими для запобігання зловживанням,
• 14:46
  але не повинні сповільнювати звичайні бізнес-процеси.
• 14:48
  Якщо обмеження тротлінг надто агресивні, правомірні запити починають зазнавати невдачі,
• 14:53
  і користувачі вдаються до обхідних шляхів, надсилаючи одні й ті самі дані знову і знову, поки вони не пройдуть.
• 14:58
  Саме тут критично важливими стають моніторинг та аналітика всередині ARRI Management.
• 15:02
  Ви бачите моделі використання з часом, виявляєте невдалі виклики та коригуєте політики ще до того, як користувачі це помітять.
• 15:10
  Отже, ви хочете, щоб усі у вашій компанії експериментували з функціями шів PowerApps та Dynamics 365,
• 15:16
  але вам потрібен захист, щоб убезпечити дані та запобігти неконтрольованим витратам.
• 15:20
  Коли керування ARRI бере на себе роль контролера, ви отримуєте більше, ніж просто захист.
• 15:24
  Ви можете реально відстежувати впровадження, бачити, які робочі процеси створюють цінність, а які даремно витрачають ресурси.
• 15:30
  Коли керівництво запитує, хто, що, коли і як, усі відповіді вже зафіксовані.
• 15:34
  Коли використання масштабується з п'яти людей у пілотному проєкті до тисяч користувачів у робочому додатку,
• 15:40
  керування ARRI гарантує, що ви не просто відкриваєте шлюзи, сподіваючись на краще.
• 15:44
  Ви спрямовуєте трафік передбачувано.
• 15:46
  Секрет у тому, що без належного керування кінцевими точками ще більшість готових до роботи інтеграції
• 15:52
  руйнується при першому ж непередбачуваному збої.
• 15:55
  Керування ARRI дозволяє перейти від ідеї до корпоративного масштабу без прихованих ризиків.
• 16:01
  Тож сприймайте це не як технічні комунікації, а як головні ворота.
• 16:04
  Звісно, навіть найкращий охоронець працює лише з тим, що йому дають.
• 16:08
  Захист кінцевих точок – це лише один бік медалі.
• 16:11
  Існує ширша картина відстеження використання, контроль бюджетів та дотримання правил відповідності.
• 16:16
  Коли додатки розвиваються або змінюються політики, саме тоді управління перестає бути необов'язковим і починає керувати всією системою.
• 16:24
  Управлінський клей – контроль витрат та нагляд за ЩІ.
• 16:27
  Якщо ви колись бачили, як Pava App за ніч перетворюється з другорядного проекту на улюблений інструмент кожного,
• 16:33
  ви, мабуть, відчули цей раптовий страх, коли витрати зростають, а ніхто не знає, хто має це контролювати.
• 16:39
  Легко святкувати успішний запуск ЩІ, аналіз настроїв працює, текстові зведення економлять години роботи,
• 16:47
  але врешті-решт хтось бачить рахунок Ежур або отримує повідомлення від відділу безпеки і всі замовкають.
• 16:55
  Це перша ознака прогалини в управлінні, яка проявляється майже завжди, коли додаток працює настільки добре, що люди продовжують ним користуватися.
• 17:02
  Цей шаблон майже універсальний.
• 17:04
  Функції ЩІ підключаються, точки доступу захищені, керівництво схвалює бізнес-кейс, потім з'являються реальні користувачі і все в середовищі стає значно складнішим.
• 17:15
  Хто контролює доступ до кінцевих точок – Ежур опенай.
• 17:18
  Скільки запитів надходить від кожного ПАВА-ЕП і чи всі вони взагалі потрібні?
• 17:23
  Де проходить межа між експериментами та автоматизацією, що спустошує бюджет?
• 17:27
  І оскільки все більше співробітників створюють або налаштовують власні автоматизації,
• 17:30
  контролювати те, що відбувається за лаштунками, стає важче з кожним тижнем.
• 17:34
  Неконтролювані витрати часто стають першим випробуванням для системи управління.
• 17:38
  Ежур веде точний підрахунок кожного токена, кожного виклику АРІ та кожного гігабайта даних,
• 17:42
  що проходять через кінцеві точки опенай, але якщо ніхто не відстежує ці цифри, витрати можуть непомітно зростати.
• 17:48
  Ви платите за використання, а контроль за ним втрачається,
• 17:51
  коли розробники-аматори щиро намагаються впроваджувати інновації,
• 17:55
  але не завжди знають, що їхній потік пава-отами звертається до кінцевої точки ще тисячу разів на день.
• 18:01
  Більшість людей дізнаються про це однаково, спрацьовує бюджетне сповіщення,
• 18:04
  або хтось у фінансовому відділі помічає помилку в рахунку.
• 18:08
  Ігнорування цього означає не лише більші витрати,
• 18:10
  ви ризикуєте тим, що проєкт закриють, щоб зупинити втрати,
• 18:13
  або, що гірше, керівництво втратить довіру до всього експерименту зіщі.
• 18:16
  Проте справа ніколи не лише в грошах.
• 18:18
  Далі виникають питання відповідності вимогам.
• 18:20
  Навіть із керуванням АРІ, що контролює вхід,
• 18:22
  залишаються питання щодо того, які дані надсилаються,
• 18:25
  як довго вони зберігаються та де можуть опинитися їхні копії.
• 18:28
  Чи приховав розробник персональні дані,
• 18:31
  перш ніж відправити текст запиту до служби підтримки вежур опенай?
• 18:35
  Чи існує запис того, хто і до чого отримав доступ,
• 18:38
  і чи відповідає це політикам вашої організації?
• 18:41
  Аудиторів не вражає відповідь «ми так думаємо».
• 18:44
  Для регульованих галузей одна помилка,
• 18:46
  наприклад, відправка конфіденційних даних
• 18:48
  для створення резюме без належної фільтрації
• 18:51
  може зупинити проєкти на тижні
• 18:53
  або створити компанії серйозні проблеми.
• 18:56
  Навіть у менш регульованих умовах IT-відділ нервує,
• 18:59
  якщо виглядає так, ніби неконтрольовані дані циркулюють у хмарі.
• 19:02
  Microsoft намагається полегшити життя в цих аспектах.
• 19:05
  Azure Cost Management надає вам інформаційні панелі,
• 19:08
  сповіщення та ліміти витрат.
• 19:09
  Однак все одно хтось має встановлювати порогові значення,
• 19:11
  відстежувати щотижневі піки використання
• 19:13
  та натискати паузу, перш ніж вони стануть критичними.
• 19:15
  Маркування кожного ресурсу, кінцевих точок ЩІ,
• 19:18
  потоків і навіть окремих PAWA-Apps –
• 19:20
  це простий, але потужний спосіб відстежити
• 19:22
  витрати кожної команди чи бізнес-напрямку.
• 19:24
  Це також допомагає з очищенням системи та звітуванням.
• 19:27
  Якщо автоматизація продовжує працювати
• 19:29
  після завершення пілотного проєкту,
• 19:30
  марковані ресурси виділяються,
• 19:32
  і ви уникаєте сценарію загадкового навантаження,
• 19:34
  який завжди виникає під час перевірки стану системи.
• 19:37
  З боку PAWA Platform –
• 19:38
  комплект Center of Excellence Data Kit –
• 19:41
  це максимально близьке рішення до командного центру ЩІ.
• 19:43
  Він сканує ваш клієнт на наявність усіх потоків,
• 19:46
  спеціальних конекторів, програм і ботів,
• 19:49
  створюючи інвентар, з яким можна працювати.
• 19:52
  IT-відділ може налаштувати аналітику використання,
• 19:55
  надсилати сповіщення про підозрілі шаблони
• 19:57
  та нагадувати розробникам-аматорам
• 19:59
  про внутрішні найкращі практики.
• 20:01
  Деякі організації використовують його
• 20:03
  для створення регулярних звітів щодо використання
• 20:05
  ARRI, інтенсивних потоків і навіть того,
• 20:07
  хто і що створює.
• 20:08
  Набір інструментів COU існує не лише для видимості.
• 20:11
  Він також надає шаблони для поетапного розгортання,
• 20:13
  ініціює перевірки для ризикованих додатків
• 20:16
  і може впроваджувати бізнес-політики,
• 20:18
  зупиняючи потоки, що виходять за межі нормативних вимог.
• 20:21
  Для швидкозростаючої організації
• 20:23
  з десятками досвідчених користувачів
• 20:24
  ці запобіжники не дають ситуації вийти з-під контролю.
• 20:27
  Варто зазначити, що проблеми з керуванням
• 20:29
  зазвичай з'являються після успіху.
• 20:31
  Візьмемо для прикладу додаток зі збору відгуків клієнтів,
• 20:34
  популярність якого зросла набагато швидше, ніж очікувалося.
• 20:36
  Використання подвоїлося за тиждень, а потім потроїлося.
• 20:39
  Протягом місяця витрати різко зросли.
• 20:41
  Рахунок Ежур змусив переглянути прогнози
• 20:43
  і виявилося, що цей самий додаток без дозволу
• 20:45
  передававав конфіденційні дані до кінцевої точки ЩІ.
• 20:48
  Довелося терміново застосовувати спеціальні скрипти та заплатки,
• 20:50
  але на той момент це вже був хаос.
• 20:52
  Процес центру компетенцій міг би завчасно виявити
• 20:54
  це зростання і змусити провести перевірку.
• 20:55
  Найкращі практики накопичуються швидко.
• 20:58
  Завжди маркуйте ресурси.
• 20:59
  Встановлюйте бюджети або м'які ліміти
• 21:01
  навіть для пілотних проєктів.
• 21:02
  Перевіряйте та аудитуйте доступ до кінцевих точок.
• 21:05
  Список тих, хто має доступ, змінюється разом
• 21:07
  із перестановками в командах і еволюцією ролей.
• 21:09
  Документуйте, які потоки і навіщо передають певні дані.
• 21:12
  Це не просто паперова робота заради самої роботи.
• 21:15
  Це означає, що хтось зможе через тижні чи місяці пояснити,
• 21:18
  як працює система і де проходять її межі.
• 21:20
  Важливо усвідомити, що керування – це не той випадок,
• 21:23
  коли можна налаштувати і забути.
• 21:24
  Моделі змінюються, бізнес-логіка трансформується,
• 21:26
  а правила конфіденційності постійно еволюціонують.
• 21:28
  Перевірки та оновлення мають бути регулярними.
• 21:31
  Надійне керування – це різниця між функцією,
• 21:34
  яка згасає під тиском і такою, що стабільно зростає, підтримуючи бізнес.
• 21:39
  А завдяки контролю керівники ІТ та бізнесу
• 21:41
  отримують впевненість для розширення експериментів та інновацій.