个人服务可靠性：Windows 计划任务、服务管理器、日志轮转与自动恢复策略 —— 横纵综合报告 未开始

题记与说明

综合报告（最终稿） · 课题：个人服务可靠性：Windows 计划任务、服务管理器、日志轮转与自动恢复策略
成文日期：2026-11-04 · 产出流水线：nightshift / nightly-research
输入：纵轴（历时）章节与横轴（共时）章节各一份（output/reports/parts/ 下同名文件），本文将其综合为最终报告，已消除两章之间的重复表述并统一了少量口径差异（差异点在正文相应位置注明）。
数据来源声明：两份章节的全部关键事实均来自 2026-11-04 当天的网络检索（WebSearch / 网页读取），关键结论附来源链接；无法从一手来源核实的细节（如 logrotate 确切首发年份、NSSM 1.0 发布日期）保留"未能核实"标注，未做虚构填充。
修订声明：2026-11-04 按独立审读意见逐条修订定稿。修订中新增两处当日核实：WinSW issue #1102（GitHub 页面读取：2024-12-10 建立，标题 "Is the project deprecated?"，维护者回应暂无时间维护并征集接手者）、healthchecks.io 官方集成文档（ping URL 形如 https://hc-ping.com/<uuid>，支持 /start 与 /fail 后缀，Period 与 Grace 共同决定告警时机）；3.6 节落地命令中 New-ScheduledTaskSettingsSet（-StartWhenAvailable、-RestartCount、-RestartInterval）、New-ScheduledTaskTrigger（-Daily、-At）、New-ScheduledTaskAction（-Execute）的参数名均已在本机 PowerShell 实测存在。

TL;DR

"个人服务可靠性"拆开是四个子问题：调度（到点有人叫它跑）、守护（死了有人拉起来）、日志（磁盘不爆、坏了能查）、监控兜底（"假活"有人发现）。Windows 原生栈的横向得分是"调度满分、守护及格、日志偏科、监控缺考"：任务计划程序的触发器全场最强，SCM 服务恢复只覆盖注册成服务的进程，普通文本日志至今没有任何原生轮转，"进程活着但功能死了"更无原生答案。三十年纵轴解释了这种分散：四件套分属五个年代、各自为战，从未有过统一设计，于是 srvany→NSSM→WinSW→Shawl/Servy 的包装器生态持续补位，单代包装器活跃期约十年上下、先后停更。2022 年 WSL2 获得 systemd 支持后，最佳实践从"二选一"转向分层组合。落地建议：调度用任务计划程序并手动打开"错过补跑"；守护按"注册服务用 sc failure、裸 exe 用 Shawl 或 Servy"；日志按"应用内滚动 > 包装器内建 > 事件日志兜底"；监控必挂 healthchecks 式外部心跳；包装器选型按"可替换件"对待、定期重估。

一、纵轴：发展脉络

个人服务可靠性不是 Windows 的原生概念，它是两条技术脉络在 90 年代中期的合流。纵轴回看，这条线索经历了六个阶段，每一次跃迁都由"承载对象变化"或"可靠性债爆发"驱动。

1.1 史前史（1975–1995）：两大源头

第一条脉络来自 Unix。 cron 诞生于贝尔实验室的早期 Unix（约 1970 年代中期），Version 7 Unix（1979）中的 cron 由 Brian Kernighan 编写，确立了"按时间表自动执行任务"的原型；1987 年 Paul Vixie 重写 cron（即 Vixie cron），加入更安全的实现与 @daily 等语法糖，成为日后绝大多数 Linux 发行版的标准组件（来源：Wikipedia: Cron、Softpanorama: History of Cron、vixie/cron 源码仓库）。日志轮转方面，Red Hat 在 90 年代中期开发了 logrotate，man 页面署名作者为 Erik Troan 与 Preston Brown（来源：logrotate(8) man page、man7.org logrotate(8)）；其确切首发年份（传言为 1996）未能在检索中从一手来源确认，Unix StackExchange 的考证帖也指出原始出处难以考证（来源：Who was the original author of logrotate?）。BSD 阵营另有 newsyslog 一线：源自 NetBSD，1997 年首次出现在 FreeBSD 2.2 中，按大小或时间轮转、可压缩归档并向守护进程发信号（来源：FreeBSD newsyslog(8) man page）。这一阶段确立的观念——定时执行 + 日志滚动 + 失败重启——就是后来 Windows 上"个人服务可靠性"要补齐的三件事。

第二条脉络是 Windows NT 的服务模型。 Windows NT 家族带来了服务控制管理器（SCM）：位于 %SystemRoot%\System32\services.exe 的系统进程，负责启动、停止和管理所有 Windows 服务；开机时从注册表 HKLM\SYSTEM\CurrentControlSet\Services 读入服务数据库，按依赖顺序拉起自动启动的服务；services.msc 与 sc.exe 都是通过同一套 API 与它对话（来源：Wikipedia: Service Control Manager，内容引自 Windows Internals 第 5 版）。SCM 随 NT 3.1（1993）问世属业界通识，本次未单独核验。服务模型的价值在于：把长驻进程交给操作系统托管——不依赖用户登录、随系统启动、崩溃由系统感知。这是个人服务可靠性的地基。

1.2 阶段一：诞生（1995–1999）——从 System Agent 到 Task Scheduler 1.0

• 1995 年：微软在 Microsoft Plus! for Windows 95 附加包中推出计划任务雏形 System Agent（来源：Wikipedia: Windows Task Scheduler）。它还只是个"提醒你整理磁盘"的小工具，但图形化定时任务从此进入 Windows。
• 1997–1998 年：随 Internet Explorer 4.0 的"Active Desktop 浪潮"，System Agent 更名 Task Scheduler 1.0 并随 IE4 分发（当时微软 KB 还在教用户排查"Task Scheduler 加载项装不上"、手工复制 Mstask.exe——来源：Microsoft KB 235634 镜像）；Windows 98（1998 年 6 月）起成为系统内置组件（来源：Wikipedia: Windows Task Scheduler）。
• 1998–1999 年：Task Scheduler 1.0 以 .job 二进制文件存储任务（存放于 %WINDIR%\Tasks），对外暴露 6 个 COM 接口；与 Unix 系 at 命令对应的 at.exe / AT 服务并行存在，但两套机制互不相通——at.exe 看不到图形界面建的任务（来源：Wikipedia: Windows Task Scheduler、nasbench: A Deep Dive Into Windows Scheduled Tasks）。

