On-Call Health：给 SRE 的"体检报告"，在倦怠压垮你之前拉你一把

2026-02-12 | Product Hunt | 官网 | GitHub

主界面是一个倦怠分析仪表盘，左侧深色导航栏，右侧四大核心模块：倦怠时间线、健康趋势、团队风险因子雷达图、个人风险评分。颜色从绿到红直观标记严重程度，一眼能看出谁快撑不住了。

30秒快速判断

这App干嘛的：从 PagerDuty、GitHub、Slack、Jira 等工具里抽取信号，再结合工程师自己的感受打分，算出一个"倦怠风险分数"。说白了就是给 on-call 工程师做体检，在他们默默崩溃之前发出预警。

值不值得关注：如果你管着一支有 on-call 轮值的团队 -- 必须关注。这是目前唯一一个基于学术研究框架（哥本哈根倦怠量表 CBI）、开源免费、还能自托管的 on-call 健康检测工具。PagerDuty 的 Analytics 只给你看数字，这个直接告诉你"谁快不行了"。

与我有关三问

与我有关吗？

• 目标用户：SRE/DevOps 团队的 Engineering Manager、Tech Lead、VP of Engineering，以及任何参与 on-call 轮值的工程师
• 我是吗：如果你每周要看 PagerDuty 排班表，或者团队里有人因为 on-call 压力想离职 -- 你就是目标用户
• 什么场景会用到：
  • 团队有人连续几周 on-call 负荷偏高 -> 用这个提前发现
  • 季度 review 时想量化 on-call 对团队健康的影响 -> 用这个出数据
  • 新人刚加入 on-call 轮值，想确保不被压垮 -> 用这个监控
  • 你是个人开发者，不做 on-call -> 不需要这个

对我有用吗？

ROI 判断：如果你的团队超过 5 人且有 on-call 轮值，花 30 分钟部署一下绝对值得。一个资深 SRE 因为倦怠离职的招聘+培训成本动辄几十万，这工具免费帮你提前发现风险。

喜闻乐见吗？

爽点在哪：

• 个人基线追踪：不拿你和别人比，而是跟你自己的历史比。老手能扛的负荷和新人不一样，这个设计很聪明
• 多信号融合：不只看 page 数量，还看 after-hours 活动、PR 量、代码审查频率、Slack 时间分布
• AI 摘要：自动告诉你"什么变了、为什么变了"，周报不用自己写了

用户真实评价：

"任何在快节奏公司工作过的人都知道 pager 疲劳和倦怠是多么真实。特别是随着 AI 编程助手加速了（复杂）事故的数量，衡量这一点从未像现在这样重要。" -- Product Hunt 用户

"SRE 的倦怠从外部看很少是戏剧性的。它看起来只是某人悄无声息地失去了参与感。让这种状态可见的工具早就该出现了。" -- Product Hunt 用户

"我以前常告诉自己 on-call 时我'还好'。但那是一种缓慢的侵蚀。晚餐时的 Slack 提醒。为了'以防万一'而不吃医生开的安眠药。围绕着笔记本电脑规划周末。" -- Product Hunt 用户

给独立开发者

技术栈

• 前端：Web 应用（托管版 oncallhealth.ai）
• 后端：Docker Compose 部署，支持自托管
• AI/模型：AI 分析趋势变化和驱动因素（具体模型未公开，但 Rootly AI Labs 有 Anthropic 和 Google DeepMind 支持）
• 认证：Google OAuth / GitHub OAuth
• 研究基础：Copenhagen Burnout Inventory (CBI) + Maslach Burnout Inventory (MBI)

核心功能实现

数据采集层连接 PagerDuty/Rootly 拿事故数据（响应时间、严重程度、非工作时间 page 数），GitHub 拿代码活动（PR 量、commit 频率、代码审查），Slack 拿沟通模式和自报告 check-in，Jira/Linear 拿工作量（issues 分配）。所有信号汇总后计算 OCH Score（0-100），用个人历史基线做对比，而不是固定阈值。分数分四档：0-24 维持平衡、25-49 监控风险、50-74 早期干预、75-100 立即行动。

