你离开 Linux 这些年，它发生了什么？—— 2016-2025 Linux 开发与部署的十年变革

如果你在 2013-2016 年间用过 Linux，熟悉 CentOS 6、yum install、service httpd start、手动编译 Nginx、写 init.d 脚本这些操作，然后离开了 Linux 世界一段时间——当你再回来时，会发现很多东西已经面目全非了。

这篇文章帮你补上这些年的”课”，聚焦在开发和部署层面的变化。

---

时间线速览

在详细展开之前，先看一张全景时间线：

2013 ── Docker 发布，容器革命开始
2014 ── systemd 成为主流 init 系统（CentOS 7）
2015 ── Let's Encrypt 发布，HTTPS 免费普及
2016 ── CentOS 7 成为主流 │ Snap 包格式发布
2017 ── Kubernetes 赢得容器编排之战
2018 ── GitHub 被微软收购 │ Flatpak 成熟
2019 ── CentOS 8 发布 │ WSL 2 发布 │ Podman 崛起
2020 ── CentOS 8 宣布停止维护（炸裂消息）│ eBPF 进入主流
2021 ── Rocky Linux / AlmaLinux 诞生 │ CentOS Stream 转型
2022 ── Ubuntu 22.04 LTS │ 内核 5.x → 6.x
2023 ── Fedora/RHEL 源码政策争议 │ 不可变发行版兴起
2024 ── systemd 功能持续扩展 │ AI 开发环境 Linux 化
2025 ── Linux 6.x 内核成熟 │ 容器原生开发成为标配

---

一、发行版格局大洗牌

1.1 CentOS 的”暴死”—— 最大的震动

这是你离开后发生的最大事件。如果你只看一段，看这段。

你记忆中的 CentOS：

RHEL（红帽企业版，收费）
  │
  └── CentOS（社区重新编译，免费）
       完全兼容 RHEL，生产环境的首选
       CentOS 6 支持到 2020
       CentOS 7 支持到 2024
       CentOS 8 支持到 2029（原计划）

2020 年 12 月，Red Hat 宣布：CentOS 8 提前终止，2021 年底停止更新。

这意味着 CentOS 不再是 RHEL 的”免费下游复制品”，而是变成了 CentOS Stream——一个 RHEL 的”上游测试版”。

以前：RHEL → CentOS（稳定的免费复制品）
现在：CentOS Stream → RHEL（CentOS 变成了试验田）

以前：RHEL 先发布，CentOS 跟着出稳定版
现在：CentOS Stream 先跑，然后 RHEL 从中挑选稳定内容

社区反应：愤怒 + 行动

几乎一夜之间，两个替代品诞生：

替代品	发起者	定位
Rocky Linux	CentOS 创始人 Gregory Kurtzer	CentOS 的精神续作，1:1 兼容 RHEL
AlmaLinux	CloudLinux 公司	同样 1:1 兼容 RHEL，企业背书

现状（2025 年）：

生产服务器 Linux 选择：

企业客户（有预算）  → RHEL（付费，有官方支持）
企业客户（省钱）    → Rocky Linux / AlmaLinux（免费，兼容 RHEL）
云服务器/个人       → Ubuntu Server（最流行）
容器/云原生         → Alpine Linux / Debian（轻量）
前沿技术尝鲜        → Fedora

1.2 Ubuntu 成为”默认 Linux”

在你离开的这些年，Ubuntu 在服务器领域的地位不断上升：

• 云平台默认镜像：AWS、Azure、GCP 的默认 Linux 镜像都是 Ubuntu
• Docker Hub 基础镜像：大量容器以 Ubuntu 为基础
• WSL 默认发行版：Windows 上跑 Linux，默认就是 Ubuntu
• AI/ML 生态：NVIDIA 驱动、CUDA、PyTorch 等首先支持 Ubuntu

2016 年生产服务器：
CentOS ████████████████████  约 50%
Ubuntu ████████████          约 30%
Debian ██████                约 15%
其他   ██                    约 5%

