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

Что такое реагирование на инциденты?

Инцидент — это событие (выход из строя сети, отказ системы, утечка данных и т.д.), которое может привести к потере или нарушению работы, услуг или функций организации. Реагирование на инцидент — это усилия организации по обнаружению, анализу и устранению опасностей, возникших в результате инцидента. В наиболее распространенных случаях, когда упоминается реагирование на инциденты, оно обычно относится к инцидентам безопасности. Иногда понятия “реагирование на инциденты” и “управление инцидентами” используются как взаимозаменяемые.

Однако инцидент может быть любого характера, он не обязательно должен быть связан с безопасностью, например:

• физическое повреждение оборудования или систем (пожар, наводнение)
• человеческая ошибка (неправильная конфигурация, случайное удаление данных)
• злоумышленники (атаки типа “отказ в обслуживании”, вредоносное ПО, ransomware).

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

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

Традиционное и современное реагирование на инциденты

Самым большим изменением в мире реагирования на инциденты стало повсеместное внедрение автоматизации.

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

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

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

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

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

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

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

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

В сфере SRE (Site Reliability Engineering) реагирование на инцидент можно разделить на следующие этапы:

1. Выявление
2. Реагирование
3. Разрешение и восстановление
4. Вскрытие

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

Выявление

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

Традиционный

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

Современный

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

Реагирование

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

Традиционный

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

Современный

Современные команды анализируют метрики и журналы, чтобы определить, насколько серьезен перебой в работе. Это кратковременный всплеск ошибок? Сколько узлов выходят из строя? Или это полный перерыв в обслуживании? На этом этапе необходимо проанализировать метрики и журналы, прежде чем приступать к дальнейшим действиям. Именно здесь ваши коллеги из других секторов могут обратиться за помощью. Использование современных инструментов ChatOps, таких как Slack, Microsoft Teams, способствует эффективному сотрудничеству. Они позволяют поддерживать связь с нужными людьми даже в глобальном масштабе, если это необходимо.

Решение и восстановление

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

Традиционный

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

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

Современный

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

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

Postmortems

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

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

Традиционный

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

Оба ограничения затрудняли обмен подробной информацией о том, что произошло и почему это произошло. Традиционные вскрытия — это, как правило, тактические документы, в которых основное внимание уделяется тому, как ИТ-персонал реагирует на инцидент.

Современный

Практика вскрытий является устоявшейся частью современного реагирования на инциденты и обычно составляется как документация “постфактум”.

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

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

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

На этом завершим статью. Мы рассмотрели, что такое реагирование на инциденты и как оно развивалось с течением времени.

Оригинал статьи можно найти здесь. А как реагировать на инциденты можно узнать здесь.

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление поддержкой ИТ-услуг

Строим эффективную ИТ-поддержку, оптимизируем существующую