可靠性 · XB 现场笔记

背压只有改变生产者行为，才真正控制了有界接入

Thu, 12 Aug 2027 00:00:00 +0000

背压把消费者的有限容量与生产者行为联系起来。通道已满时，生产者可能等待、拒绝新任务，或执行经过明确选择的丢弃策略。关键是容量限制真正改变上游怎么做。队列不断增长，或仪表盘显示积压，只能说明供需失衡，本身不自动形成控制接入的机制。需要从观察到过载，继续追到生产者是否确实减速或停止提交。

坏掉的样子

无界队列可以吸收短暂突发，却也会隐藏持续过载。如果到达速度长期超过完成速度，未完成任务和等待时间就持续增长。把积压挪到待处理线程、重试任务或另一个无界缓冲，并没有消除压力。容量边界必须覆盖任务真正被保存的位置，不能只限制一个容易观察的队列对象，却允许周围继续无限保留工作。

有界队列本身也没有定义完整过载策略。无限阻塞可能耗尽生产者线程或让关闭流程卡住；立即拒绝时，调用方若误认为成功，就可能丢失工作；每次拒绝后立即重试，又可能加重负载。应依据应用契约明确选择：在截止时间内等待、拒绝并稍后重试，还是有意丢弃。不同选择改变交付语义，不能在实现中含糊处理。

队列容量与处理完成是两件事。消费者取出项目可以释放槽位，但此时可能仍在处理这个项目。等待容量为二，也可能同时还有额外执行中的工作。生产者成功入队，仅说明队列接受了项目，不证明已经执行、持久保存或完成下游副作用。若把所有这些状态都叫作“成功”，过载和失败时就无法判断责任归属。

快速验证

将脚本保存为 check-backpressure.py，运行 python3 check-backpressure.py。它只使用 Python 标准库，在 Python 3.14.4 上执行。线程通过明确事件和有界等待协调，不依赖远端消息代理、数据库或刻意拖慢的外部服务。所有队列和任务都只存在当前进程中，结果用于观察接入与完成的语义，不代表分布式队列的持久化保证：

from queue import Queue,Full
from threading import Event,Thread
import json

unbounded=Queue()
for item in range(1000):unbounded.put_nowait(item)
assert unbounded.qsize()==1000
channel=Queue(maxsize=2)
channel.put('a');channel.put('b')
try:
 channel.put('deadline-rejected',timeout=.02)
 raise AssertionError('a full bounded queue accepted another item')
except Full:rejected=True
assert channel.qsize()==2
entered,delivered=Event(),Event()
def produce():
 entered.set();channel.put('c',timeout=2);delivered.set()
producer=Thread(target=produce,daemon=True);producer.start();assert entered.wait(1)
assert not delivered.wait(.05) and channel.qsize()==2
first=channel.get(timeout=1);assert first=='a'
assert delivered.wait(1);producer.join(timeout=1);assert not producer.is_alive()
assert channel.qsize()==2
rest=[channel.get(timeout=1),channel.get(timeout=1)];assert rest==['b','c']
assert channel.empty()
completed=Event()
def join():channel.join();completed.set()
waiter=Thread(target=join,daemon=True);waiter.start();assert not completed.wait(.05)
for item in [first,*rest]:channel.task_done()
assert completed.wait(1);waiter.join(timeout=1);assert not waiter.is_alive()
print(json.dumps({'unbounded_backlog':unbounded.qsize(),'bounded_capacity':2,'deadline_rejected':rejected,
 'blocked_producer_resumed_after_get':delivered.is_set(),'delivered_items':[first,*rest],
 'empty_queue_did_not_mean_processing_complete':True,'join_finished_after_task_done':completed.is_set()}))

第一个队列使用默认无界容量。没有消费者运行时，一千次 put_nowait 全部成功，留下同样数量的积压。这是小规模行为演示，不是耗尽内存测试。它说明接入成功本身无法证明下游已有进展，也不能证明到达速度可持续。监控若只统计提交成功率，就可能在处理能力不足时仍显示表面正常。

第二个队列容量为二，先放入 a 和 b。再次 put 使用短超时，随后抛出 Full，已有项目保持不变。失败项目没有被暗中排队等待以后执行。调用方因此获得明确接入结果，可以按契约决定重试或拒绝，而不是把无限等待包装成已经交付。脚本核对队列状态，避免仅凭异常出现就忽略是否发生了部分接收。

随后生产者线程尝试放入 c。两个槽位占满时，测试确认它仍被阻塞。取出 a 后空出一个位置，生产者完成 put，队列留下 b 和 c。程序验证三个已接受项目最终按顺序被取出。这演示压力确实传递到了生产者，又被具体容量变化释放，而不是仅记录一个队列长度，却让生产者继续无节制提交。

取出其余项目后，队列已经为空，但另一个等待 join 的线程仍未完成。只有对三个已接受项目分别调用 task_done，join 才返回。取出动作先释放容量，任务确认之后才表示被跟踪工作完成。测试刻意分开这些事件，避免把队列清空误认为业务处理结束。生产系统也需要对“拿到任务”和“完成任务”保留对应区分。

让接入契约贯穿整个处理链

应使用队列操作的真实结果，不要根据 qsize 或 full 先检查再行动。其他线程可以随时改变队列，这些观察在并发环境下只具有近似性质。本例通过事件和暂停消费者，使断言对应受控观察；生产调用方应通过操作本身处理 Full 或成功 put，避免在检查与提交之间发生竞争，或将过期容量判断当成保证。

容量应对应真正保留的资源。项目大小不受限时，按个数限制不能直接封顶内存；等待队列限制也不包括所有活跃工作线程或外部请求。评估过载时，需要一起考虑处理并发和上游重试。一个有界组件周围如果仍存在无限待处理工作，整个系统依然可能无界，不能因局部出现 maxsize 就宣布过载闭环已经完成。

最后要定义完成的含义。Python task_done 更新队列记账，不是持久事务，也不证明外部副作用成功。工作线程失败、进程崩溃，或响应不明确之后的重试，都需要应用对应的交付与幂等契约。背压控制接入和节奏，正确性仍依赖明确处理已接受、被拒绝、执行中与已完成任务。两类职责配合，才能在压力变化时保持可解释行为。

来源

Python queue documentation，有界容量、Full、阻塞写入与任务完成，已核验 2026-09-12。
Google SRE: Handling Overload，客户端节流、负载丢弃与基于资源的过载限制，已核验 2026-09-12。

缓存失效是主动推进，不是祈祷

Thu, 05 Aug 2027 00:00:00 +0000

源站文件改了，并不意味着每个已经保存响应的缓存都会收到通知。失效操作控制的是哪些已存副本还可以继续复用，而不只是更新磁盘上的内容。可靠的发布要区分到期、重新验证、定点移除以及使用新 URL：它们解决不同范围的问题，也没有哪一种能远程擦掉读者已经下载的所有字节。

到期不是广播通知

源站发生变化后，一份仍然新鲜的响应可能继续被合法使用。新鲜度由缓存寿命和当前年龄共同决定，年龄计算涉及缓存元数据与经过的时间，并非只从源站的 Date 字段开始倒计时。到期改变的是直接复用时必须满足的条件，既不保证存储介质立即删除条目，也不会让无人访问的缓存主动联系源站。

验证器同样不是内容变化的推送通道。请求需要重新验证时，正确的 ETag 才能帮助源站确认表示未变，或者返回替代正文。浏览器手上的响应还新鲜、没有理由回源时，新增验证器并不能强迫它询问。把源站策略改成 no-cache 或 no-store，也无法追溯修改浏览器之前已经收到的缓存指令。

先确定失效覆盖范围

RFC 9111 要求：缓存收到不安全方法对应的成功或重定向响应时，必须使目标 URI 的已存响应失效。这个义务只涉及该请求实际经过的缓存，不是向整个网络广播。通过另一条接口修改数据库，不会自动覆盖所有派生页面、查询参数变体、不同语言表示和搜索列表，应用需要识别这些真实依赖。

CDN 的清理接口也只管理服务商控制的副本，无法直接清空独立浏览器缓存。应按服务商的实际契约确认受影响的主机、路径、变体以及缓存标签。先让替代内容在源站可用，再发起清理、跟踪完成状态，并比较实际响应正文和缓存状态。接口已经接受清理请求，并不能单独证明它已传播，也不能证明源站已经能返回预期的新字节。

坏掉的样子

如果源站尚未更新就先清理边缘，下一次未命中可能立即把旧内容重新填回去。已经在途的回填也可能和失效操作竞争，具体结果取决于缓存实现。反复执行全站清理不能证明这些竞争已经解决，反而会让更多对象变冷、增加回源负担。应准确圈定受影响对象，并评估清理之后源站需要承担的请求量。

对于静态资产，应先发布带内容指纹的新文件名，再切换 HTML 或清单中的引用。在旧文档仍可能引用旧资产期间，旧文件也应继续可用。新 URL 可以避开旧缓存条目，但前提是读者先拿到更新后的引用文档。只生成一个新文件名，却不更新文档，或者文档本身仍被直接复用，都不会使现有读者自动转向新版本。

涉及机密信息删除时，边界还要更严格。删除源站文件或清理 CDN 不能撤销已经下载的字节，缓存策略也不等于访问授权。应从源头防止敏感响应进入不合适的缓存，而不是泄露后依赖清理挽救。对于紧急修复，要先定义“可见”的对象：新访问者、已经打开的标签页、所有曾下载的副本，不能共享同一种到达保证。

快速验证

准备 Python 3.10 或更新版本及 POSIX shell；实际运行使用 Python 3.14.4、CacheControl 0.14.4 和 Requests 2.34.2。安装下列固定版本后，用 "$invalidation_lab/venv/bin/python" 执行 Python 代码。程序在自动分配的回环端口启动一个 HTTP 服务，并建立两个互不共享存储的内存私有缓存；关闭环境代理，不访问外部服务器，最后关闭客户端、线程和服务。只有依赖安装需要联网。

invalidation_lab=$(mktemp -d)
python3 -m venv "$invalidation_lab/venv"
"$invalidation_lab/venv/bin/python" -m pip install CacheControl==0.14.4 requests==2.34.2

from collections import Counter
from http.server import BaseHTTPRequestHandler, HTTPServer
from threading import Thread

import requests
from cachecontrol import CacheControl
from cachecontrol.cache import DictCache

assets = {"/manual.txt": b"A"}
counts = Counter()


class Origin(BaseHTTPRequestHandler):
 def log_message(self, *_):
 pass

 def do_GET(self):
 counts[self.path] += 1
 body = assets.get(self.path, b"missing")
 status = 200 if self.path in assets else 404
 self.send_response(status)
 self.send_header("Cache-Control", "max-age=600" if status == 200 else "no-store")
 self.send_header("Content-Length", str(len(body)))
 self.end_headers()
 self.wfile.write(body)


server = HTTPServer(("127.0.0.1", 0), Origin)
worker = Thread(target=server.serve_forever)
worker.start()
base = f"http://127.0.0.1:{server.server_port}"
caches = [DictCache(), DictCache()]
clients = []
try:
 for cache in caches:
 client = CacheControl(requests.Session(), cache=cache)
 client.trust_env = False
 clients.append(client)

 def check(index, path, status, body, cached):
 response = clients[index].get(base + path, timeout=3)
 assert (response.status_code, response.content, response.from_cache) == (
 status, body, cached
 )

 for index in range(2):
 check(index, "/manual.txt", 200, b"A", False)
 check(index, "/manual.txt", 200, b"A", True)
 assert counts["/manual.txt"] == 2
 print("warm: two independent caches hold A; origin requests=2")

 assets["/manual.txt"] = b"B"
 caches[0].delete(base + "/manual.txt")
 check(0, "/manual.txt", 200, b"B", False)
 check(1, "/manual.txt", 200, b"A", True)
 assert counts["/manual.txt"] == 3
 print("targeted invalidation: cache 0=B; cache 1=A")

 check(1, "/manual.v2.txt", 404, b"missing", False)
 assets["/manual.v2.txt"] = b"B"
 for index in range(2):
 check(index, "/manual.v2.txt", 200, b"B", False)
 check(index, "/manual.v2.txt", 200, b"B", True)
 assert counts["/manual.v2.txt"] == 3
 check(1, "/manual.txt", 200, b"A", True)
 print("new URL: 404 before publication, then both caches=B")
 print("old URL: cache 1 still holds A")
finally:
 for client in clients:
 client.close()
 server.shutdown()
 worker.join()
 server.server_close()

两名客户端各自第一次向源站获取 A，随后命中自己的缓存，所以初始回源总数是两次。把源站内容改成 B 后，只删除零号缓存中精确 URL 对应的条目：零号客户端重新取得 B，一号仍直接返回 A，不会产生新回源。此时旧 URL 的回源总数为三次。结果直接展示了定点移除的作用范围，并没有证明所有副本已经收敛。

新文件名第一次请求返回带 no-store 的 404，特意暴露了“先引用、后发布”的错误顺序。发布这个文件后，两名客户端都能取得并缓存 B；由于前面的错误响应不存储，它不会挡住这次读取。然而一号客户端再访问旧 URL，仍然命中 A。新旧 URL 是不同条目，发布新版本并不意味着旧条目已被擦除。

这是使用真实 HTTP 请求和缓存存储的局部实验，不是 CDN 清理实现，也没有测试浏览器行为、全球传播或在途回填竞态。CacheControl 的安全模型是私有缓存，不能把这段程序扩成多用户共享边缘。实验只证明明确操作过的条目会变化，其他缓存仍按各自收到的策略工作；上线验收必须另外检查真实服务商规则和实际请求链路。

来源

RFC 9111：使已存响应失效，不安全方法与失效范围，已核验 2026-09-07。
CloudFront：清理与版本化文件名，清理边缘不会清空独立缓存，已核验 2026-09-07。
CacheControl 用法，会话与独立缓存存储，已核验 2026-09-07。
CacheControl 安全模型，私有缓存的适用限制，已核验 2026-09-07。

连接超时阻止无声的停摆

Sun, 01 Aug 2027 00:00:00 +0000

超时首先规定某个操作最多等待多久。它不会自动成为整个请求的总期限，也不能证明远端工作已经停止。选择数值或解释错误之前，要把连接建立、单次读取和调用方的整体预算分开；否则配置看起来都有限，整条调用链仍然可能等得远比预期久。

连上了，不代表能拿到有用的响应

TCP 建连可以成功，而对端应用始终不产生响应。此时问题属于读取阶段，不是 TCP 握手尚未完成。诊断信息应写出发生超时的阶段；含糊的“数据库连接超时”，可能指连接池获取借用失败，也可能指新建套接字失败，或已经连上后等不到查询结果。它们占用的资源、下一步检查和恢复语义并不相同。

Python 套接字上的超时作用于阻塞操作。循环执行多次成功的 recv()，每次都可能获得一份新的等待额度，因此对端只要持续发送小片段，就可能把整个读取循环拖到远超那个超时值。下面特意每次只读一个字节，便于观察单次操作成功与完整响应及时到达之间的差别，而不是把“一次没有超时”当成整个消息已经满足时限。

如果需要整个接收过程共用预算，应先用 time.monotonic() 建立一个截止点。每次开始下一项操作前，计算剩余时间，再取剩余时间与该操作上限中的较小值；预算耗尽后，就不能继续开始新的等待。单调时钟不会因校正系统日期而突然倒退或跳到另一段墙钟时间，但它也不能保证线程恰好在截止的那一刻获得调度，因此不能把它理解成硬实时执行器。

把这个模式扩展到真实客户端之前，仍要核对所用库的契约。域名解析、多个地址尝试、TLS 协商、发送请求以及从连接池排队获取连接，可能有各自的计时方式。本例只访问一个数字形式的回环地址，并使用普通 TCP；它没有证明 DNS 解析已经受限，也没有实现一个覆盖完整 HTTPS 请求流程的通用总超时。

坏掉的样子

已接受连接但保持沉默的对端，会让调用方读到超时；不断滴送少量数据的对端，则能让每次读取都成功，却使完整响应过慢。只有建连超时，并不能处理连接已经成功之后的这两种情况。反过来，设置得过短，也可能把正常的网络波动或线程调度延迟误判成故障，数值需要结合真实调用预算和工作负载来确定。

失败路径需要释放自己拥有的资源，并保留完整数据与部分数据的区别。套接字读取返回空字节串，表示 EOF，并不等于应用消息必然收齐。实验知道目标帧应该有六个字节，所以提前关闭会被当成失败；不能因为连接已经结束，就把收到的半份结果当作正常响应交给业务。

放弃等待也不等于取消远端工作。调用方超时时，对端可能已经执行了某个副作用。重试需要匹配的重放契约，以及原操作还剩下的预算，而不是每次重新获得一整套等待时间。这里的总期限是在操作边界协作检查的约束，仍有调度与清理开销，并不是对任意线程、系统调用或远端执行的瞬时中断保证。

快速验证

将代码保存为 connection_probe.py，执行 python3 connection_probe.py。脚本只依赖标准库，本次在 macOS 的 Python 3.14.4 上验证。每种情况都创建自己的回环监听端口和对端线程，结束时关闭套接字并等待线程退出；不会连接外部主机，也不修改防火墙或生产服务。

import socket
import threading
import time


PAYLOAD = b"abcdef"
PER_OPERATION = 0.5


def exercise(trickle, total=None, peer_payload=PAYLOAD):
 stop = threading.Event()
 failures = []
 with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as listener:
 listener.bind(("127.0.0.1", 0))
 listener.listen(1)
 listener.settimeout(2.0)

 def peer():
 try:
 connection, _ = listener.accept()
 with connection:
 connection.settimeout(0.5)
 if not trickle:
 stop.wait(2.0)
 return
 for byte in peer_payload:
 if stop.wait(0.1):
 return
 connection.sendall(bytes([byte]))
 except (BrokenPipeError, ConnectionResetError):
 pass # The deadline case deliberately closes the client.
 except Exception as error:
 failures.append(error)

 worker = threading.Thread(target=peer)
 worker.start()
 started = time.monotonic()
 deadline = None if total is None else started + total
 received = bytearray()
 phase, outcome = "connect", "complete"

 def allowance():
 if deadline is None:
 return PER_OPERATION
 remaining = deadline - time.monotonic()
 if remaining <= 0:
 raise TimeoutError("total budget expired")
 return min(PER_OPERATION, remaining)

 try:
 with socket.create_connection(listener.getsockname(), timeout=allowance()) as client:
 phase = "read"
 while len(received) < len(PAYLOAD):
 client.settimeout(allowance())
 chunk = client.recv(1)
 if not chunk:
 raise EOFError(f"short frame: {len(received)}/{len(PAYLOAD)} bytes")
 received.extend(chunk)
 except TimeoutError:
 outcome = "total" if deadline is not None and time.monotonic() >= deadline else phase
 finally:
 elapsed = time.monotonic() - started
 stop.set()
 worker.join(2.0)
 assert not worker.is_alive(), "fixture peer failed to stop"
 assert not failures, failures
 return outcome, bytes(received), elapsed


