一台服务器上运行 60 个容器
一个裸金属服务器运行数十到数百个 Hoody 容器。KSM 和 BTRFS 去重使边际成本接近零。
容器·快照
use-cases / mute-flaky-job / hero
CRON · MANAGED ENTRIES · PATCH
把不稳定的任务静音,但别丢掉它
每小时的指标导出已经连续失败三天。今晚轮到你值班。给托管的 cron 条目 PATCH 一下 enabled:false——schedule、command、comment 全都保留。任务处于一个明确的状态:存在但被静音,等着有人来修复。
cron.containers.hoody.com · entries
https://cron.containers.hoody.com/users/me/entries实时
开id调度命令状态
- a1f2*/5 * * * *curl -fsS http://prod/health已启用
- c4b90 3 * * */usr/local/bin/backup.sh已启用
- e7d30 * * * */srv/cron/metrics-export.sh已静音 · 2 天前 · @alex已静音 2d ago · 由 @alex“flaking on monday with prod-db — see #pager-fri”
- 9b21@hourlypsql -c 'VACUUM ANALYZE'已启用
- f0a80 9 * * 1-5/srv/cron/digest.sh已启用
- d3c7*/15 * * * */srv/cron/reindex-search.sh正在 PATCH…
PATCH/users/me/entries/d3c7请求体
{ "enabled": false, "comment": "reindex flaking — see thread" }
切换只是一次 PATCH · 条目从未离开列表
use-cases / mute-flaky-job / mechanism
静音就是一次 PATCH
Hoody Cron 的托管条目是一份 JSON 资源:每行有 id、schedule、command、comment 和一个 enabled 标志。把 enabled 翻成 false 就是一次 PATCH。条目继续留在 crontab 里,下一个人能读到它,再决定怎么办。
终端 · 值班笔记本
PATCH · 静音# mute the flaky entry — entry stays in the crontab curl -X PATCH \ https://cron.containers.hoody.com/users/me/entries/e7d3 \ -H "Content-Type: application/json" \ -d '["enabled": false, "comment": "flaking on monday with prod-db — see #pager"]' # response HTTP/1.1 200 OK { "id":"e7d3", "enabled":false, "schedule":"0 * * * *", "command":"/srv/cron/metrics-export.sh", ... }
终端 · 第二天早上
GET · 验证# the entry is still on the list — just not running curl GET https://cron.containers.hoody.com/users/me/entries HTTP/1.1 200 OK [ { "id":"a1f2", "enabled":true, ... }, { "id":"e7d3", "enabled":false, "comment":"flaking — see #pager" }, { "id":"9b21", "enabled":true, ... } ] # present and muted — the on-call hand-off has somewhere to point
PATCH 不会删除、重写或移动条目——只是翻一个布尔。交接只要一行:'metrics-export 条目 e7d3 已静音,见 hoody-cron,请看一下。'
use-cases / mute-flaky-job / states
三种状态,同一个条目
Hoody crontab 上的一个条目永远恰好处于三种状态之一。每种状态对第二天早上谁知道什么有不同的后果。
ENTRY · e7d3 · /srv/cron/metrics-export.shPATCH 在状态间切换——从不破坏
ENABLED
按计划执行,失败时呼叫值班
条目在 crontab 里,内核 cron 守护进程每小时拾取一次。失败时唤醒值班。这是健康任务的默认状态。
MUTED
存在、暂停、有备注
enabled:false。条目仍在 crontab 里,团队能读到它的 schedule、command 和 comment。cron 守护进程跳过它。明天凌晨 2 点不会被叫醒,也不会有人忘了它的存在。
DELETED
消失了——上下文也跟着消失
一旦 DELETE,schedule、command、comment、原因——全都离开 crontab。下一个值班无处可 grep。静音是那个保留记忆的选择。
静音是大多数调度器没有名字的中间态。Hoody Cron 有,因为 enabled 在托管条目上是一等公民字段。
use-cases / mute-flaky-job / powers
为什么有一个明确的静音状态很重要
今晚修不好任务时,问题是它的缺席在第二天会以什么形态呈现。静音让那个形态可读。
HAND-OFF
值班消息只要一行
不用粘 Slack 串、也不用提交一行被删的 PR——消息就是那个条目 id。明天的值班打开 cron URL,读 comment,就知道从哪开始。
AUDIT
每次静音都是一行,而不是一段记忆
GET /entries 返回 enabled:false 以及 comment。靠过滤就能搭出一个审计面板。谁静音的、为什么、多久前——都在 JSON 里,而不是某人的私聊里。
REVERSIBLE
解除静音就是反过来的 PATCH
底层问题修好后,再来一次 enabled:true 的 PATCH 就把条目放回排程。不用重写 cron 表达式、不冒打错字的风险、不走提交-发布的循环。
use-cases / mute-flaky-job / capacity
Cron API 给你的能力
数字来自 Hoody Cron 的托管条目接口本身,不是编出来的基准。
- 一种方法PATCH
PATCH /users/[user]/entries/[id] 接受部分 body。单独发送 ["enabled":false]——schedule、command、comment 完全不动。
- 保留的字段5+1
五字段 schedule、command、comment、expires_at 和 id 在静音过程中全部保留。内核 crontab 仍然反映这个条目——只不过被 cron 服务注释掉了。
- 重写次数0
无文件编辑、无 PR、无发布。整个静音往返就是从任意终端发出的一次 HTTP 调用——包括手机上的那个。
依据 Hoody Cron 托管条目 API:每个条目除了 schedule、command、comment 和可选的 expires_at 之外,还带一个 enabled 布尔。PATCH 接受部分 body。
use-cases / mute-flaky-job / punchline
Disabled 不是 deleted——条目在等着有人来修。
今夜 · 值班 · 23:14明天 · 团队 · 09:00
旧的工作流长这样vim crontab → 注释一行 → 提交 → PR → 合并 → 发布六步 · 丢失 comment 上下文 · 累的夜里容易打错字
现在它长这样curl -X PATCH .../entries/e7d3 -d '["enabled":false]'一次 PATCH · 条目留在列表里 · 备注随条目同行
use-cases / mute-flaky-job / replaces
它替代了什么
团队通常用来「临时停掉」一行不稳定 cron 的几种方式。每一种要么具有破坏性、要么会丢信息、要么离生产还隔着两个 PR。
- 手动注释 crontab 行丢掉了结构化的 enabled 标志 · 容易忘
- 删除条目并「记住」schedule、command、原因都跟着没了
- 代码里手动写 // FIXME 注释活在仓库里,不在真正运行的排程里
- 把 Slack 串当值班记忆可搜索一周 · 然后就没人管了
- 为「静音但未删除」的任务建 GitHub issue为还在 crontab 上的东西开 issue——重复状态
- Terraform 管理的 cron 配置plan、apply、deploy——只为了一个布尔字段
use-cases / mute-flaky-job / cta
别再凌晨 2 点删除不稳定的任务。把它静音、留个备注,让明天的值班读 JSON。
use-cases / mute-flaky-job / related
阅读其他内容
