浏览器部署与发布：运维决策地图

浏览器部署是一套复核顺序，不是一串开关。这个枢纽把部署主题簇连起来，并给出一份有边界的发布记录：写明容量决策、构建选型、验证结果和回滚路径。起点是浏览器发布验证。

BotBrowser 支持在容器和长驻服务器中运行授权的 profile，并能保持浏览器可见值与 profile 一致；它不能替你决定基础设施规模、保证某个厂商构建可用，也不能判断某次发布对你的产品是否可接受，它不替代你自己的容量与回滚测试。

TL;DR

• 容量来自实测并发，而不是某个主机恰好扛住的最高数字。
• 把浏览器构建和 profile 类别与发布记录写在一起。
• 在真正承载负载的主机规格上验证。
• 带着回滚路径发布，并保留让这个决定可被复核的证据。

目录

• 四组部署能力面
• 按顺序走部署主题簇
• 做一次发布复核
• 记录与发布声明
• 判断第一个失败
• 实践结论

四组部署能力面

一次浏览器部署有四组运维能力面。容量覆盖一台主机能承载多少上下文、内存如何回收、哪些上限是测出来的而不是假定的。构建选型覆盖你安装的包：标准版还是精简版、目标平台，以及它背后的驱动栈。发布验证覆盖切流之前检查了什么：profile 能否加载、页面能否渲染、交互是否正常。证据与回滚覆盖发布之后剩下的东西：解释这次决定的记录，以及回到上一版本的路。

容量还取决于BrowserContext 容量规划里描述的上下文预算，所以在公布并发数字前要把两者一起读。

四组失效方式不同，暴露的时间尺度也不同。容量上限在持续负载下出现，常常是在第一个成功请求之后几个小时。构建选型问题表现为缺库，或者容器根本不提供的渲染路径。验证缺口表现为实验室里可用、生产里失败的交互。缺少回滚路径，会把一次本来可恢复的坏发布变成一场和诊断耗时一样长的故障。

BotBrowser 在这里的作用，是让浏览器可见身份在这些上下文之间与声明的 profile 保持一致。这种一致性让差异可以归因：如果两个使用同一 profile 的容器互相不一致，原因大概率在部署能力面，而不是某个没被管住的变量。

按顺序走部署主题簇

• 浏览器发布验证确定发布前必须检查哪些 profile、版本和回滚状态。
• Docker 浏览器自动化给出可复现的容器基线。
• Ubuntu 服务器上的无头浏览器部署覆盖服务器前置条件。
• Linux x64 上选标准版还是精简版比较两种打包版本。
• Mesa llvmpipe 与 SwiftShader覆盖 Linux 上的渲染后端选择。
• 扩展浏览器上下文覆盖规模化时的逐上下文 profile。
• BrowserContext 容量规划把内存测量变成上下文预算。
• 浏览器容器资源上限把 CPU、内存和磁盘上限放在一起看。
• 浏览器自动化性能覆盖工作负载的运行成本。
• 可靠的截图捕获覆盖这类部署最常见的输出。

枢纽只负责复核顺序和发布记录格式，具体到某一面的失败与细节留在对应文章里。。

做一次发布复核

在测量任何东西之前先写下声明输入：主机规格、浏览器构建、profile 类别、预期并发，以及你打算运行的工作负载。然后在同一次复核里每一面记一行，这样后来的差异才有参照点。

{
  "runId": "deploy-review-20261019-01",
  "declared": {
    "hostClass": "8 vCPU / 16 GB",
    "browserBuild": "standard-linux-x64",
    "profileClass": "fresh-temporary",
    "expectedConcurrency": 24
  },
  "observed": {
    "capacity": "24-contexts-stable-30min",
    "build": "profile-loaded-renderer-recorded",
    "validation": "owned-fixture-passed",
    "rollback": "previous-build-redeployable"
  },
  "firstFailure": null,
  "testedOn": "2026-10-19"
}

记录是数据，不是报告。它应当短到能贴进一次故障讨论，又明确到另一位运维可以在同一主机规格上重跑这四行。要在复核过程中填写，而不是事后补：凭记忆写出的记录往往描述的是打算使用的配置，而不是主机实际运行的配置，而这两者的差异比团队预期更常见。

有意识地选择构建和后端

是两个独立决定，各自都会改变部署能做什么。标准版带有完整渲染栈；精简版缩小了包体和攻击面，对一个范围很窄的负载可能是正确选择。两者在生产里并没有普遍更快的一方：吞吐取决于你加载的页面以及它们走的渲染路径。

在 Linux 上，图形后端决定页面是走 llvmpipe 这类软件光栅化，还是 --use-angle 选择的硬件路径。没有 GPU 的主机通常只能用软件渲染，这在容器里很常见，而它在 WebGL、canvas 和字体渲染上的行为并不相同。记录部署实际使用的后端，并在各次发布之间保持一致。两次其他方面完全相同的构建之间出现后端变化，就是一次渲染变化，必须写进发布说明。

在你真正运行的工作负载上、在你真正部署的主机规格上比较两个版本和两种后端。在工作站上得到的比较回答的是另一个问题。当比较结果接近时，优先选择回滚路径更简单的配置；两分钟就能重新部署，比一点吞吐差异更有价值。

