SRE · XB 现场笔记

Alertmanager 通过标签匹配树选择告警接收器

Wed, 08 Dec 2027 00:00:00 +0000

Alertmanager 根据告警标签遍历路由树，选择通知接收器。路由树表达责任归属与升级策略，接收器则定义实际通知集成。配置能够解析，并不代表每一类告警都被分配给正确目的地。因此，不能把重载成功当作路由有效的完成证据；应该先核对进入系统的标签契约，再验证整棵树针对典型告警的选择结果。

既要看匹配，也要看何时停止

每条告警都会进入必须匹配所有告警的根路由。子路由继承没有主动覆盖的配置；没有子节点匹配时，由当前节点处理。否则，遍历通常在第一个匹配的子节点后停止。匹配节点配置 continue: true，才允许继续检查后续同级节点。这不表示配置中的所有接收器都会获得同一条告警，未匹配的节点仍然不会参与。

一个路由节点只能指定一个接收器。接收器内部可以包含多个通知集成，多条匹配路由也可以选择不同接收器，两者是向多个目的地通知的不同方式。不能把路由的 receiver 字段直接换成列表，就期待具有相同行为。选择方案时应核对是否会重复通知，以及不同目的地是否需要独立的分组方式、升级策略和发送节奏。

责任归属依赖稳定的标签契约

匹配 team="payments" 的路由，需要进入 Alertmanager 的告警真正带有这个标签值。名为 team 的注解不能满足该条件。Prometheus 表达式中的聚合可能提前移除一个维度，所以应该检查最终告警标签，包括告警重新标记的影响，不能假定原始指标上的标签会原样保留到通知阶段。原始指标存在团队字段，不足以证明路由可以看到它。

根接收器应当对没有匹配具体子节点的告警仍然有用。这类告警也需要可观察的去向，以及能够修正分类的负责人。测试时除了已知团队，还应覆盖标签缺失：缺少团队的警告可能留在根节点，但缺少同一标签的严重告警仍可能命中独立的严重程度路由。是否缺失与是否完全没有匹配路径，是不同问题。

路由排列顺序本身就是行为。较宽泛的前置路由，可能让后面的具体路由根本没有机会被检查，除非启用了继续匹配。因此，即使匹配器文字没有变化，移动一段配置也可能改变收件方。顺序调整应按策略变化审阅，并把代表性标签输入与配置放在一起，以便持续核对预期选择。

按时间静默不会让匹配节点从遍历中消失。一个被静默的子节点在关闭继续匹配时，仍可能阻止后面的同级节点。因此，办公时间路由在不活跃时，不会自动变成值班路由的回退条件。升级策略需要同时审阅时间条件和树的停止规则，不能只看两个时段是否互补，就认为收件方一定连续覆盖。

坏掉的样子

拼写错误或标签改名可能使告警落到根接收器，新添加的宽泛子路由可能截走后面团队的告警，而不必要的继续匹配则可能让一个事件产生多份通知。诊断这些问题，需要实际标签和完整匹配路径，单独阅读某个节点通常不够。还应核对新增规则与既有顺序共同作用后的结果，而不只是新增部分自身是否正确。

接收器选择正确仍不等于送达。分组等待、静默、抑制、模板错误、传输故障和目的地行为，都可能在之后介入。先验证路由，再沿所选接收器追踪通知链路。增加规则等待时间不会修复团队匹配条件，缩短分组等待也不能修复接收器凭据缺失。每个阶段都需要对应证据，不能用前一阶段通过代替后一阶段结果。

快速验证

把程序保存为 routing.py，执行 python3 routing.py。需要 Docker 与公开的 Alertmanager 0.28.1 镜像，镜像缺失时可能先下载。真实 amtool 检查配置并验证七组标签输入。实验接收器只有名称，没有实际发送集成，因此可以检查路由选择而不会联系任何人员或外部服务，也不会影响现有告警系统。

import subprocess
import uuid

