一、现场：被远程桌面统治的世界

很多公司的机房里都有这样一台机器：Windows Server，上面跑着 IIS 站点和 SQL Server，可能是官网、可能是内部系统、可能是财务软件的服务端。它的运维方式通常是一个词——远程桌面：想看状态，mstsc 登上去；服务挂没挂，打开服务管理器看；日志出问题了，事件查看器翻半天。值守？不存在的，Windows 机器往往在「出事了用户先发现」的名单里。

win-srv 就是这么一台 Windows Server 2019，IIS 官网加 SQL Server Express。这一篇要把它拉进和 Linux 一样的体系：SSH 接入、角色探针值守、PowerShell 排障。看完你会发现，前面六篇建立的所有直觉——只读直行、高危确认、值守告警、角色识别——在 Windows 上原样成立，变的只是命令方言。

二、接入：装个 OpenSSH，剩下交给助手

Windows 侧唯一的前置动作是启用 OpenSSH Server（Windows 10 1809 与 Server 2019 起内置该可选功能，几条 PowerShell 或图形界面操作即可开启，官方文档有现成步骤）。装好后，在助手 Web GUI 的添加主机表单里选设备类型 Windows，填 IP 和账号，或者直接对 AI 说：

我：加一台 Windows 主机：名称 win-srv，IP 10.10.10.88，

    管理员账号 administrator

 

AI：→ add_host（设备类型 windows，SSH 22 端口）

  连接测试通过。注意：Windows 主机的命令走 PowerShell 方言。

还有一类更省心的场景：如果助手就装在这台 Windows 机器上，启动时它会探测本机的 22 端口，发现 OpenSSH 可用就自动把本机登记进主机清单——命名冲突自动避让、已有人工备注不覆盖。装完软件什么都不配，它已经能管脚下这台机器了。

接入之后，中文乱码这个 Windows 远程运维的经典坑已经提前填掉：PowerShell 的输出按 GBK 和 UTF-8 双重解码处理，事件日志里的中文报错、netstat 里的中文服务名，回来都是可读的。这个坑不踩一次不知道有多烦——GBK 机器上的乱码排查日志，能把排障时间翻倍。

三、值守：IIS 与 SQL Server 的专属探针

和 Linux 机器一样，win-srv 开值守前先做角色识别：

我：win-srv 也开值守，它上面是官网和 SQL Server

 

AI：→ scan_roles(host="win-srv")

  候选角色：windows（IIS 服务指纹命中，SQL Server 指纹命中）

 

我：确认

 

AI：角色已写回，值守挂载 windows 探针：监控 W3SVC（IIS）、

    SQL Server 服务族状态，配合 CPU / 内存 / 磁盘阈值。

windows 角色探针盯的是 IIS 与 SQL Server 的服务族状态，叠加通用的资源阈值轮询。从这一刻起，这台机器不再依赖「用户报障」：IIS 的 W3SVC 服务停了、SQL Server 服务族异常，30 秒内横幅、报警音、邮件三路齐发。

两台机器命名上的小习惯：Linux 主机和 Windows 主机在清单里并列共存，角色探针各挂各的——web01 挂 web 探针查 nginx，win-srv 挂 windows 探针查 W3SVC。值守面板不区分操作系统，红的绿的摆在一起看，这本身就是对「Windows 是二等公民」这种默认认知的纠正。

四、排障：中文不乱码的 PowerShell 现场

某天下午，值守横幅如期而至：win-srv 的 W3SVC 服务状态异常。打开对话框：

我：win-srv 的 IIS 告警了，看看怎么回事

 

AI：→ run_command(Get-Service W3SVC | Format-List Name,Status)

  Status: Stopped

 

AI：服务已停止。查事件日志找原因 →

    run_command(Get-WinEvent -FilterHashtable @{LogName="System";

    Id=7031,7034} -MaxEvents 5 | Format-List TimeCreated,Message)

  「服务 IIS Admin Service 意外终止」——工作进程崩溃循环后停止

 

AI：根因方向：应用池工作进程崩溃导致服务停止。

    恢复建议：启动 W3SVC 并观察是否再次崩溃。是否执行？

    （服务启动属变更操作，将弹确认）

 

我：执行

 

AI：→ run_command(Start-Service W3SVC)（已确认）

    → run_command(Get-Service W3SVC)

  Status: Running

    → run_command(Invoke-WebRequest -UseBasicParsing http://localhost)

  StatusCode: 200（官网已恢复响应）

整个链路和 Linux 排障如出一辙：查状态、翻日志、给结论、拟恢复命令、等确认、执行、回验。唯一的区别是命令从 systemctl 换成了 PowerShell——而这一层翻译工作 AI 已经替你做了。你不需要会 PowerShell，就像你不需要会 bash 一样；但如果你会，AI 拟的每一条命令你都看得懂，确认起来心里有底。

多行脚本也有专属通道：复杂排障（比如一次采集服务状态、端口监听、最近错误日志三样）需要跑一段 PowerShell 脚本，AI 会把脚本经 stdin 注入远程 PowerShell 执行，不受命令行长度限制，输出同样过双重解码。批量执行 run_command_on_hosts 对 Windows 主机同样有效——Linux、Windows 混编主机清单里，AI 会按方言自动区分。

环节	传统做法	AI 运维助手
接入方式	远程桌面人肉登录	OpenSSH 通道，Web/CLI 均可管
值守能力	基本没有，靠用户报障	IIS / SQL Server 探针 30 秒轮询
中文乱码	GBK 环境排查日志靠猜	双重解码，回显原样可读
命令门槛	要会 PowerShell	说人话，AI 拟命令你确认
故障恢复	手工重启服务	AI 定位后拟命令，确认即恢复

五、收尾：操作系统不是边界

Windows 支持交付那天，我给这个版本的注解是：AI 运维助手跨出 Linux。这句话的含金量要到实战里才看得清——公司环境从来不是纯净的 Linux 集群，它总有几台「离不开又不想天天看」的 Windows。现在它们和 Linux 一样：进主机清单、挂角色探针、出事三路告警、排障一次确认。

至此，主机侧的故事基本讲完了：Linux、Windows、网络设备、集群探针。但运维变更还有一种最重的形态——动整台机器：内核升级、大版本更新、激进参数调整。文件备份挡不住这类变更，你需要的是快照。最后一篇实战，讲怎么让 KVM 和 VMware 的虚机在 AI 手里打快照、做演练、一键回滚。