部署 · XB 现场笔记

变更窗口为人设计，不是为服务器

Thu, 29 Jul 2027 00:00:00 +0000

一次发版既是技术时刻，也是人与协作的时刻。选在什么时候，在于谁会在场看结果。

流量只是算式的一半

选在流量最低的时段发布,用户受影响的面确实最小,但它与人撞了个满怀:凌晨运维最可能不在场、或正在处理别的告警。如果发布在半夜半途失败而无人留意,静默故障可以持续数小时才被人类读取。低流量是好的起点,但它回答的是"流量"而不是"风险"。要在减少用户波及与"是否有人来得及反应"之间权衡,优先选择你确实能观察结果的那个窗口,而不是把少一千个用户看得比回滚能力更重。

尊重人的时钟

窗口要服从的不是服务器,而是人。想一想出了问题谁要行动:值班的 SRE、业务负责人、开发团队,把他们的注意力安排进时段。再想想最近还有哪些变更正在凑热闹——新发布的版本、定时任务、自动迁移——别让它们在同一窗口和你绞成一团,把一次发布变成连环事故。与其选一个"并发更小但没人在场"的时段,不如选一个相关的人清醒、可联系、且尚未超载的时段,这才是真正划算的发布时机。

让窗口成为习惯

固定且有人值守的窗口，可以帮助协调高风险变更，使观察和响应更加可预期。但这并不意味着所有发布都必须攒成一批：小型、自动化、可独立回退的变化，也可以使用持续交付流程。节奏应根据实际风险和响应覆盖决定。把构建、冒烟和金丝雀检查自动化，同时保留明确负责人以及经过演练的恢复路径；日历中的时段应当支持这些保障，而不能取代它们。

坏掉的样子

第一种坏法，是窗口之外的紧急变更没有通道。线上正在着火，值班却被告知等下个窗口，于是有人绕过流程直接推生产，无人盯盘，也无回滚说明。窗口本意是门禁，可如果没有破窗程序——谁来批准、谁来盯着、事后补什么记录——每一次例外都会变成暗箱发布。应在正常安排之外写清紧急通道，并演练到和普通发布一样熟；不能把等待下个日历窗口当作所有事故的处理方式。

第二种坏法，是窗口之内的批量堆积踩踏。四五个服务挤进同一两个小时，仪表盘信号混在一起，错误率一抬头，谁也说不清到底是谁引起的。回滚从一键按钮变成多方谈判，因为回滚其中一个，就要猜另外几个的状态。共享故障信号或依赖的变更应当错开，每个条目进入窗口前，都要写清负责人、健康信号与回退路径。排队是为了让归因清晰，值班才敢果断回滚。

第三种坏法，是跨时区窗口错位。作者写周三上午十点，心里是柏林时间，洛杉矶的同事按本地时间理解，结果在半数响应人熟睡时发布。夏令时切换还会悄悄再挪一小时。窗口必须连时区一起存、按读者本地时间展示，排班时逐一确认真有人在场，才能把这个时段算作有人值守。凡是只写钟点不写时区的窗口，迟早会在某个深夜兑现为误操作。

快速验证

把下面程序保存为 change_window_check.py，运行 python3 change_window_check.py。它只用标准库，把每个窗口都当作时区感知的时间段，结论只有两种：allow 表示满足窗口条件，needs-approval 表示需要审批。演示表包含柏林与纽约的周三上午窗口，起止时间位于同一天。冻结日按明确选择的 UTC 政策日期解释，不取决于调用方用哪个时区表达输入瞬间。坏样本是故意留下的反例，仅作拦截演示。

from datetime import datetime, time
from zoneinfo import ZoneInfo

WINDOWS = [
 {"name": "berlin-wed", "weekday": 2, "start": "09:00", "end": "11:00", "tz": "Europe/Berlin"},
 {"name": "newyork-wed", "weekday": 2, "start": "09:00", "end": "11:00", "tz": "America/New_York"},
]
FREEZE_DATES = frozenset({"2027-12-24"})
FREEZE_ZONE = ZoneInfo("UTC") # Organization-wide policy, independent of input representation.


def _hhmm(value):
 hour, minute = map(int, value.split(":"))
 return time(hour, minute)


def decide(moment, windows=WINDOWS, freeze=FREEZE_DATES):
 if moment.tzinfo is None or moment.utcoffset() is None:
 return "needs-approval", "naive datetime carries no zone; attach a ZoneInfo first"
 freeze_day = moment.astimezone(FREEZE_ZONE).date()
 if freeze_day.isoformat() in freeze:
 return "needs-approval", f"freeze date {freeze_day} in UTC; emergency path only"
 for window in windows:
 local = moment.astimezone(ZoneInfo(window["tz"]))
 if local.weekday() == window["weekday"] and _hhmm(window["start"]) <= local.time() < _hhmm(window["end"]):
 return "allow", f"inside {window['name']} ({local:%Y-%m-%d %H:%M %Z})"
 return "needs-approval", f"outside all windows ({moment:%Y-%m-%d %H:%M %Z})"


def check(actual, expected, label):
 status, reason = actual
 assert status == expected, f"{label}: got {status} ({reason})"
 print(f"{label}: {status} -- {reason}")


