运维工具手册：常用官网与排障命令场景化分类指南

做运维这些年，身边的同事换了好几茬，但有个习惯我一直没扔：每个星期会固定花半小时整理手头的书签和文档。尤其是那些官方的文档站、工具下载页、故障排查手册——别小看这个动作，关键时刻它能救命。有一次凌晨两点线上告警，数据库主从延迟越来越离谱，我从查进程、看慢查询到翻官方文档确认参数含义，全程没超过二十分钟，靠的正是平时积累的工具入口。这篇手册，就是我把自己这些年常用的运维官网和工具按场景重新整理了一遍，分享给准备入行或者正在进阶的同学。它不是什么高深理论，而是一份能直接落地的“找东西”指南：遇到问题知道去哪查、用什么工具、翻哪个页面。

1. 先把运维这摊事拆开：一份可复用的工具分类地图

很多刚入行的同学问我，运维到底要学多少工具才够？我的答案一直是：不要对着工具列表学，要对着“工作场景”学。运维的本质是保障业务稳定运行，围绕这个目标，日常工作基本可以拆成几个固定板块：基础设施与网络、服务器与操作系统、容器与云原生、监控与日志、自动化与发布、数据存储、桌面终端。每一个板块背后，都有一批“官方入口”和“保命工具”，把它们整理清楚，你就拥有了自己的运维地图。

这张表看起来简单，但它的价值在于“分类”。我见过不少运维的浏览器收藏夹里躺着一两百个链接，真到排查问题时却翻不到。原因就是没按场景分类。收藏一个官网之前，你先问自己：这条链接对应哪个板块、解决什么问题、大致怎么用？写一句话备注，才算是真正收集完成。官网和教程网站最大的区别在于，教程可能会过时、可能有笔误，而官网上的 release notes、changelog、官方 FAQ 才是第一手信息。Docker 的 API 变了、Kubernetes 的弃用资源列表更新了，永远都是官网先给出说明。

2. 域名、证书与网络排查：日常接触最频繁的官网入口

网络问题占运维日常工单的比例不低，尤其是涉及域名解析、证书过期、链路质量这三类。先说域名和 DNS。排查解析问题，我基本固定用 dig，参数记得两个就够：dig @8.8.8.8 example.com +short 是快速看解析结果，dig +trace 是完整追踪解析链路，能看到每一步返回的服务器和耗时。nslookup 不是不能用，只是输出信息比较碎，脚本里处理不如 dig 方便。在线工具方面，IP 归属和 DNS 传播查询可以看 ipip.net，它能看到某个域名在全球各地区的解析结果，适合判断“是不是 DNS 还没同步”。

证书过期是每年必踩的坑，比起等到浏览器报错再处理，不如主动监控。检查证书最简单的一条命令：

bash复制echo | openssl s_client -connect www.example.com:443 2>/dev/null | openssl x509 -noout -dates

输出里能看到证书的 notBefore 和 notAfter，配合脚本做成定时检查，到 30 天就提醒，基本能杜绝证书过期事故。这里注意，openssl 的 s_client 在 TLS 1.3 之后行为有变化，有些老版本机器需要加 -servername 参数指定 SNI，否则拿到的是默认证书。另外在线检测可以用 SSL Labs，输入域名就能看到证书链、协议版本、加密套件的完整报告，适合做上线前的安全体检。

链路质量问题用 ping 只能测通断，测不出“哪一跳在丢包”。mtr 才是正经工具，它把 traceroute 和 ping 结合到一起，持续探测每一跳的丢包率和延迟。排查“用户反馈访问偶尔卡顿”这类问题时，先 mtr 一下目标地址，基本能定位是哪一段的问题。抓包工具有 tcpdump 就够了：

bash复制tcpdump -i any -nn host 10.0.0.5 and port 443 -c 100 -w /tmp/capture.pcap

-i any 抓所有网卡，-nn 不解析主机名和端口名，-w 存成 pcap 文件带回去分析。抓包别在业务高峰直接全量抓，容易把网卡跑满，先加过滤条件只抓目标 IP 和目标端口。连接状态排查，ss 比 netstat 好使，ss -antp 能直接看到端口对应哪个进程，排查端口冲突时不用再拿 lsof 绕一圈。

提示：线上环境做网络变更前，建议先看一眼 /etc/resolv.conf 和路由表 ip route，很多“网络不通”其实是 DNS 地址错了或者默认路由丢了，不用一上来就抓包。

