Обзор лучших систем управления инцидентами

Инциденты случаются в любом бизнесе. И его стабильность и способность к долгосрочному развитию напрямую зависят от реакции на такие ситуации. Поэтому системы реагирования на внештатные ситуации - это важная инвестиция в будущее компании. В этом тексте расскажем о существующих на рынке решениях и кастомной системе, созданной для клиента Evrone.

Под инцидентом подразумевают любое событие или ситуацию, которые нарушают нормальную работу системы, услуги или процесса, либо могут потенциально привести к такому нарушению. Инциденты могут возникать в различных контекстах, например, в информационных технологиях, промышленности, безопасности или здравоохранении.

Система управления инцидентами (Incident Management System, IMS) — это инструмент или набор процессов, предназначенных для выявления, регистрации, анализа, устранения и предотвращения инцидентов в организации. 

Почему важна работа с инцидентами?

Сбои в системах, ошибки в процессах или угрозы безопасности, могут привести к значительным потерям времени, ресурсов и репутации. Пренебрежение ими часто оборачивается повторением тех же проблем, увеличением затрат и снижением качества услуг. Систематический подход к инцидент-менеджменту позволяет не только минимизировать последствия, но и извлекать уроки из каждой ситуации, укрепляя устойчивость компании. Кроме того, управление инцидентами помогает соблюдать нормативные требования, оптимизировать использование ресурсов и улучшать коммуникацию между командами. Вот основные преимущества, которыми обладают централизованные системы управления уязвимостями:

• Снижение времени простоя

Быстрое реагирование и устранение инцидентов минимизирует простой систем и услуг.

• Повышение качества услуг

Систематический подход к управлению инцидентами улучшает стабильность и надежность процессов.

• Соблюдение нормативных требований

В некоторых отраслях управление инцидентами является обязательным для соблюдения стандартов (например, ISO 27001, ITIL).

• Оптимизация ресурсов

Позволяет эффективно распределять ресурсы для решения проблем.

• Улучшение коммуникации

Центральная система упрощает обмен информацией между командами и заинтересованными сторонами.

• Обучение и развитие

Анализ прошлых инцидентов помогает учиться на ошибках и улучшать внутренние процессы.

Какие функции обязательно должны быть у программы для управления инцидентами

Система управления инцидентами должна обладать набором функций, которые обеспечивают полный цикл обработки инцидентов — от их обнаружения до разрешения и анализа. Вот основные функции:

Регистрация инцидентов

Обычно включает фиксацию данных об инциденте: описание проблемы, время, место, затронутые системы или процессы. Вводить эти данные можно вручную по шаблону, что увеличивает время реагирования, или подключить автоматическую регистрацию, чтобы фиксировать инциденты из других систем, например, мониторинговых инструментов.

Классификация и приоритизация

Для правильной реакции ситуации нужно классифицировать по категории. Это может быть сбой оборудования, ошибка ПО, нарушение безопасности. После этого событию присваивают приоритет на основании влияния и срочности. Для упрощения поиска и фильтрации инцидентов полезна система тегов.

Назначение и эскалация

Возможность быстро назначать инцидент на соответствующую команду или специалиста ускоряет его решение. При этом важно предусмотреть эскалацию или автоматический перевод инцидента на более высокий уровень в случае отсутствия реакции или невозможности решения. Для группы реагирования важно распределение ролей, чтобы все, кто вовлечен в решение проблемы, знали свою зону влияния и ответственности.

Реагирование и устранение

В системе должна быть возможность отслеживать прогресс устранения инцидента, например, через контроль выполнения задач ответственными сотрудниками. Для взаимодействия между участниками стоит предусмотреть чаты и real-time уведомления внутри системы, чтобы впоследствии можно было просмотреть историю. Для типичных инцидентов можно разработать пошаговые инструкции, то есть встроенные руководства или базы знаний для решения привычных и хорошо изученных проблем. 

Мониторинг и уведомления