def main():
 berlin = ZoneInfo("Europe/Berlin")
 newyork = ZoneInfo("America/New_York")
 good_berlin = datetime(2027, 8, 4, 9, 30, tzinfo=berlin)
 good_ny = datetime(2027, 8, 4, 9, 30, tzinfo=newyork)
 check(decide(good_berlin), "allow", "good/berlin-wed-morning")
 check(decide(good_ny), "allow", "good/newyork-wed-morning")
 # Same UTC instant, different local reading: 07:30 UTC is 09:30 in Berlin but 03:30 in New York.
 same_instant = datetime(2027, 8, 4, 7, 30, tzinfo=ZoneInfo("UTC"))
 check(decide(same_instant), "allow", "good/same-instant-via-berlin")
 evening = datetime(2027, 8, 4, 22, 10, tzinfo=berlin)
 check(decide(evening), "needs-approval", "bad/wednesday-night")
 wrong_day = datetime(2027, 8, 5, 9, 30, tzinfo=berlin)
 check(decide(wrong_day), "needs-approval", "bad/thursday-morning")
 frozen = datetime(2027, 12, 24, 9, 30, tzinfo=berlin)
 check(decide(frozen), "needs-approval", "bad/freeze-date")
 naive = datetime(2027, 8, 4, 9, 30)
 check(decide(naive), "needs-approval", "bad/naive-datetime")
 misread = datetime(2027, 8, 4, 9, 30, tzinfo=ZoneInfo("America/Los_Angeles"))
 check(decide(misread), "needs-approval", "bad/timezone-misread")
 check(decide(datetime(2027, 8, 4, 9, 0, tzinfo=berlin)), "allow", "good/start-inclusive")
 check(decide(datetime(2027, 8, 4, 11, 0, tzinfo=berlin)), "needs-approval", "bad/end-exclusive")
 winter = datetime(2027, 1, 6, 8, 30, tzinfo=ZoneInfo("UTC"))
 check(decide(winter), "allow", "good/winter-berlin")
 # This Wednesday would otherwise pass: the freeze test cannot pass by accident.
 frozen_wednesday = frozenset({"2027-08-04"})
 shifted = same_instant.astimezone(ZoneInfo("Etc/GMT+12"))
 assert shifted == same_instant and shifted.date() != same_instant.date()
 check(decide(same_instant, freeze=frozen_wednesday), "needs-approval", "bad/UTC-freeze")
 check(decide(shifted, freeze=frozen_wednesday), "needs-approval", "bad/same-freeze-other-zone")
 assert decide(same_instant, freeze=frozen_wednesday) == decide(shifted, freeze=frozen_wednesday)
 print("PASS: 5 allows and 8 approvals; policy dates do not depend on caller timezone")


if __name__ == "__main__":
 main()

运行后应看到五行 allow、八行 needs-approval，最后打印 PASS。开始边界包含在窗口内，结束边界不包含。夏季与冬季的 UTC 案例使用不同偏移，却都换算为柏林九点半。另一个本来符合窗口的周三瞬间，被冻结规则拒绝；即使把同一瞬间写成当地日期仍是前一天的时区表示，也必须得到完全相同的拒绝结果。如果直接检查输入日期，后一种表示就会错误放行。

修订后的断言已在 Python 3.12.14 下执行通过。allow 仅表示这项日历判断通过，不授予发布权限，也没有验证真的有人值守。这个同日窗口示例不处理跨午夜时段，也不验证含糊或不存在的本地时间是怎样构造出来的。应从已知瞬间进行换算，再独立核对审批、值班表、观察时长和恢复准备；日期计算正确只是完整变更流程的一部分。

来源

Google SRE：发布工程，把发布当作一种工程实践，已核验 2026-10-15。
12Factor：构建发布运行，构建与发布分离，已核验 2026-10-15。
Python datetime，感知时区的时间戳与时区表示换算，已核验 2026-10-15。
Python zoneinfo，IANA 时区规则与夏令时变化，已核验 2026-10-15。

滚动更新分批换上新版本

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

滚动更新是一种受控替换，不是服务绝不中断的承诺。它的价值在于引入新副本时可以保留部分旧副本；用户能否平稳完成请求，还取决于资源余量、健康检查是否可信，以及应用如何退出。本文讨论已经选择滚动更新之后怎样调节节奏、怎样观察过程；姊妹篇讨论更靠前的问题：两个版本到底能不能同时运行。

浪涌与缺口

十个期望副本，配 maxSurge: 2，更新目标上限是十二，不是十一。maxUnavailable: 1 给控制器的可用性预算是九个。这不是「每一波最多删除一个旧 Pod」：只要已经有足够的新副本可用，控制器就能继续撤掉多个旧副本。正在终止的 Pod 还可能保留一段时间并继续消耗资源，因此十二也不是所有 Pod 对象或进程数量的绝对上限。

百分比必须先换算整数：surge 向上取整，unavailable 向下取整。三个副本使用默认的百分之二十五，实际就是一个 surge、零个 unavailable。这里有一个边界例外：surge 为零、非零的 unavailable 百分比却向下取成零时，控制器会把有效 unavailable 调整为一，让替换能够推进。因此，不能从这个换算得到的零，推断更新一定不会主动减少可用副本。

两个参数都不会替你预留节点资源。选择速度之前，要把资源请求量与可调度容量、命名空间配额、放置约束以及旧 Pod 的退出耗时一起检查。账面上多出的两个位置，并不一定真有节点能承接；新 Pod 全部 Pending 时，调大 surge 也不会凭空生出机器。

健康是换班的门槛

首先确认清单中确实配置了就绪探针。就绪检查应该回答「这个实例现在能否处理预期的流量」。只检查端口监听可能漏掉应用故障；检查必要的后端依赖可能更准确，但共享依赖短暂失败也可能让全部副本一起退出就绪状态。是否应该停止接流量，要根据业务的降级能力决定，而不是机械地把所有依赖都塞进探针，更不能一看到失败就放宽条件。

minReadySeconds 要求新 Pod 持续就绪一段时间，之后才计入 Deployment 的可用副本。它不会把 Service 流量也延迟到这段时间结束。启动慢的容器可以用 startup probe，避免还在初始化就被存活检查重启。这些检查仍不能证明订单处理正确，也不能证明实例能持续承受生产负载。