2025 年生产服务器：
Ubuntu ████████████████████  约 45%
RHEL系 ████████████          约 30%
Debian █████                 约 12%
Alpine ████                  约 8%（容器场景）
其他   ██                    约 5%

1.3 LTS 版本节奏

现在选 Linux 发行版，LTS（Long Term Support）版本是关键：

Ubuntu LTS（每 2 年一个，支持 5 年 + ESM 扩展 5 年）：
  16.04 → 18.04 → 20.04 → 22.04 → 24.04

RHEL（支持 10 年）：
  RHEL 7 (2014-2024) → RHEL 8 (2019-2029) → RHEL 9 (2022-2032)

Debian（支持约 5 年）：
  9 Stretch → 10 Buster → 11 Bullseye → 12 Bookworm

---

二、systemd —— 你记忆中的 init 脚本已经消亡

2.1 从 SysVinit 到 systemd

这是你会感受最直接的变化。CentOS 6 用的是 SysVinit（/etc/init.d/ 脚本），CentOS 7 开始全面切换到 systemd。

你记忆中的操作（CentOS 6）：
  service httpd start
  service httpd stop
  chkconfig httpd on
  /etc/init.d/nginx restart
  编写 init.d 启动脚本（几十行 shell）

现在的操作（systemd）：
  systemctl start httpd
  systemctl stop httpd
  systemctl enable httpd
  systemctl restart nginx
  编写 service 文件（十几行 INI 格式）

2.2 systemd 服务文件：简洁得多

以前写一个 init.d 脚本可能要 50-100 行 shell，现在：

# /etc/systemd/system/myapp.service
[Unit]
Description=My Application
After=network.target

[Service]
Type=simple
User=appuser
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/bin/server --port 8080
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

就这么多。相比以前的 init.d 脚本，不需要手动处理 PID 文件、start/stop/status 分支、后台化等逻辑——systemd 全包了。

2.3 systemd 不只是启动服务

systemd 已经变成了一个庞大的系统管理套件：

systemd 家族（2025 年）：

systemctl       ── 服务管理（你最常用的）
journalctl      ── 日志查看（取代了翻 /var/log 文件）
systemd-networkd ── 网络管理
systemd-resolved ── DNS 解析
systemd-timesyncd── 时间同步（取代 ntpd）
systemd-boot     ── 引导管理
loginctl        ── 登录会话管理
timedatectl     ── 时区时间管理
hostnamectl     ── 主机名管理

2.4 journalctl：日志查看革命

以前查日志：tail -f /var/log/messages，在各种日志文件里翻找。

现在：

# 查看某个服务的日志
journalctl -u nginx

# 实时跟踪日志
journalctl -u myapp -f

# 看今天的日志
journalctl --since today

# 看最近 5 分钟的错误日志
journalctl --since "5 min ago" -p err

# 看上次启动以来的内核日志
journalctl -b -k

日志存储在二进制格式的 journal 中，支持结构化查询、自动轮转、按服务/时间/级别过滤。

---

三、容器化革命 —— 部署方式的根本改变

3.1 从”装软件”到”跑容器”

你记忆中的部署方式：

1. 买/租一台服务器
2. 装 CentOS 6
3. yum install 各种依赖
4. 编译安装 Nginx / PHP / MySQL
5. 配置各种 conf 文件
6. 写 init.d 启动脚本
7. 祈祷下次迁移时能复现这个环境

现在的部署方式：

# Dockerfile - 把整个环境打包
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install --production
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

# 一条命令构建
docker build -t myapp .

# 一条命令运行
docker run -d -p 3000:3000 myapp

# 在任何一台装了 Docker 的机器上都能跑
# 不再有"在我机器上能跑"的问题

3.2 Docker：从新玩意到基础设施

Docker 发展线：

