5 个 PowerShell 最佳实践

任何工具的有效性取决于所使用的方法 - 这也适用于 PowerShell。本文介绍了日常管理工作的五种最佳实践。

一个好的脚本不仅要达到预期的结果，还要具有可靠性、可移植性和可追溯性。本文是“最佳实践 - 从可执行代码到专业代码”的延续，探讨了可遵循的五种最佳实践，以充分利用 PowerShell 并编写不仅可以工作，而且可以在不同场景中生存和定制的脚本。

幂等性：确保您的脚本重复且安全地执行

一致性至关重要，尤其是在自动化重复任务时：幂等性原则在这里发挥着重要作用。幂等脚本或函数可确保您可以多次执行它并每次都获得相同的结果，而不会产生不需要的副作用。

想象一个应该在服务器上创建文件的脚本。幂等脚本将首先检查文件是否已经存在。如果是这样，它不会执行任何操作或更新文件。但是，它肯定不会创建第二个同名文件或显示错误消息。

如果您注意 PowerShell 中的幂等性，这意味着：

• 在进行任何更改之前检查当前状态。
• 避免重复执行可能产生不同结果或意外副作用的操作。
• 如果您想确保资源处于某种状态，请使用幂等的 cmdlet，例如 Set-* 而不是 Add-*。
  
  

通过确保脚本是幂等的，您不仅可以最大限度地减少错误，还可以实现更安全的自动化场景，其中脚本可以定期或自动执行。

例如，您希望在其中创建文件之前确保目录存在：

$directoryPath = "C:\ExampleDirectory"
if (-not (Test-Path $directoryPath)) {
  New-Item -Path $directoryPath -ItemType Directory
} else {
  Write-Output "The directory already exists."
}

通过将这些检查集成到 PowerShell 脚本中，您可以确保一致的执行，无论脚本执行的频率如何。

错误处理：一致使用try-catch-finally

错误处理在任何脚本或程序中都起着核心作用。在 PowerShell 中，try-catch-finally 构造为您提供了一种对错误做出反应的可靠方法。这确保了清理工作的持续进行。

• 尝试：此块包含可能导致错误的代码。如果 try 块中发生错误并且该块具有中止字符（例如通过 ErrorAction Stop 参数），则执行将直接传递到关联的 catch 块。
• Catch：一旦 try 块中发生错误，该部分就会激活。在这里您可以选择处理错误 - 例如通过记录或通知。
• 最后：无论try块的结果如何，该部分总是被执行。它用于清理工作或其他最终行动。

常见的过程是在执行过程中创建临时文件，然后应再次将其删除，如下所示：

$tempFile = "C:\Temp\myTempFile.txt"

try {
  # Create temporary file
  New-Item -Path $tempFile -ItemType File -Force

  # Do things with the temporary file
  # ...
}
catch {
  Write-Output "An error occurred: $_"
}
finally {
  # Ensure that the temporary file is deleted in the end
  if (Test-Path $tempFile) {
    Remove-Item -Path $tempFile -Force
    Write-Output "Temporary file has been removed."
  }
}

将此错误处理结构集成到您的脚本中可确保您为潜在错误做好准备，并且能够充分解决它们。

最小化依赖性：编写可移植脚本

脚本通常需要能够在不同的系统上运行。因此，主要目标之一应该是使脚本尽可能可移植。这意味着最大限度地减少依赖性并确保脚本在不同条件下一致工作。最大限度地减少依赖关系可防止脚本因缺少特定资源或工具而无法在某些环境中运行。对脚本的具体要求越少，它就越有可能在各种系统上顺利运行。

PowerShell 中的一个常见场景是使用外部工具或程序。但是，PowerShell 通常提供可以实现相同目的的内置 cmdlet，并且使用这些 cmdlet 可以帮助减少依赖性。您可以依靠内置的 PowerShell cmdlet，而不是依赖 systeminfo.exe 等外部程序（某些系统上可能缺少这些程序或提供不同的输出）。

# Not recommended: Using an external program
$output = & "systeminfo.exe"

# Recommended: Using a built-in PowerShell cmdlet
$systemInfo = Get-CimInstance -ClassName Win32_OperatingSystem