左侧柱状图展示每个团队成员的 CBI 倦怠评分，中间雷达图从五个维度（工作强度、响应压力等）分析团队整体风险因子，右侧时间序列图追踪健康趋势变化。

开源情况

• 开源：完全开源，GitHub 仓库 Rootly-AI-Labs/On-Call-Health
• License：可 fork 可自定义
• 类似开源项目：没有直接竞品。Grafana OnCall 做排班但不做倦怠检测，而且 OSS 版已进入维护模式（2026年3月归档）
• 自己做难度：中等偏高。数据集成不难（都是现成 API），难的是倦怠评分模型的设计和校准。如果不想从零研究 CBI/MBI，直接 fork 这个项目改是最快的。预计 1-2 人月

商业模式

• 变现方式：On-Call Health 本身不变现，完全免费开源
• 真实目的：Rootly 母公司的事故管理平台是付费的，On-Call Health 是获客工具。你用了免费的倦怠检测，发现团队 on-call 有问题，自然会考虑买 Rootly 的完整方案
• 客户量：Rootly 母公司服务 NVIDIA、LinkedIn、Dropbox、Tripadvisor 等

巨头风险

PagerDuty 有 Analytics 模块但偏通用报表，没有专门做倦怠检测。Opsgenie（Atlassian）2027 年关闭，incident.io 目前也没有这个功能。短期内巨头做的概率不高 -- 倦怠检测是个"nice to have"功能，不够撑起一个独立产品线。但作为开源项目，即使 Rootly 不维护了，社区也可以接手。

给产品经理

痛点分析

• 解决什么问题：on-call 工程师的倦怠是"温水煮青蛙" -- 不是一次大事故压垮人，而是日复一日的隐性压力积累。70% 的 SRE 表示 on-call 压力直接导致了倦怠和人才流失
• 痛点有多痛：高频 + 刚需。PagerDuty 2024 报告显示企业事故量同比增长 16%，AI 代码助手加速了代码产出也加速了生产事故。疲惫的工程师决策更慢、漏检率更高、最终导致更高的人员流失

用户画像

• 主要用户：Engineering Manager / VP of Engineering -- 需要数据支撑决策，而不是靠感觉判断谁累了
• 次要用户：SRE 工程师本人 -- 通过自报告参与，也能看到自己的趋势
• 使用场景：每周 incident review 时拉出 On-Call Health 仪表盘，看团队整体风险；季度人力规划时用数据论证需要加人或调整轮值

功能拆解

竞品差异

可借鉴的点

1. Apple Health 启发的自报告设计：像 Apple Health 的"State of Mind"一样，让工程师用简短的 check-in 分享真实感受，降低了参与门槛
2. 个人基线 vs 固定阈值：不搞"超过 X 次 page 就算倦怠"的一刀切，而是追踪每个人的变化趋势。这个思路可以用在很多健康/效率类产品上
3. 开源获客策略：Rootly 用免费工具建立信任和品牌认知，再转化到付费产品。对 B2B SaaS 是很好的 PLG 参考

给科技博主

创始人故事

• Sylvain Kalache：Rootly AI Labs 负责人。前 LinkedIn 高级 SRE（共同设计过自愈基础设施的专利），后来跨界联合创立了 Holberton School（一家获得 Jerry Yang、Solomon Hykes、NE-YO 等人支持的编程教育创业公司）。从一线 SRE 转型到做教育再回到 SRE 工具，个人经历本身就很有故事性
• Spencer Cheng：Rivian 软件工程师，作为 Rootly AI Labs Fellow 参与开发
• 背后支持者：Anthropic、Google Cloud、Google DeepMind -- 这个阵容让一个开源 side project 显得分量很重

争议点/讨论角度

• "倦怠能被量化吗？"：OCH Score 只测量工作负荷，不直接测量身心状况。有人会质疑用数字量化人的感受是否合适。但项目明确声明"这不是医疗诊断工具"
• "监控还是关怀？"：管理者看到团队成员的倦怠分数，这是关心员工还是另一种形式的监控？这个边界很微妙
• "AI 加速了事故，又用 AI 检测倦怠"：有用户指出 AI 编程助手增加了代码产出也增加了生产事故数量，然后又用 AI 来检测因此产生的倦怠 -- 有点讽刺