# Requires Docker and Alertmanager 0.28.1. No receiver has a delivery integration.
script = r"""set -eu
cat > /tmp/routes.yml <<'ROUTES'
route:
 receiver: default
 group_by: [alertname, service]
 routes:
 - receiver: payments
 matchers: ['team="payments"']
 continue: true
 - receiver: pager
 matchers: ['severity="critical"']
receivers:
 - name: default
 - name: payments
 - name: pager

ROUTES
/bin/amtool check-config /tmp/routes.yml
/bin/amtool config routes test --config.file=/tmp/routes.yml --verify.receivers=payments,pager team=payments severity=critical
/bin/amtool config routes test --config.file=/tmp/routes.yml --verify.receivers=payments team=payments severity=warning
/bin/amtool config routes test --config.file=/tmp/routes.yml --verify.receivers=pager team=data severity=critical
/bin/amtool config routes test --config.file=/tmp/routes.yml --verify.receivers=default team=data severity=warning
/bin/amtool config routes test --config.file=/tmp/routes.yml --verify.receivers=default severity=warning
/bin/amtool config routes test --config.file=/tmp/routes.yml --verify.receivers=default team=payments-preview severity=warning
sed 's/continue: true/continue: false/' /tmp/routes.yml > /tmp/stop.yml
/bin/amtool config routes test --config.file=/tmp/stop.yml --verify.receivers=payments team=payments severity=critical
"""
name = "xbcatm-route-test-" + uuid.uuid4().hex[:12]
try:
 result = subprocess.run(
 ["docker", "run", "--rm", "--name", name, "--network", "none", "-i",
 "--entrypoint", "/bin/sh", "prom/alertmanager:v0.28.1", "-s"],
 input=script, text=True, capture_output=True, timeout=30,
 )
