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

Статья
10/15/2024

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

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

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

Основные стратегии проектирования

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

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

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

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

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

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

Составление плана реагирования на инциденты

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

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

Роли

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

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

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

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

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

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

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

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

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

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

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

Действовать по триггерам наблюдаемости

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

Определение процедур хранения

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

Определение процедур триажа

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

Создание отчетов об инцидентах RCA

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

Удержание инцидентов в постмортиме

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

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

Упрощение функций Azure

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

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

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

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

Контрольный список операционных знаний

Ознакомьтесь с полным набором рекомендаций.