题干与适用场景
一个多发行版 Linux fleet 想通过 OpenTelemetry 打包仓库安装 Injector、自动插桩包和 Collector，以减少人工部署。官方说明该打包工作仍在早期，仓库不是生产级托管方案，软件包尚未签名。请设计从实验到生产的安全边界、验证、权限和回滚。
面试官考察点
面试官考察你是否能把“安装方便”与“供应链可信”分开，识别脚本权限、包来源、自动注入副作用、网络出口和版本回滚风险。高质量回答会说明哪些环境可以试用、哪些环境必须等待成熟，并给出证据和护栏。
回答前需要澄清的问题
- 目标主机发行版、架构、代理和升级策略是什么？
- 安装的是 Collector、Injector、语言包，还是全部组件？
- 主机是否允许新增 systemd 服务、eBPF 权限和外连端点？
- 组织的软件签名、镜像代理、SBOM 和回滚要求是什么？
30 秒回答
“我不会把早期仓库的一键脚本直接放进生产。先在隔离主机验证包内容、来源、哈希、权限、systemd 单元、网络出口和卸载路径；未签名包只能用于短期实验，不能绕过组织供应链门槛。生产候选必须经过内部镜像、签名验证、最小权限和可回滚版本管理。灰度从非关键主机开始，观察 CPU、内存、网络、进程启动、数据泄露和卸载成功率，护栏失败就停止扩展。”
分步骤深入解答
1. 划定试用边界
把官方仓库标为实验源，不把“可用命令”当作生产批准。选择可重建、无敏感数据的主机，禁止在核心数据库、跳板机和高权限控制节点直接运行。
2. 做供应链验证
锁定仓库提交、包版本和依赖清单，校验下载地址、哈希、构建来源、SBOM 和签名状态。未签名包必须经过内部审核和隔离代理；不得使用脚本中的 trusted 或跳过校验选项来解决安装失败。
3. 检查权限与副作用
审阅安装脚本、systemd unit、文件路径、用户身份、Capabilities、eBPF 需求和防火墙变化。确认 Injector 只作用于允许的进程，Collector 只能访问必要日志和指标，凭据使用短期引用而非明文文件。
4. 控制数据出口
列出 OTLP endpoint、TLS、代理、重试、队列和脱敏规则。先把数据发往隔离后端，验证服务名、主机标识、命令行参数和个人信息不会越过租户或地域边界。无网络时应有明确丢弃或本地缓冲策略。
5. 设计灰度指标
按发行版、架构和业务重要性分批。观察安装成功、进程启动、CPU/内存、eBPF 错误、Collector 队列、出口流量、敏感字段命中和卸载成功率。任何异常只停止新主机加入，不扩大权限来掩盖问题。
6. 回滚和升级
保留原始包、配置、systemd 状态和文件清单；回滚先停 Injector 和 Collector，再恢复旧包和防火墙。为每个版本记录可重复卸载命令与恢复时间。供应链签名、托管仓库和安全审查未成熟前，维持实验范围。
高质量示范回答
我会把这个仓库当实验源。先在可重建主机检查提交、哈希、SBOM、签名、依赖、systemd、权限、eBPF 和网络出口；未签名包不进入生产。Injector 只允许作用于明确进程，Collector 采用最小权限、短期凭据和隔离后端，数据经过 TLS 与脱敏。灰度按发行版和业务重要性推进，观察安装、资源、队列、出口和卸载指标。保留旧包、配置与恢复步骤，失败时停新主机并逐台回滚；直到内部镜像和签名流程成熟才扩大范围。
常见错误
- 一键脚本直接生产运行 → 权限和供应链未知 → 先隔离审阅和内部镜像。
- 忽略未签名包 → 无法证明来源 → 要求哈希、SBOM 和签名门槛。
- 让 Injector 作用所有进程 → 业务和隐私风险扩大 → 按进程白名单限制。
- 只监控安装成功 → 运行后可能泄露数据 → 监控出口、脱敏和资源指标。
- 没有卸载与恢复清单 → 失败后只能人工排障 → 版本化回滚步骤。
追问及应对
未签名包是否完全不能测试？
可以在隔离、无敏感数据且可销毁的环境短期测试，但必须标记为实验，禁止把测试结果当作生产批准。
为什么不直接给脚本 root 权限？
root 会扩大安装脚本和依赖的影响面。应预先审阅所需权限，用专用账号、Capabilities 和受控 systemd 服务缩小边界。
如何证明自动插桩没有改变业务？
对照同版本主机的错误率、延迟、进程启动参数和关键路径，检查新增 span、日志和网络连接；异常时关闭 Injector 而非修改业务代码。
什么时候可以进入生产？
至少需要受控托管仓库、可验证签名、SBOM、最小权限、数据出口审计、可重复回滚和分批验收。早期仓库自身的生产就绪声明不能被推断。