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

Завершено

Процесс обработки серьёзных инцидентов

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

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

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

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

Этапы в процессе крупного инцидента

1. Проверить состояние службы Azure

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

2. Заявка в поддержку зарегистрирована

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

3. инженерные команды, участвующие

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

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

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

Для получения дополнительной информации см. статью роли Azure, роли Microsoft Entra и классические роли администратора подписки, обзор классического интерфейса портала работоспособности служб .

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

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

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

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

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

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

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

Заметка

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

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

Когда регистрируется случай поддержки степени A в компании Microsoft, каждого клиента уведомляют, и инженер техподдержки будет предоставлять все обновления текущих случаев поддержки.

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

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

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

  

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

  

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

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

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

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

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

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

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

Дополнительные сведения и пошаговые инструкции см. в панели мониторинга Cloud Support Request Visibility.