Azure Stack Hub 报修与技术支持：Dell + Microsoft 双供应商协同支持流程

未经同意，请勿转载！

本文聚焦当 Azure Stack Hub 出现问题时如何正确报修------是 Dell 的问题还是 Microsoft 的问题？Dell 和 Microsoft 怎么处理？是 Tracewell 还是 Dell Product Engineering？升级路径如何？这是工程师 / 客户协作的"实操图"。

系列预告 ：本篇为 三篇运维实战系列 的第 3 篇（报修篇）：

第 1 篇（管理员篇）：Azure Stack Hub 管理员日常操作 ------ StampInformation、管理员门户、PEP、区域管理、容量监管。

第 2 篇（租户篇）：Azure Stack Hub 租户日常操作 ------ 订阅、虚拟网络、NSG、VM、VMSS、监控、ARM 模板。

第 3 篇（本文·报修篇）：报修与技术支持 ------ Dell + Microsoft 双供应商协同支持流程、SLA 升级路径、紧急联系方式。

版本基础 ：本文基于 Dell Integrated System for Microsoft Azure Stack Hub 14G（AX 系列） 与 azs-2005 至当前主流 azs 版本 整理，覆盖 azs-2002 / 2005 / 2102 / 2206 / 2301 / 2405 / 2503 等。不同 azs 版本、不同集成系统世代（13G/14G/15G/16G）以及不同 OEM 厂商的支持细节可能存在差异 ，本文以 Dell 集成系统视角展开，其他厂商支持路径相似但具体编号 / 联系方式 / SLA 不同------参考各自 Support Matrix。

修订说明：

本篇为 Azure Stack Hub 运维管理三篇系列 · 报修篇首发版，基于内训示材料《Azure Stack Hub 运维管理》报修与技术支持章节 + Dell Integrated System for Microsoft Azure Stack Hub Support Process 流程图整理，按四层原则做工程化改写。

