За межами простого моніторингу: існує кращий спосіб визначення «норми» в складній інфраструктурі

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

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

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

Відкриття нової норми

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

Розгляньте виробничий завод, де трафік раптом збільшується о 14:00 у вівторок. Традиційний моніторинг може сповістити про це, оскільки воно перевищує попередньо встановлений поріг, але це насправді проблема? Не існує способу знати це без глибших даних та діагностичних засобів. Раптове збільшення може свідчити про легітимну бізнес-діяльність, таку як новий графік зміни або збільшення виробництва для виконання терміну, або це може сигналізувати про серйозну загрозу безпеки, таку як викрадення даних або компрометовані системи, які сигналізують до командних та контрольних серверів.

Саме тут виявлення аномалій, кероване ІІ підвищує інтелект моніторингу інфраструктури. Цей новий метод безперервно аналізує історичні дані для створення інтелектуальних базових рівнів, які автоматично коригуються згідно з змінними умовами. Цей підхід дозволяє здійснювати більш проактивне сповіщення, яке надає додатковий час адміністраторам ІТ та командам DevOps для вирішення проблеми до того, як вона призведе до серйозних наслідків.

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

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

Відмовлення від дублікатів сповіщень

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

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

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

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

Майбутнє інтелектуального моніторингу

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

Промислові сенсори ІІ, шлюзи краю та пристрої ОТ зараз спілкуються поряд із стандартними протоколами ІТ. Коли ці різноманітні системи зустрічають проблеми, адміністраторам потрібен моніторинг, який може зрозуміти взаємозв’язки по всьому екосистемі, а не розглядати кожну систему окремо. Бдительность є непоговорним, оскільки успішний прорив може зупинити виробничі лінії, пошкодити дороге обладнання та створити ризики для безпеки. Насправді, не планова простійка зараз коштує компаніям Fortune Global 500 11% їхнього річного доходу, підкреслюючи, що вартість інтелектуального моніторингу значно нижча, ніж витрати на ручне налагодження та втрачену продуктивність.

Тим часом немає виходу з того, що хакери на іншій стороні кібербезпеки використовують цю технологію як прорив продуктивності для атак у масштабі. Безкоштовні або дешеві генеративні моделі великих мовних моделей (ЛЛМ) дозволяють хакерам генерувати та модифікувати атаки за мінімальну вартість. І з часом зрозуміло, що зловмисники все частіше бачать ІІ як прорив. Сьогодні 7 з 10 вважають, що технологія та її різні інструменти підвищують khảсті хакінгу, у порівнянні з лише двома з 10 у 2023 році.

Сучасні алгоритми виявлення аномалій засновані на математиці та статистиці, які були добре встановлені протягом десятиліть. Ця технологія працює, але появу та застосування ІІ та ЛЛМ до моніторингу метрик є проривом. Ми бачимо деякі з перших часових моделей ЛЛМ, які з’являються на ринку, і можемо очікувати, що це перетворить виявлення аномалій протягом наступних двох років. Деякі з цих нових моделей демонструють відмінну точність та вдосконалення.

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