Azure 老号 Azure微软云故障排除

前言：云不是魔法，是流水账

Azure（微软云）一旦出问题，很多人第一反应是：“怎么又坏了？”然后在控制台里疯狂点点点，搜一堆关键字，最后发现最重要的那一步——先搞清楚“到底哪里坏了”——还没做。

我理解这种挫败感。云环境复杂：网络、身份、资源、权限、路由、证书、DNS、配额、区域容量……每一个环节都可能成为“罪魁祸首”，还经常带着“我看起来没问题”的伪装。

所以这篇文章给你一个可落地的故障排除框架：不追求一口气解决所有问题，而是让你用更少的试错，把定位速度拉上去。你会看到一套“先范围、后证据、再假设、最后验证”的流程，也会穿插一些常见踩坑案例。放心，不讲玄学，只讲方法。

Azure 老号 故障排除的核心思路：从“像”到“准”

故障排除通常分四步走：

• 观察现象：错误信息、影响范围、发生时间、频率与持续时间。
• 确定范围：是单一资源、某个订阅、某个区域，还是全局服务波动？
• Azure 老号 收集证据：日志、指标、告警、配置差异、网络路径、DNS 解析结果。
• 验证假设：用最小代价的方式验证推断（比如回放请求、切换区域、替换证书、比较前后版本）。

你会发现：一旦你严格按这个流程来，很多“看似灾难”的问题会逐渐变得可控。云故障就像找漏水：你先别急着拧总阀门，你要先判断水是从屋顶滴还是从管道渗。

准备工作：让你少跑一圈冤枉路

在真正遇到故障之前，建议你把以下“基础材料”准备好。不是为了装专业，而是为了关键时刻别手忙脚乱：

• 资源清单：涉及的资源类型、名称、所在区域、资源组、依赖关系。
• 最近变更记录：最近有没有部署、升级、重置密钥、改 DNS、调整网络安全组（NSG）、替换证书？
• 访问路径图：从客户端到服务端的链路（比如 CDN/Front Door → Load Balancer → VM/容器 → 存储/数据库）。
• 告警与监控：你用的是什么监控方式（Azure Monitor、Log Analytics、App Insights、第三方监控）以及告警规则。
• Azure 老号 权限信息：谁能改什么？是否需要排查 RBAC/策略（Policy）导致的“看不见”或“改不了”。

如果你已经有这些，那恭喜你：你比很多“临时抱佛脚”的团队领先一个时代。

排查流程总览：一张“问诊单”

遇到 Azure 故障时，可以按下列顺序逐项确认。为了更贴近实际，我把它写成“问诊单式”的清单。

1）先问：影响是什么？用户体验怎么说的？

• 报错是 超时、连接被拒绝、还是 权限不足？
• 是所有用户还是部分用户？是否只发生在特定网络（例如企业网络、特定地区、IPv6）？
• 是某个接口/功能异常还是整个服务不可用？

一句话：错误类别决定方向。超时通常跟网络/路由/防火墙有关；权限不足通常跟身份与访问控制有关。

2）再问：范围有多大？只在你这边，还是 Azure 本身？

• 是否是单一订阅/资源组？
• 是否只影响某个区域（比如 East US）？
• 是否同时影响多个服务或应用？

这一步非常关键。很多人忙着在自己代码里找“bug”，其实是区域网络波动或者某项服务发生了影响。

3）记录时间线：发生前做了什么？

• 故障开始的时间点是什么？
• 前后是否有发布、扩缩容、证书轮换、密钥更新、DNS 变更、策略（Policy）应用？
• 有没有“批量变更”但你没注意它的影响范围？

如果你把这一步做扎实，定位速度会提升一大截。因为很多故障其实是“你不小心把手伸进了老虎笼”。

4）收集证据：用指标和日志把“感觉”变成“事实”

• 应用层：请求量、错误率、响应时间分布、关键依赖的失败情况。
• 基础设施：CPU/内存/磁盘、网络吞吐、连接数、延迟、资源重启记录。
• 平台层：诊断日志、资源运行状况、失败原因（比如 Load Balancer 探测失败）。

别急着改东西。先看证据说什么。

5）形成假设：别发散，先锁定优先级

你可以按“概率 + 影响面”排序假设。常见优先级通常是：