quiet = exercise(trickle=False)
assert quiet[0] == "read" and quiet[1] == b""
trickle = exercise(trickle=True)
assert trickle[0] == "complete" and trickle[1] == PAYLOAD
assert trickle[2] >= 0.5 # Each successful recv got a fresh operation timeout.
bounded = exercise(trickle=True, total=0.25)
assert bounded[0] == "total" and bounded[1] != PAYLOAD
try:
 exercise(trickle=True, peer_payload=b"ab")
except EOFError as error:
 assert str(error) == "short frame: 2/6 bytes"
else:
 raise AssertionError("a truncated frame must not become success")
print("early EOF rejects a two-byte fragment of the six-byte frame")
for name, result in (("quiet", quiet), ("trickle", trickle), ("bounded", bounded)):
 outcome, data, elapsed = result
 print(name, outcome, repr(data), "elapsed", round(elapsed, 3))

quiet 情况先成功建立连接，但没有收到任何数据，大约半秒后报告 read 超时。trickle 情况在发送六个字节之前分别暂停一小段时间，每次读取都落在单次额度内，完整帧却花了超过半秒才到齐。这里的 complete 是指六个预期字节全部到达，不是某一次读取返回了非空内容；这直接展示了逐次操作超时为什么不能代替整个读取循环的预算。

加入四分之一秒总预算后，同样的滴送过程无法收完整帧，结果报告 total 到期并保留部分字节。确切收到了几个字节、打印的小数是多少，会随调度变化；断言检查的是超时类别和结果是否完整，并没有承诺精确到毫秒的运行轨迹。第四个对端只发送两个字节就关闭，读取方必须抛出 EOFError，不能把片段当成完整帧。实验中的短数值只是为了快速暴露这几个边界，不应复制成生产环境默认值。

最后的 stop 事件是测试程序主动提供的协调机制，用于清理时释放本机对端线程，不是 TCP 自动向任意远程业务发送了取消命令。这些结果只验证单次等待与共享接收预算的区别，没有覆盖连接黑洞、TLS 失败、业务重试或生产尾延迟；上线前仍需沿真实客户端调用链逐段确认预算到底覆盖到了哪里。

来源

Python socket，阻塞操作超时、连接建立与套接字读取，已核验 2026-09-09。
Python time，单调时钟与经过时间测量，已核验 2026-09-09。

排班需要连续覆盖，也需要复核实际负担

Fri, 16 Jul 2027 00:00:00 +0000

排班可以分配责任，但相同班次数量并不保证负担公平。应同时检查夜间告警、事故处理时间、恢复休息和可靠备援，而不只看每个人在表里出现了几次。

一份被共同承担的职责

值班是团队的事，不是某一位英雄的。轮班把「谁上次没睡好就谁来」变成一张明确的排班表、一套流程，让被打断分担到每个人头上，而不是让一个人独自背完一整条告警队列。而具体排班好不好，就在于「换人不换上下文」这六个字——交接若只换名字不换现状，同一个故障会在每次轮换时被重新发现一遍。所以轮班的灵魂不是「谁那天晚上在」，而是「责任与上下文如何平稳移交」。

交接是工作的一半

一次值班最容易断的，恰是交接这个环节。当接手的人从零开始、一片黑地接过来，本来该是交接的事就变成了重新破案。堵住这个缝只需要两样：一份书面交接（当前坏在哪、试过哪些、下一棒该试什么），以及一段重叠时间——让接班的人跟着旧的人一起盯岗，旧的人在正式放下前把现场讲完。一张只用来排名字的表，会一次次把同一个事故变成新事故。做出这套的难点，不在排满班，而在排完后还留得住上下文。

在铃声响起前演练

演练应安排在告警响起之前，而不是等故障发生。低峰期把 runbook 平铺地走一遍，练的是「恢复路径」而不是症状集；每一条 pager 都应映射到一份写好的计划，让雪夜里的铃声到来时，它是 checklist 而不是谜。提前练习可以增加团队在压力下的可靠选择；平静时候一遍遍过的常规动作，正是把「到时候再想」变成「按部就班照做」的地方。

坏掉的样子

单人长期值班看似省事，实则先压垮的是人。一个人连续几个月拿着寻呼机，即使没有告警也睡不踏实，看到通知就心慌，最后要么倦怠请辞，要么在一次深夜故障中彻底失手。谷歌站点可靠性工程指导强调人员配置与可持续工作负担。解法是设定单次值班上限，并保证下线周真正下线，上周的主值班不再兼任隐形备援。

升级链断裂是第二种常见死法。备援从不确认、联系方式过期，或者所谓升级到经理只是发进一个无人查看的邮箱，深夜三点主值班只能独自拆弹。升级链要像恢复流程一样演练：在工作时间实际寻呼一次备援，确认有人能在几分钟内应答，而不是只在通讯录里写个名字。

告警疲劳是第三种慢性失效。几百条噪声大、无法行动的告警教会团队寻呼机在说谎，于是唯一真实的那条也被顺手划掉。每条告警都应有负责人、有可执行的 runbook 链接、有经过上次误报调优后的阈值，无法行动的告警宁可降级为工单，也不要继续消耗信任。

交接缺失则让轮换只换名字不换上下文。周一换人时没有书面状态，周二就把周一的排查从零再做一遍。必须要求简短交接记录：当前症状、已尝试步骤、下一步动作，并在旧主值班真正下线前保留十五分钟重叠时间，把现场讲完再走。

快速验证

在正式发布排班前，可以先运行这个纸面模型。它为二十个连续星期安排虚构的主值班与备援，并保留两周虚构的特殊覆盖标记。标记不代表任何国家真实的公共假日，遇到标记也不会让整个服务无人负责。持续运行的服务，在某位工程师休假时仍需要明确接替，不能以节日为由直接删除那一周的覆盖。

把代码保存为空目录下的 rota_probe.py。
用 Python 3.9 或更新版本运行 python3 rota_probe.py；程序不访问网络或文件。
核对逐周人员、各角色次数和最后的 PASS 行。

from collections import Counter
from datetime import date, timedelta

TEAM = ["ana", "ben", "cara", "dev", "elin"] # fictional names
START = date(2027, 8, 2)
WEEKS = 20
SPECIAL_WEEKS = {START + timedelta(weeks=1), START + timedelta(weeks=4)}
rota = [(START + timedelta(weeks=i), TEAM[i % 5], TEAM[(i + 1) % 5])
 for i in range(WEEKS)]
assert len(rota) == WEEKS
assert len({week for week, _, _ in rota}) == WEEKS
assert all(primary != secondary for _, primary, secondary in rota)
assert all(primary in TEAM and secondary in TEAM for _, primary, secondary in rota)
assert all(b[0] - a[0] == timedelta(days=7) for a, b in zip(rota, rota[1:]))
assert all(a[1] != b[1] for a, b in zip(rota, rota[1:]))
primary_counts = Counter(primary for _, primary, _ in rota)
secondary_counts = Counter(secondary for _, _, secondary in rota)
assert set(primary_counts.values()) == {4}
assert set(secondary_counts.values()) == {4}
for week, primary, secondary in rota:
 marker = " special-coverage" if week in SPECIAL_WEEKS else ""
 print(f"{week}: primary={primary} secondary={secondary}{marker}")
assert sum(week in SPECIAL_WEEKS for week, _, _ in rota) == 2
print("primary:", dict(sorted(primary_counts.items())))
print("secondary:", dict(sorted(secondary_counts.items())))
print("PASS: 20 covered weeks, distinct backup, four turns per role; special weeks remain staffed")

每一周都有不同的主值班与备援，包括两周特殊覆盖。每人分别获得四次主值班和四次备援，相邻两周的主值班也不同。本轮在 Python 3.12.14 中执行通过了这些断言。它们只证明表里明确检查的排班性质：星期没有缺口、两个角色不由同一人兼任，以及各角色计数相等。

计数相等不代表夜间打断相等，也不衡量同时发生多起事故、人员真实可用性、时区、补偿或恢复休息。正式启用前，仍应让团队确认这些约束，并测试真实升级联系人。若安排了请假、培训或其他职责，应重新验证替补后的完整覆盖，而不是只把某个名字从表里删除。模型没有给任何真实人员发送通知，也没有承诺他们同意承担某次值班。

来源

SRE Workbook：值班，构建公平的值班轮换，已核验 2026-10-15。
SRE 书：值班，值班实践与边界，已核验 2026-10-15。

探针告诉平台何时出手

Fri, 18 Jun 2027 00:00:00 +0000

探针结果是控制循环使用的证据，不是平台对应用健康的直接理解。Kubernetes 不会从 healthz 这个路径名称推断你希望怎样恢复服务；真正决定下一步的是探针类型、结果、阈值与容器生命周期。把每次失败都描述成“重启 Pod”，会抹掉直接影响可用性的关键区别。

三个问题，对应不同动作

启动探针为初始化提供独立的检测政策。配置后，在它成功之前，存活和就绪探针都不会执行。启动探针成功后，在当前容器生命周期内便不再持续检查；如果容器重新启动，则需要再次通过启动阶段，不能把上一次成功沿用到新生命周期。

存活检查用于识别适合通过重启当前容器恢复的状态。达到失败阈值后，kubelet 终止受到影响的容器，并应用对应的重启政策。这不是保证重建整个 Pod、改变其身份或修复外部数据库，也不意味着容器之间的依赖与在途工作都能自动安全恢复。

就绪失败则让容器继续运行，并持续检查是否恢复。它影响通常按就绪状态选择目标的 Service 流量，但不是防火墙，也不会取消已经通过连接到达的请求。直接访问实例的客户端和现有连接，仍需要自己的生命周期处理，不能把就绪状态误读成网络阻断保证。

阈值统计连续观察结果

failureThreshold 为三，不是从启动以来累计失败三次就动作，而是连续失败达到三次；一次成功会打断这段失败序列。就绪恢复可以要求多次连续成功，而启动和存活探针的 successThreshold 必须为一。阅读结果轨迹之前，应先明确进入失败和恢复成功两个方向的阈值。

超时、初始延迟、执行周期和终止宽限期同样影响实际表现。阈值乘周期可以辅助估算，但不能当成端到端故障切换的精确秒表；调度、探针执行和路由传播都参与其中。容器尚未就绪时，就绪探针还可能比配置周期更频繁地执行，以便更快恢复就绪。

实验选择四次启动失败、三次存活失败、两次就绪失败，并要求连续两次就绪成功才能恢复。这组数字只是为了看清不同计数器的边界，不是生产推荐。真实门槛应结合启动时间、检查成本、错误恢复方式以及误判代价确定，不能照搬实验参数。

检查机制决定你拿到了什么证据

HTTP 检查使用文档定义的 200 至 399 成功范围。即使响应正文写着“内部错误”，返回 200 也不会因为人类读出了坏消息，就自动变成失败探针。应沿实际探测路径检查认证和重定向，而不是默认平台与交互式浏览器具有完全相同的访问结果。

TCP 探针证明的是连接可以打开，不是查询或事务能够完成。exec 检查则需要镜像里确实存在相应命令，并且退出状态有明确含义；频繁创建进程还会消耗节点资源。应该选择能够回答当前问题的低成本机制，而不是认为检查越复杂、调用越多就越可靠。

就绪成功并不是存活执行的前提。没有启动探针隔离时，初始化较长的应用可能还没来得及就绪，就因为存活失败反复被终止。相反，启动容忍窗口过大，也会推迟发现真正无法完成的启动。两边都需要依据实际启动分布和恢复目标权衡。

探针失败与 Unknown 结果不是同一种状态。Kubernetes 文档规定 Unknown 不改变容器状态，之后继续检查。本例只接受成功与失败两个值，故意没有第三种结果，所以无法预测传输错误会如何分类。实际排查应检查 kubelet 事件和部署中的探针处理机制，先确认错误属于哪类，再解释是否应计入连续失败。

坏掉的样子

把外部依赖可用性直接作为存活条件，可能在共享故障期间不断重启健康进程；另一个独立线程上始终绿色的处理器，又可能遗漏业务工作线程的死锁。重启并不天然便宜，它会中断在途工作、重复初始化，也可能进一步增加故障依赖的压力。

如果就绪涵盖每一项可选依赖，本来还能服务的容量也会被撤走；如果状态频繁抖动，负载会在副本之间来回转移，进一步恶化饱和。因此，既要测试明确故障能否被发现，也要测试误判和恢复行为，不能只看一次故障注入能不能把状态变红。

应对照探针结果、容器重启次数、事件记录、就绪变化和真实客户端流量，并确认部署中的配置与路由消费者。一个本地计数模型通过，不代表 kubelet、网络路径或负载均衡器已经正确执行同样规则。平台侧证据不能由应用侧自述替代。

快速验证

保存为 probe_policy_check.py，用 Python 3.10 以上版本执行 python3 probe_policy_check.py，本轮已在 Python 3.12.14 上重新运行。这个确定性模型接收成功或失败两个值，不部署 Pod，不调用 Kubernetes，不安排真实探测时间，也不会重启操作系统进程。

class ProbePolicy:
 # (consecutive successes, consecutive failures), chosen for this experiment.
 thresholds = {"startup": (1, 4), "liveness": (1, 3), "readiness": (2, 2)}

 def __init__(self):
 self.restart_requests = 0
 self.start_container()

 def start_container(self):
 self.started = self.ready = self.restart_requested = False
 self.successes = dict.fromkeys(self.thresholds, 0)
 self.failures = dict.fromkeys(self.thresholds, 0)

 def sample(self, kind, passed):
 if self.restart_requested:
 return "awaiting-restart"
 if kind != "startup" and not self.started:
 return "suppressed"
 if kind == "startup" and self.started:
 return "disabled"
 success_limit, failure_limit = self.thresholds[kind]
 self.successes[kind] = self.successes[kind] + 1 if passed else 0
 self.failures[kind] = 0 if passed else self.failures[kind] + 1
 if passed and self.successes[kind] >= success_limit:
 if kind == "startup":
 self.started = True
 elif kind == "readiness":
 self.ready = True
 if not passed and self.failures[kind] >= failure_limit:
 self.ready = False
 if kind != "readiness":
 self.restart_requested = True
 self.restart_requests += 1
 return "restart-requested" # A model output, not a kubelet or OS action.
 return "sampled"


policy = ProbePolicy()
for _ in range(3):
 assert policy.sample("startup", False) == "sampled"
 assert policy.sample("liveness", False) == "suppressed"
 assert policy.sample("readiness", True) == "suppressed"
assert policy.restart_requests == 0 and not policy.ready
assert policy.failures["liveness"] == 0 and policy.successes["readiness"] == 0
policy.sample("startup", True)
assert policy.started and not policy.ready
assert policy.sample("startup", False) == "disabled"
print("three startup failures do not trigger liveness; startup success enables the other probes")

policy.sample("readiness", True)
assert not policy.ready
policy.sample("readiness", True)
assert policy.ready
policy.sample("readiness", False)
assert policy.ready
policy.sample("readiness", True) # Breaks the consecutive-failure run.
policy.sample("readiness", False)
assert policy.ready
policy.sample("readiness", False)
assert not policy.ready and policy.restart_requests == 0
for result in (True, False, True):
 policy.sample("readiness", result)
assert not policy.ready
policy.sample("readiness", True)
assert policy.ready
print("two readiness failures remove readiness without restart; two consecutive successes restore it")

for result in (False, False, True, False, False):
 policy.sample("liveness", result)
assert policy.restart_requests == 0
assert policy.sample("liveness", False) == "restart-requested"
assert policy.restart_requests == 1 and not policy.ready
assert policy.sample("liveness", False) == "awaiting-restart"
assert policy.restart_requests == 1
policy.start_container() # Explicitly model the beginning of another container lifetime.
assert not policy.started and not policy.ready
for _ in range(4):
 policy.sample("startup", False)
assert policy.restart_requests == 2
print("three consecutive liveness failures request a restart; a fresh lifetime runs startup checks again")
print("four startup failures request another restart; no real container, clock, or traffic route was changed")

前三次启动失败尚未达到实验阈值，期间试图输入的存活、就绪观察都会被抑制，不增加它们的计数。启动成功后，其他检查才开始生效，但不会因此自动变成就绪，仍然需要满足就绪自己的成功条件。

连续两次就绪失败撤下就绪状态，却不申请重启；恢复需要连续两次成功，中间插入相反结果会重置相应的连续计数。连续三次存活失败才产生一次重启请求；模型处于等待重启阶段时，继续输入失败不会重复增加请求数量。

显式开始一个新的容器生命周期后，启动状态被清空，连续四次启动失败又会申请重启。Unknown 结果、传输错误分类、真实计时、重启政策执行、终止宽限和端点传播都没有在此验证；依赖完整平台行为之前，需要在目标集群上补充对应验收。

来源

Kubernetes：存活、就绪与启动探针，探针动作、机制、阈值和启动阶段隔离，已核验 2026-10-15。
Kubernetes：配置探针，可执行配置与容器重启观察，已核验 2026-10-15。
Kubernetes：Pod 生命周期，容器重启政策及终止与流量生命周期的区别，已核验 2026-10-15。

资源限制约束运行，请求参与放置

Mon, 14 Jun 2027 00:00:00 +0000

Kubernetes 的资源 request 与 limit 属于不同决策。请求参与调度和资源共享，限制则配置运行时及操作系统支持的执行约束。把 limit 当成调度器预留的容量，会同时混淆这两个机制。有效的资源策略需要说明放置需求、可以接受的争用，以及运行中的工作负载到达边界后应该发生什么，不能只在清单上填写一组看起来合理的数字。

CPU 与内存具有不同失败方式

在典型 Linux 环境中，CPU 限制会形成带宽约束，繁忙控制组可能被节流，而进程仍然存活。内存限制依赖内存记账和回收；受约束的分配无法满足时，可能触发控制组 OOM 处理。内核不会像推迟 CPU 使用那样，把所有超限内存申请都温和地放慢。两种资源因此需要不同的容量指标和故障判断方式。

内存执行机制具有反应性，不能描述成恰好达到某个字节就调用应用回调，也不能保证使用量绝对不会短暂超过配置值。应用可能收到分配失败，OOM 处理也可能终止进程。应先观察真实终止原因、容器状态和可用的内存事件，再给故障命名，避免仅因为配置了内存限制，就把所有异常退出都解释成越界。

限制覆盖的不只是应用打算保存的业务数据。运行时开销、其他进程，以及被记账的缓存或其他内存，都可能占用控制组额度。容器限制为六十四 MiB，并不意味着它能在已有开销之外，再安全创建同样大小的数据结构。内存支持的卷也可能贡献内存消耗，表现为文件存储并不会让这部分成本消失。

坏掉的样子

退出码 137 对应常见的 SIGKILL 终止表示，本身不足以证明 OOM。应与容器的 OOMKilled 原因以及相关运行时或内核证据结合。节点压力驱逐又是另一种机制，需要检查 Pod 级状态和驱逐决策，不能把一个容器超过自身控制组预算，与 kubelet 为缓解节点压力而移除 Pod 混成同一个过程。

