MSaet10/azure-project-1-infrastructure

# Azure 基础设施部署项目 ## 项目概述 本项目演示了如何部署一个安全、可扩展且受监控的 Azure 基础设施环境。该环境包括虚拟网络、虚拟机、负载均衡、身份与访问管理、监控与警报、无服务器工作流、备份与灾难恢复、成本管理以及故障模拟。 本项目的目标是模拟真实的 Azure 云环境，并展示云工程、基础设施部署、监控、安全和运维排障技能。 ## 架构  ## 使用的技术 - Microsoft Azure - Azure Virtual Network (VNet) - Azure Virtual Machines (Windows Server) - Azure Load Balancer - Network Security Groups (NSGs) - Microsoft Entra ID - Azure RBAC - Azure Monitor - Log Analytics Workspace - Application Insights - Azure Functions - Azure Storage Account / Blob Storage - Recovery Services Vault - Azure Backup - Azure Cost Management - PowerShell - Azure CLI - Visual Studio Code ## 项目实施 ### 第 1 天 — 环境设置 通过创建和验证 Azure 订阅上下文、安装 Azure CLI 和本地工具、创建 `rg-cloud-project` 资源组，以及应用用于成本跟踪和组织的标签来设置 Azure 环境。 ### 第 2 天 — 网络层 通过创建带有分段子网（`web-subnet` 和 `app-subnet`）的 `vnet-cloud-project` 虚拟网络、创建 Network Security Groups、添加针对 HTTP、HTTPS 和受限管理访问的入站规则，以及将 NSG 关联到子网来构建网络基础。 ### 第 3 天 — 核心计算 在 Web 子网中部署 Windows Server 虚拟机，分配用于测试的公共 IP，通过 RDP 连接，安装 IIS，托管一个简单的 HTML 网页，并验证基于 HTTP 的 Web 访问。同时还配置了 Windows 容器运行时，并记录了容器排障过程。 ### 第 4 天 — 负载均衡与高可用性 创建了 Azure Standard Load Balancer，配置了前端公共 IP、后端池、HTTP 运行状况探测和针对端口 80 的负载均衡规则。将两台 Web 虚拟机都添加到后端池，并通过停止一台虚拟机来测试故障转移，同时确认应用程序仍可通过负载均衡器保持可用。 ### 第 5 天 — 身份与 RBAC 使用 Microsoft Entra ID 实现身份和访问控制，创建了测试用户，在资源组范围内分配了 Reader 和 Contributor 角色，启用了 MFA，并通过用户测试验证了访问限制。 ### 第 6 天 — 监控与可观测性 配置了 Azure Monitor、Log Analytics Workspace、Azure Monitor Agent、Data Collection Rules，以及针对高 CPU、虚拟机心跳丢失、网络流量和磁盘空间不足的警报。构建了一个用于监控正常运行时间、CPU、磁盘和网络的工作簿仪表板。 ### 第 7 天 — 无服务器与事件驱动工作流 创建了 Azure Storage Account、Blob 容器和带有 Blob 触发器的 Azure Function App。从 Visual Studio Code 开发并部署了该函数，然后通过上传的文件和 Application Insights 日志验证了其执行情况。 ### 第 8 天 — 备份、灾难恢复与成本优化 创建了 Recovery Services Vault，为虚拟机启用了 Azure Backup，生成了恢复点，测试了虚拟机还原，审查了 Azure Cost Management，并创建了用于成本治理的月度预算警报。 ### 第 9 天 — 故障模拟 模拟了真实场景中的故障事件，包括虚拟机停机、NSG 阻止 HTTP、CPU 飙升、磁盘空间不足、Web 服务故障和 RBAC 访问拒绝。验证了警报是否在 Azure Monitor 和 Application Insights 中正确触发，随后记录了排障步骤、解决方案和经验教训。 ## 故障模拟 通过模拟真实场景中的故障事件对环境进行了测试，以验证监控、警报和排障程序。 ### 故障 1 — 虚拟机停机 - 手动停止了虚拟机 - Azure Monitor 警报检测到虚拟机可用性问题 - Load Balancer 将流量重定向到剩余的虚拟机 - 解决方案：重启虚拟机 - 经验教训：监控与高可用性协同工作以保持正常运行时间 ### 故障 2 — Network Security Group 阻止 HTTP - NSG 入站拒绝规则阻止了端口 80 - 网站变得不可访问 - 调查显示 NSG 规则阻止了 HTTP - 解决方案：移除拒绝规则 - 经验教训：NSG 规则和优先级会直接影响应用程序的可用性 ### 故障 3 — CPU 使用率过高 - 虚拟机上的 CPU 使用率被人为提高 - Azure Monitor CPU 警报被触发 - 调查显示 CPU 出现飙升 - 解决方案：停止占用大量 CPU 的进程 - 经验教训：性能警报有助于检测资源耗尽情况 ### 故障 4 — 磁盘空间不足 - 创建大文件以减少磁盘空间 - 触发了磁盘空间不足警报 - 解决方案：删除大文件 - 经验教训：磁盘监控可防止系统故障 ### 故障 5 — Web 服务器宕机 - IIS 服务被停止 - 触发了 Application Insights 可用性警报 - 解决方案：重启 Web 服务 - 经验教训：应用层面的监控非常重要，不能仅限于虚拟机监控 ### 故障 6 — RBAC 访问被拒绝 - Reader 用户尝试停止虚拟机 - 访问被拒绝 - 验证了 RBAC 限制正在正常运行 - 经验教训：RBAC 可防止未经授权的更改并保护资源 ## 成本优化 使用 Azure Cost Management 来监控和控制该环境的支出。 已实施的成本优化步骤： - 在不使用时停止虚拟机 - 使用 Standard HDD 托管磁盘而不是 Premium SSD - 对 Azure Functions 使用消耗计划（无服务器） - 在 50%、70% 和 80% 阈值处配置预算警报 - 使用资源标签进行成本跟踪（项目：CloudPortfolio） - 按资源审查成本分析，以识别成本最高的资源 主要产生成本的资源： - 虚拟机 - 托管磁盘 - 公共 IP 地址 - 负载均衡器 - Log Analytics Workspace - 存储账户 - 恢复服务保管库（备份） ## 经验教训 本项目提供了在 Microsoft Azure 中设计、部署、保护、监控和维护云基础设施环境的实践经验。 获得的主要经验教训： - 资源组用于组织和管理 Azure 资源 - 虚拟网络和子网提供网络分段和安全边界 - Network Security Groups 充当控制流量的防火墙 - 虚拟机在云中托管应用程序和服务 - Azure Load Balancer 提供高可用性和故障转移能力 - Microsoft Entra ID 和 RBAC 控制对云资源的访问 - Azure Monitor 和 Log Analytics 提供集中式监控和警报 - Application Insights 支持应用程序级别的监控和可用性测试 - Azure Functions 实现无服务器和事件驱动的工作流 - Azure Backup 和 Recovery Services Vault 提供灾难恢复能力 - Azure Cost Management 有助于监控和控制云支出 - 故障模拟有助于验证监控、警报和排障程序 - 文档和 GitHub 代码库对于作品集和知识共享非常重要 ## 结论 本项目演示了完整 Azure 基础设施环境的部署，包括网络、计算、负载均衡、身份与访问管理、监控、无服务器计算、备份与灾难恢复、成本优化以及故障模拟。 对该环境进行了监控、安全保护、故障测试和文档记录，以模拟真实的云工程和云运维场景。本项目展示了实用的 Azure 管理、基础设施部署、监控、排障和文档编写技能。

标签：AI合规, 云计算, 微软云, 灾备, 网络安全, 自动化运维, 虚拟化, 规则引擎, 运维, 隐私保护