偏日常运维与交付排障的工程速查图，回答从 Linux 基础到容器、发布与线上诊断的常见主线 (2025-2026)
| 上层 | 依赖的下层 | 关系说明 |
|---|---|---|
| 系统排障 | Linux 基础 | 不会看进程、文件描述符、权限和日志，排障会完全失去抓手 |
| 网络排障 | 系统与网络 | 端口、路由、DNS、TLS、连接状态决定了 70% 的线上“服务不可用”问题 |
| Docker / 容器 | Linux 内核机制 | 容器背后还是 Namespace、Cgroups、OverlayFS，不理解底层很难排查资源和网络问题 |
| CI/CD | 自动化能力 | 流水线的本质是标准化脚本和环境，而不是点点点界面 |
| 可观测性 | 交付体系 | 没有部署上下文和版本信息，再完善的监控也难和故障闭环 |
| SRE / 稳定性治理 | 全栈能力 | 稳定性不是某个工具，而是系统、网络、发布、监控、应急联合产物 |
| 主题 | 常用命令 | 作用 | 高频坑 |
|---|---|---|---|
| 文件定位 | 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 适合看系统级错误。
先看服务状态，再看服务日志，再看系统日志，最后再去看配置和依赖。
dig / nslookup 确认域名解析是否正确ping 看 ICMP，traceroute 看路径，curl / telnet / nc 看端口ss -tulpn 看是否真的在监听目标端口0.0.0.0 还是 127.0.0.1iptables / 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 → 构建制品 → 镜像构建 → 漏洞扫描 → 推送仓库 → 部署到测试环境 → 冒烟测试 → 人工或自动发布生产 → 回滚机制。
一次构建，多环境复用；发布前验证制品，不要每个环境重新构建。
| 层级 | 必须监控 | 原因 |
|---|---|---|
| 主机 | CPU、内存、磁盘、Load、网络流量 | 快速判断是不是资源级故障 |
| 服务 | QPS、错误率、P95/P99 延迟、并发数 | 反映用户真实体验 |
| 依赖 | 数据库连接、缓存命中率、下游错误率 | 很多服务故障其实来自依赖雪崩 |
| 发布 | 版本号、发布时间、变更人、变更单 | 定位“是不是刚发版引入的”会快很多 |
| 阶段 | 至少做什么 | 常见翻车点 |
|---|---|---|
| 发布前 | 确认变更范围、回滚方式、监控面板、值守人和依赖窗口 | 代码准备好了，但没人明确谁盯发布、谁拍回滚、依赖方是否也在变更 |
| 发布中 | 看错误率、P95/P99、实例健康、关键日志和依赖连接数 | 只盯 CI 成功，不盯真实服务信号，问题已经发生却没人意识到 |
| 发布后 5-15 分钟 | 对照基线看核心接口、队列积压、数据库慢查询、缓存命中和告警 | 发布完成立刻离场，结果小流量阶段没暴露的问题在几分钟后才放大 |
| 异常止血 | 优先回滚、摘流、限流、扩容，不要先在生产上临时改一堆配置 | 为了“现场修好”不断加临时操作，最后让问题更难复盘和恢复 |
| 发布结束 | 记录版本号、时间、影响面、异常点和后续复盘入口 | 这次看似没出大事，但没有留痕，下次同类事故还会原样再来一遍 |
平台工程继续减少手工运维占比: 组织会更强调标准模板、自助服务和 golden path，而不是口口相传的运维经验。
DevSecOps 逐步前置: 安全扫描、制品签名、策略校验会更多嵌进流水线，而不是上线后补检查。
观测与成本融合: 监控不再只看“红不红”，还要看“值不值”。FinOps 会和 SRE 越走越近。
AI 辅助排障: 运行日志、告警聚类、变更关联会越来越多地被 AI 参与分析，但前提仍是数据质量过关。
eBPF 普及: 在网络观测、安全审计和性能分析上会继续扩大应用面。
轻量化平台: 不是所有团队都需要全套大平台，越来越多组织会追求“足够好而不臃肿”的交付体系。
工具崇拜: 买再多平台、装再多组件，也替代不了混乱流程和不清晰职责。
知识断层: 太早跳到平台抽象层，反而会让团队失去对 Linux 和网络底层的判断力。
告警风暴: 没有分级和去重的监控体系，最后只会把值班人训练成忽略告警。