Система оповещения нужна для уведомления о новых инцидентах или изменении их статуса. При этом, ее можно реализовать через email, мессенджеры или SMS. Получать данные о проблемах в реальном времени можно через интеграцию с системами мониторинга.  Плюс, важно иметь панель управления или dashboard для отслеживания текущих и завершенных инцидентов внутри системы. 

Анализ и отчётность

Для аналитики нужно сохранить историю инцидентов, а для упрощения работы с этими данными полезна функция генерации отчетов по количеству, типам, времени решения инцидентов и другим показателям. На продвинутом уровне добавляют инструменты для выявления причин инцидентов и предотвращения их повторения (RCA).

Интеграция и масштабируемость

Для процесса автоматизации инцидентов важна адаптация под нужды растущего бизнеса. Также нужна интеграция с другими системами, например, с ITSM-платформами, CRM, ERP, мониторинговыми системами.

Автоматизация процессов

На основе типа инцидента или других критериев можно настроить автоматическое назначение задач, шаблоны действий для типовых инцидентов и сценарии устранения для быстрого реагирования. Например, перезапуск серверов.

Управление доступом и безопасность

В целях конфиденциальности стоит ограничить доступ к информации на основе ролей пользователей и их месте в команде реагирования. Для аудита стоит ввести логирование действий или запись всех действий пользователей в системе.

Мобильный доступ

Необязательная, но очень удобная функция, особенно, для распределенных команд. Для реакции в нерабочее время стоит предусмотреть приложения или адаптивный интерфейс для управления инцидентами с мобильных устройств. И, конечно, систему уведомлений, чтобы быстро оповестить дежурных сотрудников о проблеме.

Не ждите, пока проблемы начнут угрожать вашему бизнесу! Выберите подходящую систему управления инцидентами, чтобы обеспечить стабильность, оперативность и прозрачность в работе вашей компании.

Сравнение существующих решений для мониторинга и управления инцидентами

На рынке представлено множество IMS (Incident Management Systems), которые различаются функционалом, масштабируемостью, стоимостью и уровнем поддержки. Среди них есть как международные лидеры, так и российские решения, адаптированные под местные реалии. В таблице ниже сравним самые популярные российские и зарубежные решения по функциям, доступности техподдержки и стоимости.

Международные решения, такие как ServiceNow и BMC Remedy, предлагают более широкий спектр функций, подходящих для крупных организаций. Российские системы (Naumen, 1C:ITIL) более ориентированы на стандартные потребности и интеграцию с локальными платформами. Также российские решения обеспечивают поддержку на русском языке, что удобно для локальных компаний. Международные системы предоставляют глобальную поддержку, но чаще на английском. Кроме того, они значительно дороже и подходят для крупных предприятий. Российские аналоги предлагают более доступные варианты, особенно для малого и среднего бизнеса.

Разработка системы управления уязвимостями на заказ

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

Об особенностях разработки индивидуального решения расскажем на примере проекта, который Evrone выполнил для одного из своих клиентов. Это крупная российская технологическая компания, которую мы не будем называть. Концепция этой системы управления рисками и уязвимостями полностью разработана клиентом, наши разработчики помогли реализовать идею.

Общая информация 

Базу знаний клиент собрал давно, и первая версия платформы была реализована через Jira, но со временем ее возможностей стало не хватать. В новой системе менеджеры могут заводить инциденты, автоматически вызывать участников через разные каналы связи, вести лог инцидентов, проверять гипотезы и собирать отчеты для разбора после ликвидации. Платформа агрегирует метрики сервисов, дежурных, отображает работы, которые проводились в течении последних 12 часов и могли повлиять на возникновение инцидента, а также отмечает затронутые сбоем сценарии пользовательского пути. Кроме графиков есть трейсеры, логи и система их хранения. 

