Облачный мониторинг и реагирование

Эта статья является частью серии в руководстве по мониторингу облака.

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

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

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

Мониторинг играет важную роль в широком спектре сценариев:

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

Оповещение

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

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

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

Современный подход предоставляет гораздо более информативные и автоматизированные способы обнаружения, например:

обнаруженное условие,	примитивное действие,	современное действие.
Метрика производительности — высокий уровень использования памяти. Угроза безопасности — обнаружена подозрительная сетевая активность. Ошибка доступности — запросы хранилища BLOB-объектов Azure завершаются сбоем.	Оповещения и уведомления, веб-перехватчик, push-уведомление, сборник схем, автоматическое масштабирование	Отправляйте запросы к журналам для определения компонента, вызвавшего ошибку, и автоматизируйте активацию для устранения проблемы с компонентом, вызывающим неполадки.

Ниже приведен список соответствующих ресурсов для создания оповещений и автоматизации в Azure:

• Что такое оповещения Azure Monitor?
• Интеграция Azure Monitor с поддерживаемыми продуктами интеграции управления ИТ-службами (ITSM).
• Автоматизация реагирования на угрозы в Microsoft Sentinel с помощью правил автоматизации

Современный облачный мониторинг

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

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

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

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

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

Разверните чтение с помощью этих ресурсов, чтобы узнать больше об автоматизации на основе оповещений метрик и событий безопасности:

• Начало работы с автомасштабированием в Azure с помощью Azure Monitor.

Рентабельность

Как и в случае с другими дисциплинами наблюдаемости, команда должна понять и понять затраты и как типы ответов, определенные в поддержке современных средств управления инцидентами, помогают контролировать затраты. Хотя конечная цель состоит в сокращении среднего времени восстановления (MTTR), быстро отвечая и устраняя проблему, необходимо постоянно оценивать потенциальные затраты и влияние на поток ДОХОДОВ ИТ или бизнеса.

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

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

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

Например:

1. Угроза, определяемая удостоверением, обнаруживается в одном или нескольких журналах, что инициирует оповещение.
2. Автоматизация немедленно активируется для сбора дополнительных сведений и сопоставления дополнительных журналов для обогащения оповещения.
3. Оператор принимает меры, выбрав правильную автоматизацию из библиотеки, например отключение учетной записи пользователя.

Пример или вариант использования может быть полностью автоматизирован.

Роль автоматизации предоставляет сборник схем, что сокращает затраты и экономит время.

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

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

Ниже приведен список предлагаемых сведений о большей автоматизации на основе событий идентификации или безопасности:

• Автоматически создавайте инциденты из оповещений системы безопасности Майкрософт с помощью Microsoft Sentinel.
• Оркестрация, автоматизация и реагирование системы безопасности (SOAR) в Microsoft Sentinel

Успешная стратегия оповещений

Чтобы починить что-то, нужно знать, что это сломано.

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

Информационные оповещения

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

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

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

• Ресурсы простоя: ресурсы IaaS или PaaS неактивны в течение длительного периода или не подготовлены на основе рекомендаций Помощника по Azure.

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

Рекомендации по стратегии оповещения

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

Чтобы определить, стоит ли создавать оповещение о симптоме, руководствуйтесь следующими принципами.

• Действия: имеет ли вопрос? Отражает ли она реальную проблему в работоспособности приложения? Например, может потребоваться отправить оповещение, если загрузка ЦП слишком высока в течение длительного периода для ресурса или SQL-запроса постоянно вызывает проблемы с производительностью, но может не потребоваться отправить оповещение, когда ЦП пикирует в течение короткого периода. Сделайте вещи действовать, чтобы уменьшить ложные срабатывания и избежать усталости оповещений.

• Срочность: требует ли проблема срочного внимания? Если да, ответственную команду необходимо незамедлительно уведомить.

• Влияние клиента: влияют ли пользователи службы или приложения на проблему?

• Влияние на зависимые системы: существуют ли оповещения из взаимосвязанных зависимостей, которые можно сопоставить, чтобы избежать уведомления разных команд, работающих над одной проблемой?

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

При непрерывной оценке того, что работает, рекомендуется задавать эти вопросы, чтобы повысить эффективность реагирования на мониторинг:

• Том генерации оповещений: вы получаете большой объем оповещений? Существует ли много недейственных оповещений, которые можно было избежать?
• Незамеченные проблемы: вы получаете отчеты или билеты от пользователей с проблемами, которые не были пойманы конфигурацией мониторинга?
• Ложные срабатывания: вы получаете оповещения или сигналы, которые были неправильно помечены?
• Оповещение или событие. Действительно ли вам нужно отправить оповещение или может ли некоторые из поднятых оповещений просто быть помеченными в системе? Если сигналы отображаются при запросе к нему, а не отправке оповещения, достаточно, чтобы избежать усталости оповещений и недейственных уведомлений?

Общие сведения о платформах мониторинга в этой серии статей см. в более глубоком понимании возможностей решений мониторинга Майкрософт.

Следующие шаги

Готовность к работе с навыками для мониторинга облака