Linux / DevOps 速查图谱
Linux 基础、系统排障、网络、Docker、CI/CD、可观测性与交付流程速查 (2025-2026)
Layer 1
Linux 基础
文件/进程/权限
→
Layer 2
系统与网络
systemd/TCP/IP
→
Layer 3
自动化与容器
Shell/Docker/IaC
→
Layer 4
交付体系
CI/CD/发布/回滚
→
Layer 5
平台与稳定性
观测/SRE/治理
| 上层 | 依赖的下层 | 关系说明 |
|---|
| 系统排障 | Linux 基础 | 不会看进程、文件描述符、权限和日志，排障会完全失去抓手 |
| 网络排障 | 系统与网络 | 端口、路由、DNS、TLS、连接状态决定了 70% 的线上“服务不可用”问题 |
| Docker / 容器 | Linux 内核机制 | 容器背后还是 Namespace、Cgroups、OverlayFS，不理解底层很难排查资源和网络问题 |
| CI/CD | 自动化能力 | 流水线的本质是标准化脚本和环境，而不是点点点界面 |
| 可观测性 | 交付体系 | 没有部署上下文和版本信息，再完善的监控也难和故障闭环 |
| SRE / 稳定性治理 | 全栈能力 | 稳定性不是某个工具，而是系统、网络、发布、监控、应急联合产物 |
1991 - Linux
Linus 发布 Linux 内核，逐渐成为服务器世界的默认操作系统。
2000s - 自动化运维
Shell、Perl、Python、配置管理工具开始替代大量手工运维。
2009 - DevOps 概念提出
开发与运维协作从文化层面被系统化，交付速度与稳定性被放到同一个目标里。
2011 - systemd 普及
Linux 服务管理、日志与启动流程逐渐标准化。
2013 - Docker
应用打包与交付标准化，开发环境与生产环境差异被显著缩小。
2014 - Kubernetes
容器编排成为新基础设施，DevOps 开始与平台工程、云原生深度融合。
2016 - GitOps / IaC 成熟
基础设施和发布流程全面代码化，运维动作逐步纳入版本管理与审计。
2018 - SRE / 可观测性普及
企业开始从“监控机器”转向“度量服务可靠性与用户体验”。
2021 - Supply Chain Security
CI/CD、制品仓库、依赖链本身成为重要攻击面，DevSecOps 越来越像交付流程的常规前提。
2024-2025 - 平台工程化
DevOps 从“人人会写脚本”走向“平台团队沉淀标准交付能力”。
| 主题 | 常用命令 | 作用 | 高频坑 |
|---|
| 文件定位 | pwd / ls -lah / find / du -sh | 看目录、文件大小、占用热点 | 误删前没确认路径；磁盘满往往是日志或临时文件 |
| 权限 | chmod / chown / umask | 设置用户、组、读写执行权限 | 把 777 当万能解法；忽略目录执行权限 |
| 进程 | ps aux / top / htop / kill / pkill | 查看资源占用、结束异常进程 | kill -9 用太快，跳过优雅退出与清理流程 |
| 文件描述符 | lsof / ulimit -n | 排查端口占用、fd 泄漏、已删文件仍占空间 | 磁盘删了文件但空间没释放，常见原因就是进程还握着句柄 |
服务管理
systemctl status nginx 看状态，systemctl restart nginx 重启，systemctl enable nginx 开机自启。
日志查询
journalctl -u nginx -n 100 --no-pager 看最近 100 行，journalctl -xe 适合看系统级错误。
日志排障顺序
先看服务状态，再看服务日志，再看系统日志，最后再去看配置和依赖。
# CPU / 内存
top
vmstat 1
free -h
# 磁盘 / IO
df -h
du -sh /var/*
iostat -xz 1
# 网络
ss -tulpn
ip a
ip route
dig example.com
curl -I https://example.com
# 进程 / 端口 / 文件
ps aux | grep nginx
lsof -i :8080
lsof +L1
# 日志
tail -f /var/log/nginx/error.log
journalctl -u docker -f
第 1 层: DNS
dig / nslookup 确认域名解析是否正确- 先分清是解析失败、解析慢，还是解析到了错误地址
第 2 层: 连通性
ping 看 ICMP，traceroute 看路径，curl / telnet / nc 看端口- 别把 ping 不通等同于服务不可达，很多环境会禁 ICMP
第 3 层: 本机监听
ss -tulpn 看是否真的在监听目标端口- 确认绑定的是
0.0.0.0 还是 127.0.0.1
第 4 层: 防火墙 / 安全组
- 检查
iptables / nftables / 云厂商安全组
- 线上很多“服务挂了”其实只是规则漏开
| 问题 | 命令 | 看什么 |
|---|
| 证书是否过期 | openssl s_client -connect host:443 -servername host | 证书有效期、链是否完整、SNI 是否正确 |
| 接口是否真的返回 200 | curl -I https://host | 状态码、重定向、Server Header |
| TLS 协议协商失败 | curl -v https://host | 握手阶段卡在哪，是否是证书或协议版本问题 |
| 主题 | 速记 | 关键点 |
|---|
| 镜像 | 不可变模板 | 镜像尽量小、层次清晰、固定版本标签，不要直接用 latest |
| 容器 | 镜像运行实例 | 容器是进程，不是虚拟机；退出了就要查主进程和入口命令 |
| 卷 | 数据持久化 | 应用与数据分离，升级容器不等于升级数据 |
| 网络 | bridge / host / overlay | 本机调试常用 bridge，集群场景会落到 overlay 或 CNI 网络 |
推荐最小链路
代码提交 → 单测 / Lint → 构建制品 → 镜像构建 → 漏洞扫描 → 推送仓库 → 部署到测试环境 → 冒烟测试 → 人工或自动发布生产 → 回滚机制。
关键原则
一次构建，多环境复用；发布前验证制品，不要每个环境重新构建。
Terraform / OpenTofu
- 适合声明式管理云资源、网络、集群、数据库
- 状态管理是核心，需要远程 state + 锁
- 生态最强，但模块治理很重要
Ansible / Shell / 脚本化
- 适合配置分发、临时操作、主机层批量变更
- 速度快、落地轻，但容易积累不可追踪的历史状态
- 适合作为 IaC 的补充，不适合作为长期唯一方案
| 层级 | 必须监控 | 原因 |
|---|
| 主机 | CPU、内存、磁盘、Load、网络流量 | 快速判断是不是资源级故障 |
| 服务 | QPS、错误率、P95/P99 延迟、并发数 | 反映用户真实体验 |
| 依赖 | 数据库连接、缓存命中率、下游错误率 | 很多服务故障其实来自依赖雪崩 |
| 发布 | 版本号、发布时间、变更人、变更单 | 定位“是不是刚发版引入的”会快很多 |
确认影响范围
→
看监控面板
→
看最近变更
→
查服务日志
→
查主机/网络
→
决定回滚/止血
重点: 先止血，再深挖
高频误区: 一上来就 SSH 到机器里乱翻
止血手段: 回滚、扩容、摘流、限流
后续动作: 复盘、补监控、补自动化
Shell 基础
→
文件/权限/进程
→
systemd / 日志
→
TCP/IP / DNS
→
常见服务部署
→
故障排查
周期: 2-4 个月
目标: 能独立管理一台 Linux 服务器
关键: 多动手，不要只背命令
产出: 一套自己的排障笔记
Linux + Git
→
Shell / Python
→
Docker
→
CI/CD
→
IaC
→
质量与安全门禁
周期: 4-8 个月
目标: 打通一条自动发布链路
关键: 标准化而不是堆工具
产出: 一个可复用流水线模板
系统与网络深入
→
观测体系
→
发布治理
→
容量与成本
→
应急响应
→
复盘机制
周期: 1-2 年
目标: 让系统真正可恢复、可运营
关键: 用数据说话，不靠经验拍脑袋
产出: SLI/SLO + 应急手册 + 复盘闭环
误区: DevOps 是一个岗位
- DevOps 首先是一套协作和交付方法论，其次才是工具链和角色分工
- “招一个 DevOps 解决组织问题”通常是误判
误区: 会背命令就等于会 Linux
- 真正重要的是理解系统模型：进程、权限、文件系统、网络、服务生命周期
- 排障靠模型，不靠死记硬背
误区: CI/CD 就是自动部署
- 没有测试、扫描、审批、回滚、观测的自动部署只是“自动把风险发到生产”
- 流水线要对质量负责，不只是对速度负责
误区: 线上问题只能靠 SSH 进机器查
- 成熟团队优先靠监控、日志、链路和变更系统定位问题
- SSH 是最后一跳，不应是第一反应
确定性趋势:
平台工程继续减少手工运维占比: 组织会更强调标准模板、自助服务和 golden path，而不是口口相传的运维经验。
DevSecOps 逐步前置: 安全扫描、制品签名、策略校验会更多嵌进流水线，而不是上线后补检查。
观测与成本融合: 监控不再只看“红不红”，还要看“值不值”。FinOps 会和 SRE 越走越近。
值得关注:
AI 辅助排障: 运行日志、告警聚类、变更关联会越来越多地被 AI 参与分析，但前提仍是数据质量过关。
eBPF 普及: 在网络观测、安全审计和性能分析上会继续扩大应用面。
轻量化平台: 不是所有团队都需要全套大平台，越来越多组织会追求“足够好而不臃肿”的交付体系。
需要警惕:
工具崇拜: 买再多平台、装再多组件，也替代不了混乱流程和不清晰职责。
知识断层: 太早跳到平台抽象层，反而会让团队失去对 Linux 和网络底层的判断力。
告警风暴: 没有分级和去重的监控体系，最后只会把值班人训练成忽略告警。
总结:
Linux / DevOps 的核心不是“记住多少命令”，而是把系统、网络、自动化、交付和稳定性连成一条完整链路。
这份速查图谱最适合谁:
- 开发者: 快速补齐线上排障和部署认知，避免“代码能跑但不会上线”
- 运维 / DevOps: 作为知识结构总览，方便补全短板和统一话术
- 团队负责人: 用它对齐交付链路，判断当前瓶颈是在系统、流程还是组织协作
一句话判断有没有必要:
如果“云原生全景图”回答的是“平台怎么搭”，那这份“Linux / DevOps 速查图谱”回答的就是“今天线上出事了，我应该怎么想、怎么看、怎么处理”。