Linux

概述 软件包管理是 Linux 系统运维的基础。Debian 系使用 apt/dpkg，Red Hat 系使用 yum/dnf/rpm。理解两套包管理体系的原理和用法，掌握仓库管理、依赖解析、包构建、版本锁定和离线安装，是高效运维的前提。本文系统对比两大体系，并深入实践包构建和镜像源优化。 apt/dpkg 体系 体系架构 apt (高级前端) │ ├── apt-get → 包安装/卸载/更新 ├── apt-cache → 包查询/搜索 └── apt → 综合命令（交互友好） │ dpkg (底层工具) │ ├── dpkg → .deb 包安装/卸载 ├── dpkg-deb → .deb 包操作 └── dpkg-query → 包查询 │ aptitude (替代前端，可选) apt vs apt-get # apt 是 apt-get 和 apt-cache 的综合，输出更友好 # 常用对照: # 安装 $ apt install nginx # 新（推荐交互使用） $ apt-get install nginx # 旧（推荐脚本使用） # 搜索 $ apt search nginx $ apt-cache search nginx # 查看包信息 $ apt show nginx $ apt-cache show nginx # 更新索引 $ apt update $ apt-get update # 升级 $ apt upgrade # 升级已安装的包（不删除） $ apt full-upgrade # 升级（可删除包以解决依赖） $ apt-get dist-upgrade # 等同 full-upgrade 在脚本中建议使用 apt-get/apt-cache，因为其输出格式稳定；交互操作使用 apt 更友好。...

前言 磁盘 I/O 往往是系统性能链条中最慢的一环。一次机械磁盘寻道约 10ms，而内存访问仅约 100ns——两者相差 10 万倍。当业务出现延迟抖动、响应变慢，排查方向总会指向 I/O 子系统。从指标体系出发，结合工具实战与生产案例，建立一套可复用的 I/O 诊断方法论。 I/O 性能指标体系 在动手之前，必须搞清楚四个核心指标的含义及其相互关系。 指标 单位 含义 典型参考值 IOPS 次/秒 每秒完成的 I/O 读写次数 HDD ~100，SATA SSD ~10 万，NVMe SSD ~50 万+ 吞吐量 MB/s 每秒传输的数据量 HDD ~150 MB/s，SATA SSD ~550 MB/s，NVMe SSD ~3000 MB/s+ 延迟 ms/μs 单次 I/O 从提交到完成的耗时 HDD 5-15ms，SSD 0.1-1ms，NVMe 0.02-0.1ms 队列深度 个 等待处理的 I/O 请求数 建议值 NVMe 32-256，SSD 8-32 这四个指标之间存在关键约束关系： 小块随机读写场景下，瓶颈是 IOPS（如数据库 OLTP 4KB 随机写） 大块顺序读写场景下，瓶颈是吞吐量（如日志追加、视频流媒体） 延迟是最终用户感知的指标，即使 IOPS 和吞吐量充足，单次延迟过高仍会导致卡顿 队列深度提升能增加并发，但也意味着单请求等待时间变长 一个重要认知：IOPS × 块大小 ≈ 吞吐量。例如 4KB 块、100 IOPS，吞吐量约 0....

概述 定时任务是运维自动化的基础组件——日志轮转、数据备份、证书续期、健康检查、报表生成，几乎每个运维场景都离不开定时执行。大多数人对定时任务的认知停留在 crontab -e 加一行 0 2 * * * /path/to/script.sh，但这在生产环境中远远不够：任务失败了谁通知？执行超时了谁处理？多台机器上的任务怎么协调？从 cron 到 systemd timer 到分布式调度，逐步梳理定时任务的管理实践。 参考来源：cron Wikipedia、systemd.timer 官方文档 一、cron 语法与局限 1.1 cron 表达式 cron 表达式由 5 个字段组成： ┌──────── 分钟 (0-59) │ ┌────── 小时 (0-23) │ │ ┌──── 日 (1-31) │ │ │ ┌── 月 (1-12) │ │ │ │ ┌ 星期 (0-7, 0和7都是周日) │ │ │ │ │ * * * * * command 表达式 含义 0 2 * * * 每天凌晨 2:00 */15 * * * * 每 15 分钟 0 */6 * * * 每 6 小时 0 0 * * 0 每周日 0:00 0 0 1 * * 每月 1 号 0:00 30 3-5 * * * 3:30, 4:30, 5:30 0 0 1 1,4,7,10 * 每季度首月 1 号 @reboot 系统启动时 @daily / @midnight 每天 0:00 @weekly 每周日 0:00 @monthly 每月 1 号 0:00 @yearly / @annually 每年 1 月 1 日 0:00 1....

