Від безперебійності до досвіду: AI‑запроваджений зсув у сучасній спостережуваності

У 2001 році IBM опублікувала автономний ІТ‑манифест. Бачення автономних обчислень розбило самоуправління на чотири стовпи: самооптимізацію, самовідновлення, самоналаштування та самозахист. Я працював у Microsoft, коли IBM представила це ІТ‑бачення. Ми відповіли, пропонуючи технологічні ідеї, такі як автономний дата‑центр, але зрештою це була мрія, що була значно випереджала свій час. Не існувало практичного способу втілити це бачення в реальність.

У своїх роках у Microsoft я працював у команді, що створювала Clippy. Хоча анімований помічник‑скріпка був сумнозвісно нав’язливим, ідея стояла твердо: комп’ютери мають активно допомагати людям у їхній роботі. У нас просто не було достатньої обчислювальної потужності та ШІ, щоб це стало можливим. 25 років потому ми нарешті це зробили.

Від рівня сервісу до рівня досвіду

Концепція спостережуваності не виникла в ІТ. У 1960 році угорсько‑американський інженер і математик Рудольф Е. Кальман ввів у вжиток термін «спостережуваність», щоб описати, наскільки добре систему можна виміряти за її виходами. Потім, у 2013 році, Twitter використав термін у серії блог‑постів, фактично заявивши, що старомодний моніторинг за допомогою всіх доступних комерційних готових інструментів був розроблений для іншої епохи технологій і не працює в архітектурах мікросервісного масштабу.

Уявіть це як лікар, який оглядає пацієнта. Він може виміряти пульс, виміряти артеріальний тиск і спостерігати інші зовнішні ознаки, щоб опосередковано оцінити внутрішнє здоров’я пацієнта. В ІТ нам потрібно робити те ж саме. Коли у пацієнта спостерігаються коливання пульсу, нам треба зрозуміти, чи це означає проблеми з ниркою чи печінкою. За масштабом і складністю операцій, з якими стикався Twitter ще 20 років тому (компанія обслуговувала лише 100 мільйонів користувачів у режимі реального часу), спостережуваність вимагала іншого інструментарію та підходу до моніторингу.

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

Коли ІТ отримує виклик у 4 години ранку, хтось має встати з ліжка і з’ясувати, чи проблема пов’язана з поганим сектором на жорсткому диску, чи з зловмисником, який намагається проникнути і завдати шкоди інфраструктурі. Насправді не важливо, який саме варіант: в кінцевому підсумку їхня робота — підтримувати роботу всіх систем. На щастя, для оцінки здоров’я додатків сьогодні ми можемо збирати всі доступні телеметричні дані: кожен мережевий пристрій, кожен додаток, тисячі готових інтеграцій, потік тикетів через JIRA або Atlassian та безліч інших сигналів.

Саме тут з’являються цілі рівня досвіду (XLO). Ви, напевно, чули про угоди про рівень сервісу (SLA) та цілі рівня сервісу (SLO), але XLO роблять наступний крок, вимірюючи, чи отримують ваші клієнти та співробітники бажаний рівень досвіду. Це про якість, а не лише про безперебійність. З технічної точки зору єдиний спосіб досягти XLO — мати видимість від мережевого інтерфейсу (NIC) до кінцевого пристрою користувача.

У жовтні минулого року AWS US‑EAST‑1 зламався. Catchpoint виявив проблему за 16 хвилин до того, як Amazon офіційно її підтвердив. Клієнти, які мали таку видимість, змогли реагувати ще до того, як їхні користувачі відчули наслідки перебою.

Обіцянка спостережуваності схожа на Смокі Беара: виявляти дим, перш ніж виникне пожежа. Якщо все зроблено правильно, спостережуваність дозволяє гасити степову пожежу, перш ніж вона перетвориться на великий вогонь, який знищить Палисейдс у Каліфорнії. Смокі — це система раннього попередження, яка може виявити навіть найменший дим, незалежно від того, звідки він надходить: проблема AWS, проблема Oracle, проблема GCP, проблема Microsoft Azure або щось не так у вашій інфраструктурі.

ШІ масштабує системи безпеки

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

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

Проте надзвичайно складні системи можуть отримувати тисячі сповіщень щодня. Панелі інструментів починають миготіти, і люди починають отримувати виклики. Перегляд усіх цих сповіщень не є ефективним використанням часу людей. Насправді Vectra оцінює, що організації отримують в середньому 2 992 сповіщення безпеки щодня, 63 % з яких залишаються без відповіді.

Інструменти ШІ можуть скоротити ці тисячі сповіщень на день до лише кількох десятків. Я пам’ятаю випадок, коли одна проблема на одному NIC на одній машині спричинила 2 000 пов’язаних сповіщень. Завдяки ШІ клієнт зміг виконати кореляцію сповіщень і швидше дійти до аналізу кореневої причини, який, у свою чергу, показав, що одна проблема в цей момент часу викликала червоне сповіщення у всьому дашборді компанії.

ШІ знову робить ІТ захоплюючим

Я взяв перерву після того, як Cisco придбала Splunk у 2023 році. Протягом наступних двох років я спостерігав, як мої друзі та колишні колеги заснували компанії, щоб використовувати ШІ способами, які ще п’ять років тому були неможливі. (Пам’ятайте, що якби ChatGPT був людською дитиною, йому було б три роки).

Командам ІТ потрібна допомога у виявленні диму до того, як спрацює сигнал тривоги, а не ще більше дашбордів, у які треба дивитися. Вони. У певному сенсі це та сама проблема, яку намагаються вирішити IBM, Twitter і навіть Microsoft з Clippy.

Ось чому я вирішив повернутися. Технологія нарешті досягла того рівня, коли ми можемо виконати початкову обіцянку спостережуваності та автономного ІТ.