退出过程需要单独验证。端点状态传播、旧连接排空、应用处理终止信号、终止宽限期必须配合。应用即使一直把就绪端点返回成功，也可能在退出时丢掉正在处理的请求。把「Pod 数量看起来充足」当成「用户请求没有失败」，会漏掉这一整类问题。

选一个有意为之的节奏

对于有额外容量的小规模服务，一个 surge、零个 unavailable 是可以考虑的起点。它限制更新过程主动削减可用副本，却不能阻止节点故障、依赖故障或请求错误。PodDisruptionBudget 也不会约束 Deployment 自己执行的滚动升级；不要把节点维护时的驱逐保护，误当成应用发布的额外保险。

人工暂停适合停下来检查，但它不是精确的单 Pod 金丝雀发布，也不锁定固定的流量比例。暂停生效前，控制器可能已经推进；暂停后，现有副本仍会运行并接流量。如果要求新版严格只接少量流量，就需要独立控制的金丝雀副本与路由。发布前应写明错误率、延迟、重启和关键业务检查的通过线，并规定完成后的观察时长，不能等看见曲线才临时决定标准。

坏掉的样子

滚不完时，先找故障发生在哪一层。调度事件指向资源或放置问题；拉取镜像失败指向镜像引用或仓库访问；容器日志与探针事件用来区分进程崩溃和就绪失败。先确认探针是否准确发现了故障，再决定要修应用、修配置，还是修检查本身。仅凭一个超时就降低健康标准，可能把尚未承接流量的错误推进到全量。

坏版本可能先消耗允许的不可用额度，然后才停滞，并不保证旧副本全部留下。progressDeadlineSeconds 会报告进度停滞，但不会自动回滚，也不会把所有协调动作冻结。应为该条件配置告警，再根据证据决定修复或回退。滚动顺利结束也不等于业务验收完成：慢内存泄漏、连接耗尽与真实流量下的错误，可能在后续观察期才出现。观察通过以前，应保留可用的修订历史和旧镜像，并确认旧版仍能启动。

快速验证

把下面的标准库练习保存为 rounding_window.py，运行 python3 rounding_window.py。程序用整数算术检查百分比换算，包括小规模副本、恰好整除的边界以及百分之百。它不是 Deployment 控制器模拟器，也不是完整的 API 校验器；不能把函数接受的所有输入都理解为有效的发布配置。百分之零到百分之一百的输入范围只是本练习的限制，并不是 maxSurge 的 API 上限。

"""Check percentage rounding only; no Kubernetes API calls."""


def round_percent(replicas, percent, *, up):
 if type(replicas) is not int or replicas <= 0:
 raise ValueError("this exercise requires positive integer replicas")
 if type(percent) is not int or not 0 <= percent <= 100:
 raise ValueError("this exercise accepts integer percentages 0..100")
 numerator = replicas * percent
 return (numerator + 99) // 100 if up else numerator // 100


def main():
 cases = [(1, 1, 0, 1), (3, 25, 0, 1), (4, 50, 2, 2),
 (10, 20, 2, 2), (10, 10, 1, 1), (4, 100, 4, 4)]
 for replicas, percent, down, up in cases:
 assert round_percent(replicas, percent, up=False) == down
 assert round_percent(replicas, percent, up=True) == up
 print(f"replicas={replicas}, percent={percent}: down={down}, up={up}")
 print("PASS: percentage rounding only; no cluster exercised")


if __name__ == "__main__":
 main()

预期先输出六行案例，再输出一行明确限定为百分比换算的 PASS。三个副本乘百分之二十五，向下取整为零、向上取整为一；十个副本乘百分之二十，两种方向都是二。百分之百的案例确认换算结果可以覆盖全部副本，并不因服务目标不允许停机就自动变成数学错误。本次修订在 Linux 的 Python 3.12.14 中执行了这些断言。通过只证明算术一致，没有证明服务可用性。

把数字用到真实发布前，先选择正确的测试集群上下文与命名空间，并确认 Deployment 实际配置。如果已有 api Deployment、Pod 标签为 app=api，可用 kubectl rollout status deployment/api --timeout=120s 观察收敛，在另一个终端用 kubectl get pods -l app=api -w 观察替换。客户端等待超时，只表示命令不再等待，并没有取消更新。如果可能同时发起多个版本，使用 --revision=N 指定要检查的修订号。观察结束时按 Ctrl-C。

这里没有执行这些集群命令。仍需在测试环境升级期间收集 Pod 事件、日志和 Deployment 状态，同时持续从真实 Service 或入口路径发请求，把错误和退出期间的延迟一起记录。事件中的对象名称、发生时间要与这次发布对应，不能把其他服务的故障当成当前更新的证据。这些才是尚待完成的集成验证；只看最终成功的一行输出，无法证明零停机。

来源

Kubernetes Deployment，更新预算、就绪时间、暂停与进度条件，已核验 2026-10-15。
Kubernetes 探针，启动、存活与就绪检查的职责，已核验 2026-10-15。
Kubernetes Pod 生命周期，终止流程与连接排空，已核验 2026-10-15。
Kubernetes 资源管理，资源请求与调度容量，已核验 2026-10-15。
Kubernetes 干扰，PodDisruptionBudget 在滚动升级中的边界，已核验 2026-10-15。
kubectl 命令参考，更新状态与客户端超时，已核验 2026-10-15。
Kubernetes 控制器的取整实现，固定版本的 ResolveFenceposts 对两个取整结果都为零的处理，已核验 2026-10-15。

让已经验证的产物逐级进入环境

Wed, 17 Feb 2027 00:00:00 +0000