概述 日志是系统运维的眼睛。从内核消息到应用日志、从安全审计到性能分析，日志贯穿了故障排查的每个环节。现代 Linux 采用 journald 作为系统日志守护进程，配合 logrotate 进行日志轮转，构成了完整的日志管理基础设施。本文深入 journald 的原理与配置、journalctl 的高级查询技巧、日志轮转策略、远程日志收集方案以及实战分析案例。 journald 原理 架构概览 journald 是 systemd 的系统日志组件，取代了传统的 syslog（rsyslog）。它接收来自内核、系统服务和应用程序的日志，统一存储为结构化的二进制格式。 [内核日志] [systemd 服务] [应用程序] │ │ │ ▼ ▼ ▼ [kmsg] [sd_journal_print] [syslog()/stdout] │ │ │ └──────────┬───────┴──────────┬───────┘ ▼ ▼ [journald] [/dev/log] │ ┌──────────┼──────────┐ ▼ ▼ ▼ [持久日志] [运行时日志] [转发到 syslog] /var/log/ /run/log/ /var/log/ journal/ journal/ messages 日志存储模式 # 查看当前存储模式 $ cat /etc/systemd/journald.conf | grep Storage #Storage=auto # 三种模式： # auto（默认）: /var/log/journal 存在则持久化，否则仅内存 # persistent: 强制持久化（自动创建 /var/log/journal） # volatile: 仅内存（/run/log/journal） 模式 存储位置 重启后保留 适用场景 persistent /var/log/journal 是 生产环境 auto /var/log/journal 或 /run/log/journal 取决于目录 默认 volatile /run/log/journal 否 临时系统/安全要求 日志大小控制 # /etc/systemd/journald....

systemd 架构概述 systemd 是现代 Linux 发行版的事实标准 init 系统，从 2015 年起已取代 SysVinit 成为绝大多数主流发行版的默认 init。它不只是"启动服务的工具"，而是一个完整的系统和服务管理器。 核心 unit 类型 systemd 通过 unit（单元）来管理系统资源，每种 unit 类型对应一种资源： unit 类型 扩展名 作用 service .service 系统服务（守护进程） socket .socket IPC 套接字（支持套接字激活） timer .timer 定时任务（替代 cron） target .target 服务组（类似传统 runlevel） mount .mount 文件系统挂载点 device .device 内核设备 path .path 文件路径监控（文件出现时触发服务） slice .slice cgroup 资源分配层级 target 与传统 runlevel 的映射 # 查看当前默认 target systemctl get-default # 通常输出: multi-user.target（对应 runlevel 3，多用户命令行模式） # 切换到图形界面（对应 runlevel 5） sudo systemctl isolate graphical....

概述 性能诊断是 SRE 的核心技能。Linux 提供了丰富的性能分析工具，从简单的 top 到强大的 perf/eBPF，每个工具都有其适用场景。掌握这些工具的使用时机和方法，是快速定位性能瓶颈的关键。本文按 CPU、内存、IO、网络和综合工具五大维度，逐步梳理 Linux 性能诊断工具集，并提供使用场景速查表和实战案例。 负载监控工具 top：经典进程监控 $ top # 顶部摘要信息 top - 15:30:00 up 30 days, 3:21, 3 users, load average: 1.23, 0.98, 0.85 Tasks: 234 total, 1 running, 233 sleeping, 0 stopped, 0 zombie %Cpu(s): 12.3 us, 3.4 sy, 0.0 ni, 83.3 id, 0.5 wa, 0.0 hi, 0.5 si, 0.0 st MiB Mem : 32000.0 total, 5000.0 free, 15000.0 used, 12000.0 buff/cache MiB Swap: 4096....

前言 Shell 脚本是运维工程师最常用的自动化工具。本文记录几个实战中常用的脚本模式。 日志定期清理 服务器日志堆积是常见问题，以下脚本按保留天数自动清理： #!/bin/bash # clean_logs.sh - 日志清理脚本 LOG_DIR="/var/log/app" KEEP_DAYS=30 find "$LOG_DIR" -name "*.log" -type f -mtime +${KEEP_DAYS} -exec gzip {} \; find "$LOG_DIR" -name "*.gz" -type f -mtime +${KEEP_DAYS} -delete echo "$(date): 日志清理完成，保留 ${KEEP_DAYS} 天" 配合 crontab 每天执行： 0 2 * * * /opt/scripts/clean_logs.sh >> /var/log/clean_logs.log 2>&1 批量主机健康检查 通过 SSH 批量检查多台服务器状态： #!/bin/bash # health_check.sh - 批量健康检查 HOSTS=("web-01" "web-02" "db-01" "cache-01") THRESHOLD=80 for host in "${HOSTS[@]}"; do echo "--- ${host} ---" ssh "$host" " echo \"CPU: \$(top -bn1 | grep 'Cpu' | awk '{print \$2}')%\" echo \"MEM: \$(free | awk '/Mem/{printf \"%....

