В современном мире ИТ-инфраструктура является сердцем бизнеса. От её надёжности и быстроты реакции на инциденты зависит не только эффективность работы компании, но и её репутация на рынке. В России аналитики мало, приведу примеры с международного рынка. Согласно исследованию Gartner, средняя стоимость простоя ИТ-системы составляет около 5600 долларов США в минуту, что эквивалентно более 300 000 долларов США в час. Более того, IDC сообщает, что годовые потери мировых компаний от простоев и сбоев ИТ-систем могут достигать 1,7 триллиона долларов. Неплохая статья на тему оценки стоимости аварий тут.

Почему компании испытывают проблемы с управлением инцидентами?

  1. Фрагментированные системы мониторинга: использование разрозненных инструментов затрудняет целостное восприятие состояния инфраструктуры. Каждый отвечает за свой кусочек инфраструктуры. Работает авторизация, работает сеть, работают базы данных, а CRM не работает, потому как отвалился внешний сервис, который никто не мониторил. Или при крупных сквозных сбоях, все системы работают, а сервис нет. При фрагментации систем мониторинга и ответственности нет целостной картины.

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

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

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

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

Еще одна история оператора связи

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

2021 год, произошел отказ системы хранения данных в основном дата-центре. Причиной оказалась физическая поломка контроллера ввода-вывода из-за перегрева.

Проблемы в управлении инцидентом:

  • Несвоевременное обнаружение: системы мониторинга не сгенерировали своевременные алерты из-за не полного покрытия мониторингом ИТ-инфраструктуры. Мониторинг контроллера не был настроен.

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

  • Неэффективная эскалация: ответственные инженеры не получили уведомления из-за сбоя в системе оповещения, основанной на электронной почте.

  • Отсутствие автоматизации: процедуры переключения на резервные системы не были автоматизированы, что увеличило время простоя.

Последствия:

  • Время простоя: 6 часов.

  • Финансовые потери: более 670 тысяч евро в виде компенсаций клиентам.

  • Репутационные риски: потеря доверия ключевых клиентов и негативное освещение в местных СМИ.

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

Процесс управления инцидентами

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

1. Консолидация алертов в единой системе

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

2. Важность лейблов и связки с ресурсно-сервисной моделью

Использование лейблов и интеграция с ресурсно-сервисной моделью (РСМ) позволяет проводить дедупликацию, корреляцию и анализ влияния инцидентов на бизнес-процессы. Это помогает приоритизировать инциденты, направлять усилия на наиболее критичные области и понимать, какие сервисы затронуты. Такой подход активно используется в передовых компаниях для эффективного управления сложными системами.

3. Событие — это не всегда инцидент

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

4. Определение ответственных и гибкость в управлении алертами

Чёткое понимание, кто отвечает за каждый алерт, и возможность перевести его на другого сотрудника при необходимости — ключевые аспекты оперативного реагирования. Это предотвращает задержки в решении проблем и обеспечивает гибкость в распределении нагрузки внутри команды, учитывая человеческий фактор.

5. Жизненный цикл событий

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

6. Гарантия и своевременность доставки уведомлений

Своевременная доставка алертов ответственным лицам — критический фактор. Используйте каналы с гарантированной доставкой. Например, push-уведомления не являются гарантированным каналом, гарантия всего 60-75%, а вот SMS - являются. А механизмы эскалации обеспечивают процесс дополнительной гарантией, что ни один инцидент не останется без внимания. Регулярное тестирование системы уведомлений и мониторинг её компонентов помогают поддерживать высокий уровень надёжности.

7. Сервисный режим для плановых работ

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

8. Использование базы знаний и ИИ для решения инцидентов

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

9. Максимальная автоматизация процессов

Автоматизация всех возможных процессов снижает вероятность человеческих ошибок и ускоряет реакцию на инциденты. Это освобождает время специалистов для решения более сложных и нетривиальных задач. Внедрение автоматизации является основой современных практик DevOps и SRE, которые применяются ведущими компаниями Европы и Азии.

Заключение

Эффективное управление инцидентами — это не просто набор инструментов, а целостный подход, сочетающий технологии, процессы и культуру внутри команды. Без правильно организованных процессов мониторинга, уведомления и реагирования на инциденты компания рискует столкнуться с серьёзными последствиями — от финансовых потерь до потери доверия клиентов.

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

Приглашаем вас присоединиться к программе раннего доступа и протестировать наш бесплатный облачный сервис Monq OnCall.

За новостями продукта Monq следите на нашем Телеграм-канале

Комментарии (4)


  1. Schekotka
    09.10.2024 14:00

    Согласно исследованию Gartner, средняя стоимость простоя ИТ-системы составляет около 5600 долларов США в минуту, что эквивалентно более 300 000 долларов США в час.

    Не очень понял, в чем ценность этой цифры? Как можно усреднить убытки от падения Telegram и 1С для 5 бухгалтеров, например?


    1. NuGan Автор
      09.10.2024 14:00

      Никак нельзя. Стоимость аварии считается исходя из стоимости простоя того или иного сервиса в конкретный момент. 4 час недоступности 1С Бухгалтерии с 2:31 до 6:31 17 сентября 2024 года может стоит ноль рублей ноль копеек, а простой 15 минут 10ого октября в с 17:45 до 18:00 той же самой 1С может стоить десятки миллионов рублей. И все потому, что во втором случае система должна была посчитать заработную плату и отправить платежные ведомости в зарплатный день в банк, чего сделать не смогла и 500 человек не получили вовремя ЗП. А согласно ФЗ за несвоевременную выплату заработной платы работодатель выплачивает компенсацию в размере 0,08 процента от суммы задолженности за каждый день просрочки. С учетом 500 человек это где-то 100 тысяч рублей прямых платежей сотрудникам, 30 тысяч штрафа от ЮЛ, 10 тысяч штрафа руководителю, еще пару человек психанут и уволятся, а это еще может быть убытков на 200-300 тысяч на новый подбор, адаптацию и т.д. Итого 15 минут простоя 1С в высокий сезон может стоить более 500 тысяч рублей.

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


  1. event1
    09.10.2024 14:00

    Всё по фактам, но тут немножко сели в лужу конечно:

    Например, push-уведомления не являются гарантированным каналом, гарантия всего 60-75%, а вот SMS - являются

    SMS теряются, только в путь. На деле, сам канал не так важен. Важные уведомления надо посылать регулярно, пока адресат не подтвердит доставку.


    1. NuGan Автор
      09.10.2024 14:00

      Справедливости ради, через провайдера можно запросить отчет от доставке SMS. Но да, я согласен, пока не подтверждена доставка получателем, и важный инцидент висит в статусе Новый и не назначен ни на кого, надо продолжать оповещать по цепочке эскалации.