От безотказности к опыту: переход к наблюдаемости, управляемой ИИ

В 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.

Это причина, по которой я решил вернуться. Технология наконец‑то достигла уровня, когда мы можем выполнить первоначальное обещание наблюдаемости и автономного ИТ.