DevOps是开发、测试、运维协同的协作机制；CI/CD是其实际入口，需完整闭环；IaC要求配置与环境严格一致；监控须定义可行动的业务指标；责任边界需在Pipeline跑通前明确写入团队公约。
DevOps 不是一种工具，也不是一个岗位，而是一套把开发、测试、运维拧成一股绳的协作机制——它解决的是“代码写完了却不敢上线”“运维说没问题，一上就崩”这类真实痛点。
为什么 CI/CD 是 DevOps 的实际入口
很多团队以为买了 Jenkins 或 GitLab CI 就算落地 DevOps，结果只是自动化了构建，没打通反馈闭环。CI/CD 真正起效的前提是：每次 git push 后，能自动跑完单元测试 → 构建镜像 → 推送到测试环境 → 执行接口回归 → 生成部署就绪标记。缺任何一环，就只是“半条流水线”。
- 常见错误现象：
build success但测试环境启动失败，因为Dockerfile里硬编码了本地路径 - 使用场景：微服务架构下，每个服务应有独立的
.gitlab-ci.yml或Jenkinsfile，而非共用一套脚本 - 参数差异：
staging和production环境必须用不同密钥、不同配置中心地址，不能靠if [ "$ENV" = "prod" ]临时拼接 - 性能影响：若集成测试耗时超 8 分钟，开发者会跳过本地验证直接提交，导致主干频繁被污染
基础设施即代码（IaC）不是写完就扔，而是要版本对齐
用 Terraform 创建了 10 台服务器，但没人管这版配置是否和线上实际一致。一旦手工改了某台机器的 /etc/nginx/conf.d，下次 terraform apply 就可能覆盖或报冲突。
- 常见错误现象：
terraform plan显示无变更，但terraform state list发现资源缺失，说明有人绕过 IaC 直接操作云控制台 - 使用场景：所有环境（dev/staging/prod）的网络、负载均衡、数据库配置都应由同一份
main.tf+ 不同tfvars文件驱动 - 关键约束：
state文件必须远程存储（如 S3 + DynamoDB 锁），禁用本地terraform.tfstate - 兼容性影响：Terraform 1.0+ 的
for_each写法不兼容 0.12 版本模块，升级前需先terraform 0.15upgrade
监控不是“加个 Prometheus 就完事”，而是要定义可行动的指标
很多团队堆了一堆仪表盘，但告警全是 CPU > 90% 这种无效信号——CPU 高可能是批处理正常运行，也可能是死循环；真正该告的是 HTTP 5xx rate > 1% 或 order_create_latency_p99 > 2s 这类业务可感知的异常。
- 常见错误现象：告警发到钉钉群后无人响应，因为没人知道这个
etcd_leader_changes_total指标涨了意味着什么 - 使用场景：每个服务上线前，必须在
prometheus.rules.yml中定义至少 3 条业务级告警规则，并关联到具体负责人标签 - 性能影响：高频打点（如每秒埋点）不采样会导致 Prometheus 内存暴涨，建议用
count by (job, instance)替代原始事件流
pipeline 跑通前就写进团队公约里。 