驱动因素：浏览器大战时期微软急于把"互联网体验"塞进操作系统，IE4 成为投放新壳层的载具；家庭 PC 普及让"开机自动整理磁盘、定时拨号"成为真实需求。此阶段可靠性概念尚未成型——任务挂了就是挂了，用户毫无感知。

1.3 阶段二：成型（2000–2006）——服务恢复的 GUI 化与脚本化

• 2000 年 2 月，Windows 2000：services.msc 的属性页出现 Recovery（恢复）选项卡，允许为"第一次失败 / 第二次失败 / 后续失败"分别配置"不操作 / 重启服务 / 运行程序 / 重启计算机"，还可设置重启延迟与失败计数重置周期（来源：O'Reilly《Windows 2000 Quick Reference》）。这是 Windows 上"自动恢复策略"第一次成为图形化的一等公民。对应 API ChangeServiceConfig2（SERVICE_CONFIG_FAILURE_ACTIONS）在现行微软文档中标注的最低支持版本为 Windows XP / Server 2003——文档标注与 GUI 功能实际出现的时间存在出入，本文以 O'Reilly 的 Win2000 资料为准认定 GUI 首现于 2000 年（来源：Microsoft Learn: ChangeServiceConfig2）。
• 2001 年，Windows XP：sc.exe 从 Windows 2000 Resource Kit 升格为系统内置命令行服务控制工具（来源：Wikipedia: Features new to Windows XP、Oracle 文档），sc failure 从此成为脚本化配置服务恢复动作的标准姿势。
• 同期（NT 时代延续）：把任意程序包装成服务的祖师爷 instsrv.exe + srvany.exe 流行于 Resource Kit 时代，微软至今保留 KB137890《Create a user-defined service》文档（来源：Microsoft Learn: Create a user-defined service）。但 srvany 有著名短板：不监控、不重启、不管理输出（来源：Core Technologies: Using Srvany），第三方包装器与看门狗工具由此开始生长——这正是后来 NSSM、WinSW 一族的市场空间。
• 2004 年：微软发布 Log Parser 2.2，用 SQL 方言统一查询事件日志、IIS 日志、文件系统等数据源（来源：Microsoft Download: Log Parser 2.2）。它侧面暴露了痛点：Windows 没有通用日志轮转——事件日志只是固定大小的循环文件，任意应用日志的轮转要靠用户自己写脚本。
• 同期的 Unix 世界：logrotate 与 newsyslog 已成标配，"轮转 + 压缩 + 保留 N 份 + HUP 信号"范式完全成熟，反衬出 Windows 的差距。

驱动因素：Windows 2000/XP 让 PC 开始承担服务器角色（小企业文件服务器、家庭媒体库），"服务崩溃后无人值守自愈"从可选变成刚需；图形化 Recovery 选项卡与脚本化 sc failure 是同一需求在 GUI 与 CLI 两个界面的落地。

1.4 阶段三：Vista 世代大重写（2006–2012）——可靠性基础设施定型

2006 年底至 2007 年初发布的 Windows Vista（及 2008 年的 Windows Server 2008）是本课题历史上最重要的一次代际跃迁，四件大事几乎同时发生：

1. Task Scheduler 2.0：彻底重写。MMC 控制台（taskschd.msc）取代旧界面；任务定义从 .job 二进制改为人类可读的 XML；新增日历与事件触发器——日志里出现某事件即可拉起任务，支持 XPath 过滤事件、任务链、失败后动作（RestartOnFailure 等）；任务历史记录进专用事件日志；Vista 自己的系统级任务全部迁移到 2.0，导致 Task Scheduler 服务从此不可禁用；API 膨胀到 42 个 COM 接口；还能从事件查看器直接"把任务附加到事件"（来源：Wikipedia: Windows Task Scheduler、Microsoft Learn: Task Scheduler 2.0 Interfaces、MSDN Magazine "Windows with C++: Task Scheduler 2.0"（2007-10））。事件驱动触发器让"出事了自动跑修复脚本"成为系统原生能力，这是自动恢复策略的一次质变。
2. 事件日志架构换代：.evt 二进制格式被 .evtx（Binary XML） 取代，引入 Windows Event Log 服务、按发布者的清单（manifest）体系与命令行工具 wevtutil（来源：Forensics Wiki: Windows XML Event Log (EVTX))、EventSentry 博客（2007-12）、Microsoft Learn: wevtutil）。
3. Windows 事件转发（WEF）：基于 WinRM 的订阅机制随 Vista/Server 2008 推出，支持"收集器发起"与"源发起"两种订阅，多机事件集中化不再依赖第三方代理（来源：Microsoft Learn: Windows Event Collector、Palantir: WEF-Subscriptions、Microsoft TechCommunity: The Security Log Haystack）。
4. Restart Manager：Vista 引入 Rstrtmgr.dll，在安装/更新时识别占用文件的进程，礼貌地关闭并在事后原地拉起，目标是"消灭或减少重启"（来源：Microsoft Learn: Restart Manager、CrowdStrike: The Windows Restart Manager、Daniel Moth 博客（2006-10））。Windows Installer 4.0 起自动接入。

SCM 侧同样在演进：延迟自动启动（Delayed Auto-Start）服务在 Vista 加入，缓解开机风暴（来源：Wikipedia: Service Control Manager）；服务触发事件（SERVICE_CONFIG_TRIGGER_INFO）则在 Windows Server 2008 R2 才补齐（来源：Microsoft Learn: ChangeServiceConfig2）——系统服务从此可以"按需唤醒"，不必常驻空转。

驱动因素：Vista 开发周期（Longhorn）的大志向之一就是让 Windows 成为"永远在线的服务平台"；企业 IT 对无人值守可靠性与安全合规（事件集中审计）的需求，通过 Server 2008 反哺到了桌面端。

1.5 阶段四：PowerShell 与包装器生态（2012–2019）——脚本化与社区补位

