linux 运维稳定性建设核心是建立可感知、可控制、可收敛的故障响应闭环，聚焦预防、发现、切换、恢复四环节，按接入层、逻辑层、数据层、基础设施层设防，并强化心跳与决策分离、健康检查标准化、fencing 机制及 slo 驱动的故障推演。
Linux 运维稳定性建设的核心，不是堆砌工具，而是建立一套可感知、可控制、可收敛的故障响应闭环。高可用运维思路本质是“用冗余换时间，用自动化换确定性”，重点落在预防、发现、切换、恢复四个环节上。
从单点防御转向系统级容错
避免把高可用等同于“加一台备用机器”。真实场景中，故障可能来自网络分区、磁盘静默错误、内核死锁、配置误发或时钟漂移。运维需按层设防：
- 接入层：用 Keepalived+VRRP 做 VIP 漂移，但必须配合接口级健康检查（如 curl -f http://localhost/health），不能只探端口
- 逻辑层：服务启动前加入预检脚本，校验磁盘空间、内存余量、依赖端口是否就绪，失败则拒绝注册为可用节点
- 数据层：数据库主从切换必须带 GTID 或日志位点校验，禁止无脑提拔从库；文件同步优先用 rsync+inotify 而非单纯定时同步
- 基础设施层：禁用 IPv6 若未使用；chrony 全集群强制时间同步；关键路径网卡启用 bonding 且配置 lacp 超时策略
心跳与决策必须分离且可验证
Corosync 负责底层心跳通信，Pacemaker 负责资源决策，二者不可混用。常见误区是把健康检查脚本写进 corosync 配置里——这会导致检测失败时仅触发通信告警，却无法驱动资源迁移。
- 心跳链路应独立于业务网络，建议走专用管理网段，并配置多播 + 单播双通道
- 所有健康检查必须返回明确退出码（0= 正常，非 0 = 异常），且支持超时控制（如 timeout 3 curl …）
- 启用 fencing 机制，如 STONITH 插件调用云平台 API 强制关机，防止脑裂导致双主写入
- 资源启动顺序需显式定义依赖，例如：VIP → 存储挂载 → 数据库 → 应用服务
监控不是看板，而是故障推演沙盒
传统监控只告诉你“哪里坏了”，高可用运维需要的是“接下来会怎样坏”。监控体系要能模拟故障路径：
- 在 Prometheus 中定义服务 SLO 指标（如 HTTP 5xx 率
- 用 Grafana 构建拓扑图，点击任一节点可下钻查看其上游依赖状态和下游影响范围
- 定期执行混沌工程演练：随机 kill pacemaker 进程、拔掉 bond 主网卡、注入磁盘 IO 延迟，验证自动恢复时效
- 所有告警必须带上下文，例如“Nginx 节点 A 失联”应附带：最近 3 次健康检查日志、Corosync 收包统计、本地 dmesg 最后 10 行
配置即代码，变更即测试
运维稳定性最大风险源常来自人工操作。所有 HA 配置必须纳入版本控制，并通过 CI 流水线验证：
- Corosync 配置用 ansible 模板生成，每次提交触发语法校验（corosync-cfgtool -s）和配置 diff 比对
- Pacemaker 资源定义用 pcs 命令导出为 XML，Git commit 前运行 xmllint 校验格式合法性
- 上线前在测试环境自动部署整套 HA 集群，执行冒烟测试：模拟主节点宕机→验证 VIP 漂移耗时→检查应用日志连续性
- 生产变更必须带回滚计划，例如 Keepalived 配置更新后，保留前一版本配置并设置自动回滚定时器