终止后发生什么，由重启策略继续决定。采用 Always 的泄漏程序可能不断重启，而根因始终存在。采用 Never 时，已终止容器保持终止，Pod 可以进入失败状态。限制只约束一种资源维度，既不会修复应用，也不保证邻居在失败发生前完全没有经历争用。是否影响业务延迟，还需要对应观测，不能由限制字段直接推断。

默认值同样重要。如果某项资源填写了 limit，却没有 request，也没有准入机制提供不同默认值，Kubernetes 会把该限制复制为请求。应读取准入后的真实对象，不能认为省略 request 就等于零。仅让内存请求与限制相等，也不足以满足传统 Guaranteed QoS 条件，还需要考虑 CPU 设置及所有相关容器。类别名称也不等于不会失败。

内存应使用明确的 Mi、Gi 等单位，小写 m 表示毫单位，不是兆字节。选择限制需要结合真实工作集与突发量，包含启动过程、并发任务和运行时开销。照抄固定比例或某个分位数，并不能替所有应用决定可接受的 OOM 行为；有状态进程与可重试短任务的恢复代价可能完全不同。

快速验证

本轮没有重跑原样保留的集群实验；以下 Kubernetes 1.34.11 观察属于历史记录。

准备使用 cgroup v2 的临时 Linux Kubernetes 集群、kubectl，以及节点可用的 python:3.11-slim-bookworm 镜像。保存为 memory-limit.py，执行 python3 memory-limit.py KUBECONFIG_PATH CONTEXT，明确指定测试参数。账号需要创建、删除命名空间。实测服务端为 Kubernetes 1.34.11，分配程序最多尝试一百二十八 MiB 载荷，其所在容器的内存限制为六十四 MiB。

import json
import subprocess
import sys
import time
from uuid import uuid4

assert len(sys.argv) == 3, 'usage: python3 example.py DISPOSABLE_KUBECONFIG CONTEXT'
base = ['kubectl', '--kubeconfig', sys.argv[1], '--context', sys.argv[2], '--request-timeout=30s']
image = 'python:3.11-slim-bookworm'


def k(*args, payload=None, expected=0):
 result = subprocess.run(base + list(args), input=json.dumps(payload) if payload is not None else None,
 capture_output=True, text=True, timeout=150)
 if expected is not None:
 assert result.returncode == expected, result.stderr
 return result


def obj(namespace, kind, name=None, selector=None):
 args = ['get', kind, '-n', namespace, '-o', 'json']
 if name:
 args.append(name)
 if selector:
 args += ['-l', selector]
 return json.loads(k(*args).stdout)


def apply(namespace, data):
 return k('apply', '-n', namespace, '-f', '-', payload=data)


def wait_for(read, ready, seconds=120):
 until = time.monotonic() + seconds
 while time.monotonic() < until:
 value = read()
 if ready(value):
 return value
 time.sleep(0.5)
 raise AssertionError('expected Kubernetes condition did not arrive')


def pod_ready(pod):
 return any(c['type'] == 'Ready' and c['status'] == 'True'
 for c in pod.get('status', {}).get('conditions', []))


def spec(script='import time; time.sleep(600)'):
 return {'automountServiceAccountToken': False, 'terminationGracePeriodSeconds': 1,
 'containers': [{'name': 'app', 'image': image, 'imagePullPolicy': 'IfNotPresent',
 'command': ['python3', '-c', script],
 'resources': {'requests': {'cpu': '10m', 'memory': '24Mi'},
 'limits': {'cpu': '200m', 'memory': '96Mi'}}}]}

namespace = 'notes-memory-' + uuid4().hex[:8]
k('create', 'namespace', namespace)
try:
 allocator = '''from pathlib import Path
import json,time
group=Path('/sys/fs/cgroup')
print(json.dumps({'memory_max':(group/'memory.max').read_text().strip(),
 'initial_memory_current':int((group/'memory.current').read_text())}),flush=True)
while not Path('/tmp/go').exists(): time.sleep(0.1)
chunks=[]
for i in range(16):
 chunks.append(bytearray(8*1024*1024))
 print('allocated_chunks='+str(len(chunks)),flush=True)
 time.sleep(0.05)
raise RuntimeError('bounded allocation unexpectedly escaped the expected limit')
'''
 constrained = spec(allocator)
 constrained['restartPolicy'] = 'Never'
 constrained['containers'][0]['resources'] = {
 'requests': {'cpu': '10m', 'memory': '32Mi'}, 'limits': {'cpu': '200m', 'memory': '64Mi'}}
 for name, podspec in [('limited', constrained), ('neighbor', spec())]:
 apply(namespace, {'apiVersion': 'v1', 'kind': 'Pod', 'metadata': {'name': name}, 'spec': podspec})
 wait_for(lambda name=name: obj(namespace, 'pod', name), pod_ready)
 first_log = wait_for(lambda: k('logs', '-n', namespace, 'limited').stdout.strip(), bool)
 before = json.loads(first_log)
 assert before['memory_max'] == str(64 * 1024 * 1024)
 k('exec', '-n', namespace, 'limited', '--', 'python3', '-c',
 'from pathlib import Path; Path("/tmp/go").touch()')
 failed = wait_for(lambda: obj(namespace, 'pod', 'limited'), lambda p: p.get('status', {}).get('phase') == 'Failed')
 status = failed['status']['containerStatuses'][0]
 terminated = status['state']['terminated']
 assert terminated['reason'] == 'OOMKilled' and terminated['exitCode'] == 137
 assert status['restartCount'] == 0
 assert failed['status'].get('reason') != 'Evicted'
 neighbor = obj(namespace, 'pod', 'neighbor')
 assert pod_ready(neighbor) and neighbor['status']['containerStatuses'][0]['restartCount'] == 0
 output = k('logs', '-n', namespace, 'limited').stdout.splitlines()
 chunks = [int(line.split('=')[1]) for line in output if line.startswith('allocated_chunks=')]
 assert chunks and max(chunks) < 16
 print(json.dumps({'before': before, 'last_reported_allocated_chunks': max(chunks),
 'termination_reason': terminated['reason'], 'exit_code': terminated['exitCode'],
 'container_restarts_with_never_policy': 0,
 'pod_was_not_evicted': True, 'neighbor_still_ready': True}))
finally:
 k('delete', 'namespace', namespace, '--wait=true', '--timeout=90s')

第一条日志记录 memory.max 为 67108864 字节。放行文件出现后，原容器进程按每块八 MiB 持续分配。本次运行在终止前报告了六块完成的分配。容器状态明确显示 OOMKilled 和退出码 137，Pod 阶段为 Failed，而不是 Evicted。由于使用 Never 策略，重启次数保持为零，这些信息共同确定了此次失败的性质。

另一个空闲测试 Pod 在最终观察时仍然 Ready，且没有重启。全部断言通过，命名空间随后清理。实验验证一次受约束 OOM 及其生命周期结果，没有测量邻居延迟，也没有建立完整节点隔离。应利用这些失败证据诊断和调整工作负载，不能把清单中存在 limit 直接当成完整可用性保证，更不能忽略真实业务恢复成本。

来源

Kubernetes: Resource Management，请求、限制、默认值与 Linux 执行机制，已核验 2026-10-15。
Kubernetes: Assign Memory Resources，内存限制与实际 OOM 终止，已核验 2026-10-15。
Linux: Control Group v2，memory.max、回收与控制组 OOM 行为，已核验 2026-10-15。

负载削减保护系统

Sun, 16 May 2027 00:00:00 +0000

负载削减是在全部接收工作会威胁服务时，主动拒绝其中一部分。目标是保留容量，让仍有机会完成的工作继续进行，而不是保证每个获准请求都足够快、都足够重要。拒绝本身也会消耗资源，因此在哪个阶段做准入判断，以及拒绝路径有多贵，与阈值大小同样重要。

保护还能产生价值的容量

过载队列既占内存，也增加等待时间。客户端可能在任务被工作线程取走之前就已经放弃，服务器却继续为无人等待的答案花费资源。更长的队列可以吸收某些突发，但在需求长期超过处理能力时，它不会创造额外容量，只会推迟暴露问题。

Google SRE 讨论了队列限制、资源压力信号、选择性拒绝和降低响应质量。削减与降级相关，但并不相同：拒绝一个请求，不等于完成一个较便宜的版本。后者必须有清楚的产品契约，说明剩下的结果仍有什么价值，不能只是悄悄少做一部分工作。

不同保护机制也可能针对不同组件。Envoy 过载管理器保护代理自身资源，而它的熔断机制主要保护上游服务。依赖熔断器不会自动解决本地内存、连接或文件描述符耗尽，所以不能只看到请求被快速拒绝，就认定整个入口已经免于过载。

选择有依据的政策

按优先级拒绝，可以保护关键业务路径，但 HTTP 方法或是否容易重试，本身并不能决定重要性。一次读取可能非常关键，一次写入也可能只是允许丢弃的遥测。应使用可信的应用分类，而不是任由调用方把自己的所有请求都声明成最高优先级。

统一准入上限或按比例拒绝，也可以是合理政策，不能因为没有业务优先级就一概认为它们错误。需要明确公平性与容量之间的取舍，包括低优先级工作是否可能长期得不到执行，以及不同租户是否共用同一个限制。拒绝顺序应该服务于真实契约，而不是凭方法名称猜测。

请求数量、字节、执行时间和 CPU 成本是不同预算。只限制三个任务，如果每个任务都可以保留任意大的正文，仍然不能约束内存。应选择与受保护资源对应的信号，并通过真实请求组合验证行为，不能把单一计数上限解释成对所有资源的统一保证。

限制准入，而不只是线程数量

线程池的工作线程上限约束同时执行的任务数，不一定限制已经接受、正在排队的工作。只在工作线程内部获取信号量，会让它前面的队列继续增长。应在昂贵工作提交之前做有界准入，并在任务生命周期真正结束时归还容量，而不是等到执行阶段才开始计数。

名称类似的代理限制，也需要精确理解。NGINX limit_conn 按文档规定的连接规则计数；在 HTTP/2、HTTP/3 中，每个并发请求都被单独计入。不能默认某个“连接数上限”始终只是在统计 TCP socket，否则复用连接下的真实请求并发可能与预想完全不同。

下面的实验同时约束排队和运行中的任务。被拒提交不会创建 future；完成回调会在成功、失败或执行前取消后归还名额，而向已经关闭的执行器提交失败，也会归还尚未使用的名额。这样准入预算对应完整生命周期，而不是只覆盖正常结束的路径。

坏掉的样子

如果已经解析巨大正文、打开数据库连接或执行了业务写入，才开始拒绝，可能已经来不及保护目标资源。昂贵的日志和错误响应生成，也可能让拒绝路径本身过载。应一起观察拒绝成本、获准吞吐量、排队时长、活动工作量与资源压力，而不是仅统计拒绝了多少次。

HTTP 503 可以表达服务暂时不可用，429 则表示调用方在某种政策下请求过多。Retry-After 只是等待信号，不证明重放写操作安全，也不保证之后一定存在容量。立即重试可能把刚削减的负载原样加回来，因此拒绝与客户端行为必须放在同一条链路中理解。

不要仅因为调用方停止等待，就提前回收仍在运行任务的名额。等待 future 结果超时，不会终止工作线程。提前归还会让新任务与实际上尚未结束的旧任务重叠，破坏原先承诺的容量上限；资源记账应以工作真实结束为依据。

快速验证

保存为 shedding_check.py，用 Python 3.10 以上版本执行 python3 shedding_check.py。实验已在 Python 3.14.4 上运行，只使用标准库。真实线程等待测试协调事件，不访问外部服务，也不制造生产负载。前后两种配置接收的是同样十二个任务的突发，用来比较获准与等待数量。

from concurrent.futures import ThreadPoolExecutor
from threading import Barrier, BoundedSemaphore, Event, Lock


def exercise(gated):
 slots = BoundedSemaphore(3) # Bounds queued plus running work, not just threads.
 started, release, lock = Barrier(3), Event(), Lock()
 running, began = set(), []

 def held(job):
 with lock:
 running.add(job)
 began.append(job)
 try:
 if job < 2:
 started.wait(timeout=5)
 assert release.wait(timeout=5), "test coordinator did not release workers"
 return job
 finally:
 with lock:
 running.remove(job)

 with ThreadPoolExecutor(max_workers=2) as pool:
 def submit(function, *args):
 if not gated:
 return pool.submit(function, *args)
 if not slots.acquire(blocking=False):
 return None # Explicit local admission refusal; no future was enqueued.
 try:
 future = pool.submit(function, *args)
 except RuntimeError:
 slots.release()
 raise
 # Completion, failure, and cancellation before execution all return the slot.
 future.add_done_callback(lambda _: slots.release())
 return future

 futures = [submit(held, job) for job in range(12)]
 accepted = [future for future in futures if future is not None]
 replacement = None
 try:
 started.wait(timeout=5)
 with lock:
 assert running == {0, 1} and set(began) == {0, 1}
 assert all(not future.done() for future in accepted)
 if gated:
 assert len(accepted) == 3 and futures[3:] == [None] * 9
 assert futures[2].cancel() # Both workers are held, so job 2 has not started.
 replacement = submit(held, 12)
 assert replacement is not None
 assert submit(held, 13) is None
 print("gated burst: 2 running + 1 queued, 9 initial refusals; cancellation returns a slot")
 else:
 assert len(accepted) == 12
 print("ungated burst: 2 workers accept 12 unfinished tasks; the other 10 still wait")
 finally:
 release.set()
 completed = [future.result(timeout=5) for future in accepted if not future.cancelled()]
 if replacement is not None:
 completed.append(replacement.result(timeout=5))
 assert sorted(completed) == ([0, 1, 12] if gated else list(range(12)))

 if gated:
 def fail():
 raise ValueError("injected task failure")

 failed = submit(fail)
 assert failed is not None
 try:
 failed.result(timeout=5)
 except ValueError as error:
 assert str(error) == "injected task failure"
 else:
 raise AssertionError("the failed task must preserve its failure")

 if gated:
 # The executor is now closed; a failed submission must not consume a slot.
 try:
 submit(lambda: None)
 except RuntimeError:
 pass
 else:
 raise AssertionError("submission to a closed executor must fail")
 acquired = [slots.acquire(blocking=False) for _ in range(3)]
 try:
 assert acquired == [True, True, True]
 assert not slots.acquire(blocking=False)
 finally:
 for success in acquired:
 if success:
 slots.release()
 print("completion, task failure, cancellation, and closed-executor submission leave all 3 slots reusable")


exercise(False)
exercise(True)

只有两个工作线程、没有准入门槛时，十二个任务都仍未完成：两个正在运行，十个在等待。增加三个名额后，只接收三个任务，其他九个在提交之前被拒绝。这里获准的是两个运行任务加一个排队任务，不是同时运行三个线程，断言明确区分了两种数量。

取消还在排队的任务，会归还一个名额供替代任务使用，紧接着再提交一个则仍会被拒。协调事件释放线程后，预期任务完成。注入的任务异常和执行器关闭后的提交失败，都保留各自错误；最后通过公开信号量操作确认，三个名额全部可以再次使用。

实验验证的是准入记账与任务生命周期，不是 HTTP 响应、字节限制、优先级调度、生产延迟或自动资源压力控制器。NGINX、Envoy 只作为语义来源被引用，没有在本例中部署或执行。把该机制用于真实服务之前，仍需针对自己的保护对象验证容量与失败路径。

来源

Google SRE：处理过载，关键性、资源信号、拒绝成本与客户端行为，已核验 2026-09-08。
Google SRE：处理级联故障，队列上限、负载削减、截止期限与降级，已核验 2026-09-08。
Envoy 过载管理器，本地资源保护与上游熔断的区别，已核验 2026-09-08。
NGINX 连接限制，请求计数、HTTP/2–HTTP/3 语义与拒绝状态，已核验 2026-09-08。
Python futures，任务提交、结果等待超时、取消与完成回调，已核验 2026-09-08。
Python 线程工具，非阻塞有界信号量准入与协调原语，已核验 2026-09-08。
RFC 9110，服务不可用、Retry-After 与重试安全语义，已核验 2026-09-08。
RFC 6585，第四节单独定义 429 与服务器决定的计数政策，已核验 2026-09-08。

Retry-After 告诉你何时再试

Tue, 04 May 2027 00:00:00 +0000

Retry-After 告诉客户端，在发起后续请求之前应当等待多久。它是调度信号，不证明下一次请求一定成功，也不证明重放原操作是安全的。客户端仍然需要截止期限、尝试次数政策，以及哪些操作可以重试的判断，不能把这些责任都交给一个响应头。

结合响应语境解释字段值

RFC 9110 允许非负十进制整数秒数，或者 HTTP 日期。秒数从收到响应之后开始计算，不是从发出原请求时算起；日期则表示一个绝对 UTC 时刻，因此正确解释它依赖客户端墙上时钟足够准确，不能把两个形式都当成“从请求开始算多久”。

发送方必须使用首选的 IMF-fixdate 格式。解析 HTTP 日期的接收方还必须接受两种旧格式，其中旧 RFC 850 格式的两位年份需要遵守五十年解释规则。负数、小数秒和任意文字，都不是合法的 delay-seconds；零和已经过去的日期，则不要求增加服务器指定的等待时间。

配合 503 时，该字段估计服务还会对客户端不可用多久；配合 3xx 响应时，它要求在发送重定向请求之前至少等待相应时间。RFC 6585 另行允许 429 携带 Retry-After，但这里是可选字段，不是每一条限流响应都必须包含的内容。

尊重等待时间，但不无限等待

一个合法等待值可能长于调用方剩余期限。客户端可以停止重试并报告失败，或者在另有授权的流程中安排后续处理；不能只是为了符合本地上限，就缩短服务器要求的等待，然后提前发起请求。很长的值并不自动等于格式错误，也可能是真实的维护安排。

把绝对日期换算成等待时长后，执行调度和经过时间记账应使用单调时钟。真正开始下一次尝试之前，还应重新检查期限，并为这次请求本身保留完成时间。时钟偏差、响应传输和调度延迟，都说明计算出的计划时间与实际请求时间不是同一份证据。

如果字段缺失或无法使用，有界客户端政策可以采用自己的退避规则。但那是客户端的选择，不是服务器给出的恢复估计。必须明确最多尝试几次、总共允许耗费多久，避免一个可选字段让暂时失败变成没有终点的重试循环。

相同等待值仍可能让调用者同时回来

如果成千上万的客户端几乎同时收到相同等待值，它们仍可能在同一个时刻返回。Retry-After 本身不会把这些请求自动摊开到恢复窗口。可以在尊重要求的等待后增加非负抖动，或者用其他不早于该边界的调度方式，但不能向前减掉等待来制造错峰。

组合本地退避和服务器提示时，需要同时保留两者约束。示例取本地退避与解析出的等待值中较大者，再添加正向抖动。注入的偏移量展示的是调度关系，不是实际分布式流量的测量结果，也不是对某个生产环境抖动范围的推荐。

坏掉的样子