• 2012 年，Windows 8 / Server 2012 / PowerShell 3.0：ScheduledTasks 模块登场，Register-ScheduledTask、Get-ScheduledTask、Export-ScheduledTask 等命令让任务管理全面脚本化（仅 Win8/2012 及以后可用）（来源：MCPmag（2012-06）、Microsoft Learn: Register-ScheduledTask）；同一代 PowerShell 引入的 Scheduled Jobs 底层也构建在 Task Scheduler 基础设施之上（来源：Wikipedia: Windows Task Scheduler）。同年，at.exe 被正式弃用，微软明确建议改用 schtasks.exe（来源：Microsoft Learn: at command）——从 1995 年沿用下来的 AT 服务时代落幕，"两套任务机制互不相通"这笔旧账就此清算。
• 服务包装器社区生态成熟：Iain Patterson 的 NSSM（The Non-Sucking Service Manager）把任意程序包成服务并失败自动重启、日志写入事件日志，支持 Windows 2000+；其 changelog 结构显示 1.0 早于 2.x 系列存在（1.0 确切发布日期未能核实，2023 年的文献引用将项目归于 2007 年）；最终稳定版停在 2.24（2014-08-31），预发布版停在 2017-04-26，规划中的 v3 至今未发布（来源：nssm.cc、nssm.cc/changelog、nssm.cc/download、nssm.cc/v3）。另一支来自 CI 世界：Kohsuke Kawaguchi（Hudson/Jenkins 之父）为让 Jenkins 在 Windows 上以服务方式运行而写的 WinSW（Windows Service Wrapper） 约在 2008 年诞生（社区通识，首提交日期未逐条核验），Jenkins 至今捆绑 winsw.exe，后来迁入 jenkinsci 组织并发展出 .NET 版本（来源：JENKINS-15596: Jenkins will not start as a Windows Service、CSDN: 探索 Winsw）。
• 2008 年前后的运维写作已系统总结服务失败计数、重置周期等恢复参数的调优经验（来源：mdenomy 博客（2008-02）、ServerFault: How can I automatically restart a Windows service if it crashes?），"Recovery 选项卡 + sc failure + 看门狗任务"的组合拳成为社区标准答案。
• 安全视角加入：Task Scheduler 因其天然隐蔽性成为恶意软件持久化（persistence）的经典载体，研究社区系统梳理了 at/schtasks/COM 接口与对应进程链（来源：nasbench: A Deep Dive Into Windows Scheduled Tasks）；企业环境对任务与服务的审计需求上升，第三方托管封装库（如社区维护的 TaskScheduler .NET 库）顺势发展。

驱动因素：个人开发者与极客把旧 PC 变成家庭服务器（下载机、家庭媒体库、个人网站），Windows 免费内置的"服务 + 计划任务"是零成本方案，但原生包装能力（srvany 已老、NSSM 停更）不足，社区生态补位；DevOps 文化兴起让"一切皆脚本"成为审美，PowerShell 化水到渠成。

1.6 阶段五：Windows 10 世代（2015–2021）——强制更新冲击与可观测性补课

• 2015 年 Windows 10 推出"Windows 即服务"（WaaS）：自动更新随时可能重启机器，对 7×24 个人服务是直接的可靠性威胁。2016 年 8 月的 Anniversary Update（1607）引入 Active Hours（使用时段），承诺在用户设定的时间段内不自动重启（来源：gHacks（2016-04）、TenForums（2016-08）、Redmond Mag（2016-08））。从此"给个人服务做可靠性"必须多考虑一层：把维护窗口写进计划任务，同时与系统更新时间窗协商。
• 取证视角揭示的默认配置变化：Task Scheduler 2.0 的任务历史（Microsoft-Windows-TaskScheduler/Operational 事件日志）在较新的 Windows 10/11 中默认关闭，需手动开启"任务历史"（来源：Cyber Triage: Windows Scheduled Tasks for DFIR Investigations）。
• 监控栈的 Windows 原生化：Martin Lindhe 于 2016 年左右创建的 wmi_exporter 让 Prometheus 抓取 Windows 指标成为现实；2020 年 5 月项目决定更名并迁入 prometheus-community 组织，成为 windows_exporter（默认端口 9182，现行版本支持 Windows Server 2016+，并已嵌入 Grafana Alloy 生态）（来源：wmi_exporter Issue #519（更名决定）、prometheus-community/windows_exporter）。
• 个人级监控服务兴起：Louis Lam 于 2021 年 7 月发布 Uptime Kuma——自我托管的多协议拨测工具（HTTP/TCP/Ping/DNS/关键词），填补了"免费好用的自托管监控"空白，成为个人服务可靠性实践中事实上的标配看板（来源：Uptime Kuma About、GitHub: louislam/uptime-kuma）。
• 安全基线文档化：澳大利亚网络安全中心（ACSC）等机构发布 Windows 事件日志与转发指南，把 WEF 订阅 + 本地日志治理写成政府级基线（来源：ACSC: Windows event logging and forwarding（2021-10））。

驱动因素：家庭宽带与内网服务（NAS、家庭自动化、自托管 Web）爆发，"个人服务器"成为主流玩法；但 Windows 10 的消费级更新策略与企业级可靠性诉求正面冲突，用户被迫在个人版上做服务器级运维。

1.7 阶段六：融合与当下（2022–2026）

• 2022 年 9 月 21 日，WSL2 获得 systemd 支持（WSL 0.67.6+，微软与 Canonical 联合发布）：个人服务开始大规模"两条腿走路"——在 WSL 里用 systemd 单元/timer 管理服务、用 journald 看日志，Windows 侧只留一个开机引导用的计划任务（来源：Microsoft DevBlogs: Systemd support is now available in WSL、Microsoft Learn: WSL systemd、Ubuntu Blog（2022-09））。Unix 世界三十年的可靠性范式（单元声明式依赖、Restart=on-failure、journal 持久化与轮转）首次可以被 Windows 宿主机直接借用。
• 原生栈并未退场：windows_exporter 持续活跃（检索时 releases 页面仍处于活跃发布状态，最新版本支持 Windows Server 2016+，来源：prometheus-community/windows_exporter releases）；Windows 11 至今沿用 Task Scheduler 2.0 的架构与 XML 任务模式——Wikipedia 信息框把 Win11 的管理控制台标注为 "Task Scheduler 3.0"，但底层仍是 2.0 对象模型，本文按"3.0 只是界面标签、架构未换代"处理（来源：Wikipedia: Windows Task Scheduler）。schtasks.exe、Register-ScheduledTask、services.msc 恢复策略与 Restart Manager 组成的四件套仍是当前 Windows 个人服务可靠性的原生答案。
• 仍未解决的空缺（基于两章所读文档的分析判断）：Windows 至今没有内置的、面向任意应用日志的通用轮转工具——事件日志只有"固定容量 + 覆盖策略"这一种自我约束（来源：Microsoft Learn: wevtutil、Forensics Wiki EVTX 条目)），任意文本日志的轮转依旧要靠 PowerShell 脚本挂计划任务、应用内滚动或包装器接管。NSSM 停在 2.24、v3 难产（来源：nssm.cc/changelog、nssm.cc/v3），包装器一棒由 WinSW、Shawl、Servy、srvany-ng 等社区项目接棒（来源：srvany-ng、Shawl、Servy）。
• 本课题在项目中的落地：该课题登记于 D:/CodexData/nightshift/backlog/research-topics.md:77（纵轴章节会话内以 grep 实际读取确认），与"本地网络服务暴露""文件同步工具对比"等同属个人基础设施（personal infra）选题批次，由 nightshift 夜间研究流水线（2026-11-03/04 夜班）处理；其夜间调度本身即是本文所述技术栈的当代实践——Windows 计划任务每 5 分钟触发调度脚本，配锁文件、状态回执与失败即停策略（来源：D:/CodexData/nightshift/README.md，纵轴章节会话内读取）。

