第一次跃迁：从“脚本自动化”到“服务编排”

背景：​

刚入职时，我每天要手动部署测试环境：装Nginx、配PHP、启MySQL、改防火墙……一天重复5次，累到怀疑人生。最怕的是半夜被叫起来：“环境又起不来了”，过去一看，要么是防火墙没放通，要么是服务启动顺序错了。

解决方案：​

我决定用 Shell脚本 + Crontab​ 做自动化，把“人肉操作”变成“可复现流程”：

#!/bin/bash
# auto_deploy_test_env.sh
# 功能：一键部署LNMP测试环境

echo "开始部署..."

yum install -y nginx php php-fpm mysql-server
systemctl enable --now nginx php-fpm mysqld

# 配置防火墙
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reload

# 创建测试页面
echo "<?php phpinfo(); ?>" > /usr/share/nginx/html/test.php

echo "部署完成！访问 http://你的IP/test.php 验证"

然后加入定时任务，顺手把日志清理也自动化：

crontab -e
# 每天凌晨2点自动清理7天前的Nginx日志
0 2 * * * find /var/log/nginx -name "*.log" -mtime +7 -delete

效果：​

• 单次环境部署从30分钟缩短到5分钟内；

• 人为遗漏（忘开防火墙、漏启服务）基本归零；

• 我开始意识到：运维的第一生产力不是技术堆砌，而是“可重复的确定性”。

课程关联：​

这正是课中“Shell脚本进阶”和“LNMP架构”的实践延伸。课本教的是命令，我用它去管服务依赖关系——比如PHP-FPM必须先就绪，Nginx反向代理才不会报502；MySQL要先初始化，应用才能连库。这些细节，书里不会替你踩，但生产环境会。

---

第二次跃迁：从“单机部署”到“容器化交付”

背景：​

开发同事一句老生常谈：“在我电脑上能跑，到你服务器就不行！”

问题出在哪？PHP版本不同、依赖缺包、SELinux策略不一致……环境差异是运维的天敌。

解决方案：​

我引入 Docker + Docker Compose，把“环境”当成代码来管理。

1. 编写 Dockerfile（Nginx + PHP）

FROM nginx:alpine
RUN apk add --no-cache php8 php8-fpm
COPY nginx.conf /etc/nginx/nginx/conf
COPY src/ /usr/share/nginx/html/
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

2. 编写 docker-compose.yml（完整LNMP栈）

version: '3.8'
services:
  web:
    build: .
    ports:
      - "80:80"
    depends_on:
      - php
    networks:
      - lnmp-net

  php:
    image: php:8.1-fpm
    volumes:
      - ./src:/var/www/html
    networks:
      - lnmp-net

  db:
    image: mysql:5.7
    environment:
      MYSQL_ROOT_PASSWORD: rootpass
      MYSQL_DATABASE: testdb
    volumes:
      - db-data:/var/lib/mysql
    networks:
      - lnmp-net

volumes:
  db-data:

networks:
  lnmp-net:
    driver: bridge

效果：​

• 新同事入职，不再需要“半天配环境”，一条 docker-compose up -d全部就绪；

• 开发、测试、生产环境完全一致，告别“环境玄学”；

• 数据卷持久化保证数据库重启不丢数据，网络隔离避免服务乱窜。

课程关联：​

课中“Docker应用实践”让我理解了镜像、容器、数据卷这些概念，但我往前多走了一步：用 Docker Compose 做多服务编排。企业里很少只跑一个容器，Nginx、PHP、MySQL 是要协同工作的，这才叫“企业级用法”，而不是课本里单跑一个 docker run。

---

第三次跃迁：从“手工运维”到“云原生架构”

背景：​

公司业务增长，服务器从5台变成50台，靠SSH登机器、手动改配置已经不可能。我们需要的是资源池化 + 自动调度，而不是“更高级的脚本”。

解决方案：​

我主导搭建了基于 OpenStack + Kubernetes​ 的私有云平台：

1. OpenStack 负责 IaaS 层（计算、存储、网络）​

• Nova 调度虚拟机实例，按需分配 CPU / 内存；

• Neutron 做虚拟网络隔离（VLAN / VXLAN），部门间流量可控；

• Cinder 提供块存储，数据库节点可随时扩容磁盘；

• Keystone 统一认证，避免各系统账号混乱。

2. Kubernetes 负责 PaaS 层（容器编排）​

• Pod 作为最小部署单元，承载 Docker 容器；

• Service 做服务发现与负载均衡，前端不再写死后端IP；

• Ingress 统一对外暴露 HTTP/HTTPS；

• HPA（Horizontal Pod Autoscaler）根据 CPU / 请求量自动扩缩容。

实战案例：电商大促期间的扩容​

平时订单服务跑 3 个 Pod，大促前流量预估翻 3 倍：

• HPA 自动扩容到 10 个 Pod，接口 RT 稳定在 200ms 内；

• 大促结束后自动缩容回 3 个，资源不浪费；

• 整个过程无人值守，只在监控里看到一条条扩容事件。

课程关联：​

课中“私有云”和“容器云”章节更多是讲组件和概念，我把它落地成了可运行的架构（文字版）：

[用户] → [Ingress Controller] → [Order Service Pod] → [MySQL Cluster]
                             ↑
                         [Auto Scaling Policy]

同时，我也关注国产信创系统（如 openEuler、麒麟 OS），在边缘节点用 K3s（轻量级 K8s）+ 麒麟OS​ 部署非核心服务，兼顾自主可控与成本。

---

第四次跃迁：从“稳定运行”到“数据驱动决策”

背景：​

系统稳了，老板却问：“为什么上个月流量激增？哪个服务最耗资源？下次大促要加几台机器？”

光“不出事”已经不够了，得回答为什么、是多少、怎么预判。

解决方案：​

我引入了 Prometheus + Grafana + ELK Stack：

• Prometheus 拉取节点、容器、业务的指标（CPU、内存、QPS、延迟）；

• Grafana 做可视化仪表盘，一眼看清系统健康度；

• ELK（Elasticsearch + Logstash + Kibana）集中采集日志，方便溯源。

实战案例：​

某次支付接口响应变慢，Grafana 显示数据库连接池持续打满 → 用 Kibana 检索应用日志，定位到一条慢查询 SQL → 给对应表加复合索引 → 单次响应从 2s 降到 200ms，后续同类型大促未再复现。

课程关联：​

课中“云计算管理平台”和“监控体系”更多是铺垫，我把它升级成了数据驱动的运维文化——不再是“坏了再修”，而是“指标异常先告警、日志先行定位、容量提前评估”。

---

总结：网管的三大核心能力模型

能力维度	关键技术	实战价值
自动化​	Shell脚本、Ansible	减少重复劳动，把人从机械操作中解放出来
标准化​	Docker、Compose、K8s	消除环境差异，保障开发/测试/生产一致性
智能化​	Prometheus、Grafana、ELK	数据驱动决策，从“救火”转向“防火”

运维不是“机器坏了你会修”，而是即使机器会坏，也能让业务不受影响。

从脚本到云原生，这条路上最值钱的不是命令本身，而是你对依赖、风险、规模的理解。

---

附：推荐学习路径（适合初学者）

1. Linux 基础 + Shell 脚本：先把自动化底线打好；

2. LNMP 架构 + MySQL 基础：理解业务怎么跑、数据怎么存；

3. Docker + Docker Compose：解决环境一致性问题；

4. Kubernetes 基础 + 私有云概念：面对规模化时的资源与编排思维；

5. 监控与日志体系（Prometheus / ELK）：让系统会“说话”，提前预警。