适用于 PowerShell 7.0 及以上版本

在现代云原生开发中，基础设施即代码（Infrastructure as Code，IaC）已经成为团队协作和持续交付的基石。传统 ARM Template 虽然功能强大，但 JSON 语法的冗长和嵌套层级让维护成本居高不下。微软推出的 Bicep 语言正是为了解决这个痛点而诞生的——它是一种透明抽象（transparent abstraction），编译后生成标准 ARM Template，同时提供了更简洁的声明式语法、类型安全和模块化支持。

Bicep 的核心优势在于：语法简洁（去掉了 JSON 的大量样板代码）、编译期类型检查（在部署前就能发现错误）、模块化设计（支持将复杂部署拆分为可复用的模块），以及与 Azure 生态的深度集成。配合 PowerShell 的 Az 模块，我们可以构建从开发到生产的完整部署流水线，实现环境一致性管理和自动化运维。

本文将从 Bicep 模板编写、PowerShell 部署脚本以及模块化与重用三个层面，介绍如何通过 PowerShell + Bicep 构建 Azure 基础设施的自动化部署方案。

适用于 PowerShell 7.0 及以上版本

每天在终端里敲命令数小时，默认的 PS C:\> 提示符只能告诉你当前路径，其他信息一概欠奉。当你在多个 Git 仓库之间切换、管理不同的 Azure 订阅、激活不同的 Python 虚拟环境时，一个信息丰富的提示符可以让你瞬间掌握上下文状态，减少低级错误。

PowerShell 的提示符本质上就是一个名为 prompt 的函数——你可以自由重写它。无论是显示 Git 分支和脏状态、上一次命令的执行耗时、当前用户权限级别，还是用颜色区分不同的服务器环境，都可以通过几行代码实现。本文将带你从手写 prompt 函数开始，再到集成 Oh My Posh 这类成熟框架，最后补充一套提升日常效率的实用工具函数。

适用于 PowerShell 7.0 及以上版本

在日常运维中，许多任务需要定时执行：清理过期资源、轮转证书、检查合规状态、生成日报。如果依赖人工操作，不仅效率低下，还容易遗漏。Azure Automation 提供了一个托管的 PowerShell 执行环境，让脚本可以在云端按计划自动运行，无需维护本地服务器。

Azure Automation 的核心概念是 Runbook——一段托管在云端的 PowerShell 脚本。Runbook 支持多种触发方式：定时计划（Schedule）、Webhook 回调、事件驱动（Event Grid），甚至可以手动启动。它内置了凭据管理、变量存储和模块缓存，使脚本能安全地访问 Azure 资源而不暴露密钥。

本文将围绕三个核心场景展开：创建和管理 Runbook、配置定时计划与 Webhook 触发、以及监控作业状态与日志输出。通过这些实践，你可以构建一个完整的无人值守运维体系。

适用于 PowerShell 7.0 及以上版本

在多团队、多订阅的云环境中，资源合规性是治理的核心难题。开发团队随手创建了一个 Premium SKU 的 Redis 缓存，费用瞬间翻了十倍；某个资源组忘了打标签，月底账单无法分摊到业务线；还有人不小心把资源部署到了不支持数据驻留的区域。这些问题在单订阅时还能人工检查，到了几十个订阅、上百个资源组的规模，靠人工审计根本忙不过来。

Azure Policy 提供了声明式的合规规则引擎，可以在资源创建或更新时自动评估是否满足预设条件。不满足条件的资源可以被审计记录、拒绝创建，甚至自动修复到合规状态。结合管理组（Management Group）的层级结构，一条策略可以向下继承到所有子订阅，真正做到”治理即代码”。

本文将演示如何通过 PowerShell 完成 Azure Policy 的三大核心操作：策略定义与管理、策略分配与范围控制、合规审计与自动修复。让你从手工巡检的时代彻底迈入自动化合规治理。

适用于 PowerShell 5.1 及以上版本