2013 ── Docker 诞生（基于 Linux 内核的 cgroups + namespace）
2014 ── Docker Hub 上线（容器镜像的"应用商店"）
2015 ── Docker Compose（多容器编排）
2016 ── Docker 成为生产环境标配
2017 ── Kubernetes 赢得编排战争
2019 ── Podman 出现（无守护进程的替代品）
2020 ── Docker Desktop 开始收费（企业用户）
2025 ── 容器已是部署的"水和电"，不再是新闻

3.3 Docker 背后的 Linux 技术

Docker 并不是魔法，它利用的全是 Linux 内核特性：

Docker 容器 = Linux 内核功能的组合：

┌─────────────────────────────────────┐
│  Namespace（命名空间）—— 隔离       │
│  ├── PID namespace  → 进程隔离     │
│  ├── NET namespace  → 网络隔离     │
│  ├── MNT namespace  → 文件系统隔离 │
│  ├── UTS namespace  → 主机名隔离   │
│  └── USER namespace → 用户隔离     │
│                                     │
│  cgroups（控制组）—— 资源限制       │
│  ├── CPU 限制                      │
│  ├── 内存限制                      │
│  └── IO 限制                       │
│                                     │
│  UnionFS（联合文件系统）—— 分层镜像 │
│  └── OverlayFS（现在的默认）       │
└─────────────────────────────────────┘

容器 ≠ 虚拟机！
容器共享宿主机内核，没有额外的操作系统开销
启动时间：秒级（vs 虚拟机的分钟级）

3.4 Docker Compose：多容器编排

一个典型的 Web 应用现在这样部署：

# docker-compose.yml
services:
  web:
    build: .
    ports:
      - "80:3000"
    depends_on:
      - db
      - redis
    environment:
      - DATABASE_URL=postgres://db:5432/myapp

  db:
    image: postgres:16
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=myapp
      - POSTGRES_PASSWORD=secret

  redis:
    image: redis:7-alpine

volumes:
  pgdata:

# 一条命令启动整个应用栈
docker compose up -d

# 以前你需要：分别安装 Node/Postgres/Redis，
# 配置各自的端口、用户、权限、启动脚本...

3.5 Kubernetes (K8s)：大规模容器编排

当你有几十、几百个容器需要管理时，就需要 Kubernetes：

Kubernetes 解决的问题：

以前（手动管理）：                现在（K8s 自动管理）：
├── 这个容器放哪台机器？          ├── K8s 自动调度到合适的机器
├── 挂了怎么办？                  ├── 自动重启、自动迁移
├── 流量大了怎么扩容？            ├── 自动水平扩展（多跑几个副本）
├── 怎么做滚动更新？              ├── 零停机滚动部署
├── 服务之间怎么发现？            ├── 内置服务发现和负载均衡
└── 配置和密钥怎么管理？          └── ConfigMap 和 Secret

不过 K8s 学习曲线陡峭，小团队通常不需要。Docker Compose 或云平台的容器服务（如 AWS ECS、阿里云 ACK）就够了。

3.6 Podman：Docker 的”继任者”？

RHEL 系现在默认推荐 Podman 而非 Docker：

Docker：
  需要一个后台守护进程（dockerd）以 root 运行
  所有容器操作都通过这个守护进程
  安全隐患：守护进程崩了，所有容器都受影响

Podman：
  无守护进程（daemonless）
  每个容器是独立进程
  可以完全以普通用户运行（rootless）
  命令兼容 Docker：alias docker=podman 就行

---

四、包管理的进化

4.1 你熟悉的 yum 变成了 dnf

CentOS 6/7：yum install nginx
CentOS 8+：  dnf install nginx   ← yum 的下一代

dnf 的改进：
├── 依赖解析更快更准确
├── 模块化（同一个包可以选不同版本流）
├── 性能大幅提升
└── yum 命令仍然可用（实际是 dnf 的别名）

4.2 EPEL 依然在，但你可能不需要了

以前装一些软件要先加 EPEL 源。现在容器化之后，大多数软件直接用 Docker 镜像：