当原请求结果未知时，盲目重放写操作可能重复产生副作用。429、503 和 Retry-After 都不会赋予操作幂等保证；重复非幂等工作之前，需要依据应用自己的重试契约，包括操作标识或去重规则，不能只检查响应头是否存在。

不同客户端库的自动重试和重定向行为也不相同。应验证真实客户端会处理哪些状态、方法和字段。实验政策只对 429 或 503 后的 GET、HEAD 做重试计划，明确不跟随重定向、不重放 POST。这是一个有界示例政策，不是 HTTP 所有幂等方法的完整名单。

非法值、巨大等待、过时日期、耗尽的截止期限和次数上限，都应进入测试。应观察真正的请求尝试与等待，而不是认为配置了响应头就代表客户端已经遵守。服务器也可能在估计时间之后仍不可用，所以重试流程需要一个清楚的终止结果。

快速验证

保存为 retry_check.py，用 Python 3.10 以上版本执行 python3 retry_check.py。此前记录使用 Python 3.14.4，本轮没有重跑；仅用标准库。代码向自己创建的回环 HTTP 服务发送真实请求，使用固定测试日期和注入时钟，结束后停止服务；不会实际等待到下一次重试，也不访问外部服务。

from datetime import datetime, timedelta, timezone
from email.utils import format_datetime, parsedate_tz
from http.client import HTTPConnection
from http.server import BaseHTTPRequestHandler, HTTPServer
import re
from threading import Thread


UTC = timezone.utc
REFERENCE = datetime(2026, 9, 8, 12, 0, 0, tzinfo=UTC)


def delay_seconds(value, received_wall):
 if value is None:
 return None
 value = value.strip(" \t")
 if re.fullmatch(r"[0-9]+", value):
 # Huge decimal values become infinity and fail the bounded retry budget.
 return float(value)
 parts = parsedate_tz(value)
 if parts is None:
 return None
 year, month, day, hour, minute, second = parts[:6]
 old_date = re.fullmatch(r"[A-Za-z]+, [0-9]{2}-[A-Za-z]{3}-([0-9]{2}) [0-9:]{8} GMT", value)
 if old_date:
 now = datetime.fromtimestamp(received_wall, UTC)
 year = now.year // 100 * 100 + int(old_date[1])
 if (year, month, day, hour, minute, second) > (
 now.year + 50, now.month, now.day, now.hour, now.minute, now.second
 ):
 year -= 100
 if not 0 <= second <= 60:
 return None
 try:
 stamp = datetime(year, month, day, hour, minute, min(second, 59), tzinfo=UTC)
 stamp += timedelta(seconds=(second == 60) - parts[9])
 except (ValueError, OverflowError):
 return None
 return max(0.0, stamp.timestamp() - received_wall)


def retry_at(status, method, value, received_wall, monotonic_now, remaining, attempt, jitter=0.25):
 assert attempt >= 1 and jitter >= 0
 if status not in (429, 503) or method not in ("GET", "HEAD") or attempt >= 3:
 return None
 server_delay = delay_seconds(value, received_wall)
 wait = max(server_delay or 0.0, 2 ** (attempt - 1)) + jitter
 if wait >= remaining:
 return None
 return monotonic_now + wait


wall = REFERENCE.timestamp()
for value in ("Tue, 08 Sep 2026 12:00:07 GMT", "Tuesday, 08-Sep-26 12:00:07 GMT",
 "Tue Sep 8 12:00:07 2026"):
 assert delay_seconds(value, wall) == 7
assert delay_seconds("Sunday, 06-Nov-94 08:49:37 GMT", wall) == 0
assert delay_seconds("Monday, 08-Sep-70 12:00:00 GMT", wall) == (
 datetime(2070, 9, 8, 12, tzinfo=UTC).timestamp() - wall
)
assert delay_seconds("Sat, 31 Dec 2016 23:59:60 GMT",
 datetime(2016, 12, 31, 23, 59, 59, tzinfo=UTC).timestamp()) == 1
for invalid in ("-1", "1.5", "later", "", "٣", "Tue, 31 Feb 2026 12:00:00 GMT"):
 assert delay_seconds(invalid, wall) is None
assert delay_seconds(" 0003\t", wall) == 3
assert retry_at(503, "GET", "9" * 5000, wall, 100, 10, 1) is None
assert retry_at(503, "GET", "3", wall, 100, 2, 1) is None
assert retry_at(503, "POST", "3", wall, 100, 10, 1) is None
assert retry_at(503, "GET", "3", wall, 100, 10, 3) is None
print("both delay forms, obsolete dates, year interpretation, and invalid values are checked")
print("an oversized wait, exhausted deadline, POST, or attempt cap stops this retry policy")

cases = {
 "/seconds": (429, "3"),
 "/date": (503, format_datetime(REFERENCE + timedelta(seconds=7), usegmt=True)),
 "/invalid": (503, "later"),
 "/missing": (503, None),
 "/redirect": (307, "3"),
 "/ready": (200, None),
}
visited = []


class Handler(BaseHTTPRequestHandler):
 def do_GET(self):
 visited.append(self.path)
 status, value = cases.get(self.path, (404, None))
 self.send_response_only(status)
 self.send_header("Date", format_datetime(REFERENCE, usegmt=True))
 if value is not None:
 self.send_header("Retry-After", value)
 if status == 307:
 self.send_header("Location", "/ready")
 self.send_header("Content-Length", "0")
 self.end_headers()

 def log_message(self, *_):
 pass


with HTTPServer(("127.0.0.1", 0), Handler) as server:
 thread = Thread(target=server.serve_forever, kwargs={"poll_interval": 0.05})
 thread.start()
 try:
 for route, expected in (("/seconds", 103.25), ("/date", 107.25),
 ("/invalid", 101.25), ("/missing", 101.25), ("/redirect", None)):
 client = HTTPConnection(*server.server_address, timeout=2)
 try:
 client.request("GET", route)
 response = client.getresponse()
 response.read()
 planned = retry_at(response.status, "GET", response.getheader("Retry-After"),
 wall, 100, 10, 1)
 assert planned == expected
 print(route, "status", response.status, "planned monotonic time", planned)
 finally:
 client.close()
 assert "/ready" not in visited
 finally:
 server.shutdown()
 thread.join(timeout=2)
 assert not thread.is_alive()

same_delay = [retry_at(429, "GET", "3", wall, 100, 10, 1, jitter=0) for _ in range(4)]
spread = [retry_at(429, "GET", "3", wall, 100, 10, 1, jitter=j) for j in (0.1, 0.2, 0.3, 0.4)]
assert same_delay == [103] * 4
assert len(set(spread)) == 4 and min(spread) > 103
print("identical server delays synchronize plans; injected positive jitter spreads them:", spread)

解析检查覆盖列出的秒数、日期、旧格式、年份解释、闰秒和非法输入，但 email.utils 还接受 HTTP 日期语法之外的输入。因此这是宽松的调度演示，不是严格的 RFC 语法验证器；生产环境需要明确自己的接收和拒绝政策。有界政策会放弃超过剩余期限的等待、POST 重放，以及达到次数上限后的再次尝试。日期和时钟是明确设定的测试数据，并没有修改机器时间，也不代表运行当时的真实 UTC 时刻。

本地 429 返回三秒等待时，从注入的单调时间一百计算出 103.25 的计划时间；日期形式的 503 得到 107.25。缺失或非法字段使用已经声明的本地退避，重定向则不会被自动跟随。四个相同延迟产生四个 103 的计划，注入正向抖动后得到 103.1 到 103.4，展示的是可以验证的计划差异。

这些是响应与调度决定测试，不是实际按时重试的验收。真实时钟校准、网络分区、代理行为、生产抖动分布和业务操作去重仍未测试。落地时应观察最终发出的请求，不能把一组正确的计算时间，直接当成客户端已经在复杂网络中按时重试的证据。

来源

RFC 9110，5.6.7 和 10.2.3 节定义 HTTP 日期和 Retry-After，已核验 2026-10-15。
RFC 6585，429 中可选的 Retry-After，已核验 2026-10-15。
Python 邮件工具，日期解析、UTC 偏移和时间戳格式化，已核验 2026-10-15。

优雅降级保留部分价值

Thu, 22 Apr 2027 00:00:00 +0000

优雅降级是在服务某一部分失效时，继续提供事先明确支持的功能子集。例如，文章页面可以暂时省略推荐区域，同时仍然显示用户请求的正文。关键是这种部分答案必须符合产品契约，既有用又如实说明限制。返回一点内容，并不天然比明确失败更安全；如果剩余内容会误导用户，就不能仅为了保持成功状态码而继续提供它。

先决定哪些东西可以缺少

编写回退代码之前，应分清可选区域和必须满足的结果。侧栏推荐消失可能可以接受，但默默跳过权限检查、把结果未确认的支付说成成功，或用未经验证的价格替代当前报价，都可能破坏核心承诺。这些情况需要明确失败或另行批准的处理流程，不能套用一个“页面总要保持绿色”的统一开关。降级范围应来自业务语义，而不是依赖清单上哪个接口最容易被捕获异常。

可选依赖应尽可能避免占住核心响应的关键路径。它的调用需要有界预算，但调用方等待超时，不代表底层工作已经停止。还应限制并发和排队，避免大量已经失去价值的任务继续占用线程或连接。占位说明应告诉用户缺少什么能力，同时避免暴露内部错误细节，也不能暗示已经取得当前数据。核心页面能否正常工作，应在强制关闭可选区域时单独检查。

把陈旧数据的可接受条件写清楚

最后一次良好数据只在明确范围与年龄政策内有用。需要记录数据取得时间，保留所属对象和授权范围，并规定年龄未知、超过限制或缓存为空时如何处理。一个时间戳本身不能证明数据正确：某些状态发生变化后，即使缓存只有很短时间，也不能继续用于作出授权或交易决定。因此，是否可以复用，是契约问题，不是看到缓存还有内容就可以决定。

上游失败后提供旧数据，与 stale-while-revalidate 并不相同，后者可以在发起验证的同时提供符合条件的陈旧响应。两者都需要有界的新鲜度与资源政策。成功刷新时，也必须真正替换缓存内容并重置年龄；否则系统可能不断声称提供“最近一次成功结果”，实际却永远返回更早的那份快照。显示年龄有助于观察，但不能代替这些状态更新与过期判断。

坏掉的样子

回退可能扩大事故。AWS 关于避免回退的文章描述了缓存故障后流量直接涌向数据库，最终超出数据库承受能力的事件。这份来源是在警告难以测试、很少运行的备用路径，并不是无条件支持“有部分答案就一定更好”。应该优先改善可预测的主要路径，并经常演练恢复行为，而不是把希望寄托在资源需求不明、只有事故时才启用的复杂分支上。

缓存同时到期、所有节点同时试探恢复，都可能制造突发负载。需要分散刷新工作，限制重试与并发，并检查备用路径是否还在争用已经耗尽的同一资源。熔断器决定是否继续调用依赖，降级政策决定剩下的答案是否可以接受。这是两个不同问题：熔断器打开，并不能证明缓存仍然有效，也不能证明某个静态占位符合业务承诺。

恢复探测失败后，普通请求准入必须继续关闭。如果还没验证恢复就先闭合熔断器，流量可能过早回到故障依赖。生产实现还需要同步、探测调度和有界恢复并发，串行示例不能验证这些性质。降级响应也应有独立计数与数据年龄观测，避免 HTTP 200 掩盖持续的功能缺失；是否需要告警，还要结合影响范围、持续时间和实际可采取的动作。

快速验证

保存为 degrade_probe.py，执行 python3 degrade_probe.py。这个标准库样本只模拟一个可选推荐区域，不执行网络或文件系统操作。缓存年龄和依赖失败都是显式注入的输入，一百二十秒上限只是示范性的产品决定。探测由程序明确、同步地调用，没有实现自动计时器或并发请求准入，因此也不声称能够协调多个进程的半开请求。

class DependencyDown(Exception):
 pass

class PageService:
 def __init__(self):
 self.cached_recs = ["cached-pick"]
 self.cached_age_s = 90 # Injected age, not a running clock.
 self.max_age_s = 120
 self.failures, self.threshold = 0, 3
 self.open = False
 self.live_calls = 0

 def live_recs(self, fail):
 self.live_calls += 1
 if fail:
 raise DependencyDown("recs down")
 return ["fresh-pick"]

 def fresh(self, data):
 self.cached_recs, self.cached_age_s = list(data), 0
 self.failures, self.open = 0, False
 return {"mode": "fresh", "data": data}

 def fallback(self, reason):
 if self.cached_recs and 0 <= self.cached_age_s <= self.max_age_s:
 return {"mode": "cached", "data": list(self.cached_recs),
 "age_s": self.cached_age_s, "reason": reason}
 return {"mode": "simplified", "data": ["popular-picks"], "reason": reason}

 def get_recs(self, fail=False):
 if self.open:
 return self.fallback("breaker-open")
 try:
 return self.fresh(self.live_recs(fail))
 except DependencyDown:
 self.failures += 1
 self.open = self.failures >= self.threshold
 return self.fallback("dependency-failed")

 def half_open_probe(self, fail=False):
 # Explicit synchronous trial; not a concurrent admission controller.
 assert self.open, "probe requires an open breaker"
 try:
 data = self.live_recs(fail)
 except DependencyDown:
 return self.fallback("probe-failed") # Leave the breaker open.
 return self.fresh(data) # Close only after success.

svc = PageService()
assert svc.get_recs() == {"mode": "fresh", "data": ["fresh-pick"]}
assert svc.cached_recs == ["fresh-pick"] and svc.cached_age_s == 0
svc.cached_age_s = 120
cached = svc.get_recs(fail=True)
assert cached["mode"] == "cached" and cached["age_s"] == 120
assert cached["data"] == ["fresh-pick"]
svc.cached_age_s = 121
assert svc.get_recs(fail=True)["mode"] == "simplified"
svc.get_recs(fail=True)
assert svc.open
calls = svc.live_calls
assert svc.get_recs()["reason"] == "breaker-open" and svc.live_calls == calls
assert svc.half_open_probe(fail=True)["reason"] == "probe-failed"
assert svc.open and svc.live_calls == calls + 1
calls = svc.live_calls
svc.get_recs()
assert svc.live_calls == calls # A failed probe must not reopen normal admission.
assert svc.half_open_probe()["mode"] == "fresh" and not svc.open
assert svc.cached_age_s == 0
svc.cached_recs = []
assert svc.get_recs(fail=True)["mode"] == "simplified"
svc.cached_recs, svc.cached_age_s = ["unknown-age"], -1
assert svc.get_recs(fail=True)["mode"] == "simplified"
print("PASS: fresh refresh, bounded cache, empty/invalid cache, open gate, failed/successful probe")

成功调用会刷新缓存。接下来依赖失败时，如果注入年龄恰好为一百二十秒，回退返回的确实是刚才取得的最新成功值；改为一百二十一秒，就选择明确简化的答案。连续三次失败使调用闸口打开，下一次普通请求继续得到回退，但实际调用计数不增加。这里验证的是旧数据仍然符合约定，而不仅仅是旧数据仍然存在。

失败探测只执行一次真实的模拟调用，并保持熔断器打开；随后普通请求依然不能增加调用数。成功探测才会关闭闸口并刷新缓存。独立的空缓存和负年龄对照也都选择简化响应。最后的 PASS 只覆盖这些确定性状态选择，没有测量真实服务的可用性，也没有证明其他机器会在同一时刻看到相同的恢复结果。

部署前，应在受控负载下对真实依赖故障和恢复验证已选择的契约，并分别检查截止时间、取消、授权范围、缓存年龄计算和可见的降级指标。示例中的静态推荐回退有意保持廉价，不需要访问另一个系统。它不能证明一个备用远程服务在相关性故障中仍然健康，更不能用来替代真实恢复并发与资源争用的验收。

来源

AWS Builders’ Library：避免在分布式系统中回退，不常执行的回退路径与事故放大风险，已核验 2026-10-15。
Google SRE：优雅降级，丢负载以保住有用部分，已核验 2026-10-15。
Martin Fowler：熔断器，打开状态下拒绝调用，以及受控恢复探测，已核验 2026-10-15。

带抖动与退避的重试

Sat, 10 Apr 2027 00:00:00 +0000

重试意味着再增加一份工作，不是自动提高可靠性的操作。它可能帮助恢复暂时失败，也可能重复一个不安全的业务行动，或把额外需求送到已经过载的依赖。选择延迟公式之前，应先确定哪些操作允许重复、总共能投入多少次尝试与多长时间，以及这些额外工作由哪一层负责。

先约束尝试次数，再安排时间

需要区分尝试和重试：总共三次尝试，是第一次调用加最多两次重试。还要确定恢复责任属于哪一层。如果嵌套的三层各自允许三次尝试，一次外层行动就可能对持续失败的最底层发起二十七次调用。抖动只能改变这些调用的时间，不能消除次数相乘的结果。

Google SRE 同时讨论单请求预算与更广范围的重试预算。即使每个请求都有限次尝试，大量失败的客户端仍可能制造相当可观的额外工作。应把重试流量与原始需求分别统计，并核对 SDK、代理和应用层已经存在的政策，避免每一层都独立认为自己只增加了少量调用。

指数退避增长的是上限

封顶指数退避让等待上限逐步增大，直到达到最大值。没有抖动时，同时失败的客户端可能算出相同的下次时间，甚至在到达上限后继续保持同样间隔。等待更久，并不必然打破同步，不能把周期变长当成请求已经分散的证据。

完全抖动会在零与当前上限之间采样。因为取值随机，即使上限正在增长，下一次实际等待仍可能比上一次短。因此，“每次失败后一定比之前多等一会儿”不是这种算法的准确描述；需要区分退避上限的变化与本次真正取到的延迟。

AWS 的文章比较了完全抖动、等量抖动和去相关抖动，并报告特定竞争模拟的结果。这些结果能帮助理解取舍，却不保证某种政策在所有工作负载下都具有最低延迟，也不保证完全没有突发。相同随机种子、定时器粒度和大量客户端，仍可能形成聚集。

整条操作共用一个截止期限

预算必须同时包括执行、等待和后续尝试。每次调用都重新拿到完整超时时长，会悄悄扩大原调用方允许的生命周期。应把剩余预算传给下游，并在准备进行更多工作之前再次检查，而不是只限制两次调用之间睡多久。

进程内计算经过时间，应使用单调时钟。客户端超时，也不证明服务器已经停止或从未提交；取消与远端截止期限需要真实的传输层支持，业务仍然需要重试或幂等契约。不能因为本地函数返回错误，就把未知结果当成未执行。

Retry-After 等服务端等待提示会增加另一项约束。不能因为本地抖动公式允许较小值，就采样出早于该边界的请求时间。如果必须等待的时间已经无法放进剩余期限，应在当前操作中放弃重试，而不是为了凑预算缩短服务端要求。

坏掉的样子

永久性的参数验证错误，不会因为重复发送就变得合法。非幂等操作在结果不明时重放，可能再次产生同一业务效果。应明确选择可重试的失败类别；捕获所有异常后循环重试，既会掩盖编程错误，也可能把一次局部故障推成持续过载。

