配置项分级是什么
配置项分级是连续判断：这一项被改坏会怎样、影响多大范围、能否恢复、恢复要多久。判据通常看三点——影响面（单机、整组还是全局链路）、可恢复性（可热改、需重启还是不可逆）、耦合度（是否被其他组件依赖）。分级的意义不在文档好看，而在于它能被工具读取：高等级项的巡检频率更高、变更需要更高审批层级、备份保留更久、漂移告警直接叫醒值班。
基本信息
| 分级维度 | 影响面、可恢复性、耦合度、合规要求 |
|---|---|
| 常见等级 | 致命（影响全局或不可逆）、重要、一般、可忽略 |
| 落地方式 | 分级写入清单文件，供巡检、审批、备份脚本读取 |
| 关键约束 | 分级按后果定，不按操作难易或看起来重不重要 |
典型使用场景
- 决定备份与快照频率：致命项每次变更前必须留档
- 决定审批层级：致命项需业务方参与，一般项值班可批
- 决定巡检节奏：关键项每日比对基线，一般项按周
- 排障排序：故障时先查致命项是否被改动
- 安全与审计：日志、审计开关属于合规相关，虽然日常无感但不能归入可忽略
- 容量规划：连接数、线程池等参数属于性能敏感项，需随规模复核
分级清单与巡检过滤
分级清单与巡检过滤
# 分级清单：让脚本能按级别取用，而不是只写在文档里
items:
- key: ssh_port
file: /etc/ssh/sshd_config
tier: 致命 # 改错会失去登录途径
backup: true
check: daily
- key: ntp_server
file: /etc/chrony.conf
tier: 一般
check: weekly
- key: max_connections
file: /etc/my.cnf
tier: 重要 # 关系连接数与稳定性，需随规模复核
check: daily
# 巡检脚本按级别过滤，避免关键项被日常噪音淹没
# 示例：只对致命与重要项做每日比对
# yq '.items[] | select(.tier=="致命" or .tier=="重要")' tier.yaml | ...分级与配套动作
| 等级 | 判据 | 审批 | 巡检与备份 | 示例项 |
|---|---|---|---|---|
| 致命 | 影响全局或不可逆 | 负责人加业务方 | 每日比对，变更前必留档 | SSH 端口与认证、存储挂载、防火墙策略 |
| 重要 | 影响可用性或性能 | 组件负责人 | 每日比对，保留历史版本 | 连接数上限、超时与重试、证书路径 |
| 一般 | 影响范围局部 | 值班可批 | 按周比对 | NTP、时区、日志级别 |
| 可忽略 | 影响装饰性或易恢复 | 知会即可 | 按需 | 提示语、备注字段 |
分级需要定期复核：同一项在单机部署时是「一般」，上了集群可能变成「致命」。复核触发点通常是架构调整、扩容、合规要求变化，而不是固定周期。
把所有项都定为最高等级，结果是审批与巡检双双失效——流程被绕过，真正高危的项反而没人细看。分级的价值来自取舍。