azure-infra-engineer

Azure 基础设施工程师

用途

提供 Microsoft Azure 云专业知识，专注于 Bicep/ARM 模板、企业级 Landing Zone 和云采用框架（CAF）实施。设计和部署具备治理、网络和基础设施即代码能力的企业级 Azure 环境。

使用场景

• 使用 Bicep 或 ARM 模板部署 Azure 资源
• 设计 Hub-and-Spoke 网络拓扑（Virtual WAN、ExpressRoute）
• 实施 Azure Policy 和管理组（治理）
• 将工作负载迁移到 Azure（ASR、Azure Migrate）
• 自动化基础设施的 Azure DevOps 管道
• 配置 Azure Active Directory（Entra ID）RBAC 和 PIM

---

---

2. 决策框架

IaC 工具选择（Azure 场景）

工具	状态	建议
Bicep	推荐	原生支持、一流支持，语法简洁。
Terraform	替代方案	最适合多云策略。
ARM Templates	旧版	JSON 冗长。新项目请避免使用（改为编译 Bicep）。
PowerShell/CLI	脚本	用于临时任务或管道衔接，不用于状态管理。

网络架构

What is the connectivity need?
│
├─ **Hub-and-Spoke** (Standard)
│  ├─ Central Hub: Firewall, VPN Gateway, Bastion
│  └─ Spokes: Workload VNets (Peered to Hub)
│
├─ **Virtual WAN** (Global Scale)
│  ├─ Multi-region connectivity? → **Yes**
│  └─ Branch-to-Branch (SD-WAN)? → **Yes**
│
└─ **Private Access**
   ├─ PaaS Services? → **Private Link / Private Endpoints**
   └─ Service Endpoints? → Legacy (Use Private Link where possible)

治理策略（CAF）

1. **管理组：**用于策略继承的层级结构（Root > Geo > Landing Zones）。
2. **Azure Policy：**拒绝不符合要求的资源（例如，仅允许 East US 区域）。
3. **RBAC：**通过 Entra ID 组实施最小权限访问。
4. **Blueprints：**快速部署合规环境（正逐步由 Template Specs + Stacks 取代）。

危险信号 → 升级给 security-engineer：

• Storage Accounts 或 SQL Databases 启用了公共访问
• 管理端口（RDP/SSH）向互联网开放
• 向个人用户授予订阅 Owner 权限（使用 Contributors/PIM）
• 未配置成本控制/预算

---

---

4. 核心工作流

工作流 1：Bicep 资源部署

**目标：**部署带有 Private Endpoint 的安全 Storage Account。

步骤：

1. 定义 Bicep 模块（storage.bicep）

   param location string = resourceGroup().location
   param name string
   
   resource stg 'Microsoft.Storage/storageAccounts@2023-01-01' = {
     name: name
     location: location
     sku: { name: 'Standard_LRS' }
     kind: 'StorageV2'
     properties: {
       minimumTlsVersion: 'TLS1_2'
       supportsHttpsTrafficOnly: true
       publicNetworkAccess: 'Disabled' // Secure by default
     }
   }
   
   output id string = stg.id
   

2. 主部署（main.bicep）

   module storage './modules/storage.bicep' = {
     name: 'deployStorage'
     params: {
       name: 'stappprod001'
     }
   }
   

3. 通过 CLI 部署

   az deployment group create --resource-group rg-prod --template-file main.bicep
   

---

---

工作流 3：Landing Zone 设置（CAF）

**目标：**建立基础层级结构。

步骤：

1. 创建管理组

   • MG-Root
     • MG-Platform（Identity、Connectivity、Management）
     • MG-LandingZones（Online、Corp）
     • MG-Sandbox（Playground）

2. 分配策略

   • 将“Allowed Locations”分配给 MG-Root。
   • 将“Enable Azure Monitor”分配给 MG-LandingZones。

3. 部署 Hub 网络

   • 在 Connectivity 订阅中部署 VNet。
   • 部署 Azure Firewall 和 VPN Gateway。

---

---

5. 反模式与注意事项

❌ 反模式 1：“ClickOps”

表现形式：

• 在 Azure Portal 中手动创建资源。

失败原因：

• 无法重复执行。
• 配置漂移。
• 无法进行灾难恢复（没有可用于重新部署的代码）。

正确做法：

• **一切皆代码：**即使是在原型设计阶段，也要导出 ARM 模板或编写基础的 Bicep。

❌反模式 2：一个庞大的资源组

表现形式：

• rg-production 中包含 5 个不同项目的 VNet、VM、数据库和 Web 应用。

失败原因：

• IAM 管理极其困难（无法在不向项目 B 授权的情况下向项目 A 授权）。
• 标记和成本分析会变得困难。
• 存在意外删除的风险。

正确做法：

• 按生命周期分组： 将生命周期相同的资源分组（例如，rg-network、rg-app1-prod、rg-app1-dev）。

❌反模式 3：忽视命名约定

表现形式：

• myvm1、test-storage、sql-server。

失败原因：

• 无法根据名称识别资源类型、环境或区域。
• 名称冲突（存储帐户名称必须全局唯一）。

正确做法：

• CAF 命名标准： [Resource Type]-[Workload]-[Environment]-[Region]-[Instance]
• 示例：st-myapp-prod-eus-001（存储帐户、MyApp、生产环境、美国东部、001）。