以前：
  yum install epel-release
  yum install nginx php redis nodejs ...
  各种版本冲突和依赖地狱

现在：
  docker run nginx
  docker run redis
  docker run node
  每个服务在自己的容器里，互不干扰

4.3 通用包格式：Snap / Flatpak / AppImage

传统包管理的问题是：不同发行版格式不同（.rpm vs .deb），依赖关系复杂。新的通用格式试图解决这个问题：

Snap（Canonical/Ubuntu 主推）：
  snap install code          # 装 VS Code
  snap install node --channel=20  # 指定版本

Flatpak（Red Hat/Fedora 主推）：
  flatpak install firefox    # 沙盒化运行

AppImage（社区方案）：
  chmod +x app.AppImage      # 下载即用，无需安装
  ./app.AppImage

在服务器端这些不太常用（服务器主要用容器），但在桌面 Linux 上已经很流行。

---

五、开发工具链的变化

5.1 编译器和语言运行时

你那个时代            →     现在

GCC 4.x               →     GCC 13/14（C++23 支持）
Python 2.7（默认）     →     Python 2 已死（2020 年终止），Python 3.11/3.12
PHP 5.x                →     PHP 8.3（性能翻倍，JIT 编译）
Java 7/8               →     Java 21 LTS（虚拟线程、模式匹配）
Node.js 4/6            →     Node.js 20/22 LTS（ESM 模块、内置测试）
没有 Rust              →     Rust 成为系统编程新贵
没有 Go 生态           →     Go 成为云原生基础设施的标准语言

5.2 Python 2 的死亡

这是你可能需要适应的最大变化之一：

2020 年 1 月 1 日：Python 2 正式终止支持

影响：
├── CentOS 6/7 默认 python 指向 Python 2 → 现在 python3 是标准
├── 很多老脚本需要迁移到 Python 3
├── pip → pip3，print 语句 → print() 函数
└── 新系统上可能根本没有 Python 2

现代 Python 版本管理：
  pyenv install 3.12.0     # 用 pyenv 管理多版本
  python3 -m venv myenv    # 用内置的 venv（不再需要 virtualenv）
  pip install poetry        # 或用 Poetry 管理项目

5.3 版本管理工具普及

以前经常要手动编译安装特定版本的语言运行时，现在：

# Node.js 版本管理
nvm install 20       # Node Version Manager
fnm install 20       # 更快的替代品（Rust 写的）

# Python 版本管理
pyenv install 3.12

# Java 版本管理
sdkman install java 21.0.2-tem

# 通用版本管理（一个工具管所有）
mise install node@20 python@3.12 java@21
# mise（前身是 rtx/asdf 的替代）正在成为新标准

5.4 Git 的绝对统治

2013 年：SVN 还有不少企业在用
2025 年：Git 统一了版本控制领域

新增概念：
├── GitHub Actions / GitLab CI  → 代码推送自动触发构建部署
├── Git LFS                     → 大文件管理
├── Monorepo                    → 单仓库管理多项目
├── Conventional Commits        → 提交信息规范化
└── GitHub Codespaces           → 云端开发环境

---

六、网络和安全的变化

6.1 HTTPS 成为默认

2015 年之前：
  HTTPS 证书要花钱买（几百到几千元/年）
  大部分网站是 HTTP

2015 年之后：
  Let's Encrypt 提供免费 HTTPS 证书
  Certbot 自动申请和续期证书
  各大浏览器开始标记 HTTP 为"不安全"

现在的操作：
  # 一条命令搞定 HTTPS
  certbot --nginx -d example.com

  # 或者用 Caddy（自动 HTTPS 的 Web 服务器）
  # Caddy 会自动申请和续期证书，零配置

6.2 防火墙：iptables → nftables / firewalld

你记忆中：
  iptables -A INPUT -p tcp --dport 80 -j ACCEPT
  iptables -A INPUT -p tcp --dport 443 -j ACCEPT
  service iptables save

