Когда и как получить поддержку

Завершено

Основной процесс инцидентов

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

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

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

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

Шаги в процессе основного инцидента

  1. Проверка работоспособности службы Azure

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

    • Служба клиентов и поддержка (CSS), активированная для устранения проблемы
    • Команда по управлению критическими ситуациями и эскалации (CMET), диспетчер инцидентов (IM) и диспетчер учетных записей клиентов (CSAM) уведомляются (применимы только к клиентам с поддержкой Premier/Unified).
  3. Инженерные команды, участвующие в разработке

    • Регулярные обновления, опубликованные в Службе Работоспособности служб Azure
    • Решение, размещенное в Службе Работоспособности служб Azure

Illustration of the major incident process.

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

Роль Description
Глобальный администратор

Владелец (Azure RBAC)

Участник (Azure RBAC)
Обращается ко всем административным функциям (на роль) в портал Azure включая доступ к созданию запросов на поддержку.
Служба поддержки Администратор Создание запросов в службу поддержки Azure и управление ими.
Чтение и настройка Работоспособности служб Azure.

Дополнительные сведения см. в статье о ролях Azure, ролях Microsoft Entra и классических ролях администратора подписки, классическом интерфейсе портала работоспособности служб

Служба поддержки Администратор istrator. Эта роль может открывать запросы на поддержку с помощью служб Microsoft для Azure и Microsoft 365 и просматривать панель мониторинга службы и центр сообщений в портал Azure и Центр администрирования Microsoft 365.

Чтобы создать запрос на поддержку, необходимо быть владельцем, участником или назначить роль службы поддержки Администраторна уровне подписки. Чтобы создать запрос на поддержку без подписки, например сценарий Microsoft Entra, необходимо быть Администратор.

Учетные записи Администратор istrator, Service Администратор istrator и Co-Администратор istrator — это три роли администратора классической подписки в Azure. Классические администраторы подписки имеют полный доступ к подписке Azure. Они могут управлять ресурсами с помощью портала Azure, интерфейсов API Azure Resource Manager и классической модели развертывания Azure. Учетная запись, используемая для регистрации в Azure, автоматически устанавливается как учетная запись Администратор istrator и service Администратор istrator. Затем можно добавить дополнительные совместно Администратор istrator. Служба Администратор istrator и со-Администратор istrator имеют эквивалентный доступ пользователей, которым назначена роль владельца (роль владельца Azure RBAC) в подписке область.

RBAC Azure — это система авторизации на основе Azure Resource Manager, которая обеспечивает точное управление доступом к ресурсам в Azure, например к вычислительным ресурсам и хранилищу. Система RBAC Azure включает более 70 встроенных ролей. В системе RBAC предусмотрены четыре основные роли. Первые три роли охватывают все типы ресурсов:

Роль Описание: Область действия
Владелец Полный доступ ко всем ресурсам.
Делегировать доступ другим пользователям.
Служба Администратор istrator и со-Администратор istrator назначают роль владельца в область подписки.
Применяется ко всем типам ресурсов.
Участник Создайте и управляйте всеми типами ресурсов Azure.
Не удается предоставить доступ другим пользователям.
Применяется ко всем типам ресурсов.
Читатель Просмотр ресурсов Azure. Применяется ко всем типам ресурсов.
Администратор доступа пользователей Управление доступом пользователей к ресурсам Azure. Н/Д

Остальные встроенные роли разрешают управление определенными ресурсами Azure. Например, роль Участник виртуальных машин позволяет пользователю создавать виртуальные машины и управлять ими. Полный список встроенных ролей см. в статье Встроенные роли для ресурсов Azure.

Модель RBAC поддерживается только порталом Azure и API-интерфейсами Azure Resource Manager. Пользователи, группы и приложения, которым назначены роли RBAC, не могут использовать API классической модели развертывания Azure.

Примечание.

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

Критические ситуации (случай поддержки серьезности)

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

Клиенты службы поддержки Microsoft Premier/Unified также получат уведомление в начале дела серьезности A от группы управления критическими ситуациями и эскалацией (глобальное управление критическими ситуациями). Роль группы управления критическими ситуациями и эскалацией (CMET) заключается в том, чтобы обеспечить надзор и мониторинг всех случаев серьезности A и вмешаться от имени клиента при необходимости. Если требуется помощь в отношении случая серьезности A, обратитесь в CMET по номеру локальной поддержки и попросите поговорить с диспетчером критических ситуаций.

Ниже приведены два примера исходных сообщений и отправленных сообщений об обновлении сообщений.

  • Первоначальные сообщения электронной почты от группы управления критической ситуацией и эскалации (CMET) для случае серьезности A.

    Screenshot of an initial communications email for a Severity A case.

  • Обновите сообщение электронной почты при использовании диспетчера критических ситуаций.

    Screenshot of an update email for a Severity A case.

Управление запросами на поддержку с помощью Центра служб

Состояние запроса на поддержку в Центре служб

Клиенты могут просматривать все варианты поддержки, включая Azure, Microsoft 365 и Dynamics 365, а также локальные запросы на поддержку централизованно в Центре обслуживания. В нем содержатся дополнительные сведения о каждом запросе на поддержку, включая состояние и спецификации. Эта информация доступна без необходимости нажимать или разворачивать выделение, что делает взаимодействие более простым и интуитивным.

Screenshot of Azure Action Center.

Screenshot of Manage Support Requests via Services Hub.

Панель мониторинга видимости случаев поддержки облака

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

На панели мониторинга видимости запросов в службу поддержки облачных служб можно:

  • Добавление или удаление подписок и клиентов
  • Включение и отключение видимости регистра для отдельных облачных ресурсов
  • Просмотр журнала состояния видимости каждого облачного ресурса
  • Использование фильтров на панели мониторинга видимости запросов в службу поддержки облака для уточнения списка и результатов поиска

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

Cloud Support Request Visibility Dashboard