1.8 时间线总表

1.9 驱动力主线（纵轴洞察）

1. 承载对象变了三次：桌面 PC（95–XP 时代，定时整理磁盘）→ 部门/家庭服务器（2000 时代，无人值守自愈）→ 永远在线的个人基础设施（2015 之后，NAS/自托管/自动化流水线）。每次承载对象变化都倒逼一轮机制升级，这是本课题最根本的驱动因素。
2. 微软的重写都发生在"可靠性债"集中爆发之后：Task Scheduler 2.0、EVTX、Restart Manager（2006）是一次总清账；PowerShell 化（2012）与 at.exe 之死是对"两套任务机制互不相通"的清算；而"任意日志轮转"至今未清账，属于平台留给生态的持续空缺。
3. 社区生态始终在补 Microsoft 的短板：srvany→NSSM/WinSW 的包装器谱系、wmi_exporter/windows_exporter 的监控谱系、Uptime Kuma 的拨测谱系，均由个人开发者主导——个人服务可靠性这个领域，使用者与建设者高度重叠，这也是它至今保持旺盛社区生命力的原因。
4. 2022 年 WSL2 systemd 支持是最近的分水岭：Windows 侧原生工具链（Task Scheduler + SCM Recovery + wevtutil）与 Linux 侧范式（systemd unit + journald + logrotate）从"二选一"变成"分层组合"，当下的最佳实践正在从单栈走向混合编排。

二、横轴：横向对比

纵轴讲的是"怎么走到今天"，横轴在 2026-11-04 这个时间截面上回答"现在谁更好用"。对比方法：把"个人服务可靠性"拆成调度 / 守护 / 日志 / 监控兜底四个子层，每一层与同类与替代方案逐一比较。

2.1 课题拆解：四层框架

贯穿全文的总判断：Windows 原生栈的四层能力是"分散的"——调度器甚至比 Linux cron 更强，但守护、日志两层的原生能力很弱，四层分布在四个互不相干的界面和工具里；而 Linux systemd 把其中三层（timer 调度 + Restart= 守护 + journald 日志）收进同一个框架。这就是所有"胶水工具"（NSSM/WinSW/Shawl/Servy）存在的根本原因。 纵轴（1.9 节）恰好解释了为什么会这样：四件套分属五个年代，各自为当时的承载对象而建，从未有过一次"统一可靠性框架"的总设计。

2.2 调度层：Windows 任务计划程序 vs cron vs systemd timer vs launchd

逐项说明：

• 任务计划程序被严重低估，但"伪装守护进程"是反模式。 任务计划程序在触发器种类（事件触发、空闲触发、唤醒机器、missed-run 补跑）上比 cron 丰富得多，Linux 用户甚至把 systemd timer 视为"最接近 Windows 任务计划程序的东西"[2]。但它当守护进程用有三个坑：错过补跑开关默认关闭；"失败后重启"仅当任务进程自行退出且返回非零退出码时才触发重试，进程被强杀、断电等硬终止不触发重试[1]；任务历史默认关闭（纵轴 1.6 节的取证发现与此互证），排障要自己翻事件查看器。此外 PowerShell 的 PSScheduledJob 模块在 PowerShell 7 中已不可用（仅 5.1），社区推荐替代是直接用 ScheduledTasks 模块操作任务计划程序[6]——Windows 侧的官方路线已收敛到任务计划程序本身。
• cron 的可靠性短板是结构性的。 cron 至今没有错过补跑、没有重试、没有内置日志聚合，一行配置的极简是它的全部和全部问题[2][3]。对"个人服务可靠性"而言，cron 是"够用但不可靠"的下限。
• systemd timer 是当前 Linux 侧的可靠性标杆。 Persistent=true 补跑、依赖管理、cgroups 资源限制、journald 日志一体化，代价是必须写两个 unit 文件[2][3]。2026 年的社区共识是"cron 用于快糙猛的简单任务，生产级定时任务用 systemd timer"[3]。
• launchd 用声明式 plist 解决同一问题。 macOS 侧的 KeepAlive（含 SuccessfulExit、NetworkState 等变体）与 Windows SCM 的服务恢复选项大致对位[5]，但 macOS 对"个人服务器"场景不友好（休眠策略、无头运行成本高），在本课题选型中权重很低，列出仅供完整性。

小结：调度层是 Windows 原生栈的强项。 任务计划程序 + 正确勾选补跑/重试，能力上不输 systemd timer；真正的问题不在调度层，而在下面两层。

2.3 守护层：SCM 原生恢复 vs 服务包装器 vs pm2 vs systemd/Docker

这是竞争最激烈、生态变化最明显的一层，也是 2025–2026 年出现"换血"的一层。

逐项说明：

