PowerShell服务器重启脚本日志异常问题排查求助

1. 已重启服务器未标记“Reboot Successful”的原因 #

• 时间对比逻辑错误：检查脚本中LastBootUpTime与$Now的判断条件，是否将LastBootUpTime -gt $Now（重启成功的正确逻辑）写反成了-lt。另外要确认运行脚本的本地机器与目标服务器的时间是否同步，时间差会直接导致对比失效——比如服务器时间比本地慢，重启后的LastBootUpTime仍可能小于$Now。
• 检测时机过早：Test-Connection连通仅代表服务器网络恢复，但WinRM/WMI服务可能还未启动，此时读取的LastBootUpTime还是重启前的旧值。脚本需要在连通后增加等待时间，或者循环重试读取LastBootUpTime，直到拿到符合条件的值或触发超时。
• 远程服务/权限问题：读取LastBootUpTime时可能因权限不足，或目标服务器的WMI/WinRM服务未正常就绪，导致获取到错误的旧值，进而误判重启失败。

2. 仅记录5台服务器的原因 #

• 异常未捕获导致脚本中断：遍历服务器列表时，若某台服务器处理出现超时、连接失败等错误，且脚本未用try/catch捕获异常，会直接终止运行，后续服务器根本没机会执行。检查脚本是否在单台服务器处理流程外包裹了异常捕获逻辑，确保一台失败不影响全局。
• 服务器列表遍历逻辑缺陷：确认服务器数据源（数组、配置文件等）是否完整，有没有空值、无效条目，或是脚本在遍历过程中因筛选条件跳过了部分服务器。
• 日志/线程问题：若脚本采用并行重启逻辑，部分服务器的处理线程可能因超时被销毁，来不及写入日志；或是日志写入未使用追加模式（比如Out-File未加-Append），但这种情况通常是覆盖而非只记录部分，更可能是脚本执行到第5台时崩溃终止。

是否需要大幅重构？ #

如果只是局部逻辑漏洞（缺重试机制、错误处理、时间对比写错），针对性修复即可，无需大幅重构。但如果脚本结构混乱（所有逻辑堆砌、无模块化、日志与业务耦合严重），或需要长期维护、扩展功能，建议重构：

• 将重启、状态检测、日志写入拆分为独立函数
• 为单台服务器处理流程增加完整的异常捕获
• 完善重试机制，对连通性和LastBootUpTime检测进行多次重试
• 增加中间步骤日志，方便后续排查问题

内容的提问来源于stack exchange，提问作者RustyAndroid