预发布测试说明的是当时实际运行的产物与环境。生产部署前重新构建，会得到另一份输出，需要检查它的身份，或者重新验证它的行为。产物晋级指把已验证的那份文件继续交给下一个环境，并记录这次决定。它减少了一类不确定性，但不会让预发布与生产环境自动等价，也不会免除部署之后的运行检查。交付字节一致，是发布判断的一部分，而不是全部。

明确究竟把什么向前传递

使用不可变的软件包标识或内容摘要定位构建结果。会移动的标签、分支名乃至源码提交，本身都不足以唯一证明部署了哪些字节。同一源码的两次构建，可能因为工具链、依赖解析、嵌入设置或打包步骤而不同。可复现的重建确实可能得到完全相同的字节，但应先比较结果，再把它视为之前通过测试的同一产物，而不是仅凭源码相同推断。

应区分构建阶段与发布阶段。发布组合包含特定产物及该部署需要的配置，运行过程再把这个组合放到真实依赖和数据之上。记录产物身份与合适的配置版本，同时避免泄露秘密。如果前端环境设置在打包时直接编译进 JavaScript，修改设置就会改变字节，也就是生成了另一份需要验证的产物。不能一边修改包内内容，一边继续沿用原包通过测试的身份。

坏掉的样子

某些流水线名义上在晋级产物，部署脚本却悄悄重新编译；另一些流程下载了正确归档，却又覆盖归档内部的配置文件。这两种操作都改变了测试时的输入。应明确哪些设置位于不可变负载之外，并通过应用已有的配置接口读取。校验和如果发生在后续修改之前，就不能继续代表运行时文件；核验时点与文件变化顺序必须一起审查。

即便产物相同，数据库结构、功能开关、依赖版本、权限、资源限制或网络路径变化，也能让行为不同。晋级保证的是字节连续性，不是整个执行上下文都一致。部署后仍要验证关键生产行为；预发布结果无法在生产重现时，要比较真正相关的环境差异，而不是看到摘要相同就认定问题与发布无关。配置也是发布组合的一部分，需要可追溯的变化记录。

回滚同样有前提。旧程序可能无法理解新写入的数据，或者无法适应已经完成的破坏性结构迁移。把指针切回旧产物，并不会撤销这些外部影响。恢复说明应关联数据兼容性、配置和依赖状态；不能反向恢复时，就应准备必要的向前修复。不能把“重新选择旧镜像”描述成所有故障都适用的完整回滚方案。

快速验证

把代码保存为 promote.py，执行 python3 promote.py。示例只使用 Python 标准库、临时目录和绑定回环地址的 HTTP 服务。它写出一份很小的应用文件，记录摘要，再复制进两个本地环境。production-simulation 只是临时目录的标签，不会触发外部部署，也不会接触真实生产配置。这个命名用于让输出清楚地区分两个运行位置。

from hashlib import sha256
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer
from pathlib import Path
from tempfile import TemporaryDirectory
from threading import Thread
from urllib.request import ProxyHandler, build_opener
import json
import runpy
import shutil

source = 'def render(config):\n return {"build": "local-build-41", "tier": config["tier"]}\n'
digest = sha256(source.encode()).hexdigest()


def verify(path):
 if sha256(path.read_bytes()).hexdigest() != digest:
 raise ValueError('artifact changed')


def handler(path, config):
 verify(path)
 render = runpy.run_path(str(path))['render']

 class Handler(BaseHTTPRequestHandler):
 def do_GET(self):
 data = path.read_bytes() if self.path == '/artifact' else json.dumps(render(config)).encode()
 self.send_response(200)
 self.send_header('Content-Length', str(len(data)))
 self.end_headers()
 self.wfile.write(data)

 def log_message(self, *args):
 pass

 return Handler


with TemporaryDirectory() as directory:
 root = Path(directory)
 artifact = root / 'build.py'
 artifact.write_text(source)
 opener = build_opener(ProxyHandler({}))
 observed = []
 for tier in ('staging-local', 'production-simulation'):
 destination = root / tier
 destination.mkdir()
 deployed = destination / 'app.py'
 shutil.copyfile(artifact, deployed)
 config = {'tier': tier}
 server = ThreadingHTTPServer(('127.0.0.1', 0), handler(deployed, config))
 thread = Thread(target=server.serve_forever)
 thread.start()
 try:
 origin = f'http://127.0.0.1:{server.server_port}'
 with opener.open(origin + '/artifact', timeout=5) as response:
 received_digest = sha256(response.read()).hexdigest()
 with opener.open(origin + '/', timeout=5) as response:
 rendered = json.load(response)
 assert received_digest == digest
 assert rendered == {'build': 'local-build-41', 'tier': tier}
 observed.append({'artifact_sha256': received_digest, 'response': rendered,
 'config_sha256': sha256(json.dumps(config, sort_keys=True).encode()).hexdigest()})
 finally:
 server.shutdown()
 thread.join()
 server.server_close()
 deployed.write_text(source + '# rebuilt\n')
 try:
 verify(deployed)
 except ValueError:
 changed_rejected = True
 else:
 changed_rejected = False
 assert changed_rejected
 print(json.dumps({'environments': observed, 'changed_copy_rejected': changed_rejected}))

每个服务启动之前，脚本都核对复制文件是否符合原始摘要，再加载其中的应用函数。请求 /artifact 会返回部署文件的真实字节；请求 / 则用该环境单独提供的配置执行应用函数。两次 HTTP 下载得到相同的产物摘要，两份应用响应也都声明 local-build-41。这些结果结合文件复制与实际请求，建立了本地传递的证据。

