Создание эффективного плана управления инцидентами для управления нарушениями

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

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

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

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

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

Терминология

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

Подготовка

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

1. Поддерживайте точные схемы архитектуры up-to-date, которые показывают все компоненты и их взаимодействие, чтобы помочь командам быстро определить узкие места или отдельные точки сбоя. Такой подход позволяет быстрее устранять неполадки во время ситуаций с высоким давлением.

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

   • Собирайте сквозную телеметрию, включая инфраструктуру и приложения.

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

   • Создайте панели мониторинга на основе модели работоспособности рабочей нагрузки. На панелях мониторинга отображаются метрики и сигналы, отслеживаемые командой.

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

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

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

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

   Используйте следующие примеры в качестве отправной точки и адаптировать их в соответствии со структурой команды.

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

4. Определите процедуры для исследования:

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

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

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

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

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

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

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

   Это важно

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

5. Настройте инфраструктуру для поддержки разрешающей способности:

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

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

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

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

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

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

8. Определите критерии, которые официально помечают инцидент как закрытый:

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

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

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

   • Позаботьтесь о подробной документации при закрытии инцидента. Запишите все сведения в системе IcM. Включите триггер, этапы локализации, решения о сортировке и окончательное разрешение. Эта документация рассматривается как раздача для RCA и ретроспективы для получения извлеченных уроков.

   Это важно

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

Обнаружение, исследование и реагирование

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

1. Действовать немедленно, когда оповещения или отчеты пользователей указывают на проблему. Используйте средства наблюдения и производительности, чтобы сопоставить аномалии с изменениями системы. Получатель инцидента настраивает команду по триажу (bridge) с нужными участниками и определяет режим связи, отслеживание хода выполнения и доступ к активам инцидента.

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

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

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

   Риск: Если вы выполняете RCA без надлежащих защитных механизмов безопасности, вы можете раскрыть конфиденциальную информацию, предоставляя доступ к журналам и данным.

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

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

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

   • По возможности сохраняйте функциональность рабочей нагрузки в пониженном состоянии.

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

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

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

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

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

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

   Это важно

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

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

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

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

Действия после инцидента

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

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

• Улучшения плана реагирования: Обновите процессы или процедуры, чтобы обеспечить более четкие, более эффективные действия.

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

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

Пример: ответ на сбой развертывания

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

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

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

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

1. Обнаружение: Команда заметила проблему, когда частота ошибок резко возросла в одной из канарных групп развертывания. Команда немедленно использует свои средства наблюдения, такие как мониторинг производительности приложений (APM), ведение журнала и телеметрия, которая связывает пользователей с этапами развертывания, чтобы определить затронутую группу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Application Insights — это расширение Azure Monitor, предоставляющее функции APM.

• Microsoft Sentinel — это решение для управления безопасностью и событиями (SIEM) и оркестрации безопасности, автоматизации и реагирования (SOAR). Это одно решение для обнаружения оповещений, видимости угроз, упреждающего поиска и реагирования на угрозы.

• Azure Pipelines предоставляет службы сборки и выпуска для поддержки непрерывной интеграции и непрерывной доставки (CI/CD) приложений.

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

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

• Многие службы базы данных Azure предоставляют функции восстановления на определенный момент времени (PITR), которые помогут вам при откате:

  • База данных SQL Azure
  • Управляемый экземпляр Azure SQL
  • Azure Cosmos DB
  • База данных Azure для MySQL
  • База данных Azure для PostgreSQL

• Azure Chaos Studio — это управляемая служба, которая использует инженерию хаоса для измерения, понимания и улучшения устойчивости облачных приложений и служб.

Связанные ссылки

• Рекомендации по разработке стратегии реагирования на инциденты
• Разработка плана аварийного восстановления для развертываний в нескольких регионах