只有退避上限，没有次数或总耗时限制，仍然允许无限工作；但期限过短，又可能让所有昂贵却合法的操作一直失败。需要一起观察完成工作量、重试次数、总延迟和放弃原因。仅看到错误率下降，可能忽略为了获得成功而越来越高的重试成本。

快速验证

保存为 retry_check.py，用 Python 3.10 以上版本执行 python3 retry_check.py。本轮以 Python 3.12.14 完整运行，只使用标准库。时钟和下游调用都是确定性模型，不真实等待，不启动服务，也不访问依赖。示例政策只允许 GET、HEAD 在超时或 503 后重试，不是所有 HTTP 客户端行为的实现。

from collections import Counter
import random


class Clock:
 def __init__(self):
 self.now = 0.0

 def advance(self, seconds):
 self.now += seconds


class ScriptedCall:
 def __init__(self, clock, steps):
 self.clock, self.steps, self.timeouts = clock, iter(steps), []

 def __call__(self, timeout):
 self.timeouts.append(timeout)
 status, duration = next(self.steps)
 self.clock.advance(min(duration, timeout))
 if duration >= timeout:
 raise TimeoutError("the cooperative fixture used the remaining budget")
 return status


def retry(call, clock, budget, sample, method="GET", max_attempts=3):
 deadline = clock.now + budget
 for attempt in range(1, max_attempts + 1):
 remaining = deadline - clock.now
 if remaining <= 0:
 return "deadline", attempt - 1
 try:
 status = call(remaining)
 except TimeoutError:
 status = None
 if clock.now >= deadline:
 return "deadline", attempt
 if status == 200:
 return "success", attempt
 if status not in (None, 503) or method not in ("GET", "HEAD"):
 return "not-retryable", attempt
 if attempt == max_attempts:
 return "attempt-limit", attempt
 ceiling = 2.0 ** min(attempt - 1, 3)
 delay = ceiling * sample()
 assert 0 <= delay <= ceiling
 if delay >= deadline - clock.now:
 return "wait-exceeds-budget", attempt
 clock.advance(delay)
 raise AssertionError("positive attempt limit required")


clock = Clock()
call = ScriptedCall(clock, [(503, 0.25), (503, 0.25), (200, 0.25)])
assert retry(call, clock, 5, lambda: 0.5) == ("success", 3)
assert clock.now == 2.25 and call.timeouts == [5, 4.25, 3]
print("three attempts finish at 2.25; propagated timeouts shrink from 5 to 4.25 to 3")

class EarlyTimeout:
 def __init__(self, clock):
 self.clock, self.timeouts = clock, []

 def __call__(self, timeout):
 self.timeouts.append(timeout)
 self.clock.advance(0.25)
 if len(self.timeouts) == 1:
 raise TimeoutError("a transient failure before the deadline")
 return 200


clock = Clock()
call = EarlyTimeout(clock)
assert retry(call, clock, 5, lambda: 0.5) == ("success", 2)
assert clock.now == 1.0 and call.timeouts == [5, 4.25]
print("an early timeout can recover without resetting the shared deadline")

for method, status in (("POST", 503), ("GET", 400)):
 clock = Clock()
 call = ScriptedCall(clock, [(status, 0.25)])
 assert retry(call, clock, 5, lambda: 0.5, method) == ("not-retryable", 1)
clock = Clock()
call = ScriptedCall(clock, [(503, 0.25)] * 4)
assert retry(call, clock, 5, lambda: 0.5) == ("attempt-limit", 3)
assert len(call.timeouts) == 3
print("POST, permanent failure, and the total-attempt cap stop further work")

clock = Clock()
call = ScriptedCall(clock, [(503, 0.25)] * 7)
assert retry(call, clock, 100, lambda: 1.0, max_attempts=7) == ("attempt-limit", 7)
assert clock.now == 32.75 # Seven 0.25 calls plus waits 1, 2, 4, 8, 8, 8.
print("the exponential ceiling stops at 8 rather than growing without bound")

clock = Clock()
call = ScriptedCall(clock, [(503, 0.1)])
assert retry(call, clock, 0.5, lambda: 1.0) == ("wait-exceeds-budget", 1)
assert clock.now == 0.1 and len(call.timeouts) == 1
clock = Clock()
call = ScriptedCall(clock, [(503, 99)])
assert retry(call, clock, 0.5, lambda: 0.5) == ("deadline", 1)
assert clock.now == 0.5
clock = Clock()
call = ScriptedCall(clock, [])
assert retry(call, clock, 0, lambda: 0.5) == ("deadline", 0) and call.timeouts == []
print("a wait that cannot fit is abandoned; cooperative execution cannot consume a fresh budget per attempt")

rng = random.Random(7) # Repeatable samples for this experiment, not a production seed.
delays = [rng.random() for _ in range(100)]
bins = Counter(int(delay * 10) for delay in delays)
fixed_bins = Counter(int(1.0 * 10) for _ in range(100))
assert all(0 <= delay < 1 for delay in delays) and sum(bins.values()) == 100
assert max(bins.values()) < 100
assert max(fixed_bins.values()) == 100
print("first-retry 0.1-second-bin peak: fixed delay", max(fixed_bins.values()), "; full-jitter sample", max(bins.values()))

leaf_calls = 0


class Unavailable(Exception):
 pass


def nested(depth):
 global leaf_calls
 if depth == 0:
 leaf_calls += 1
 raise Unavailable
 for _ in range(3):
 try:
 return nested(depth - 1)
 except Unavailable:
 pass
 raise Unavailable


try:
 nested(3)
except Unavailable:
 pass
assert leaf_calls == 27
print("three retrying layers, each allowing three total attempts, invoke the failing leaf 27 times")

两次失败后成功，最终模型时间为 2.25。传给各次调用的超时依次缩短为五秒、4.25 秒和三秒，没有每次重新领取一份完整预算。额外用例确认提前超时仍能在同一预算内恢复；指数先封顶再计算，避免总尝试上限很大时先生成过大的幂。其他断言覆盖总尝试次数、八秒退避上限、永久错误、POST 不自动重放、放不进预算的等待，以及开始时就已经耗尽的期限。

一百个固定的首次重试延迟，集中在同一个 0.1 秒区间；可复现的完全抖动样本中，最拥挤区间只有十三个计划。这里比较的是计算出来的时间安排，不是实际网络到达时刻或成功吞吐量。固定种子只服务于实验复现，不应该拿它让生产客户端共享同一串随机安排。

最后，三层重试循环在最终失败前调用了二十七次最底层函数，故意展示放大效应，而不是推荐这种组织方式。更大范围的重试配额、服务端等待字段解析、真实定时器、传输取消、分布式时钟和生产延迟，都没有在这个模型里得到验证。

来源

AWS：指数退避与抖动，封顶退避、完全抖动公式与特定负载下的比较，已核验 2026-10-15。
Google SRE：处理过载，请求及客户端重试预算与重试责任归属，已核验 2026-10-15。
Google SRE：处理级联故障，重试次数放大、截止期限传递和取消，已核验 2026-10-15。
RFC 9110，幂等方法重试与 Retry-After 语义，已核验 2026-10-15。

熔断器阻止对故障服务的轰炸

Tue, 06 Apr 2027 00:00:00 +0000

熔断器决定的是一个新的调用，是否还应该到达看起来不健康的依赖。它可以立即拒绝，避免继续为很可能失败的请求投入资源，但不会修复依赖、取消已经运行的调用，也不能证明所有被拒工作本来都会失败。它是否有用，取决于真正实现的失败信号、作用域和恢复政策，而不只是有没有三个状态名称。

明确政策，而不只是画出状态

关闭表示允许调用通过，不代表每次调用都会成功；断开表示按照熔断政策拒绝新调用；半开则允许有限的试探工作，先取得一些恢复证据，再决定是否重新放行普通流量。不能把状态名字直接读成依赖的客观健康证明。

检测规则也不一定是滑动窗口内的失败百分比。Fowler 的示例统计失败，并在成功后重置；其他实现可能使用时间窗口、失败比例、慢调用阈值或最小样本数。应该明确当前使用的规则，而不是借用一张状态图，就默认阈值和统计方法已经确定。

下面的实验按完成顺序统计连续两次已分类失败，使用五秒冷却期，并且只允许一个半开探测。一次成功会把连续失败数清零。这些数字方便验证状态转移，不是生产配置建议；实际门槛需要结合故障形态与业务容忍度决定。

分类失败，并限定影响范围

调用方参数错误，不一定表示依赖已经宕机。需要确定哪些异常、状态码和慢结果应该影响熔断判断。本地直接拒绝的请求，也不同于已经到达依赖后失败的请求；如果把二者混在同一个失败统计里，熔断器可能不断用自己的拒绝强化拒绝状态。

状态应覆盖你真正想保护的故障范围。某个分片或操作不可用，不一定意味着其他独立提供方也应该被阻止。反过来，如果有成千上万个进程各自维护熔断器，每个都允许一个探测，总探测量仍可能很大。“只放一个半开请求”可能只是每实例一个，不是全局一个。

超时仍然不可缺少。一个永远不结束的调用，会占住连接或工作线程，却可能始终不产生足以触发熔断的完成结果。准入决定不能替代截止期限、并发上限和资源清理；等待结果所消耗的资源，也应进入实际验收范围。

恢复是一场受控试探

冷却时间结束后，应原子地占用探测名额。如果多个线程都先看见“现在可以试一下”，然后各自放行，所谓单探测就变成了一批突发请求。实验使用锁保护很短的状态修改，不会在依赖操作实际运行期间一直持有这把锁。

已经在途的旧调用，其结果如何处理也需要明确。这里进入新的断开阶段时会增加本地代次，旧许可对应的结果不能关闭这个较新的断开状态。代次只是模型内部的记账，不是分布式 fencing token，也没有能力撤销已经发生的远程工作。

探测失败会开始另一轮冷却，探测成功则关闭这个实验里的熔断器。但是，一次成功不证明依赖已经能够承接所有返回流量。如果需要逐步恢复，应该验证真实的流量准入政策，而不是认为只要存在“半开”状态，就必然实现了平滑放量。

坏掉的样子

阈值过于激进，会拒绝原本可以成功的请求；冷却过长，又会在依赖恢复后继续阻止调用。范围过大容易掩盖局部健康，而重试循环如果不停捕获断开异常，即使没有继续请求下游，也仍可能浪费本地资源，使故障路径消耗超出预期。

应分别观察转发调用、已分类结果、本地拒绝、状态变化和探测结果。测试持续失败、偶尔成功、并发争抢探测以及迟到的完成消息。一个计数器单测通过，并不证明真实依赖会安全恢复；需要沿着请求、资源占用和实际恢复流量继续检查。

快速验证

保存为 breaker_check.py，用 Python 3.10 以上版本执行 python3 breaker_check.py。实验已在 Python 3.14.4 上运行，只使用标准库。代码模拟结果，并注入表示单调时间的数值，不真实等待，也不访问服务；半开名额则由八个真实线程竞争，检查准入决定是否一起完成。

from concurrent.futures import ThreadPoolExecutor
from threading import Barrier, Lock


class OpenCircuit(Exception):
 pass


class Breaker:
 # Explicit fixture policy: two consecutive classified failures, five-second cooldown.
 def __init__(self):
 self.state, self.failures, self.until = "closed", 0, 0
 self.epoch, self.probe_busy = 0, False
 self.lock = Lock()

 def acquire(self, now):
 with self.lock:
 if self.state == "open":
 if now < self.until:
 raise OpenCircuit
 self.state = "half-open"
 if self.state == "half-open":
 if self.probe_busy:
 raise OpenCircuit
 self.probe_busy = True
 return self.epoch, True
 return self.epoch, False

 def complete(self, permit, succeeded, now):
 epoch, probe = permit
 with self.lock:
 if epoch != self.epoch:
 return # This outcome belongs to an earlier breaker generation.
 if probe:
 self.probe_busy = False
 self.epoch += 1
 self.failures = 0
 self.state = "closed" if succeeded else "open"
 if not succeeded:
 self.until = now + 5
 elif self.state == "closed":
 self.failures = 0 if succeeded else self.failures + 1
 if self.failures >= 2:
 self.state, self.until = "open", now + 5
 self.epoch += 1


breaker = Breaker()
other_dependency = Breaker()
forwarded = []


def invoke(succeeded, now):
 permit = breaker.acquire(now)
 forwarded.append(now) # A modeled dependency invocation, not a network call.
 breaker.complete(permit, succeeded, now)


invoke(False, 0)
assert breaker.failures == 1
invoke(True, 1)
assert breaker.failures == 0
late = breaker.acquire(1)
invoke(False, 2)
invoke(False, 3)
assert breaker.state == "open" and breaker.until == 8
other_permit = other_dependency.acquire(4)
other_dependency.complete(other_permit, True, 4)
assert other_dependency.state == "closed"
before = len(forwarded)
try:
 invoke(True, 7.99)
except OpenCircuit:
 pass
else:
 raise AssertionError("open circuit must reject before dispatch")
assert len(forwarded) == before
breaker.complete(late, True, 7.99)
assert breaker.state == "open"
print("success resets consecutive failures; two later failures open until time 8")
print("open calls are not dispatched; an older in-flight success does not close a newer open generation")

gate = Barrier(8)


def probe_attempt(_):
 gate.wait(timeout=5)
 try:
 return breaker.acquire(8)
 except OpenCircuit:
 return None


with ThreadPoolExecutor(max_workers=8) as pool:
 permits = list(pool.map(probe_attempt, range(8)))
admitted = [permit for permit in permits if permit is not None]
assert len(admitted) == 1 and admitted[0][1] is True
assert breaker.state == "half-open" and breaker.probe_busy
breaker.complete(admitted[0], False, 8)
assert breaker.state == "open" and breaker.until == 13
print("eight simultaneous half-open candidates receive one probe permit and seven refusals")
print("failed probe opens a new cooldown ending at time 13")

try:
 breaker.acquire(12.99)
except OpenCircuit:
 pass
else:
 raise AssertionError("second cooldown must still apply")
probe = breaker.acquire(13)
breaker.complete(probe, True, 13)
assert breaker.state == "closed" and not breaker.probe_busy
invoke(True, 14)
assert other_dependency.state == "closed" and other_dependency.failures == 0
print("a successful later probe closes this breaker; another dependency has separate state")

开始时的一次成功会清零失败数；后面两次失败让熔断器断开到时间八。在这之前发起调用，不会增加模拟下游调用记录。先前获准、后来才完成的成功结果，也不能关闭新一代的断开状态；另一依赖早已存在的熔断器仍然可以使用，没有被一并影响。

到时间八，八个同时到来的候选请求中只有一个获得许可，其余七个被拒绝。这个探测失败后，又开始一轮到时间十三结束的冷却。之后的探测成功，会让当前熔断器关闭，并恢复普通调用准入。断言检查的是这些明确的状态和许可变化。

模型要求每个获准调用都恰好报告一次已经分类的完成结果。真实传输超时、取消、自动错误分类、跨进程探测协调、库集成和恢复吞吐量没有在本例中测试。适合时应复用成熟实现，并依据实际工作负载验证它的精确契约，而不是将这个小模型当作完整生产熔断库。

来源

Martin Fowler：熔断器，失败计数、成功重置与试探恢复，已核验 2026-09-08。
Azure 架构：熔断器，状态语义、异常分类、并发与故障范围，已核验 2026-09-08。
Python 线程工具，并发许可实验使用的锁与同步屏障，已核验 2026-09-08。

错误预算是真预算

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, 25 Feb 2027 00:00:00 +0000

备用节点只有在提升路径可用、旧写者不能破坏新历史时才有价值。故障切换既是决策，也是流程与演练。副本看起来健康，不代表客户端能连上它，也不代表所有已确认写入都已经复制过去。先确定恢复时间目标与可接受的数据损失，再决定何时切换，而不是等报警响起才现场讨论。

提前设计好决定

确定谁有权批准提升、什么证据足以说明故障，以及由自动化还是操作员执行。心跳丢失可能是网络分区，而不是主库已经停止。故障检测本身不能授权两个独立写者。系统需要真正执行所有权边界的机制，例如经过确认的节点隔离，或存储端校验的 fencing，并使它与复制协议的保证相匹配。

单写者服务的安全目标是「最多一个被接受的写者」，并非每一瞬间都恰好有一个可用写者。隔离旧节点后、提升新节点前，暂时没有写者可能正是正确的停机选择。操作手册应写明候选节点、复制位置、可接受的丢失范围、客户端如何重连，以及前提不成立时由谁叫停。自动切换能缩短决策时间，却不能凭空补回尚未复制的数据。

演练真实经过的路径

根据风险决定演练频率，并在相关变更后重测。演练只能证明实际覆盖到的路径：绕过 DNS 的数据库提升不能验证地址缓存；测试客户端使用另一套身份，也不能证明生产权限正确。在安全前提下，加入真实的重连流程和已确认写入核对。记录范围、耗时、复制延迟、拒绝条件及恢复证据，不要把最近一次成功的日期当成完整的就绪评分。

开始前先安排安全停止点和恢复步骤。新主库一旦接受写入，切回旧节点往往就不再是撤销一项配置那么简单。旧主库可能需要对账或重建为副本，不能因为进程重新启动就恢复写权限。备份提供另一条恢复路径，但「有备份」本身也不等于已经验证能恢复。

坏掉的样子

旧主库在提升之后仍可写，就会产生脑裂。控制器里记录一句「已隔离」不够，存储或隔离机制必须真正阻止旧写入。落后的候选节点也可能在切换成功后丢失已确认写入。延迟阈值必须有明确单位，并与数据损失目标相连；允许非零延迟，不能同时宣称零数据丢失。

健康检查反复抖动会触发来回切换，应设置明确的故障判定和恢复条件，不要在重新同步之前自动切回。DNS 修改只影响后续查询：已有连接可能持续使用旧地址，按旧 TTL 缓存的回答也不会立刻消失。事故发生时调低 TTL，不能追溯缩短已经缓存的寿命。除了权威 DNS 的响应，还要验证真实客户端的重试、缓存和重连行为，否则控制台显示成功，用户路径仍可能失败。

快速验证

将下面内容保存为 failover_drill.py，在临时目录运行 python3 failover_drill.py。它只修改内存对象。健康状态和复制延迟是模拟值，fence() 只是更新集合，并不执行真实隔离。模型保留一个被指定的主节点，但隔离期间允许没有可写节点。候选节点通过检查后会被明确解除隔离，因此切回旧节点时不会出现「已经成为主库，却还留在隔离集合中」的自相矛盾状态。

"""Failover drill: single-primary switch with health and lag guards (stdlib only)."""
from dataclasses import dataclass

MAX_LAG = 128 # Synthetic units, not seconds or a zero-data-loss guarantee.

class FailoverRefused(Exception):
 pass

@dataclass
class Node:
 name: str
 healthy: bool = True
 lag: int = 0
 is_primary: bool = False