响应中的环境标签不同，记录的配置摘要也不同；这里的配置仅包含无害标签。它说明同一份应用字节可以因为明确的配置输入而产生不同输出。服务停止后，脚本再修改一份副本，同样的摘要检查会拒绝它，因而这道身份门禁能够发现示例中的静默重建。不能把摘要检查称为功能测试，二者分别验证不同性质。

本实验没有模拟注册仓库、认证、数据库迁移、真实生产流量或回滚，只覆盖本地文件传递、校验、独立配置以及 HTTP 结果。它也不能证明某个真实部署系统已经遵循相同规则。把范围写清楚，才能让读者理解哪些步骤可直接观察，哪些发布条件仍需要结合自己的系统另行验证。

核对真正运行的发布组合

把晋级决定关联到产物与配置版本，然后检查已部署进程或实际服务的文件，不能只依赖上传成功。为需要的恢复窗口保留批准过的原产物。如果后续阶段生成了另一份软件包，应为新输出分配新的身份，并执行与变化相关的验证。可用的晋级记录，应能够回答传递了哪些字节、带了哪份配置，以及传递之后实际观察到了什么行为。

来源

The Twelve-Factor App: build, release, run，区分构建产物、发布组合和运行过程，已核验 2026-09-13。
The Twelve-Factor App: config，随部署环境变化的配置，已核验 2026-09-13。

功能开关把发布与暴露解耦

Tue, 09 Feb 2027 00:00:00 +0000

部署代码和向用户开放功能，是不同动作。功能开关可以在代码部署后选择运行路径，支持渐进开放和快速关闭；前提是旧路径仍兼容，配置也真正到达负责求值的进程。开关控制一次决定，不会撤销部署或新行为已经造成的全部效果。讨论回滚时，应明确能停止什么、不能恢复什么，而不是把关闭按钮当作万能撤销。

在明确的门控后部署

发布开关通常默认选择既有路径，让新实现先接受验证。不过部署阶段仍可能变化：导入、启动钩子、表结构迁移、依赖和资源使用，都可能位于被保护分支之外。因此关闭开关不能保证用户完全无感。应同时测试关闭和开启状态的真实产物，包括启动流程，以及两条路径与已有数据的兼容性，避免只看功能入口是否隐藏。

关闭开关可以阻止后续请求进入新路径，却不会撤销已经完成的写入、已发送消息、迁移或在途工作。回滚窗口内应让两条路径都能处理相关数据格式，并定义部分执行后可能需要的修复。紧急关闭只有在传播延迟和实际停止边界符合响应计划时才有效；控制台显示关闭，不代表所有正在运行的操作已经中止。

按含义选择默认行为

对于尚未完成的发布功能，未知配置时退回旧路径可能是安全选择。但这是具体开关的语义，不是任何情况下 false 都安全。关闭保护性检查，或者反转名为 disable-validation 的开关，可能产生相反结果。应明确备用值、配置新鲜度，以及无法求值时的处理，不能只用“失败为关”四个字替代对实际行为的审查。

在合适的操作边界求值一次，并在该操作内部复用决定。多个服务或独立请求之间，需要明确传递兼容决定的方式；每个进程本地求值一次，不会自然形成全局一致性。权限校验也应独立存在。客户端控制显示的开关，不能变成服务器接受受保护操作的授权凭证，否则隐藏按钮并没有真正限制访问。

用稳定身份逐步开放

把稳定用户标识与稳定开关键一起散列，可以形成可重复的分组。改变身份字段、盐值或分桶算法，即使百分比不变，也可能让用户重新分组。用户比例也不等于请求比例：少量重度用户可能产生大量流量。因此解释放量指标前，先记录分配单位，确认观察的是账号、请求还是其他业务实体，不能把几个百分比直接互换。

紧急关闭应覆盖普通分桶选择，并具有经过测试的配置传递路径。SDK 缓存和配置服务故障，可能让部分实例继续使用旧值。应按实际求值的变体观察错误与延迟，不能把控制面修改成功当作每次请求已经切换的证明。放量节奏应依据服务风险和观察延迟决定，不存在对所有业务都适用的固定百分比或等待时间。

坏掉的样子

临时发布开关如果没有删除负责人，会变成长期分支。应指定负责人和退出条件，在回滚窗口结束后删除不再需要的路径。运维开关和权益控制则可能有意长期存在，需要持续测试和维护，不能要求所有开关都很快过期。区分类型，才能既避免死配置堆积，又保留真正需要的长期运行控制。

互相矛盾的开关还可能形成无人测试的组合。可行时集中决定规则，定义优先级，同时验证备用与开启路径。日志只保留足以诊断不一致的非敏感上下文，避免无限保留真实用户标识。本例使用的名字全部是合成测试数据；把这份内存审计列表搬到生产环境前，还需另行设计保留、访问和脱敏规则。

快速验证

把代码保存为 flag_check.py，用 Python 3.10 或更新版本运行。原始实验记录使用 Python 3.14.4，本轮用 Python 3.12.14 重新执行其决定逻辑。脚本只模拟一个百分比发布开关、紧急关闭、稳定用户分桶和内存审计列表。百分比假定已通过零至一百的输入验证，不包含真实配置下载、SDK 缓存或身份服务。

import hashlib


class Flag:
 """One percentage flag with kill switch, default-closed, and audit log."""

 def __init__(self, key, percent):
 self.key = key
 self.percent = percent
 self.killed = False
 self.audit = []

 def _bucket(self, user):
 digest = hashlib.sha256(f"{self.key}:{user}".encode()).hexdigest()
 return int(digest, 16) % 100

 def evaluate(self, user):
 if self.killed:
 decision, reason = False, "killed"
 elif not user:
 decision, reason = False, "default-closed"
 else:
 hit = self._bucket(user) < self.percent
 decision, reason = hit, ("in-bucket" if hit else "out-of-bucket")
 self.audit.append({"user": user, "decision": decision, "reason": reason})
 return decision