概述 文件系统是操作系统与存储设备之间的桥梁，直接影响数据可靠性、I/O 性能和运维复杂度。Linux 支持多种文件系统，每种都有其设计取舍。本文对比 ext4、xfs、btrfs、zfs 四大主流文件系统，深入挂载参数优化、IO 调度器选择、journal 模式、fsync 性能等核心主题，并提供生产环境的选型建议和调优方案。 文件系统对比 核心特性一览 特性 ext4 xfs btrfs zfs 最大文件 16TB 8EB 16EB 16EB 最大卷 1EB 8EB 16EB 256ZB 日志 是 是 是（CoW） 是（CoW/ZIL） 快照 否 否 是 是 压缩 否 否 是 是 去重 否 否 是（实验） 是 校验和 否 否 是 是 子卷 否 否 是 是 RAID 否 否 是 是（原生） 在线扩容 是 是 是 是 在线缩容 否 否 是 否 CoW 部分 否 是 是 开发方 Linux 社区 SGI → Red Hat Oracle OpenZFS ext4：稳定可靠的传统选择 ext4 是 ext3 的改进版，自 2008 年进入主线内核，是 Ubuntu、Debian 等发行版的默认文件系统。...

概述 Linux 内核通过 /proc/sys/ 和 sysctl 接口暴露了数千个可调参数，涵盖网络、内存、文件系统、安全等各个方面。合理调整这些参数可以显著提升系统性能和稳定性，但盲目调参也可能适得其反。本文逐步梳理 sysctl 体系，按网络、文件描述符、内存、安全四大维度展开，并提供生产环境调优模板和参数验证方法。 sysctl 体系 参数查看与修改 # 查看所有参数 $ sysctl -a # 查看特定参数 $ sysctl net.ipv4.tcp_max_syn_backlog $ sysctl vm.swappiness # 临时修改（重启失效） $ sysctl -w vm.swappiness=10 # 从文件加载 $ sysctl -p /etc/sysctl.d/99-custom.conf # 永久生效：写入配置文件 # /etc/sysctl.conf — 传统配置文件 # /etc/sysctl.d/*.conf — 推荐方式（按字母序加载） 配置文件加载顺序 /etc/sysctl.d/ 下按文件名字母序加载： 00-default.conf → 默认值 50-network.conf → 网络参数 99-custom.conf → 自定义参数（最后加载，覆盖前面） 最后加载 /etc/sysctl.conf（如果存在） 参数命名空间 kernel.* — 内核通用参数 vm.* — 虚拟内存参数 fs.* — 文件系统参数 net....

前言 一台默认安装的 Linux 服务器，暴露的攻击面远超想象：多余的 RPM 包、开放的网络服务、宽松的 SSH 配置、未启用的审计系统。安全加固不是一次性操作，而是一套从安装到运行的全生命周期清单。本文按 CIS Benchmark 框架梳理加固要点，每一步都给出可直接执行的配置。 系统最小化安装原则 包管理裁剪 最小化安装的核心思路：只装需要的，不装可能需要的。 # 安装时选择 Minimal Install（RHEL 系）或 minimal image（Debian 系） # 安装后审计已安装的包组，移除不需要的 yum grouplist # RHEL/CentOS dnf group list # Fedora/RHEL 8+ # 移除不需要的包组 dnf group remove "GNOME Desktop" "Graphical Administration Tools" # 审计已安装的包，按大小排序 rpm -qa --queryformat '%{SIZE} %{NAME}\n' | sort -rn | head -30 # 移除已知不需要的包 dnf remove -y ypbind rsh-server ypserv telnet-server talk-server Debian/Ubuntu 系： # 查看手动安装的包（可安全移除的候选） apt-mark showmanual # 移除不需要的服务包 apt purge -y rsh-client rsh-redone-server telnetd tftpd xinetd 服务裁剪 安装后审计运行中的服务，关闭一切非必要服务：...