• Windows 原生恢复机制：免费、可靠、但只覆盖"注册成服务"的进程。 sc.exe failure 可以给任意服务配"失败动作链"，例如重启两次、第三次改为跑一个救援脚本：sc failure "MyService" reset= 86400 actions= restart/60000/restart/60000/run/10000，动作类型仅 restart/reboot/run/none 四种[7][8]（与纵轴 1.3 节 Win2000 Recovery 选项卡的 GUI 四选项一一对应，两章口径一致）。本质缺陷：非服务化的普通 exe 无法享受，且它不知道进程"假活"（进程在但功能已死）。"计划任务 + 失败重启"可以伪装守护进程，但由于 2.2 节列出的硬崩溃不触发等问题，只适合容忍偶发中断的弱需求。
• 包装器代际更替：NSSM → WinSW → Shawl/Servy。 这是本次横轴对比最重要的生态发现，且与纵轴互相印证：NSSM（约 2007 年起步、2017 年停更）是"经典但已死"，但它有两项到今天都没过时的设计——把任意 exe 的 stdout/stderr 重定向到文件并支持在线按大小轮转（AppRotateOnline），以及进程树清理[10]；其参数明文写入注册表的安全问题在后来者的对比文档中被反复点名[11]。WinSW 是"半退休"：双版本停在 2023-01-28[12]；2024 年 12 月仓库内出现"项目是否已弃维护"的公开 issue（#1102，维护者回应暂无时间维护并征集接手者，至今未关闭），2025 年 Jenkins 社区亦公开讨论替代方案[14]；其声明式 XML + 三种日志滚动模式仍是设计上的标杆，尽管 roll-by-size-time 有不按大小滚动的已知 bug[13]。Shawl（Rust，v1.8.0，2025-12-08[15]）与 Servy（C#，v10.7[16]）接过这一层：前者胜在活跃 + 单文件极简，后者把"包装器"升维成"带 GUI 的个人级可靠性平台"——健康检查、自动重启、心跳 URL（对接 healthchecks.io 并路由到 Slack/Telegram 等）、DPAPI+AES-256 凭据加密、进程树僵尸清理、签名二进制与 SBOM[11][16][17]。需要提醒：Servy wiki 中对 NSSM/WinSW 的"不安全"指控来自竞争对手自己的文档，方向可信、程度需独立验证[11]。
• pm2 在 Windows 上是"套娃"方案。 pm2 的 pm2 startup 不支持 Windows，旧的 pm2-windows-service 已弃用并指路 pm2-installer，而 pm2-installer 本身做的事——把 pm2 注册成 Windows 服务——与 NSSM 同构[18]。对 Node 之外的任何语言，pm2 都不是 Windows 首选。
• 与 Linux/容器侧的对照揭示了"能力-复杂度"光谱。 systemd 用 Restart=always/on-failure + RestartSec + StartLimitIntervalSec/StartLimitBurst（限速防爆刷）实现守护，是这一层的能力上限；但它自己官方也承认 Restart=always 的滥用会把失败藏起来[4][19]。Docker 的 unless-stopped 与 always 的语义差异（手动停止后，守护进程重启时要不要复活）是同一问题的容器化表达[20]。Windows 侧没有任何原生机制同时覆盖这两者的全部语义，这正是包装器市场的生存空间。

小结：守护层是"补丁文化重灾区"。 2026 年的新部署推荐顺序：已有服务化程序直接用 SCM 原生恢复；裸 exe 用 Shawl（极简）或 Servy（要监控）；Node 生态用 pm2-installer；WinSW 可继续用于存量（Jenkins 等大项目仍在用），但不建议作为新依赖。

2.4 日志层：Windows 事件日志 vs logrotate/journald vs 应用内滚动 vs 包装器内建

逐项说明：

• Windows 只对事件日志有原生轮转，对普通文本日志"什么都没有"。 事件日志的 .evtx 文件由系统独占管理：用 wevtutil sl Security /ms:1073741824 调大上限，/rt: 可选 AutoBackup（满后归档换新文件）或 Retain（拒收新事件防覆盖）[21]。但对个人服务最常产生的普通文本日志，Windows 没有任何原生轮转机制——这与 Linux（logrotate 事实标准 + journald 内建）形成最刺眼的对比[2][22]。这与纵轴 1.3/1.7 节"2004 年 Log Parser 时代即暴露、至今未清账"的判断一致，两章在此完全互证。
• Windows 文件锁决定了日志策略的上半场在"写日志的那一刻"。 Linux 的 logrotate 之所以能外挂轮转活动日志，是因为它可以给进程发信号要求重开文件；Windows 没有等价机制，正在被写入的文件被锁住，外挂轮转要么失败要么丢数据[24]。社区由此收敛出两条正路：要么在应用内滚动（Serilog/NLog 的滚动目标，自己在写的时候切文件[24]），要么让包装器接管输出（NSSM/WinSW 在管道层面轮转[10][13]）。Log-Rotate（PowerShell 版 logrotate 移植[22]）的合理用途被压缩到"轮转已归档的历史文件"。
• 对"不写代码的个人服务"（别人给的 exe、第三方脚本），包装器内建轮转几乎是唯一解。 这一点与守护层的结论合流：在 Windows 上，选哪个服务包装器，同时就决定了日志策略——NSSM 按大小轮转、WinSW 可按时间+大小轮转、Servy 提供按服务隔离的日志目录[10][13][11]。事件日志则无论选谁都应该开：它是 Windows 唯一"系统替你管好"的日志层，也是任务计划程序排障的唯一官方出处。

小结：日志层是 Windows 原生栈的最大短板，但短板有清晰的绕法。 推荐分层：程序内能用 Serilog/NLog 就用应用内滚动；程序改不了就换有内建轮转的包装器（新装选 Shawl/Servy；WinSW 仅限已引入的存量场景，原因见 2.3 小结；弃用"裸跑+事后清理"）；事件日志调大上限作为系统层兜底。

2.5 监控兜底层："假活"是四层框架解不掉的问题

前三层都解决不了同一类失败：进程活着，但功能死了（死锁、句柄耗尽、上游服务换接口后脚本空转）。这是为什么以 Servy 为代表的新一代服务包装器开始内置"健康检查 + 心跳"——Servy 的做法是让服务向指定 URL 汇报心跳，失败即路由到 healthchecks.io 并推送到 Slack/Teams/Discord/Telegram[11]——就本次检索所见，这一组合目前仅 Servy 一例（2.3 节表格中 Shawl、NSSM 均无此能力，WinSW 亦仅有限支持）。healthchecks.io 代表的"死人开关"（dead man's switch）模式——由外部周期性验证"我最近真的成功跑过"，而不是验证"进程还活着"——是 Windows 原生栈完全没有对应物的一层（Uptime Kuma 是同一思路的自托管拨测实现，见纵轴 1.6 节）。个人服务可靠性方案若只有四件套而没有外部心跳，本质上只防住了"崩溃"，没防住"假活"。