flag = Flag("new-checkout", 20)
users = [f"user-{i}" for i in range(200)]

# 1. Default closed: a missing user never gets the new path.
assert flag.evaluate("") is False
assert flag.evaluate(None) is False

# 2. Stickiness: the same user gets the same answer twice.
first = flag.evaluate("user-1024")
second = flag.evaluate("user-1024")
assert first == second

# 3. Kill switch overrides every bucket.
flag.killed = True
assert flag.evaluate("user-1024") is False
assert flag.evaluate("user-7") is False
flag.killed = False

# 4. The dial moves exposure for a fixed fixture set.
open_20 = sum(flag.evaluate(u) for u in users)
flag.percent = 100
open_100 = sum(flag.evaluate(u) for u in users)
flag.percent = 0
open_0 = sum(flag.evaluate(u) for u in users)
flag.percent = 20
assert open_0 == 0
assert 0 < open_20 < len(users)
assert open_100 == len(users)

# 5. A different bucketing key disagrees somewhere: the inconsistency to avoid.
session_flag = Flag("new-checkout-session", 20)
mismatch = [u for u in users if flag.evaluate(u) != session_flag.evaluate(u)]
assert mismatch, "expected at least one user where two flag keys disagree"

# 6. Audit log holds one entry per evaluation with its reason.
assert len(flag.audit) == 2 + 2 + 2 + 200 * 3 + 200
assert len(session_flag.audit) == 200
assert all(set(e) == {"user", "decision", "reason"} for e in flag.audit)
print(f"default-closed empty user: off; sticky user-1024: {'on' if first else 'off'} twice")
print(f"dial 0/20/100 over 200 users: {open_0}/{open_20}/{open_100}")
print(f"killed flag forces off; different flag keys disagree on {len(mismatch)} users, e.g. {mismatch[0]}")
print(f"audit entries: flag={len(flag.audit)}, session_flag={len(session_flag.audit)}")
print("PASS: default-closed, sticky bucketing, kill switch, dial, and audit log behave as asserted")

在百分之二十时，缺失用户保持关闭，紧急关闭覆盖全部具名用户，同一用户重复求值保持稳定。两百个固定测试用户在零、二十、一百三档，分别有零、三十五、两百人开启。三十五是这组输入的确定结果，不保证任意有限用户集合都精确达到百分之二十，也不说明相同比例的请求会使用新路径。

第二个求值器改变的是开关键，用户标识仍相同。因此它展示的是盐值或键漂移，不是真实的会话标识对照实验。审计条数证明每次求值都有一条记录。本地模型不测试分布式配置传播、请求内结果复用、数据库回滚或授权；这些仍是实际系统需要分别验证的集成责任，不能由本例的 PASS 自动推导。

来源

功能开关模式(Martin Fowler)，开关分类学，已核验 2026-10-15。
LaunchDarkly：什么是功能开关，渐进暴露，已核验 2026-10-15。
12 Factor：构建/发布/运行分离，配置与开关所在，已核验 2026-10-15。

蓝绿部署让两套环境随时待命

Mon, 02 Nov 2026 00:00:00 +0000

蓝绿部署在独立环境中准备新应用版本，同时让旧版本继续服务流量。就绪检查通过后，路由把新的工作导向新环境。保留旧环境可以缩短回滚，因为恢复不必等待重新构建。但这个模式本身并不保证全部依赖都有两份、切换瞬间完成，或每一项数据修改都可以撤销。发布方案必须明确哪些东西被切换，以及哪些状态仍然共享。

定义切换究竟控制什么

路由机制可能是负载均衡后端、服务选择器，也可能是 DNS。它们的传播与连接语义不同。修改一个控制面对象，不等于所有数据面实例在同一瞬间采用新值。权威配置已经改变后，DNS 缓存与既有连接仍可能访问旧地址，因此配置写入成功只能作为开始观察的时间点，不能直接作为全局完成证据。

应明确路由选择发生在每次请求、每条连接、每个会话，还是队列任务这一层。长连接可能继续留在蓝色环境，新连接则进入绿色；另一些代理会为每个请求重新选择上游。因此，最长客户端连接不一定决定所有部署的排空时间。需要记录实际机制及其超时、终止行为，并知道强制关闭会怎样影响正在执行的工作。

两套版本都应有能力承担分配给自己的流量与依赖，这并不意味着软件版本必须相同，也不意味着整个系统永远精确支付双倍费用。容量可以分阶段准备，数据库或辅助服务也可能共享。节省资源会改变恢复条件：若旧环境已经缩容到很小，切回路由也无法立刻得到原来的完整服务能力。

在重叠窗口内保持数据兼容

共用数据库很常见，但它是设计选择，不是蓝绿部署的定义。使用两个数据库会引入复制、同步和数据对账问题。反转路由不能抹去绿色环境已经接受的写入，也不能安全地凭空补出蓝色环境缺失的事务。应像定义请求流向一样，明确每类数据在切换和回滚时怎样处理。

共用存储时，可以用先扩展再收缩的方式支持版本重叠。先增加兼容字段，部署能容忍两种表示的读写逻辑，必要时回填数据，最后再删除旧结构。仅等待旧 HTTP 连接结束还不够：旧工作进程、定时任务、回滚版本以及外部消费者，都可能仍依赖旧模式。清理条件应覆盖这些实际使用者。

兼容性不仅是列名存在。两个版本可能都能解析字段，却把相同数值解释成不同单位。迁移可能导致查询报错、写入不一致，也可能造成稍后才暴露的数据损坏；不能断言一定损坏，也不能假定总会干净地拒绝操作。宣布回滚安全之前，需要执行具有代表性的读写路径，并检查业务结果而不只是健康检查。