• 最近变更相关的假设
• 网络/安全相关的假设
• 身份/权限相关的假设
• 容量/配额/依赖超时相关的假设

例如：如果今天刚替换了 TLS 证书，那么优先怀疑证书链、SNI、到期时间、绑定关系，而不是先怀疑数据库。

6）用最小代价验证：确认后再动“刀”

验证策略建议：

• 对照测试：从不同地区、不同网络（有条件的话用外网访问/内网访问对比）。
• 回放请求：用同一请求对比故障前后的响应。
• 切换路径：临时把流量切换到备用实例/备用区域。
• 替换关键组件：比如证书、DNS 解析、NSG 规则（先在测试环境或通过最小范围修改）。

常见故障类型与排查指南（按场景来）

下面进入“好用的部分”：把常见问题按场景拆开。你只要对号入座，就能把排查落到具体动作。

场景一：服务不可用 / 连接超时

表现：用户访问失败，浏览器显示“超时”，或 API 返回 5xx/网关超时。

可能原因（按常见度排序）

• 网络层阻断：NSG、UDR（路由表）、防火墙规则、端口不开放。
• 负载均衡探测失败：探测端点不通导致实例被摘除。
• DNS 解析错误：解析到错误 IP 或旧地址。
• 证书/HTTPS 握手问题：表面看是超时，实则握手失败或被重置。
• 应用层卡死或依赖不可用：导致响应延迟，最终触发超时。

排查动作

• 看错误细节：浏览器/客户端是否有 DNS 解析日志、TLS 报错、连接重置？
• 检查负载均衡与探测：验证后端实例是否 Healthy。若使用自定义探测，确认探测路径与端口正确。
• 核对 NSG：入站/出站规则是否允许对应端口；是否最近改动过优先级（规则顺序影响命中结果）。
• 验证路由：是否把流量错误导向了 NVA/防火墙？路由表是否改变？
• 从网络上做连通性验证：用跳板或同 VNet 内的工具（telnet/curl/nc）检查端口和响应。

踩坑瞬间（常见得像例行公事）

有一次我们排查“突然全站超时”，大家都以为是应用挂了。结果发现 Load Balancer 的探测路径被某次发布改了，但 LB 还在用旧路径；探测全失败，于是后端被摘光。应用其实还活着，只是没人敢把流量往它那儿送。

结论：当你遇到“超时 + 健康检查怪怪的”，请先看健康检查，再看应用。

场景二：权限失败 / 身份认证错误（401/403）

表现：登录失败、调用 ARM/资源时提示没有权限，或访问存储/数据库返回 401/403。

可能原因

• RBAC 角色变更或不正确：角色没给对 scope（订阅/资源组/资源级别）。
• 托管身份（Managed Identity）被禁用、权限缺失或路径变了。
• 应用注册（App Registration）凭据过期：client secret 到期、证书过期。
• 条件访问或策略（Azure Policy）导致拒绝。

排查动作

• 确认错误来源：是登录 token 获取失败，还是调用具体资源时拒绝？
• 核对 scope：权限是给了订阅还是只给了资源组？调用的资源在不在这个范围？
• 检查 Managed Identity：身份是否启用？角色是否绑定到了正确的存储/密钥/数据库 scope？
• 看策略影响：如果启用了 Azure Policy，可能是限制了某些动作（比如禁止公开访问、限制某些网络设置）。
• 凭据有效性：检查证书/secret 是否过期，是否在部署时被替换。

踩坑瞬间

团队里有人说：“我们权限都配好了，肯定没问题。”然后错误日志显示 403，但 RBAC 实际是给了某个“看起来同名但不同 resource group 的资源”。Azure 控制台通常不帮你做“同名资源”这种温柔提示。你要做的，是把 scope 精确到资源。

场景三：DNS 解析异常 / 域名访问失败

表现：域名解析不对、解析到旧 IP、偶尔可用偶尔不可用，或浏览器提示证书与域名不匹配。

可能原因

• DNS 记录指向了错误的终端（旧入口、已下线资源）。
• TTL 过长导致变更后“怎么还不生效”。
• DNS 与证书绑定不一致（尤其是通配符/多域名证书）。
• 缓存问题：本地缓存、递归 DNS 缓存、CDN 缓存。

排查动作