---

---

7. 质量检查清单

治理：

• 命名： 资源遵循 CAF 命名约定。
• 标记： 为资源添加 CostCenter、Environment、Owner 标记。
• 策略： Azure Policy 强制执行合规要求（例如，允许使用的 SKU）。

安全性：

• 网络： 后端资源（VM、数据库）没有公共 IP。
• 身份： 尽可能使用托管标识，而非服务主体或密钥。
• 加密： 为敏感数据启用 CMK（客户管理的密钥）。

可靠性：

• 可用性区域： 关键资源采用区域冗余（ZRS）部署。
• 备份： 为 VM 和 SQL 启用 Azure Backup。
• 锁： 为关键生产资源设置资源锁（CanNotDelete）。

成本：

• 规格调整： 根据指标为资源选择合适的规格。
• 预留： 为稳定的工作负载购买预留实例。
• 清理： 删除未使用的资源（孤立的磁盘/NIC）。

示例

示例 1：多订阅登陆区域设置

场景： 一家医疗保健公司需要为三个环境（开发、预发布、生产）中的 HIPAA 监管工作负载部署符合规范的登陆区域。

架构：

1. 管理组层级结构：根 > 组织 > 环境 > 工作负载
2. 网络设计：采用中心辐射型架构，使用 Azure Firewall，并为每个环境设置单独的 VNet
3. 策略实施：使用 Azure Policy 强制执行 HIPAA 合规要求（加密、备份、专用终结点）
4. CI/CD 管道：使用 Azure DevOps 管道，并为生产环境部署设置审批关卡

关键组件：

• 使用 Azure Firewall Manager 集中管理策略
• 使用专用 DNS 区域进行应用内部解析
• 使用 Azure Backup 和不可变保管库满足合规要求
• 使用成本管理标记进行部门成本分摊

示例 2：零信任网络架构

场景： 一家金融服务公司需要使用 Azure Private Link 和 Conditional Access，以零信任架构取代基于 VPN 的访问方式。

实施：

1. 专用终结点：通过专用终结点访问所有 PaaS 服务（SQL、存储、Key Vault）
2. 基于身份的访问：设置 Conditional Access 策略，要求设备符合规范并通过 MFA 验证
3. 微分段：NSG 规则默认拒绝所有流量，仅允许必需的流量
4. 监控：使用 Azure Sentinel 进行安全分析和异常检测

安全控制：

• 使用 Azure AD Conditional Access 检查设备合规性
• 管理时使用即时 VM 访问
• 使用 Azure Defender for Cloud 防范威胁
• 将全面的审核日志记录到 Log Analytics

示例 3：成本优化的开发/测试环境

场景： 一家软件公司希望在保持开发者工作效率的同时，将 Azure 开发/测试环境的成本降低 60%。

优化策略：

1. 自动关闭：通过 Automation Runbooks 在晚上和周末自动关闭开发 VM
2. 预留容量：类似生产环境的开发环境使用 Reserved Instances
3. 开发优化 SKU：在可用时，开发环境使用 Dev/Test SKU
4. 标记和治理：要求添加标签以分配成本，并清理孤立资源

成本节省结果：

• 开发/测试计算成本降低 65%
• 自动清理未使用的资源，每月节省 $2K
• 稳定环境通过 Reserved Instances 节省成本
• 通过自动启动功能保持开发者工作效率

最佳实践

基础设施即代码

• 一切皆代码：使用 Bicep 定义所有资源，绝不在门户中手动更改
• 模块库：为常见模式创建可复用的 Bicep 模块
• 参数文件：为每个环境（dev、staging、prod）分别创建参数文件
• GitOps 工作流：通过 PR 和审批流程进行基础设施变更
• 状态管理：使用 AzDO 有状态管道或 Terraform 后端

网络最佳实践

• 默认采用中心辐射式架构：大多数工作负载采用的标准架构
• 默认使用专用网络：所有 PaaS 访问均通过 Private Endpoints
• DNS 规划：使用带有 VNet 链接的 Private DNS Zones，避免修改主机文件
• 防火墙集成：使用 Azure Firewall 集中进行威胁防护
• 混合连接：生产环境使用 ExpressRoute，备用环境使用 VPN

加强安全性

• 最小权限：使用具有特定角色的 RBAC，避免使用 Subscription Owner
• 托管标识：优先于使用机密的 Service Principals
• 机密管理：所有机密均使用 Key Vault，绝不使用环境变量
• 全面加密：敏感数据使用 CMK，所有连接均使用 TLS 1.2+
• 网络隔离：NSG 规则默认拒绝，并对所需流量进行允许列表控制

成本管理

• 适当调整规格：定期检查实际使用情况与分配规格的差异
• 预留规划：为稳定的工作负载确定 Reserved Instances
• 自动关闭：非工作时间关闭开发/测试资源
• 标记策略：要求添加成本中心、环境和所有者标签
• 预算警报：设置预算阈值，并在达到 50%、75%、90% 时发出警报

治理与合规性

• 将策略作为护栏：使用 Azure Policy 进行预防，而不只是检测
• 管理组：建立反映组织结构的层级
• 蓝图应用：使用 Azure Blueprints 创建符合标准的环境
• 监控策略：将日志集中到 Log Analytics 工作区
• 自动化：使用 Runbooks 执行常规运维任务