00:00:00
周刊说明：为什么每周看一遍 GitHub 热榜 原创
这个周刊每周一期，只做一件事：把过去一周 GitHub 上热度最高、和 SRE 相关的开源项目挑出来，讲清楚它是干什么的、值不值得你花时间。不做排行榜搬运，只做筛选和判断。
一、为什么要单独做一个周刊
技术选型最贵的一步不是"选哪个"，而是"知道有哪些"。
监控告警这一块，每隔半年就会有新东西冒出来：去年大家在聊 OpenTelemetry 采集层的收敛，今年聊的是 AI Agent 怎么接进排障链路。这些东西不会出现在官方文档里，也不会有人专门推送给你——它们先出现在 GitHub 的 star 曲线和 release 列表里，半年后才变成招聘 JD 上的一行字。
所以需要一个固定的节奏去扫一遍：每周十分钟，知道这周有什么新东西，不用自己去看。
这个周刊不是"Awesome 列表"，也不是单纯的 star 排榜：
- 只挑 SRE 相关：监控、告警、可观测性、K8s、发布、IaC、混沌工程、值班响应，其他领域再火也不收
- 看增量而不是总量：star 总数高的永远是那几个老面孔，光看总量等于每周看同一份榜单
- 给出判断：每个项目都写清楚"它解决什么问题"和"你该不该上手"，不做中立背书
二、怎么筛
每周的入选池来自四类信号，按优先级排：
| 信号 | 说明 | 权重 |
|---|---|---|
| 本周有实质更新 | 一周内有 push，且是有意义的提交/发布 | 必要项 |
| 近期发布版本 | 一周内或临近窗口有新 release、新大版本 | 🟢 高 |
| 领域内 star 存量 | 存量代表生态认可度，用来排主次 | 🔵 中 |
| 本周新晋黑马 | 近一个月内创建、一周内爆发式增长 | 🟠 关注位 |
具体到每一期，榜单结构固定成四块：
- 本周焦点：选一个项目展开讲，通常是这周动静最大、或者最能代表趋势的那个
- 上榜项目：按领域分组，每项给出 star 量级、语言、一句话定位和观察点
- 新晋项目：新面孔单独列，star 数字不一定高，但可能代表方向
- 下周观察：留一两条跟踪线索，让读者知道下一期会看什么
榜单里的 star 数是抓取当天的快照，不是实时数据。发布版面的数字会肉眼看得出"有点旧"，这是刻意的——周刊本来就该是一张照片，不是一块仪表盘。
三、数据从哪来
所有条目都来自 GitHub 公开 API 的实际抓取，没有人工编造的数字：
- 仓库元数据（star、fork、语言、license、创建时间、最近 push）走
GET /repos/{owner}/{repo} - 本周新晋项目走 Search API，按
created+pushed双条件筛 - 版本号走
GET /repos/{owner}/{repo}/releases
抓取脚本放在仓库的 shell/sre-weekly/fetch-gh-hot.mjs，可以自己跑一遍复现当期的入选池：
bash
# 抓最近一周（默认口径），输出 JSON
node shell/sre-weekly/fetch-gh-hot.mjs
# 指定周区间
node shell/sre-weekly/fetch-gh-hot.mjs 2026-11-01 2026-10-26GitHub 匿名调用有 10 次/分钟的检索配额，脚本按固定配额发请求、遇限流自动退避重试。有 token 的话传 GITHUB_TOKEN 环境变量，配额会宽松些。
四、一条阅读建议
不要每周照单全收。看到感兴趣的，先问三个问题：
- 它替代了我现在链路里的哪一环：是替换，还是补位？替换的成本很高，补位才值得试
- 它背后的维护者是谁：CNCF 毕业/孵化项目、有商业公司背书、或者个人长期维护，风险差别很大
- 我什么时候会用到它：如果三个月内都不会用到，收藏起来就够了，不用真去部署
周刊给的是"信息"，不是"决策"。真正决定上不上生产，还是得自己压测、看 issue 区、翻最近三个月的 commit 质量。
每周一期 · 只收录 SRE 相关的开源项目 · star 数为抓取当日快照