Рекомендации по разработке стратегии реагирования на чрезвычайные ситуации

Статья
11/15/2023

Применяется к этой рекомендации по контрольным спискам операционной эффективности Azure Well-Architected Framework:

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

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

Ключевые стратегии проектирования

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

Предварительные требования
- Разработка платформы наблюдаемости
- Составление плана реагирования на инциденты
Этапы инцидента
- Обнаружение
- Containment
- Рассмотрение
Этапы после инцидента
- Анализ первопричин (RCA)
- безобвинительное рассмотрение аварийной ситуации;
Текущая активность
- Учения по реагированию на чрезвычайные ситуации

В следующих разделах приведены рекомендации для каждого из этих этапов.

Наблюдаемость

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

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

Дополнительные сведения см. в статье Рекомендации по проектированию и созданию платформы наблюдаемости.

План реагирования на инциденты

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

Четко определите следующие компоненты в плане.

Роли

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

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

Процессы и процедуры

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

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

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

Другие элементы для включения

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

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

Создайте инструкции по выполнению отработки аварийного реагирования и ведите запись о выполнении отработки.

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

Обнаружение инцидентов

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

Containment

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

Рассмотрение

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

Отчеты по анализу первопричин

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

Посмертные инциденты

Беспристрастный человек должен вести невиновные посмертные. На посмертных сеансах каждый делится своими результатами инцидента. Каждая группа, которая принимала участие в реагировании на инцидент, должна быть представлена лицами, которые работали над инцидентом. Эти лица должны прийти на сессию, подготовленную с примерами успешных областей и областей, которые можно улучшить. Сеанс не является форумом для назначения blame для инцидента или проблем, которые могли возникнуть во время реагирования. Руководитель postmortem должен выйти из сеанса с четким списком действий, которые сосредоточены на улучшении, например:

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

Упрощение поддержки Azure

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

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

Log Analytics — это надежное средство аналитики, встроенное в Monitor. Log Analytics можно использовать для выполнения запросов к агрегированным журналам и получения аналитических сведений о рабочей нагрузке.

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

Контрольный список эффективности операций

См. полный набор рекомендаций.