熬夜盯Windows服务这事儿干过运维的都懂。半夜三点服务挂掉、早上被电话吵醒、一到节假日就神经衰弱最后熬到发际线和耐心一起退守高地。我之前就是这么过来的直到把一套自动化巡检加自愈脚本跑起来算是彻底告别了“守着任务管理器过日子”的状态。这篇文章就把这套方案从设计到落地的完整过程写出来包括服务状态监控、异常判定、自动拉起、失败告警、日志留痕这些环节的实操细节以及踩过的几个不小的坑。适合被Windows服务运维折腾过的同学参考不管你是刚接手服务器的新手还是被值班表压得喘不过气的资深运维这套思路都能直接用。1. 先搞清楚为什么服务会挂以及“盯”到底该盯什么1.1 服务挂掉的原因远比想象中复杂Windows服务在无人值守的服务器上挂掉很多情况不是“崩了”这么简单。我梳理了一下实际运维中遇到的场景大概是这样的进程崩溃或异常退出代码里的未捕获异常、内存泄漏后的OOM、第三方DLL加载失败都可能导致服务进程直接消失。服务假死但进程还在这是最坑的一种服务状态显示正在运行但实际已经不响应请求了数据库连接池耗尽、线程死锁、消息队列堆积都会造成这种情况。依赖项出问题服务依赖的数据库、消息中间件、网络共享、其他Windows服务出现异常服务本身虽然没崩但功能已经完全不可用。系统环境变化磁盘写满、内存不足、系统更新后权限变更、策略组调整这些看似外围的因素也可能把服务间接搞挂。人为误操作同事在服务器上改了服务配置、停掉了某个服务忘了恢复这种场景也真实存在。这也是为什么巡检脚本不能只用一个简单的“服务状态是否Running”来判断否则假死和依赖故障会被完全漏掉。一个真正能落地的巡检方案至少要覆盖“进程是否在”“状态是否正常”“关键功能是否可用”三层检查。1.2 自愈不是万能的先定义“自动化边界”这里先泼一盆冷水。脚本能做的自愈主要是针对“进程挂了但配置没坏”“服务停止了但能正常拉起”“依赖恢复后服务可以自行启动”这类场景。并不是所有故障都能靠自动拉起解决——如果服务的配置文件被改坏了、数据文件损坏、依赖的基础组件本身挂了盲目拉起不仅没用还可能造成更严重的问题。所以我在设计脚本的时候给自愈加了几条原则只有在“服务状态处于Stopped”或“进程不存在但配置校验通过”的情况下才执行自动拉起。连续拉起N次失败后不再重复尝试转为告警升级。服务每隔一段时间会自检业务健康状态连续多次异常才判定为真故障避免偶发抖动触发误杀或误拉。所有自愈动作必须写日志能追溯到什么时间、因为什么条件、执行了什么命令、结果如何。简单说巡检脚本眼睛自愈脚本手告警通知嘴。眼睛负责发现问题手负责处理能处理的问题嘴负责把处理不了的问题喊出来。这样才能既减少人工介入又不至于让自动化替代了人的判断。2. 巡检脚本的设计健康状态不能只看“Running”2.1 从Windows服务本身能拿到的信息PowerShell是Windows服务巡检的首选工具因为系统自带的Get-Service和Get-Process已经能拿到大部分需要的信息。先看一段最基础的示例# 获取服务状态 $serviceName MyAppService $service Get-Service -Name $serviceName -ErrorAction SilentlyContinue if ($null -eq $service) { Write-Output [ERROR] 服务 $serviceName 不存在 } elseif ($service.Status -eq [System.ServiceProcess.ServiceControllerStatus]::Running) { Write-Output [OK] 服务正在运行 } elseif ($service.Status -eq [System.ServiceProcess.ServiceControllerStatus]::Stopped) { Write-Output [WARN] 服务已停止 } else { Write-Output [INFO] 服务状态: $($service.Status) }但这里有一个很容易被忽略的问题Windows服务的Status属性只代表服务控制管理器SCM视角的“基本状态”它不会告诉你服务内部的业务是不是正常。比如一个服务线程死锁主线程还活着SCM依然认为它是Running。只靠这个判断远远不够。2.2 业务健康检查用最小代价探测“真正可用”针对假死类问题我采用了“轻量级业务探活系统资源基线”的组合方式。所谓轻量级探活就是模拟一个真实用户的请求看服务能不能在可接受时间内返回预期结果。具体到不同服务类型做法不一样HTTP类的服务请求一个固定探活接口检查HTTP状态码和响应耗时。TCP类的服务尝试建立TCP连接判断端口连通性。数据库类服务执行一个轻量查询比如SELECT 1。自定义Windows服务可以在服务内部开放一个命名管道或本地HTTP端口专门给巡检脚本做健康检查。拿HTTP探活来说PowerShell的Invoke-WebRequest就很方便但要注意设置超时不能让它无限等下去。更好的做法是直接用.NET的HttpClient类可以精确控制超时和重试逻辑。下面是我实际在用的探活封装function Test-ServiceHealth { param( [string]$HealthCheckUrl, [int]$TimeoutSeconds 5 ) try { $httpClient New-Object System.Net.Http.HttpClient $httpClient.Timeout [TimeSpan]::FromSeconds($TimeoutSeconds) $response $httpClient.GetAsync($HealthCheckUrl).GetAwaiter().GetResult() if ($response.IsSuccessStatusCode) { return $true } else { Write-Output [WARN] 健康检查返回状态码: $([int]$response.StatusCode) return $false } } catch { Write-Output [ERROR] 健康检查请求异常: $($_.Exception.Message) return $false } finally { if ($httpClient) { $httpClient.Dispose() } } }这里加一个个人建议探活接口尽量做一些真实的依赖校验比如访问一下数据库、检查一下缓存服务是否可连而不是返回一个写死的字符串。否则服务虽然活着实际业务链路已经断了探活还是通过的那就失去了意义。2.3 系统资源检查提前处理服务挂掉的“土壤问题”资源类的故障通常不是一瞬间爆发的而是有前置征兆的。巡检脚本如果能在资源出现瓶颈之前发现并处理胜过大半夜被Call起来救火。我习惯把下面的关键指标加进巡检逻辑里。CPU使用率持续超过90%超过10分钟就需要关注了。内存使用率物理内存使用率超过90%或服务进程工作集异常增长。磁盘空间系统盘剩余空间低于10%或低于设定的绝对值阈值。句柄数/线程数服务进程的句柄数和线程数持续递增往往是泄漏的征兆。PowerShell获取这些数据有很多现成的办法Get-WmiObject Win32_Processor、Get-Counter、Get-Process都能用。但Get-Counter在性能开销上要稍微注意不要在巡检脚本里过于频繁地调用。3. 自愈脚本的核心逻辑拉起的姿势和顺序有讲究3.1 直接Start-Service没那么简单最简单的自愈当然是Start-Service -Name MyAppService但实际操作中你会发现很多细节问题服务拉起后需要时间初始化立即检查状态往往是StillStarting或者又崩了。某些服务需要以特定账户运行权限不足时Start-Service虽然返回成功服务实际没有起来。依赖服务没就绪时直接启动主服务可能失败。连续重启次数过多Windows会触发服务控制管理器的快速恢复机制导致服务无法被再次启动。所以我在自愈逻辑里做了一层“启动前检查-启动-初始化等待-二次验证”的流程。先把依赖项和服务状态全部确认一遍再执行启动启动后按照服务类型等待不同的初始化窗口然后才做第二次健康确认。3.2 自愈状态机的落地实现我在脚本里定义了一套有限状态集合每次巡检都按照这个顺序流转检查进程是否存在 - 检查服务状态 - 检查健康接口 - 检查资源基线 - 判定是否自愈 - 执行自愈 - 验证自愈结果 - 记录日志与告警下面是一个简化但能直接用的自愈函数结构function Restore-ServiceWithGuard { param( [string]$ServiceName, [string]$HealthCheckUrl, [int]$MaxRestartAttempts 3, [int]$InitWaitSeconds 15 ) $restartCount 0 while ($restartCount -lt $MaxRestartAttempts) { Write-Output [INFO] 第 $($restartCount 1) 次尝试拉起服务 $ServiceName # 启动前检查目标服务是否已存在若不存在则记录并跳过 $service Get-Service -Name $ServiceName -ErrorAction SilentlyContinue if ($null -eq $service) { Write-Output [ERROR] 服务 $ServiceName 不存在停止自愈流程 return $false } # 检查服务类型如果是需要先启动依赖服务的场景先处理依赖 $dependencies $service.ServicesDependedOn foreach ($dep in $dependencies) { $depService Get-Service -Name $dep.ServiceName -ErrorAction SilentlyContinue if ($depService -and $depService.Status -ne [System.ServiceProcess.ServiceControllerStatus]::Running) { Write-Output [INFO] 启动依赖服务: $($dep.ServiceName) Start-Service -Name $dep.ServiceName -ErrorAction SilentlyContinue } } # 执行启动 try { Start-Service -Name $ServiceName -ErrorAction Stop } catch { Write-Output [ERROR] Start-Service 抛出异常: $($_.Exception.Message) } # 等待初始化窗口 Start-Sleep -Seconds $InitWaitSeconds # 二次验证状态健康检查双重判断 $service Get-Service -Name $ServiceName -ErrorAction SilentlyContinue $healthy Test-ServiceHealth -HealthCheckUrl $HealthCheckUrl if ($service.Status -eq [System.ServiceProcess.ServiceControllerStatus]::Running -and $healthy) { Write-Output [OK] 服务自愈成功 return $true } else { Write-Output [WARN] 服务状态: $($service.Status), 健康检查通过: $healthy $restartCount } } Write-Output [ERROR] 已达最大重启次数 $MaxRestartAttempts自愈失败需要人工介入 return $false }这个结构使用了一个关键思想while循环配合状态验证而不是盲目地执行固定次数重启。每次重启之后都会认真检查是否真正“活”了避免服务处于半死不活的状态就宣布成功。3.3 关于服务恢复选项的提醒有些服务在“恢复”标签页里配置了“重新启动服务”选项系统会在服务异常退出后自动拉起一次。这个机制本身是好的但在自动化脚本的环境中反而可能导致冲突——如果系统已经在自动重启服务脚本这边还在判断状态两边同时操作可能出现重复拉起的情况。我的建议是二选一要么用系统的恢复选项做第一层脚本只在确定服务已经停了之后才介入要么直接禁用系统恢复完全让脚本接管。实操中我更推荐第二种因为脚本接管之后能做的事情更多——它可以判断服务为什么挂、可以处理依赖、可以做更细致的日志系统自带的重启策略做不到这些。4. 通知与告警把“半夜被叫醒”变成“早上看报告”4.1 分级告警设计自愈脚本处理掉的问题不需要立刻打电话发短信那反而成了噪音。真正需要即时告警的只有两种情况连续多次自愈失败、或者检测到资源层面可能导致多个服务连锁故障的严重情况。所以我设计了三档告警告警级别触发条件通知方式信息级服务正常、巡检通过不通知写日志警告级服务曾异常但自愈成功汇总到日报严重级自愈失败、资源严重不足、关键服务不可用即时推送延迟到分钟级这样做的核心目的只有一个把运维的注意力集中到真正需要人工处理的事情上。服务自己拉起来了、恢复了没必要半夜把人吵醒。4.2 通知脚本的几种落地方式通知渠道我前后用过几种各有取舍这里直接列出来供参考邮件通知最传统也最稳定适合日报、月度总结这类不紧迫的消息。但邮件服务本身也依赖SMTP服务器的可用性如果监控的对象恰好是公司内部邮件系统相关服务要注意别形成循环依赖。即时通知例如通过Webhook推送到企业IM机器人。这类方式的优势是实时性好配置也简单一个Invoke-RestMethod就能发出去。短信或电话告警严重级别才会用成本相对高通常由更上层的监控平台完成脚本一般只负责把告警信息推给监控平台。下面是一个通过Webhook推送告警的示例核心就是构造一个JSON对象然后POST出去function Send-AlertMessage { param( [string]$WebhookUrl, [string]$Title, [string]$Message ) $payload { title $Title text $Message } | ConvertTo-Json try { Invoke-RestMethod -Uri $WebhookUrl -Method Post -ContentType application/json -Body ([System.Text.Encoding]::UTF8.GetBytes($payload)) -ErrorAction Stop Write-Output [OK] 告警消息发送成功 } catch { Write-Output [ERROR] 告警消息发送失败: $($_.Exception.Message) } }关于编码有个坑我单独拿出来说一下。PowerShellInvoke-RestMethod直接传字符串时中文内容经常因为编码问题变成乱码。上面的示例里我特意用了UTF8.GetBytes($payload)把字符串编码成字节数组再传递这在大部分机器人Webhook接口上都能避免乱码问题。4.3 巡检日志让每次自动动作都可追溯日志是整个自动化体系里最容易被忽视、但真正出了问题最救命的部分。我设计日志时定了几个标准每次巡检一行摘要包含时间、服务名、检查结果、动作类型。每次自愈动作独立记录包含触发原因、启动尝试次数、每步命令的结果。日志文件按天滚动保留最近30天超过的自动清理。日志写入时带上执行耗时方便后续评估脚本本身的性能开销。PowerShell里写日志最简单的办法是Add-Content但需要注意并发访问的问题。如果巡检脚本通过计划任务多次运行多个进程同时写同一个文件可能冲突。我通常会让每个巡检周期生成独立的日志子文件最后再由汇总任务整理这样既避免并发写冲突也让原始数据更完整。5. 计划任务与细节处理自动化本身也要可靠5.1 计划任务配置的几个关键项脚本写好了最终靠Windows任务计划程序来定时触发。计划任务配置不当脚本功力再好也白搭。我踩过的坑主要集中在下面几点运行账户必须用专用服务账号不能用普通用户登录会话否则服务交互、网络权限都受限。触发频率要按业务容忍度设置。核心服务我希望2分钟内发现故障那就每2分钟跑一次次要服务可以放宽到5分钟。“如果任务运行时间超过x天则停止任务”这个选项默认是不启用的但如果脚本出现死循环计划任务会一直挂着导致下一次触发直接跳过。“如果请求后任务仍在运行则此规则启动新实例”要设置为“Parallel”否则上一次巡检卡住时新的巡检会直接不运行。这里贴一个计划任务创建示例用schtasks命令配合XML配置最为灵活# 创建一个每2分钟执行一次的巡检任务 $trigger New-ScheduledTaskTrigger -Once -At (Get-Date) -RepetitionInterval (New-TimeSpan -Minutes 2) -RepetitionDuration (New-TimeSpan -Days 3650) $action New-ScheduledTaskAction -Execute powershell.exe -Argument -NoProfile -ExecutionPolicy Bypass -File C:\Scripts\ServicePatrol.ps1 $principal New-ScheduledTaskPrincipal -UserId DOMAIN\svc_monitor -LogonType S4U -RunLevel Highest Register-ScheduledTask -TaskName ServicePatrol -Trigger $trigger -Action $action -Principal $principal -Description Windows服务巡检自愈任务一个关键的选择-RepetitionDuration要设置成一个很长的时间从任务被创建的时刻开始算起而不是“从现在开始无限循环”。如果你只填了一天的Duration第二天任务就不会再跑了这个是我见过最常见的问题之一。5.2 脚本自身的安全与防重入巡检脚本本身也要考虑被意外终止、被重复执行、被篡改的情况。我做了三道防线加一个互斥锁确保同一时间只有一个巡检进程在跑。PowerShell里可以用Mutex实现。脚本目录权限收紧到只有管理员和专用服务账号可读写避免普通用户篡改探活接口和自愈逻辑。每次运行记录自己的执行时间如果发现运行耗时异常超过预定上限触发一次日志告警——因为这往往意味着脚本本身遇到了问题。互斥锁的实现方式也很简单$mutexName Global\\ServicePatrolMutex $mutex New-Object System.Threading.Mutex($false, $mutexName) if (-not $mutex.WaitOne(0)) { Write-Output [SKIP] 另一个巡检实例正在运行本次跳过 exit 0 } try { # 巡检逻辑 } finally { $mutex.ReleaseMutex() $mutex.Dispose() }“全局互斥锁”名称加Global\\前缀是给所有会话共用的不加的话只在当前会话内有效计划任务每次创建新的powershell进程会话同名互斥锁反而起不到防重入的效果。6. 实测数据与避坑总结6.1 这套方案跑出来的实际效果我用这套方案在一个承担内部业务系统的服务器上跑了大约半年结果值得拿出来聊聊。在部署前这个服务器上的核心服务平均每个月要处理2到3次半夜故障多数是第二天早上用户反馈了才发现。部署后服务的异常发现时间缩短到2分钟以内以我这边的数据来看大约70%的服务停止类故障都通过自动拉起恢复没有惊动任何人剩下30%的复杂故障由于无法自愈在几分钟内告警通知到了值班人员处理效率比之前被用户问“服务是不是挂了”再去看要快得多。当然70%这个数字只能作为参考不同服务的复杂度不一样自愈成功率会有很大差异。对基础组件类服务比如消息队列、缓存来说拉起后依赖恢复相对简单但对有状态服务来说恢复过程还涉及数据一致性问题就不能简单靠脚本解决了。这也是我在前面强调“自动化边界”的原因——脚本解决的是“让服务回到正常运行状态”这件事而不是“把服务里的数据修好”这件事。6.2 我在部署过程中踩过的三个关键坑第一个坑是探活接口和业务耦合过深。一开始我把探活接口设计成访问所有核心依赖以保证健康检查的严格性结果发现依赖里任何一个组件慢探活接口就会超时脚本就会判定服务异常开始自动重启。而频繁重启又加重了依赖的负载最后形成恶性循环。后来我改成“主服务自身存活关键依赖分级别探活”探活结果分权重计算问题明显缓解。第二个坑是快速恢复机制引发的重启风暴。Windows服务在短时间内反复崩溃时SCM会触发快速恢复策略服务会进入“禁用恢复”状态。我们的脚本在不知道这个机制的情况下反复尝试启动与系统的策略打架。后来我在脚本里加了判断如果检测到服务进入“缓慢启动”或恢复相关状态就停止自动拉起直接转为告警升级。第三个坑是脚本权限的配置问题。计划任务使用专用服务账号运行时务必检查这个账号有没有“作为服务登录”的权限。如果缺少这个权限服务拉起动作会失败但错误信息可能被吞掉从外部看只看到脚本日志里的“启动失败”排查了很久才发现是权限配置的问题。6.3 从脚本巡检到平台化巡检的扩展思路脚本方式的优势是轻量、部署快、不依赖额外组件对只有几台服务器的场景完全够用。但如果你管理的服务器多了脚本分散在各台机器上缺少集中视图、告警汇总困难和脚本版本管理麻烦这些问题就会浮现出来。这个时候可以考虑把巡检数据上报到集中的监控端或者在每台机器上只保留一个轻量采集器由中央平台统一做策略下发和数据分析。不过要提醒一句从脚本巡检迁移到平台化巡检不要一上来就追求大而全。先把脚本里的判定逻辑和故障处理经验整理成标准操作手册再考虑平台化的事情。我在迁移过程中最大的体会是——平台只是载体真正有价值的是你对每个服务“什么叫正常、什么叫异常、异常怎么处理”的理解这套知识体系不建立起来换个再牛的平台也做不好自动运维。按照我目前的习惯新接手一批服务器时先手工梳理所有服务的依赖关系、启动顺序、健康检查标准和恢复策略再把这些内容固化到脚本里。这个前置工作确实花时间但它决定了一个自动化巡检自愈项目能否真正长期稳定运行。一次投入后面的日子就好过多了至少“半夜爬起来盯服务”这件事和我已经没有关系了。
熬夜盯Windows服务这事儿干过运维的都懂。半夜三点服务挂掉、早上被电话吵醒、一到节假日就神经衰弱最后熬到发际线和耐心一起退守高地。我之前就是这么过来的直到把一套自动化巡检加自愈脚本跑起来算是彻底告别了“守着任务管理器过日子”的状态。这篇文章就把这套方案从设计到落地的完整过程写出来包括服务状态监控、异常判定、自动拉起、失败告警、日志留痕这些环节的实操细节以及踩过的几个不小的坑。适合被Windows服务运维折腾过的同学参考不管你是刚接手服务器的新手还是被值班表压得喘不过气的资深运维这套思路都能直接用。1. 先搞清楚为什么服务会挂以及“盯”到底该盯什么1.1 服务挂掉的原因远比想象中复杂Windows服务在无人值守的服务器上挂掉很多情况不是“崩了”这么简单。我梳理了一下实际运维中遇到的场景大概是这样的进程崩溃或异常退出代码里的未捕获异常、内存泄漏后的OOM、第三方DLL加载失败都可能导致服务进程直接消失。服务假死但进程还在这是最坑的一种服务状态显示正在运行但实际已经不响应请求了数据库连接池耗尽、线程死锁、消息队列堆积都会造成这种情况。依赖项出问题服务依赖的数据库、消息中间件、网络共享、其他Windows服务出现异常服务本身虽然没崩但功能已经完全不可用。系统环境变化磁盘写满、内存不足、系统更新后权限变更、策略组调整这些看似外围的因素也可能把服务间接搞挂。人为误操作同事在服务器上改了服务配置、停掉了某个服务忘了恢复这种场景也真实存在。这也是为什么巡检脚本不能只用一个简单的“服务状态是否Running”来判断否则假死和依赖故障会被完全漏掉。一个真正能落地的巡检方案至少要覆盖“进程是否在”“状态是否正常”“关键功能是否可用”三层检查。1.2 自愈不是万能的先定义“自动化边界”这里先泼一盆冷水。脚本能做的自愈主要是针对“进程挂了但配置没坏”“服务停止了但能正常拉起”“依赖恢复后服务可以自行启动”这类场景。并不是所有故障都能靠自动拉起解决——如果服务的配置文件被改坏了、数据文件损坏、依赖的基础组件本身挂了盲目拉起不仅没用还可能造成更严重的问题。所以我在设计脚本的时候给自愈加了几条原则只有在“服务状态处于Stopped”或“进程不存在但配置校验通过”的情况下才执行自动拉起。连续拉起N次失败后不再重复尝试转为告警升级。服务每隔一段时间会自检业务健康状态连续多次异常才判定为真故障避免偶发抖动触发误杀或误拉。所有自愈动作必须写日志能追溯到什么时间、因为什么条件、执行了什么命令、结果如何。简单说巡检脚本眼睛自愈脚本手告警通知嘴。眼睛负责发现问题手负责处理能处理的问题嘴负责把处理不了的问题喊出来。这样才能既减少人工介入又不至于让自动化替代了人的判断。2. 巡检脚本的设计健康状态不能只看“Running”2.1 从Windows服务本身能拿到的信息PowerShell是Windows服务巡检的首选工具因为系统自带的Get-Service和Get-Process已经能拿到大部分需要的信息。先看一段最基础的示例# 获取服务状态 $serviceName MyAppService $service Get-Service -Name $serviceName -ErrorAction SilentlyContinue if ($null -eq $service) { Write-Output [ERROR] 服务 $serviceName 不存在 } elseif ($service.Status -eq [System.ServiceProcess.ServiceControllerStatus]::Running) { Write-Output [OK] 服务正在运行 } elseif ($service.Status -eq [System.ServiceProcess.ServiceControllerStatus]::Stopped) { Write-Output [WARN] 服务已停止 } else { Write-Output [INFO] 服务状态: $($service.Status) }但这里有一个很容易被忽略的问题Windows服务的Status属性只代表服务控制管理器SCM视角的“基本状态”它不会告诉你服务内部的业务是不是正常。比如一个服务线程死锁主线程还活着SCM依然认为它是Running。只靠这个判断远远不够。2.2 业务健康检查用最小代价探测“真正可用”针对假死类问题我采用了“轻量级业务探活系统资源基线”的组合方式。所谓轻量级探活就是模拟一个真实用户的请求看服务能不能在可接受时间内返回预期结果。具体到不同服务类型做法不一样HTTP类的服务请求一个固定探活接口检查HTTP状态码和响应耗时。TCP类的服务尝试建立TCP连接判断端口连通性。数据库类服务执行一个轻量查询比如SELECT 1。自定义Windows服务可以在服务内部开放一个命名管道或本地HTTP端口专门给巡检脚本做健康检查。拿HTTP探活来说PowerShell的Invoke-WebRequest就很方便但要注意设置超时不能让它无限等下去。更好的做法是直接用.NET的HttpClient类可以精确控制超时和重试逻辑。下面是我实际在用的探活封装function Test-ServiceHealth { param( [string]$HealthCheckUrl, [int]$TimeoutSeconds 5 ) try { $httpClient New-Object System.Net.Http.HttpClient $httpClient.Timeout [TimeSpan]::FromSeconds($TimeoutSeconds) $response $httpClient.GetAsync($HealthCheckUrl).GetAwaiter().GetResult() if ($response.IsSuccessStatusCode) { return $true } else { Write-Output [WARN] 健康检查返回状态码: $([int]$response.StatusCode) return $false } } catch { Write-Output [ERROR] 健康检查请求异常: $($_.Exception.Message) return $false } finally { if ($httpClient) { $httpClient.Dispose() } } }这里加一个个人建议探活接口尽量做一些真实的依赖校验比如访问一下数据库、检查一下缓存服务是否可连而不是返回一个写死的字符串。否则服务虽然活着实际业务链路已经断了探活还是通过的那就失去了意义。2.3 系统资源检查提前处理服务挂掉的“土壤问题”资源类的故障通常不是一瞬间爆发的而是有前置征兆的。巡检脚本如果能在资源出现瓶颈之前发现并处理胜过大半夜被Call起来救火。我习惯把下面的关键指标加进巡检逻辑里。CPU使用率持续超过90%超过10分钟就需要关注了。内存使用率物理内存使用率超过90%或服务进程工作集异常增长。磁盘空间系统盘剩余空间低于10%或低于设定的绝对值阈值。句柄数/线程数服务进程的句柄数和线程数持续递增往往是泄漏的征兆。PowerShell获取这些数据有很多现成的办法Get-WmiObject Win32_Processor、Get-Counter、Get-Process都能用。但Get-Counter在性能开销上要稍微注意不要在巡检脚本里过于频繁地调用。3. 自愈脚本的核心逻辑拉起的姿势和顺序有讲究3.1 直接Start-Service没那么简单最简单的自愈当然是Start-Service -Name MyAppService但实际操作中你会发现很多细节问题服务拉起后需要时间初始化立即检查状态往往是StillStarting或者又崩了。某些服务需要以特定账户运行权限不足时Start-Service虽然返回成功服务实际没有起来。依赖服务没就绪时直接启动主服务可能失败。连续重启次数过多Windows会触发服务控制管理器的快速恢复机制导致服务无法被再次启动。所以我在自愈逻辑里做了一层“启动前检查-启动-初始化等待-二次验证”的流程。先把依赖项和服务状态全部确认一遍再执行启动启动后按照服务类型等待不同的初始化窗口然后才做第二次健康确认。3.2 自愈状态机的落地实现我在脚本里定义了一套有限状态集合每次巡检都按照这个顺序流转检查进程是否存在 - 检查服务状态 - 检查健康接口 - 检查资源基线 - 判定是否自愈 - 执行自愈 - 验证自愈结果 - 记录日志与告警下面是一个简化但能直接用的自愈函数结构function Restore-ServiceWithGuard { param( [string]$ServiceName, [string]$HealthCheckUrl, [int]$MaxRestartAttempts 3, [int]$InitWaitSeconds 15 ) $restartCount 0 while ($restartCount -lt $MaxRestartAttempts) { Write-Output [INFO] 第 $($restartCount 1) 次尝试拉起服务 $ServiceName # 启动前检查目标服务是否已存在若不存在则记录并跳过 $service Get-Service -Name $ServiceName -ErrorAction SilentlyContinue if ($null -eq $service) { Write-Output [ERROR] 服务 $ServiceName 不存在停止自愈流程 return $false } # 检查服务类型如果是需要先启动依赖服务的场景先处理依赖 $dependencies $service.ServicesDependedOn foreach ($dep in $dependencies) { $depService Get-Service -Name $dep.ServiceName -ErrorAction SilentlyContinue if ($depService -and $depService.Status -ne [System.ServiceProcess.ServiceControllerStatus]::Running) { Write-Output [INFO] 启动依赖服务: $($dep.ServiceName) Start-Service -Name $dep.ServiceName -ErrorAction SilentlyContinue } } # 执行启动 try { Start-Service -Name $ServiceName -ErrorAction Stop } catch { Write-Output [ERROR] Start-Service 抛出异常: $($_.Exception.Message) } # 等待初始化窗口 Start-Sleep -Seconds $InitWaitSeconds # 二次验证状态健康检查双重判断 $service Get-Service -Name $ServiceName -ErrorAction SilentlyContinue $healthy Test-ServiceHealth -HealthCheckUrl $HealthCheckUrl if ($service.Status -eq [System.ServiceProcess.ServiceControllerStatus]::Running -and $healthy) { Write-Output [OK] 服务自愈成功 return $true } else { Write-Output [WARN] 服务状态: $($service.Status), 健康检查通过: $healthy $restartCount } } Write-Output [ERROR] 已达最大重启次数 $MaxRestartAttempts自愈失败需要人工介入 return $false }这个结构使用了一个关键思想while循环配合状态验证而不是盲目地执行固定次数重启。每次重启之后都会认真检查是否真正“活”了避免服务处于半死不活的状态就宣布成功。3.3 关于服务恢复选项的提醒有些服务在“恢复”标签页里配置了“重新启动服务”选项系统会在服务异常退出后自动拉起一次。这个机制本身是好的但在自动化脚本的环境中反而可能导致冲突——如果系统已经在自动重启服务脚本这边还在判断状态两边同时操作可能出现重复拉起的情况。我的建议是二选一要么用系统的恢复选项做第一层脚本只在确定服务已经停了之后才介入要么直接禁用系统恢复完全让脚本接管。实操中我更推荐第二种因为脚本接管之后能做的事情更多——它可以判断服务为什么挂、可以处理依赖、可以做更细致的日志系统自带的重启策略做不到这些。4. 通知与告警把“半夜被叫醒”变成“早上看报告”4.1 分级告警设计自愈脚本处理掉的问题不需要立刻打电话发短信那反而成了噪音。真正需要即时告警的只有两种情况连续多次自愈失败、或者检测到资源层面可能导致多个服务连锁故障的严重情况。所以我设计了三档告警告警级别触发条件通知方式信息级服务正常、巡检通过不通知写日志警告级服务曾异常但自愈成功汇总到日报严重级自愈失败、资源严重不足、关键服务不可用即时推送延迟到分钟级这样做的核心目的只有一个把运维的注意力集中到真正需要人工处理的事情上。服务自己拉起来了、恢复了没必要半夜把人吵醒。4.2 通知脚本的几种落地方式通知渠道我前后用过几种各有取舍这里直接列出来供参考邮件通知最传统也最稳定适合日报、月度总结这类不紧迫的消息。但邮件服务本身也依赖SMTP服务器的可用性如果监控的对象恰好是公司内部邮件系统相关服务要注意别形成循环依赖。即时通知例如通过Webhook推送到企业IM机器人。这类方式的优势是实时性好配置也简单一个Invoke-RestMethod就能发出去。短信或电话告警严重级别才会用成本相对高通常由更上层的监控平台完成脚本一般只负责把告警信息推给监控平台。下面是一个通过Webhook推送告警的示例核心就是构造一个JSON对象然后POST出去function Send-AlertMessage { param( [string]$WebhookUrl, [string]$Title, [string]$Message ) $payload { title $Title text $Message } | ConvertTo-Json try { Invoke-RestMethod -Uri $WebhookUrl -Method Post -ContentType application/json -Body ([System.Text.Encoding]::UTF8.GetBytes($payload)) -ErrorAction Stop Write-Output [OK] 告警消息发送成功 } catch { Write-Output [ERROR] 告警消息发送失败: $($_.Exception.Message) } }关于编码有个坑我单独拿出来说一下。PowerShellInvoke-RestMethod直接传字符串时中文内容经常因为编码问题变成乱码。上面的示例里我特意用了UTF8.GetBytes($payload)把字符串编码成字节数组再传递这在大部分机器人Webhook接口上都能避免乱码问题。4.3 巡检日志让每次自动动作都可追溯日志是整个自动化体系里最容易被忽视、但真正出了问题最救命的部分。我设计日志时定了几个标准每次巡检一行摘要包含时间、服务名、检查结果、动作类型。每次自愈动作独立记录包含触发原因、启动尝试次数、每步命令的结果。日志文件按天滚动保留最近30天超过的自动清理。日志写入时带上执行耗时方便后续评估脚本本身的性能开销。PowerShell里写日志最简单的办法是Add-Content但需要注意并发访问的问题。如果巡检脚本通过计划任务多次运行多个进程同时写同一个文件可能冲突。我通常会让每个巡检周期生成独立的日志子文件最后再由汇总任务整理这样既避免并发写冲突也让原始数据更完整。5. 计划任务与细节处理自动化本身也要可靠5.1 计划任务配置的几个关键项脚本写好了最终靠Windows任务计划程序来定时触发。计划任务配置不当脚本功力再好也白搭。我踩过的坑主要集中在下面几点运行账户必须用专用服务账号不能用普通用户登录会话否则服务交互、网络权限都受限。触发频率要按业务容忍度设置。核心服务我希望2分钟内发现故障那就每2分钟跑一次次要服务可以放宽到5分钟。“如果任务运行时间超过x天则停止任务”这个选项默认是不启用的但如果脚本出现死循环计划任务会一直挂着导致下一次触发直接跳过。“如果请求后任务仍在运行则此规则启动新实例”要设置为“Parallel”否则上一次巡检卡住时新的巡检会直接不运行。这里贴一个计划任务创建示例用schtasks命令配合XML配置最为灵活# 创建一个每2分钟执行一次的巡检任务 $trigger New-ScheduledTaskTrigger -Once -At (Get-Date) -RepetitionInterval (New-TimeSpan -Minutes 2) -RepetitionDuration (New-TimeSpan -Days 3650) $action New-ScheduledTaskAction -Execute powershell.exe -Argument -NoProfile -ExecutionPolicy Bypass -File C:\Scripts\ServicePatrol.ps1 $principal New-ScheduledTaskPrincipal -UserId DOMAIN\svc_monitor -LogonType S4U -RunLevel Highest Register-ScheduledTask -TaskName ServicePatrol -Trigger $trigger -Action $action -Principal $principal -Description Windows服务巡检自愈任务一个关键的选择-RepetitionDuration要设置成一个很长的时间从任务被创建的时刻开始算起而不是“从现在开始无限循环”。如果你只填了一天的Duration第二天任务就不会再跑了这个是我见过最常见的问题之一。5.2 脚本自身的安全与防重入巡检脚本本身也要考虑被意外终止、被重复执行、被篡改的情况。我做了三道防线加一个互斥锁确保同一时间只有一个巡检进程在跑。PowerShell里可以用Mutex实现。脚本目录权限收紧到只有管理员和专用服务账号可读写避免普通用户篡改探活接口和自愈逻辑。每次运行记录自己的执行时间如果发现运行耗时异常超过预定上限触发一次日志告警——因为这往往意味着脚本本身遇到了问题。互斥锁的实现方式也很简单$mutexName Global\\ServicePatrolMutex $mutex New-Object System.Threading.Mutex($false, $mutexName) if (-not $mutex.WaitOne(0)) { Write-Output [SKIP] 另一个巡检实例正在运行本次跳过 exit 0 } try { # 巡检逻辑 } finally { $mutex.ReleaseMutex() $mutex.Dispose() }“全局互斥锁”名称加Global\\前缀是给所有会话共用的不加的话只在当前会话内有效计划任务每次创建新的powershell进程会话同名互斥锁反而起不到防重入的效果。6. 实测数据与避坑总结6.1 这套方案跑出来的实际效果我用这套方案在一个承担内部业务系统的服务器上跑了大约半年结果值得拿出来聊聊。在部署前这个服务器上的核心服务平均每个月要处理2到3次半夜故障多数是第二天早上用户反馈了才发现。部署后服务的异常发现时间缩短到2分钟以内以我这边的数据来看大约70%的服务停止类故障都通过自动拉起恢复没有惊动任何人剩下30%的复杂故障由于无法自愈在几分钟内告警通知到了值班人员处理效率比之前被用户问“服务是不是挂了”再去看要快得多。当然70%这个数字只能作为参考不同服务的复杂度不一样自愈成功率会有很大差异。对基础组件类服务比如消息队列、缓存来说拉起后依赖恢复相对简单但对有状态服务来说恢复过程还涉及数据一致性问题就不能简单靠脚本解决了。这也是我在前面强调“自动化边界”的原因——脚本解决的是“让服务回到正常运行状态”这件事而不是“把服务里的数据修好”这件事。6.2 我在部署过程中踩过的三个关键坑第一个坑是探活接口和业务耦合过深。一开始我把探活接口设计成访问所有核心依赖以保证健康检查的严格性结果发现依赖里任何一个组件慢探活接口就会超时脚本就会判定服务异常开始自动重启。而频繁重启又加重了依赖的负载最后形成恶性循环。后来我改成“主服务自身存活关键依赖分级别探活”探活结果分权重计算问题明显缓解。第二个坑是快速恢复机制引发的重启风暴。Windows服务在短时间内反复崩溃时SCM会触发快速恢复策略服务会进入“禁用恢复”状态。我们的脚本在不知道这个机制的情况下反复尝试启动与系统的策略打架。后来我在脚本里加了判断如果检测到服务进入“缓慢启动”或恢复相关状态就停止自动拉起直接转为告警升级。第三个坑是脚本权限的配置问题。计划任务使用专用服务账号运行时务必检查这个账号有没有“作为服务登录”的权限。如果缺少这个权限服务拉起动作会失败但错误信息可能被吞掉从外部看只看到脚本日志里的“启动失败”排查了很久才发现是权限配置的问题。6.3 从脚本巡检到平台化巡检的扩展思路脚本方式的优势是轻量、部署快、不依赖额外组件对只有几台服务器的场景完全够用。但如果你管理的服务器多了脚本分散在各台机器上缺少集中视图、告警汇总困难和脚本版本管理麻烦这些问题就会浮现出来。这个时候可以考虑把巡检数据上报到集中的监控端或者在每台机器上只保留一个轻量采集器由中央平台统一做策略下发和数据分析。不过要提醒一句从脚本巡检迁移到平台化巡检不要一上来就追求大而全。先把脚本里的判定逻辑和故障处理经验整理成标准操作手册再考虑平台化的事情。我在迁移过程中最大的体会是——平台只是载体真正有价值的是你对每个服务“什么叫正常、什么叫异常、异常怎么处理”的理解这套知识体系不建立起来换个再牛的平台也做不好自动运维。按照我目前的习惯新接手一批服务器时先手工梳理所有服务的依赖关系、启动顺序、健康检查标准和恢复策略再把这些内容固化到脚本里。这个前置工作确实花时间但它决定了一个自动化巡检自愈项目能否真正长期稳定运行。一次投入后面的日子就好过多了至少“半夜爬起来盯服务”这件事和我已经没有关系了。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