finally:
 subprocess.run(["docker", "rm", "-f", name],
 stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
print(result.stdout, end="")
if result.returncode:
 raise RuntimeError(result.stderr or result.stdout)
print("Verified seven route cases, including continuation and unmatched labels.")

第一组结果为 payments,pager：支付团队路由先匹配并继续，严重程度路由随后也匹配。支付团队警告只选择支付接收器，数据团队严重告警选择呼叫接收器；没有匹配或缺少团队值的相应输入进入根接收器。payments-preview 不会匹配精确的支付团队值，避免把名称相近误认为条件成立。

最后一项把继续匹配改为关闭，确认支付团队严重告警现在只选择支付接收器。每组结果都由 --verify.receivers 强制核对，出现差异会直接使执行失败。容器没有外部网络，不挂载宿主机目录，退出时自动移除。真实接收器的通知送达仍需要另行安排受控验证，这份结果只证明路由选择。

本轮没有修改此运行实验，也没有重新执行。文中的预期输出和此前记录的观察，与本轮执行证据分别保留，不能据此声称真实集成已经再次通过。

来源

Alertmanager: configuration，路由继承、同级继续匹配与接收器定义，已核验 2026-10-15。
Alertmanager 0.28.1: README，配置与路由检查工具，已核验 2026-10-15。
Prometheus: Alertmanager，路由、分组与通知抑制的职责，已核验 2026-10-15。

水平自动伸缩按需扩缩容

Thu, 04 Nov 2027 00:00:00 +0000

HorizontalPodAutoscaler 根据配置的指标目标调整可伸缩工作负载。它的输出是期望副本数，不是“额外 Pod 已经接收流量”的保证。调度、镜像启动、初始化、就绪状态以及节点容量，都会决定这个建议多久才能转变成真正有用的服务能力。设计控制循环时，必须把这些延迟一起考虑，不能只根据一条公式估计恢复时间。

指标产生的是副本建议

对于简单的逐 Pod 平均值，期望副本等于当前副本数乘以当前指标除以目标指标，再向上取整。比值为二时，在额外控制介入之前会建议翻倍。比值低于一可能建议缩容，但容差、缺失测量、就绪处理、上下限和扩缩行为，都可能阻止或限制最终动作。公式描述起点，不是所有条件下都直接生效的完整算法。

CPU 利用率以资源 requests 为分母。改变请求值，即使用掉的 CPU 没变，也可能改变利用率，所以纵向与横向伸缩需要协调。指标接口必须可用，目标还要支持 scale 子资源。HPA 修改 Deployment 的副本数量，再由 Deployment 控制器管理 ReplicaSet 与 Pod；这几层职责不同，不应把它们统称为一个瞬间完成的操作。

默认协调周期为十五秒，但它不是端到端响应时间的承诺。指标自身还有采集窗口和传输延迟。需要区分跨 Pod 的平均用量、测量管线里的时间平均，以及控制器对建议值的稳定处理。一条过旧但格式有效的数字，仍可能误导运行正常的控制器，造成尖峰过去以后才扩容的现象。

稳定的是建议历史，不是上次调整时间

缩容稳定机制保留近期副本建议，并在配置窗口中选择最高值。默认缩容窗口为五分钟，autoscaling/v2 的 behavior 可以进一步调整。它不是从上一次真正改变副本数开始计时的简单冷却期。即使某次较高建议没有改变现有数量，只要仍在窗口里，也可能推迟下一次缩容，这正是下面模型专门展示的差异。

速率策略另外限制一段时间内可以改变多少 Pod 或百分比。因此扩容也可能被限制，不能说它永远立即、无限进行。最小副本应考虑启动延迟所需余量，最大副本应符合节点容量和成本。稳定机制能降低反复变化，却不能修复选错瓶颈或目标值的问题；把窗口加长只是改变响应方式，不会让错误信号变正确。

选择增加副本能够缓解的压力

CPU 对计算密集型请求可能有效，队列深度或每副本工作量可能更适合后台工作者。但延迟或任意资源图表，并不会天然成为合适的控制输入。如果所有副本都在等待同一台已经饱和的数据库，继续增加副本可能扩大争用，反而延长等待时间。需要先确认瓶颈能否随着应用副本增加而解除。

具体检查新增一个副本后会发生什么：工作能否分配给它，每副本压力是否下降，下游是否还有足够容量。长连接、分区不均与缓存预热都会推迟效果。控制器仅仅改变数量，不会替应用重新分片或自动迁移已有连接。观察这些行为，可以判断问题应该通过扩容解决，还是需要改变工作分配或下游容量。

坏掉的样子

缺失指标表示未知需求，不表示需求为零。多指标配置中，即使一路失败，另一条有效扩容建议仍可能使用；但失败来源会阻止其余指标建议的缩容。个别 Pod 缺失样本也有保守处理。应通过条件和事件区分这些情况，而不是假定每次缺少一个样本就停止所有动作，也不要据此手工删除仍在服务的容量。

maxReplicas 过低时，计算出的建议被限制，ScalingLimited 可以显示这一情况，但队列仍在增长。过高的下限也会掩盖真实低需求。部署自动化反复写固定 replicas 会与 HPA 竞争。还应检查 CPU 请求变化和启动就绪状态，再归咎于普通滚动更新：HPA 支持 Deployment 发布，并不是把每个初始化 Pod 都当成可以随意缩掉容量的零负载样本。

快速验证

保存为 hpa_loop.py，执行 python3 hpa_loop.py。它用标准库建模比例计算、上下限，以及取近期最高建议的缩容窗口。模型明确省略容差、速率策略、逐 Pod 样本和真实 Kubernetes 协调，不应被当作生产控制器的完整复制品。运行只涉及本地算术与列表状态，不访问集群。

import math

TARGET = 50.0
MIN_REPLICAS = 2
MAX_REPLICAS = 10
WINDOW_S = 300


def desired(replicas, value):
 raw = math.ceil(replicas * value / TARGET)
 return max(MIN_REPLICAS, min(MAX_REPLICAS, raw))


def step(replicas, history, now, value):
 if value is None:
 print(f"t={now}s metric=missing hold={replicas}")
 return replicas
 recommendation = desired(replicas, value)
 history[:] = [(t, count) for t, count in history if now - t <= WINDOW_S]
 history.append((now, recommendation))
 if recommendation < replicas:
 result = min(replicas, max(count for _, count in history))
 else:
 result = recommendation
 print(f"t={now}s raw={recommendation} {replicas}->{result}")
 return result


def main():
 history = []
 replicas = step(3, history, 0, 100)
 assert replicas == 6
 replicas = step(replicas, history, 240, 50)
 assert replicas == 6
 replicas = step(replicas, history, 400, 15)
 assert replicas == 6 # A recent recommendation, not a recent scale event.
 replicas = step(replicas, history, 541, 15)
 assert replicas == 2
 replicas = step(replicas, history, 600, None)
 assert replicas == 2
 assert desired(2, 500) == 10
 assert desired(2, 5) == 2
 print("PASS: recommendation history holds 6 at t=400, then shrinks to 2")


if __name__ == "__main__":
 main()

零秒时模型从三个副本扩到六个。二百四十秒时再次建议六个，数量并未变化。四百秒时新的原始建议为两个，但近期的六副本建议仍在窗口内，所以继续保持六个；此时距离上次实际扩容已超过五分钟。五百四十一秒时，那个较高建议离开窗口，模型才缩到两个。这说明约束来自建议历史，而不是上次调整的时间戳。

两种语言中的代码均在本轮通过 Python 3.12.14，包含输入缺失保持和两个边界断言。这些结果只证明模型声明的行为。调试真实集群时，还应按时间对照 HPA 条件、副本建议、实际数量、Pod 就绪和应用延迟。本轮没有运行真实控制器或指标管线，本地成功不能代替真实系统验证。

来源

Kubernetes 水平自动伸缩文档，HPA 如何推演副本数，已核验 2026-10-15。
HorizontalPodAutoscaler 演练，多指标与状态条件的完整示例，已核验 2026-10-15。

错误预算是真预算

Thu, 25 Mar 2027 00:00:00 +0000

错误预算把可靠性约定变成能够参与排期的依据。产品与运维先确定目标，再度量失败是否超出允许范围，并提前约定预算耗尽后如何调整工作。这个数字支持共同决策，却不能预测明天的部署会不会引发事故。发布会引入风险，真正消耗已度量预算的是观察到的不良事件；不能把每次发布机械地扣成固定额度，也不能把余额充足当成变更必然安全的证明。

先定义这本账如何计算

对于基于请求的目标，允许失败数等于符合统计条件的请求总数乘以一减目标值。例如，三百万次请求的目标为百分之九十九点九，便允许三千次不良请求。接入发布规则之前，需要写清请求范围、成功条件、测量位置和观察窗口。按流量加权的失败额度，不会自动变成一个固定的宕机分钟数；高峰和低谷的同样一分钟可能影响完全不同数量的请求。

滚动三十天的统计会持续移除旧记录并加入新记录。流量变化时，分母与允许失败数都可能变化，即使目标百分比没有改动。自然月统计则在约定的日历边界重新开始，两种窗口回答的问题不同。事故处理中临时换窗口，可能让看似精确的余额失去可追溯含义。因此应将计算定义与策略一起版本化，并在余额旁显示实际窗口、请求范围和统计截止时间。

在争论之前约定如何响应

一种示例策略是：预算超支时暂停非必要功能发布，把资源转向可靠性工作，同时允许紧急安全修复和事故修复经过审核后执行。需要明确决策负责人、例外所需材料、记录方式以及恢复普通发布审查的条件。谷歌公开的预算策略针对书中的示例服务，不能不加判断地把所有阈值和升级处理规则照搬到另一项业务。

预算余额也不能独立决定是否具备发布条件。事故仍未结束、监控覆盖不足、回归失败或缺少可靠回退方案，都可能继续阻止变更。反过来，修复当前事故的必要变更，不应只因为该事故已经花光预算而被机械阻挡。把判断及依据写下来，才能让规则服务于用户影响和工程取舍，而不是让仪表盘变红的团队承担未经分析的责任。

坏掉的样子

一个大事故离开滚动窗口后，预算可能突然恢复。计算本身没有错，但这不能说明根因已经消除。悄悄更改排除条件，把无法采集的样本填成成功，或者直接平均不同流量服务的成功百分比，同样会制造虚假的盈余。看到余额改善时，应先检查测量覆盖与定义是否变化，再判断服务状态是否确实改善，尤其不能把未知数据解释为零失败。

短窗口燃烧率提供另一种观察角度：把实际不良事件比例除以目标允许的不良比例，可以看出近期消耗速度是否异常。高燃烧率能够在长窗口预算耗尽前发出警告，但由它推算剩余时间，需要假设流量与错误行为继续保持可比，不能当成确定的倒计时。应结合长窗口余额、短窗口变化和低流量条件设置可执行的告警，而不是每出现一次失败就叫醒值班人员。

快速验证

把下面代码保存为 budget-policy.py，使用 Python 3 执行。数据是人为构造的每日请求统计，用来核对滚动窗口及一个刻意保持简单的策略。程序不会连接发布系统，也没有对任何真实变更的事故概率作出估计；运行输出只证明给定输入下的计算和判断分支。

from fractions import Fraction

target = Fraction(999, 1000)
# Every synthetic daily bin has 100,000 eligible requests.
days = [(100000, 1300)] + [(100000, 70)] * 29

def account(window):
 eligible = sum(total for total, _ in window)
 bad = sum(errors for _, errors in window)
 allowed = eligible * (1 - target)
 return bad, allowed, allowed - bad

def feature_policy(remaining, incident_open):
 return "hold" if remaining < 0 or incident_open else "eligible for review"

before = account(days)
after = account(days[1:] + [(100000, 50)])
assert before == (3330, 3000, -330)
assert after == (2080, 3000, 920)
assert feature_policy(before[2], False) == "hold"
assert feature_policy(after[2], True) == "hold"
assert feature_policy(after[2], False) == "eligible for review"
for label, (bad, allowed, remaining) in [("before", before), ("after", after)]:
 print(f"{label}: bad={bad}, allowed={float(allowed):.0f}, remaining={float(remaining):.0f}, spent={float(bad / allowed):.2%}")
print("after rotation, incident still open:", feature_policy(after[2], True))
print("after rotation, incident closed:", feature_policy(after[2], False))

第一个窗口包含三千三百三十次不良请求，允许三千次，预算使用率为百分之一百一十一，余额为负三百三十。移除最旧一天、加入新一天后，不良请求降为二千零八十次，使用率约百分之六十九点三三，剩余九百二十次。示例特意让两个窗口都包含三百万次符合条件的请求，以便单独观察旧事故离开窗口的影响；真实系统的分母不一定保持不变。

即使新余额已经为正，只要事故仍处于打开状态，策略仍输出 hold。最后一个场景才变成 eligible for review，表示可以进入发布审查，并没有直接批准部署。这样可以把可验证的算术与使用它的运维判断分开：在采取行动前，同时检查统计定义、覆盖程度、事故证据和变更验证，避免只凭一个转绿的数字宣布恢复正常。

来源

Google SRE Workbook: Example Error Budget Policy，发布限制、例外与责任约定，已核验 2026-09-13。
Google SRE: Service Level Objectives，度量边界与可靠性目标，已核验 2026-09-13。
Google SRE Workbook: Alerting on SLOs，燃烧率与告警窗口，已核验 2026-09-13。

错误预算为允许的失败命名

Thu, 17 Sep 2026 00:00:00 +0000

“可靠性达到百分之九十九点九”还不是一项完整的工程约定。它针对哪些用户、在哪个位置测量、观察多长时间，又把怎样的结果视为成功？只有回答这些问题，错误预算才能把允许的失败变成可计算的数量。因此，首先要定义统计总体和成功规则，而不是先挑选仪表盘上的绿色阈值。两个页面展示相同的百分比，如果分母和判定不同，也不能直接比较。

统计真正承诺的用户体验

服务水平指标描述实际测得的量，服务水平目标则为它规定阈值与时间窗口。对于基于事件的指标，成功比例等于符合条件的成功事件数除以全部符合条件的事件数。成功可以要求一次业务操作正确完成，并且没有超过延迟上限。仅有正常的响应状态码，不能证明订单已经正确写入；服务器内部计时也可能没有包含用户实际经历的网络等待。

分母必须明确，例如某个接口收到的有效客户请求尝试，而文档约定的合成探针可以另行统计。还要事先决定重试、客户端取消、认证失败、超时以及异步完成如何表示。排除条件应来自服务承诺的边界，不能在事故后临时创造，用来美化结果。应保留足够的记录，分辨一条事件是按规则排除，还是因为采集失败而没有进入统计；这两者的含义完全不同。

一条失败可以同时触发多个条件

假设成功请求既要返回预期响应，也要在三百毫秒内完成。一个缓慢的服务器错误同时违反两个条件，但仍然只是一条不良请求。应计算失败条件的并集，或者直接对成功判定取反。如果把“超时延迟计数”和“错误状态计数”相加，而两者不是互斥类别，就会重复计入交叉部分，导致预算消耗被夸大。

对于目标值与符合条件的请求总数，允许失败数就是请求数乘以一减目标值，剩余预算再减去实际失败数。请求型预算统计的是事件，时间型预算统计的是服务处于指定状态的时长。三十天内百分之九十九点九的时间型目标，对应四十三点二分钟的不良时间；不能把这个换算直接套到任意流量下的请求统计。部分用户失败、高低峰切换和不同请求权重，都会破坏两种口径之间的简单对应关系。

滚动窗口还会随着旧事件离开而变化，即使没有新增失败。应在同一个窗口内重新计算额度与失败数，不能把终身累计扣款直接当成滚动余额。发布政策还必须说明负余额会触发哪些实际行动；计算本身既不授权继续制造失败，也不会自动阻止部署，这些决策需要事先约定。

坏掉的样子

只统计应用服务器日志，可能看不到到达应用之前就被拒绝的请求。只记录已经完成的请求，也可能遗漏仍然卡在队列中的请求。这样得到的成功率可以很好看，用户却已经无法使用服务。需要选择合适的观测位置，纳入超时结果，并展示覆盖程度或独立检查；不能把遥测缺失解释成服务成功，更不能靠丢掉失败样本让分母看起来干净。

如果窗口里没有符合条件的事件，成功比例没有可解释的分母，应标记为没有观察值，并另行处理监控缺失。请求量很小时，高目标也会对单次失败特别敏感，因为预算是一个数学额度，不一定恰好等于整数次事件。不要为了得到一个“至少允许失败一次”的结果而向上取整。跨实例比较时也必须保留同样的范围和请求权重，直接平均各实例的百分比会改变指标含义。

快速验证

把代码保存为 slo-population.py，用 Python 3 执行。这个模拟接口的规则是：只有状态二百且耗时不超过零点三秒才算成功。样本包含已完成的客户事件，以及明确标记为探针的独立事件，用来验证分类计算。它没有证明真实采集器的完整性，也没有把正常状态码等同于真实业务结果已经正确完成。

from fractions import Fraction

# Synthetic events: (kind, status, duration_seconds).
events = ([('user', 200, 0.10)] * 9970
 + [('user', 200, 0.50)] * 10
 + [('user', 503, 0.02)] * 10
 + [('user', 503, 0.50)] * 10
 + [('probe', 503, 0.50)] * 100)
eligible = [(status, duration) for kind, status, duration in events if kind == 'user']
bad_status = sum(status != 200 for status, _ in eligible)
too_slow = sum(duration > 0.30 for _, duration in eligible)
bad = sum(status != 200 or duration > 0.30 for status, duration in eligible)
good = len(eligible) - bad
target = Fraction(999, 1000)
allowed = len(eligible) * (1 - target)
remaining = allowed - bad

assert len(eligible) == 10000 and bad_status == too_slow == 20
assert bad == 30 and bad_status + too_slow == 40
assert allowed == 10 and remaining == -20
assert Fraction(good, len(eligible)) == Fraction(997, 1000)
# The inclusive threshold is part of the synthetic contract.
assert not (200 != 200 or 0.30 > 0.30)
assert 200 != 200 or 0.300001 > 0.30
# Aggregation must weight each eligible event, not each instance equally.
assert Fraction(999 + 0, 999 + 1) == target
assert (Fraction(999, 999) + Fraction(0, 1)) / 2 != target
assert 1 * (1 - target) == Fraction(1, 1000)
print(f"eligible={len(eligible)}; good={good}; bad_union={bad}")
print(f"status_failures={bad_status}; slow={too_slow}; wrong_sum={bad_status + too_slow}")
print(f"SLI={good / len(eligible):.3%}; allowed={float(allowed):.0f}; remaining={float(remaining):.0f}")

样本里有一万次符合条件的客户事件，另有一百次探针被排除。客户事件中，状态不符合预期的有二十次，延迟超限的也有二十次，其中十次同时属于两类。因此失败并集实际只有三十次，成功事件为九千九百七十次；直接相加会错误地得到四十次失败。

输出的成功指标为百分之九十九点七，低于目标。按请求数计算的允许失败数为十次，剩余预算为负二十次，这些单位都是事件次数，而不是停机秒数。分别查看状态错误与延迟超限仍然有助于诊断，但判断目标是否达成时必须使用同一个已声明的成功规则。把计算接入告警和发布策略之前，应逐项核对生产计数器的范围、阈值是否包含边界、时间窗口及缺失数据处理方式。

来源

Google SRE: Service Level Objectives，指标总体、测量方式与目标，已核验 2026-09-13。
Google SRE: Monitoring Distributed Systems，显式错误与业务层面的失败，已核验 2026-09-13。
Google SRE Workbook: Alerting on SLOs，事件型目标与预算消耗，已核验 2026-09-13。

SRE · XB 现场笔记

Alertmanager 通过标签匹配树选择告警接收器

既要看匹配，也要看何时停止

责任归属依赖稳定的标签契约

坏掉的样子

快速验证

来源

水平自动伸缩按需扩缩容

指标产生的是副本建议

稳定的是建议历史，不是上次调整时间

选择增加副本能够缓解的压力

坏掉的样子

快速验证

延伸阅读

来源

错误预算是真预算

先定义这本账如何计算

在争论之前约定如何响应

坏掉的样子

快速验证

延伸阅读

来源

错误预算为允许的失败命名

统计真正承诺的用户体验

一条失败可以同时触发多个条件

坏掉的样子

快速验证

延伸阅读

来源