Azure 租户开通 微软云 Azure 账号项目删除恢复

删错项目？先别关窗口，你还有机会

凌晨两点，咖啡见底，你刚执行完 az group delete --name prod-rg --yes，回车键按下去的瞬间，屏幕一黑——不是电脑蓝屏，是你的心跳骤停。三秒后你猛拍大腿：等等！那个RG里藏着上个月客户验收用的API密钥轮换记录，还有没备份的自定义策略分配……

别急着删历史记录、别慌着给微软Support发加急工单，更别立刻去翻备份硬盘（如果有的话）。在Azure世界里，“删除”从来不是一声清脆的“咔嚓”，而是一场带缓冲区的慢动作——只要你没关掉那扇窗，它可能还在后台喘气。

先搞懂：你删的到底是什么？

Azure里没有叫“项目”的官方术语——这是开发者和运维们从GCP或阿里云带过来的口语习惯。实际对应的是三个层级：资源组（Resource Group）、订阅（Subscription）、管理组（Management Group）。它们的关系像俄罗斯套娃：

• 资源组：最常用，是逻辑容器，比如dev-rg、prod-network-rg。删它=删里面所有资源（VM、存储、数据库），但不删订阅本身；
• 订阅：付费单位+权限边界，一个账号下可有多个订阅。删订阅=整个账单周期清零，所有资源组、策略、角色分配灰飞烟灭；
• 管理组：跨订阅治理层，删它只影响策略继承关系，不删任何资源。

所以第一件事：打开Azure门户，点左上角“所有资源”→右上角搜索框输入你删的名字，再看它出现在哪一级菜单里。如果搜不到？恭喜，它大概率进了“软删除队列”。

软删除：Azure悄悄留的后门

Azure 租户开通 Azure对两类资源开了“后悔药”通道：

• 资源组：启用软删除后，默认保留30天（不可调）；
• 密钥保管库（Key Vault）：软删除默认开启，保留90天，还能开“清除保护”锁。

注意！软删除不是自动生效的——资源组软删除需手动开启（新创建的订阅默认已开，老订阅请自查）。怎么查？PowerShell一句搞定：

Get-AzSubscription -SubscriptionId "xxx" | Get-AzResourceGroup | Where-Object {$_.ProvisioningState -eq "Deleting"}

或者用CLI看最近删过的RG：

az group list --query "[?contains(name, 'deleted')].{Name:name,Location:location}" -o table

如果返回空？别放弃——接着查操作日志。

操作日志：比监控更忠实的目击证人

Azure Activity Log（活动日志）默认保留90天，记录所有DELETE操作。路径：门户→左侧“监视器”→“活动日志”→筛选器设为“删除”+时间范围。重点看三列：

• 状态：显示“成功”还是“已取消”（有些删除会被策略拦截）；
• 调用方：确认是不是你本人操作，还是被CI/CD流水线误触发；
• 资源ID：复制这个长串ID，它是恢复的关键钥匙。

找到记录后，点击“JSON视图”，抄下resourceId字段值——别手敲，容易漏斜杠。

恢复实操：三步走，稳准狠

第一步：确认软删除是否存活
运行此命令（替换你的RG名和位置）：

az resource show --ids "/subscriptions/{sub-id}/providers/Microsoft.Resources/deletedResourceGroups/{rg-name}" --api-version "2020-10-01"

如果返回404，说明已过期或未启用软删除；若返回JSON含properties.provisioningState为Deleting，恭喜，它还活着。

第二步：执行恢复
一行命令唤醒它：

az resource invoke-action --action "restore" --ids "/subscriptions/{sub-id}/providers/Microsoft.Resources/deletedResourceGroups/{rg-name}" --api-version "2020-10-01"

注意：恢复后资源组会回到原位置，但内部资源状态可能不一致（比如VM是“已停止”而非“正在运行”），需手动启动。

第三步：验证+加固
进门户确认RG存在后，立刻做三件事：

1. 检查关键资源是否在线（别只看RG图标绿不绿）；
2. 导出当前策略分配：az policy assignment list --resource-group {rg-name} > policy-backup.json；
3. 给RG加锁：az lock create --lock-type CanNotDelete --resource-group {rg-name} --name "prevent-accidental-delete"。

恢复失败？这些坑我替你踩过了

你试了命令却报错？对照这份“翻车清单”：

• 错误：Operation returned an invalid status code 'Forbidden'
  → 权限不足。恢复操作需要Microsoft.Resources/deletedResourceGroups/restore/action权限，普通Contributor不够，得是Owner或Custom Role含该操作。
• 错误：The deleted resource group does not exist in the specified location
  → RG删之前在East US，你却查West US。软删除保留原位置，必须指定正确region参数。
• 错误：Resource group is not in soft-deleted state
  → 要么超时了，要么RG根本没开软删除（老订阅需管理员手动开通）。

血泪教训：三条铁律，救你于水火

铁律一：删前必锁，锁是免费的保险
所有生产RG，创建后第一件事就是加CanNotDelete锁。命令就一行，耗时3秒，能防80%的手抖事故。

铁律二：用命名规范代替记忆
别用test、temp这种词。强制约定：rg-prd-appname-001（环境-用途-序号），配合标签Team=FinanceBackupPolicy=Daily。删的时候看到标签就知道“这玩意儿老板上周刚签字验收”。

铁律三：自动化脚本里禁用--yes
CI/CD里所有az group delete必须删掉--yes，改用--no-wait + 人工审批环节。我们曾因Terraform apply时网络抖动导致重复执行，硬生生把灰度环境删了两遍。

最后说句实在话

Azure的恢复能力再强，也强不过一次快照、一个ARM模板、一份定期导出的策略备份。技术只是兜底手段，真正的安全网，是你写在Wiki里的《删除操作SOP》、团队晨会里反复强调的“三思后删”文化、还有每次执行前那10秒的深呼吸。

下次再想敲delete，试试先默念三遍：“我删的是什么？谁依赖它？有没有锁？日志在哪？”——这比背一百行PowerShell管用得多。

毕竟，在云的世界里，最贵的不是计算资源，是你重做的那三天时间，和客户发来的那封“你们系统又挂了”的邮件。