Объем данных и информационного шума, сопутствующий сложности корпоративных ИТ-систем, затрудняет операционным командам определение приоритетов проблем и повышение надежности. Некоторые моменты упускаются из виду, команды вынуждены постоянно работать в режиме экстренной сортировки задач, а по мере расширения среды управление системами становится все более сложным.
Модели, обученные на телеметрических данных инфраструктуры, могут распознавать закономерности в метриках, журналах и событиях. В сочетании с большими языковыми моделями (LLM) они могут раньше обнаруживать необычное поведение и объяснять, что происходит, помогая операционным командам быстро определять, что изменилось и где следует проводить расследование.
По мере того как рабочие нагрузки ИИ увеличивают объем инфраструктуры, которую должны обслуживать организации, системные администраторы, команды DevOps и инженеры по надежности сайтов (SRE) с трудом связывают сигналы между разрозненными данными, рабочими процессами и инструментами. Существует слишком много взаимосвязанных и чувствительных ко времени переменных — включая гибридные и мультиоблачные метрики, метрики ЦП, памяти, сети и дискового ввода-вывода — для того, чтобы традиционные инструменты мониторинга и наблюдаемости могли их быстро интерпретировать. Результатом становится перенасыщение оповещениями, замедление устранения неполадок и растущее давление на команды, отвечающие за поддержание работоспособности систем.
Модели временных рядов, обученные на телеметрических данных инфраструктуры, могут распознавать закономерности в метриках, журналах и событиях. Они позволяют командам, отвечающим за корпоративную инфраструктуру, перейти от реактивного к проактивному подходу, выявляя уязвимости в стеке, которые могут привести к полному сбою. Это открывает возможность перехода к более значимым, чувствительным ко времени и контекстуальным оповещениям, а также к автономному, самовосстанавливающемуся и прогнозирующему обслуживанию.
«Предприятия действительно стремятся к более проактивным подходам, чтобы иметь возможность выявлять особо критические проблемы на уровне симптомов и устранять их до того, как произойдет сбой».
Фанидар Коганти, старший выдающийся технолог в области гибридного облака Hewlett Packard Enterprise (HPE), говорит: «Предприятия действительно стремятся перейти к более проактивным подходам, чтобы начать выявлять особо критические проблемы на уровне симптомов и устранять их до того, как произойдет сбой».
Коганти и только что опубликованный белый документ HPE «Beyond the Noise: Toward a Self-Healing Autonomous IT» исследуют эти проблемы и потенциал стратегии самовосстановления для высокопроизводительных вычислительных сред, основанных на базовой модели временных рядов, оптимизированной для ИТ (IT-TSFM).
Готовы ли предприятия к AIOps? Они определенно будут готовы, если эта технология позволит устранять риски до возникновения сбоев.
Дорогостоящий риск неизвестного
Хотя цифры варьируются, по оценкам, сбой обходится как минимум в 4000 долларов в минуту — для предприятий из разных секторов эта стоимость может быть гораздо выше.
Но не только масштабные сбои обходятся организациям дорого. Частичное, незаметное ухудшение качества работы может привести к еще более высоким затратам в целом. И эти затраты накапливаются со временем, поскольку такие проблемы, как правило, сложнее обнаружить и на их устранение уходит больше времени.
Как отмечает dTelecom, полный отказ систем — явление редкое: «Реальные затраты связаны с неопределенностью. Во время инцидентов команды тратят от 20 до 40 % времени просто на то, чтобы выяснить, кто пострадал — какие пользователи, какие регионы, какие сервисы, какие пути передачи данных».
Традиционные панели мониторинга и наблюдаемости показывают смесь этих неизвестных сбоев, некоторых известных сбоев и большого количества ложных тревог. Но именно неизвестные неизвестные или «серые сбои» не дают спать Коганти.
«Эти незаметные сбои обычно ускользают от человеческого глаза, и если на следующий день эти проблемы приводят к сбою, это напрямую влияет на бизнес». Он далее объясняет, что они, как правило, являются результатом взаимосвязанности распределенных зависимостей, которые масштабируются вместе с размером вашего предприятия и объемом используемого программного обеспечения.
«Серый сбой» — это не то, что обязательно приведет к сбою ваших систем сегодня, но он, возможно, уже замедляет их работу или обходится вам в дополнительные расходы. Кроме того, он повышает риск того, что завтра все рухнет.
Так как же ваши операционные команды могут их обнаружить? Как они могут оценить, устранить или даже исправить их все в масштабе?
Специфика, необходимая для серых сбоев
Общие модели временных рядов не могут обнаруживать эти «серые» сбои, поскольку они не обучены нюансам ИТ или специфическим особенностям инфраструктуры каждого предприятия. Как объясняется в техническом документе, общие модели неспособны понимать нюансы сезонного поведения и взаимозависимое поведение, характерное для ИТ-сред.
Вот несколько примеров из сферы ИТ:
- Всплеск нагрузки на ЦП в 21:00 может быть нормальным запланированным резервным копированием или аномальной распределенной атакой типа «отказ в обслуживании» (DDoS).
- Увеличение скорости вращения вентилятора внутри сервера является ожидаемым поведением, но если оно происходит без соответствующего повышения температуры, это становится аномалией.
«Даже на наших ноутбуках запущено так много приложений, и некоторые из них написаны некачественно. Будут небольшие сбои из-за утечки памяти», — приводит Коганти еще один распространенный пример. «Они происходят настолько медленно, что при повседневном использовании вы не заметите их, пока они не достигнут определенного порога».
Это может вызвать раздражение из-за медленной работы, а затем проект или весь ноутбук внезапно зависнет без сохранения данных.
«Устранение неполадок не обязательно должно быть очень сложным», — продолжает он. Для этого может быть достаточно простой перезагрузки, «потому что основной целью является обеспечение непрерывности бизнеса. Устранение неполадок отличается от постоянного исправления проблемы». Обычно это дает вам время, чтобы найти постоянное решение.
В корпоративной среде примеры быстро становятся все более взаимосвязанными и сложными.
Коганти приводит пример розничных организаций, которым необходимо отслеживать любые аномалии в поведении, возникающие в течение дня, а затем устранять их после закрытия магазина, чтобы, опять же, обеспечить непрерывность бизнеса.
В настоящее время операторы-люди, как правило, устанавливают общие пороговые значения: например, если загрузка ЦП превышает 90%, вызывают дежурного специалиста. Но Коганти отмечает, что загрузка ЦП в пределах от 80 до 90% в будний день является нормальной, тогда как загрузка в пределах от 70 до 80% в выходные дни — аномалия. Если, конечно, речь не идет о сайте электронной коммерции в декабре, когда может потребоваться выделение большего объема ЦП на весь месяц.
Эта сезонность имеет ключевое значение.
Цель базовой модели временных рядов, оптимизированной для ИТ (IT-TSFM), объясняет Коганти, заключается в установке адаптивных пороговых значений, чтобы «попытаться выявить «серые» сбои на уровне симптомов путем тщательного анализа того, что происходило в течение всего дня, или даже недели или месяца, с целью определения наличия медленных, незаметных сбоев, которые потенциально могут привести к отключению на следующий день».
Если — или, скорее всего, когда — это произойдет, речь пойдет не только об устранении проблемы и ее окончательном исправлении, но и о оповещении операционной команды. Среди типичных проблем, которые будет выявлять эта новая модель, можно назвать следующие:
- «Зомби-сервисы»
- Ухудшение пользовательского опыта
- Конфликт между двумя ресурсами, т. е. высокое время ожидания дискового ввода-вывода + нормальная загрузка ЦП
- Проблемы безопасности
- Проблемы с задержками
Постоянно меняющиеся паттерны временных рядов данных и сложность современной корпоративной инфраструктуры делают практически невозможным для человека их обнаружение и реагирование на них — особенно в условиях нынешнего роста сложности, вызванного повсеместным внедрением ИИ.
Заменит ли ИИ SRE?
Со временем эти базовые модели временных рядов, специфичные для ИТ, смогут понять уникальные паттерны вашей инфраструктуры и начнут предлагать решения или даже автоматически устранять некоторые из этих скрытых сбоев. В конечном итоге предприятия смогут перейти к проактивным ИТ-средам с функцией самовосстановления.
Но, как и во всех других аспектах ИИ в жизненном цикле разработки программного обеспечения, операторы-люди по-прежнему необходимы. Это должно позволить им управлять процессом устранения уязвимостей более комплексно, одновременно выявляя более сложные проблемы на более ранних этапах.
«Допустим, человек сообщает системе: на этой неделе я только что установил совершенно новое приложение, и я хочу, чтобы ты рассматривала это поведение как нормальное, а любые отклонения, которые ты увидишь по различным метрикам, постарайся проактивно проанализировать и предупредить меня, если заметишь серьезное отклонение», — говорит Коганти.
Поскольку это новое приложение, необходимо выявлять даже небольшие отклонения, «чтобы обнаруживать проблемы на системном уровне до того, как произойдет сбой».
Как следует из названия, эта специфическая для ИТ модель временных рядов предназначена для размещения поверх базы знаний корпоративной ИТ-инфраструктуры в качестве фундамента для крупных языковых и логических моделей, а в дальнейшем — для агентного ИИ.
Вероятно, это будет развиваться одновременно с возможностями проактивного и автономного устранения неполадок.
Эта базовая модель временных рядов для ИТ была разработана в сотрудничестве с HPE Labs и выпускается в рамках празднования 60-летия передовых достижений компании в области вычислений.
Ознакомьтесь с инновационной технологией, лежащей в основе базовой модели временных рядов, оптимизированной для ИТ, и прочитайте технический документ «Beyond the Noise: Toward a Self-Healing Autonomous IT» (За пределами шума: к самовосстанавливающейся автономной ИТ).
Подписывайтесь на наш канал в Телеграм
⚡ Подписаться