• 在第一个示例中，外部程序systeminfo.exe用于收集有关操作系统的信息。虽然该程序存在于许多 Windows 系统上，但其输出可能会因版本或配置而异。
• 第二个示例使用 Get-CimInstance cmdlet 和 Win32_OperatingSystem 类来获取有关操作系统的详细信息。由于此 cmdlet 直接集成到 PowerShell 中并检索标准化 CIM 信息，因此输出更加一致，并且脚本具有更少的外部依赖项。
  
  

附加提示：

• 避免固定路径：不要在脚本中使用固定路径，而是考虑使用相对路径或参数。
• Prüfe auf Vorhandensein von Ressourcen： Bevor du auf eine bestimmte Ressource zugreifst, überprüfe, ob sie tatsächlich vorhanden ist (z. B. mit 测试路径)。
• 检查资源是否存在：在访问特定资源之前，检查它是否确实存在（例如使用测试路径）。
• 记录依赖关系：如果您的脚本确实需要外部工具或特定资源，请在脚本开头记录这些依赖关系。

最大限度地减少 PowerShell 脚本中的依赖性可确保它们在大量系统和不同环境中一致且可靠地工作。

避免交互式对话框：专注于自动化！

如果您直接使用交互式对话框，它们会很有用。但在自动化 IT 环境中，它们可能会成为一个问题。如果在脚本运行时出现对话框，则需要进行人机交互。这会中断自动化流程并增加出错的可能性。

想象一个场景，其中脚本应该从服务器查询信息。该脚本不应在运行时询问您服务器名称，而应接受它作为参数。

# Not recommended: Query server name interactively
$serverName = Read-Host "Please enter the server name."
$serverInfo = Get-ADComputer -Identity $serverName

# Recommended: Accept server name as parameter
param($serverName)
$serverInfo = Get-ADComputer -Identity $serverName

• 在第一个示例中，Read-Host 用于在运行时询问您服务器名称。这对于自动化环境来说并不理想，因为它涉及您/人在过程中的交互。
• 在第二个示例中，脚本将服务器名称作为参数。这允许脚本针对不同的服务器名称自动运行，而无需您干预。

使用参数不仅可以促进自动化，还可以提高脚本在不同上下文中的可重用性。

一致的日志记录实践：始终掌握最新情况

在复杂的 IT 环境中，准确记录脚本和自动化工具的操作和结果至关重要。一致且详细的日志记录使管理员能够快速识别、诊断和解决问题。此外，良好的日志提供了一种跟踪执行历史记录的方法，这在排除故障或分析事件时非常有用。

Write-Host cmdlet 直接将信息输出到控制台，在生产环境中应避免使用。一种更加结构化且可用于生产的方法是使用专用的日志记录功能，例如 Write-Log：

# Define the Write-Log function
function Write-Log {
  param
  (
   [Parameter(Mandatory=$true)]
   [string]$Message,
   [Parameter(Mandatory=$false)]
   [string]$LogPath = "C:\Logs\MyScript.log"
  )
  Add-Content -Path $LogPath -Value "$(Get-Date) - $Message"
}

# Not recommended: Use Write-Host for direct console output
Write-Host "This action has been completed."

# Recommended: Use Write-Log for consistent logging practices
Write-Log -Message "This action has been completed."

• 在非推荐示例中，脚本使用Write-Host将消息直接输出到控制台。虽然这在开发环境中很有用，但对于生产环境来说并不理想，因为此类消息不会被记录下来并且无法用于以后的分析。
• 推荐的示例定义了一个 Write-Log 函数，该函数将带有时间戳的每条消息保存在日志文件中。这确保了所有活动和结果都被记录下来以供以后审查和分析。

还有一些提示：

• 日志轮转：考虑如何控制日志文件的大小，以免它们变得太大并消耗过多的资源。
• 集中式日志记录：您可能希望使用集中式日志记录工具（例如 ELK Stack 或 Graylog）来集中收集和分析日志。
• 不要重新设计一切：已经有许多模块可以使 PowerShell 中的日志记录变得更加容易。我在这里推荐的是 Friedrich Weinmann 的 PSFramework 模块（在 GitHub 上）。
  
  

结论

PowerShell 提供了许多用于自动化和管理 IT 环境的选项。然而，与任何工具一样，成功的关键在于正确使用它。任何使用 PowerShell 的人都应该考虑这些最佳实践来创建强大、可靠和可持续的解决方案。