2.6 整栈横向对比：五条技术路线的四层能力矩阵

把前四节收拢成一张矩阵（✓ 原生完备 / ◐ 可用但要胶水或第三件套 / ✗ 缺失）：

这张矩阵直接回答了本课题在竞争格局中的定位：Windows 原生栈的调度层不输任何对手，守护与日志两层必须靠生态补齐（路线 B），补齐后的总成本仍然低于迁移到 Linux（路线 C）——前提是接受"包装器选型按可替换件对待、定期重估"这个事实，因为 NSSM（2017 停更）、WinSW（2023 停更）的先例刚刚上演过一轮。

三、交叉洞察：两轴结合说明了什么

单看纵轴是编年史，单看横轴是选购指南；两条轴放在一起，才能看清"个人服务可靠性"这个课题的真实结构。以下五条洞察均由两轴交叉得出。

3.1 横向的"四层分散"，是纵向五个年代各自建成的结果

横轴最扎眼的发现是：Windows 的四层能力散落在任务计划程序、services.msc、事件查看器、第三方包装器四个互不相干的界面里。纵轴解释了这不是设计失误，而是历史沉积：调度层是 1995 年作为桌面附属功能问世的；守护层 2000 年才 GUI 化、且从一开始就只覆盖"注册成服务"的进程；日志层在 2006 年只换掉了事件日志的内核、从未接管任意应用日志；监控兜底层则从未进入原生范围。每一层都为当时的承载对象（桌面 PC → 部门服务器 → 个人基础设施）而建，Microsoft 从未做过一次"把四层收进一个框架"的总设计。对照组恰好说明这一点：Linux systemd 从头就是 init 系统，守护是它的本职，timer 和 journald 顺理成章长在同一个框架里——"三层一体"不是 systemd 聪明，而是 Windows 的四件套没有亲缘关系。

3.2 胶水生态的"换血"节奏，横向发现由纵向先例背书

横轴发现包装器市场正在换血（NSSM 2017 停更、WinSW 2023 停更、Shawl/Servy 2025 接棒）；纵轴显示这不是第一次——srvany（Resource Kit 时代）→ NSSM（约 2007）→ WinSW（约 2008，Jenkins 捆绑）的更替早就发生过一轮。把两轴放在一起本可给出一个带时间刻度的经验规则，但把日期摆上桌面，"整齐的换代周期"并不成立：NSSM 约 2007 年起步（该年份仅见于 2023 年文献转述、无一手链接）、2017 年停更，活跃约十年；WinSW 约 2008 年诞生、2023-01-28 停更，活跃约十五年——且两者长期并存十余年，并非一前一后的代际更替。因此本文不用"每 N 年一换"的公式，只保留一条弱化版规则：单代 Windows 服务包装器的活跃期约十年上下，新老长期并存、先后停更，选型必须按"可替换件"对待——具体做法是：包装器只承担"启动 + 重启 + 重定向"这类最小职责（Shawl 路线），把健康检查、心跳等易变需求放在包装器之外（healthchecks.io/Uptime Kuma），这样换血时迁移成本最低。反过来，Servy 把四层功能全部收进一个包装器，功能最全，但一旦它停更，需要迁移的功能面也最大——它自身 2024 年才出现，社区存量小，两个判断需同时纳入。

3.3 "微软总在债爆之后重写"——据此可以预判下一个缺口

纵轴的三次大动作（2006 Vista 总重写、2012 PowerShell 化 + at.exe 弃用、2016 Active Hours 应对 WaaS 冲击）都发生在可靠性债集中爆发之后；而横轴指出当前最大的未清账项是任意文本日志的通用轮转与假活检测。交叉推论：短期内（以微软对 Win11 的维护节奏）不要指望原生补齐——事件日志架构 2006 年定型后近二十年未再换代，任务计划程序 2012 年后仅做增量；所以这两层的解法在未来数年内仍属生态（应用内滚动、包装器、healthchecks 式心跳），而不属平台。个人部署不应把架构押在"下一个 Windows 版本会解决"上。

3.4 2022 年 WSL2 systemd 是纵向分水岭，横向含义是"分层组合"

纵轴把 2022-09 的 WSL2 systemd 支持（WSL 0.67.6+，微软与 Canonical 联合发布）列为最近的分水岭；横轴的整栈矩阵则为它补上了经济学含义：路线 C（Linux systemd 栈）的维护心智成本最低，路线 A/B（Windows 原生 + 生态）的迁移成本最低，WSL2 让两者可以按服务拆分组合——需要 Windows 专属软件（如依赖 Win32 API 的工具）的服务留在原生栈（路线 B），纯脚本/开源服务放进 WSL 用 systemd timer + Restart= + journald 管理，Windows 侧只留一个开机引导用的计划任务。二选一变成分层组合，这是 2026 年个人服务可靠性的新默认。

3.5 成本结构：金钱成本全是零，真正的变量是"心智 + 换血 + 更新窗"

五条路线的金钱成本全部为零（内置或开源）——横轴矩阵的这一列高度一致；纵轴则指出了三个金钱之外的真实成本：维护心智成本（Windows 栈要求同时熟悉任务计划程序、SCM、包装器、事件日志四个体系；systemd 栈只要一个框架）、换血成本（单代包装器活跃期约十年上下、先后停更，见 3.2 节）、更新窗成本（Windows 10/11 的 WaaS 强制更新随时重启机器，2016 年 Active Hours 只承诺"使用时段不重启"，维护窗口仍需写进计划任务并与更新窗协商）。对个人用户而言，选型的真实问题从来不是"哪个免费"，而是"愿意长期背哪几份心智账"。

3.6 对用户的判断与建议

综合两轴，给出按四层组织的落地清单（每条都注明理由出处）：