现在：
  # firewalld（CentOS 7+ 默认，更友好）
  firewall-cmd --add-service=http --permanent
  firewall-cmd --add-service=https --permanent
  firewall-cmd --reload

  # 或 ufw（Ubuntu 默认，更简单）
  ufw allow 80/tcp
  ufw allow 443/tcp
  ufw enable

底层变化：
  iptables → nftables（内核层面的替代）
  nftables 性能更好、语法更统一
  但大多数人通过 firewalld/ufw 操作，不直接碰底层

6.3 SSH 安全加强

变化：
├── DSA 密钥已废弃 → 用 Ed25519（更安全、更短）
│     ssh-keygen -t ed25519
├── 密码登录越来越不推荐 → 密钥登录成为标配
├── SSH 跳板机/堡垒机 → 企业标配
└── SSH 证书认证 → 大规模环境替代密钥分发

新实践：
  # 生成现代 SSH 密钥
  ssh-keygen -t ed25519 -C "your@email.com"

  # SSH 配置简化（~/.ssh/config）
  Host myserver
    HostName 192.168.1.100
    User deploy
    IdentityFile ~/.ssh/id_ed25519

6.4 SELinux 你可能关过，但现在不该关了

2013 年的常见操作：
  setenforce 0                    # 临时关闭
  sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config  # 永久关闭
  # "SELinux 太烦了，直接关掉"

2025 年的态度：
  不要关闭 SELinux！容器安全依赖它。
  学会查看和处理 SELinux 拒绝日志：
  ausearch -m avc --start today
  sealert -a /var/log/audit/audit.log

---

七、文件系统和存储

7.1 默认文件系统的变迁

CentOS 6 默认：ext4
CentOS 7 默认：XFS（更适合大文件和高并发）
CentOS 8+/RHEL 9：XFS
Ubuntu：ext4（但越来越多人用 Btrfs）

新选手：
├── Btrfs → 快照、压缩、子卷，适合桌面和开发环境
├── ZFS  → 企业级存储，数据完整性极佳
└── bcachefs → 最新内核中的新秀，目标是结合以上所有优点

7.2 LVM + 薄置备

以前：
  分区时就要规划好大小，改起来很麻烦

现在（LVM 薄置备 + XFS）：
  可以动态扩展分区大小
  支持快照用于备份
  大多数云平台已经帮你配好了

---

八、Linux 内核的重大进化

8.1 内核版本跳跃

你那个时代：
  CentOS 6 → 内核 2.6.32
  CentOS 7 → 内核 3.10

现在：
  内核 6.x（2025 年最新主线）

重要里程碑：
  3.x → 4.0 (2015)：OverlayFS 合入（Docker 的基石）
  4.x → 5.0 (2019)：io_uring、WireGuard
  5.x → 6.0 (2022)：Rust 代码进入内核

8.2 值得关注的内核新特性

eBPF —— 内核中的”可编程沙盒”

eBPF 是什么：
  允许你在内核中安全地运行自定义程序
  不需要修改内核代码或加载内核模块

用途：
├── 网络监控和过滤（替代 iptables 的高性能方案）
├── 性能分析（观测系统调用、函数调用耗时）
├── 安全策略（运行时检测恶意行为）
└── 容器网络（Cilium 项目，K8s 网络层基于 eBPF）

工具：
  bpftrace   → eBPF 的"awk"，一行命令观测内核
  bcc        → eBPF 工具集
  Cilium     → 基于 eBPF 的容器网络

io_uring —— 异步 IO 革命

以前：
  Linux 的高性能 IO 用 epoll（Go、Nginx 等都用它）
  但 epoll 只能处理网络 IO，不能处理磁盘 IO

现在：
  io_uring 统一了网络和磁盘的异步 IO
  性能比 epoll 还好
  新版数据库和存储引擎都在适配 io_uring

cgroups v2 —— 容器资源管理升级

cgroups v1（你那个时代）：
  多个独立的层级树，管理混乱
  CPU、内存、IO 各自独立控制