系统管理员和运维工程师在日常工作中，经常需要面对各种系统故障和性能问题。当用户反馈系统卡顿、服务响应缓慢时，快速定位问题根因是恢复服务的关键。传统的排查方式是手动逐项检查——先看 CPU，再查内存，然后翻日志——不仅耗时，还容易遗漏关键线索。

通过 PowerShell 编写系统诊断脚本，可以将这些分散的检查步骤自动化，形成一套标准化的诊断流程。脚本可以在几秒内完成对硬件资源、操作系统状态、网络连接和安全配置的全面扫描，并以结构化报告的形式输出结果，帮助运维人员快速做出判断。

本文提供三个层次的诊断脚本：从硬件性能分析开始，到操作系统与服务状态检查，最后整合为一键全量诊断报告，方便直接集成到运维自动化平台中使用。

适用于 PowerShell 7.0 及以上版本，需要 Az.DesktopVirtualization 模块

适用于 PowerShell 5.1 及以上版本

每次创建新的 PowerShell 模块项目，都需要手动建立目录结构、编写模块清单（.psd1）、创建入口脚本（.psm1）、添加 Pester 测试文件，甚至还要配置 CI/CD 流水线。这些重复劳动不仅耗时，而且容易出现结构不一致的问题，尤其在多人协作的团队中更为突出。

Plaster 是由 PowerShell 社区开发的正式项目脚手架工具，它的灵感来源于 Node.js 的 Yeoman 和 Python 的 Cookiecutter。Plaster 使用 XML 模板来定义完整的项目结构，通过声明式的方式描述文件、目录、参数和条件逻辑，一键生成标准化的项目骨架。

借助 Plaster，团队可以将最佳实践固化到模板中——无论是代码规范、测试框架配置，还是 Git 钩子和 CI 流水线——每次创建新项目时都能保持结构一致，大幅降低遗漏关键配置的风险。

适用于 PowerShell 7.0 及以上版本

Azure Container Registry（ACR）是微软 Azure 平台提供的托管私有 Docker 镜像仓库服务。与 Docker Hub 的公开镜像不同，ACR 让企业可以在 Azure 区域内就近存储和管理容器镜像，享受低延迟的镜像拉取体验和网络隔离的安全保障。无论是运行在 Azure Kubernetes Service（AKS）中的编排集群，还是 App Service 的容器化 Web 应用，都可以直接从 ACR 拉取镜像来部署。

然而，镜像管理远不止”推送和拉取”这么简单。随着版本迭代，注册表中会积累大量过时镜像，占用存储空间并增加攻击面。安全团队要求对所有镜像进行漏洞扫描，运维团队需要配置最小权限的访问控制和跨区域复制策略。如果用 Azure Portal 手动处理这些任务，在面对数十个注册表和成百上千个镜像标签时，效率会非常低下。

本文将通过三个部分介绍如何用 PowerShell 自动化管理 ACR：首先是基础操作，包括注册表的创建、镜像的推送拉取和标签管理；其次是镜像清理与安全扫描，自动化识别并移除未使用的镜像层；最后是访问控制与复制策略，通过 RBAC 和 Webhook 将 ACR 深度集成到 CI/CD 流水线中。

适用于 PowerShell 7.0 及以上版本

在日常运维工作中，我们经常遇到需要同时处理大量独立任务的场景。比如批量检查 100 台服务器的连通性、并行下载数十个日志文件、同时对多个数据库执行查询。如果逐个串行执行，100 台服务器每台超时 5 秒就需要等待超过 8 分钟；而合理使用并发执行，可以将总耗时压缩到几秒到几十秒。

PowerShell 历经多年发展，提供了多种并发执行机制。最早期的 Start-Job 基于独立的 PowerShell 进程，开销大但隔离性好；后来的 ThreadJob 模块改用 .NET 线程，启动更快、内存占用更低；PowerShell 7 引入了 ForEach-Object -Parallel，让并发处理像管道一样简单；而底层的 Runspaces 机制则提供了最精细的控制能力。

本文将从易到难，依次介绍这四种并发机制的核心用法、适用场景和注意事项，帮助你根据实际需求选择最合适的方案。

适用于 PowerShell 5.1 及以上版本