1. 调度层（选 Windows 原生，务必调两个开关）：任务计划程序是全场触发器最丰富的选择[1][2]。最小落地（GUI）：新建任务后进"属性 → 设置"页，勾选"如果错过计划开始时间，尽快启动任务"（Run task as soon as possible after a scheduled start is missed，对应语言无关的设置项 StartWhenAvailable，默认关闭）[1]，并在同页配置"任务失败时按间隔重启"（默认 1 分钟、最多 3 次）[1]；命令行等效一行（涉及参数名均经本机 PowerShell 实测存在）：Register-ScheduledTask -TaskName "nightly-job" -Trigger (New-ScheduledTaskTrigger -Daily -At 23:00) -Action (New-ScheduledTaskAction -Execute "C:\jobs\job.cmd") -Settings (New-ScheduledTaskSettingsSet -StartWhenAvailable -RestartCount 3 -RestartInterval (New-TimeSpan -Minutes 1))；理解"失败重启"仅当任务进程自行退出且返回非零退出码时触发、进程被强杀/断电等硬终止不触发[1]，不要拿计划任务当守护进程。
2. 守护层（注册服务用原生，裸 exe 用新包装器）：已注册的原生服务一律配 sc failure 动作链（如 sc failure "MyService" reset= 86400 actions= restart/60000/restart/60000/run/10000，reset= 为失败计数清零秒数、actions= 为"动作/延迟毫秒"序列；GUI 等效操作：services.msc → 服务属性 →「恢复」选项卡）[7][8]；裸 exe 新项目选 Shawl（极简、活跃）[15]或 Servy（要 GUI/健康检查/心跳/凭据加密时）[16][11]；新依赖不要选 NSSM/WinSW（停更近十年 / 三年无 release）[9][12]，存量 Jenkins 等场景可继续用；Node 生态用 pm2-installer[18]。
3. 日志层（应用内滚动 > 包装器内建 > 事件日志兜底）：Windows 文件锁使"外挂轮转"这一 Linux 思维失效[24]；程序内能用 Serilog/NLog 就用应用内滚动[24]；改不了的第三方 exe 靠包装器接管输出[10][13]；事件日志无论选谁都要做两件事——用 wevtutil sl <Log> /ms: 调大上限（示例同 2.4 节：wevtutil sl Security /ms:1073741824，即 1 GiB）[21]、在任务计划程序里手动开启"任务历史"（GUI 操作：任务计划程序 → 右侧"操作"窗格 →"启用所有任务历史"/Enable All Tasks History；默认关闭）。
4. 监控兜底层（无原生答案，必须外挂）：healthchecks.io 式"死人开关"是防"假活"的唯一手段[11]。最小接线：在 healthchecks.io 建一个 Check，得到形如 https://hc-ping.com/<uuid> 的 ping URL；在计划任务脚本末尾加一行 curl -fsS https://hc-ping.com/<uuid>（纯 PowerShell 脚本用 Invoke-WebRequest -UseBasicParsing https://hc-ping.com/<uuid> | Out-Null）；在控制台把 Check 的 Period 设为略大于任务调度周期、Grace 留出执行余量，Period+Grace 时间内未收到 ping 即判定 Down，按配置的邮件/Slack/Webhook 告警；需要区分"跑了但失败"时，可在脚本开头 ping <uuid>/start、失败分支 ping <uuid>/fail。自托管可选 Uptime Kuma；没有它，前三层只能防崩溃、防不了静默失败；Servy 已把这一层产品化，但注意 3.2 节对"功能全收进包装器"的耦合提醒。
5. 整栈策略（按服务拆分，原生与 WSL2 混合）：Windows 专属依赖留在原生栈（路线 B），纯脚本/开源服务进 WSL2 用 systemd 管理（路线 C 的能力、本地运行的便利）（见 3.4 节）；同时把维护窗口写进计划任务、与 Active Hours/更新窗协商（见 1.6 节）。
6. 周期性重估：每当所用包装器连续两年无 release、或出现更活跃的成熟替代，即重新评估包装器选型（见 3.2 节）；本文写作当日（2026-11）的推荐组合是"任务计划程序 + sc failure/Shawl/Servy + 应用内滚动或包装器轮转 + healthchecks 式心跳"。

一个收尾的印证：承载本课题的 nightshift 流水线自身就是这套技术栈的当代实践——Windows 计划任务每 5 分钟触发调度脚本，配锁文件、状态回执与失败即停策略（D:/CodexData/nightshift/README.md）。它用的正是"调度层原生 + 应用层自管可靠性"的组合，没有依赖任何停更包装器——其调度与失败即停的做法与本报告的推荐一致；至于监控兜底层，README 所述机制中未见外部心跳配置，按第 4 条的标准，这一层对它而言仍是待补项，本文不对之作已达成断言。

四、两章口径差异的处理说明

综合过程中对两份章节做了如下对齐（正文已按统一口径表述）：

1. NSSM 时间线：纵轴写"2.24（2014 年前后）"，横轴给出精确日期"2.24（2014-08-31）、预发布 2017-04-26"——本文采用横轴精确日期，并保留纵轴"1.0 发布日期未能核实"的标注。
2. Windows 11 的任务计划程序版本：纵轴提到 Wikipedia 信息框标注 "Task Scheduler 3.0" 但底层仍是 2.0 对象模型——本文统一按"3.0 只是界面标签、架构未换代"表述，避免与横轴"沿用 TS 2.0 架构"产生版本号矛盾。
3. 任务历史默认关闭：两章各提一次（纵轴在 Win10 取证视角、横轴在调度层短板）——本文在 1.6 节保留历史发现，在 2.2 节与落地清单中引用，不再重复展开。
4. "Windows 无通用日志轮转"：两章结论一致（纵轴从 2004 Log Parser 与当下空缺两处论述、横轴从文件锁机制论述）——本文合并为一条主线：2004 年暴露、2006 年只换了事件日志内核、至今未清账，机制原因是文件锁。
5. SCM 恢复动作：纵轴的 GUI 四选项（不操作/重启服务/运行程序/重启计算机）与横轴的 CLI 四动作（none/restart/run/reboot）为同一机制的两种界面，本文合并表述并互注。
6. ChangeServiceConfig2 文档标注（XP/2003 起）与 Recovery 选项卡首现（Win2000）的时间出入：本文以 O'Reilly 的 Win2000 资料为准认定 GUI 首现，并保留文档标注原文，不做调和性猜测。

五、参考来源

以下链接均于 2026-11-04 由两份章节的检索会话抓取验证；编号 [1]–[24] 在正文横轴部分（第二章）复用，纵轴章节（第一章）的来源以行内链接标注。

调度层：