报修与技术支持的全景：三方博弈
支持矩阵的硬性事实：哪些问题归谁
[Dell 集成系统支持流程：12 步全景图](#Dell 集成系统支持流程：12 步全景图)
升级路径：什么情况下需要升级
[Dell EMC 报修渠道：电话 + Web + 邮件](#Dell EMC 报修渠道：电话 + Web + 邮件)
[Microsoft 报修渠道：Azure Portal 优先](#Microsoft 报修渠道：Azure Portal 优先)
[四条故障归属判定方法：10 秒定位责任方](#四条故障归属判定方法：10 秒定位责任方)
[四类典型案例：故障发生时的完整 SOP](#四类典型案例：故障发生时的完整 SOP)
四层原则落地：支持流程的版本依赖与差异
三大误判信号：报修时最常踩的坑
三条操作红线：报修时绝对不能越的边界
报修篇小结：应急流程的工程化整合

1. 报修与技术支持的全景：三方博弈

Azure Stack Hub 是一个深度集成的 OEM 系统 ，故障发生时通常不止一家公司在支持链路里------这与 Azure 公有云的"工单创建 → 微软处理"模式差异显著。

1.1 三方核心架构

复制代码

                Azure Stack Hub 报修生态
                          │
        ┌─────────────────┼─────────────────────┐
        │                 │                     │
    客户（Customer）   集成系统 OEM           软件供应商
        │           （Dell EMC / Lenovo /      （Microsoft
        │            HPE / Cisco 等）           Azure）
        │                 │                     │
        ▼                 ▼                     ▼
   最终用户          硬件 / 固件 /         软件 / 更新 /
   / 租户运维        物理更换支持          平台级支持

1.2 关键角色清单

角色分类：

角色	英文	责任范围	L 分类
客户	Customer / Partner	业务 / 运维 / 与供应商对接	L1 微软硬要求
Microsoft Azure Stack Engineering	Microsoft	Azure Stack Hub 软件 / 更新 / 平台	L1 微软硬要求
International Product Support（IPS）	Microsoft IPS	微软侧全球支持响应	L1 微软硬要求
Microsoft Azure Support	Microsoft	微软侧 Azure 平台支持	L1 微软硬要求
Dell EMC	Dell EMC	14G 集成系统的硬件 / 服务	L2 OEM 实现差异
Dell Parts Logistics	Dell EMC	备件物流	L2 OEM 实现差异
Dell / Microsoft Solutions Support (SST)	Dell SST	Dell 与 Microsoft 联合支持团队	L2 OEM 实现差异
Dell S&DS Field	Dell S&DS	现场服务工程师	L2 OEM 实现差异
Dell Product Engineering	Dell PE	硬件工程升级	L2 OEM 实现差异
Tracewell Engineering	Tracewell	机箱 / 电源 / 特殊硬件	L2 OEM 实现差异
SupportAssist Enterprise (L3)	Dell SupportAssist	远程监控 / 自动化数据收集	L2 OEM 实现差异
Microsoft CSP Partner Portal	Microsoft CSP	CSP 模式客户对接	L2 实现差异
Back Office Support	Dell / Microsoft	后台支持流程	L2 / L3

1.3 三方博弈的本质

维度	客户	OEM（Dell）	Microsoft
合同	与 OEM 签（含 Microsoft 通过 OEM 转授）	与客户签	与 OEM 签合作合同
计费	一次性买断 + 服务订阅	按合同 SLA	按 OEM 微软合同
沟通主体	报修第一接触 = OEM	报修第二接触 = Microsoft	升级到 OEM 后 = 微软处理
责任主体	日常运维 + 报修	硬件 + 集成系统	软件 + Azure 平台

L1 微软硬要求 ：Azure Stack Hub 的支持架构天然就是三方协作 ------ 客户不能绕过 OEM 直接找微软（除了 Microsoft.Azure.com 等 Web 渠道的反向链路）。这是设计的"集成系统" 责任分配。

2. 支持矩阵的硬性事实：哪些问题归谁

2.1 故障归属的三大判别类别

故障类型	责任主体	例子
硬件故障	Dell EMC（含 S&DS / Product Engineering）	服务器主板、电源、磁盘、SSD 损坏；交换机端口 down；BMC 失效
集成系统层（OEM 定制部分）	Dell EMC 主导，Microsoft 协助	机架布局、ToR 交换机配置、HLH、Tracewell 机箱（Dell 部分型号）
Azure Stack Hub 软件 / 平台	Microsoft（Dell 协助）	Update 安装失败、Portal 异常、RP 行为、Storage Spaces Direct 故障
租户应用层	客户	VM 内部 OS 故障、应用配置错误、网络安全策略问题

2.2 "硬件 vs 软件"的快速判断法

L3 最佳实践·故障归属快速判断：

复制代码

问 1：故障是否涉及物理组件（机器不亮 / 风扇异常 / 磁盘卡死）？
├─ Yes → 硬件 → Dell EMC
└─ No  → 进入问 2

问 2：故障是否在"管理员门户 / Operator PowerShell / PEP"层级表现？
├─ Yes → 软件平台层 → Microsoft（走 Dell → Microsoft 的升级路径）
└─ No  → 进入问 3

问 3：故障是租户侧工作负载 / 应用 / VM OS 内部的？
├─ Yes → 租户应用层 → 客户 / 应用供应商 / VM OS 供应商
└─ No  → 升级到 PE / 升级 Dell + Microsoft 联合诊断

2.3 责任边界案例

场景	责任主体	修复入口
服务器硬盘 SMART 报警	Dell EMC	Dell Parts Logistics + S&DS
交换机 firmware 不一致	Dell EMC	Dell Product Engineering
管理员门户无法访问	Microsoft	通过 Dell → Microsoft
Update Bundle 安装失败	Microsoft	通过 Dell → Microsoft
租户 VM 蓝屏	客户（VM OS / 驱动 / 应用）	客户 / ISV / OS 供应商
租户 vNet 不通	Microsoft（平台软件）	通过 Dell → Microsoft
物理网络包丢失	Dell EMC（交换机 / 网线）	Dell S&DS
RDMA 性能问题	Dell EMC + Microsoft	联合诊断

L1 微软硬要求 + L2 OEM 实现差异 ：上面表格中 "Microsoft 主导" 还是 "Dell 主导" 的边界，不是僵化的 ------实际工程中两类问题常互相影响 （如硬件故障可能引发平台问题），客户做"故障归属判断"时应先报 Dell，由 Dell 内部判定是否升级 Microsoft。

3. Dell 集成系统支持流程：12 步全景图

3.1 提供的 12 步流程

复制代码

      [1] Secure Remote Services (SR Initiation)
                          │
                          ▼
      [2] Service Cloud / Proactive SR / Chat / Phone
                          │
                          ▼
      [3] Support Technician
                          │
        ┌─────────────────┼─────────────────┐
        │                 │                 │
        ▼                 ▼                 ▼
  [4]Web / Chat   [5]Phone / Dial   [6]Home
        │                 │                 │
        └─────────────────┼─────────────────┘
                          │
                          ▼
              [7] Categorize: 4 类问题
       ┌────────┬─────────┬─────────┬─────────┐
       ▼        ▼         ▼         ▼
   Compute  Networking  Storage   Platform
       │        │         │         │
       ▼        ▼         ▼         ▼
       └────────┴─────────┴─────────┘
                          │
                          ▼
              [8] Software / Security / Deployment
                          │
                          ▼
              [9] SR / Back Office Support
                          │
                          ▼
          [10] International Product Support
                          │
                          ▼
          [11] Microsoft Azure Stack
                          │
                          ▼
          [12] 3rd Party CSP / Billable / Software / Field / Escalation

3.2 12 步流程详解

细化：每一步对应的责任方与工程含义。

步骤	节点	责任方	关键操作
1	Secure Remote Services（SR）	Dell	收集遥测、远程诊断支持
2	Service Cloud / Proactive SR / Chat / Phone	Dell	工单创建入口（4 种联系方式）
3	Support Technician	Dell EMC	一线支持工程师接单
4	Web / Chat	Dell EMC	Web 入口走在线工程师
5	Phone / Dial	Dell EMC	电话入口走值班工程师
6	Home（Home Support）	Dell EMC	主要服务区域工程师
7	Categorize	Dell EMC	4 类分类：Compute / Networking / Storage / Platform
8	Software / Security / Deployment	Dell EMC	软件 / 安全 / 部署类升级
9	Back Office Support + 3rd Party CSP	Dell	后台支持与第三方协同
10	International Product Support（IPS）	Microsoft	升级到微软侧
11	Microsoft Azure Stack	Microsoft	微软 IPS 内部处理
12	Field / Escalation	Dell 或 Microsoft	现场或升级

3.3 流程的工程实质

L3 最佳实践（PPT 未明说，但流程图本身揭示了）：

第 1 步 = 遥测 ------ Dell 通过 Secure Remote Services（这是一套 Dell 自有的远程诊断通道）持续收集硬件 / 固件健康数据，这是 SOP 第一步。

第 2-3 步 = 一线接单 ------ 工单进入 Dell Service Cloud 系统，按照 4 种渠道分流。

第 4-6 步 = 一线工程师处理 ------ Compute / Networking / Storage / Platform 4 类问题分类，分别走对应工程师（这是 Dell 内部 L1 / L2 / L3 工程支持的层级）。

第 7-9 步 = 升级路径 ------ 一线无法解决时，进入 IPS（Microsoft 侧）+ Azure Stack 工程团队。

第 10-12 步 = 微软侧处理 ------ 微软 IPS 与 Azure Stack Engineering 联合处理。

第 13-15 步 = 极端升级 ------ 现场支持 / 跨 OEM 协同 / Tracewell Engineering（专用机箱硬件厂商）。

3.4 Tracewell Engineering 的作用

L2 OEM 实现差异 ：Tracewell 是部分 Dell Azure Stack Hub 集成系统的第三方机箱供应商------主要负责电源 / 机箱 / 特殊硬件设计。Dell 集成系统中的 Tracewell 部分故障会升级到 Tracewell Engineering 处理（第 14 步）。

3.5 SupportAssist Enterprise

L2 OEM 实现差异 ：SupportAssist Enterprise 是 Dell 的远程监控和自动化数据收集产品 。Azure Stack Hub 集成系统出厂时会预装 SupportAssist 代理（L2），用于：

自动收集硬件遥测

自动检测故障并开 SR

与 Dell Service Cloud 集成

SupportAssist 在报修中的作用：

预开工单------检测到硬件异常时自动开 SR
遥测数据------为 Dell 工程师提供远程诊断依据
客户不必主动开 SR------某些硬件故障由 SupportAssist 自动报告

L3 最佳实践 ：客户应确保 SupportAssist 始终在线------若 SupportAssist 离线，硬件故障不会自动上报，需要客户主动报修。

4. 升级路径：什么情况下需要升级

4.1 升级路径全景

精细化：

复制代码

       Customer / Partner
              │
              ▼
   Lightning Support Ticket
              │
       ┌──────┴──────┐
       ▼              ▼
   Dell EMC        Microsoft Azure
   Support         Support
       │              │
       ▼              ▼
   Dell Microsoft   Automated Case
   Solutions        Exchange
   Support Team
       │
       ▼
   International
   Product Support
       │
       ▼
   AzS Hub
   Engineering
       │
       ▼
   Engineering
   Escalations
              │
              ▼
       ┌──────┴──────┐
       ▼              ▼
    Question       Bug (JIRA)
    (JIRA)         (Microsoft AzS Bug)
       │              │
       ▼              ▼
    New Feature    Improvement
    (Microsoft     (JIRA)
     Product)

4.2 升级的 6 类触发条件

L3 最佳实践：

一线工程师无法定位故障 ------ 例如硬件测试一切正常，但现象持续 → 升级到 Microsoft 侧 IPS。

涉及软件平台层 ------ 例如 Update 安装失败、Platform 异常 → 升级 Microsoft。

SLA 超时 ------ 例如紧急工单 4 小时未解决 → 自动升级到 IPS 或 Field Service。

跨厂商问题 ------ 例如硬件 OEM 软件 bug → 升级 Microsoft Product Engineering。

数据完整性问题 ------ 例如某客户数据可疑丢失或破坏 → 升级 Microsoft IPS（高优先级）。

安全 / 合规事件 ------ 任何安全相关 → 升级路径最快、最严。

4.3 升级流中的 JIRA 用途

出现两次 JIRA ：MHC -- JIRA（Microsoft Health Care JIRA），这是 Dell 内部缩写。

更正术语：MHC 是 Dell 内部的 Microsoft Health Care 系统缩写------指代 Dell 管理 Microsoft 相关工单的内部跟踪系统。每次跨厂商升级都会生成 JIRA 项。

L3 最佳实践 ：当客户看到 Dell 工程师在工单系统里同步生成 "MHC-JIRA" 项时，这是升级的前兆------意味着 Microsoft 侧即将介入。

4.4 升级时效（L2 OEM 实现差异）

升级层级	SLA 时限（建议参考）	备注
Dell 一线 → 二线	通常 4 小时	因合同 SLA 而异
Dell 二线 → Microsoft IPS	通常 8-24 小时	取决于工单严重性
IPS → Microsoft AzS Engineering	通常 24-72 小时	微软内部升级
Engineering → Product Group	可能 1-2 周	涉及 bug 修复
Field Service（现场）	通常 4-24 小时出发	取决于硬件严重性

L2 OEM 实现差异 ：实际 SLA 取决于客户与 Dell 的合同（如 "Pro Support Plus" / "Pro Support" / 基本支持等不同档位）。本文表格是"通常范围"，不构成承诺。

5. Dell EMC 报修渠道：电话 + Web + 邮件

5.1 原文

原文：Dell EMC 24 小时 × 7 天电话服务

免费电话：

中文：800 8190009 / 800 8103777 / 10800 852 1116

英文：800 8580523 / 108008521117

收费电话：

中文：400 6700009

英文：400 8819925

5.2 渠道的多维对比

维度	电话（Dell）	Web / 邮件（Dell）	Azure 门户（Microsoft）
入口	24×7 客服专线	Dell 官网工单系统	`portal.azure.com`
语言	中文 / 英文	中文 / 英文	全 portal 支持的语言
响应时效	立即（人工值班）	通常 1-4 小时	通常 1-8 小时
适用场景	紧急 / 关键问题	常规 / 非关键问题	Microsoft 主导的问题（软件 / 平台）
沟通方式	同步（实时通话）	异步（工单回复）	异步（工单系统）
数据采集	工程师口头引导	自动收集 SupportAssist 遥测	自动关联 Azure 资源
客户操作复杂度	低（直接拨打电话）	中（需登录 Dell 账号）	中（需登录 Microsoft 账号）

5.3 电话号码的多区域理解

L2 OEM 实现差异 ：上面 PPT 列出的电话号码是 中文支持电话 ------具体号码的可用性取决于客户所在区域：

800 开头 ------ 中国大陆免费电话（部分被运营商屏蔽，可用性可能有变化）

10800 开头 ------ 中国大陆境外拨打免费（部分区域支持）

400 开头 ------ 收费电话（全国通用）
L3 最佳实践 ：本文不固化电话号码。实际报修电话以当期 Dell 官网公布的 Dell EMC 服务支持页面为准 （https://www.dell.com/support/ ，具体编号因区域 / 合同而异）。

6. Microsoft 报修渠道：Azure Portal 优先

6.1 原文

Microsoft 推荐使用 Azure 门户网站创建技术支持工单。

6.2 为什么 Azure Portal 是 Microsoft 侧的"标准入口"

关联资源 ID ------ 工单自动绑定 Microsoft 视角的资源（如订阅、租户）
遥测数据自动采集 ------ Microsoft 后台已经收到诊断数据
SLA 可视化 ------ 客户能看到工单的响应 SLA 倒计时
升级一键触发 ------ 在工单系统内直接升级到 Product Group

6.3 Microsoft 报修的具体步骤

复制代码

1. 登录 Azure Portal（portal.azure.com）
2. 顶部"?" → "帮助 + 支持"
3. 单击"创建支持工单"
4. 选择"问题类型"
5. 选择"订阅"（选择 Azure Stack Hub 对应的订阅）
6. 填写问题描述（建议附上 StampInformation + 错误码 + 截图）
7. 选择严重性：
   - Critical（A）：生产全停
   - High（B）：严重受影响
   - Medium（C）：部分受影响
   - Low（D）：一般咨询）
8. 提交工单

L3 最佳实践 ：Critical 工单通常可走电话 + Web 同时建 ------ 但 Microsoft 强烈建议先在 Portal 创建以便跟踪。

6.4 关于 Microsoft 对 Azure Stack Hub 的支持

重要说明：

Azure Stack Hub 不通过 Azure 公有云订阅提供支持 ------它是一套独立产品线，由 Microsoft 通过 OEM（Dell 等）转售。

客户在 portal.azure.com 看到的 Azure Stack Hub 工单 ，合同主体通常是 OEM。

一些 azs 版本允许通过 Microsoft 账号直接开 SR，但大多路径下需要先联系 Dell。

6.5 Microsoft Support 路径与 Dell 路径的关系

复制代码

   客户故障
      │
      ▼
   问：谁的问题？
      │
   ┌──┴──┐
   │     │
 Dell    Microsoft
   │     │
   │  ┌──┴──────────┐
   │  │             │
   │ Software      Other
   │ Platform      cases
   │  (升级到 MS) (Dell 一线)
   │  │
   └──┴───────────┐
              ▼
       Microsoft IPS
       (Microsoft AzS Eng)

关键工程事实 ：Microsoft 侧对 Azure Stack Hub 的支持入口通常需要通过 Dell 升级，而不是由客户直接开 SR。这是 OEM 集成系统的渠道架构。

7. 四条故障归属判定方法：10 秒定位责任方

7.1 判别方法 #1：物理部件测试法

复制代码

问 1：故障涉及的部件是否在物理硬件层？
├─ 服务器 / 磁盘 / 电源 / 网络线 / ToR 交换机 → Dell EMC
├─ BMC / iDRAC 异常 → Dell EMC
├─ 风扇噪音 / 温度异常 → Dell EMC
└─ 软件层 UI / API / PowerShell → 进一步判定

7.2 判别方法 #2：管理员门户可见性法

复制代码

问 2：故障是否在管理员门户层可见？
├─ 不可见（租户内部问题）→ 客户 / ISV
├─ 管理员门户能登录但行为异常 → Microsoft / Dell
├─ 管理员门户打不开 → Microsoft / Dell（紧急）
└─ 看是否在警报列表中 → 警报归属

7.3 判别方法 #3：警报严重性法

警报严重性	通常归属
Critical Hardware Fault	Dell EMC
Storage Spaces Direct 异常	Microsoft 主导（经 Dell 升级）
PEP 不可达	Dell + Microsoft 联合
Update Bundle 失败	Microsoft 主导（经 Dell 升级）
容量达到阈值	客户（管理租户）
租户 VM 异常	客户

7.4 判别方法 #4：时间相关性法

复制代码

问 4：故障是突发的还是长期？
├─ 突发（刚刚发生）→ 检查近期事件（Update / 维护）
├─ 最近 Update 安装 → Microsoft（Update 相关）
├─ 最近硬件更换 → Dell EMC
└─ 一直就有 → 长期问题，应创建工单而非应急

7.5 综合判别表

现象	立即动作	主要责任	协同
服务器掉电	紧急电话 Dell	Dell EMC	---
Portal 打不开	检查 SupportAssist + 拨 Dell	Microsoft → Dell → MS	联合
VM I/O 慢	Performance Monitor + SupportAssist 数据	Microsoft	联合
RDP 不到 VM	检查 NSG + 子网	客户或 Microsoft	---
容量触顶	客户 / 管理员共同处理	客户	联合
SupportAssist 离线	紧急电话 Dell	Dell EMC	---

8. 四类典型案例：故障发生时的完整 SOP

8.1 案例 #1：物理硬盘故障

现象：管理员门户 → 容量 → 存储警报显示 "Disk X failed"；SupportAssist 自动开 SR。

SOP：

复制代码

步骤 1: SupportAssist 自动开 SR（Dell 工程师已知）
步骤 2: 客户 / 管理员通知内部值班（保留 SR 编号）
步骤 3: Dell 工程师安排备件（Dell Parts Logistics）
步骤 4: Dell S&DS Field 工程师上门更换磁盘（4-24 小时）
步骤 5: 更换后 S2D 自动触发 rebuild（通常 24-72 小时）
步骤 6: 重测容量警报 → 关闭 SR

关键要点：

不要主动重试 ------ 让 S2D 自动恢复
不要手工操作磁盘 ------ OEM 验证过的故障处理流程对磁盘是确定的
收集 SupportAssist 遥测 ------ 为 Dell 工程师提供数据

8.2 案例 #2：Update Bundle 安装失败

现象：管理员门户 → 更新 → 上传 Bundle → 安装失败，警报指向 S2D 角色。

SOP：

复制代码

步骤 1: 立即回滚（如果支持）--- 通过管理员门户 → 更新 → 历史
步骤 2: 收集 PEP 日志: Get-AzureStackLog -OutputPath ...
步骤 3: 通过 Dell → Microsoft IPS 开 SR
步骤 4: 微软 IPS 工程师诊断 Update Bundle 兼容性
步骤 5: 可能需要回退到上一 Bundle 版本
步骤 6: 修复后重新尝试更新

关键要点：

立即备份当前运行状态 ------ 让 SupportAssist 收集
不要跨多个 Update Bundle 跳跃 ------ 严格按照 Update Matrix 路线升级

8.3 案例 #3：管理员门户无法访问

现象：客户使用 CloudAdmin 登录管理员门户失败，所有用户都遇到。

SOP：

复制代码

步骤 1: 验证 URL 是否正确（凭 StampInformation）
步骤 2: 检查 SupportAssist 是否离线（硬件可能正常）
步骤 3: 通过 HLH / OAW 进入 PEP（如果有可达）
步骤 4: 如果 PEP 也无法访问 → 紧急电话 Dell（Severity A）
步骤 5: Dell 升级到 Microsoft IPS
步骤 6: 微软工程师介入恢复 ADFS / 网络层

关键要点：

Portal 不能访问 ≠ 系统崩溃 ------ 只是认证 / 网络层问题
PEP 是最后一道防线 ------ 必须能进入才能恢复

8.4 案例 #4：租户体验性能下降

现象：多个租户报告 VM 性能慢，CPU / IO / 网络指标正常。

SOP：

复制代码

步骤 1: 客户 → Azure Stack Hub 管理员（这是分层报修）
步骤 2: 管理员检查基础设施层（管理员门户）
步骤 3: 收集 PEP 日志 + SupportAssist 遥测
步骤 4: 通过 Dell → Microsoft IPS 开 SR
步骤 5: 微软工程师诊断是否是底层问题
步骤 6: 如果是租户应用层问题 → 转回客户 / ISV

关键要点：

租户报修应该直达 Microsoft ❌------租户应该找自己的 IT（客户）
客户 → 管理员 → Dell → Microsoft 是正确的"自下而上"传递路径
跨层传递不应直接跳级

8.5 案例联合总结

案例	优先报修方	通过谁升级
硬盘故障	Dell	不需升级
Update 失败	Dell → Microsoft IPS	是
Portal 不可访问	Dell → Microsoft IPS	是
租户性能问题	客户 → 管理员 → 视情况升级	可能

9. 四层原则落地：支持流程的版本依赖与差异

将报修流程按 L0 版本事实 / L1 微软硬要求 / L2 OEM 实现 / L3 最佳实践 四层重新梳理：

流程 / 角色	层级	说明
SupportAssist 自动开 SR	L2 OEM	这是 Dell 设计的功能
SupportAssist 通过 Secure Remote Services 收集遥测	L2 OEM	Dell 安全通道
Microsoft 是 Azure Stack 软件责任主体	L1 微软硬要求	这是合作合同明示的
Dell 是硬件责任主体	L1 微软硬要求	OEM 集成系统合同
升级路径必须 Dell → Microsoft，不能客户直跳 Microsoft	L1 微软硬要求	这是合作渠道设计
通过 Microsoft Azure Portal 开 SR（基于公有云视角）	L2 实现	不是所有客户都通过此路径
现场服务（Field Service）由 Dell S&DS 提供	L2 OEM	Dell 派遣
Tracewell 参与机箱 / 电源类故障	L2 OEM 实现	部分 Dell 集成系统包含 Tracewell
报修 SLA 时限（如 4 小时响应）	L2 OEM 实现	随合同 / 区域 / 严重性变化
报修电话号码	L2 OEM 实现	随 Dell 区域页面变化
Microsoft 侧技术支持入口（portal.azure.com 工单）	L1 微软硬要求	微软的标准接口
紧急 Severity A 工单处理流程	L3 最佳实践	来自经验
三方博弈中的客户主动权	L3 最佳实践	客户可加速升级
"硬件 vs 软件"快速判定法	L3 最佳实践	来自经验的判断规则
等 SupportAssist 数据自动上传而不是立刻打电话	L3 最佳实践	取决于严重性

9.1 跨 OEM 的差异风险

L2 OEM 实现差异 ：本文以 Dell Integrated System for Microsoft Azure Stack Hub 14G 视角整理；其他集成系统的支持流程在以下方面可能差异：

OEM 厂商（如 HPE / Lenovo / Cisco）--- 硬件责任方不同

集成系统世代（13G / 14G / 15G（Azure Stack 不存在）/ 16G）--- 部分支持流程已 EOL 不再支持

CSR / 合同条款 --- SLA 时限可能不同

SupportAssist 等价产品 --- 各 OEM 自有远程诊断工具

现场服务团队 --- 由各 OEM 自有渠道派遣
L3 最佳实践 ：本文的"Dell 14G 视角"在其他集成系统上适用原则相同，但具体编号 / 联系方式 / SLA 不同------参考各自 OEM 的 Support Matrix 与 Service Manual。

10. 三大误判信号：报修时最常踩的坑

10.1 误判 #1：客户绕过 Dell 直接报修 Microsoft

现象：客户尝试从 portal.azure.com 直接对 Azure Stack Hub 资源开 Microsoft SR。

结果：

微软可能拒绝受理（因为是 OEM 客户路径）
或承接后回退到 Dell------浪费双方时间

正解：

直接联系 Dell------Dell 内部升级 Microsoft
至少同步通知 Dell 避免责任链断裂

10.2 误判 #2：SupportAssist 报警就直接大动干戈

现象：SupportAssist 报警显示某个组件异常（但生产仍可用）。

结果：

客户 / 管理员恐慌性应急操作反而引发更多问题
SupportAssist 报警本身是遥测报告，由 Dell 决定响应

正解：

让 SupportAssist 自动开 SR
等 Dell 工程师联系（或主动跟进 SR）
不要"自行修复" ------ 除非 OEM 指导

10.3 误判 #3：把 VM 内部问题报给"Dell / Microsoft"

现象：客户 VM 蓝屏 / 应用异常 / 性能差，直接找 Dell。

结果：

Dell 工程师判定不属于 Dell 责任范围------回退给客户
浪费客户 / Dell / MS 资源

正解：

租户应用层问题 是客户责任------客户 IT / ISV / OS 供应商
只在客户无法定位时才升级 Microsoft Azure Stack 工程师

11. 三条操作红线：报修时绝对不能越的边界

L1 微软硬要求 + L3 最佳实践 。以下是报修时绝对不能越的边界。

11.1 红线 #1：不经 Dell 直接跳到 Microsoft

越界行为	后果
客户直接打 Microsoft Support	通常被回退到 Dell；可能因流程问题被延长
在 Microsoft 工单系统中针对 Azure Stack Hub 开 SR	主体不对，可能失效
私下联系 Microsoft 工程师	绕过支持流程；可能被标记为非授权

L1 微软硬要求：必须经过 Dell 才能升级 Microsoft------否则渠道不连续。

11.2 红线 #2：在生产时段未经授权执行"修复操作"

越界行为	后果
在 SR 处理期间自行重启 ERCS	破坏 PEP 完整性
在 SR 处理期间手工触发 Update Bundle	可能导致数据风险
在 SR 处理期间擅自更换硬件	与 Dell S&DS Field 流程冲突

L3 最佳实践：所有"修复操作"应在 OEM / Microsoft 工程师指导下执行------这是支持流程的核心约束。

11.3 红线 #3：把 PII（个人可识别信息）/敏感数据泄露在工单中

越界行为	后果
在工单描述中包含真实姓名 / 身份证号 / 银行卡	合规事件
在工单附件中上传未加密的密钥	安全事件
在工单系统外沟通敏感信息	审计漏洞

L1 微软硬要求 ：Dell / Microsoft 工单系统对客户数据保密，但客户仍应最小化敏感数据进入工单------使用专用测试账号 / 假数据代替真实数据。

12. 报修篇小结：应急流程的工程化整合

12.1 报修时"10 秒速查"

现象	速判	报修
物理硬件异常	硬件	Dell EMC
管理员门户异常	软件平台	Dell → Microsoft IPS
Update 失败	软件平台	Dell → Microsoft IPS
容量触顶	业务	客户 / 管理员
租户 VM 蓝屏	租户应用	客户 / ISV
SupportAssist 离线	硬件监控	Dell EMC

12.2 报修后"升级路径清单"

复制代码

Dell EMC 24x7 → Dell 一线工程师 → Dell 内部二线
                → IPS（Microsoft）→ AzS Hub Engineering
                → Product Group Engineering
                → 现场支持 Field Service
                → Tracewell Engineering（特定硬件）

12.3 跨篇衔接

基础设施变更：超出客户授权的（如 Update Bundle 流程），由管理员 / 微软 IPS 处理------见第 1 篇。
租户侧故障：VM 内部问题是租户的责任------见第 2 篇。
三方博弈的本质：报修不是"Dell vs Microsoft"，而是"Dell + Microsoft 协作"------客户应在二者之间建立双向沟通。

12.4 持续维护建议

联系人清单 ------ 维护一份"Dell / Microsoft / ISP / 现场工程师"联系表（每季度更新）
SupportAssist 状态监控 ------ 确保 SupportAssist 始终在线（SLA 报告依赖它）
SR 历史归档 ------ 内部维护每次 SR 的处理记录（搜索、复用经验）
紧急场景演练 ------ 至少每年演练一次"Dell + MS 联合报修"（如一年一次桌面演练）

附录 A：报修场景速查表

现象	主要责任	联系方式	SLA（建议）
硬盘故障	Dell EMC	Dell 电话	4-24 小时
服务器掉电	Dell EMC	Dell 电话	紧急（4-8 小时）
Portal 无法访问	Microsoft via Dell	Dell 电话 → MS	8-24 小时
Update 失败	Microsoft via Dell	Dell 工单 → MS	8-48 小时
NSG 不生效	Microsoft via Dell	Dell 工单 → MS	8-48 小时
VM 蓝屏	客户 / ISV	客户	N/A
容量触顶	管理员 / 客户	内部	视情况
SupportAssist 离线	Dell EMC	Dell 电话	紧急（4-8 小时）
PEP 不可达	Dell + MS	Dell → MS	紧急（4-8 小时）
租户 RDP 不通	客户（通常 NSG）	客户	N/A

附录 B：常见报修术语速查

术语	含义	L 分类
SR（Service Request）	服务请求 / 工单	L2 OEM 实现
Severity A / B / C / D	工单严重性等级	L2 OEM 实现
IPS（International Product Support）	微软侧全球产品支持	L1 微软硬要求
SST（Solutions Support Team）	Dell 与 Microsoft 联合支持	L2 OEM 实现
S&DS	Dell 现场服务团队	L2 OEM 实现
PE（Product Engineering）	厂商产品工程	L2 OEM 实现
CSP（Cloud Solution Provider）	微软 CSP 合作伙伴	L2 OEM 实现
SupportAssist	Dell 远程监控 / 自动化诊断	L2 OEM 实现
Tracewell Engineering	部分 Dell 集成系统的机箱/电源供应商	L2 OEM 实现
PEP（Privileged Endpoint）	Azure Stack Hub 特权终结点	L1 微软硬要求
StampInformation	Azure Stack Hub 部署摘要文件	L1 微软硬要求

附录 C：本文相关资源链接参考

L0 版本事实 ：以下链接随微软 / Dell 文档演进可能变化------应以当期"Dell Azure Stack Hub Support Matrix / Microsoft AzS Hub Documentation" 为准。

Dell Azure Stack Hub Support：https://www.dell.com/support/（具体编号因区域 / 合同而异）
Microsoft Azure Stack Hub Operator / User Documentation：https://learn.microsoft.com/en-us/azure-stack/（具体页面以当期微软文档树为准）
Azure Portal 工单系统：https://portal.azure.com → 帮助 + 支持 → 创建支持工单

本文版本 ：v1.0（首发 · 2026-07-30）维护：Azure Stack Hub 运维管理三篇系列 · 报修篇 写作依据 ：内训演示材料《Azure Stack Hub 运维管理》（报修与技术支持章节）整理 + Dell Integrated System for Microsoft Azure Stack Hub Support Process + Microsoft AzS Hub Documentation + 实操经验 下次修订触发：Dell / Microsoft 支持合同结构变化、SupportAssist 重大变更、新一代集成系统（16G+）支持流程调整

Azure Stack Hub 报修与技术支持：Dell + Microsoft 双供应商协同支持流程

修订说明：

目录

1. 报修与技术支持的全景：三方博弈

1.1 三方核心架构

1.2 关键角色清单

1.3 三方博弈的本质

2. 支持矩阵的硬性事实：哪些问题归谁

2.1 故障归属的三大判别类别

2.2 "硬件 vs 软件"的快速判断法

2.3 责任边界案例

3. Dell 集成系统支持流程：12 步全景图

3.1 提供的 12 步流程

3.2 12 步流程详解

3.3 流程的工程实质

3.4 Tracewell Engineering 的作用

3.5 SupportAssist Enterprise

4. 升级路径：什么情况下需要升级

4.1 升级路径全景

4.2 升级的 6 类触发条件

4.3 升级流中的 JIRA 用途

4.4 升级时效（L2 OEM 实现差异）

5. Dell EMC 报修渠道：电话 + Web + 邮件

5.1 原文

5.2 渠道的多维对比

5.3 电话号码的多区域理解

6. Microsoft 报修渠道：Azure Portal 优先

6.1 原文

6.2 为什么 Azure Portal 是 Microsoft 侧的"标准入口"

6.3 Microsoft 报修的具体步骤

6.4 关于 Microsoft 对 Azure Stack Hub 的支持

6.5 Microsoft Support 路径与 Dell 路径的关系

7. 四条故障归属判定方法：10 秒定位责任方

7.1 判别方法 #1：物理部件测试法

7.2 判别方法 #2：管理员门户可见性法

7.3 判别方法 #3：警报严重性法

7.4 判别方法 #4：时间相关性法

7.5 综合判别表

8. 四类典型案例：故障发生时的完整 SOP

8.1 案例 #1：物理硬盘故障

8.2 案例 #2：Update Bundle 安装失败

8.3 案例 #3：管理员门户无法访问

8.4 案例 #4：租户体验性能下降

8.5 案例联合总结

9. 四层原则落地：支持流程的版本依赖与差异

9.1 跨 OEM 的差异风险

10. 三大误判信号：报修时最常踩的坑

10.1 误判 #1：客户绕过 Dell 直接报修 Microsoft

10.2 误判 #2：SupportAssist 报警就直接大动干戈

10.3 误判 #3：把 VM 内部问题报给"Dell / Microsoft"

11. 三条操作红线：报修时绝对不能越的边界

11.1 红线 #1：不经 Dell 直接跳到 Microsoft

11.2 红线 #2：在生产时段未经授权执行"修复操作"

11.3 红线 #3：把 PII（个人可识别信息）/敏感数据泄露在工单中

12. 报修篇小结：应急流程的工程化整合

12.1 报修时"10 秒速查"

12.2 报修后"升级路径清单"

12.3 跨篇衔接

12.4 持续维护建议

附录 A：报修场景速查表

附录 B：常见报修术语速查

附录 C：本文相关资源链接参考