把日常熟悉的事物重新组合，往往能产生意想不到的效果。GitHub 贡献图是全球数千万开发者每天都会看到的东西 —— 绿色方块按日历排列，-commit 越多颜色越深。但如果你把这些绿色方块换成红色，用它们来表示「服务挂了多少次」「这次故障有多严重」，会得到什么？答案是 Red Squares—— 一种把服务中断元数据当作贡献来追踪的可观测性工程实践。
从「绿色方块」到「红色方块」
GitHub 贡献图的本质是一个日历热力图：横轴是周，纵轴是星期几，每个单元格的颜色深浅映射当日活动量。这个可视化范式之所以有效，是因为它把抽象的时间数据转换成了直观的视觉模式 —— 开发者一眼就能看出过去一年哪个星期最忙，哪几天在摸鱼。把这个思路迁移到服务监控上，逻辑是完全一致的：服务是否稳定，本质上也是一个时间序列问题。
Red Squares 的核心洞察在于：服务中断也是一种「可量化的活动」，它值得被赋予与代码提交同等的视觉权重。传统监控大盘通常用折线图、仪表盘来展示可用性，这些当然精确，但对于需要快速建立「体感」的场景 —— 比如向管理层汇报全年稳定性趋势、或者在团队内部做回顾 —— 贡献图风格的红色方块更能激发直觉式的理解。红色天然带有警示含义，与绿色的「正向贡献」形成对照，语义上完全自洽。
断点续传与元数据结构
实现这样一个可视化系统，数据层的设计是第一个关键点。原始 incident 数据通常来自 status page API 或者内部监控系统，以 JSON 形式返回，包含 incident ID、开始时间、结束时间、严重等级、影响组件等字段。要把这些转换为贡献图格式，需要经历几个处理步骤。
第一步是时间对齐：将每个 incident 的时间戳映射到对应的「贡献日」。这里需要决定粒度 —— 是按自然日计算，还是按事件发生的时间点单独标记？实践中通常取前者，因为贡献图的最小单位就是一天，如果一天内多次故障，可以在该单元格内叠加显示（比如用更深的红色或者在旁边标注数字）。第二步是严重等级映射：incident 通常有 P1 到 P5 或者「Major」「Minor」之类的分级，需要将这些等级转换为颜色深浅。最简单的做法是 Major 对应深红，Minor 对应浅红，无 incident 的日期显示为灰色或留空。第三步是聚合计算：统计每个月的 incident 数量、计算平均严重等级、找出最长连续无故障天数（calm streak），这些衍生指标可以补充显示在图表旁边。
工程落地的参数与阈值
如果你想在内部系统中实现类似方案，以下参数值得参考。日粒度是贡献图的默认精度，对于周级别以上的趋势分析已经足够；如果需要更细的粒度（比如小时级），则需要改用热力图的其他变体。颜色映射建议使用五级色阶：灰色表示零 incident，浅红表示 1 次 Minor，中红表示 1 次 Major 或 2 次 Minor，深红表示 2 次以上 Major 或 3 次以上 Minor，黑色或暗红表示服务完全不可用。这种分级方式与 GitHub 贡献图的五级绿色相对应，保持了视觉语言的一致性。
时间窗口通常取过去 365 天，与 GitHub 贡献图的默认显示范围一致。超过一年的数据可以归档到年度报告中，但不适合在主视图中展示，因为单元格的物理尺寸会变得过小。数据源方面，GitHub 官方 status API（api.github.com/status）提供实时的 incident feed，是最权威的来源；如果要追踪其他服务，StatusPage.io、Instatus 等平台也提供标准化的 API。
可观测性的范式转移
Red Squares 背后更深刻的理念是把「负向事件」提升为可观测性体系的一等公民。传统监控往往把故障当作需要消除的异常，是 SLO 计算公式里的分子；但如果换个视角，把每次 incident 也看作一种「输出」，与正常的服务请求并列放在同一个时间轴上，就能得到更完整的服务健康画像。这种思维方式在 SRE 领域正在获得更多关注 ——Google SRE 书籍中提到的「错误预算」概念，本质上也是把故障时间当作一种资源来管理，而非单纯的负面指标。
更进一步，贡献图风格的可视化降低了跨团队沟通的成本。产品经理、运营团队、甚至客户成功部门，可能看不懂 Prometheus 的 PromQL 查询或者 Datadog 的仪表盘，但他们一定能看懂「过去一年有多少个红色方块」。这种可视化的「universal readability」，是它相比传统监控大盘的核心优势。
资料来源
本文核心案例来自 GitHub Downfall（githubdownfall.com），该站点自 2025 年 1 月起追踪 GitHub 官方服务中断，以贡献图风格可视化呈现。