1. ServerFault: Failed Scheduled Task Does Not Restart；Advanced Installer: Task Scheduler Settings（失败重启/错过补跑设置及默认值）
2. xtom: Systemd Timers vs. Cron；unix.stackexchange: Cron vs systemd timers（cron 无补跑/无内置日志，timer 补跑）
3. linuxcert.guru: Systemd Timers vs Cron；dev.to: Cron vs Systemd Timers vs daemontools（两个 unit 文件的成本、生产级共识）
4. systemd.service 官方文档；unix.SE: Restart=always 含义
5. launchd.info；Apple: Creating Launch Daemons and Agents（KeepAlive 变体）
6. PowerShell #12743: PSScheduledJob 在 PS7 不可用；MS Docs: PSScheduledJob（仅 5.1）

守护层：

1. MS Learn: sc failure 命令)；Octopus: Set Recovery on Failure Actions
2. Medium: Configure Windows Service Recovery from Command Line；/r/PowerShell 动作链示例
3. nssm.cc/download（2.24 于 2014-08-31；预发布 2017-04-26；Public Domain）；nssm.cc；nssm.cc/changelog；nssm.cc/v3
4. nssm.cc/usage；nssm.cc/commands（AppStdout/AppStderr、AppRotateOnline、nssm rotate）
5. Servy wiki: Comparison with Alternatives（注意：竞争方文档，NSSM/WinSW 安全问题的描述需独立验证）
6. WinSW Releases；WinSW issue #1129（v2.12.0 / v3.0.0-alpha.11 均为 2023-01-28）；WinSW issue #1102 "Is the project deprecated?"（2024-12-10 建立，维护者称暂无时间维护并征集接手者）
7. WinSW v3 日志文档（roll-by-size/time/size-time）；issue #894（size-time 轮转 bug）
8. Jenkins 社区: WinSW deprecated? Any alternatives?；JENKINS-15596
9. Shawl releases（v1.8.0, 2025-12-08）；Shawl 主仓库
10. Servy 官网；Servy releases（v10.7）；SignPath 项目页
11. Servy 主仓库（MIT 许可）；dev.to: Servy vs NSSM vs WinSW
12. pm2-windows-service（已弃用，指路 pm2-installer）；StackOverflow: Node 进程管理器选型（Windows）
13. systemd issue #30804（Restart=always 掩盖失败状态）
14. Docker 官方文档: Start containers automatically（四档 restart policy）

日志层：

1. MS Learn: wevtutil（/ms、/rt、AutoBackup）；SOC Prime: Export Windows Event Logs EVTX
2. theohbrothers/Log-Rotate（PowerShell 移植）；PowerShell Gallery: Log-Rotate 1.3.0
3. ServerFault: Equivalent of LogRotate for Windows?；Storj 论坛: Windows 原生日志轮转讨论（普通文本日志无原生轮转）
4. ServerFault 同上 + NLog/Serilog 滚动配置（Windows 文件锁→应用内滚动成为推荐模式；NLog archiveEvery/maxArchiveFiles，Serilog rollingInterval/retainedFileCountLimit）

历史与平台脉络（纵轴）：

• Wikipedia: Windows Task Scheduler；Microsoft Learn: Task Scheduler 2.0 Interfaces；MSDN Magazine: Task Scheduler 2.0（2007）；Microsoft KB 235634 镜像；nasbench: A Deep Dive Into Windows Scheduled Tasks
• Wikipedia: Service Control Manager；Microsoft Learn: ChangeServiceConfig2；O'Reilly: Windows 2000 Quick Reference（Recovery 选项卡）；Wikipedia: Features new to Windows XP（sc.exe）；Oracle 文档（sc.exe）
• Microsoft Learn: Create a user-defined service（srvany/instsrv）；Core Technologies: Srvany 的局限；srvany-ng
• Forensics Wiki: EVTX)；EventSentry: Vista/2008 Event Log Changes；Microsoft Learn: Windows Event Collector；Palantir: WEF-Subscriptions；Microsoft TechCommunity: The Security Log Haystack；ACSC: Windows event logging and forwarding（2021-10）
• Microsoft Learn: Restart Manager；CrowdStrike: Windows Restart Manager；Daniel Moth（2006）
• Microsoft Learn: at command（弃用声明）；MCPmag: Managing Scheduled Tasks with PowerShell（2012）；Microsoft Learn: Register-ScheduledTask；mdenomy 博客（2008-02）；ServerFault: 自动重启崩溃服务；TaskScheduler .NET 库；CSDN: 探索 Winsw
• gHacks: Active Hours（2016）；TenForums（2016）；Redmond Mag（2016-08）；Cyber Triage: Scheduled Tasks for DFIR
• wmi_exporter Issue #519；prometheus-community/windows_exporter；windows_exporter releases；Uptime Kuma About；louislam/uptime-kuma
• Microsoft DevBlogs: systemd in WSL（2022）；Microsoft Learn: WSL systemd；Ubuntu Blog（2022-09）；Wikipedia: Cron；Softpanorama: History of Cron；vixie/cron 源码仓库；FreeBSD newsyslog(8)；logrotate(8) man page；man7.org logrotate(8)；logrotate 原始作者考证（unix.SE）；Microsoft Download: Log Parser 2.2

项目内部来源（本会话内读取）：

• D:/CodexData/nightshift/backlog/research-topics.md:77（课题登记，纵轴章节以 grep 实际确认）
• D:/CodexData/nightshift/README.md（nightshift 夜间调度机制：计划任务每 5 分钟触发、锁文件、状态回执、失败即停）

未核实事项声明（沿用两章标注并合并）：logrotate 确切首发年份、NSSM 1.0 发布日期与 NSSM 起步年份（"约 2007"仅见 2023 年文献转述、无一手链接）、WinSW 约2008 年诞生的首提交日期、SCM 随 NT 3.1 问世（通识）均未从一手来源单独核验；Servy 对 NSSM/WinSW 的安全指控仅来自竞争方 wiki 与 dev.to 文章，未独立复现；Shawl 与 Servy 的 GitHub star 数、精确发布频率未逐一核对；n8n/Home Assistant 等更上层自动化平台因姊妹报告（《个人自动化平台对比》，2026-10-29；《把 Windows 机器变成 24 小时服务》，2026-10-29）覆盖，本篇仅在整栈矩阵中提及、未展开。

*综合报告最终稿 · 由纵轴（历时）与横轴（共时）两份章节综合而成 · 2026-11-04 · 按独立审读意见修订定稿*