本篇内容主要来自内部的一次分享，也是最近工作的一些总结。 1. 常见的故障处理流程 如上图是一次典型的运维异常处理流程。 按照时间线，有如下关键时间点: 发生故障 发现故障 响应故障 定位故障 恢复故障 发生故障到发现故障，指的是被系统检测到，主要涉及到指标的采

1. 为什么将元数据存储从 Redis 迁移到 PGSQL PGSQL 成本低 Redis 使用内存存储元数据，PGSQL 使用磁盘存储元数据，成本差异显而易见。 PGSQL 性能可调节 不同的 PGSQL 提供了不同的性能 IOPS。如果对性能没有持续高的要求，使用 PGSQL 是不错的选择。 PGSQL 存储上限更高 如果按照元数据大小估算

1. 查看 CPU 查看 CPU 型号 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 46 bits physical, 57 bits virtual CPU(s): 160 # 有 160 个 CPU On-line CPU(s) list: 0-159 Thread(s) per core: 2 # 每个核心支持 2 个线程 Core(s) per socket: 40 Socket(s): 2 NUMA node(s): 2 Vendor ID: GenuineIntel CPU family: 6 Model: 106 Model name: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz Stepping: 6 CPU MHz: 3000.000 # 当前工作频率为 3000 MHz BogoMIPS:

处理故障时，参考或者记录下的内容，持续更新中 1. XID 错误事件 XID 是 NVIDIA 的错误码，可以通过命令: 1 dmesg -T | grep -i "NVRM: Xid" 根据 XID 可以定位故障，下面是一些常见的 XID 事件 XID 说明 13 Graphics Engine Exception。通常是数组越界、指令错误,小概率是硬件问题。 31 GPU memory page fault。

1. 什么是 Ops 项目 我在之前的文章中介绍过一个常用的 Ops 工具。 Ops 的设计理念在于，运维工具的核心在于文本分发和脚本执行，实现了这两种能力就能够满足运维的功能诉求。 目前我主要的运维对象是 Host 主机、Kubernetes 集群，因此在 OpsObject 层实现了 Host 和 Cluster 对象，分别