• 做全链路解析对比：用不同网络环境分别查询（比如公司网 vs 手机热点），确认解析结果是否一致。
• 核对记录类型：A/AAAA/CNAME 是否正确，是否意外改成别的指向。
• 结合证书检查：TLS 证书的 CN/SAN 是否覆盖你的域名？链路是否使用正确证书？
• 考虑缓存：如果你刚改 DNS，TTL 影响是现实存在的；不要用“秒回原样”的标准判断。

场景四：虚拟机（VM）异常 / 应用启动失败

表现：VM 停机、重启、无法通过 SSH/RDP 连接、应用服务进程起不来。

可能原因

• 网络安全（NSG/端口未开/路由问题），导致你连不上。
• 磁盘耗尽：日志打爆、系统盘满导致服务崩。
• 资源被压到极限：CPU/内存不足引发 OOM。
• 启动脚本/扩展失败：自定义脚本、VM 扩展错误。

排查动作

• 先确认 VM 状态：是否被触发重启？是否有“平台原因”的记录。
• 检查串行控制台/诊断日志：看启动阶段是否有错误信息。
• 看磁盘空间：至少检查系统盘剩余，确认没有“差一丁点就满”的情况。
• Azure 老号 应用进程与端口：应用是否监听正确端口？服务是否起了吗？
• 检查 VM 扩展：如果你用扩展做配置（例如监控代理、部署脚本），错误会直接导致配置不完整。

踩坑瞬间

有一次我们排查 VM 无法访问，结果不是网络问题，而是磁盘满了。应用启动失败，但外面看起来就是“连接不上”。你会发现：故障的表象经常比你想象更狡猾。

场景五：存储（Storage）读写失败 / 性能突降

表现：Blob/Queue/Table 读写异常，或出现大量超时、延迟上升。

可能原因

• 访问策略或 SAS 过期：令牌到期导致 403/401。
• 网络规则限制：Storage 账户启用防火墙/虚拟网络规则导致请求被拦。
• 容量与限制：吞吐不足、连接数过多。
• 应用请求模式异常：批量并发导致瞬时写入冲击。

排查动作

• 检查 token 有效性：SAS 是否到期？权限是否足够（读/写/列出）？
• 核对网络访问：调用方所在网络是否被允许？Storage 的公共访问策略是否改变？
• 查看存储诊断日志：失败原因通常会写得很直接（比如身份验证失败、网络拒绝、限流）。
• 对比性能指标：看是请求量增长还是延迟突然抬升。

场景六：数据库连接失败 / 查询慢

Azure 老号 表现：连接超时、失败重试、数据库响应慢导致应用整体变慢。

可能原因

• 网络层问题：私网访问、NSG/防火墙规则不通。
• 连接池耗尽：应用并发导致连接建立或保持失败。
• 资源不足：DTU/vCore、CPU/IO 达到上限。
• 死锁或慢查询：执行计划变化、索引缺失。

排查动作

• 先判断是“连不上”还是“慢”：连不上更偏网络与权限；慢更偏性能与查询。
• 检查连接与重试：应用日志通常能告诉你是超时、还是认证失败、还是连接被拒。
• 看数据库指标：CPU、IO、等待队列、锁等待。
• 定位慢查询：结合慢查询日志/查询分析，找执行计划与索引问题。

场景七：容器服务（AKS）或应用网关异常

表现：Kubernetes Pod 重启、Ingress 不通、负载均衡不健康，或网关报 502/504。

可能原因

• 镜像拉取失败：私有镜像凭据过期。
• 网络策略影响：NetworkPolicy/NSG 导致流量被拒。
• Ingress/Service 配置错误：端口映射不一致。
• 自动扩缩容滞后：流量上升但实例没跟上。

排查动作

• 看 Pod 状态：CrashLoopBackOff、Pending、ImagePullBackOff 等都有典型原因。
• 看事件（Events）：K8s 的事件列表非常“直白”，经常直接告诉你谁在失败。
• 检查 Ingress Controller：健康检查、默认后端、路由规则。
• 检查 Secret/镜像拉取：registry 凭据是否过期、Secret 是否存在且绑定正确。

当你不知道从哪儿开始：用“证据链”定位

有时你会遇到：错误很泛、日志不完整、用户反馈也不统一。别慌，仍然可以用证据链方法。