В компании есть система сбора телеметрии всех сервисов. Для каждого установлены значения, при которых автоматически создается предупреждение о возможном сбое. Работает служба круглосуточных дежурных которые отвечают за сервисы, чтобы в случае инцидента всегда было, кому дозвониться. Задачей нового сервиса было собрать все процессы и данные по управлению инцидентами в одном месте.

Компоненты и стек

Система менеджмента сбоев состоит из следующих модулей:

• Core-сервис, который управляет инцидентами и агрегирует всю информацию по ним.
• Сервис планирования работ, где как в календаре, отмечают будущие манипуляции, которые потенциально могут стать источником проблем.
• Platform Event Log — сервис-агрегатор событий от платформы, который показывает инцидент-менеджеру, какие сервисы деплоились или откатывались в момент сбоя.
• Легаси-сервис для управления дежурствами, откуда берется информация о дежурных, чтобы призывать их в инциденты.

Основной язык — Go, только сервис дежурств был реализован на Python. Календарь работ мы полностью переработали, чтобы он корректно работал в новом кластере. Взаимодействие между всеми компонентами идет по кастомному протоколу.

Базы данных

В легаси-сервисах используется PostgreSQL, но для core-сервиса нужно было что-то более гибкое и простое в масштабировании. Сама структура домена и количество данных в инциденте иерархичны: инцидент, дежурный, участники, аттачменты, тред в мессенджере. Все это хорошо ложится на модель, принятую в MongoDB, поэтому мы сделали выбор в пользу этой базы данных. 

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

Траблшутинг

Система управления инцидентов располагает огромной базой знаний, на основе которых инцидент-менеджеры могут принимать решения. Для удобного доступа к этим данным мы строим систему траблшутинга, которая дает менеджеру подсказки. Например, если какой-то сервис стал тормозить, появится предупреждение. Одновременно появится уведомление, что, например, в базе данных много зависших транзакций. Это подсказка, которая потенциально поможет инцидент-менеджеру справиться с проблемой. Задача — научить систему определять, какая информация может быть полезна и важна, и не перегрузить человека ненужными данными. В качестве подсказок могут быть текущие метрики, логи инцидентов и теоретическая информация из базы знаний. Главное — помочь менеджеру в принятии решений, но не сделать это за него. 

Автоматизация

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

Вместе с тем проект для большей безопасности разделяют на микросервисы. В отдельный микросервис мы вынесли авторизацию, она отвечает за допуск и отслеживание действий пользователей. Микросервис получает данные из центральной системы управления пользователями, выдает токены и отправляет обратно данные о том, какие действия пользователь совершил. Одинаковые действия разных пользователей могут приводить к разному результату, это зависит от роли в иерархии инцидента. 

Авторизация — это первый шаг к автономии системы управления инцидентами. Пока сервис работает на ресурсах всей экосистемы, в случае масштабных сбоев он тоже деградирует. Чтобы этого не произошло, и была возможность управлять такими большими и опасными инцидентами, мы реализуем нестандартный для клиента сценарий автономного сервиса. 

Разработчики Evrone продолжают работу на проекте и вместе с командой клиента развивают и масштабируют систему управления инцидентами. Мы с нуля создали для нее кодовую базу и запустили в прод, она активно используется в бизнес-процессах компании. На этом примере видно, что иногда заказная разработка — лучшее решение, ведь ни одна существующая платформа не может предложить такие возможности. Сторонние решения несут свои риски и обязательства. Например, Atlassian прекратил поддержку Jira в России. Поэтому собственные разработки выбирают компании, которым особенно важна безопасность.

Заключение

Рынок предлагает множество решений, которые помогут структурировать процесс Vulnerability Management и практику управления инцидентами. Готовые решения из коробки могут быть отличным вариантом для компаний с типичными процессами, можно подобрать вариант, который соответствует как целям, так и бюджету. Кастомные системы подходят компаниям, которым важна максимальная адаптация под их потребности, безопасность и независимость. Однако выбор между готовым решением и кастомной разработкой зависит от баланса между бюджетом, сроками и требованиями бизнеса.