Прежде чем запускать исправление, нужно установить причину сбоя
CitiusCloud обслуживает ИТ-инфраструктуру предприятий, в том числе систем, для которых важны соблюдение требований и непрерывная работа. Приложения работают на разных платформах. Когда возникает неожиданный сбой, инженер сначала выясняет его причину и только затем выбирает команды для исправления. Даже при автоматическом выполнении команд этот разбор требует работы специалиста. [1]
Заранее заданный сценарий выполняет известные действия. Для нового сбоя сначала нужно понять, что сломалось, сопоставить его с прошлыми инцидентами и проверить, подходит ли найденное исправление для работающей системы. [1]
infraBOT объединяет анализ сбоя, согласование с инженером и автоматическое исправление
CitiusCloud добавила в infraBOT ИИ-агентов — программных помощников для анализа сбоев и подготовки исправлений — с помощью IBM watsonx Orchestrate. По открытым материалам, решение уже работает и общедоступно на Red Hat OpenShift Container Platform, платформе для запуска и управления приложениями. Его можно расширить на другие среды Kubernetes — системы управления контейнерными приложениями. [1]
Процесс начинается, когда система обнаруживает сбой и создаёт заявку. ИИ-агенты анализируют его с учётом сведений о прошлых инцидентах и предлагают исправление. Перед изменением рабочей системы инженер проверяет предложение. [1]
После одобрения infraBOT выполняет команды, готовит разбор причины сбоя (RCA) и сохраняет его в базе знаний. При следующем инциденте агенты могут обратиться к этому разбору и найденному решению. На странице продукта CitiusCloud показывает цепочку: сбой → заявка → одобрение человека → автоматическое исправление → разбор причины. [2]
Изменения в рабочих системах разрешает инженер
Агент может сам создать заявку
По материалам CitiusCloud, агент сам создаёт заявку со сведениями о сбое и предложенными командами. Инженер получает её для проверки и согласования; вручную запускать каждую такую заявку не требуется. [2]
Руководитель ИТ-инфраструктуры одобряет изменение
Исправление в рабочей системе запускается только после одобрения. Анализ и выполнение можно автоматизировать, а ответственность за разрешение изменения остаётся у человека. [2]
Права доступа и история действий встроены в продукт
По материалам продукта, infraBOT поддерживает несколько уровней согласования, права доступа по ролям и журнал действий. Данные и секреты — защищённые сведения для доступа к системам — можно хранить на стороне заказчика, под его управлением. Эти функции позволяют ограничить полномочия системы и проверить, что она сделала. [2]
В заявке сохраняются диагноз, согласование и результат
Express Computer описывает связь между заявкой, анализом сбоя, одобрением и разбором причины. По этой истории команда может восстановить, почему система выполнила конкретное действие. [1]
Решённые инциденты помогают разобраться со следующим сбоем
После исправления infraBOT добавляет разбор причины в базу знаний. При следующих сбоях агенты могут найти этот случай, изучить ход диагностики и использовать найденное решение, если оно подходит. [1]
Вместе с закрытой заявкой остаётся описание того, как команда решила проблему. Это позволяет вернуться к основаниям решения при новом сбое.
Процесс описан, но показатели для бизнеса не опубликованы
Express Computer описывает решение как работающее и общедоступное на Red Hat OpenShift, с возможностью расширения на платформы Kubernetes.
Для выполнения исправления, которое предложил агент, требуется одобрение инженера.
Каждое документированное решение можно использовать при разборе будущих сбоев.
Обнаружить → разобраться → предложить → согласовать → выполнить → сохранить опыт
Ниже — примеры, где можно применить этот подход. Это не описания внедрений у заказчиков CitiusCloud.
Уведомление о сбое → разбор → предложение исправления → одобрение инженера → исправление → разбор причины.
Событие на оборудовании → сбор сведений → предложение действия → одобрение руководителя → задание на работу → сохранение опыта.
Расхождение в данных → разбор → предложение решения → одобрение закупщика → действие в ERP, учётной системе компании → обновление правила.
Нарушение → проверка обстоятельств → предложение исправления → одобрение ответственного → подтверждение результата → история действий.
Каждое предложенное действие можно проверить и согласовать
Агент помогает выбрать способ исправления
Агент сопоставляет обстоятельства сбоя с прошлыми случаями и предлагает команды для исправления. Инженер оценивает, подходят ли они к текущей ситуации.
Одобренное предложение выполняет та же система
После одобрения infraBOT выполняет исправление. Инженеру не требуется вручную переносить предложенные команды в другой инструмент.
Каждое решение может помочь при следующем сбое
Разбор причины добавляют в базу знаний, и позже система может на него сослаться. Он остаётся доступным для дальнейшей работы.
Согласование — предусмотренный шаг процесса
Изменение рабочей системы требует отдельного разрешения, а работу до и после этого шага можно автоматизировать.
После исправления сбоя нужно сохранить основания и результат
ИИ анализирует сбой и предлагает команды. Инженер проверяет их и разрешает изменение рабочей системы; затем infraBOT выполняет исправление.
В описании CitiusCloud связаны все этапы работы с инцидентом: обнаружение, поиск причины, предложение, согласование, выполнение и сохранение разбора. Инженер видит предложение до изменения системы, а команда может вернуться к решённому случаю позднее.
Этот порядок можно рассмотреть и для других процессов. ИИ собирает сведения, изучает прошлые случаи и готовит действие. Квалифицированный специалист проверяет предложение и разрешает изменение. После выполнения в базе знаний сохраняются результат и основания решения.
Для пробного запуска стоит искать повторяющиеся проблемы, по которым команда уже сохраняет разборы. Нужно проверить, достаточно ли в них данных, чтобы предложить исправление и дать инженеру основания для согласования.
Шесть вопросов перед автоматизацией работы со сбоями
Какое событие надёжно сообщает системе, что возник сбой или нестандартная ситуация?
Какие прошлые инциденты, связи между системами, правила и рабочие записи нужно учитывать при разборе?
Какие шаги исправления можно выполнить автоматически после одобрения?
Кто имеет право разрешить действие, которое повлияет на рабочую систему?
Как сохранить решённый случай, чтобы использовать его при следующем сбое?
Можно ли восстановить, какие данные видел агент, что предложил, что выполнил и какой результат сохранил?
ИИ-агенты для работы с нестандартными ситуациями
Команда снова разбирает похожий сбой и каждый раз вручную ищет его причину?
Покажите нам один такой процесс: какие сведения нужны для поиска причины, кто разрешает исправление и что происходит после решения. Мы вместе разберём, как автоматизировать шаги, сохранить контроль над действиями и использовать опыт при следующих сбоях.
Это независимый разбор Maak.Digital о работе ИИ-агентов в infraBOT компании CitiusCloud Services. Он основан на статье Express Computer от 8 октября 2026 года и официальных материалах CitiusCloud об infraBOT и практике применения ИИ. Maak.Digital не участвовала во внедрении. Открытые источники подтверждают последовательность: обнаружение сбоя, заявка, анализ, одобрение человеком, исправление и сохранение разбора причины в базе знаний. В них нет показателей конкретных заказчиков по времени устранения сбоев, простоям, числу инцидентов или окупаемости. Здесь такие результаты не предполагаются.