适用于 PowerShell 7.0 及以上版本

Polyglot Notebooks（前身 .NET Interactive）是微软推出的一款交互式笔记本工具，它将 Jupyter 笔记本的理念带入了 .NET 生态。与传统的 Jupyter 仅支持 Python 等单一内核不同，Polyglot Notebooks 的核心优势在于多语言互操作：你可以在同一个笔记本中无缝切换 PowerShell、C#、F#、JavaScript、HTML 等语言，并通过变量共享机制让不同语言的代码块协同工作。

对于 PowerShell 用户而言，这意味着你不必再在”用 PowerShell 写脚本”和”用 Jupyter 做数据分析”之间做选择。你可以直接在笔记本中用 PowerShell 获取系统数据、调用 REST API、操作文件系统，然后用 C# 处理复杂的计算逻辑，最后用 JavaScript 生成可交互的可视化图表——所有这些都在同一个文档中完成。

本文将从三个方面介绍 Polyglot Notebooks 的实战用法：首先搭建环境并掌握基础的 Magic Commands，然后演示多语言协作与变量共享的技巧，最后通过一个数据分析实战案例展示完整的工作流。

适用于 PowerShell 7.0 及以上版本

Azure Monitor 是 Azure 的统一监控平台，负责收集、分析和处理来自云资源与应用的指标和日志数据。随着云基础设施规模的不断增长，运维团队需要面对成百上千个资源的健康状态监控需求，手动在门户中逐个配置告警规则既繁琐又容易遗漏关键阈值。

通过 PowerShell 与 Az 模块的结合，我们可以将告警规则的创建、通知动作组的配置以及告警历史查询全部脚本化。这不仅大幅提升了部署效率，还让告警策略成为代码的一部分，可以纳入版本控制和 CI/CD 流水线进行审计与回滚。

本文将围绕三个核心场景展开：指标告警规则的批量创建、基于 Log Analytics 日志查询的告警与通知配置、以及告警生命周期管理与健康合规审计。掌握这些技巧后，你可以轻松实现可观测性即代码（Observability as Code）的实践。

适用于 PowerShell 7.0 及以上版本

在基础设施即代码（IaC）的实践中，配置管理一直是最核心也最容易出问题的环节。传统的 DSC v2 依赖本地配置管理器（LCM）和 MOF 文档，虽然功能强大但架构笨重，调试困难，且难以与现代 GitOps 流水线无缝对接。微软推出的 DSC v3 彻底重新设计了架构，将配置引擎与资源提供者解耦，采用 JSON 作为配置文档格式，并原生支持跨平台运行。

DSC v3 的设计哲学是”配置即代码”（Configuration as Code）。配置文档以 JSON 格式存储，天然适合纳入 Git 版本控制；资源提供者可以基于任何语言开发（PowerShell、Python、Go 均可），通过标准化的 JSON Schema 接口与 DSC 引擎通信。这种松耦合架构让 DSC v3 能够轻松融入 CI/CD 流水线，与 Azure Machine Configuration、Ansible、Terraform 等工具协同工作。

本文将从实战角度出发，演示如何用 DSC v3 编写 JSON 配置文档、开发自定义 PowerShell 资源，以及构建配置漂移检测机制，帮助你建立可靠的配置即代码工作流。

适用于 PowerShell 5.1 及以上版本

在 PowerShell 的早期版本中，我们通常使用 PSCustomObject 或哈希表来构建自定义数据结构。虽然它们足够灵活，但缺乏类型约束、无法定义方法、也不支持继承，在构建大型自动化项目时显得力不从心。PowerShell 5.0 引入了 class 关键字，让我们可以直接在脚本中定义真正的 .NET 类型。

class 不仅仅是语法糖，它带来了完整的面向对象编程能力：类型安全的属性、可重载的构造函数、继承与多态、以及与 .NET 生态的无缝集成。你可以用 class 来建模业务实体、封装复杂逻辑、甚至实现设计模式，让脚本从”一次性工具”进化为可维护的工程化代码。

本文将从基础类定义开始，逐步深入继承与多态，最后通过一个服务器管理框架的实战案例，展示 class 在真实自动化场景中的威力。

适用于 PowerShell 5.1 及以上版本

新年伊始，系统管理员面临着一系列”开年”初始化任务：更新所有自动化脚本的版权年份、重置年度计数器和统计数据、创建新的日志目录结构、部署第一季度的安全基线检查。这些琐碎但重要的工作如果逐一手动完成，不仅耗时，还容易遗漏关键环节，给后续全年运行埋下隐患。

更麻烦的是，这些任务往往分散在不同的服务器和项目目录中。脚本可能分布在几十个仓库里，日志配置文件散落在多台服务器上，计划任务的调度时间需要按新年度重新校准。手动逐一排查和更新，不仅效率低下，而且很难保证一致性——某台服务器忘了更新目录，某份脚本的年份还是去年的，这些疏忽往往要到年中出问题时才被发现。