你可以把整条链路拆成三段，每段都回答一个问题：

• 请求是否到达入口？（CDN/Front Door/Ingress/LB 是否记录了请求）
• 入口是否转发到后端？（探测/路由/后端健康状态）
• 后端是否处理完成？（应用日志、依赖服务、超时与错误码）

只要你能在这三段里明确“卡在第几段”，剩下的就好办了。故障排除的本质，就是把不确定性切成可验证的小问题。

监控与告警：别等故障发生才想起它们

Azure 故障排查离不开监控。更准确地说：你要让监控在“没发生”时就能帮你判断“发生了什么”。

Azure 老号 建议你至少配置这些告警维度

• 基础设施：CPU、内存、磁盘、网络吞吐、错误连接数。
• 应用指标：请求成功率、错误率、响应时间 P95/P99、关键接口失败。
• 依赖服务：数据库/存储/API 的超时与错误率。
• 健康状态：LB 探测、容器就绪状态、服务不可用比例。

告警不是越多越好，而是要“跟故障定位有关”。如果告警告诉你“CPU 很高”，但你不知道它和你那条线上接口有什么关系，那它就像报警器响了，但你不知道是火还是猫。

服务健康与区域问题：别把锅全甩给你自己

很多团队在遇到问题时首先怀疑代码、怀疑配置，最后才想到 Azure 平台可能也在波动。虽然你们的代码可能确实有 bug，但云平台的状态也要看。

当你发现以下情况，建议你同步检查平台健康状况：

• 多个订阅或多个应用同时异常（且与你的改动无明显相关）。
• 同一区域资源普遍出现相似问题。
• 错误类型集中在网络连接、服务响应、认证波动等平台层。

平台波动不意味着你可以不排查，但它会显著改变你的优先级：先确认是不是“天塌了”，再决定是否“修你家屋顶”。

一份实用的“故障排查清单”（你可以直接打印贴墙）

下面这份清单是为“实战”准备的。你可以按顺序逐条勾选，直到找到明确根因或至少找到最有可能的方向。

• 故障开始时间与持续时间已确认。
• 影响范围已确认：单资源/单订阅/单区域/全局。
• 最近变更已确认：发布、证书轮换、DNS 修改、网络策略调整。
• 错误类型已分类：超时、连接失败、权限失败、应用错误码。
• 入口链路已确认：请求是否到达（网关/负载均衡日志）。
• 转发链路已确认：后端健康检查是否通过。
• 网络策略已检查：NSG、防火墙、路由表、私网访问与端口。
• 身份权限已检查：RBAC、Managed Identity、SAS/凭据有效性。
• 应用依赖已检查：数据库/存储/API 是否报错或超时。
• 资源容量与配额已检查：CPU/内存/连接数/吞吐/配额不足。
• 日志与指标已汇总：能形成证据链的那种，而不是“感觉”。
• 验证动作已执行：最小代价验证假设，并记录结果。

如何写好排查记录：让下次更快

故障排查不仅是“把问题解决”，更是“让团队复用经验”。建议你写三段式记录：

• 现象：发生了什么？用户说了什么？错误码/日志摘录是什么？
• 过程：你检查了哪些点？每一步得到了什么证据？
• 结论与复盘：根因是什么？如何防止再次发生？未来需要哪些监控或自动化？

如果你能把这三段写清楚，下次你再遇到同类故障，基本不会再从“茫茫大海”里重新找一遍。

结束语：云故障排除的态度，比技术更重要

Azure 的故障排除看起来复杂，但它并不神秘。你真正需要的是：流程、证据、优先级和复盘。不要急着“改到天亮”，先把范围和错误类型搞清楚；不要只看自己系统，也要考虑平台健康与区域波动；不要把“可能”当成“确认”，用验证动作让假设闭环。

最后送你一句大实话：当你已经排查了五十分钟却找不到根因时，不要加速瞎猜。停下来，把问题写成一句清晰的描述：“在什么条件下、出现什么错误、影响哪些范围、前后发生过哪些变更。”你会惊讶地发现，根因往往在你写下这句话的瞬间，悄悄露了头。

愿你在 Azure 的故障现场，永远是那个冷静、条理清晰、还能顺手把日志整理干净的人。毕竟，团队需要的不只是英雄，还有会记录的人。