cgroups v2（现在的默认）：
  统一的层级树
  更精细的资源控制
  更好的容器支持
  systemd 和 Docker/Podman 都已默认使用 v2

---

九、CI/CD 与 DevOps：部署流程的革命

9.1 从”手动部署”到”自动流水线”

你记忆中的部署：
  1. SSH 登录服务器
  2. cd /var/www/html
  3. git pull
  4. 重启服务
  5. 祈祷没出问题

现在的部署（CI/CD 流水线）：
  1. 开发者 git push 代码
  2. 自动触发 CI 流水线：
     ├── 自动运行测试
     ├── 自动构建 Docker 镜像
     ├── 自动推送镜像到仓库
     └── 自动部署到服务器/K8s
  3. 失败则自动回滚
  4. 全程不需要 SSH 登录服务器

9.2 主流 CI/CD 工具

GitHub Actions   ── GitHub 原生，最流行
GitLab CI/CD     ── GitLab 原生，企业用得多
Jenkins          ── 老牌工具，依然活跃
ArgoCD           ── K8s 原生的 GitOps 工具

一个典型的 GitHub Actions 流水线：

# .github/workflows/deploy.yml
name: Deploy
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build Docker image
        run: docker build -t myapp .

      - name: Push to registry
        run: docker push registry.example.com/myapp

      - name: Deploy to server
        run: ssh deploy@server "docker pull && docker compose up -d"

代码推送到 main 分支 → 自动构建 → 自动部署。整个过程无需人工介入。

9.3 Infrastructure as Code（基础设施即代码）

以前：
  手动在控制台点点点创建服务器、配置网络、安全组...
  下次复现？全凭记忆和文档

现在：
  Terraform → 用代码定义云基础设施
  Ansible   → 用代码批量配置服务器
  Pulumi    → 用编程语言（而非 DSL）定义基础设施

示例（Terraform 创建一台阿里云服务器）：
  resource "alicloud_instance" "web" {
    instance_type = "ecs.t6-c1m1.large"
    image_id      = "ubuntu_22_04"
    ...
  }
  # terraform apply → 自动创建服务器
  # 环境完全可复现

---

十、云原生与微服务

10.1 从”一台服务器跑所有东西”到”微服务”

2013 年的典型架构（单体）：
┌─────────────────────────┐
│  一台 CentOS 服务器       │
│  ├── Nginx               │
│  ├── PHP/Java 应用        │
│  ├── MySQL               │
│  ├── Redis               │
│  └── 定时任务 (crontab)   │
└─────────────────────────┘
  所有东西跑在一台机器上

2025 年的典型架构（微服务 / 容器化）：
┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
│API 网│ │用户  │ │订单  │ │支付  │
│关    │ │服务  │ │服务  │ │服务  │
│Nginx │ │Node  │ │Java  │ │Go    │
└──┬───┘ └──┬───┘ └──┬───┘ └──┬───┘
   │        │        │        │
   └────────┴────┬───┴────────┘
                 │
          ┌──────┴──────┐
          │ Kubernetes  │
          │ 容器编排     │
          └─────────────┘
  每个服务独立容器，独立部署，独立扩容

10.2 云原生关键组件

服务网格    → Istio / Linkerd（服务间通信管理）
API 网关    → Kong / APISIX（请求路由和鉴权）
配置中心    → Consul / Nacos（配置统一管理）
消息队列    → Kafka / RabbitMQ / NATS（异步通信）
监控        → Prometheus + Grafana（替代 Nagios/Zabbix）
日志        → ELK Stack / Loki（集中日志管理）
链路追踪    → Jaeger / Zipkin（分布式调用链跟踪）

---

十一、WSL —— 在 Windows 上跑 Linux

如果你现在在 Windows 上开发，WSL (Windows Subsystem for Linux) 是一个巨大的变化：

以前在 Windows 上用 Linux：
├── 装虚拟机（VMware/VirtualBox）—— 重，吃资源
├── 装双系统 —— 切换麻烦
└── 用 Cygwin/MinGW —— 兼容性差

