DevOps 原则

CI/CD 流水线

• 快速失败：在昂贵的集成测试之前运行代码检查和单元测试——节省时间和计算资源
• 在不同运行之间缓存依赖项——npm install每次构建都执行会浪费数分钟
• 使用 SHA 固定操作版本，而非标签——actions/checkout@v3可能会变化，SHA 则是不可变的
• 密钥应放在环境变量中，绝不在代码或日志里——在 CI 输出中将其掩码
• 为独立步骤设置并行作业——测试、代码检查和构建可以同时运行

部署策略

• 蓝绿部署：新版本与旧版本并行运行，原子性地切换流量——通过切回旧版本实现即时回滚
• 金丝雀发布：将一定比例的流量路由到新版本——在全量发布前发现问题
• 滚动更新：逐步更新实例——在速度和风险之间取得平衡
• 部署前始终制定回滚计划——明确知道如何回退
• 将所有环境部署相同的构建产物——一次构建，分阶段推进

基础设施即代码

• 所有基础设施配置（Terraform、Ansible、CloudFormation）都应进行版本控制，并存储在Git中
• 未经计划/差异审查，切勿应用变更执行terraform plan在应用变更之前
• 状态文件包含敏感信息——应远程加密存储，切勿放入Git
• 使用模块化设计实现组件复用——避免复制粘贴基础设施定义
• 通过工作区或目录隔离环境——开发环境的变更不应影响生产环境

容器

• 单容器单进程原则——容器不是虚拟机
• 必须配置健康检查——编排器依赖其进行路由和重启决策
• 禁止以root权限运行——在Dockerfile中使用非root用户
• 保持镜像不可变性：通过环境变量配置，而非固化到镜像中——所有环境使用相同镜像
• 使用Git SHA值标记镜像，而非仅使用latest标签——精确掌握部署内容

密钥管理

• 切勿将密钥存储在提交至git的环境文件中——应使用保险库、加密密钥或CI密钥存储
• 定期轮换密钥——自动化让轮换变得轻松无痛
• 不同环境使用不同密钥——开发环境泄露不应影响生产环境
• 审计密钥访问——清楚谁在何时访问了什么
• 密钥尽量存于内存而非磁盘——临时文件的存留时间可能超出预期

监控与告警

• 四大黄金指标：延迟、流量、错误、饱和度——从这里开始
• 针对症状而非原因告警——“用户看到错误”而非“CPU过高”
• 每条告警必须可操作——若无法采取行动，则只是噪音
• 每个服务配备关键指标仪表盘——一眼可知健康状况
• 采用结构化日志（JSON）便于机器解析——grep可行，但查询更佳

可靠性

• 建立告警前先定义SLO——对该服务而言“健康”意味着什么？
• 错误预算：允许部分故障——99.9%可用性意味着每年8小时停机是可接受的
• 在预演环境中进行混沌工程——在意外发生前主动制造故障
• 常见事故操作手册——凌晨三点可不是琢磨恢复步骤的时候
• 无问责复盘会——聚焦系统问题，而非个人责任

常见误区

• 直连生产环境修复问题——所有变更都应通过自动化完成，否则你终将忘记操作记录
• 缺少预发布环境——“我机器上能运行”不等于生产环境可行
• 放任不稳定测试——这会侵蚀对持续集成的信任，必须修复或删除
• 部署流程包含人工步骤——未自动化的环节终将出错
• 仅监控正常流程——必须同时关注错误率与边界情况

网络架构

• 内部服务无需公网IP——使用私有子网，仅暴露负载均衡器
• 全链路TLS加密——包括内部流量，即使防火墙后也需零信任机制
• 采用DNS服务发现——硬编码IP在服务迁移时将导致故障
• 负载均衡健康检查独立于应用健康检查——前者需要快速响应，后者可以更全面
• 防火墙默认拒绝策略——仅显式放行必要流量，阻断其余所有访问