第二章：工具链全景图——CI/CD、版本控制、配置管理、监控告警、容器编排
说实话，我刚入行那会儿，DevOps 这个词还没这么火。那时候大家各管各的，开发写代码，运维管服务器，出了问题互相甩锅。后来我慢慢意识到，工具链的整合才是 DevOps 的灵魂。今天我就带你一张图看懂整个生态。
2.1 版本控制：一切的基础
版本控制是 DevOps 的基石。没有它，后面所有环节都是空中楼阁。
Git 是绝对的主流。我见过不少团队还在用 SVN，说实话，迁移到 Git 之后，分支管理和协作效率提升不止一个档次。我个人习惯用 GitFlow 工作流，但小团队其实用 GitHub Flow 更轻量。
核心工具对比
| 工具 | 适用场景 | 我的评价 |
|---|---|---|
| GitHub | 开源项目、中小团队 | 生态最好，Actions 很香 |
| GitLab | 企业级、自托管 | CI/CD 集成度高，我项目里常用 |
| Bitbucket | Jira 生态用户 | 和 Atlassian 全家桶配合不错 |
避坑指南：我曾经遇到一个团队，所有代码都往 master 分支推，结果上线前合并冲突搞了三天。记住，分支策略一定要提前定好。
2.2 CI/CD：自动化的心脏
CI/CD 说白了就是让代码从提交到上线全自动跑起来。我刚开始做 CI 时，觉得不就是跑个脚本吗？后来发现坑多着呢。
持续集成（CI）：每次代码提交都自动构建、测试。我建议至少跑单元测试和代码扫描。
持续交付（CD）：自动部署到测试环境，人工确认后上线。
持续部署：全自动，连确认都省了。嗯，这个风险比较大，我一般只在非核心服务上用。
主流 CI/CD 工具
- Jenkins：老牌工具，插件丰富，但配置起来有点重。我早期项目都用它。
- GitLab CI：和 GitLab 无缝集成，.gitlab-ci.yml 写起来很爽。
- GitHub Actions：现在我最常用的，市场里现成的 action 太多了。
- ArgoCD：Kubernetes 环境下的 CD 利器，声明式部署，我用它做 GitOps。
# 一个简单的 GitLab CI 示例
stages:
- build
- test
- deploy
build-job:
stage: build
script:
- echo "编译代码..."
- mvn clean package
test-job:
stage: test
script:
- echo "跑单元测试..."
- mvn test
deploy-job:
stage: deploy
script:
- echo "部署到服务器..."
- scp target/*.jar user@server:/app/
注意：流水线里千万别写死密码。用变量或者密钥管理工具，比如 Vault。我曾经见过有人把数据库密码直接写在脚本里，结果代码泄露了...嗯，那场面很尴尬。
2.3 配置管理：别让环境差异坑了你
配置管理解决的是「为什么开发环境能跑，生产环境就挂了」的问题。你想想看，是不是经常遇到这种情况？
基础设施即代码（IaC） 是核心思想。用代码来管理服务器、网络、中间件。
工具选型
| 工具 | 类型 | 我的使用感受 |
|---|---|---|
| Ansible | 配置管理 | 无代理，SSH 直连，上手快。我用来批量改服务器配置。 |
| Terraform | 基础设施编排 | 声明式，多云管理。我建云资源首选。 |
| Pulumi | 基础设施编排 | 用编程语言写 IaC，适合开发团队。 |
| Helm | K8s 包管理 | 管理 K8s 应用，模板化部署。 |
个人经验：我建议配置和代码分开管理。用 Consul 或 etcd 做配置中心，这样改配置不用重新部署。我之前有个项目，配置写在代码里，每次改个数据库连接都要发版，累死人。
2.4 监控告警：系统的眼睛
没有监控，你就像蒙着眼睛开车。我见过太多系统挂了半天，运维还在群里问「有人反映卡了吗？」。
监控四层体系：
- 基础设施监控：CPU、内存、磁盘、网络。Prometheus + Node Exporter 是标配。
- 应用监控：接口响应时间、错误率、QPS。我用 SkyWalking 做 APM。
- 日志监控：ELK（Elasticsearch、Logstash、Kibana）或者 Loki。
- 告警通知：Alertmanager + 钉钉/企业微信/邮件。
我的监控栈推荐
- Prometheus：时序数据库，采集和告警一体。我几乎所有项目都用它。
- Grafana：可视化面板，图表做得漂亮。可以接 Prometheus、InfluxDB 等。
- Alertmanager：告警管理，去重、分组、静默。嗯，这个配置有点复杂，但值得花时间。
# Prometheus 告警规则示例
groups:
- name: example
rules:
- alert: HighCpuUsage
expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
for: 5m
labels:
severity: warning
annotations:
summary: "CPU 使用率超过 80%"
避坑指南：我曾经把告警阈值设得太低，结果半夜被告警轰炸，全是误报。后来我学乖了，先设一个宽松的阈值，观察一周再收紧。还有，告警一定要有「静默期」，别重复发。
2.5 容器编排：云原生的基石
容器化之后，怎么管理成百上千个容器？这就是容器编排要做的事。
Kubernetes 是事实标准。说实话，K8s 学习曲线确实陡，但一旦上手，你会发现它真的很强大。我刚开始也被各种概念搞晕了——Pod、Service、Deployment、Ingress...后来慢慢就习惯了。
容器编排工具对比
| 工具 | 特点 | 适用场景 |
|---|---|---|
| Kubernetes | 功能全面，生态庞大 | 生产环境首选 |
| Docker Swarm | 简单易用，和 Docker 原生集成 | 小团队、测试环境 |
| Nomad | 轻量，支持非容器工作负载 | 混合部署场景 |
个人建议：如果你刚开始学容器编排，可以先从 Docker Compose 入手，理解服务编排的基本概念。然后再上 K8s。我当年就是这么过来的，一步一个脚印。
2.6 一张图看懂 DevOps 生态
好了，上面讲了五个核心领域。现在我把它们串起来，你想象一下这个流程：
- 开发提交代码到 Git（版本控制）
- 触发 CI/CD 流水线，自动构建、测试
- 用 Terraform/Ansible（配置管理）准备基础设施
- 部署到 Kubernetes（容器编排）集群
- Prometheus + Grafana（监控告警）实时观察运行状态
这五个环节环环相扣，缺一不可。我见过一些团队只上了 CI/CD，但监控和配置管理没跟上，结果上线后出了问题找不到原因。说白了，工具链要配套，不能偏科。
总结一下我的选型建议：
- 小团队（10人以下）：GitHub + GitHub Actions + Ansible + Docker Compose + Prometheus
- 中型团队（10-50人）：GitLab + GitLab CI + Terraform + K8s + Grafana
- 大型企业：自托管 GitLab + Jenkins/ArgoCD + Terraform + K8s + 完整监控栈
嗯，工具选型没有银弹。关键是根据团队规模和业务需求来定。我这些年换过好几套工具链，每次迁移都踩过坑，但也学到了很多。希望这张全景图能帮你少走弯路。