坏掉的样子

切换期间看到两个版本，并不自动说明部署失败。排空、逐步传播或有意分流，都可能产生这种正常现象。只有客户端或共享状态无法容忍重叠时，它才成为故障。可在适当诊断中记录发布标识，然后将错误与路由状态、连接年龄及版本兼容性关联，避免把所有差异都归因于非原子切换。

反过来，同一个客户端连续五十次看到绿色，也不能证明全局原子性。它可能始终访问同一个边缘节点，或复用同一条连接。就绪副本数量也不能证明服务选择器、端点列表、入口控制器以及外部负载均衡器都指向这些副本。需要检查完整请求路径，并从具有代表性的客户端位置验证实际结果。

不要因为切换命令成功，就立即关闭蓝色环境。应预先定义回滚窗口，监控错误和延迟变化，并在不兼容清理前确认旧后台工作已经退出。如果回滚所依赖的状态已经不可逆改变，就需要前向修复或演练过的数据恢复，而不是反复拨动路由。保留一套进程，并不等于保留了所有恢复前提。

快速验证

用 Python 3 执行下面模型，保持断言开启。代码只改变内存字典：两个路由实例分别更新，已有会话保留当初选定的环境，而模式契约决定两个版本能否运行。这是明确写出的模型，并非某个负载均衡器的测量结果，也不是 Kubernetes 集成测试。

routers = {"edge-a": "blue", "edge-b": "blue"}
existing = {"session-1": "blue", "session-2": "blue"}
routers["edge-a"] = "green"
assert set(routers.values()) == {"blue", "green"}
routers["edge-b"] = "green"
assert set(routers.values()) == {"green"}
assert set(existing.values()) == {"blue"}
print("new routes green; existing sessions still blue")

required = {"blue": {"amount_cents"}, "green": {"amount_cents", "currency"}}
def compatible(schema, colour):
 return required[colour] <= schema
schema = {"amount_cents", "currency"}
assert all(compatible(schema, colour) for colour in required)
routers = dict.fromkeys(routers, "blue")
assert compatible(schema, "blue")
print("rollback remains schema-compatible")

# A destructive replacement can invalidate the old version.
required["green"] = {"amount_minor", "currency"}
schema = {"amount_minor", "currency"}
assert compatible(schema, "green")
assert not compatible(schema, "blue")
print("routing rollback cannot restore a removed column")

第一个断言暴露了路由实例更新到一半时的混合状态。即使两个实例都选择绿色，模型中的旧会话仍留在蓝色。追加字段后的模式支持切回旧版本，而后来破坏性的字段替换不支持。三行输出分别指出这些边界，不给出并不存在的通用切换时长，也不把进程存活等同于数据兼容。

随后应在隔离部署中，使用真实路由器、代表性流量和可回退的测试数据重复这些检查。分别测量传播、排空与回滚，并保留路由收敛以及应用兼容的证据。前者回答新工作去了哪里，后者回答两套版本能否正确处理当前状态；两类结果不能相互替代。

来源

Martin Fowler：蓝绿部署，该模式的原始论述，包含共享数据库这一前提，已核验 2026-09-16。
Kubernetes：Deployment，滚动更新、就绪与回滚语义，已核验 2026-09-16。
AWS：蓝绿部署白皮书，路由层切流及其代价，已核验 2026-09-16。
AWS Route 53 切流, DNS 缓存、加权切换及容量取舍，已核验 2026-10-15。

渐进发布需要证据与恢复路径

Fri, 18 Sep 2026 00:00:00 +0000

渐进发布一边扩大新版本的暴露范围，一边检查行为是否可以接受，可能在所有请求都切换之前发现退化。它不会自动让改动可逆，不保证只有选定比例的用户受到影响，也不一定需要功能开关。流量路由、实例替换和功能暴露是不同控制，可以共同参与一份发布计划。真正需要说明的是谁先接触变化、根据什么证据继续，以及异常发生之后怎样恢复服务。

明确人群及其共享依赖

百分比需要分母：请求、用户、租户和实例并不是一回事。百分之一的实例不一定处理百分之一的流量，一个繁忙客户也可能占据大部分请求样本。应选择能够覆盖相关工作负载的群体，而不是把数量很少当成安全证明。一个工作流需要多次请求都落在同一版本时，还要保持一致的分配，避免新旧行为在流程中交替出现。

新旧人群可能共享数据库、队列、缓存或配额。故障金丝雀能够耗尽共同依赖，也可能写入不兼容数据，使旧版本同样受影响。因此，百分之一的放量并不能把事故影响严格限制在百分之一。确定阶段之前，应盘点共享故障路径，尤其注意跨租户状态、公共连接池和异步消息，不能只看入口分流比例就宣布其他用户完全不会感知。

收集足以支持决定的测量

按金丝雀人群拆分错误率和延迟，与合适的对照群体比较，同时保留绝对的服务目标。如果共同依赖让两个版本都坏了，二者指标相近不能证明健康。发布前就应定义观察窗口、最小流量、相关路由，以及测量缺失或过旧时的处理。十个请求没有错误，与大量代表性请求没有错误，证据强度不同；分母不足时不应把零直接解释成通过。

阶段时长应覆盖准备评估的效应，例如启动、缓存预热、长任务、延迟写入及业务周期。三十秒既不是天然足够，也不是天然没有价值。承接一半流量也不能证明满量容量，因为非线性瓶颈可能在后面才出现。满量之后仍需监控，并明确何时算发布完成。观察不是等待一个固定数字过去，而是取得足够新鲜、相关、可解释的证据。

坏掉的样子

