全栈面试：DevOps 与部署
CI/CD 是什么？
CI 是持续集成，强调频繁提交代码后自动构建、测试和检查。
CD 是持续交付或持续部署，强调把通过检查的代码自动发布到环境。
常见流程：
- 提交代码
- 运行 lint
- 运行测试
- 构建产物
- 部署到测试环境
- 人工确认或自动发布生产
Docker 解决什么问题？
Docker 把应用和运行环境打包成镜像，减少“我本地可以运行，服务器不行”的问题。
核心概念：
- Image 镜像
- Container 容器
- Dockerfile
- Registry 镜像仓库
- Volume
- Network
面试时可以补充：Docker 不是虚拟机，它更轻量，但也需要关注镜像体积、安全和配置管理。
Nginx 常见用途有哪些？
常见用途：
- 静态资源服务
- 反向代理
- 负载均衡
- HTTPS 终止
- gzip 压缩
- 路由转发
- 缓存
前端项目常用 Nginx 托管静态文件，并把 /api 转发到后端服务。
环境变量有什么作用？
环境变量用于区分不同环境配置，例如：
- API 地址
- 数据库连接
- Redis 地址
- 密钥
- 日志级别
不要把密钥写死在代码里，也不要提交到 Git 仓库。
常见环境：
- local
- dev
- test
- staging
- production
蓝绿部署和灰度发布有什么区别？
蓝绿部署是准备两套环境，一套当前对外服务，一套部署新版本，验证后切流量。
灰度发布是让一小部分用户先使用新版本，观察稳定后逐步扩大范围。
对比：
- 蓝绿切换快，回滚方便，但资源成本较高。
- 灰度更稳，可以降低影响范围，但流量控制更复杂。
如何做回滚？
常见回滚方式：
- 重新部署上一个版本
- 镜像版本回退
- 蓝绿环境切回旧版本
- Feature Flag 关闭新功能
- 数据库变更预留回滚方案
注意：代码回滚容易，数据结构和数据写入回滚更难，所以数据库迁移要特别谨慎。
日志应该记录什么？
常见字段：
- timestamp
- level
- requestId
- userId
- path
- method
- status
- duration
- error stack
不要记录密码、token、身份证、银行卡等敏感信息。
线上故障怎么排查？
常见步骤：
- 确认影响范围。
- 查看告警和监控。
- 查看最近发布记录。
- 查看错误日志和 requestId。
- 检查数据库、缓存、队列和第三方服务。
- 先止血，再定位根因。
- 复盘并补充监控和测试。
面试时可以强调：线上事故先恢复服务，再追求完美定位。
DevOps 面试追问
如何部署前端静态站点？
前端静态站点通常先构建生成 dist，再部署到 Nginx、对象存储、CDN 或静态托管平台。SPA 项目要配置路由回退到 index.html，否则刷新深层路径会 404。
生产环境还要处理缓存策略：带 hash 的静态资源可以长缓存，index.html 不宜强缓存。发布后可以通过健康检查和页面探活确认站点可访问。
如何部署 Node.js 服务？
Node.js 服务部署一般包括安装依赖、构建、配置环境变量、启动进程和接入反向代理。进程管理可以用 PM2、systemd、Docker 或 Kubernetes。
需要关注端口、日志、异常重启、健康检查、优雅关闭和资源限制。线上服务不能依赖本地 .env，生产配置应该由部署平台或密钥管理系统注入。
Dockerfile 如何优化？
Dockerfile 优化重点是减小镜像体积、提高构建缓存命中和降低安全风险。常见做法是使用多阶段构建，只把运行所需文件复制进最终镜像。
还可以选择更小的基础镜像、固定依赖版本、合并层、避免复制无关文件，并用非 root 用户运行服务。面试时可以补充 .dockerignore 很重要。
如何管理生产环境配置？
生产配置应该和代码分离，通过环境变量、配置中心或密钥管理系统注入。不同环境要有清晰边界，例如开发、测试、预发、生产。
敏感配置如数据库密码、API key 不能提交到仓库。配置变更要有审计、灰度和回滚能力，避免一次配置错误影响全量服务。
如何做健康检查？
健康检查通常分为存活检查和就绪检查。存活检查判断进程是否还活着，就绪检查判断服务是否可以接流量，例如数据库、缓存、依赖是否可用。
接口可以设计为 /health 或 /ready，返回状态、版本和关键依赖结果。注意健康检查不能太重，否则检查本身会拖垮服务。
如何做日志收集？
日志收集一般由应用输出结构化日志，再通过采集器收集到日志平台，例如 ELK、Loki 或云日志服务。日志要包含时间、级别、requestId、服务名、接口、耗时和错误信息。
敏感数据要脱敏，日志量要控制采样和保留周期。好的日志应该能支持搜索、聚合、告警和事故复盘。
如何处理发布后接口报错？
先看影响范围和错误率，如果影响用户核心流程，优先回滚或降级。然后根据版本、requestId、错误日志、监控指标和最近变更定位问题。
常见原因包括配置错误、数据库变更不兼容、依赖服务异常、环境变量缺失、接口字段变更。处理顺序是先恢复服务，再补根因修复和回归测试。
如何设计 Git 分支流程？
小团队可以使用 trunk-based development，主分支保持可发布，功能通过短分支和 PR 合入。更传统的团队可以使用 main、develop、feature、release、hotfix 分支。
关键不是分支越多越好，而是保证代码评审、自动化测试、可回滚和发布节奏清晰。紧急修复要能从生产分支拉 hotfix，并及时合回主开发线。