class Cluster:
 def __init__(self):
 self.nodes = {"a": Node("a", is_primary=True), "b": Node("b")}
 self.fenced: set[str] = set()

 @property
 def primary(self) -> str:
 primaries = [n for n in self.nodes.values() if n.is_primary]
 assert len(primaries) == 1, f"must keep exactly one primary, saw {[p.name for p in primaries]}"
 return primaries[0].name

 def can_write(self, name: str) -> bool:
 node = self.nodes[name]
 return node.is_primary and node.healthy and name not in self.fenced

 def health_check(self, name: str) -> bool:
 node = self.nodes[name]
 return node.healthy and node.lag <= MAX_LAG

 def fence(self, name: str) -> None:
 self.fenced.add(name)
 assert not self.can_write(name)

 def failover(self, target: str, *, fence_old: bool) -> str:
 old = self.primary
 if target == old:
 raise FailoverRefused("target is already primary")
 if target not in self.nodes:
 raise FailoverRefused(f"unknown target {target}")
 candidate = self.nodes[target]
 if not fence_old or old not in self.fenced:
 raise FailoverRefused(f"refuse: old primary {old} is not fenced; fence first to avoid split brain")
 if not candidate.healthy:
 raise FailoverRefused(f"refuse: standby {target} is unhealthy")
 if candidate.lag > MAX_LAG:
 raise FailoverRefused(f"refuse: standby {target} lags by {candidate.lag} (> {MAX_LAG})")
 self.nodes[old].is_primary = False
 # Model explicit reactivation after the old writer is fenced.
 self.fenced.discard(target)
 candidate.is_primary = True
 assert self.primary == target and self.can_write(target)
 assert sum(self.can_write(name) for name in self.nodes) <= 1
 return target

def expect_refused(fn, label: str) -> None:
 try:
 fn()
 except FailoverRefused as exc:
 print(f"refused as expected ({label}): {exc}")
 return
 raise AssertionError(f"should have refused: {label}")

def main() -> None:
 # 1. Clean drill: healthy standby, caught-up replica, old primary fenced.
 cluster = Cluster()
 assert cluster.primary == "a"
 assert cluster.health_check("b")
 cluster.fence("a")
 assert cluster.failover("b", fence_old=True) == "b"
 print("clean switch: a -> b")

 # 2. Refuse lag beyond this policy; even accepted positive lag may lose writes.
 cluster = Cluster()
 cluster.nodes["b"].lag = 900
 assert not cluster.health_check("b")
 cluster.fence("a")
 expect_refused(lambda: cluster.failover("b", fence_old=True), "stale replica")
 assert cluster.primary == "a"

 # 3. Unhealthy standby must not promote.
 cluster.nodes["b"].lag = 0
 cluster.nodes["b"].healthy = False
 expect_refused(lambda: cluster.failover("b", fence_old=True), "unhealthy standby")
 assert cluster.primary == "a"

 # 4. Unfenced old primary must block promotion (split-brain guard).
 cluster.nodes["b"].healthy = True
 unfenced = Cluster() # nobody fenced yet
 expect_refused(lambda: unfenced.failover("b", fence_old=False), "split brain")
 expect_refused(lambda: unfenced.failover("b", fence_old=True), "split brain without fence record")
 assert unfenced.primary == "a"

 # 5. Failback: resynchronize the candidate, then fence the CURRENT writer.
 cluster = Cluster()
 cluster.fence("a")
 cluster.failover("b", fence_old=True)
 cluster.nodes["a"].healthy = True
 cluster.nodes["a"].lag = 0
 cluster.fence("b")
 assert cluster.failover("a", fence_old=True) == "a"
 print("failback: b -> a")

 print("PASS: at most one writable node; 4 refusals + clean switch + failback passed")

if __name__ == "__main__":
 main()

输出包括一次正常切换、分属三类的四次拒绝，以及一次切回，最后为 PASS: at most one writable node; 4 refusals + clean switch + failback passed。拒绝提升会保留原有的主节点标记，但已经被隔离的旧主库仍不可写，并不代表服务自动恢复可用。正常切换与切回场景的延迟都是零；策略另外允许最多 128 个模拟单位的正延迟，这包含可能丢失数据的取舍，不应误读为真实数据库的推荐阈值。

旧版练习记录的环境是 macOS、Python 3.14.4；修订版在 Linux、Python 3.12.14 下通过断言。当前测试验证顺序执行的决策逻辑，也检查曾被隔离的目标节点是否真正恢复为可写。它不验证并发提升、真实复制、权限、DNS 传播、存储隔离或生产恢复。那些结论需要另外获准的预发布演练，使用实际机制和具有代表性的客户端；这个小模型不能替代它们。

来源

PostgreSQL 18：故障切换，旧主库隔离、重建冗余与书面切换流程，已核验 2026-10-15。
AWS：配置 DNS 故障切换，健康检查及路由配置，已核验 2026-10-15。
Google SRE：可靠性测试，生产测试范围、自动化防护与灾难恢复测试，已核验 2026-10-15。
AWS：记录 TTL，解析器缓存以及切换前的 TTL 调整，已核验 2026-10-15。

队列定义投递，消费者仍须保护副作用

Fri, 05 Feb 2027 00:00:00 +0000

队列的投递承诺只描述工作流程中的一段边界。消息到达消费者，与业务副作用已经提交，是不同事件。至少一次允许重复投递，至多一次则允许在不确定时丢失而不继续重试。仅凭这两个标签，不能保证订单、通知或数据库更新在所有故障下都恰好完成一次。可靠性需要沿真正的数据和确认路径逐步检查。

找到发布、确认与提交的位置

首先明确生产方何时知道 broker 已经接受消息、保留多久，以及持久化政策覆盖哪些故障。消息从未成功发布、超过保留期或被明确删除，都不会因为消费者自称至少一次就自动恢复。恢复前提必须与投递标签一起记录，否则“永不丢失”会遮住多个根本没有交给队列负责的环节。

消费方若先确认，再提交业务结果，就会形成丢失窗口：broker 停止重试时，应用可能还没完成工作。先提交又留下另一种窗口：结果已成功，但确认丢失，工作于是重新出现。这个重复仍然符合投递契约，并不意味着最初操作失败。排查时要分别检查业务结果与确认结果，不能用其中一个推断另一个。

可见性超时与确认期限控制的是何时允许下一次尝试，不证明第一个工作进程已经停止。慢处理者可以与重投后的处理者同时运行，因此延长期限与防止重复副作用解决的是不同问题。应同时记录投递尝试和已经提交的业务结果，而不是只统计消费者调用次数，便把它当作成功执行次数。

在真正的事务边界内消除重复效果

若副作用都位于同一个事务数据库，可以把唯一操作身份与业务结果放进同一事务。唯一性检查必须能够裁决并发尝试，单独读取再无保护地写入并不够。还需要保存足够的载荷信息，识别“同一身份却携带不同指令”的情况，不能看到编号重复就无条件接受。这既是去重问题，也是操作身份的契约问题。

数据库事务不会自动包住外部邮件、支付接口或另一套独立存储。这些目标需要自己的幂等或协调契约。本地标记先写、远端调用后做，可能丢失效果；标记后写，则可能留下重复窗口。因此，本地去重表不能被说成端到端恰好一次保证。只有明确哪些动作一起提交、哪些动作仍独立失败，设计才有可检查的边界。

有些服务确实提供带明确范围的恰好一次投递能力，例如 Google Pub/Sub 说明了地域、订阅类型等限制，也区分投递重复与发布侧重复。应阅读具体契约，不应宣称这个能力不可能存在，也不能把它推广成所有下游副作用都已解决。多个已发布消息代表同一业务意图时，稳定业务身份仍然有独立价值。

坏掉的样子

持续失败的消息可能阻塞有序进度，过短期限则可能让本来正常的任务出现重叠尝试。重投计数能提供调查线索，却不能唯一判断是毒数据、慢依赖、确认丢失还是工作进程停滞。应关联消息身份、载荷、异常、处理时长和确认记录，再决定怎样修改重试政策。只根据“一条还是多条计数升高”断言根因，很容易修错位置。

需要限制重试并说明隔离失败如何审阅或重新执行。进入死信队列只是移动未完成工作，并没有完成它。去重记录的保存期限必须覆盖计划容忍的重放范围，删除身份记录之后，旧请求可能再次生效；永远保存又有存储和隐私代价。这里没有适用于所有任务的统一选择，应把保留与重放规则一起设计。

快速验证

保存为 delivery_guarantee_probe.py，使用 Python 3 运行。本次在 Python 3.12.14 与 SQLite 3.53.1 上通过。实验验证真实事务消费落点，而不是模拟 broker：临时数据库同时保存操作身份和一个无害数字总计，不会对任何账户扣款，也不向外发送消息。只有本程序自己的临时文件会被创建和清理。

from contextlib import closing
from pathlib import Path
from tempfile import TemporaryDirectory
import sqlite3


def apply(db, message_id, amount, interrupt=False):
 db.execute('BEGIN IMMEDIATE')
 try:
 prior = db.execute('SELECT amount FROM inbox WHERE id=?', (message_id,)).fetchone()
 if prior is not None:
 if prior[0] != amount:
 raise ValueError('same identity, different payload')
 db.commit()
 return False
 db.execute('INSERT INTO inbox VALUES (?, ?)', (message_id, amount))
 db.execute('UPDATE totals SET amount=amount+? WHERE id=1', (amount,))
 if interrupt:
 raise RuntimeError('controlled failure before commit')
 db.commit()
 return True
 except BaseException:
 db.rollback()
 raise


with TemporaryDirectory(prefix='queue-sink-') as directory:
 path = Path(directory) / 'sink.db'
 with closing(sqlite3.connect(path, isolation_level=None)) as db:
 db.execute('CREATE TABLE inbox(id TEXT PRIMARY KEY, amount INTEGER NOT NULL)')
 db.execute('CREATE TABLE totals(id INTEGER PRIMARY KEY, amount INTEGER NOT NULL)')
 db.execute('INSERT INTO totals VALUES (1, 0)')
 try:
 apply(db, 'work-1', 100, interrupt=True)
 except RuntimeError:
 pass
 else:
 raise AssertionError('controlled failure did not occur')
 assert db.execute('SELECT count(*) FROM inbox').fetchone() == (0,)
 assert db.execute('SELECT amount FROM totals').fetchone() == (0,)
 assert apply(db, 'work-1', 100)
 assert apply(db, 'work-2', 50)
 # Close and reopen the real database rather than retaining an in-memory set.
 with closing(sqlite3.connect(path, isolation_level=None)) as db:
 assert not apply(db, 'work-1', 100)
 try:
 apply(db, 'work-1', 999)
 except ValueError:
 pass
 else:
 raise AssertionError('conflicting payload reused the same identity')
 assert db.execute('SELECT count(*) FROM inbox').fetchone() == (2,)
 assert db.execute('SELECT amount FROM totals').fetchone() == (150,)
 assert not db.in_transaction
 print('rollback kept marker and effect together; reopened retry changed nothing; total=150')

两项写入之后主动抛出的异常，会让身份标记与总计一起回滚。随后重试，提交两项操作；关闭并重新打开数据库后，重复第一项身份不会改变结果，而用不同数额复用相同身份会报错。最终数据库有两个身份，总计为一百五十，并且连接不在事务中。这个检查比只把编号放进内存集合更能说明持久化边界。

这里验证的是 SQLite 落点中的回滚、关闭连接后重新打开仍保留已提交状态，以及重复处理。实验没有终止进程，没有模拟断电，没有运行并发消费者，也没有验证 broker 的发布、重投与确认。要作更广泛的投递承诺，仍须使用目标服务单独验证这些环节，不能把本地去重成功当成整个消息系统已经验收。

来源

Amazon SQS 标准队列，至少一次投递与重复处理，已核验 2026-10-15。
Amazon SQS 可见性超时，重试资格与重复边界，已核验 2026-10-15。
Google Pub/Sub 恰好一次投递，范围限定与发布侧重复，已核验 2026-10-15。
SQLite 事务，显式事务、提交与回滚，已核验 2026-10-15。

幂等键是客户端的承诺

Wed, 20 Jan 2027 00:00:00 +0000

幂等键命名的是一次预期行动，不是一次网络投递尝试。服务支持这项契约时，客户端在结果不明确后重试同一个行动，应该继续发送同一个键。每次重试都生成新键，实际是在告诉服务器“这是另一次行动”，因此完全可能合理地产生第二份业务效果。客户端必须先把行动身份与尝试次数分开。

创建一次，在后续尝试中保留

在第一次发送之前生成键，并把它与操作参数、目标一起保存。如果后台任务可能在客户端重启后恢复，任务记录也需要保留这个身份。仅把键放在临时网络连接或一次调用栈中，无法可靠地把后续尝试关联回原来的意图，恢复程序也不应临时猜一个替代值。

真正的新行动应该使用新键，即使参数与之前的购买完全一样。仅用正文哈希无法区分“再买一次同样的东西”和“重试第一次购买”。键与请求指纹承担不同职责：键标记行动，指纹检查是否发生了不兼容的复用。把二者合并，既可能漏去重，也可能错误阻止合理的新操作。

键的格式和作用域应遵循服务提供方的契约。Stripe 建议使用 UUIDv4 等随机标识，并提醒不要把敏感数据放进键中。键不是认证凭据，拥有某个键也不能代替访问已存结果所需的授权。不要把 bearer 凭据、邮箱或个人信息塞进用于关联请求的标识。

接收方必须真正实现这份承诺

只加一个 Idempotency-Key 请求头，不会自动实现去重。服务端必须在明确契约下识别它，说明比较哪些参数、保留哪些结果、执行尚未完成时如何处理重复请求，以及记录会保存多久。这些都是服务行为，不能从客户端看见一个字段名就推断已经具备。

Stripe API v1 记录的是首次进入执行阶段的请求状态码与正文，包括 500 响应。如果参数验证失败，或与正在执行的请求发生冲突，而端点执行尚未开始，则不会保存对应幂等结果。因此，“重复请求必须等待第一份结果”并不是所有 API 都必须采用的通用规则，调用方要处理实际的在途冲突语义。

Stripe API v2 则可能继续尝试失败或部分失败的工作，并返回更新后的结果；不能把 v1 的原响应保存规则直接套到 v2。不同提供方也不保证逐字重放响应。EC2 文档说明，成功重试不会再次执行行动，但返回结果可以包含更新后的创建状态等信息。RFC 9110 定义的是预期效果；具体服务是否复用原始响应字节，是叠加在其上的另一层契约，不能把两者当成同一要求。

让键的含义保持稳定

同一个键被配上不兼容的参数时，应按照服务明确的错误规则处理，而不是静默创建另一项操作，或覆盖原先保存的结果。JSON 字段顺序、默认值、数字表示和省略字段，都可能影响比较。一个小例子能规范化某种输入，不代表已经解决任意正文的语义等价问题。

下面的实验只接受一个商品字符串和一个正整数量。将这两个字段排序，定义了它自己的比较规则，并不是通用 JSON 等价算法。示例用 409 表示参数冲突，也是测试接口的政策，不是每一家幂等 API 都保证返回的状态码。

坏掉的样子

超时不能证明操作没有执行。使用新键重试，可能把一次已经成功但丢了响应的购买变成两次。为了绕过已保存的错误而换键，也可能在原行动结果仍不明时额外启动工作。应该按照服务文档给出的恢复路径核对原行动，而不是用新身份掩盖不确定性。

保留期同样限制承诺范围。Stripe API v1 允许在键至少保存二十四小时后清理，并将清理后的同键请求视为新请求；这既不是永久保存身份，也不是适用于所有服务的精确过期定时器。客户端的恢复窗口必须与实际保留契约一致，不能只考虑立即发生的重试。

快速验证

保存为 intent_check.py，用 Python 3.10 以上版本执行 python3 intent_check.py。实验已在 Python 3.14.4 上运行，只使用标准库。代码在临时目录中写入一份行动记录，再读回，退出时清理目录。API 与响应丢失都是明确的顺序模拟，不会发送网络请求，也不会连接真实支付服务。

import json
from pathlib import Path
from tempfile import TemporaryDirectory
from uuid import uuid4


def new_intent(parameters):
 return {"key": str(uuid4()), "parameters": dict(parameters)}


class FixtureAPI:
 # One already authenticated scope, sequential execution, no network service.
 def __init__(self):
 self.saved = {}
 self.orders = []
 self.attempts = []

 def execute(self, intent):
 key, parameters = intent["key"], intent["parameters"]
 self.attempts.append(key)
 if (set(parameters) != {"product", "quantity"}
 or not isinstance(parameters["product"], str) or not parameters["product"]
 or type(parameters["quantity"]) is not int or parameters["quantity"] < 1):
 return 400, '{"error":"invalid parameters"}'
 fingerprint = json.dumps(parameters, sort_keys=True, separators=(",", ":"))
 if key in self.saved:
 original, response = self.saved[key]
 return response if original == fingerprint else (409, '{"error":"key reused with other parameters"}')
 self.orders.append(dict(parameters))
 response = (201, json.dumps({"order_id": len(self.orders)}, separators=(",", ":")))
 self.saved[key] = (fingerprint, response)
 return response


def deliver(api, intent, lose_response=False):
 response = api.execute(intent)
 if lose_response:
 raise TimeoutError("simulated response loss after the fixture saved its result")
 return response


api = FixtureAPI()
parameters = {"product": "notebook", "quantity": 2}
intent = new_intent(parameters)

with TemporaryDirectory(prefix="idempotency-intent-") as directory:
 record = Path(directory) / "intent.json"
 with record.open("x", encoding="utf-8") as stream:
 json.dump(intent, stream)
 try:
 deliver(api, intent, lose_response=True)
 except TimeoutError:
 pass
 else:
 raise AssertionError("expected simulated response loss")
 assert len(api.orders) == 1
 with record.open(encoding="utf-8") as stream:
 recovered = json.load(stream)
 assert recovered == intent
 first_known_result = deliver(api, recovered)
 assert first_known_result == (201, '{"order_id":1}')
 assert deliver(api, recovered) == first_known_result
 assert len(api.orders) == 1 and api.attempts[:3] == [intent["key"]] * 3
 print("one persisted intent survives serialization and three attempts produce one order")

 reordered = {"key": intent["key"], "parameters": {"quantity": 2, "product": "notebook"}}
 assert deliver(api, reordered) == first_known_result
 changed = {"key": intent["key"], "parameters": {**parameters, "quantity": 3}}
 assert deliver(api, changed)[0] == 409 and len(api.orders) == 1
 assert deliver(api, recovered) == first_known_result
 print("equivalent field ordering replays; changed parameters conflict without replacing the saved result")

 mistaken_retry = new_intent(parameters)
 assert mistaken_retry["key"] != intent["key"]
 assert deliver(api, mistaken_retry) == (201, '{"order_id":2}')
 assert len(api.orders) == 2
 print("generating a new key for an uncertain retry creates a second order")

 invalid = new_intent({"product": "notebook", "quantity": 0})
 assert deliver(api, invalid)[0] == 400
 assert invalid["key"] not in api.saved and len(api.orders) == 2
 corrected = {**invalid, "parameters": {"product": "notebook", "quantity": 1}}
 assert deliver(api, corrected) == (201, '{"order_id":3}')
 assert len(api.orders) == 3
 print("this fixture does not save pre-execution validation failures; the corrected request can execute")

