Что делать во время нарушения работы службы #REF!

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

Корпорация Майкрософт предоставляет соглашение об уровне обслуживания (SLA) для многих своих служб в качестве обязательства по обеспечению доступности и подключения. Соглашения об уровне обслуживания для отдельных служб #REF! можно найти в разделе Соглашения об уровне обслуживания #REF!.

Понять масштаб инцидента

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

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

1. Перейдите к Работоспособность служб Azure, который предоставляет:

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

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

2. Если у вас возникли проблемы с доступом к порталу #REF!, перейдите к состоянию #REF!.

   Замечание

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

3. Если возникли проблемы со страницей состояния, проверьте наличие записей из @AzureSupport на социальной платформе X.

Инциденты зоны доступности и центра обработки данных

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

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

Дополнительные сведения о поддержке зон доступности в службах #REF! и различиях между зональными, избыточными зонами и региональными (незональными) службами см. в разделе #REF! службы поддержки зон доступности.

Если существуют проблемы с зональными или региональными ресурсами, развернутыми в затронутой зоне доступности, рекомендуется инициировать планы непрерывности бизнес-процессов и аварийного восстановления (BC/DR).

Логические и физические зоны доступности

Каждая #REF! подписка видит другой список зон доступности. Логические зоны, используемые каждой подпиской, могут соответствовать разным физическим зонам. Вы можете сопоставить ваши логические зоны и физические зоны, чтобы подтвердить, какие ресурсы работают в затронутой физической зоне доступности. Дополнительные сведения см. в разделе "Физические и логические зоны доступности".

Инциденты на уровне региона

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

Приоритет непрерывности бизнес-процессов

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

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

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

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

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

• Цели уровня обслуживания (SLOs), установленные для пользователей вашей рабочей нагрузки, если они у вас есть. Соглашения об уровне обслуживания (SLO) помогают в принятии решений в подобных ситуациях. Например, в некоторых ситуациях вы можете перейти на ручное управление, пока ваши службы не заработают в нормальном режиме, и это решение может быть отражено в SLO для системы. Чтобы узнать больше об SLO и их определении, см. статью Рекомендации по определению целевых показателей надежности в #REF! Well-Architected Framework.

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

Рассмотрите план аварийного восстановления

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

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

Это важно

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

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

Переключение на резерв, инициированное Майкрософт

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

Поддержка Azure

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

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

• Вы видите проблемы, которые не рассматриваются в описании инцидента на Работоспособность служб Azure.

• Вам нужна помощь от Корпорации Майкрософт в рамках усилий по восстановлению.

  Подсказка

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

При открытии обращения в службу поддержки четко объясните затронутые ресурсы и влияние проблемы. Укажите идентификатор подписки #REF! и регион, в котором возникла проблема. Задайте серьезность случая поддержки на основе влияния на ваш бизнес. Помните, что многие клиенты могут реактивно обращаться к поддержке #REF! во время перебоя в работе служб #REF! вне этих условий, описанных выше. Эта добавленная нагрузка на ресурсы поддержка Azure может к сожалению отложить решение ваших потребностей в поддержке.

После инцидента

1. Чтобы понять, чему корпорация Microsoft научилась из этого инцидента, ознакомьтесь с Post Incident Review (PIR) в панели истории работоспособности Работоспособность служб Azure или через оповещения о работоспособности службы, настроенные клиентом. Различные инциденты могут получить различные типы PIR. Предварительные пин-коды обычно публикуются через несколько дней после инцидента, и более полные ПИН-коды следуют несколько недель спустя.

2. Для крупных инцидентов, которые были перечислены на общедоступной странице статуса, присоединяйтесь к прямой трансляции ретроспективы инцидентов #REF!, чтобы получить ответы на все ваши вопросы, или прослушайте запись.

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

4. Рассмотрим, что можно узнать из инцидента, чтобы повысить устойчивость и процессы. Рассмотрим такие вопросы:

   • Насколько хорошо работает план аварийного восстановления? Есть ли какие-либо улучшения, которые вы могли бы сделать? Дополнительные сведения см. в руководстве #REF! Well-Architected Framework по стратегиям аварийного восстановления.

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

   • Существуют ли #REF! руководства по надежности службы для используемых служб? Руководства по надежности содержат сведения о том, сколько служб #REF! можно настроить в соответствии с требованиями к устойчивости.

   • Существует ли компромисс по проектированию, который вы можете сделать, чтобы повысить устойчивость в будущем для этого типа проблемы? Дополнительные сведения см. в разделе надежность в рамках #REF! Well-Architected Framework.

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

   • Следует ли настроить оповещения Работоспособность служб Azure для автоматического уведомления о любых будущих инцидентах?

5. Если у вас есть отзывы о том, как мы можем улучшить наш ответ на инциденты, сообщите нам через назначенного представителя Майкрософт или через сайте обратной связи #REF!.