YAML 为何成运维标准之一

YAML（YAML Ain’t Markup Language）之所以成为运维（尤其是云原生和自动化运维）领域的“事实标准”之一，核心原因在于它平衡了“人易读”和“机易解析”，并且恰好踩中了运维技术演进的关键节点。

下面从几个维度说明原因：

1. 可读性极强，接近自然语言

运维配置文件往往由人编写、也需要人 review。

YAML 的特点：

• 使用缩进表示层级（像 Python）
• 没有多余符号（相比 XML 的 <tag>、JSON 的 {} ""）
• 支持注释（#）

示例对比：

XML

<service>
  <name>nginx</name>
  <replicas>3</replicas>
</service>

JSON

{
  "service": {
    "name": "nginx",
    "replicas": 3
  }
}

YAML

service:
  name: nginx
  replicas: 3

对运维人员来说，YAML 一眼就能看懂。

2. 完美契合“基础设施即代码（IaC）”

现代运维强调：

• 环境可描述
• 配置可版本化
• 变更可回溯

YAML 天然适合写“声明式配置”：

• Kubernetes 所有资源都是 YAML
• Ansible Playbook 是 YAML
• Terraform（部分场景）、GitHub Actions、GitLab CI 也都用 YAML

例如 K8s：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3

这种“描述期望状态”的方式，和运维理念高度一致。

3. 被云原生生态“绑定”

YAML 成为标准，很大程度上是生态推动：

• Kubernetes（2014+）全面采用 YAML
• CNCF 项目几乎全用 YAML
• CI/CD 工具（GitLab CI、GitHub Actions、Drone）统一 YAML
• Helm / Kustomize 也是 YAML 衍生

当“行业标准工具”都用 YAML，YAML 就成了标准。

4. 比 JSON 更适合手写和维护

JSON 更适合“机器之间通信”，但不适合人写：

• 不能写注释
• 引号、逗号容易错
• 多层嵌套极难读

YAML 弥补了这些痛点，同时：

• 可被解析为 JSON 结构
• 工具链成熟（yaml lint、schema 校验）

5. 表达能力强，但不过度复杂

YAML 支持：

• 列表、字典
• 多行文本
• 锚点复用（advanced）
• 类型自动推断

足以描述复杂系统，又不会像 XML 那样臃肿。

6. 工具和语言支持极好

几乎所有语言都支持 YAML：

• Python（PyYAML）
• Go（k8s 生态）
• Ruby / Java / Node

CI、配置中心、编排系统都能轻松解析。

总结一句话

YAML 成为运维标准，是因为它“人能写、人能读、机器能解析”，并且被 Kubernetes 和云原生生态直接封神。

如果你愿意，我也可以讲：

• YAML 的坑（缩进、类型陷阱）
• YAML vs JSON vs HCL
• 为什么有些团队开始“嫌弃 YAML”