现在：
  wsl --install        # 一条命令安装 WSL 2 + Ubuntu
  wsl                  # 进入 Linux 环境
  code .               # 在 VS Code 中打开（无缝集成）

WSL 2 的本质：
  跑在 Hyper-V 轻量虚拟机里的真正 Linux 内核
  文件系统互通，网络互通
  Docker Desktop 可以直接跑在 WSL 2 里
  性能接近原生 Linux

---

十二、现代 Linux 服务器搭建速查

把以上所有变化整合成一个对照表，帮你快速对应新旧概念：

你记忆中（CentOS 6 时代）          →  现在（2025 年）

─── 系统管理 ───
service httpd start              →  systemctl start httpd
chkconfig httpd on               →  systemctl enable httpd
/var/log/messages                →  journalctl
init.d 脚本（80 行 shell）        →  systemd service 文件（15 行）
iptables                         →  firewalld / ufw / nftables

─── 包管理 ───
yum install                      →  dnf install / apt install
rpm -qa                          →  dnf list installed
手动编译安装                      →  Docker 镜像 / 容器

─── 部署 ───
FTP/SCP 上传代码                  →  Git push + CI/CD 自动部署
手动装依赖                        →  Dockerfile 打包环境
单台服务器                        →  容器集群 / 云服务
crontab 定时任务                  →  systemd timer / K8s CronJob

─── 开发 ───
Python 2.7                       →  Python 3.12
vim + screen                     →  VS Code + tmux（或 SSH 远程开发）
SVN                              →  Git + GitHub/GitLab
手动测试                         →  CI 自动化测试

─── 安全 ───
HTTP                             →  HTTPS（Let's Encrypt 免费证书）
密码登录 SSH                     →  Ed25519 密钥 + 禁用密码登录
关闭 SELinux                     →  保持 SELinux 开启

─── 监控 ───
top / free / df                  →  htop / btop / glances
Nagios / Cacti                   →  Prometheus + Grafana
tail -f /var/log/xxx             →  journalctl -f -u xxx

---

十三、学习路径建议

如果你想快速跟上这些年的变化，建议按以下顺序学习：

第一周：基础回血
├── 装一台 Ubuntu 24.04（或 Rocky Linux 9）
├── 熟悉 systemd（systemctl / journalctl）
├── 了解 firewalld/ufw
└── 适应 Python 3

第二周：容器入门
├── 安装 Docker
├── 学会 Dockerfile 编写
├── docker compose 多容器编排
└── 把一个项目容器化

第三周：CI/CD
├── 用 GitHub Actions 搭建自动构建
├── 了解 Git 分支策略（Git Flow / Trunk-based）
└── 实现代码推送自动部署

第四周：进阶
├── 了解 Kubernetes 基本概念
├── 学习 Terraform/Ansible
├── 了解 Prometheus + Grafana 监控
└── 探索 eBPF 和现代内核特性

---

总结

用一句话概括 2016-2025 年 Linux 开发部署领域的变化：

从”手工打造单台服务器”到”代码定义一切、容器承载一切、流水线自动化一切”。

你那个时代的很多技能（Linux 基础、Shell 编程、网络配置、服务管理）依然有价值——它们是理解现代工具的基础。容器不是魔法，CI/CD 不是黑箱，K8s 不是天书——它们都建立在你已经了解的 Linux 基础之上。

不同的是，现在的趋势是把运维知识编码化——以前记在脑子里的操作步骤，现在写在 Dockerfile、Compose 文件、Terraform 配置和 CI/CD 流水线里。代码可以版本控制、可以复现、可以协作，这就是”基础设施即代码”的核心思想。

欢迎回来。

---

本文为个人视角的技术趋势总结，不代表全面的行业分析。Linux 生态极其广阔，本文聚焦在与中小型开发团队最相关的变化。如有补充或纠正，欢迎交流。