先在主机上规划，再发第一个请求

大多数浏览器部署先在主机上失败，然后才在浏览器里失败。一个能干净启动的容器，仍可能在截图高峰里耗尽共享内存、用光文件描述符或撞上磁盘配额。把这些上限放在一起复核，才能把一次成功变成可重复的部署。

容器内存上限应当来自单个上下文实测的工作集，乘以你真正打算运行的并发，再加上你在同一主机规格上实测到的浏览器进程开销。不要把厂商宣传的最低配置当作上限：那是能启动的下限，不是反映你工作负载的数字。带大缓冲区的转换任务和带大量打开页面的截图任务，在同一台主机上会得出不同的数字。

给浏览器一块可写的共享内存区域，例如 --shm-size=1g，并在容器内用 df -h /dev/shm 确认。很多容器运行时默认的 /dev/shm 很小，分不到足够共享内存的浏览器在负载下会崩溃渲染进程，而不是在启动时崩溃。要显式设置大小，把数值写进发布记录，并在基础镜像变化时重新检查。临时存储同理：浏览器会写缓存和会话数据，只读文件系统会以看起来像应用 bug 的方式失败。

文件描述符和进程上限也要看。每个上下文、每个 Worker、每个大页面都可能占住多个描述符，实验室里宽松的上限，在同一个容器承载两倍流量时就会变紧。记录你设置的上限，而不是你继承来的默认值。

记录与发布声明

故障复盘会问四个问题：部署了什么、部署在哪里、用了哪个 profile，以及自上次正常发布以来改了什么。一份能回答这四个问题的记录，能省下调查的第一个小时。它不需要复杂，只需要把主机规格、构建、profile 类别、并发、fixture 版本和验证结果放在一起，并带上日期。

把记录放在 docs/blog-release-batches.json 旁边，而不是聊天记录里。准备下一次发布时，对比两条记录能直接看出哪些输入变了，而这个对比通常就是回溯回归原因最快的路。贴在工单里的记录无法与任何东西比较，而两份文件可以逐行 diff。

保留期限要和产品负责人一起定，通常与 supportWindow 一致。一份解释发布的记录在该发布的支撑周期内有用，例如 retentionDays: 90；永久保存只会让存储变成噪音。一条写明发布、移除原因和移除日期的短备注就够了。

发布复核也是决定这次部署可以声称什么的地方。如果部署跑在带噪声邻居的共享主机上，容量数字就是下界而不是保证，记录应在 hostClass 旁边注明这一点。如果部署使用托管卷，第一分钟的 I/O 并不具代表性。把这些约束写进发布记录，之后的性能投诉才不会变成关于测量方法的争论。

把第一个生产窗口当作验证的一部分，而不是验证之后的形式。观察你在实验室记录的同样四行：容量、构建、验证和回滚准备。一次在实验室通过、在第一个小时退化的发布，不是失败发布，而是容量那一行测得太短的发布。纠正动作是更长时间的测量，而不是更大的主机，直到曲线给出别的结论。

工作负载变化时，重跑复核而不是外推。新的页面类型、更大的上传或额外的标签页都会改变工作集和描述符数量，之前的容量数字不再描述这个部署。从相似负载外推，正是上季度能承载二十个上下文的容器，这季度在十二个就失败的原因。

即使引用同一次发布，也要把部署记录和故障记录分开。部署记录说明打算做什么、实测了什么；故障记录说明发生了什么、做了什么决定。把两者合并，会让发布决定看起来像事后判断，也会掩盖「发布在故障之前就已经复核过」这一事实。

第一个平静的周之后也要复核部署，不只是出问题之后复核。一次留在容量行之内、没有意外的部署，和前一次需要回滚的部署一样值得记录，因为下一位复核者需要一个基线来对比。只由故障构成的历史，无法显示正常发布在这台主机规格上是什么样，所以平静的发布也要留在同一份 singleReleases 清单里。

判断第一个失败

如果 profile 加载不上，就停下：后面几行描述的是一个没有按你声明运行 profile 的浏览器。如果页面渲染了但交互失败，先查 fixture 版本和驱动栈，再看主机。如果交互通过而输出不同，比较渲染后端和 profile 类别。如果全部通过但主机仍然报压力，把它当作容量发现，在更低的并发下重新测量，再改别的东西。

点名能力面、保留记录，每次重试只改一个声明输入。一次以一个具名失败收尾的部署复核，比一次列出十几条无人认领观测的复核有用。具名失败也让下一次复核更短：团队知道该盯哪一行、先改哪个输入。

实践结论

当容量、构建、验证和回滚被一起记录时，浏览器部署才是可复核的。用这个枢纽确定复核顺序，用主题簇获取细节，所有结论都限定在产生它的那个主机规格、构建和 profile 之内。

来源

• MDN：跨源资源共享与容器部署说明
• W3C：Web 内容无障碍指南
• WHATWG：HTML 标准中的 Worker
• BotBrowser 文档：部署
• BotBrowser 文档：profile 格式