热度数据

• PH 排名：107 票
• Hacker News：Show HN 帖子，获得关注
• 媒体报道：VMBlog 等科技媒体跟进报道
• 搜索趋势：产品刚发布（2026年2月11日），热度在上升期

内容建议

• 适合写的角度："为什么我们开始给 SRE 做心理体检" -- 从行业倦怠现象切入，On-Call Health 作为案例
• 蹭热点机会：当下 AI 安全和 AI 对工程师影响是热门话题，"AI 既是病因又是药方"这个角度很有讨论性

给早期采用者

定价分析

没有付费版，没有隐藏成本。唯一的"成本"是自托管需要的服务器资源和 OAuth 配置时间。

上手指南

• 上手时间：30 分钟（托管版 5 分钟）
• 学习曲线：低
• 步骤：
  1. 打开 oncallhealth.ai，用 mock 数据先感受一下
  2. 如果要接入真实数据：fork GitHub 仓库，配置 .env 文件（OAuth tokens）
  3. docker compose up -d 启动
  4. 连接 PagerDuty/Rootly + GitHub + Slack
  5. 等待数据采集和评分生成

坑和吐槽

1. Beta 阶段：官方明确说"expect some rough edges"，遇到 bug 不意外
2. OAuth 配置：自托管必须配置 Google 或 GitHub OAuth 才能登录，对不熟悉 OAuth 的人可能有门槛
3. 非诊断工具：分数只代表工作负荷趋势，不能当作医疗或心理诊断依据

安全和隐私

• 数据存储：自托管时数据完全在你自己的服务器上
• 隐私考虑：涉及员工工作模式 and 感受数据，需要团队共识才能推行
• 安全审计：开源代码可自行审查

替代方案

给投资人

市场分析

• 赛道规模：事故响应软件市场 $29.21B（2022），DevOps 整体市场预计 2034 年达 $86B
• 增长率：DevOps 市场 500%+ 增长（2024-2034）
• 驱动因素：AI 代码助手导致更多代码上线 -> 更多生产事故 -> 更大 on-call 压力 -> 倦怠检测需求上升

竞争格局

Timing 分析

• 为什么是现在：三个趋势交汇 -- (1) AI 加速代码产出导致事故增多；(2) 后疫情时代对员工心理健康的关注持续升温；(3) SRE 人才稀缺，留人比招人更重要
• 技术成熟度：集成层面成熟（PagerDuty/GitHub/Slack API 都是现成的），倦怠评分的学术框架也成熟（CBI 是 90 年代就有的研究），新的是用 AI 做自动化分析
• 市场准备度：70% SRE 认可 on-call 压力是问题，56% DevOps 团队将防倦怠列为优先事项 -- 需求端已经准备好了

团队背景

• Rootly 创始团队：2020 年成立于旧金山，YC 校友
• AI Labs 负责人：Sylvain Kalache，前 LinkedIn 高级 SRE，Holberton School 联合创始人
• 核心团队：30-50 人，AI Labs Fellow 来自 Rivian、Twilio、Venmo、Okta、Weights & Biases、Cribl

融资情况

• 已融资：$15.3M（种子 + Series A）
• Series A：$12M (2023)，Renegade Partners 领投
• 主要投资人：Y Combinator, Google Gradient Ventures, XYZ Ventures, 8VC, Renegade Partners
• 客户：NVIDIA, LinkedIn, Dropbox, Tripadvisor, Replit 等
• 估值：未公开

结论

On-Call Health 做了一件所有人都知道该做、但没人做的事：用数据量化 on-call 工程师的倦怠风险。 它不是什么革命性的新技术，而是把已有的数据源（PD、GitHub、Slack）+ 成熟的学术框架（CBI）+ AI 趋势分析组合在一起，填补了一个真实存在的空白。免费开源的定位让它几乎没有试用门槛。

资源链接

2026-02-12 | Trend-Tracker v7.3