测试先保存第一次操作结果，再模拟超时。读回保存的行动并继续使用原键，三次尝试只生成一笔订单。字段顺序变化仍重放同一结果，数量改变则发生冲突，而且原结果没有被替换。如果把不确定的重试换成新键，就会创建第二笔订单，直接展示错误客户端行为的后果。

这个测试接口不会保存执行前的参数验证失败，因此修正非法数量后，仍可用尚未执行过的那个键发起操作。这只展示已经声明的政策，不能理解为对已经执行的请求也可以随意修改参数。应先区分是否进入执行阶段，再应用具体服务的规则。

文件往返验证的是序列化后身份仍然保留，并没有启动新的客户端进程，也不证明客户端存储能抵抗崩溃。持久化服务端记录、并发执行、真实传输丢失与提供方 API 都没有在本例中验收。把应用部署称为可安全重试之前，仍需验证这些真实边界。

来源

Stripe：幂等请求，稳定键、API v1 的结果保留与执行前失败，以及 API v2 差异，已核验 2026-10-15。
EC2 API 幂等性，客户端令牌语义与可反映更新状态的结果，已核验 2026-09-08。
RFC 9110，9.2.2 节定义预期效果与非幂等方法重试条件，已核验 2026-09-08。

优雅关闭：停止准入，再排空工作

Sat, 19 Dec 2026 00:00:00 +0000

优雅关闭改变的是服务接收与完成工作的方式，信号只是触发条件。它能够提供的保证比“绝不丢失任何东西”更有限，也更具体：停止接收新的业务工作，记录此前已经接受的任务，在有界时间内等待完成，并在期限耗尽时如实报告剩余工作。仅仅捕获一个信号，并不等于已经实现安全关闭。

信号开始的是协调过程

应用可以处理 SIGTERM，然后启动自己的关闭流程；SIGKILL 则不能捕获、阻塞或忽略。首先应确认谁真正收到了停止信号：如果外层包装进程收到信号却不转发，内部工作进程即使安装了正确的处理器，也可能根本没有机会执行它。

信号处理器应保持简短。Python 在主解释器的主线程执行信号处理函数，并明确警告不要在其中使用同步锁。实验只设置一个标记，把修改就绪、关闭准入和等待任务的工作留给普通控制流程，不在信号处理器里执行网络操作或等待工作线程。

应该尽早撤下就绪，让路由变更开始传播，但本地业务准入仍需要独立闸口，因为已有连接和传播延迟都可能带来后续请求。关闭闸口与登记已经接受的任务，必须使用一致的边界；否则看似已经停止接收，实际上却可能漏记同时进入的新任务。

截止期限约束完整生命周期

任务应一直记账到真正的完成点。调用方等待超时，不证明工作线程已经停止；响应已经发送，也不证明业务事务已经持久化。应根据操作契约选择完成边界，而不是把任意一次连接关闭都解释成成功，更不能仅凭客户端离开就提前回收在途任务。

进程内的经过时间应由单调时钟计算，并在监督器实际允许的时间内为清理留出余量。期限到达后，对剩余工作必须有明确的取消、放弃或可靠移交政策。从等待循环里跳出来，本身不会终止正在运行的线程，也不会撤销已经执行的业务效果。

正常排空和未完整关闭，应在记录中保持可区分。某个非零退出码是服务自身的约定，不是能够保证正确恢复的通用规则。客户端没有拿到响应时，仍可能需要根据幂等契约或业务记录确认结果，不能仅凭服务正在关闭就断言重试一定安全。

与监督器核对同一份契约

systemd 的 TimeoutStopSec 管理配置中的停止命令等待和服务停止等待；KillMode 选择被终止的进程范围，不决定排空能持续多久。mixed 模式首先向主进程发送终止信号，最后的强制终止覆盖控制组内剩余进程；主进程提前退出，也可能触发这一升级。真实 unit 中的停止钩子和通知延长机制必须一起检查。

Kubernetes 在执行已配置的 preStop 钩子之前，就开始计算终止宽限时间，钩子不是额外领取另一份独立预算。EndpointSlice 的终止状态更新与本地关闭同时推进，并不是完成一次全局同步屏障后，从此再也不会有请求到达。因此，端点变更不能替代应用自己的准入判断。

实际停止信号也可能受到镜像或运行时配置影响。应测试部署中的进程树和停止约定，而不是把本地直接执行程序的结果扩大为容器、sidecar 与代理协调全部正确的证据。这些组件各自的关闭顺序和宽限时间，需要沿真实调用链核对。

坏掉的样子

一个只修改就绪状态的关闭标记，可能让已有的持久连接继续不断提交新工作；反过来，立即切断全部活动连接，又会丢掉原本有时间完成的请求。停止新的业务准入，与完成已经获准的工作，是两个需要分别控制和观察的决定。

无界等待线程可能超过监督器允许的时长。守护线程允许进程退出时不等待它们，但这意味着放弃，不等于安全取消或事务回滚。库自身也有关闭契约：Python socketserver 的 shutdown 必须从不同于 serve_forever 的线程调用，否则会造成死锁，关闭路径反而永远无法结束。

应同时观察接受、完成、拒绝和未完成的工作，以及关闭耗时和退出结果。只记录一个“退出成功”，却不区分这些数量，可能掩盖真正丢掉的任务。验收对象应该是完整生命周期，而不是那一行信号注册代码或某个看起来正常的退出状态。

快速验证

保存为 shutdown_check.py，在类 Unix 系统上用 Python 3.10 以上版本执行 python3 shutdown_check.py。实验已在 macOS、Python 3.14.4 上运行。每种情况都创建自己的子进程和回环 HTTP 服务，SIGTERM 只发给该子进程；POST release 路由仅用于测试协调，不是建议上线的管理接口。

from concurrent.futures import ThreadPoolExecutor
from http.client import HTTPConnection, RemoteDisconnected
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer
import json
import selectors
import signal
import subprocess
import sys
from threading import Condition, Event, Thread
import time


def child(grace):
 state = {"draining": False, "active": 0}
 condition, release = Condition(), Event()
 stop_requested = False

 def stop(signum, frame):
 nonlocal stop_requested
 stop_requested = True # No lock, I/O, or shutdown call in the signal handler.

 class Handler(BaseHTTPRequestHandler):
 def log_message(self, *args):
 pass

 def reply(self, status, value):
 body = json.dumps(value).encode()
 self.send_response(status)
 self.send_header("Content-Type", "application/json")
 self.send_header("Content-Length", str(len(body)))
 self.send_header("Cache-Control", "no-store")
 self.end_headers()
 self.wfile.write(body)

 def do_GET(self):
 if self.path == "/state":
 with condition:
 snapshot = dict(state)
 self.reply(200, snapshot)
 elif self.path == "/readyz":
 with condition:
 ready = not state["draining"]
 self.reply(200 if ready else 503, {"ready": ready})
 elif self.path == "/work":
 with condition:
 admitted = not state["draining"]
 if admitted:
 state["active"] += 1
 if not admitted:
 self.reply(503, {"error": "draining"})
 return
 try:
 if release.wait(timeout=5):
 self.reply(200, {"done": True})
 else:
 self.reply(503, {"error": "fixture-timeout"})
 finally:
 with condition:
 state["active"] -= 1
 condition.notify_all()
 else:
 self.reply(404, {"error": "not-found"})

 def do_POST(self):
 if self.path == "/release": # Loopback-only test coordination, not workload admission.
 self.reply(200, {"released": True})
 release.set() # Finish the control reply before work can complete and the child exits.
 else:
 self.reply(404, {"error": "not-found"})

 signal.signal(signal.SIGTERM, stop)
 server = ThreadingHTTPServer(("127.0.0.1", 0), Handler)
 server.daemon_threads = True # Explicitly permits abandonment in the deadline case.
 serving = Thread(target=server.serve_forever, kwargs={"poll_interval": 0.01})
 serving.start()
 print(json.dumps({"port": server.server_port}), flush=True)
 while not stop_requested:
 time.sleep(0.005)
 deadline = time.monotonic() + grace
 with condition:
 state["draining"] = True
 while state["active"] and time.monotonic() < deadline:
 condition.wait(timeout=max(0, deadline - time.monotonic()))
 unfinished = state["active"]
 server.shutdown() # Called outside the thread running serve_forever.
 serving.join(timeout=2)
 server.server_close() # Does not wait for daemon request threads.
 assert not serving.is_alive()
 print(json.dumps({"unfinished": unfinished, "deadline_expired": unfinished > 0}), flush=True)
 return 3 if unfinished else 0 # Fixture policy, not a universal exit-code convention.


def request(port, route, method="GET"):
 connection = HTTPConnection("127.0.0.1", port, timeout=3)
 try:
 connection.request(method, route)
 response = connection.getresponse()
 return response.status, json.loads(response.read())
 finally:
 connection.close()


def wait_state(port, predicate):
 deadline = time.monotonic() + 3
 while time.monotonic() < deadline:
 status, state = request(port, "/state")
 assert status == 200
 if predicate(state):
 return state
 time.sleep(0.01)
 raise AssertionError("child did not reach the expected state")


def exercise(finish):
 process = subprocess.Popen(
 [sys.executable, __file__, "child", "3" if finish else "1"],
 stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True,
 )
 try:
 with selectors.DefaultSelector() as selector:
 selector.register(process.stdout, selectors.EVENT_READ)
 assert selector.select(timeout=5), "child did not announce its local port"
 port = json.loads(process.stdout.readline())["port"]
 assert request(port, "/readyz") == (200, {"ready": True})
 with ThreadPoolExecutor(max_workers=1) as pool:
 active = pool.submit(request, port, "/work")
 wait_state(port, lambda state: state["active"] == 1)
 process.send_signal(signal.SIGTERM)
 wait_state(port, lambda state: state["draining"])
 assert request(port, "/readyz") == (503, {"ready": False})
 assert request(port, "/work") == (503, {"error": "draining"})
 assert request(port, "/state")[1]["active"] == 1
 if finish:
 assert request(port, "/release", "POST")[0] == 200
 assert active.result(timeout=4) == (200, {"done": True})
 output, errors = process.communicate(timeout=5)
 assert errors == ""
 record = json.loads(output)
 assert process.returncode == (0 if finish else 3)
 assert record == {"unfinished": 0 if finish else 1, "deadline_expired": not finish}
 if not finish:
 try:
 active.result(timeout=4)
 except (OSError, RemoteDisconnected):
 pass
 else:
 raise AssertionError("abandoned work must not report a successful reply")
 print("completed drain" if finish else "expired drain", record, "exit", process.returncode)
 finally:
 if process.poll() is None:
 process.kill() # Safety cleanup targets only this fixture's child.
 process.wait(timeout=5)
 process.stdout.close()
 process.stderr.close()


if __name__ == "__main__":
 if sys.argv[1:2] == ["child"]:
 raise SystemExit(child(float(sys.argv[2])))
 exercise(True)
 exercise(False)

两个场景都在 SIGTERM 之前接受一个请求。排空标记可见后，就绪返回 503，新的业务请求也得到 503，而先前获准的请求仍然计入在途工作，没有因为开始关闭就被假装清零。断言比较的是这些真实 HTTP 响应与子进程状态。

释放原请求后，它先收到 200，子进程再以零退出，并报告没有未完成工作。如果不释放，当前实验的一秒排空预算会耗尽；子进程报告一个未完成请求，以三退出，等待中的客户端拿不到成功响应。退出三只是这份实验明确选择的结果约定。

后一个场景刻意演示退出时放弃守护线程，不证明协作式取消、持久化、SIGKILL 清理或安全重放。实验没有运行 systemd unit、部署 Kubernetes 工作负载、执行真实事务或施加生产流量；这些更强保证不能从本机关闭结果中直接推导。

来源

Linux signal(7)，终止信号与 SIGKILL 不可捕获的边界，已核验 2026-09-09。
Python 信号，主线程信号处理及处理器内禁止使用锁的警告，已核验 2026-09-09。
Python socketserver，关闭调用的线程要求及守护请求线程行为，已核验 2026-09-09。
systemd.service，TimeoutStopSec 的停止等待与通知延长机制，已核验 2026-09-09。
systemd.kill，KillMode 进程范围与终止升级，已核验 2026-09-09。
Kubernetes：Pod 生命周期，preStop、终止宽限、停止信号与 EndpointSlice 变化，已核验 2026-09-09。

fsync 在更新协议中完成存储同步请求

Fri, 27 Nov 2026 00:00:00 +0000

普通 write(2) 成功，可以让实际接受的字节通过内核文件状态被访问，但本身不能建立崩溃持久性。fsync 请求同步文件数据及相关元数据，并等待存储栈报告完成。它是更新协议中的一个操作，仍需要正确顺序、错误检查、目录项处理和底层真实保证。不能只在代码里出现一次 fsync，就推断整个更新已经具有完整事务与恢复语义。

坏掉的样子

用户态缓冲还形成更早一层边界。语言缓冲区尚未把字节提交给内核时，对描述符调用 fsync 无法同步这些字节。应先 flush 缓冲，并检查两个阶段的错误。普通 write 也可能只完成部分写入，延迟存储错误则可能在同步时才出现，而不是在最初写入时报告，因此每层返回结果都需要按契约处理。

同步新建文件，不一定同步命名它的目录项。在 Linux 上，持久创建或替换协议还需要适当的目录同步。原子 rename 提供运行期间的命名空间可见性保证，却不会独立证明目录变化能够经历崩溃保留。当前打开新路径能读到数据，与重启后仍能通过该名字找到预期对象，是不同问题。

fdatasync 不意味着完全不处理元数据。它同步数据，以及后续正确读取数据所需的元数据，包括变化后的文件长度；对于读取不必需的其他元数据更新，则可以省略。把它理解为与 fsync 在所有方面相同，或者完全无视元数据，都会掩盖选择两者的真正依据，应根据应用需要保持的状态理解同步范围。

快速验证

把脚本保存为 syncfile.py，在装有 Python 和 strace 的一次性 Linux 系统中运行 python3 syncfile.py。临时目录必须支持普通文件和目录同步。实测使用 Linux 6.12.76、Python 3.11.2、strace 6.1 和 ext4 卷。样本检查真实调用与运行结果，不会切断存储电源：

from pathlib import Path
from tempfile import TemporaryDirectory
import subprocess,sys

program=r'''
from pathlib import Path
import errno,os,sys
root=Path(sys.argv[1]);current=root/'current';candidate=root/'candidate'
current.write_bytes(b'old');old=current.open('rb')
try:
 with candidate.open('wb') as handle:
 handle.write(b'new');handle.flush();os.fsync(handle.fileno())
 os.replace(candidate,current)
 directory=os.open(root,os.O_RDONLY|os.O_DIRECTORY)
 try:os.fsync(directory)
 finally:os.close(directory)
 assert current.read_bytes()==b'new' and old.read()==b'old'
 with current.open('ab') as handle:
 handle.write(b'-extended');handle.flush();os.fdatasync(handle.fileno())
 assert current.read_bytes()==b'new-extended' and current.stat().st_size==12
 read_end,write_end=os.pipe()
 try:
 try:os.fsync(write_end)
 except OSError as error:assert error.errno==errno.EINVAL
 else:raise AssertionError('fsync on a pipe unexpectedly succeeded')
 finally:os.close(read_end);os.close(write_end)
finally:old.close()
print('replacement content, old open reference, appended length, and unsupported-pipe error verified')
'''
with TemporaryDirectory(prefix='xbcatm-fsync-') as directory:
 root=Path(directory);trace=root/'trace'
 result=subprocess.run(['strace','-yy','-s','200','-e','trace=%file,write,fsync,fdatasync','-o',str(trace),'--',sys.executable,'-c',program,str(root)],capture_output=True,text=True,timeout=10)
 assert result.returncode==0,result.stderr
 lines=trace.read_text().splitlines()
 file_sync=next(i for i,line in enumerate(lines) if 'fsync(' in line and str(root/'candidate') in line and '= 0' in line)
 rename=next(i for i,line in enumerate(lines) if line.startswith('rename') and str(root/'current') in line and '= 0' in line)
 directory_sync=next(i for i,line in enumerate(lines) if 'fsync(' in line and '<'+str(root)+'>' in line and '= 0' in line)
 assert file_sync<rename<directory_sync
 assert any('fdatasync(' in line and str(root/'current') in line and '= 0' in line for line in lines)
 print(result.stdout,end='')
 for line in lines:
 if line.startswith(('fsync(','fdatasync(','rename')):print(line)
 print('syscall order verified: flush data, fsync candidate, replace name, fsync parent directory')

子进程创建内容为 old 的当前文件，并保留一份打开读取引用。然后把 new 写入独立候选文件，flush Python 缓冲，再对候选描述符调用 fsync。候选文件位于同一个目录，也使此实验的后续 rename 保持在同一文件系统内，不依赖跨挂载复制等不同操作来模拟替换。

接着替换当前路径，并同步包含它的目录描述符。追踪断言顺序为：候选文件 fsync 成功，rename 成功，父目录 fsync 成功。这些是实际观察到、且检查了返回值的系统调用，不是仅凭注释声明已经遵守同步顺序。程序意图和真实执行之间的对应关系，可以从保留的追踪中核对。

读取当前路径得到 new，先前打开的引用却仍读到 old。这区分原子名字替换与修改全部既有引用：旧引用继续指向原来文件对象，不会因为同名路径换成新文件就自动转移。需要读取新版本的消费者，仍应根据应用发布协议选择对象，不能假定手里已有的句柄会始终代表路径最新状态。

之后子进程追加 extended 后缀，flush 缓冲，再执行 fdatasync。最终内容为 new-extended，长度十二，实际覆盖了文件长度改变后的成功数据同步。这与后续读取所需元数据不能被简单忽略的契约一致，而不是只在内容长度不变的最简单情况里验证调用能够返回。

最后对管道调用 fsync，得到 EINVAL。脚本检查真实失败，没有把任意描述符都当作可同步的普通文件；清理时关闭全部句柄。追踪证明本地内核接受了相应文件与目录请求，却不能独立证明某台物理设备在断电时正确兑现刷新。接口行为与底层故障保证，需要按证据范围分别描述。

定义可以确认提交的边界

应明确哪次更新必须保留，以及读取者允许观察什么。单文件替换中，发布前同步候选，发布后同步受影响目录；跨目录移动还需要考虑两边目录更新。跨文件系统移动采用不同机制，不能假定方便的 rename 协议可以原样适用。更新范围决定哪些对象和命名关系需要被纳入提交边界。

同步失败时，不应报告持久更新已提交。之前写入或 rename 可能已经生效，因此失败不是自动回滚。应保留足够的事务或版本信息，判断实际状态，并按应用契约恢复。fsync 本身不会把多个文件的一系列变化变成单个原子事务，也不会替代应用对于中间状态的处理设计。

