Azure Function App 长期 0 worker、应用与 SCM 同时 HTTP 503 时，核对诊断、订阅、存储与日志，区分代码故障和平台实例分配问题。
直接答案：Azure Function App 同时出现站点 HTTP 503、SCM/Kudu 503、ZIP 部署报 ServiceUnavailable from host runtime，并且“诊断并解决问题”显示长期为 0 个工作实例时，先不要反复改代码或删除资源。这组现象更接近函数宿主没有启动或平台没有分配工作实例；只有宿主已经运行、日志出现入口点或依赖错误时，才进入代码修复。
先在 Azure 门户打开“函数应用 → 诊断并解决问题 → Function App Down or Reporting Errors”。此检查不收费，也不会改动资源。重启会造成短暂中断；更换托管计划、重建应用或新增监控可能产生费用。
先确认是不是同一个 0 worker 故障
| 观察结果 | 更可能的方向 | 下一步 |
|---|---|---|
| 应用 503，但 SCM 可打开且有启动异常 | 代码、运行时或配置错误 | 查看 Application Insights 与宿主日志 |
| 应用和 SCM 都 503，诊断长期 0 worker | 宿主未获实例或平台侧异常 | 核对订阅、计划、资源提供程序和服务运行状况 |
| 应用可打开，只有某个函数 5xx | 函数代码、触发器或依赖问题 | 按执行日志修复 |
| 重启后短暂恢复又失败 | 启动配置、存储、资源压力或平台波动 | 保留时间线并检查配置与指标 |
从诊断入口收集不会改动资源的证据
- 进入目标函数应用，打开“诊断并解决问题”。
- 搜索并打开“Function App Down or Reporting Errors”，记录检查时间、工作实例数和问题代码。
- 打开“概述”，核对订阅状态是否为 Enabled，并记下资源组、区域、操作系统和托管计划。
- 打开“活动日志”，筛选创建、启动、停止、配置写入和部署失败事件。
- 若已启用 Application Insights，查看失败请求和异常；若没有宿主启动记录，也要如实记录“无日志”。
以下只读命令不会修改应用。把变量替换为实际值：
az account show --query "{subscription:id,state:state,tenant:tenantId}" -o table
az functionapp show --resource-group <资源组> --name <函数应用名> --query "{state:state,host:defaultHostName,kind:kind,plan:serverFarmId}" -o json
az monitor activity-log list --resource-group <资源组> --offset 2h --status Failed --max-events 50 -o table订阅应为 Enabled。活动日志有策略、配额、部署或资源提供程序错误时，先沿该错误处理；结果正常但仍长期 0 worker，平台侧证据更强。
排除会阻止函数宿主启动的配置
Azure Functions 依赖关联的存储账户管理触发器、日志和动态扩缩容。进入“设置 → 环境变量”，只核对设置是否存在，不要复制连接字符串。重点检查 AzureWebJobsStorage；Windows Consumption 或 Premium 还可能使用 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 与 WEBSITE_CONTENTSHARE。
若存储账户被删除、连接信息失效、网络规则拒绝访问，宿主可能无法启动。先恢复原存储可达性或回退最近一次配置，不要新建空存储后直接替换生产连接。
Node.js 应用已获得实例但入口点报错时，再检查运行时版本、package.json 和入口注册。可临时设置 FUNCTIONS_NODE_BLOCK_ON_ENTRY_POINT_ERROR=true 让入口错误进入日志；修改环境变量会重启应用，操作前记录原值。
什么时候重启，什么时候停止重建
没有正在处理的请求，且诊断没有指出配置写入进行中时，可在“概述 → 重启”执行一次。下面命令会造成短暂中断：
az functionapp restart --resource-group <资源组> --name <函数应用名>重启后应用与 SCM 仍为 503、诊断继续显示 0 worker 时，不要连续重启、跨区域批量新建或删除原应用。这些动作会增加费用和配置差异，也会破坏故障证据。
确认平台侧异常后提交支持请求
先检查 Azure Service Health。进入“帮助 + 支持 → 创建支持请求”，提供订阅、资源组、应用、区域、托管计划、503 的 UTC 时间、诊断中 0 worker 的持续时间、活动日志关联 ID，以及已核对的订阅和存储状态。不要提交存储密钥、发布配置文件、连接字符串或访问令牌。
修复后怎样验收和回退
- 诊断不再显示持续 0 worker，应用与 SCM 不再返回 503。
- 部署一个可识别版本，确认部署接口成功。
- 调用最小 HTTP 函数，确认返回预期状态码。
- 检查请求、异常和依赖，至少覆盖一次冷启动。
- 保存配置变更前后值和账单影响。
若新配置扩大故障，恢复原值并再次重启；平台恢复前业务不能等待时，从已验证的代码和配置部署备用应用，再切换流量。原应用要保留到日志、域名、密钥引用和回退路径均已核对。
联系 Telegram 客服 