只靠定时器的发布，即使没有取得有效测量也会继续晋升。证据不足时应暂停，由明确负责人在约定时间内调查，不能悄悄按成功处理。自动回滚在触发条件与恢复动作都经过验证时可以缩短响应时间，但有些故障需要值班人员判断。自动化是一种执行手段，不会证明恢复操作本身没有风险；暂停也不能无限无人接手。

另一种失败，是认为恢复旧二进制就能恢复旧状态。数据库模式、已持久化格式、已经发出的消息和外部副作用，都可能在流量切回以后继续存在。应保留仍兼容的旧产物，并演练真实恢复路径。如果反向切换不安全，应准备向前修复或业务对账方案，不要展示一个实际上无法恢复服务的回滚按钮。发布可逆性来自这些设计条件，而不是来自阶段名称。

全量平均会掩盖局部退化。假设旧版本错误率为零，处理十分之一请求的金丝雀出现百分之十五错误，摊到全量后只有百分之一点五。算术上的稀释并没有使故障人群变得可以接受。需要同时观察群体拆分、业务结果和整体健康，而且对照组自身也必须正常。不同人群的流量类型差异，还可能让简单比较失去解释力。

快速验证

保存为 rollout_check.py，用 Python 3.10 或更新版本执行 python3 rollout_check.py。本轮以 Python 3.12.14 完整运行。下面是使用虚构请求计数的确定性决策模型，不是部署控制器；它不会改变路由，不等待真实遥测，也不实际执行回滚。最小请求数和错误阈值都是教学参数，不应直接作为生产服务目标。

from dataclasses import dataclass

STAGES = (1, 10, 50, 100)
MIN_REQUESTS = 1000
MAX_ERROR_RATE = 0.02 # Illustrative gate, not an SLO error budget.


@dataclass(frozen=True)
class Sample:
 requests: int
 errors: int


def decide(sample):
 if not 0 <= sample.errors <= sample.requests:
 raise ValueError("invalid request/error counts")
 if sample.requests < MIN_REQUESTS:
 return "PAUSE", None
 rate = sample.errors / sample.requests
 return ("ROLLBACK_REQUESTED" if rate > MAX_ERROR_RATE else "PROMOTE"), rate


def plan(samples):
 history = []
 for stage in STAGES:
 decision, rate = decide(samples[stage])
 history.append((stage, decision, rate))
 if decision != "PROMOTE":
 break
 return history


healthy = plan({stage: Sample(2000, 10) for stage in STAGES})
faulty = plan({stage: Sample(2000, 300) for stage in STAGES})
missing = plan({stage: Sample(0, 0) for stage in STAGES})
sparse = plan({stage: Sample(100, 0) for stage in STAGES})
assert [row[0] for row in healthy] == list(STAGES)
assert all(row[1] == "PROMOTE" for row in healthy)
assert faulty == [(1, "ROLLBACK_REQUESTED", 0.15)]
assert missing == sparse == [(1, "PAUSE", None)]
assert decide(Sample(1000, 20)) == ("PROMOTE", 0.02)
assert decide(Sample(1000, 21)) == ("ROLLBACK_REQUESTED", 0.021)
for sample in (Sample(-1, 0), Sample(10, -1), Sample(10, 11)):
 try:
 decide(sample)
 except ValueError:
 pass
 else:
 raise AssertionError("invalid sample accepted")

# A 10% canary at 15%, with a zero-error control, gives 1.5% fleet errors.
fleet_rate = 0.1 * 0.15 + 0.9 * 0.0
assert fleet_rate < MAX_ERROR_RATE
for label, history in (("healthy", healthy), ("faulty", faulty),
 ("missing", missing), ("sparse", sparse)):
 print(label, history)
print(f"fleet dilution: {fleet_rate:.1%}; rollback was requested, not executed")

健康样本会通过四个阶段，故障样本在第一级返回请求回滚。没有测量与只有一百个请求的零错误样本都会暂停。边界断言允许恰好百分之二，拒绝百分之二点一；不合法的请求和错误计数则触发校验失败。这些检查说明代码如何决策，没有证明阈值具有统计合理性，也没有测量不同流量分配是否真正落实。

最后的计算用明确假设的零错误对照展示全量稀释。真实发布还必须验证群体可比性、遥测新鲜度、观察时间和恢复动作的实际结果。返回 ROLLBACK_REQUESTED 只是一项决定，服务是否恢复必须另有执行结果和健康证据。把这两个阶段分开记录，才能避免流水线打印了成功，却仍有故障版本在处理请求。

来源

Google SRE：金丝雀发布，群体比较、共享故障域与观察区间，已核验 2026-10-15。
Argo Rollouts：分析，成功、失败和无法判定时的处理，已核验 2026-10-15。
Google SRE：发布工程，可复现产物与发布自动化，已核验 2026-10-15。

部署 · XB 现场笔记

变更窗口为人设计，不是为服务器

流量只是算式的一半

尊重人的时钟

让窗口成为习惯

坏掉的样子

快速验证

延伸阅读

来源

滚动更新分批换上新版本

浪涌与缺口

健康是换班的门槛

选一个有意为之的节奏

坏掉的样子

快速验证

延伸阅读

来源

让已经验证的产物逐级进入环境

明确究竟把什么向前传递

坏掉的样子

快速验证

核对真正运行的发布组合

延伸阅读

来源

功能开关把发布与暴露解耦

在明确的门控后部署

按含义选择默认行为

用稳定身份逐步开放

坏掉的样子

快速验证

延伸阅读

来源

蓝绿部署让两套环境随时待命

定义切换究竟控制什么

在重叠窗口内保持数据兼容

坏掉的样子

快速验证

来源

渐进发布需要证据与恢复路径

明确人群及其共享依赖

收集足以支持决定的测量

坏掉的样子

快速验证

延伸阅读

来源