工程实践Oxide Public RFDs
该 RFD 规划 Oxide 为 cosmo 计算节点与 minibar 制造平台执行的一次 RoT 代码签名仪式：为 RoT 支持的 4 个信任锚点建立专用代码签名 PKI 根，由 permslip 认证中间签名者并签署调试凭据，同时为不参与机架信任仲裁的 minibar 建立平台身份 PKI。文章重点论证用标签打印机替代手工抄录摘要值，以降低人为错误，并在无无线、体积、Linux 驱动支持等约束下对比 Brother QL-600 与 Dymo LabelWriter 550 的选型。文中还给出 YubiHSM 对象数与字节容量的精确估算，说明新增密钥后仍余量充足，并讨论了 USB 外设的侧信道/功耗分析风险与安全存储要求。边界在于地点、仪式脚本等内容被脱敏，且方案依赖既有的 offline-keystore 软件，标签打印属未验证的优化项，不能阻塞 cosmo 交付。
推荐收录：这不是流程公告，而是一份带真实约束、取舍与可验证数据的工程文档——包含 HSM 存储容量的量化估算、标签打印机在无无线/Linux 支持/体积上的对比，以及外设侧信道风险的明确分析。对负责硬件信任根、代码签名、密钥仪式或安全制造流程的工程与安全读者具有可迁移价值，可参考其仪式降错思路、选型标准和空间预算方法。主要局限是关键脚本与地点被脱敏，读者无法完整复现仪式细节。
工程实践Oxide Public RFDs
RFD 619 讨论 Oxide 在 Dropshot HTTP API 服务端版本化后如何组织已发布类型，以降低新增 API 版本的修改负担。作者提出为每个 types crate 配套 versions crate，集中定义所有历史版本，types crate 仅重导出 latest，API trait 只依赖 versions crate，业务逻辑只依赖 types crate。核心规则包括：类型定义在最早出现版本，后续变更在新 vN 模块，相邻版本用 From/TryFrom 或 from_vN/into_vN 转换，非版本代码放 impls 模块，最新端点用 floating identifier、旧端点用 versioned identifier。文中还给出一次性迁移与新增版本指南，并论证旧方案、域优先嵌套、独立 conversion 模块等替代方案被拒原因。其适用边界是 Oxide/Omicron 的 Rust、Dropshot、OpenAPI/Progenitor 技术栈，外部团队需按自身仓库结构与兼容策略调整。
推荐收录：该 RFD 包含完整的动机、原则、determinations 和逐项 rationale，并用真实 PR 说明旧类型组织方案的维护痛点，属于可复核的工程决策证据。适合维护长期兼容 HTTP API、使用 Rust/Dropshot/OpenAPI 或需要设计服务端版本化的后端与基础设施团队阅读；versions crate 分层、按最早版本存类型、相邻版本转换等规则可迁移到其他 API 版本化场景。风险是它绑定 Oxide 特定 crate 命名与工具链，外部团队需按自身边界调整。
职业经验Oxide Public RFDs
这篇 Oxide RFD 讨论前员工重新加入公司的招聘政策。作者以 Sun Microsystems 曾欢迎前员工回归为引，指出 Oxide 鼓励员工自由离开，以降低回归障碍。核心判定是：前员工申请开放职位时不应简化流程，而须像初次应聘一样提交材料，并更新内容以反映在 Oxide 及离开后的经历，而非复用旧材料。这既能促使申请人反思回归动机，也便于与未曾共事过的同事建立了解，并允许申请不同岗位。文章强调统一流程有助于维持招聘透明度和团队协作。其局限是篇幅较短，主要面向 Oxide 内部文化，缺少更广泛的数据和工程实践验证。
推荐收录。文章直接给出 Oxide 前员工回归的明确判定：必须走与普通候选人相同的申请流程并提交更新材料，而非复用旧材料。其“让离开更容易也让回归更自然”及用统一流程维护透明与协作的思路，对工程管理者和招聘负责人有迁移价值；局限是篇幅短、偏组织文化，不涉及技术实现。
技术文章Oxide Public RFDs
本文是 Oxide 的 RFD 552，讨论硬件/软件接口透明性应成为系统厂商选择硬件的前提。作者先将接口分为 ISA、数据接口与控制接口，并区分 HAL、实现负载等非接口概念，继而提出五级透明性框架：公开文档、私下无约束文档、开源 HAL、逆向工程、有约束的私下文档（最不可取）。文章逐条反驳厂商常见反对理由（被复制、支持负担、安全风险、第三方协议），并揭示文档不完整、代码有 bug、暴露错误、他人写软件等未明说的恐惧。结论是透明性近乎零成本，能催生编译器、OS、调试器等生态，而封闭会阻碍跨层创新；Intel 与 Linux 的共生被作为论据。其边界是公司立场文件而非量化研究，但提供了可复用的接口透明性评估框架。
推荐收录。文章给出可操作的接口分类和五级透明性模型，并用 Renesas 电源控制器、AMD openSIL、LPC55S69 逆向、Lattice iCE-40 等实例支撑，不是泛泛呼吁开源。适合硬件/软件协同设计、基础设施、SoC 选型与开源战略相关读者，可用于制定供应商接口文档要求和评估封闭接口的长期成本；但需注意其立场源于 Oxide 的全面开源目标，未必适用于所有商业约束。
职业经验Oxide Public RFDs
本文是 Oxide 的 RFD 537，说明公司远程化后从录制 All Hands 扩展到几乎所有会议，并正式确立“录制每个会议”的政策。作者以透明、团队协作、严谨、同理心与节俭等价值论证录制会议：可减少转述失真、方便回看、帮助新人融入和缺席者追赶，并沉淀技术细节。政策除晨间闲聊、招聘/1:1 等人事会议及拒绝录制的外部会议外，要求计划会议、临时讨论、调试、客户与合作伙伴对话都录制，推荐 Google Meet 自动录制与转录。文中给出有疑问先询问、随时可补录等原则，安全与隐私引用 RFD 455；其适用边界是依赖 Oxide 文化与 Google Meet 生态、需参与者同意，受合规隐私限制的组织要调整。
推荐收录。该 RFD 不是简单宣布政策，而是逐条论证录制会议的透明、协作、严谨、同理心等价值，并给出 Google Meet 自动录制步骤、必录/不录清单和例外处理，可作为工程组织制定会议与知识留存规范的参考。适合远程协作团队、工程管理者及关注工程文化的读者；迁移时需结合隐私合规、外部参会者同意和存储安全，不宜直接照搬。
工程实践Oxide Public RFDs
这份 RFD 定义了 Oxide 的安全事件响应计划：如何声明、分级、研判、调查和复盘安全事件，以保护产品与系统完整性、客户数据及公司运营。范围覆盖 Oxide Cloud Computer 及周边软件的生产、构建、签名、制造和更新分发系统，并支撑 SOC for Supply Chain 与 SOC 2；客户环境事件通常不在范围内，除非出现产品漏洞被利用或客户数据受影响。文档规定了 Incident Manager、通信负责人、高管、法务等角色，按 SEV-0 至 SEV-3 分级并给出响应投入。生命周期为声明、遏制、调查、恢复、关闭与复盘，SEV-0/1 及部分 SEV-2 需完成无责复盘，还规定记录系统、编号、证据、纠正项和外部通知触发条件。其边界是高度依赖 Oxide 的组织与合规语境，不直接覆盖客户环境的一般安全事件。
推荐收录。它提供了一份可审计、可执行的安全事件响应模板，包含分级示例、角色默认分配、响应生命周期和通知触发条件等直接证据，适合安全工程师、SRE/运维负责人和合规工程团队参考。其价值在于把供应链安全、事件复盘和组织职责落到可迁移流程；但读者需注意它绑定 Oxide 的 Google Workspace/GitHub 等工具与合规边界，不能照搬。
工程实践Oxide Public RFDs
该 RFD 为 Oxide 云平台上的虚拟机实例提出身份与远程证明方案：目标是把测量链从平台 RoT 扩展到实例的启动盘摘要、UUID 与配置，向 guest 暴露证明接口，并把实例持有的临时公钥绑定到平台证明。方案用 qualifying data 把 nonce 或附加数据混入签名，propolis 作为 VM Instance RoT 将 JSON 格式的实例日志经哈希后交给 Oxide Platform RoT 签名，从而在 propolis 无签名密钥时仍能绑定实例信息。通信通道选择 vsock，采用 JSONL 协议和单一 attest 命令，32 字节 qdata 可扩展为 digest(nonce|key_pub) 以完成密钥绑定。性能测试显示平台 RoT 是瓶颈，attest 平均约 104 ms，证书链约 120 ms。当前实现只覆盖 Oxide 平台 RoT，对可变启动盘、非开源组件和 API 向后兼容性有明确限制。
推荐收录：该 RFD 系统性地给出 VM 身份与证明设计，包括 qdata 绑定、测量链扩展、vsock/JSONL 接口、SPDM 对比和 gimlet 时延基准，证据具体。适合云平台、虚拟化安全、远程证明与机密计算方向的工程师阅读；其中 nonce 加日志哈希绑定、无签名 RoT 委托签名模式和接口取舍可迁移。风险是早期设计，初始 API 可能破坏兼容且未覆盖全部 RoT/闭源组件。
工程实践Oxide Public RFDs
该 RFD 分析 Flex BMR491 IBC 在 R1C 及更早版本中的设计缺陷：输入欠压保护误触发会使 12V 输出瞬时跌到约 8V。作者反推 Flex 的缓解方案和 PMBus 寄存器数学，发现其 MAX_DUTY 常量存在字节序错误，按 LINEAR11 重新推导出 95% 占空比对应 0xeaf8。结合 Oxide 各机型热插拔阈值，文章判断 Gimlet/Sidecar 实际不会降到 35V，只有 Cosmo 需要启用 VOUT 欠压保护。最终决定仅对 R1C 关闭 VIN 欠压、不持久化配置，并在 A2 状态由 Service Processor 写入，以规避竞态和 STORE_USER_ALL 风险；局限是 R1D 修复尚未验证。
推荐收录：这是一份真实硬件/固件工程决策记录，包含设计缺陷机理、厂商缓解方案、PMBus 寄存器反推、错误常量验证和多机型约束取舍，证据链完整。适合固件、硬件系统、电源与可靠性工程师阅读；其“批判性重算供应商配置、按修订版本灰度启用、避免持久化写风险”的方法可迁移到类似嵌入式/基础设施维护场景。
工程实践Oxide Public RFDs
本文是 Oxide 的 RFD 595，扩展 RFD 493，系统设计面向 Oxide 云盘的 Kubernetes CSI 插件。文章解释 CSI 的 CO、SP、工作负载、卷与节点术语，以及 Identity/Controller/Node 服务和 sidecar 部署模式，并按卷生命周期把 RPC 映射到 Oxide API：CreateVolume 用 POST /v1/disks，ControllerPublishVolume 用 attach，NodeStage/NodePublish 在 Linux 上分区格式化并挂载，卸载和删除分别用 detach 与 DELETE。文中给出 Deployment、DaemonSet、CSIDriver、StorageClass 与 PVC 示例，并列出热插拔需停机、单实例最多 8 盘、设备令牌认证、无法扩容/克隆、仅支持 SINGLE_NODE_WRITER、多机架拓扑未定等限制；首版仅支持创建删除、挂载卸载和快照恢复。
推荐收录。该 RFD 不是概念介绍，而是给出 CSI RPC 到 Oxide API 的逐项映射、Kubernetes 部署 YAML 与明确的阻塞/限制/开放问题，适合 Kubernetes CSI 驱动开发者、平台与存储工程师阅读。其 sidecar 模式、卷生命周期处理、幂等与拓扑约束分析可迁移到其他存储插件设计；但内容绑定 Oxide API 且仍处讨论状态，读者需注意版本与实现可能变化。
工程实践Oxide Public RFDs
本文是 Oxide 工程经验 RFD，记录控制平面 Omicron 使用分布式 Saga（Steno）执行实例启动、磁盘创建、区域替换等流程时的问题。作者指出 Saga 要求动作幂等、未定错误必须重试、永久错误不可重试、补偿不可失败，这些约束难以编码和验证；静态 DAG 与软件升级强耦合，卡住或废弃的 Saga 无法自动恢复，更新可能阻塞或冒险恢复。文章比较背景任务/协调器模式：周期性重取状态、每次只决定下一步，并用事务、声明式 API 和 generation 号保证并发安全，使错误可由软件更新修复且不阻塞升级。结论是新增工作应优先考虑背景任务，选择 Saga 必须规划废弃与修复；但作者并未主张完全移除 Saga，部分场景改写仍有挑战。
推荐收录：该 RFD 以 Oxide 生产系统为证据，系统梳理了分布式 Saga 在幂等、未定错误、补偿失败、升级和废弃恢复上的具体故障模式，并给出 reconciler/background task 的替代设计与并发安全手段。对构建控制平面、工作流引擎、分布式事务或可靠性系统的工程师与研究者有很高迁移价值，可帮助在 Saga 与协调器模式间做架构取舍；需注意其结论绑定 Oxide 的 Omicron/Steno 场景，并非通用定论。
工程实践Oxide Public RFDs
该 RFD 由 Oxide 提出，用于解决 Dropshot 版本化 OpenAPI 文档在 Git 中的存储难题：新增版本会被识别为全新文件，造成上万行 diff、失效的 blame 与工作副本膨胀。核心方案是 Git stub 文件——用 `<commit-hash>:<path>` 单行文本替代历史版本的 JSON，使 Git 将新版本识别为重命名而非新文件，从而恢复可读 diff 与 blame，并把 Omicron 工作副本从 76MiB 降至 46MiB。文中给出精确的转换规则（仅对已 blessed、非最新、且非同一提交引入的版本生效），说明了与 Progenitor 通过 Cargo build script 集成的做法，并系统对比了外部工具、current copy、diff chain、Git LFS、仅历史等替代方案。主要代价是解引用 stub 依赖完整 Git 历史、不兼容浅克隆，并会引入 rename/rename 合并冲突，需要 API manager 扩展冲突处理。
推荐收录。这是一份完整的设计文档：明确的问题（大 diff、blame 失效、仓库膨胀）、可验证的效果（工作副本降 39%）、带对比表的替代方案分析和已落地的实现状态，并诚实列出浅克隆、source archive、合并冲突等边界。对设计版本化 API 存储、开发者工具链或 Git 工作流的团队有直接迁移价值：用指针文件替代不可变历史、借重命名启发式恢复 diff 与 blame 的思路可复用；风险是需完整 Git 历史与额外冲突处理复杂度。
工程实践Oxide Public RFDs
该 RFD 提议 Oxide 开发并维护官方 Packer 插件，让用户用 Packer 构建定制化 Oxide 镜像，满足应用、OS 与安全需求。文章对比运行时与构建时定制，认为插件可减少配置漂移并降低迁移摩擦。设计上插件用 Go 实现并基于 Oxide Go SDK，包含 oxide-instance builder 和 oxide-image data source，支持内置 provisioner 与 SSH/WinRM。文中给出配置结构、接口注册、验收测试、安全日志脱敏及开放问题，并说明当前尚未实现、配置可能变化，且不含 post-processor/provisioner 组件。
推荐收录，因为该 RFD 以可执行工程设计为核心，给出了插件组件划分、Go 接口、配置字段、验收测试、日志脱敏和迁移路径，而非产品发布宣传。适合基础设施/平台工程、IaC 工具开发及需要构建黄金镜像的读者，可迁移到其他 Packer 插件或平台集成设计；主要风险是提案尚未落地，实现细节可能调整。
工程实践Oxide Public RFDs
RFD 532 讨论 Oxide 内部 HTTP API 在控制面驱动在线升级中的版本化问题。因分布式组件无法原子更新，旧客户端与新服务端混用可能令升级卡死；作者按更新顺序提出 lockstep、仅服务端版本化、客户端版本化三种策略，并优先前两者。系统通过 API 依赖图决定组件更新顺序，并用自动化测试在合入 main 前拦截破坏升级的变更。客户端版本化需 Reconfigurator 告知可用 API 版本，客户端周期性查询并可能持久化，但实现与测试更复杂。该方案只覆盖 API 语法兼容，不解决语义破坏；switch zone、host OS 依赖和客户端元数据仍是开放问题。
推荐收录：这是一份完整的设计决策记录，给出 lockstep、仅服务端、客户端三种 API 版本化策略的选择依据，并把更新顺序、依赖图、自动化测试与开发者工作流放在同一约束下讨论。适合分布式系统、API 平台和基础设施团队参考；可迁移点是先确定组件更新顺序，再选择版本化策略，并用自动化防止依赖假设失效。主要不足是只处理语法兼容，客户端版本化路径尚不成熟。
工程实践Oxide Public RFDs
RFD 609 提出并系统分析了 async Rust 中的 futurelock：一个任务负责轮询多个 Future，却停止轮询持有共享资源的 Future，导致其他 Future 永久等待。文章用可复现的 tokio::select! 示例说明，当分支使用 &mut future 且在其他分支的 handler 中 await 时，已启动但未完成的 Future 不会被取消，锁的等待队列和 select! 的提交行为共同造成死锁。作者还复盘了 Omicron 中数据库访问全部挂起的真实故障，给出通过 DTrace 定位 mpsc 发送阻塞的调试线索。确定部分给出了规避建议：避免任务停止轮询已启动的 Future，优先用 tokio::spawn 或 JoinSet，谨慎在 select! 分支中 await，并重新审视有界通道的阻塞 send 模式。局限是问题高度依赖运行时语义，调试困难，且没有一劳永逸的抽象或编译器检查，需逐例判断。
推荐收录，因为它把一次真实线上挂起抽象为可复现的 futurelock 机制，并给出 tokio::select!、Mutex 等待队列、任务轮询职责之间的因果链。对使用 async Rust/Tokio 的工程师、维护高并发服务或做代码评审的人有直接迁移价值；局限是结论依赖运行时语义，调试与规避仍需逐例判断。
工程实践Oxide Public RFDs
Oxide RFD 538 定义了机架控制平面对外提供 Webhook 通知的 API 契约。事件按层级化 event class 分类，订阅支持 * 与 ** 通配符，每个事件带全局唯一 UUID，用于跨接收方关联与去重；接收方需注册 endpoint 与至少一个 HMAC 密钥，密钥只能新增或删除以支持轮换。投递为 HTTP POST JSON，携带 delivery-id、webhook-id、event-class、event-id 与 x-oxide-signature 头，采用至少一次语义，失败最多重试三次（1 分钟、5 分钟后），3xx 视为失败，2xx 即确认且不再重投。文档还用 probe 事件做存活探测与失败事件重发，并附有可靠接收方的实现建议。边界是只保证至少一次、不保证投递顺序，且目前仅 fleet.admin 可创建 Webhook、统一以 fleet.viewer 权限运行，细粒度 RBAC 留待后续。
推荐收录。这是一份生产级 Webhook 接口契约，直接给出了多密钥 HMAC 轮换、至少一次投递与重试退避、3xx 视为失败、probe 探活配合失败事件重发等可迁移的设计决策，并明确写清失败语义与权限边界。适合设计事件推送或对外集成 API 的后端与平台工程师参考，附录的接收方可靠性要求也可直接当作对接方检查清单。
职业经验Oxide Public RFDs
Oxide Computer 的 RFD 576（作者 Bryan Cantrill）系统讨论工程组织应如何规范使用大语言模型。文章以责任、严谨、同理心、团队协作、紧迫性五个价值观（按优先级排列）为判断基准，强调人类始终在环并须为 LLM 产出负责。随后逐类拆解用途：作为读者、研究者、编辑、写作者、代码审查者、调试者和程序员，分别给出适用方式与边界，例如研究须回归原始来源、公共与个人写作应避免代笔、贴近生产的代码需自审且进入同行评审后不宜整体重生成。文章还归纳三类反模式：强制使用、羞辱使用者与拟人化。它是一份政策与价值观导向的准则，可迁移性强，但属经验判断，未提供实验或量化验证。
推荐收录。它把 LLM 使用从工具技巧上升为可执行的团队规范：用价值观排序支撑具体规则，并对阅读、研究、写作、代码审查与编程等场景给出差异化边界，还点名强制使用、羞辱与拟人化三类反模式。适合工程负责人、技术写作者和正在制定 AI 使用规范的团队参考，其框架可迁移到其他组织的治理讨论；局限在于它是政策主张而非实证研究。
技术文章Oxide Public RFDs
Oxide RFD 400 系统讨论 async Rust 的取消安全与取消正确性。作者把取消安全定义为单个 future 的局部属性，把取消正确性定义为系统级全局属性，并梳理 select!、timeout、try_join、task abort、runtime shutdown 等取消来源。文章给出库作者和调用方的处理模式：拆分复杂操作、reserve permit、恢复部分进度、协作式取消、避免 tokio::sync::Mutex、用后台任务隔离 cancel-unsafe 操作，并以串口代理、installinator、write_all_buf 等案例说明取舍。结论是取消安全没有银弹，需结合 Tokio 语义和业务边界逐案验证。
正文以 Oxide 控制面开发中的真实问题为背景，系统定义 cancel safety/cancel correctness，并给出 select!、timeout、try_join、task abort 等取消源和 reserve、部分进度恢复、协作取消等可迁移模式，还附多个生产案例。适合编写或评审异步 Rust 服务、库 API 与分布式控制面的工程师；主要风险是结论依赖 Tokio 语义和 Oxide 场景，迁移到其他 runtime 或业务时需重新验证。
工程实践Oxide Public RFDs
RFD 373 讨论控制平面中的可靠持久工作流（RPW）：持续将数据库期望状态与 DNS、VPC、软件更新等目标的运行时状态对齐，而非一次性 saga。文章提出三条约束——目标最终获知更新、所有目标按同一顺序收敛、单目标离线不阻塞其他目标，并比较周期激活、全量/增量更新、generation number、目标驱动与 Nexus 驱动等模式。文中否定在 API 请求内联更新、按变更创建 saga 或使用队列，指出会导致顺序错乱、无界积压或惊群；也讨论分布式互斥难题，倾向让目标串行化请求。结论是将 RPW 作为一等抽象并从 DNS 落地迭代；但多数设计未实现，部分示例仍需验证。
推荐收录。该文档不是泛泛介绍，而是给出 RPW 的明确约束、generation number、全量/增量传播、目标驱动与 Nexus 驱动、互斥与队列等模式的逐项取舍，并系统分析内联更新、滥用 saga/队列等反模式；适合构建控制平面、分布式协调、Kubernetes 控制器或自愈系统的工程师。其 reconciliation、激活模型和可观测性设计可直接迁移到类似场景，但部分章节作者自述不确定，落地前需结合实现验证。
工程实践Oxide Public RFDs
RFD 363 描述 Oxide 的 Minibar：一种面向 SP3/SP5 计算 sled 的制造测试器。它插入 sled 背板，提供类机架接口，将背板 PCIe x4 引出到 x16 槽，把 SGMII 管理网口转为 BASE-T，并内置 Ignition 控制器。目标是在编程站一次完成编程、测试和锁定，验证 Ignition、PCIe Gen3 x4、管理链路及 200G/100G KR4 环回链路，并通过 PCIe 网卡加载主机 OS。架构复用 Sidecar 的 VSC7448 交换、Ignition 控制器和 RoT/SP，分为生产型与 Minibar Lite，并讨论机械/电气安全和基于 RoT 测量启动的缓解。其边界是高度绑定 Oxide 专用 sled 与背板，部分安全细节未定型，但测试夹具、环回验证和复用既有平台的取舍对硬件/基础设施工程有迁移价值。
推荐收录。该 RFD 不是产品宣传，而是给出完整的制造测试器需求、五项测试能力、Sidecar 复用、PCIe 引出、管理网口转换、KR4 环回、两种机械形态、安全与威胁模型等工程细节。适合服务器硬件、数据中心基础设施、制造测试和固件/平台工程师阅读，可迁移其测试夹具设计、复用既有平台、环回验证与安全缓解思路；主要限制是高度依赖 Oxide 专用 sled/背板，部分安全设计仍未定型。
工程实践Oxide Public RFDs
本文是 Oxide 的 RFD 493，讨论其平台最关键的 Kubernetes 集成并给出路线图。文章先概述 Kubernetes 组件和声明式 API，再区分原生集成与发行版集成，逐项分析 Cloud Controller Manager、Cluster API、CNI、CSI、Ingress/Gateway API、Rancher Node Driver 的问题、所需 Oxide API、开发量和延期风险。路线图分三阶段：优先 Cluster API 与 Rancher Node Driver 改进，其次 CCM 和 Rancher UI 扩展，最后 CSI；CNI、Ingress、Gateway API 明确推迟。边界是 Oxide 暂不提供托管 Kubernetes，部分估算需更多研究，方案高度依赖其自身 API 与存储、网络能力。
推荐收录：这是已发布的 Oxide RFD，提供了集成点、所需 API、开发量、延期风险和分阶段路线图等直接证据，而非泛泛介绍。适合平台工程、Kubernetes 发行版/云集成和基础设施团队参考，可迁移的是如何按客户价值与差异化程度排序集成、推迟非核心组件；主要风险是结论绑定 Oxide 平台，外部读者需注意其前提。
工程实践Oxide Public RFDs
本文是 Oxide 的 RFD 决策记录，讨论 CockroachDB 从 BSL 1.1 转为严格专有/源码可见许可后，控制平面数据库的选型去留。作者先回顾选用 CockroachDB 的原因：空间和性能要求不高，但持久性、可用性与免运维至关重要；随后逐项评估替换数据库、购买企业版、接受免费源码可见版、停留在 Apache 2.0 的 22.x 等方案。最终决定继续自支持 CockroachDB 22.1/22.2，不升级到 22.2 之后，并将内部补丁整理为 Oxide 自有仓库维护。其边界是 Oxide 将数据库嵌入出货硬件、运行于 illumos 衍生系统且本就准备自支持；代价是长期停留在旧版本并自行承担维护与安全风险，不能直接照搬为通用数据库选型建议。
推荐收录：文中给出了因上游许可证变更而重新评估数据库依赖的完整决策链，包括 BSL、CCL、强制遥测、按核年费、Apache 转换时间表和自支持成本等具体约束。适合基础设施、数据库选型、开源合规和平台工程读者参考，可迁移到评估关键基础软件供应链风险与版本冻结策略；但需注意其结论高度依赖 Oxide 的嵌入式出货场景，不构成通用选型建议。
工程实践Oxide Public RFDs
RFD 479 介绍 Dropshot 的 API trait 方案：用 Rust trait（#[dropshot::api_description]）定义端点集合，端点作为静态方法，从而把 API 接口定义与具体实现分离。宏会生成 support module，提供 api_description 与 stub_api_description，前者用真实实现启动服务器，后者无需实现即可生成 OpenAPI 文档。该设计主要解决函数式 API 的迭代慢、Nexus 与 sled-agent 循环依赖、OpenAPI 合并冲突和难以提供测试实现等问题。Oxide/Omicron 落地后，OpenAPI 测试从约 18 秒降到 1.5 秒，新增 KnownArtifactKind 的流程从 20 多分钟降到 1 分钟以内。边界是要求 Rust 1.75+、使用静态分发、trait 不能对象安全，且尚不支持 trait 组合与部分测试实现的自动委派，更适合大型服务或需要多实现的 API。
推荐收录：它给出了从问题、约束、迁移路径到量化收益的完整工程论证，并有 Dropshot 0.11.0 与 Omicron 全量迁移作为落地证据。适合 Rust 后端、API 平台、基础设施和架构设计读者，可迁移的是接口与实现解耦、宏生成 OpenAPI、打破循环依赖和加速迭代的模式。需注意其结论依赖 Oxide 的 Rust 技术栈与 Dropshot 工具链，其他团队要评估版本、静态分发和生态限制。
工程实践Oxide Public RFDs
本文是 Oxide Computer 的公开 RFD 419，探讨如何为分布式 saga 编写正确的节点。文章首先定义正确 saga 节点需满足的四个属性：补偿动作应尽量回滚前向动作或使系统保持一致、前向动作必须幂等、原子性（避免多步状态变更）以及必须得到已知结果。随后列举常见陷阱，包括在参数中使用名称引发 TOCTOU、动态状态变更的循环、无补偿动作的节点、中间状态可见导致并发 saga 冲突，以及删除与创建 saga 交错执行。文章强调 saga 并非事务，节点执行间隔可能很长，作者必须考虑重复执行、并发执行和跨时间重复的“企鹅”问题，并建议通过软删除和幂等端点来支持重试。最后指出这些约束需扩展到被调用的守护进程及其嵌套路径，但未给出强制机制，依赖代码作者和评审者的纪律。
推荐收录。本文系统总结了分布式 saga 节点正确性的四个核心属性（补偿、幂等、原子、已知结果），并列举了大量来自 Oxide 真实工程（如磁盘删除、快照创建、NIC 附加）的陷阱与应对模式，如避免参数用名、处理动态步数、防范并发 saga 交错。对设计分布式任务编排、微服务补偿流程或需要保证最终一致性的后端工程师极具参考价值，可直接迁移其检查清单。主要不足是缺少自动化强制手段，依赖作者与评审者纪律。
工程实践Oxide Public RFDs
RFD 357 提出 Oxide MVP 的外部 DNS 方案：运维方委派一个子域，并提供 2 个以上（建议 3-10 个）客户网络 IP，由 Oxide 运行独立于内部 DNS 的权威外部 DNS 服务器。每个 Silo 获得 $silo.sys.$delegated_domain 主机名，指向同时服务控制台与 API 的 Nexus 实例，更新时采用蓝绿部署并动态迁移固定 IP 来提升可用性。TLS 证书在 MVP 中倾向通过 API 管理，因为客户环境常不暴露公网，难以使用 ACME 公网挑战。文章还讨论 DNS 最终一致性、扩展性、Cookie 作用域和备选方案，但安全考虑尚未展开，且不覆盖通用递归 DNS 与实例 DNS。
推荐收录：该 RFD 不是泛泛介绍 DNS，而是给出可执行的系统设计决定，包括委派域、外部权威 DNS 服务器、按 Silo 命名、蓝绿更新与固定 IP 迁移，并系统比较证书管理和多种备选方案。适合基础设施、网络、控制平面和系统架构读者，可迁移到多租户平台、客户自管 DNS 域名和 TLS 证书自动化等场景。主要风险是内容面向 Oxide MVP，安全考虑尚未展开，且部分细节标记为待定。
工程实践Oxide Public RFDs
该 RFD 把 Crucible 原始文件格式从块数据与每块上下文分离，改为交错打包，以减少上下文冗余并提升对 ZFS 的机械友好性。为保证崩溃一致性，作者分析 ZFS 的 zfs_write 会在 recordsize 边界拆分事务，因此要求块与上下文落入同一 transaction group，并按 recordsize 对齐。元数据上把 BlockContext 缩减为 PackedBlockContext，去掉 on_disk_hash，依赖 ZFS 校验或解密验证，使 512 字节块的上下文开销从 18.75% 降至 6.25%。消息层引入 PackedWrite/PackedReadResponse，只读区域保留 raw，可写区域迁移到 packed；初步随机读测试显示小读约 1.4 倍提升，但方案依赖 ZFS 实现细节并增加迁移复杂度。
推荐收录。该 RFD 不是概念介绍，而是给出可验证的工程证据：ZFS 事务拆分源码分析、recordsize 对齐约束、上下文结构缩减方案，以及随机读 1.08–1.42× 的基准数据。适合存储系统、虚拟化与基础设施工程师阅读，其崩溃一致性设计、文件布局与消息格式迁移思路可迁移到其他基于事务文件系统的存储系统；风险是结论高度依赖 ZFS 与 Crucible 具体实现。
工程实践Oxide Public RFDs
该 RFD 解析 Crucible Upstairs 的背压设计，说明现有背压由在途写字节数和活跃作业数决定，取二次延迟曲线最大值，在写返回前施加人工延迟并持锁，避免并发写压垮系统。作者以“吞吐背压”模型解释系统稳定在“一进一出”状态，并指出 IOP/带宽限制未接入背压、MAX_ACTIVE_COUNT 为硬限制、大写在途字节延迟未钳制可能导致故障阈值难触发，以及大量写后 flush/read 延迟变长等不足。文末决定增加在途字节故障条件、调参曲线并移除/重实现 IOP/带宽限制，还讨论曲线形状、其他背压来源与资源受限下的 QoS 安全考量。结论主要基于 Crucible 具体实现，需结合目标系统验证。
推荐收录。它来自 Oxide 公开 RFD，围绕真实存储系统遇到的上层队列堆积问题，给出了背压实现、队列限制、故障阈值和延迟/吞吐权衡的一手设计证据，并明确列出不足与后续决定。适合存储系统、分布式系统、SRE 和性能可靠性工程师阅读，其中“按资源量分级施加背压、同时用故障阈值兜底”的思路可迁移到其他有界资源系统；需注意其参数和结论绑定 Crucible 实现，迁移时要重新验证。
工程实践Oxide Public RFDs
RFD 347 提出 Delay Driven Multipath（ddm），面向物理多路径数据中心网络做 L3 包级负载均衡与容错。它受 DRILL 和 Swift 启发：控制平面用距离向量分发前缀，数据平面在 IPv6 逐跳扩展头中携带时间戳，节点通过确认计算目的端时延及其导数，持续逼近分布式 Dijkstra 森林。ddm 追求 N-1 容错、灵活拓扑、包级最优负载均衡和可扩展性，并在 RTT 内响应拥塞与故障，且不绑定传输层流；文章详述发现、前缀交换、server/transit 路由器、管理 API、时延表、基础/概率/预测 pick 函数和接收端重排序，并讨论 illumos 与 P4 实现。其边界是 15 跳扩展头限制、重排序与缓冲开销，中转路由器、路径向量和预测选路等仍属未来工作。
推荐收录：这是一份真实的网络协议设计 RFD，给出了多路径数据中心网络中基于时延的 L3 负载均衡与容错方案，包含控制平面、数据平面、pick 函数、重排序分析和实现平台约束。适合网络架构、数据中心基础设施和分布式系统读者，可用于理解延迟驱动路由、IPv6 扩展头数据面及多路径协议设计中的取舍。风险是部分设计仍属未来工作、缺乏生产验证，需结合实现与测量评估。
技术文章Oxide Public RFDs
本文是 Oxide 的 RFD 463，描述用于查询和加工机架遥测数据的领域特定语言 OxQL。oximeter 采集硬件与软件指标并存入 ClickHouse，OxQL 以表、时间序列、字段和数据点为核心模型，支持 gauge、cumulative counter、delta 与 histogram，并在读取 cumulative 数据时自动转为 delta，以便对齐、聚合和连接。语言采用 Unix 管道式表操作（get、filter、align、group_by、join）和子查询，配合字面量、比较/逻辑运算符及 EBNF 语法定义。文档强调自研 DSL 的理由：现有 SQL 和各类指标查询语言不适配时序数据且集成成本高。其边界是目前不支持 raw cumulative 选择和 outer join，且作为发布后不再更新的规范，主要面向 Oxide 内部与用户文档。
推荐收录。该 RFD 不是新闻或营销稿，而是完整给出了 OxQL 的设计动机、数据模型、语法定义、示例和查询语义，包含 cumulative 到 delta 的自动转换、对齐/分组/连接等可迁移概念。适合做可观测性、时序数据库、DSL 或后端查询系统的读者参考。注意其内容与 Oxide 机架和 ClickHouse 强绑定，且 RFD 声明发布后不再更新，迁移时需结合具体数据模型取舍。
工程实践Oxide Public RFDs
本文是 Oxide 机架控制平面的 RFD 457，定义物理 sled/磁盘与控制平面 sled/磁盘两类对象及其生命周期。作者先区分 in_service、quiesced、failed、expunged 与 graceful removal，再围绕 sled 和 physical_disk 表设计 policy 与 state，规定添加、优雅移除和 expunge 在分配、信任仲裁、电源、实例迁移、Crucible region 替换和 Omicron zone 重建上的差异。文章用 blueprint planner/executor 流程说明 sled/磁盘的添加与 expunge 顺序，并强调 expunge 必须由运维触发，避免把瞬时故障误判为永久移除。对于 expunged sled 如何确保不再启动，文中比较 Ignition 断电、服务处理器 A2 与 trust quorum，指出仍有开放问题；磁盘误拔重插则要求 Sled Agent 重新建立服务并告警。边界是 quiesce、临时维护和优雅移除细节不在本文范围，部分流程仍为 TBD，且实现与 Oxide 架构强绑定。
推荐收录：该 RFD 给出了 policy/state 分离的硬件生命周期模型，以及 blueprint planner/executor 在 add、graceful remove、expunge 时对分配、信任仲裁、数据重建和电源控制的具体处理，属于可迁移的系统设计证据。适合分布式系统、存储、可靠性与基础设施工程师阅读，尤其可借鉴优雅移除与永久移除的区分、运维触发 expunge 的风险取舍。主要风险是内容高度绑定 Oxide 控制平面，且若干流程仍为 TBD 或超出范围。
工程实践Oxide Public RFDs
该 RFD 复盘 Oxide Crucible 存储 Upstairs 的重构：重构前多个 async 任务共享一个 tokio Mutex<Downstairs>，单个作业需加锁 11–15 次，io_send 等路径竞争严重，多任务拆分收益有限。作者提出按客户端拆分锁，并用 per-job 原子位标记跨客户端状态；同时给出更激进的“一个大任务”反提案，让同步状态机核心独占数据、异步仅位于边界。基准显示大块随机写提升约 20%–30%，但部分收益来自加解密移出锁范围，早期基准不够严谨。最终因 reconciliation 等路径依赖两个任务同时接触共享数据，无法渐进改造，团队选择并完成了非渐进式重构，消除约 3KLOC。
推荐收录：这是来自生产存储系统的真实架构重构记录，包含锁竞争量化、数据归属表、两种重构方案权衡、失败尝试和最终落地效果。对使用 Rust async、Tokio 或维护高并发存储/分布式系统的工程师尤其有价值，可迁移其从锁拆分到同步状态机核心的设计判断。阅读时应留意基准不严谨及后期归因修正，不能只照搬性能数字。
工程实践Oxide Public RFDs
该 RFD 提出 illumos 的 GPIO 框架设计，目标是为内核和用户态提供统一管理与消费方式。文章梳理 GPIO 在 Gimlet 上的用途，并对比多种 SoC 与 GPIO 扩展器属性，论证抽象必须保留设备特定性。方案包括内核 GPIO 框架与 provider API、控制器字符设备、gpioadm 工具，以及把受约束 GPIO 定义为 DPIO，通过 /dev/gpio/:name 提供 open/read/write/poll 语义。文章还讨论 I/O muxing、策略、中断与持久化难题，并列出内核框架、AMD Milan provider、仿真驱动和用户态命令等首批交付物。边界是不支持高速 bit-banging，muxing、中断与持久化仍属探索阶段。
推荐收录：这是 Oxide 公开的工程 RFD，直接给出内核 GPIO 框架、provider API、DPIO 与 gpioadm 的设计，并逐项比较 AMD Milan、Intel C620、ST H753 等控制器差异，证据密度高。适合操作系统、驱动开发、平台固件/硬件抽象相关读者，可迁移其属性建模、DPIO 约束和 I/O muxing 数据表方法；主要风险是部分设计仍为探索阶段，不能当作最终 API 规范。
工程实践Oxide Public RFDs
RFD 469 讨论 Oxide 控制面仍运行已停止上游支持的 CockroachDB v22.1，而 CockroachDB 仅支持逐个大版本升级且默认自动 finalize、无法降级，因此提出短期过渡方案。作者在 v8 控制面引入 cluster.preserve_downgrade_option，并采用 Tick-Tock 模型：Tick 将 cockroachdb zone 升级到下个大版本，并在长期测试环境验证降级可用；Tock 重置并重新保留降级选项。按计划从 v22.1 逐版本推进到 v23.2，分别落在控制面 v8 至 v14，每个大版本跨两个发布完成验证与收尾。实现上要求不给 Mupdate 增加额外手工步骤，也不编写 Nexus 自动化后会丢弃的新代码。开放问题是 Tick 与 Tock 之间能否升级补丁版本，仍需测试；该方案是过渡性运维设计，不替代最终自动更新工作流。
推荐收录，因为它给出了数据库大版本升级的真实约束与可复现操作模型：用 preserve_downgrade_option 保留回退路径，用 Tick-Tock 跨控制面版本逐步验证和 finalize，并明确排期、实现约束与开放问题。对负责数据库、控制面或平台升级的 SRE/工程读者，这套分阶段升级与回滚设计可直接迁移；但内容高度依赖 Oxide 内部发布流程，缺少故障演练结果和性能数据，阅读时需结合自身环境验证。
工程实践Oxide Public RFDs
本文是 Oxide 的 RFD 459，定义了 Omicron 控制平面各组件的生命周期管理语义与运维动作。作者沿用 RFD 457 的术语，提出在 blueprint 中为每个受管 zone 记录 disposition（in service、quiesced、expunged），并说明 Nexus 如何借此实现 sled 优雅移除、剔除、未来升级和扩缩容。文章以表格和分节方式列出 CockroachDB、External/Internal DNS、Nexus、Oximeter、Boundary/Internal NTP、ClickHouse、ClickHouse Keeper、Crucible Pantry 等组件在加入、quiesce 和 expunge 时所需动作，例如配置重写与 reload、decommission、DNS 更新、停止接收新请求、重新分配 saga 和 metric producer 等。结论是多数组件可归纳为通用 reconfigurator 动作加组件特定操作，但部分组件存在灾难恢复边界。该 RFD 依赖若干未完成 issue 和 RFD，边界服务配置等细节不在本文范围内。
推荐收录：该文档不是泛泛介绍，而是把控制平面组件在加入、quiesce、expunge 三种状态下的具体动作逐项列出，并给出 disposition 模型和 blueprint/Nexus/Reconfigurator 的落地机制。适合负责分布式基础设施、控制平面、SRE 与平台工程的读者，可迁移其状态机设计、组件生命周期操作规程和故障边界分析方法；主要限制是它绑定 Oxide 自有 Omicron 架构，部分步骤依赖未完成 issue，需结合上下文使用。
工程实践Oxide Public RFDs
本文是 Oxide 关于虚拟机热迁移单调时间处理的公开 RFD，核心是 x86 TSC。文章说明 guest 要求 TSC 单调、恒频且启动归零，而跨主机迁移使 bhyve 传统偏移算法失效。作者结合 AMD SVM 与 Intel VMX 的 TSC 缩放/偏移机制，推导 guest TSC、offset 与频率倍率公式，并用四个场景演算。随后分析定点表示导致的溢出与精度限制，提出最大倍率上限，并讨论向下倍率漂移和 NTP 误差边界。最后列出误差建模、机架频率差异、跨迁移墙钟同步等开放问题，部分内核实现仍处原型阶段。
推荐收录：这是一份面向真实热迁移需求的系统设计 RFD，直接给出 TSC offset/倍率公式、AMD/Intel 定点表示、溢出边界和倍率取舍，证据充分而非泛泛介绍。适合虚拟化、hypervisor、OS 时间子系统与云基础设施工程师阅读，可迁移到跨主机迁移的时间一致性与数值边界验证；不足是墙钟同步、误差建模和内核接口仍留作开放问题。
工程实践Oxide Public RFDs
该 RFD 讨论机架发货前如何为承载 U.2 设备的 zpool 启用根数据集加密，因为在完整 trust quorum 可用前仍需保护静态数据。作者把威胁模型分为 L1–L4，按攻击者能窃取并启动的 sled 数量相对 K 来界定能力，核心目标是让被盗磁盘无法恢复数据。最终决定采用 Low Rent Trust Quorum（LRTQ），沿用 RFD 301 的存储密钥派生，把 LRTQ 提供的输入密钥材料经 HKDF 生成密钥。文档比较了不加密、使用不安全 IKM、在 M.2 明文保存随机数、用 M.2 随机数作盐并结合 VPD 等替代方案，说明各自攻击面与妥协。未来可在线升级到完整 trust quorum；但 LRTQ 不能防御引导网络上的在线攻击，L4 仍不在当前长期威胁模型内。
推荐收录。该 RFD 以明确威胁模型（L1–L4）、密钥派生链路和替代方案对比，记录了机架发货前磁盘加密的真实工程取舍与安全边界。适合存储、安全和基础设施工程师理解 trust quorum 未就绪时的临时方案，以及如何规划在线升级；其中对 LRTQ 局限的说明也避免了把临时方案误用为长期安全保证。
工程实践Oxide Public RFDs
该 RFD 讨论 Oxide 控制平面使用 Rust async/await 三年后暴露的任务取消安全问题：Future 在 await 点被 drop 或 task 被 abort 时，内部状态会被丢弃，可能导致互斥锁在保护的不变量恢复前释放。作者用同步 Mutex 与 tokio Mutex 的对照示例复现状态机不变量被破坏，并列出 Dropshot 请求处理、tokio::select!、timeout、try_join 等取消来源。文章指出 tokio 对 cancellation safety 的说明零散且不完整，编译器无法检查，审计成本高。短期内通过让 Dropshot handler 独立成 task 缓解，长期需讨论是否迁移同步线程模型或制定取消安全规范。该文不提供完整解决方案，重点在界定问题、风险与取舍边界。
推荐收录，因为它以 Oxide 真实控制平面 bug 为例，给出可复现的同步/异步 Mutex 对照代码，并系统梳理任务取消安全的来源、风险与 FAQ 取舍。对使用 Rust 构建分布式后端、维护长期控制面或评估 async 架构的读者，文中的 await 点不变量、取消传播和短期缓解策略具有直接迁移价值；需注意它聚焦问题界定，不提供完整解决方案。
工程实践Oxide Public RFDs
RFD 316 定义了 Oxide 主机系统软件（HSS）与 Service Processor（SP）之间异步串行链路的通信协议。协议以主机单向发起请求、SP 仅回复为核心，SP 通过 GPIO 电平中断通知事件，并采用 hubpack 小端编码、固定头部（magic/version/sequence/command）、Fletcher-16 校验和最大 4123 字节消息。帧层使用 COBS 与 0x0 分隔符，单次仅允许一个未完成请求，并通过状态寄存器、额外帧终止符和重传处理 SP 重启、帧损坏与死锁。文档还列出 HSS→SP 与 SP→HSS 命令表、状态/启动选项寄存器以及安全边界。其限制是 UART 无双向认证、可被物理中间人攻击，且部分长耗时操作与 RoT 请求语义仍待确定。
推荐收录：该 RFD 不是概念介绍，而是给出了可实现的串行 RPC 协议细节，包括消息布局、命令枚举、COBS 组帧、校验、重传和失步恢复，并明确无认证等安全不足。适合嵌入式/固件、系统软件和硬件-软件接口设计者参考，其单请求串行、状态寄存器驱动和重同步策略可迁移到类似带外管理通道。
工程实践Oxide Public RFDs
本文是 Oxide 的 RFD 404，定义边界隧道路由问题并提出基于 ddm 路由协议分发隧道路由的解决方案。问题在于实例/服务发往外部上游网络的包需经 Geneve 封装到 IPv6 underlay，封装器 OPTE 需知道可用网关、如何选择多个网关以及路由变化如何传播。方案让交换机上的 mgd/ddmd 将上游前缀与边界隧道端点 IPv6 ULA 通过 ddm 通告并传播到各 sled，ddmd 再把隧道路由写入 OPTE 新增的 V2B 表，并用 metric、ECMP 哈希和路径向量协议能力处理多网关与故障。文中还给出协议对象、指标设计、与纯控制面/对称交换机配置等替代方案对比，以及安全与开放问题。边界是当前仍处讨论阶段，可扩展性、路由剪枝和 mgd 健康监控等未完全验证，主要适用于 Oxide 的 underlay/overlay 边界路由。
推荐收录，因为这是一份真实基础设施系统的设计文档，完整展示了从问题定义、路由协议选型、OPTE V2B 表设计到替代方案、指标与安全风险权衡的推理链条。适合网络、基础设施和分布式系统工程师阅读，可迁移到多机架网关路由、overlay 路由传播和故障收敛等场景；风险是仍处讨论阶段且若干可扩展性与实现细节未定。
工程实践Oxide Public RFDs
本文是 Oxide 的公开 RFD，讨论分布式 saga 框架 Steno 的升级问题。Steno 将复杂分布式操作拆解为幂等动作并持久化每个动作的输出，导致软件版本变化时恢复旧 saga 状态非常脆弱。作者提出“同一 saga 仅由同一版本 Nexus 执行”的约束，并通过蓝绿部署排空旧实例以及为 saga 存储版本/签名来实现。文章详细分析了签名设计、升级本身也是 saga 的边界情况、回滚与孤儿 saga 的处理，并对比了显式键值存储、Stripe 式 API 版本化和 WASM 等备选方案。该方案可避免跨版本恢复的复杂性，但代价是存在 bug 的在途 saga 无法被新版本修复，且旧版本可能因等待排空而延长暴露时间；文中尚有许多实现细节待定。
推荐收录，因为该 RFD 针对真实分布式系统的升级难题给出了具体约束、机制设计和多种备选方案对比，并讨论了排空、版本签名、回滚失败与安全暴露等工程取舍。适合设计分布式 saga、持久化工作流或升级系统的工程师阅读，其中的问题拆解和权衡方法可迁移到类似场景。但需注意它只是方向性草案，并非已验证实现，适合作为设计推理参考而非直接落地方案。
工程实践Oxide Public RFDs
Oxide RFD 0301 提出机架级密钥层级策略，以 Rack Secret 为根，保护控制面数据、Crucible 卷加密密钥和 U.2 盘上的 ZFS 加密数据。它基于 Shamir 秘密共享的 Trust Quorum：K 个 share 可重构 rack secret，再通过 HKDF-SHA3-256 为每块 U.2 盘派生独立 ZFS 加密密钥，并用 new/old epoch 信息绑定用途。重配置时，dealer 用新 epoch rack secret 派生包装密钥加密旧 rack secret，随 prepare 消息分发；提交后节点重构新秘密、解密旧秘密、派生并轮换各盘密钥，再安全删除旧秘密。关键结论是每盘独立密钥限制单盘泄漏，epoch 与两阶段提交处理分布式轮换和 false start，且不依赖硬件全盘加密。边界是主要覆盖 MVP 存储加密与 rack secret 包装，证书等留待后续 RFD，故障细节依赖 RFD 238，且方案绑定 Oxide rack 架构。
推荐收录，因为它给出完整可验证的机架级密钥层级设计：从 Rack Secret、Shamir 分享、HKDF info 字符串到每盘 ZFS 密钥与重配置包装/轮换流程，并明确目标、约束与 determinations。适合基础设施安全、分布式存储和密钥管理读者，可迁移其按数据生命周期与空间局部性设计密钥层级、用 epoch 和两阶段提交处理密钥轮换的方法；局限是绑定 Oxide 硬件与 RFD 238，通用性需自行抽象。
工程实践Oxide Public RFDs
Oxide 的 RFD 284 描述主机操作系统镜像如何由 Pico Host Boot Loader（phbl）加载并启动。phbl 从复位向量开始，将引导核从 16 位实模式推进到 64 位长模式，初始化 UART，解压 CPIO 归档中的 phase1 镜像，提取 illumos 内核 ELF 并载入 RAM，最后调用其入口点。文档规定了虚拟内存映射保证（最大页优先、UART 非缓存、RAM writeback）、内核入口时的硬件与页表状态，以及最小化系统状态修改的设计目标。安全上假设服务处理器已用根信任验证镜像，phbl 不做运行时校验，存在 TOCTOU 风险；当前归档被编译进 phbl 镜像，内核路径硬编码，为待解问题。
推荐收录，因为本文给出了真实系统中引导加载器与内核之间的完整接口契约：从 CPU 模式切换、页表粒度保证到入口时的寄存器与内存状态，均有明确约束和设计取舍。对操作系统、固件和低层系统开发者来说，这些边界条件与安全假设（如依赖 SP 校验镜像导致的 TOCTOU）具有直接参考价值，可迁移到其他平台的设计与调试中。
工程实践Oxide Public RFDs
Oxide RFD 250 讨论管理网络拓扑与“本体感知”：控制平面 MGS 如何发现 SP、推断机架位置，并让 SP 获知自身位置。文章先确立 L2 网络、SP 间隔离、每交换机隔离、VSC7448/Tofino 端口一一对应等原则，再提出用 VLAN 标签实现隔离：MGS 到 VSC7448 按目标端口打标签，KSZ8463 到 SP 用 0x301/0x302。随后说明 MAC 从 FRU EEPROM 分配、以 EUI-64 生成 IPv6、用多播和 NDP 发现地址，并通过向确定端口发探测消息判断 Sidecar A/B 位置。文章还列出备选方案、开放问题和安全考量，指出恶意 Sidecar 可重配 VSC7448 等边界。
推荐收录：这是一份公开的机架管理网络设计文档，给出了 VLAN 隔离、地址发现、位置推断和安全威胁模型的完整取舍，并包含备选方案与开放问题。适合做数据中心网络、带外管理、嵌入式 SP 通信或 L2 隔离设计的读者参考，其中“用拓扑约束替代额外硬件或协议”的思路可迁移到类似系统。
工程实践Oxide Public RFDs
本文是 Oxide RFD 238，定义机架级信任仲裁与磁盘解锁：在不需人工输入密码的前提下，防止 U.2 盘被盗或少于阈值 K 的 sled 被窃后读出数据。方案用 GF(256) 上的 Shamir 秘密共享，初始化时把机架秘密拆成 N 份，每个 sled 持有一份；启动时经 sprockets 的 mTLS 和远程证明向成员取回 K-1 份，重建秘密并派生 ZFS 密钥以解锁本地存储。成员须属于信任组，防止被篡改 sled 插机架偷取份额；重配置通过 epoch、Prepare/Commit、Peer Commit 与取消机制增删节点并轮换密钥。文中给出安全/活性不变量、K=N/2+1 取舍及 TLA+ 规范。适用于 Oxide 机架和非拜占庭、部分同步环境，依赖 RoT、PlatformId、sprockets 等基础设施。
推荐收录。该 RFD 完整覆盖了从威胁模型、Shamir 秘密共享、sprockets 远程证明到重配置协议的工程权衡，并明确安全/活性不变量和 K 值选择依据，属于可长期参考的系统安全设计。适合分布式系统、存储加密、可信计算和基础设施工程师阅读，其协议设计、形式化验证与故障处理思路可迁移到类似集群密钥管理场景；需注意其强依赖 Oxide 的 RoT/PlatformId 等专用硬件。
职业经验Oxide Public RFDs
这篇 Oxide 公开 RFD 复盘 2021 年修订职位描述（JD）的决策，并提出未来撰写 JD 的方法。作者主张公开 JD 首要服务候选人，用具体工作内容吸引合适人才，而非罗列完美资格清单。标题应使用外部可理解的通用名称，避免过窄或过泛；正文按“日常职责—有帮助的特质—为什么来 Oxide”三部分组织，并强调职责不等于资格。文章还建议采用积极、透明、非竞争性的语气，避免“rockstar”“blame”等被滥用的词，最后附一份 control plane 软件工程师示例 JD。其经验适用于系统软件/基础设施公司的招聘沟通，对其他组织仅具参考价值，且部分内容带有公司自我推广色彩。
推荐收录：它给出了可操作的 JD 写作框架，包括三部分结构、标题通用性、职责与资格分离、避免 startup 话术等具体规则，并附有真实示例。适合工程管理者、招聘负责人和关注工程文化的读者参考，可迁移到技术团队招聘沟通；但内容主要基于 Oxide 自身实践，通用性有限，且包含公司福利与文化宣传，需与更广泛的招聘研究配合阅读。
工程实践Oxide Public RFDs
这是 Oxide 公开的 RFD 224《开源政策》，由 Bryan Cantrill 和 Steve Klabnik 编写，改编自 Joyent RFD 164。它设立开源顾问办公室（OSCO）集中处理政策咨询与风险评估，并按许可证风险把开源使用分为可直接使用、需咨询后可用于外部、仅限内部且须明确许可三类，具体列出 MPL、MIT、BSD、Apache、GPL/LGPL、AGPL/SSPL 等许可。文章还规定对外贡献须保留个人署名、版权归 Oxide、新项目默认采用 MPL 2.0 并放在公司 GitHub 组织，同时覆盖 LICENSE 文件、第三方源码引入、安全保密、CLA 和行为准则。其价值在于给出可操作的开源合规与贡献治理框架，但条款带有 Oxide 特定组织背景，其他团队需结合自身法务与业务边界调整。
推荐收录：文章不是泛泛倡导开源，而是把许可证按使用场景和审批要求分级，并明确贡献署名、版权、CLA、安全保密与行为准则等可执行规则。适合工程负责人、开源维护者和合规/安全团队参考，可迁移为公司开源政策模板或审查清单；但条款服务于 Oxide 的商业模式与法律立场，直接照搬前需结合本地法务和业务约束。
工程实践Oxide Public RFDs
本文是 Oxide Omicron 控制面数据库的设计 RFD，围绕强一致性与可扩展性，给出多租户 API 资源（Project、Instance、VPC 等）的建模与查询模式。作者采用 UUID 主键、身份元数据、按父作用域与 name 的唯一部分索引，支持分页、重命名和软删除，并避免显式外键。文章用条件 UPDATE、CTE、generation number 与 rcgen 处理并发更新和检查-使用竞态，也比较事务、CTE、saga 的适用场景。最后分析读-改-写、长事务、双管理员并发及集合删除/创建竞态，并指出实现尚不完整、方案依赖 CockroachDB SERIALIZABLE 与具体 API 约束。
推荐收录。文章不是泛泛介绍数据库范式，而是给出可核验的表结构、唯一部分索引、条件 UPDATE/CTE、rcgen 和 saga 选择规则，并明确 CockroachDB SERIALIZABLE、软删除与双管理员并发下的边界。适合控制面、分布式数据库和后端架构读者，其中的并发控制与一致性模式可迁移到多租户 API 设计；风险是方案与 Oxide/CockroachDB 强耦合且实现未完成。
工程实践Oxide Public RFDs
RFD 297 讨论 Oxide 系统中 Silo（多租户隔离单元）与 API 资源之间的关系，明确将资源划分为 siloed 与 non-siloed 两类。Organizations、Projects、Instances、VPC、用户等在每个 Silo 内被虚拟化，不能跨 Silo 共享甚至无法互相引用；而 Racks、Sleds、Silos、全局镜像等在所有 Silo 中保持一致。作者给出三种典型部署形态（单一 Silo、运维+终端用户两 Silo、运维+多终端 Silo），并对比它们在身份管理、IdP 审计、误操作隔离和复杂度上的取舍。文章还列出当前已实现与规划中的资源分类，讨论“运维 Silo”标记、是否生成独立 OpenAPI 规格、禁用端点应返回 404 还是 403 等开放问题，以及细粒度访问控制与灵活协作之间的安全平衡。
推荐收录，因为这是真实系统的多租户设计文档，清晰划分 siloed 与 non-siloed 资源，并以三种部署形态说明身份、审计与隔离之间的具体权衡，还保留了替代方案和开放问题。它适合负责多租户平台、API 资源层级与访问控制的设计者，“资源作用域与身份作用域分离”的思路可迁移到类似云平台或 SaaS 系统。
工程实践Oxide Public RFDs
本文是 Oxide 的 RFD 241，提出主机启动策略 Holistic Boot：将几乎全部启动逻辑放入单一 illumos 主机 OS 镜像，不向独立生产内核交接，也不依赖可逆固件状态。设计确定由主机 OS 完成硬件初始化，内核驻留并保持控制；采用 phase-1 SPI NOR 与 phase-2 SSD、双 BSU A/B 绑定升级，由 loader stub 加载内核，host OS 经 SP 获取变量信息并负责 phase-2 度量/策略，SP 负责 stage-0/phase-1 度量与恢复。文章对比 Tiny/Giant/Helios 方案，引用 LinuxBoot 多阶段状态传递事故，分析 LZMA 压缩、MP0、ELF 压缩等空间约束，并讨论可验证启动、安全边界与开放问题。其结论依赖 Gimlet 及类似 sled 硬件、illumos/SP 生态，压缩与 loader 实现仍待原型验证。
推荐收录：它给出真实系统启动架构的完整决策记录，包含硬件约束、存储布局、固件行为和 LinuxBoot 反例，能帮助读者理解从 firmware 到 OS 的状态交接风险。适合做操作系统、固件/启动、服务器基础设施和可验证启动的工程师研读；其中 BSU 绑定、度量边界和单阶段启动取舍可迁移到类似平台设计，但部分方案未落地，需结合开放问题阅读。
工程实践Oxide Public RFDs
本文是 Oxide 的 RFD 223，讨论 Web Console 的客户端-服务端架构，并将其从 RFD 169 的认证议题中拆出。核心决定是：为避免在机架内引入 Node.js 和 npm 生态风险，Console 先做成由 Nexus 托管的静态 JS bundle，直接在浏览器调用 Nexus，并由 Nexus 接受会话 Cookie。文章对比浏览器单端、带/不带数据库连接的 Console 服务以及独立数据库方案，并分析 DDoS 缓解与 Node 依赖树风险。作者还评估 Deno、V8 Rust 绑定等服务端 JS 路径，以及共享校验、加载 spinner、SSR、Server Components、Remix 的收益与复杂度。结论是当前采用浏览器单端，后续加服务端集成不会丢弃代码；是否重启该决定取决于 UX 收益能否显著超过风险。
推荐收录：这是一份完整的架构决策记录，直接给出浏览器单端方案、会话 Cookie 认证、Node/npm 风险、DDoS 缓解和多种备选架构的取舍证据，而非泛泛介绍。适合前端架构、平台工程、控制面/基础设施开发者阅读，可迁移到 BFF 取舍、控制台认证、依赖治理和渐进式 SSR 决策。主要限制是结论高度依赖 Oxide 的 Rust 栈与安全约束，其他团队需重新评估。
工程实践Oxide Public RFDs
RFD 177 描述 Oxide 虚拟存储服务 Crucible 的实现，基于 Northern Mux 设计，将虚拟磁盘按 LBA 划分为多组三副本区域，由 Upstairs/Guest 转发读写，Downstairs 在物理 SSD 上以 extent 文件存储数据。文中详述 Volume 抽象、只读父层与快照/克隆、实时迁移和热插拔，并讨论端到端完整性哈希、AES-GCM-SIV 加密、TLS 传输及崩溃一致性。关键结论包括用 generation/flush/dirty 位驱动三副本 reconciliation 和 extent 修复，通过 WriteUnwritten 后台迁移只读父层，快照与密钥轮换也复用该机制。边界是部分章节因弃用 SQLite 已过时，且 IO 传输、认证、限流等仍有开放问题。
推荐收录：这是一份来自 Oxide 的公开 RFD，具体展示了三副本块存储服务在崩溃一致性、加密完整性、快照/克隆与在线迁移上的架构取舍，而非泛泛介绍。适合分布式存储、云基础设施和虚拟化平台工程师阅读，可迁移到副本选主、修复、只读父层和密钥轮换等设计。注意部分章节已标注因移除 SQLite 而过时，需结合 determinations 和开放问题判断时效性。
工程实践Oxide Public RFDs
本文是 Oxide 的 RFD 113，讨论工程中“Determination”即方向性技术抉择的制定与沟通。作者区分 decision 与 determination，强调复杂权衡下应寻找可行方向而非唯一正确解，并以 Responsibility、Rigor、Urgency、Courage、Versatility、Teamwork、Thriftiness 等价值观分析其张力。文章主张 urgency 最终应压过 rigor，但须避免轻率与分析瘫痪，并建议把决定写下来，篇幅可伸缩。随后以 OpenTitan/Tock/Hubris、Host CPU 选择、SP 网络为例，说明可深入试错、及时改向，或保留选项以推进决策。其边界是 Oxide 特定工程文化与实践，并非通用量化决策框架。
推荐收录。它由 Oxide 的 Bryan Cantrill 撰写，直接给出工程 determination 的价值框架、沟通要求与三个真实系统决策案例，适合工程负责人、架构师和基础设施团队参考。其可迁移价值在于把 urgency/rigor 取舍、保留选项和书面决定用于实际项目；风险是高度依赖 Oxide 文化，不提供可量化评分或普适流程。
工程实践Oxide Public RFDs
这份 Oxide RFD 203 提出在产品、代码、API、控制台和文档中统一数据量单位与词头的规范。它先区分 bit 与 byte，以及网络常用的十进制 SI 词头与内存/存储常用的二进制 IEC 词头，指出机架规模下 PB 与 PiB 差异超过 12%，单位误解可能造成数量级错误。核心判定是：网络吞吐以 bit/s 为单位并使用十进制词头；内存和存储以 byte 为单位并使用 KiB、MiB 等二进制词头。若因硬件等原因必须偏离，应使用正确标签或同时给出两种形式，例如 3.2 TB（2.9 TiB）。该规范适合接口设计、文档和运维沟通，主要不足是改变既有习惯需要迁移成本。
推荐收录，因为该 RFD 给出了可直接执行的单位规范，并用表格明确网络吞吐、内存和存储分别应使用 bit/s 与 KiB/MiB 等标签，还覆盖了硬件例外和双单位展示边界。对设计 API、CLI、控制台、监控指标或技术文档的工程师来说，这类约定能减少跨层沟通中的数量级误解，具有跨项目迁移价值；风险是它属于组织内部标准，外部团队需结合实际历史兼容。
工程实践Oxide Public RFDs
本文是 Oxide 发布的 RFD，系统讨论机架遥测系统的需求与技术选型。作者先按用途划分实时/历史、高可用、水平扩展、趋势近似与精确测量等要求，并辨析事件与指标、基数控制、资源可预测性以及采集与存储解耦。随后评估 illumos FMA、Prometheus、Thanos、InfluxDB、ClickHouse、VictoriaMetrics 等候选构件，比较其查询、告警、集群和重聚合能力。针对 ClickHouse 与 VictoriaMetrics 的模拟指标实验显示 ClickHouse 资源使用更可预测，作者初步倾向 ClickHouse，但指出其集群依赖 ZooKeeper。文末实验数据在抓取中截断，部分最终架构判断仍需结合后续 determinations。
推荐收录：文中不仅罗列候选技术，还把遥测需求拆成实时性、HA、水平扩展、精度、趋势等可比较维度，并以 ClickHouse/VictoriaMetrics 实验和 Prometheus、InfluxDB、VM 的具体缺陷作为选型证据。对构建可观测性平台、时序存储或基础设施监控系统的读者尤其有价值，其需求分解、评估表和踩坑记录可直接迁移到类似选型场景。需注意该 RFD 仍在形成最终架构判断，实验数据在抓取中截断，引用时需核对后续版本。
工程实践Oxide Public RFDs
这份 RFD 定义 Oxide 服务器机箱管理的职责分配架构，重点划分主机处理器与服务处理器（SP）之间的数据和控制路径。作者提出单一事实源、单一执行点、库存与健康监测合一、复杂行为自托管及 Sidecar/Gimlet/PSC 对等等原则，并据此分配热环路、DIMM SPD、电源控制、FRU 库存与错误/性能遥测。热与电源安全控制归 SP，带内设备库存和主机侧遥测归主机；DIMM SPD 比较多种方案后倾向在 EVT1 验证 SP 代理。文档还覆盖安全考量与开放问题，并声明除 DIMM SPD 等未决项外，分配结论对当前及后续产品具有规范性。
推荐收录：该文档不是泛泛介绍，而是给出可执行的机箱管理职责矩阵、原则和 DFD，包含热环路、DIMM SPD、电源与遥测等真实取舍。适合服务器硬件、固件、带外管理和系统架构读者，其“单事实源/单执行点/对等分配”方法可迁移到类似平台。需注意 DIMM SPD 最终方案仍待 EVT1 验证，部分安全与开放问题尚未闭合。
工程实践Oxide Public RFDs
这是 Oxide 公开 RFD 82，讨论机架硬件相关的 Operator Facilities 设计动机、原则与需求。文章将运维场景分为容量规划、产品生命周期、基本产品运行、运维硬件故障和未知问题调查五类，并提出对齐客户业务、一致性、无意外、有意义的差异四项原则。作者通过故障风扇、无法上电的 U.2 NVMe、新增网络 uplink、容量评审等案例，提炼识别、诊断、上报、派单、维修、验证与 RCCA 等信息需求。文档还列出组件电源控制、诊断重启与崩溃转储、固件升级、健康状态等需求，并强调现场技术人员可能无法访问控制平面。适用边界是 Oxide 机架和控制平面的设计共识，不包含完整架构实现或实验结果。
推荐收录。该 RFD 不是泛泛的产品愿景，而是用 CP/PL/BPO/OHF/IUP 分类、故障更换 walkthrough 和容量规划问题清单，把硬件运维需求结构化，并给出一致性、无意外等可验证的设计原则。适合基础设施、SRE、硬件控制平面与系统设计读者，可迁移到故障管理、容量规划和现场可服务性设计；局限是高度绑定 Oxide 机架及产品假设。
工程实践Oxide Public RFDs
本文是 Oxide Computer 的 RFD 169，讨论 Web Console 以静态 JS 包由 Nexus 提供后，浏览器直接调用 API 时的认证与会话管理。方案采用随机串 session cookie，服务端 sessions 表关联用户，并配置 Secure、HttpOnly、SameSite=Lax 以及空闲和绝对超时。为缓解 CSRF，文章在 SameSite 之外叠加会话级 CSRF token 与自定义请求头，借同源策略和 CORS 预检阻止第三方构造请求；HttpOnly 用于降低 XSS 窃取会话的风险。文中还描述登录 OAuth 流程、未认证时 API 返回 401 而页面重定向、过期会话硬删除和登录后回跳等取舍，并指出浏览器兼容、子域不可信和 token 生命周期等边界。适合设计 SPA 控制台、API 认证与 Web 安全机制的后端/安全工程师参考。
推荐收录：这是 Oxide 公开 RFD，正文给出可验证的会话 cookie 属性、SameSite+CSRF token/自定义头组合、过期策略和 OAuth 登录流程，不是泛泛的安全清单。对构建 SPA 控制台、API 网关或需要兼顾 CSRF/XSS 的 Web 后端读者，可直接迁移其威胁模型、属性配置和取舍思路；需注意方案绑定 Nexus 与 Oxide 环境，具体 TTL、CORS 和清理作业仍待实现确定。
工程实践Oxide Public RFDs
Oxide 的 RFD 161 定义了整个机架指标数据的建模方式，并确定在 ClickHouse 时序库中存储与查询这些数据。文章先提出数据模型目标——表达力、可操作性、可扩展性、效率与强类型，并借用 Google Monarch 的术语定义 target、metric、timeseries、field 与 metric type。随后用服务请求延迟、虚拟机 CPU 利用率、磁盘温度三个例子给出 target/metric schema 与 timeseries key 的构造方式，并列举代表性查询。核心内容是两种数据库组织方案的对比：字段展开（元数据表加大量 join）与动态表（按 target-metric 对建表，更少 join 但需管理数千张表）。最终决定采用字段展开模型，并列出 pre-quorum 数据、不同时间尺度字段的存储、日志与分布式追踪未覆盖等开放问题。
这是 Oxide 公开的真实架构决策文档，给出两种时序数据建模方案的具体 schema、示例查询与权衡：join 成本对比建表和 schema 管理复杂度，并指出 ClickHouse 数千表下的性能未知，最终明确选定字段展开方案。对设计指标/可观测性平台、在 ClickHouse 等列存库上建模时序数据的工程师有直接参考价值和可迁移的取舍方法。
工程实践Oxide Public RFDs
本文是 Oxide 的公开 RFD 162，描述机架内指标采集系统的架构与设计。文章统一 target、metric、timeseries、measurement、producer、collector 等术语，比较 push/pull 采集模型后确定当前采用 pull 模式，由 Nexus 将 producer 分配给 oximeter 实例并按间隔轮询。设计包括 producer/collector 注册、数据模型校验、oximeter 本地缓存、同一 producer 多 collector 写入不同 ClickHouse 以保证可用性，以及 Nexus、producer、oximeter 三类接口。文末列出对 Nexus/CockroachDB 的依赖、quorum 前遥测、外部查询、schema 更新和访问控制等开放问题。该文接口与取舍清晰，但仍属早期设计，查询实现和落地验证不在范围，部分关键问题未有定论。
推荐收录。该 RFD 给出了指标采集系统从术语、pull/push 取舍、Nexus 分配到 oximeter API 的完整设计链，并明确缓存、多 collector 冗余和开放问题，对构建可观测性平台或理解控制平面指标采集的读者有可迁移价值。风险在于它仍是早期设计文档，查询路径和实现验证缺失，使用时需结合后续实现与数据模型文档判断。
工程实践Oxide Public RFDs
Oxide RFD 116 讨论机架产品中的遥测（telemetry）用例与需求，而非具体架构。作者主张使用更宽泛的 telemetry 而非 metric，以便把软件版本、硬件故障、实时迁移等上下文与定量指标交织起来。文章将能力分为满足既有期望、核心需求与差异化三类，并梳理系统是否达预期、容量规划、内部组件监控、调试和产品迭代等用例。文中还对比公有云默认实例指标、服务器管理传感器与网络设备期望，提出 API、Web 控制台、仪表盘、告警和外部 Oxide 服务等交互方式。V1 明确不做通用客户应用指标采集、机架内无限期存储和第三方集成。该 RFD 仅作为后续架构设计的输入，且网络设备部分未展开。
推荐收录：这是 Oxide 公开的遥测需求 RFD，直接给出能力分类、跨层关联、V1 边界和不做事项，属于可迁移的基础设施与可观测性设计材料。适合平台工程、SRE、可观测性产品与基础设施团队阅读，可用于梳理自研平台的遥测范围与告警取舍。局限是未给出具体实现与存储/查询架构，网络设备小节仍为占位。
工程实践Oxide Public RFDs
该 RFD 讨论 Oxide 控制平面中的 Workflows Engine，用于编排复杂、可能长时间运行的任务，如 VM 创建、SSD 固件升级、虚拟机迁移和故障服务器替换。作者先以 Terraform 类比解释期望状态、当前状态与 workflow 的关系，再调研 Airflow、Argo、Cadence、Conductor、Prefect、Zeebe 等开源引擎，比较语言、执行语义、部署、失败恢复与人工介入等设计维度。文章将工作流分为一次性、可靠一次性、可靠持久三类，提出用 distributed sagas 处理需要完整完成或回滚的控制平面操作，并讨论 exactly-once、超时、通知和用户可见服务等难点。最终决定优先实现内部 saga 引擎，暂缓可靠持久工作流与客户可见服务，Nexus 中已有用于实例创建的原型。
推荐收录：这是一份真实控制平面系统设计的 RFD，给出了工作流分类、开源引擎横向调研、distributed sagas 的取舍以及明确非目标，证据密度高。适合做基础设施、分布式系统、控制平面或云平台架构的读者参考，其中状态/期望态分离、失败回滚与人工介入边界可直接迁移。风险是它绑定 Oxide 内部场景，读者需自行判断适用范围。
工程实践Oxide Public RFDs
该 RFD 界定 Oxide 控制平面持久化数据存储需求：需存储实例、虚拟磁盘、网络资源、服务器、用户/SSH 密钥等对象，支持持久 CRUD、分页一致性枚举和乐观并发控制，并讨论 ACID 是否必需。非功能要求包括强一致、有限故障下可读写、零计划停机、无人值守、可诊断、安全、开源与低成本，且把逻辑复制和在线 schema 迁移列为一等能力。文中估算单机架约万级实例、约 100 GiB 数据，外部 API 延迟需数百毫秒内、数据库访问约 150ms 内，短生命周期负载可达千级 rps；作者据此主张先评估现有系统，并给出从调研、Jepsen 失败分析到部署、故障与长时压测的漏斗式选型方法。候选聚焦 CockroachDB、Yugabyte、TiKV/TiDB、VoltDB 等 NewSQL，排除传统 RDBMS、NoSQL、FoundationDB 与 ZooKeeper/Etcd 类系统；但该文仍是早期需求框架，未给出最终基准和选型结果。
推荐收录。该文不是产品宣传，而是把控制平面数据存储的功能/非功能需求、规模与延迟估算、自研与采购取舍、候选 NewSQL 及排除项、以及分阶段评估方法写得很具体，对设计高可用控制平面、做分布式数据库选型或需要向团队说明存储约束的工程师有直接参考价值。局限是它属于早期 RFD，未给出实测基准和最终选型，读者应把它当作需求清单和评估框架而非结论。
工程实践Oxide Public RFDs
这是 Oxide 的 RFD 83，提出把每周三设为 Focus Day，专门保护员工长时间专注工作，避免会议切割专注时间。文章强调协作与独立深度工作都重要，而会议影响会超出原定时段，因此需要制度性保护。选择周三既能限制连续会议日数量，也让周初协作成果输入周中专注工作，再反哺周尾协作。执行上要求当天不排会议，仅在紧急且所有参与者同意时例外，并且不期待同事即时回复。文章也承认这会加重其他工作日会议压力，需预留准备和会后讨论缓冲，并关注视频会议疲劳。
推荐收录，因为这是来自真实工程组织的制度设计文档，给出了 Focus Day 的具体动机、周三选择理由、会议例外规则和沟通边界，而非泛泛倡导专注。对需要设计团队协作、会议治理或工程效率制度的读者，可迁移其中的“用整块时间对抗会议碎片化”思路。注意它是一份组织政策提案，效果依赖团队共识和外部协作约束。
工程实践Oxide Public RFDs
RFD 70 提出多租户基础设施中容量、分配与利用率的管理框架，先区分 in-use、provisioned、reserved、capacity，并定义 utilization、threshold、overprovisioning、bursting。其核心原则是用透明、可操作的数据帮助用户和运维决策：展示容量仪表盘与按用户/团队/项目下钻视图，设置阈值告警，提供一键调整实例或磁盘、通知项目成员的流程，并用配额防止过度分配。文档明确反对超售，强调扩容与缩容并重、按实际使用率优化，并建议将利用率与成本节省纳入账单，甚至用排行榜激励良好使用习惯。它属于早期设计讨论稿，给出术语、原则、指标和交互场景，但缺少实现细节、规模化验证和预测模型的量化评估。适用于云平台、SRE 与基础设施容量治理场景。
推荐收录：它把容量治理从“看监控”推进到可操作流程，明确区分 in-use、provisioned、reserved、capacity，并给出仪表盘、阈值告警、配额、扩缩容和账单联动等机制。对云平台、SRE 和基础设施团队，反对超售、以利用率驱动资源调整的原则可直接迁移到多租户容量规划。风险是它仍是 RFD 设计稿，缺少落地数据与实现验证，部分激励机制需按组织裁剪。
工程实践Oxide Public RFDs
本文是 Oxide 的 RFD 110，评估将 CockroachDB 作为控制平面数据库的可行性。作者先说明控制平面对强一致、高可用、水平扩展和低运维的诉求，再介绍 CockroachDB 的 range 分片、Raft 写、leaseholder 读、自动分裂/合并与故障恢复机制，并汇总在线扩缩容、长跑、schema 变更、备份恢复、滚动升级及多种故障注入测试。结果显示 CockroachDB 无数据丢失、故障后无需人工干预即可收敛，但扩缩容和 schema 变更会造成明显尾延迟上升，非企业版备份恢复与许可证也是主要风险。作者结论是 CockroachDB 足够可靠，值得继续推进，同时列出未测试项和后续风险。
推荐收录，因为它不是产品介绍，而是包含明确选型目标、测试设计、故障注入结果和风险清单的工程评估。对负责数据库选型、分布式存储或控制平面可靠性的读者，文中的测试维度、CockroachDB 行为边界以及备份/许可证风险可直接迁移到类似系统设计。注意其结论基于特定版本、AWS 与 illumos 环境，绝对性能结论有限。
技术文章Oxide Public RFDs
本文是 Oxide 的 RFD 5，将工程工作划分为 Scoping、Exploration、Prototyping、Determination、Development、Validation、Stress、Production 八个阶段，为未知技术域提供结构化路径。作者强调阶段并非严格线性，可能重叠、回退或并行，硬件项目通常更线性，部分阶段可省略。探索期需提出引导问题，查阅论文、会议、文档、非正式写作并联系专家；原型应围绕明确问题展开。Determination 指出决策时机是艺术，过早或过晚都有代价，重要决策应写入 RFD 并考虑可逆性。后段强调验证宜早、压力测试要主动打破系统、生产阶段须倾听早期失败并反哺改进。整体属通用工程方法论，偏高层原则，未绑定具体技术栈或量化案例。
推荐收录。Oxide 公开 RFD 由 Bryan Cantrill 完整阐述八阶段工程方法，包含各阶段定义、探索问题清单和决策/生产原则；适合在新技术域负责方向判断、架构取舍的工程师与技术负责人。其可迁移价值是提供结构化框架，帮助团队避免过早承诺或死亡行军；限制是偏高层方法论，缺少量化案例，需结合自身领域落地。
工程实践Oxide Public RFDs
本文是 Oxide 公开的 RFD 63，系统阐述单机架到多机架的网络架构设计。文档先给出七项设计目标（低延迟体验、无单点故障、可扩展、兼容客户网络、实例可任意迁移、简化管理、可演进），继而提出物理层采用基于 IPv6 的 L3 + ECMP 架构并把路由决策下推到主机，虚拟层用 Geneve 封装实现 VPC，每台主机运行可编程的 OPTE 完成路由、NAT、防火墙等转换，边界服务则通过 BGP 与客户网络对接。文中以物理转发、内部 DNS、实例互通、出站 NAT、浮动 IP 入站等五条报文流程推演实现路径，并对比 VL2、Ananta、VFP、Andromeda 与 Joyent Fabrics 的经验教训。文档同时声明其边界：不解决信任问题，且为初期产品做了取舍，诸多细节留待后续 RFD 完善。
推荐收录：该 RFD 不是概念宣传，而是给出明确的七项设计目标、L3+ECMP 物理架构，以及 Geneve 之上由 OPTE 承担 L3 转换的完整方案，并用五条报文流程逐步推演，还复盘了 VL2、Ananta、VFP、Andromeda 与 Joyent Fabrics 的取舍和失败教训。对从事云网络、VPC 虚拟化、多租户隔离或数据中心架构的读者，其“目标—决策—权衡”链条极具可迁移价值；需注意它是尚未完全定稿的设计文档，明确不覆盖信任模型，部分细节待后续补充。
工程实践Oxide Public RFDs
本文是 Oxide 的 RFD 0052，定义机架/云平台配额策略的设计。与 IAM 关注“谁可以访问什么”不同，配额策略关注项目或组织可消费的资源数量，只能挂载在组织或项目上，并默认沿资源层级继承，区域策略未显式覆盖时继承全局策略。创建资源时先做 IAM 鉴权，再检查项目配额，不足时返回明确 API 错误；文中还描述通过 UI/CLI/API 申请更多配额、配额将耗尽告警，以及 CPU、磁盘、IP、VPC、VM 类型等配额维度和示例 JSON 语法。边界是初期配额先在第一机架全局设置，多区域后续支持；示例中的 VM 类型配额仍是占位，文档偏设计规范，缺少实现与验证细节。
推荐收录，因为该 RFD 直接给出配额策略的归属层级、继承与区域覆盖规则，以及 IAM 检查顺序、API 错误返回、资源维度和 JSON 示例，属于可复用的平台设计证据。适合云基础设施、API 设计、多租户资源治理方向的读者；其继承模型和告警/申请流程可迁移到类似平台，但实现细节和 VM 类型定义仍需后续文档补全。
工程实践Oxide Public RFDs
RFD 56 设计 Oxide 的 Billing API，目标是支持客户对其内部组织、项目和用户做资源计费与 chargeback/showback。文档定义了 /system/billing、组织和项目计费汇总等端点，允许按资源类型配置按秒、分或日计价，并考虑按区域定价和 standard/spot 实例服务等级。价格变更只影响当前及未来账期，v1 不追溯历史账单、不删除计费项，但保留未来定价生效时间和历史调整的扩展空间。计费流程涵盖组织默认 billing account、项目切换账单账户、月度发票、历史发票、第三方集成、信用额度及未使用配额展示。它还描述了预算告警与邮件通知，但属于设计提案，缺少实现验证和长期运营数据。
推荐收录。该 RFD 提供了完整的 Billing API 端点、计价粒度、组织/项目账单账户、发票、信用额度和第三方集成设计，并明确 v1 不追溯历史账单、不删除计费项等边界。适合云平台/基础设施开发者、API 设计者及多租户计费系统设计者参考，可迁移到 chargeback、预算告警和账单集成场景；风险是它属于设计提案，尚未展示实现与运营验证。
工程实践Oxide Public RFDs
本文是 Oxide Rack 控制平面需求型 RFD，界定数据平面与控制平面边界，并列出开发者 API、运维 API、生命周期、远程支持和指标采集等功能。作者主张控制平面状态为权威状态并尽量同步传播到数据平面，提出可用性、持久性、强一致性、可扩展性和安全性等非功能要求。存储部分比较 FoundationDB/CockroachDB、PostgreSQL 复制与 Raft 加本地存储等方案，并强调逻辑复制价值。迁移部分区分计划内 live migration 与非计划迁移，讨论自动恢复的分裂脑、故障放大和资源耗尽风险。多机架控制平面被推迟，许多细节仍开放，故本文更像需求与设计取舍清单。
推荐收录。文中以明确的需求条目和设计取舍讨论了控制平面 API、权威状态、同步/异步传播、可用性与持久性目标、存储选型及自动迁移风险，证据密度高。适合云基础设施、分布式系统和控制平面架构读者作为需求清单与风险检查表；但它是需求型 RFD，很多实现细节与多机架方案仍 TBD，使用时需结合后续 RFD 与实现验证。
工程实践Oxide Public RFDs
RFD 45 定义 Oxide 机架面向运维人员的系统级 API，提供跨项目/虚拟机的全局指标与硬件库存视图。指标 API 覆盖 CPU、内存、存储和网络的容量、利用率或收发计数，规定 60 秒采样且最长 240 秒后才可见，并支持按项目、服务器、机架等维度查询。库存 API 通过 Component、Firmware 等模型描述组件健康、错误、保修、固件历史和设置，用于盘点和告警。文中还提出 SQL 查询与自定义仪表盘，但后者推迟到 MVP 之后。整体是讨论阶段的 API 设计草案，查询语义和实现边界尚未完全确定。
推荐收录：该 RFD 给出了可落地的系统级 API 端点、OpenAPI 数据模型和指标采样语义，并系统梳理了运维人员关心的容量、利用率、库存、固件与健康问题。适合平台工程、基础设施、监控/可观测性和 API 设计读者参考，其按资源维度聚合与库存建模思路可迁移到类似管理平面。需注意它仍是讨论阶段草案，部分接口和实现边界未定，不能当作最终规范直接照搬。
工程实践Oxide Public RFDs
RFD 0020 定义 Oxide 的 Host Bootstrap Software（HBS）目标：只覆盖主机处理器从复位后到移交宿主 OS 前的软件。其核心职责是加载 HOS 镜像、扩展信任并移交控制权。文档限定只能从预置 M.2 NVMe 或 SP UART 启动，拒绝任意介质和交互式启动，失败需经 SP 上报。实现上依赖 AMD PSP 初始化 DRAM 后唤醒 x86 核心，安全策略点类似 UEFI SEC，并强调功能尽量下沉到 HOS、用声明式描述替代常驻固件。目标包括开源可重分发、快速启动、有限 G/S 状态且不追求 PC 兼容；部分内容已被 RFD 241/215/216 取代。
推荐收录，因为它不是泛泛的固件介绍，而是给出 HBS 的职责边界、启动链、信任扩展、启动介质限制和非目标，可直接用于理解现代服务器从 PSP 到 HOS 的启动设计。对做操作系统、固件/引导、系统安全和基础设施架构的读者有较高迁移价值，尤其是功能下沉 HOS、声明式描述和最小化常驻固件的原则。需注意文档绑定 Oxide/AMD 平台且部分细节已被后续 RFD 取代，使用时应交叉核对。
工程实践Oxide Public RFDs
本文是 Oxide 的 RFD 58，围绕机架交换机（rack switch）的需求与设计空间展开，系统梳理控制面、块存储与应用三类流量对交换机的功能要求。作者讨论双交换机冗余、Tofino 2 与 Tomahawk 3 的 ASIC 选型、外部 PCIe 连接、热插拔、带外管理与 NC-SI/专用管理网络等关键取舍，并以可证明固件完整性和无单点故障为目标。最终计划采用 Tofino 2 作为交换 ASIC，并选择专用管理网络而非 NC-SI，同时说明升级到 200G、QSFP28 光模块管理和多机架组网等扩展方向。该文档面向机架级基础设施设计，很多结论绑定 Oxide 的硬件形态与供应链约束，偏架构决策记录而非通用教程。
推荐收录：该 RFD 不是产品宣传，而是从需求分类、ASIC 选型、PCIe 热插拔到带外管理网络的一手架构决策记录，包含明确约束、备选方案与取舍理由。适合做机架级网络、数据中心硬件、系统可靠性或基础设施架构的读者参考，其冗余设计、固件 attestation、管理面与数据面隔离等思路可迁移到类似系统。风险是结论高度依赖 Oxide 的供应链和硬件形态，需结合自身平台重新评估。
工程实践Oxide Public RFDs
本文是 Oxide 的 RFD 79，讨论控制平面软件在 Rust 中应选择 async/await 事件驱动还是同步多线程（threaded）方案。作者从内存占用、线程池规模设定、病态场景行为、编程模型易用性与可调试性五个维度逐项对比，并用权衡表和风险表量化两种方案的优劣、发生概率与缓解手段。核心结论是：在能够按需投入可调试性建设（自定义 executor、动态追踪、指标采集等）的前提下，建议继续沿用基于 async/await 的事件驱动方案。文章还讨论了不使用 async/await 的事件方案与 channel 通信的取舍，以及该决策难以低成本回退的边界。
推荐收录，因为它把一次真实且代价高昂的并发模型选型拆解为内存、线程池调优、病态故障、编程模型和可调试性等可验证维度，并给出风险概率、严重度与缓解措施。对负责 Rust 后端、控制平面或高可用服务的工程师，文中关于线程池设置、超时与并发上限、异步调试取舍的分析可直接迁移到类似系统设计中。
工程实践Oxide Public RFDs
该 RFD 讨论 Oxide 机架块存储设施的架构选择，目标是为 VM 提供弹性、安全且性能足够的虚拟块设备，并支持快照、镜像和备份等能力。作者将存储系统抽象为靠近 VM 的 North 与靠近 SSD 的 South，逐项界定数据冗余、修复重建、完整性校验、快照、限流、压缩、加密、分配与设备管理等职责。随后评估 Ceph、Lustre、GlusterFS、OpenZFS、DRBD、分布式 KV 等候选软件，并提出 Southern Volume Manager、Northern Mux、ZFS on ZFS、ZFS with Remote Allocation 四种候选架构。通过 AWS 模拟，Southern Volume Manager 性能约为本地 SSD 的 10%，且失败韧性不足；Northern Mux 则用模拟器验证失败与成功路径算法，早期结果较有希望。最终结论倾向 Northern Mux，并计划继续开发模拟器、AWS 测试台与压测工作负载；v1 优先交付时间、数据完整性和安全，性能与经济性并非首要目标。
推荐收录，因为这是一份真实基础设施架构决策记录：它明确比较四种块存储架构在冗余、修复、校验、快照、加密和分配等职责上的取舍，并用 AWS 模拟与失败场景测试淘汰 Southern Volume Manager。对从事块存储、分布式系统、虚拟化基础设施或可靠性设计的读者，North/South 分层、冗余数据路径、性能压测指标及 ZFS/Ceph 评估方法都有可迁移价值；但结论面向 Oxide 特定机架环境，需结合自身约束判断。
工程实践Oxide Public RFDs
这份 Oxide RFD 讨论多机架部署的故障域与资源作用域。作者沿用云行业概念，提出从 server、rack、cell、AZ、region 到 fleet 的层级，并定义每层默认故障爆炸半径与共享资源边界。随后给出实例、存储、网络、镜像、项目和认证等资源的建议作用域及汇总表，例如实例归 AZ、存储卷归 Cell、虚拟网络和项目归 Region、认证归 Fleet。文中还讨论客户需自行构建真实独立故障域、跨 AZ/跨 Region 链路信任与加密、管理平面单一视图等开放问题。当前多为设计假设，尚未实现验证，且默认 v1 可能仅面向单机架，细节仍会随其他 RFD 演进。
推荐收录。该 RFD 直接给出从服务器到 fleet 的故障域层级和资源 coherence 汇总表，并系统权衡了多机架下的可用性、网络、存储与 API 作用域，属于可迁移的架构设计材料。适合云基础设施、分布式系统和控制平面设计者阅读，用于设计多 AZ/多 Region 的部署边界；但需注意其尚未落地验证，部分结论仍标注为开放问题。
工程实践Oxide Public RFDs
该 RFD 定义 Oxide Rack 的用户网络 API，覆盖 VPC、子网、路由表、Internet Gateway、浮动/临时 IP、DNS、防火墙与 VPC Peering 等核心模型。文档用三层博客架构示例说明浮动 IP、负载均衡、子网路由、NAT 网关和数据库间的流量路径，并给出最长前缀匹配、自定义路由优先、防火墙优先级与状态化规则等关键行为。它还描述默认规则、IP 保留、DNS 命名方案、VPC 隔离/对等约束及 VNIC/DHCP 表现。内容偏重平台网络 API 与架构设计，含未来方向与开放问题，适合云网络和基础设施工程师参考，但并非通用实现教程，且部分 API 端点细节未完整展开。
推荐收录：该文档以真实产品 RFD 形式给出 VPC、路由、NAT、浮动 IP、DNS 和安全组/防火墙的完整设计模型与示例，包含可验证的规则优先级、默认行为和边界条件，而不是泛泛介绍。适合云网络、基础设施、API 设计工程师在规划多租户网络、隔离、对外暴露和排障规则时迁移参考；风险在于它绑定 Oxide 的特定实现，部分端点与未来方向仍在讨论中。
工程实践Oxide Public RFDs
本文是 Oxide 计算机公司发布的 RFD 4，关于用户面向 API 的早期设计草图。文章系统阐述了云平台 API 的设计原则：采用 OpenAPI 规范生成多语言客户端与静态文档，追求极简、直观并优先满足 Terraform、Kubernetes 等上游集成需求。核心设计包括异步操作返回 operationId、用 Etags 做条件请求与并发控制、PUT 整体替换资源、暂不支持 PATCH、以及 Stripe 式版本迁移策略；同时覆盖认证（OAuth2、SSH 密钥、2FA）、资源模型（Projects、Instances、Tags）和身份元数据等。作者明确 GraphQL 不是优先项，并强调 API 需保持向后兼容。该文档注明具体 API 已过时，应参考后续 RFD 322 和实际 OpenAPI 描述，但其原则仍具参考价值。
推荐收录。该 RFD 并非产品发布稿，而是公开的 API 设计决策记录，完整呈现了云平台 API 在 OpenAPI 客户端生成、异步操作、Etags 并发控制、版本迁移、认证与资源建模上的取舍与理由。对从事云基础设施、API 平台、系统设计的读者有直接可迁移价值。需注意文档自述具体 schema 已过时，应结合后续 RFD 和实际 OpenAPI 描述阅读。