通过 PowerShell 脚本将这些”开年”任务编排为一套可一键执行的自动化流程，可以确保所有初始化工作在统一的控制下完成，每一步都有日志记录、有结果校验。本文将从年度环境初始化、安全基线审计、全年计划任务部署三个维度，展示如何用 PowerShell 高效完成新年开局工作。

适用于 PowerShell 5.1 及以上版本

2025 年对 PowerShell 社区而言是里程碑式的一年。PowerShell 7.5 正式发布，全面拥抱 .NET 8 带来的性能提升与新 API，同时官方团队持续推动跨平台体验的统一。云原生、容器化和 GitOps 已经不再只是 buzzword，而是日常运维的基本范式，PowerShell 在其中扮演了越来越重要的胶水语言角色。

与此同时，AI 大模型的爆发深刻改变了自动化脚本的工作方式。从调用 OpenAI API 做日志分析，到用本地模型生成配置模板，再到 IDE 中的智能补全，AI 工具链已经深度融入 PowerShell 开发者的日常工作流。这一年我们见证了脚本编写方式从”查文档写代码”到”描述需求生成代码”的范式转变。

站在岁末年初的节点，本文将回顾 2025 年 PowerShell 生态的关键技术变化，梳理当前最实用的 AI 集成与云原生实战技巧，并展望 2026 年值得关注的趋势和学习方向。

适用于 PowerShell 5.1 及以上版本

回顾这一年的技能连载，我们从基础命令一路走到了高级自动化场景。在实际生产环境中，能跑通一段脚本只是起点，让脚本在面对异常输入、网络波动、权限变更时依然稳定运行，才是工程师的真正功力。今天我们就来系统梳理 PowerShell 脚本编写的最佳实践。

这些实践并非教条，而是从大量生产故障中提炼出来的经验总结。遵循它们可以让你的脚本更健壮、更易维护，也让接手代码的同事少踩几个坑。无论你是刚入门的新手还是资深运维工程师，这些原则都值得时刻对照。

适用于 PowerShell 5.1 及以上版本

每到年底，IT 部门都需要向管理层提交各类运维报告：服务器可用性统计、安全事件汇总、资源使用趋势分析、成本核算等。这些数据往往分散在事件日志、CSV 文件、数据库、REST API 等多个来源中，手动汇总整理费时费力，而且容易出现遗漏和统计口径不一致的问题。

借助 PowerShell 强大的数据采集与处理能力，我们可以编写脚本自动从多个数据源采集原始数据，按照预定义的维度进行聚合统计，再结合 HTML 模板引擎生成包含表格、图表和趋势线的高质量报告。整个过程无需手动干预，一条命令即可产出一份数据完整、格式专业的年终总结。

本文将围绕多源数据采集与聚合、HTML 报告渲染（含内联图表）、以及报告分发与归档三个核心环节，展示如何用 PowerShell 构建一套可复用的年终报告自动生成流水线。

适用于 PowerShell 7.0 及以上版本

在传统运维模式中，自动化脚本通常运行在虚拟机或容器上，无论脚本是否执行，底层计算资源都在持续消耗成本。对于定时清理、事件响应、API 集成等轻量级任务来说，这种模式既浪费资源又增加了运维负担——你不仅要维护脚本本身，还要操心服务器的补丁更新、高可用和扩缩容。

Azure Functions 是微软 Azure 提供的无服务器（Serverless）计算平台，支持使用 PowerShell 作为运行时语言。函数只在被事件触发时才执行，按实际运行时间和调用次数计费，空闲时不产生任何费用。PowerShell 运行时内置了 Az 模块和大量常用 cmdlet，让你可以直接在云端编写和运行自动化逻辑，无需自行管理基础设施。

本文将从三个实战场景出发：搭建 Azure Functions PowerShell 项目并编写 HTTP 触发器函数、使用定时触发器和队列触发器处理周期性与事件驱动任务，以及部署、监控与错误处理的最佳实践。

适用于 PowerShell 5.1 及以上版本

PowerShell 模块生态在过去几年里蓬勃发展，PowerShell Gallery 上已经托管了数以万计的模块。从日常运维的 Active Directory 管理，到云端自动化的 Az 模块，再到新兴的 AI 交互工具，几乎每种场景都有对应的模块可用。然而，模块数量的增长也带来了管理上的挑战：不同项目依赖同一个模块的不同版本、私有环境的离线分发需求、以及供应链安全对模块来源的审计要求，都是实际工作中必须面对的问题。

PowerShell 7 引入了 PSResourceGet（Microsoft.PowerShell.PSResourceGet）作为新一代包管理引擎，替代了沿用多年的 PowerShellGet v2。PSResourceGet 基于 NuGet 协议重新实现了仓库交互，在性能、安全性和功能覆盖面上都有显著提升。同时，它保留了与 PowerShellGet 类似的命令风格，降低了迁移成本。对于仍然运行在 Windows PowerShell 5.1 环境中的系统，PowerShellGet 依然可用，但强烈建议尽早迁移到 PSResourceGet。

本文将从基础操作入手，逐步介绍模块搜索与安装、版本锁定与依赖分析，以及私有仓库的搭建方法，帮助你在不同规模的自动化环境中实现可靠的包管理与依赖控制。