3. Linux系统与终端工具：从命令到效率工具的整理

Linux 是运维的基本盘，相关命令多到可以写一本书，但日常真正高频的其实是一小撮。系统发行版官网要认识几个：内核版本看 kernel.org，Ubuntu 桌面或服务器看 ubuntu.com，CentOS 停更后新项目一般转向 Rocky Linux（rockylinux.org）或 AlmaLinux，别再用老 CentOS 7 裸奔了。

性能排查有个固定顺序：先看负载，再看 CPU/内存/IO，最后看日志。uptime 看 load average，top 看 CPU 占用和进程排行，free -h 看内存余量，iostat -x 1 看磁盘 IO 的 await 和 util，vmstat 1 看 r 和 b 队列。这条链路走完，80% 的性能问题都能定位到方向。记录历史性能数据用 sar，它是 sysstat 包自带的，sar -u -f /var/log/sa/sa$(date +%d) 能看某天的 CPU 历史趋势，排查“昨天什么时候开始异常的”特别好用。

磁盘排查也有固定套路。df -h 先看分区剩余，df -i 看 inode 是否耗尽，然后 du -sh /* 2>/dev/null | sort -rh | head 一层层定位大目录。这里有个很难发现的坑：进程占用了一个已删除的大文件，df 显示磁盘满，但 du 加起来就是找不到空间去哪了。这时候用 lsof | grep deleted 看哪些进程还占着已删除的文件，找到后重启对应进程或清空文件即可释放空间。

除了系统命令，我强烈建议每个运维都配一套终端效率工具：tmux 保持会话不中断，jq 解析 JSON 日志，ripgrep（rg）替代 grep 实现毫秒级搜索，fzf 做命令行模糊搜索，zoxide 快速跳目录。装好之后，日常操作效率至少提升一倍。比如查看某个服务的 JSON 日志并提取关键字段：

bash复制tail -f app.log | jq 'select(.level=="ERROR") | {time, message}'

懂一点 Shell 和管道组合也是基本功。统计访问日志里 Top 10 IP：

bash复制awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -10

这条命令几乎是面试常客，日常排障也经常用。awk 提取字段，sort 排序，uniq 去重计数，sort -rn 倒序排，head 取前十条。多看几遍，手就会了。

4. Kubernetes、containerd与云原生生态：核心官网与调用原理

容器和 Kubernetes 是现在运维绕不开的板块，先把必须收藏的官网列出来：kubernetes.io 是核心文档，k8s 版本特性、API 变更、kubectl 命令参考都在这；containerd.io 是运行时文档；helm.sh 是包管理工具，相当于 K8s 的“应用商店”；goharbor.io 是镜像仓库；istio.io 是服务网格。这些页面打开之后，第一件事是看“Quick Start”和“FAQ”，第二件是把 Release Notes 加入定期关注列表。

关于 K8s 和 containerd 的关系，很多新手一直没搞明白。早期 Kubernetes 直接调用 Docker，后来为了不绑定单一运行时，社区定义了 CRI（Container Runtime Interface）标准接口。containerd 实现了这个 CRI 接口，成为 K8s 最主流的运行时。Kubernetes 1.24 之后移除了 dockershim，现在大部分集群都是 containerd 作为底层运行时。整个调用链是这样的：

text复制kubelet（节点上的 K8s 组件）
    │ 通过 gRPC 调用 CRI 接口
    ▼
containerd（内置 CRI 插件）
    │ 针对每个容器启动一个 shim 进程
    ▼
containerd-shim
    │ 调用 runc
    ▼
runc 创建并运行容器，直接与内核交互（namespace、cgroup、rootfs）
    ▼
容器进程

为什么中间要插一个 shim？这层设计很巧妙。runc 创建容器后，理论上容器进程的父进程就是 runc，如果 runc 退出，容器就成了孤儿进程，状态没法上报。shim 作为中间守护者，把容器的生命周期和 containerd 主进程解耦，即使 containerd 重启，shim 依然守着容器，能继续上报状态、回收资源。这就是它存在的意义。

排查日常问题，掌握三个层面的命令就够。kubectl 主要看集群状态，kubectl get pods -o wide、kubectl describe pod <name>、kubectl logs -f <pod> -c <container>。再往下一层，用 crictl 查看容器运行时状态，crictl 是专门面向 CRI 的命令行工具：

bash复制crictl ps -a                    # 查看所有容器（包含已退出）
crictl logs <container-id>       # 查看容器日志
crictl inspect <container-id>    # 查看容器详细配置

注意 crictl 和 ctr 的区别：ctr 是 containerd 原生的 CLI，不经过 CRI 层，查到的视角和 K8s 不太一致；crictl 才是站在 CRI 层面，能看到 Pod 和容器的关系。日常排障优先用 crictl。节点 NotReady 时，先 systemctl status containerd 看进程状态，再 journalctl -u containerd -n 100 --no-pager 看最近日志，多数问题是镜像盘满了或者 CRI 插件异常。

5. 监控告警与日志链路：Prometheus、ELK/Loki的选型与入口

监控是运维的“眼睛”，没有监控寸步难行。目前最主流的方案还是 Prometheus 全家桶：node_exporter 做节点指标采集，Prometheus 做指标存储和查询，Alertmanager 做告警通知，Grafana 做可视化面板。官网入口分别是 prometheus.io、grafana.com、github.com/prometheus/node_exporter。这四个组件的关系，我习惯理解成“采、存、警、显”四个字，各司其职。

PromQL 是查询语言，刚开始觉得难，掌握几条常用查法就够用。查节点磁盘剩余空间：

promql复制node_filesystem_avail_bytes{mountpoint="/"}

查 CPU 使用率：

promql复制100 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100

告警规则配置在 Prometheus 里，比如磁盘空间小于 20% 触发告警：

yaml复制groups:
  - name: node
    rules:
      - alert: DiskWillFillIn24h
        expr: predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[1h], 24*3600) < 0
        labels:
          severity: warning

日志这块，选择更容易被规模决定。数据量大、要做复杂搜索和聚合，ELK 是经典组合：Elasticsearch 存储、Logstash 采集加工、Kibana 展示；容器环境下常见用 Fluentd 或 Fluent Bit 替代 Logstash 收集，形成 EFK。如果团队规模不大、K8s 集群为主，Loki（grafana.com/oss/loki/）+ Promtail + Grafana 是更轻量的选择，它不建索引、按标签归档，查询时再扫描，成本和复杂度都低不少。

提示：告警规则过多会让人麻木。我当时踩过的坑是规则一股脑全加上，结果半夜被不痛不痒的告警轰炸，重要问题反而被忽略。建议告警分级别：warning 走群通知，critical 走电话/短信，能自愈的问题先考虑自动化处理，不要无脑告警。

排障时日志命令也要熟。systemd 系统服务看 journalctl -u <service> -f，容器看 kubectl logs -f --tail=200。关键词过滤配合 awk 和 grep 几乎是每天都要用的组合。有一个实际案例：线上某服务磁盘占用异常增长，通过 Grafana 看板发现 /data 分区近两天持续上涨，定位到容器日志目录，发现某个应用把 debug 日志全量输出到 stdout，一天写了 50GB。这就是监控和日志配合的价值：监控发现趋势，日志定位根因。

6. 自动化运维与发布链路：Ansible、Jenkins与代码仓库

自动化运维的目的不是“显得高级”，而是减少人为误差。重复的批量操作一到深夜就容易出错，漏了一台机器、写错一个参数，都可能变成事故。自动化工具里，我最推荐 Ansible 起步，因为不需要在目标机器装 agent，基于 SSH 就能干活，一条命令批量执行：

bash复制ansible all -m ping
ansible web -m shell -a 'uptime'

Ansible 的三个核心概念：inventory（主机清单）、module（执行模块）、playbook（任务剧本）。模块可以理解成现成的“功能库”，比如 copy 模块传文件、yum 模块装软件、service 模块管服务；playbook 则是把这些模块按顺序编排成剧本。举一个最简单的 Playbook，检查 nginx 进程是否存在：

yaml复制- hosts: web_servers
  gather_facts: no
  tasks:
    - name: 检查 nginx 进程
      shell: pgrep nginx
      register: result
      ignore_errors: yes

    - name: 输出结果
      debug:
        msg: "nginx {{ '运行中' if result.rc == 0 else '未运行' }}"

这套写法基本就是 Ansible 的骨架，剩下的都是在这个基础上加变量、加模板、加角色。和 SaltStack、Puppet、Chef 相比，Ansible 的优势是无 agent、上手快、不需要独立的服务端架构，适合中小规模团队。几百上千台机器也是它能扛住的水平，再大规模再考虑 SaltStack 或自研调度。

代码仓库一定要用起来。个人脚本、Ansible Playbook、Dockerfile、K8s YAML 全部进 Git 管理，别让配置散落在各自电脑里。GitHub 社区资源多，GitLab 适合私有化部署，国内访问可选 Gitee。Git 的基本操作不复杂，git add、git commit、git push、git pull 四个命令走天下，配合分支做变更管理就够了。

发布链路方面，Jenkins 是老牌 CI/CD 工具，生态最全，任何语言都能接。云原生环境下 ArgoCD 这类 GitOps 工具正在成为主流，应用版本和配置都定义在 Git 仓库里，让集群自动向仓库状态收敛。选型逻辑很简单：传统部署用 Jenkins，K8s 化程度高就考虑 ArgoCD。至于运维开发，Shell 加 Python 解决 70% 的自动化需求，脚本、小工具、接口对接都够用。Python 写脚本注意用 venv 建虚拟环境，别把依赖装到系统 Python 里。

7. 数据库与中间件运维：MySQL、Redis与达梦的常用官网和命令入口

数据是业务的核心资产，数据库运维的核心永远是“备份、监控、排障”。MySQL 的官网是 mysql.com，但说实话，多数问题靠官方文档和 mysql 命令行就够。日常巡检三件事：SHOW PROCESSLIST; 看当前连接有没有长时间未关闭的查询，SHOW GLOBAL STATUS LIKE 'Threads_connected'; 看连接数水位，慢查询日志里看有没有全表扫描。SQL 卡顿先 EXPLAIN 一把，看有没有走索引：

sql复制EXPLAIN SELECT * FROM orders WHERE user_id = 123;

type 列是 ALL 就说明全表扫描了，基本就是索引没建到位。备份用 mysqldump，线上 7x24 的库要加 --single-transaction 做一致性快照，避免锁表：

bash复制mysqldump -u root -p --single-transaction --master-data=2 mydb > mydb_$(date +%F).sql

Redis 这边，官网是 redis.io。日常运维命令集中在几个：INFO memory 看内存水位，INFO persistence 看 RDB/AOF 备份状态，SLOWLOG GET 10 看慢命令，CONFIG GET maxmemory 看内存上限。Redis 故障最常见的就是内存满了触发淘汰策略，或者大 key 导致阻塞。排查大 key 可以线上用 redis-cli --bigkeys 扫一遍，注意高峰期扫大 key 有阻塞风险，尽量低峰执行。

提示：Redis 的缓存雪崩和穿透是面试高频，也是线上常见问题。雪崩的通用解法是缓存过期时间加随机值，避免大量 key 同时失效；穿透的解法是缓存空值或者前置布隆过滤器。排查时先 INFO 看命中率，命中率骤降基本就是穿透或雪崩的典型信号。

达梦数据库（DM8）是国产数据库里市场占有率比较高的一款，适配信创环境，官网在 eco.dameng.com，开发者文档都在生态社区里。Linux 下部署达梦，和 MySQL/Oracle 的思路类似：先建安装用户，规划数据目录，执行安装脚本，再初始化实例。常用运维命令包括：用 disql 连接数据库执行 SQL，用 dmrman 做物理备份恢复，查实例状态 ps -ef | grep dmserver。达梦的某些参数习惯偏向 Oracle，做过 Oracle 的人上手很快。这里就不展开具体命令了，实际使用时一定以官方文档对应版本的《管理员手册》为准，不同小版本可能有些差异。

中间件层面，Nginx 是绕不开的。官网 nginx.org，配置改了先 nginx -t 检查语法再 nginx -s reload 平滑加载。access log 分析是看业务量最直接的手段，统计某一小时请求量 Top 10 来源：

bash复制awk '$4 ~ /23\/Jun\/2025:14:/ {print $1}' access.log | sort | uniq -c | sort -rn | head -10

systemd 作为现代 Linux 的服务管理器，也已经把 Tomcat、Redis、Nginx 这些服务的启停统一了：systemctl start|stop|restart|status <service>，日志统一用 journalctl -u <service> -f 实时看。运维人员记住这一套就够用了。

8. 桌面运维、统信UOS与LiveCD救援：容易被忽视的另一片战场

桌面运维看上去 “技术含量不高”，但它直接面对一线用户，处理问题的思路和服务器运维不太一样。工单里最常见的就是：电脑卡顿、连不上网、打印机装不上、软件装到一半报错、账号密码忘了。这类问题第一步永远是“问清楚现象”，再远程看一眼，而不是直接动手重装。卡顿先看任务管理器里什么进程占用 CPU 或内存，网络连不上先 ping 网关判断是物理链路、IP 配置还是 DNS 的问题，打印机问题先看驱动版本和打印服务状态——思路和服务器排障是一模一样的，只是界面图形化了而已。

信创环境下，统信 UOS（统信软件官网）是桌面端常见的选择。Dell、联想这些整机的出货量不小，日常会碰到不少 UOS 系统故障。UOS 官方提供了 LiveCD 救援工具，类似 Windows PE 的概念：系统起不来、引导坏了、密码忘了，都能通过 LiveCD 进去修。

LiveCD 修复系统的标准流程大致如下：

1. 准备 UOS LiveCD 启动盘（官方 ISO 写入 U 盘）。
2. 开机从 U 盘启动，选择进入 LiveCD 模式。
3. 打开终端，先 lsblk 看磁盘分区，确认系统根分区是哪个（一般是 ext4 或 xfs，看挂载点 /）。
4. 把系统根分区挂载到 /mnt：mount /dev/sda2 /mnt，具体设备以实际为准。
5. 挂载虚拟文件系统：

bash复制mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys

6. chroot 进入真实系统环境：chroot /mnt。
7. 此时可以执行修复操作，比如重置密码：passwd root，或者修复引导 grub2-mkconfig -o /boot/grub2/grub.cfg。
8. 退出并重启：exit、umount -R /mnt、reboot。

这个流程我在实际救援中用过很多次，核心就是“挂载真实系统 + chroot 进去操作”，比直接重装省事得多，还能保住用户数据。

桌面运维还有一个容易被忽略的点：建立问题记录表单。用户报修的次数、故障分类、解决耗时，统计一段时间就能发现规律——比如某型号电脑网卡驱动频繁失效，某部门打印机总是缺驱动。这类问题就不是孤立的“修一次”了，而是要在采购或部署层面规避。流程上可以借鉴 ITIL 的思路，事件管理管“恢复服务”，问题管理管“查找根因”，变更管理管“改动留痕”。桌面运维虽然面对的是单机，但管理思路和服务器运维没有本质区别。远程协助工具推荐准备一个 RustDesk 或同类软件，能大幅减少跑现场的次数；离线安装包提前准备好，外网受限时直接本地分发。

9. 运维面试与成长路线：把这些工具串成技术栈

闲聊了这么多工具，最后聊聊成长和面试。运维岗面试，考来考去其实就那几个维度：Linux 命令掌握程度、网络基础、Shell/Python 脚本能力、数据库常识、容器和 K8s 的实操、故障排查的完整思路。我面试别人时最看重的是“排查思路”，因为具体命令可以查手册，但遇到问题有没有清晰的定位逻辑，才是拉开差距的地方。

技术栈可以按这个层级搭，每一层学扎实再往上走：

高频面试题基本都有固定套路。比如“线上 CPU 飙高怎么排查”，回答顺序：top 找 CPU 占用最高的进程 PID，top -H -p PID 看该进程下哪个线程占资源，线程 ID 转十六进制 printf "%x\n" <tid>，再用 jstack 或 gdb 定位到具体代码。再看“磁盘满怎么处理”，df -h 确认、du -sh /* 逐层定位、lsof | grep deleted 找被占用的已删除文件。再看“K8s Pod 一直 Pending”，kubectl describe pod 看 Events，大概率是资源不足、镜像拉取失败或污点/容忍不匹配。

如果你正在准备面试，我给的建议就三句话：第一，每个工具都自己搭一遍，别只看文档，很多细节只有亲手翻车才会记住；第二，把每一次排障过程写成文档，格式可以是“现象—排查链路—根因—修复—预防”，这比背面试题库有用得多；第三，不要追求工具数量，追求“用熟几个核心工具的组合拳”，能完整处理一条链路的问题，比“听过大全套”更有竞争力。

写到这里，我想起自己刚做运维的时候，电脑里堆了十几个“技术收藏”文件夹，真正用起来却找不到。后来我给自己定了个规矩：收藏一个官网或工具，就必须写一句话说明“这个网站是什么、什么时候用、怎么进”，否则不算收集完成。这个方法让我这些年积累的几百个书签真正变成了生产力。如果这篇手册对你有用，你也可以试着建一份自己的运维工具手册，从你现在最常用的工具开始，一个月后再回头看，你会发现自己排查问题的思路和速度都会完全不同。