应用契约允许时，可以让多项操作共享提交边界，以降低同步成本，但确认应在所需边界成功后发出。还需要在真实存储栈验证崩溃恢复，包括文件系统和设备缓存行为。虚拟化实验中成功的系统调用追踪，可以证明接口执行，却不能替所有下层组件证明各自的故障保证。

来源

fsync(2)，文件目录同步、fdatasync 元数据与错误，已核验 2026-09-12。
rename(2)，原子路径替换与既有打开引用，已核验 2026-09-12。
write(2)，缓冲写入完成、部分写入与延迟错误，已核验 2026-09-12。

限流需要一个稳定的客户端标识

Thu, 29 Oct 2026 00:00:00 +0000

限流键定义了哪些请求共用一份预算。账号、API 凭据、地址、租户和已认证会话是不同身份，不是“客户端”的几种可互换写法。选错归组方式，可能让无关用户相互挤占额度，也可能让同一份工作只改一个字段，就拿到新的使用机会。

使用政策真正承诺的身份

如果规则是按账号限流，就应从认证结果中取得账号，而不是相信调用方提交的账号请求头或查询参数。仅仅看见一个凭据，并不能证明它有效；认证层必须先验证凭据、解析主体，再让账号级准入决定使用这个结果。限流键的可信程度不能高于它的来源。

按凭据限流也可以是合理的产品契约，但行为与按账号限流不同。轮换凭据或再创建一份凭据，可能得到新的凭据键，却仍属于同一个账号。应先决定这是否应当带来新额度，而不是等出现滥用或投诉后，才发现实现按的身份与产品描述并不一致。

一个账号不一定只对应一个人或一个应用，一个人也可以拥有多个账号。稳定账号键改善的是归组的一致性，并不证明公平，不阻止批量养号，也不限制整个服务的总需求。其他层级的限制应由明确需求支持，不能认为“已经按账号计数”就涵盖所有容量风险。

地址表示的是网络路径

企业 NAT、运营商网络或 VPN 后面的多个账号，可能共用一个公网地址；按 IP 的桶会把它们的流量合在一起。反过来，更换地址的调用方可能进入一个新桶。这两种结果并不说明地址解析错误，而是说明网络地址与业务主体本来就在表示不同对象。

没有已验证账号的公开接口或认证前入口，仍可以用地址级限制保护资源。但应按地址政策评估阈值，包括正常共享网络的流量，不能把它描述成精确的个人限制，也不能假设一个地址规则一定拦得住分散在许多网络上的抓取者。

地址在成为键之前需要语法规范化。同一个 IPv6 地址的不同合法写法，不应创建多份额度。是否按网段聚合，或把特定地址族形式视为同一个对象，是另外的政策选择，需要权衡误伤范围；规范化文本本身并不能替你回答这些业务问题。

转发身份必须有信任边界

随意提交的 Forwarded、X-Forwarded-For 或类似字段，不是客户端来源的证明。RFC 7239 明确指出，客户端和沿途节点都能改变转发信息。是否可信取决于直接连接的对端、配置的代理链，以及这条链如何移除或安全处理用户原先提交的字段。

NGINX 的真实 IP 模块需要明确配置可信来源地址和递归处理规则。“永远取转发字段里的第一个地址”不是适用于所有网络的正确方法。如果代理接收后原样转发了不可信声明，看似稳定的身份键就可能变成由调用者控制的新预算生成器。

下面的实验只模拟一个已经配置的可信代理，它会覆盖字段，并只发送一个 IP 字面值。其他对端提交的替换声明被忽略，来自这个代理的多地址列表则被拒绝。它不是通用代理链解析器，也不是已经部署并验收的 NGINX 配置，不能直接扩大其覆盖范围。

坏掉的样子

键里漏掉租户维度，会合并不同租户中标识相同的账号。按原始 URL 计数，又可能因为查询参数不同，把同一个操作拆成多个桶；如果政策按操作限流，应使用路由解析出的稳定操作身份。直接拼接字符串还可能产生歧义，应在编码中保留各组件边界。

不要把原始 bearer 秘密作为预算键或诊断标签。稳定的内部凭据标识或主体标识通常更合适，日志也仍需要隐私控制。无限创建身份会消耗限流器内存；评估过期或状态淘汰时，还应考虑桶被重置后产生的新额度，不能只看到内存回收这一面。

选定阈值前，应测试共享地址、漫游客户端、凭据轮换、租户隔离和伪造声明等真实身份组合。还要沿数据来源检查所谓“已验证主体”是否真的来自认证结果。如果它本身是从不可信请求直接复制出来的，后面再精巧的字典键也修复不了这个信任错误。

快速验证

保存为 identity_check.py，用 Python 3.10 以上版本执行 python3 identity_check.py。实验已在 Python 3.12.14 上运行，只使用标准库。记录代表已经完成认证和路由解析的测试请求，并不是认证实现；计数器只模拟一个测试窗口，不启动服务，不发送网络请求，也不写文件。

from collections import Counter
from ipaddress import ip_address


def account_key(request):
 # These two fields come from authentication and routing, not request headers.
 tenant, account = request["verified_actor"]
 return ("account", tenant, account, request["operation"])


def admit(counts, key, limit=2):
 if counts[key] >= limit:
 return False
 counts[key] += 1
 return True


alice = {"verified_actor": ("north", "alice"), "operation": "export",
 "peer": "198.51.100.8", "credential_id": "key-a", "claimed_account": "alice"}
bob = {**alice, "verified_actor": ("north", "bob"), "credential_id": "key-b"}
by_ip, by_account = Counter(), Counter()
assert [admit(by_ip, str(ip_address(request["peer"]))) for request in (alice, alice, bob)] == [
 True, True, False,
]
assert [admit(by_account, account_key(request)) for request in (alice, alice, bob)] == [
 True, True, True,
]
print("two accounts behind one address collide in the IP budget, but not the account budget")

roaming = {**alice, "peer": "203.0.113.9", "credential_id": "key-a-rotated"}
assert admit(by_ip, str(ip_address(roaming["peer"])))
assert not admit(by_account, account_key(roaming))
for claim in ("bob", "new-account", "admin"):
 assert account_key({**roaming, "claimed_account": claim}) == account_key(alice)
print("changing address, credential ID, or an untrusted account claim does not reset this account budget")

other_tenant = {**alice, "verified_actor": ("south", "alice")}
other_operation = {**alice, "operation": "thumbnail"}
assert admit(by_account, account_key(other_tenant))
assert admit(by_account, account_key(other_operation))
assert account_key({**alice, "verified_actor": ("a:b", "c")}) != account_key(
 {**alice, "verified_actor": ("a", "b:c")}
)
print("tenant and operation are explicit dimensions; tuple encoding avoids delimiter collisions")

# One configured proxy that overwrites the header with exactly one IP literal.
trusted_proxy = ip_address("192.0.2.10")


def network_key(peer, replacement):
 peer = ip_address(peer)
 return str(ip_address(replacement)) if peer == trusted_proxy else str(peer)


assert network_key("198.51.100.8", "203.0.113.77") == "198.51.100.8"
assert network_key("198.51.100.8", "not-an-address") == "198.51.100.8"
assert network_key("192.0.2.10", "198.51.100.8") == "198.51.100.8"
assert network_key("2001:0db8:0:0::1", "ignored") == network_key("2001:db8::1", "ignored")
try:
 network_key("192.0.2.10", "198.51.100.8, 203.0.113.9")
except ValueError:
 pass
else:
 raise AssertionError("the single-address proxy contract must reject a chain")
print("untrusted peers cannot choose a forwarded identity; equivalent IPv6 text shares one key")
print("the configured one-address proxy contract rejects a multi-address value")

Alice 耗尽地址桶后，同地址的 Bob 也会被阻止；按账号归组则保留 Bob 自己的额度。Alice 更换地址可以得到新 IP 额度，但换地址、轮换凭据标识，或者伪造账号声明，都不会改变这里的账号键。这个结果依赖测试记录中的主体已经可信，不能反过来作为认证正确性的证明。

不同租户与不同操作得到独立键，元组保留组件边界，避免分隔符碰撞。非可信对端不能选择替换地址，同一个 IPv6 地址的等价写法被统一；单代理、单地址契约会拒绝地址列表。真实认证、代理转发、并发计数、分布式配额和生产身份数量都未在本例中验证。

来源

RFC 6585，第四节将身份选择与计数范围交给限流政策定义，已核验 2026-09-08。
RFC 7239，转发字段完整性、可信代理与信息暴露，已核验 2026-09-08。
NGINX 真实 IP 模块，可信替换地址与递归处理，已核验 2026-09-08。

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

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。

时钟同步约束机器之间的时间偏差

Wed, 09 Sep 2026 00:00:00 +0000

时钟同步用于减少机器之间的民用时间读数差异，支撑证书有效期检查、事件时间解释以及许多过期策略，但不会建立完美的全局时钟。一台主机能够输出格式正确的 UTC，同时仍然测量了错误瞬间。应用需要区分经过时长、绝对截止时间和因果顺序，不能让所有语义都依赖未经解释的钟表数值比较。

四个时间戳估算两个量

一次 NTP 交换包含客户端发送时间 T1、服务端接收时间 T2、服务端发送时间 T3 和客户端接收时间 T4。常用偏移估计为 ((T2-T1)+(T3-T4))/2，正值表示服务端看起来比客户端更快。往返延迟估计为 (T4-T1)-(T3-T2)，其中减去了服务端处理所花的时间。它们是根据观测推算的量，并没有直接测出每一段单向网络路径的时延。

当去程和回程延迟不同，偏移估计就会包含误差。较小的往返延迟有参考价值，却不能证明两个方向完全对称。同步守护进程会使用多次采样、来源选择、过滤和时钟模型，而不是把单个报文当作无条件可信的真相。来源可达性、估计不确定性和来源可信度都需要考虑，较低的 stratum 数字本身并不是精度证书。

时间戳的表示分辨率也不同于测量准确度。小数字段即使能编码非常细的步长，实际时钟或网络观测仍可能带有明显更大的不确定性。多打印几位小数不会改善证据质量，解释结果时应同时说明测量方法和它能够支持的结论。

时钟控制是后续的另一阶段。守护进程可以逐渐调整，也可以在配置允许的条件下直接跳变。因此不能保证 NTP 永远不会造成实时时钟的不连续，更不能承诺所有环境都达到亚毫秒精度。网络、振荡器、平台和配置共同决定实际效果。告警阈值应来自应用需求和测量条件，而不是把某个固定偏差值无条件推广到所有系统。

坏掉的样子

实时时钟可能向前或向后调整，直接相减得到的时长就可能失真甚至变成负数。本机持续时间和超时应选择适当的单调时钟，但其参考起点不能直接当成其他主机或下次启动仍可使用的时间戳。证书日期和业务截止时间仍需要民用时间语义，因此单调时钟并不是替代所有日期处理的通用答案。

格式不完整、与请求不对应、来源未同步或被策略拒绝的 NTP 响应，都不能当成普通样本使用。核对返回的 origin 时间戳是否匹配本次请求，有助于拒绝无关报文，但并不构成密码学认证。生产客户端还需要协议规定的更多校验和来源选择行为。时钟同步也不能自动让基于时间戳的租约成为安全分布式锁，更不能保证非常接近的事件按时间排序就等于因果顺序。

快速验证

使用全新的临时 Debian 12 Docker 容器，先执行 apt-get update，再执行 apt-get install -y python3 chrony 准备依赖。将代码保存为 ntp-exchange.py，以 root 运行 python3 ntp-exchange.py。实测版本是 chrony 4.3 和 Python 3.11.2。创建容器时应去掉 SYS_TIME 能力，并保持独立网络命名空间，不使用宿主网络；实验只需要容器内的回环通信。

from pathlib import Path
from tempfile import TemporaryDirectory
import json
import os
import socket
import struct
import subprocess
import time

assert os.geteuid() == 0 and Path('/.dockerenv').exists(), 'use a disposable root Linux container'
NTP_EPOCH = 2208988800
ERA = 2**32


def stamp(unix_time):
 value = unix_time + NTP_EPOCH
 whole = int(value)
 return struct.pack('!II', whole % ERA, int((value - whole) * ERA))


def seconds(data, reference):
 whole, fraction = struct.unpack('!II', data)
 era = round((reference + NTP_EPOCH - whole) / ERA)
 return whole + era * ERA - NTP_EPOCH + fraction / ERA


def estimate(t1, t2, t3, t4):
 return ((t2 - t1) + (t3 - t4)) / 2, (t4 - t1) - (t3 - t2)


def validate(data, sent):
 if len(data) < 48:
 raise ValueError('short packet')
 if data[0] >> 6 == 3:
 raise ValueError('unsynchronised source')
 if (data[0] & 7) != 4 or ((data[0] >> 3) & 7) != 4:
 raise ValueError('unexpected mode or version')
 if not 1 <= data[1] <= 15:
 raise ValueError('unusable stratum')
 if data[24:32] != sent:
 raise ValueError('origin timestamp mismatch')


with TemporaryDirectory(prefix='ntp-exchange-') as directory:
 root = Path(directory)
 with socket.socket(socket.AF_INET, socket.SOCK_DGRAM) as reservation:
 reservation.bind(('127.0.0.1', 0))
 port = reservation.getsockname()[1]
 config = root / 'chrony.conf'
 config.write_text(f'pidfile {root}/pid\ncmdport 0\nbindcmdaddress {root}/command.sock\n'
 f'port {port}\nbindaddress 127.0.0.1\nlocal stratum 8\nallow 127.0.0.1\n')
 process = subprocess.Popen(['chronyd', '-x', '-n', '-u', 'root', '-f', str(config)],
 stdout=subprocess.PIPE, stderr=subprocess.PIPE)
 try:
 deadline = time.monotonic() + 5
 while not (root/'command.sock').exists():
 assert process.poll() is None
 if time.monotonic() > deadline:
 raise AssertionError('chronyd did not start')
 time.sleep(0.05)
 with socket.socket(socket.AF_INET, socket.SOCK_DGRAM) as client:
 client.settimeout(5)
 client.connect(('127.0.0.1', port))
 request = bytearray(48)
 request[0] = 0x23
 t1, start = time.time(), time.monotonic()
 sent = stamp(t1)
 request[40:48] = sent
 client.send(request)
 data = client.recv(512)
 t4, finish = time.time(), time.monotonic()
 validate(data, sent)
 t2, t3 = seconds(data[32:40], t1), seconds(data[40:48], t1)
 offset, delay = estimate(t1, t2, t3, t4)
 assert data[1] == 8 and finish >= start
 bad_origin = bytearray(data); bad_origin[24:32] = bytes(8)
 alarm = bytearray(data); alarm[0] |= 0xC0
 denied = bytearray(data); denied[1] = 0
 rejected = []
 for candidate in (data[:40], bad_origin, alarm, denied):
 try:
 validate(candidate, sent)
 except ValueError as error:
 rejected.append(str(error))
 else:
 raise AssertionError('invalid packet accepted')
 symmetric = estimate(100, 105.020, 105.022, 100.042)
 asymmetric = estimate(100, 105.010, 105.012, 100.042)
 assert abs(symmetric[0] - 5) < 1e-9 and abs(symmetric[1] - 0.040) < 1e-9
 assert abs(asymmetric[0] - 4.990) < 1e-9 and abs(asymmetric[1] - 0.040) < 1e-9
 print(json.dumps({'actual_loopback_sample': {'stratum': data[1],
 'offset_seconds': offset, 'delay_seconds': delay,
 'monotonic_elapsed_seconds': finish-start},
 'rejected_packets': rejected,
 'synthetic_symmetric_estimate': list(symmetric),
 'synthetic_asymmetric_estimate': list(asymmetric),
 'known_synthetic_offset': 5,
 'system_clock_adjustment_disabled': True,
 'external_UTC_accuracy_tested': False}))
 finally:
 process.terminate()
 process.communicate(timeout=5)

程序用 -x 启动 chronyd，明确禁止调整系统时钟，再配置仅供本地使用的 local stratum 8 来源。它发送真实的第四版客户端报文，检查响应模式、层级、origin 时间戳及告警状态。预期获得层级为八的实际样本，偏移和延迟数值会随运行条件变化。随后四份被改动或截短的报文分别被拒绝，最终关闭套接字与守护进程，不留下后台服务。

另外两个合成计算案例把真实服务端超前量都设为五秒。去程与回程各二十毫秒时，估计结果是五秒，网络往返延迟四十毫秒。改为去程十毫秒、回程三十毫秒后，往返仍为四十毫秒，估计超前量却变成 4.990 秒。十毫秒误差来自路径对称性的假设；这些固定数值是计算案例，不能写成实际回环链路的测量结果。

全部断言已经执行通过。本地来源共享测试主机的时钟，并没有外部 UTC 参考。实验既没有校准系统时钟，也没有证明外部精度、NTS 认证或完整客户端符合性。诊断记录应始终区分已经观察到的有效交换、带不确定性的估计，以及真正足以支撑生产业务的可信时间。

来源

RFC 5905: Network Time Protocol Version 4，时间戳交换、偏移估算及路径延迟，已核验 2026-09-13。
chronyd 4.3 manual，时钟控制及禁用调整选项，已核验 2026-09-13。
Python: time，实时时钟与单调时钟行为，已核验 2026-09-13。

可靠性 · XB 现场笔记

背压只有改变生产者行为，才真正控制了有界接入

坏掉的样子

快速验证

让接入契约贯穿整个处理链

延伸阅读

来源

缓存失效是主动推进，不是祈祷

到期不是广播通知

先确定失效覆盖范围

坏掉的样子

快速验证

延伸阅读

来源

连接超时阻止无声的停摆

连上了，不代表能拿到有用的响应

坏掉的样子

快速验证

来源

排班需要连续覆盖，也需要复核实际负担

一份被共同承担的职责

交接是工作的一半

在铃声响起前演练

坏掉的样子

快速验证

延伸阅读

来源

探针告诉平台何时出手

三个问题，对应不同动作

阈值统计连续观察结果

检查机制决定你拿到了什么证据

坏掉的样子

快速验证

延伸阅读

来源

资源限制约束运行，请求参与放置

CPU 与内存具有不同失败方式

坏掉的样子

快速验证

延伸阅读

来源

负载削减保护系统

保护还能产生价值的容量

选择有依据的政策

限制准入，而不只是线程数量

坏掉的样子

快速验证

延伸阅读

来源

Retry-After 告诉你何时再试

结合响应语境解释字段值

尊重等待时间，但不无限等待

相同等待值仍可能让调用者同时回来

坏掉的样子

快速验证

延伸阅读

来源

优雅降级保留部分价值

先决定哪些东西可以缺少

把陈旧数据的可接受条件写清楚

坏掉的样子

快速验证

延伸阅读

来源

带抖动与退避的重试

先约束尝试次数，再安排时间

指数退避增长的是上限

整条操作共用一个截止期限

坏掉的样子

快速验证

延伸阅读

来源

熔断器阻止对故障服务的轰炸

明确政策，而不只是画出状态

分类失败，并限定影响范围

恢复是一场受控试探

坏掉的样子

快速验证

延伸阅读

来源