云计算运维学习路线：从Linux基础到自动化监控与排错实战

简介一份面向云计算运维学习者、技能竞赛及PaaS相关岗位备赛人群的系统化学习路线文档。内容从Linux目录结构、常用命令、防火墙Iptables/Firewalld、时间同步NTP、Web服务Tomcat/Nginx、MySQL/MariaDB等基础讲起逐步覆盖Shell脚本自动化部署LNMP、MySQL全备与增备、MySQL用户权限与主从复制、LVS负载均衡与PCS集群、OpenStack虚拟化、Ansible自动化部署、Python编程、Docker容器化以及基于Kubernetes的CICD持续集成几乎串联起云计算运维全栈核心知识点。每个阶段都明确了学习周期、推荐视频和独立考核任务方便读者按周拆分、边学边练避免单纯读文档式的低效学习。资源包为单个docx文件大小18KB文字紧凑、无冗余素材便于检索、打印和后续复习。目前已有1691人浏览学习适合准备技能竞赛、系统构建运维知识体系或向DevOps转型的读者。文档还特别设计了检验性任务例如独立部署webmall、在三台云主机上搭建高可用数据库集群、基于K8s构建CICD等能够有效巩固所学并帮助读者查漏补缺。1. 云计算运维为什么要有“学习路线”“云计算运维学习路线”听起来像是一份培训机构的课表但真正干过几年服务器运维的人都知道它背后是一条技术栈不断演化的主线。传统运维的核心是“守住机器”磁盘满了、进程挂了、机房断电能第一时间处理就算合格。云计算运维的核心变成了“管好资源”几十台、几百台实例的创建和销毁存储桶的权限策略负载均衡的转发规则这些都不能再靠手工一台台登录去改。对工作三五年、正处于传统运维向云平台运维转型期的工程师来说路线图不是用来收藏的是用来对照自己缺哪块补哪块的。我见过不少从 IDC 机房运维转到云平台运维的同事起初最不习惯的是“一切皆可编程”。以前vi /etc/nginx/nginx.conf改完reload就好现在要面对的是 Terraform 脚本、镜像构建、弹性伸缩组这些抽象层。这篇文章不罗列课程大纲而是按“底层硬基础 → 云平台核心服务 → 监控与自动化 → 排错与验证”这条主线把每一步需要的具体命令、参数和容易踩的坑写清楚。适合两类人一是准备转岗云运维的 Linux 工程师二是已经在云平台上做基础运维、想把自动化能力补齐的人。2. 底层硬基础云计算运维绕不开的 Linux、网络和脚本2.1 从单机排障到集群视角Linux 命令的学习重点迁移传统运维学 Linux 命令重点在ls、cd、top、free这些单机操作。云计算运维里这些命令依然要用但视角完全不同。你面对的不再是某一台物理机而是一组相同配置的云服务器实例排查问题需要先定位是单点故障还是整体异常。因此top、free、df -h这些命令的学习重点不在“怎么用”而在“怎么从输出里快速判断瓶颈特征”。我一般会先让新人掌握一组“组合命令”把多个基础命令串起来完成一个相对完整的排查动作# 查看系统负载与 CPU 核数判断 load average 是否超过核数 uptime # 定位 CPU 占用最高的进程 top -b -n 1 | head -20 | sort -k9 -r # 结合上下文查看内存分布 free -h cat /proc/meminfo | grep -E MemTotal|MemFree|Buffers|Cached # 查看磁盘 inode 使用率很多告警隐藏在这里 df -h df -i这段脚本的逻辑是先看整体负载再下钻到具体进程最后检查容易被忽略的 inode 耗尽问题。参数上要注意top -b -n 1表示非交互模式只取一次快照方便在脚本里继续处理free -h的-h选项用可读性更好的单位输出避免换算十进制和二进制的差异。云服务器磁盘多数是云盘iostat看到的延迟和吞吐指标反映的是底层存储的真实状态这也是比单机时代更需要关注的地方。2.2 网络排查命令从 ping 通到链路质量判断云计算运维里网络排查的难度比传统机房更复杂因为流量路径上多了虚拟网络层。同一地域内不同可用区间通信、跨地域专线、负载均衡到后端节点的链路每层都可能出现丢包或延迟抖动。很多人在这一步只记得ping和telnet但真正定位问题靠的是分层排查的思路。# 第一步判断目标是否可达、解析是否正常 ping -c 4 云服务器内网IP # 第二步确认目标端口是否在监听 telnet 云服务器内网IP 80 # 第三步跟踪路由定位延迟或丢包发生在哪一跳 traceroute -n -T -p 443 目标域名 # 第四步查看本机连接状态确认 TCP 连接是否存在半开状态 ss -ant | grep 目标IP | head -20traceroute使用-T参数走 TCP 探测而不是默认的 UDP很多云厂商安全组会屏蔽 UDP 探测包TCP 探测的结果更接近真实业务链路的连通性。ss -ant命令里-a表示显示所有连接-n禁用域名反解以加快显示速度-t限定 TCP 协议。看到大量SYN_SENT或TIME_WAIT状态的连接时常见原因是安全组策略未放通或后端服务并发连接数设置过低。2.3 脚本语言是云运维的“母语”只靠手敲命令走不远的这一点在云平台环境里格外明显。几十台机器上批量改配置、定时清理日志、自动创建云资源快照这些场景都需要脚本。Python 和 Bash 是云运维岗位面试里出现频率最高的两种语言前者适合做复杂的逻辑处理和 API 调用后者适合快速完成系统层面的操作。下面是一段用 Python 调用云厂商 OpenAPI 完成云服务器定期快照的示例脚本片段这类需求在真实业务里非常常见#!/usr/bin/env python3 批量创建云服务器快照用于每日备份 import boto3 # 通用示例换成国内云厂商 SDK 时对应修改 client 初始化 ec2 boto3.client(ec2, region_namecn-north-1) instance_ids [i-xxxxx, i-yyyyy] # 生产环境建议从标签或配置文件读取 for instance_id in instance_ids: # DescribeInstances 获取实例当前状态避免对已停止的实例创建快照 resp ec2.describe_instances(InstanceIds[instance_id]) state resp[Reservations][0][Instances][0][State][Name] if state ! running: print(f跳过非运行中实例: {instance_id}, 当前状态: {state}) continue # CreateTags 给快照打标签便于后续按业务线筛选和清理 snapshot ec2.create_snapshot( VolumeIdresp[Reservations][0][Instances][0][BlockDeviceMappings][0][Ebs][VolumeId], Descriptionfdaily-backup-{instance_id} ) ec2.create_tags( Resources[snapshot[SnapshotId]], Tags[{Key: Name, Value: fautosnap-{instance_id}}] ) print(f已创建快照: {snapshot[SnapshotId]})代码先检查实例状态再对第一块数据盘创建快照最后打上标识性的标签。这样做的好处是避免批量任务把已销毁实例的无效资源重试一遍。参数上要注意BlockDeviceMappings取的是列表索引为 0 的数据云服务器挂载多块数据盘时需要遍历所有映射项。标签策略是云运维的常规要求没有标签的快照过一个月就分不清归属清理时也不敢删。3. 云平台核心服务与资源编排把 Terraform 用起来3.1 云基础设施机制是云环境的基础构件块搞清它们如何协作“云基础设施机制是云环境的基础构件块”这句话在云计算概论的教材里出现频率很高落到实际运维里指的就是计算、存储、网络、数据库这几类基础服务之间的协同关系。云服务器的创建不只是选择一个镜像和规格同时要考虑它挂载的云盘类型、所属的 VPC 子网、绑定的安全组规则、关联的密钥对以及是否需要分配公网 IP。任何一项配置不当都可能引发后续访问不通或性能不达标的问题。在云厂商控制台上点击创建实例很容易但生产环境不可能靠手工点击来维护上百台机器更不可能在故障后几分钟内重建出一套环境。这也是我坚持让运维团队尽早接触资源编排工具的原因。Terraform 是目前跨云平台兼容性最好的基础设施即代码IaC工具模板写好后plan和apply两个动作就能完成环境的创建和变更。3.2 用 Terraform 定义一套最小可运行环境下面是一份用 Terraform HCL 语言定义云服务器与安全组的精简配置展示资源编排的基本形态# 指定云厂商插件与版本 terraform { required_providers { alicloud { source aliyun/alicloud version ~ 1.200.0 } } } # 配置认证信息生产环境建议用环境变量注入避免明文写在代码里 provider alicloud { region var.region } # 查询当前账号下可用的最新 Ubuntu 镜像 data alicloud_images ubuntu { most_recent true owners system name_regex ^ubuntu_24_04_x64 } # 创建 VPC 与交换机生产环境需要按可用区规划网段 resource alicloud_vpc vpc_main { vpc_name prod-vpc cidr_block 172.16.0.0/16 } resource alicloud_vswitch vsw_main { vpc_id alicloud_vpc.vpc_main.id cidr_block 172.16.1.0/24 zone_id var.zone_id } # 安全组只放行 22 端口和 80 端口 resource alicloud_security_group sg_web { vpc_id alicloud_vpc.vpc_main.id } resource alicloud_security_group_rule allow_ssh { type ingress ip_protocol tcp nic_type intranet policy accept port_range 22/22 priority 1 cidr_ip var.admin_cidr security_group_id alicloud_security_group.sg_web.id } # 云服务器实例最小规格、绑定公网 IP、安装 nginx 启动脚本 resource alicloud_instance web_server { instance_name prod-web-01 image_id data.alicloud_images.ubuntu.images[0].id instance_type ecs.g8i.small vswitch_id alicloud_vswitch.vsw_main.id security_groups [alicloud_security_group.sg_web.id] internet_max_bandwidth_out 5 user_data -EOF #!/bin/bash apt-get update -y apt-get install -y nginx systemctl enable nginx systemctl start nginx EOF }这段配置的核心逻辑是把“网络环境、安全组、计算实例”三个相互耦合的资源放在同一个模板里统一管理。注意security_groups参数传入的是一个列表云服务器的网卡可以同时加入多个安全组规则取并集。user_data脚本只在实例首次启动时执行如果后续想变更初始化逻辑需要配合配置管理工具而不是改这段脚本重新执行。admin_cidr建议使用公司出口 IP 段而不是0.0.0.0/0这是云运维中最容易被忽略的安全底线。3.3 Terraform 运维的常见误区和调整方式资源编排工具上手不难难在与现有运维流程结合。我见过有团队把 Terraform 当作云控制台的替代品等于“用脚本点击按钮”资源创建完成后就不再更新模板导致模板与实际环境脱节。也有团队在模板里写死资源名称和 IP跨环境复用能力几乎没有。正确的做法是把环境差异收敛到变量文件中每个环境维护独立的dev.tfvars、prod.tfvars内容只放不同部分的参数比如实例规格、可用区、标签。同一份资源定义在多个环境间重复使用时资源命名要带环境前缀避免删掉测试环境时误伤生产资源。terraform plan的输出必须人工审查确认destroy操作只发生在预期资源上。云平台上数据误删后很难恢复快照和备份策略要独立于 Terraform 之外定期验证。4. 监控告警与自动化运维把“被动救火”变成“主动巡防”4.1 云监控指标怎么选主机层、应用层和云服务层要分开看监控体系是云运维的承重墙但很多人的监控面板一大堆图表真正告警时还是靠用户先发现故障。问题的根源在于监控指标选得不对。云平台默认带的基础监控覆盖 CPU、内存、磁盘 IO、网络流量这些只能反映资源使用率不能真实反映用户体验。业务层面的延迟、错误率、队列积压量必须用自定义监控或接入 Prometheus 这类开源方案来补全。下表是一个三层的监控指标框架可以对照自己的环境做一次检查监控层级关键指标推荐阈值示例采集方式主机层CPU 使用率、load average持续 15 分钟 70% 告警云监控 Agent / node_exporter主机层磁盘空间使用率数据盘 80% 告警 90% 紧急node_exporter Alertmanager应用层Nginx 5xx 比例、响应时间5xx 占比 1% 持续 5 分钟Prometheus nginx_exporter应用层消息队列积压量积压 1000 条持续 10 分钟云监控自定义消息 / 脚本上报云服务层负载均衡后端健康检查失败数连续 3 次探测失败即预警云监控事件中心云服务层的监控很容易被忽略。负载均衡后端健康检查失败、RDS 慢查询数突增、CDN 回源失败这些事件通常出现在云厂商的控制台事件列表里不会主动推到你的告警系统需要额外配置事件订阅。我处理过不少棘手的线上问题最终定位到的根因都不是服务器本身而是云服务侧的限流或故障切换。4.2 Prometheus 告警规则一个可以直接落地的告警配置Prometheus 在云原生运维里的地位已经非常稳固它的告警规则用 YAML 描述语法简单但表达逻辑很灵活。下面是一段适用于云服务器场景的告警规则配置groups: - name: cloud_server_alerts rules: # 磁盘空间使用率超过 80% 且持续 30 分钟触发告警 - alert: DiskUsageHigh expr: (1 - (node_filesystem_avail_bytes{fstype!~tmpfs|overlay} / node_filesystem_size_bytes{fstype!~tmpfs|overlay})) * 100 80 for: 30m labels: severity: warning annotations: summary: 实例 {{ $labels.instance }} 磁盘使用率超过 80% description: 当前使用率已持续 30 分钟请检查是否需要扩容或清理日志。 # 实例 CPU 使用率超过 90% 且持续 15 分钟升级为严重级别 - alert: CpuHighLoad expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100) 90 for: 15m labels: severity: critical annotations: summary: 实例 {{ $labels.instance }} CPU 使用率过高配置里for: 30m的作用很关键它表示指标表达式结果持续为真 30 分钟才触发告警能有效过滤瞬时尖峰造成的骚扰。告警规则里的正则表达式fstype!~tmpfs|overlay排除了虚拟文件系统避免把临时文件系统当作数据盘来告警这是从实践中总结出的细节。rate函数计算的是每秒增长量配合5m窗口平滑波动比直接使用 counter 原始值准确得多。4.3 自动化运维工具链的选型与参数边界监控发现问题之后处理动作也要尽量自动化。Ansible 是云运维中使用门槛最低的自动化工具基于 SSH 执行不用在目标机器上安装 Agent。对国内云环境来说它处理批量配置修改、服务重启、软件安装都很顺手。下面是一段批量修改 Nginx 配置并重新加载服务的最小 Ansible Playbook--- - name: 批量更新 nginx 配置并重载 hosts: web_servers become: yes vars: nginx_worker_processes: 4 tasks: - name: 写入 nginx 主配置 template: src: nginx.conf.j2 dest: /etc/nginx/nginx.conf owner: root group: root mode: 0644 register: config_result - name: 测试配置语法 command: nginx -t when: config_result.changed notify: - reload nginx handlers: - name: reload nginx systemd: name: nginx state: reloadedPlaybook 的核心逻辑是通过template模块渲染配置模板register捕获变更结果只有配置实际变化时才执行nginx -t语法检查并通过notify触发 handler 执行重载。when: config_result.changed这个条件避免每次执行都重启服务是自动化任务避免“无脑变更”的关键设计。handler 的reloaded状态表示热加载不会中断现有连接相比restarted更适合生产环境。自动化工具的边界也值得说清楚。Ansible 适合做“有状态”的变更操作比如更新配置、发布版本而云资源的创建销毁这类“无状态”操作更适合交给 Terraform。两者重叠的部分是初始化新服务器常见方案是 Terraform 负责创建实例和基础网络Ansible 接管实例创建后的软件部署与配置标准化。职责分开后排查问题时的路径会清晰很多。智能风电运维、AI 运维这些概念这几年很热但实际落地时还是要回到数据采集、告警降噪、故障定位这些基础能力上。没有规范的监控指标和自动执行通道再强的智能算法也拿不到有效数据。5. 排错实战从连接失败到服务卡死的定位链路5.1 一条命令链走完“网络层 → 服务层 → 进程层”的排查故障排错是云运维面试里最常见也最能拉开差距的环节。很多运维遇到服务访问失败第一反应是登录服务器看服务状态却忽略了先确认网络链路是否正常。正确的顺序应该是从外向里逐层收缩范围。下面这条命令链覆盖了从连接到进程的完整定位路径我在遇到线上故障时基本按照这个顺序执行# 1. 确认公网入口是否可达丢包率过高先怀疑安全组或负载均衡 ping -c 4 负载均衡VIP # 2. 确认 TCP 端口是否开放telnet 能通不代表 HTTP 正常 timeout 3 bash -c /dev/tcp/负载均衡VIP/443 echo port open # 3. 查看负载均衡后端节点健康状态 curl -s http://负载均衡IP/healthz | jq .status # 4. 登录后端云服务器确认服务进程是否存活 systemctl status nginx # 5. 查看本地端口监听与连接队列 ss -lntp | grep 80 ss -lnt sport :80 | wc -l # 6. 抓取到达本机的流量确认请求是否真的到达后端 tcpdump -i eth0 tcp port 80 -c 50/dev/tcp/IP/端口是 Bash 内置的 TCP 连接测试方式不需要安装额外工具超时控制可以用timeout命令包裹避免卡住。ss -lnt sport :80统计的是当前处于监听状态的连接数量当这个数字接近net.core.somaxconn的默认值时说明有大量请求堆积在 accept 队列应用处理速度跟不上。tcpdump抓包是最接近真相的手段但生产环境流量较大时建议加-c限制包的数量避免把临时文件塞满磁盘。5.2 云服务器 CPU 飚高却找不到进程不可中断睡眠与 D 状态有一种故障是云服务器整体响应缓慢top显示 CPU 使用率很高但看不到明显吃 CPU 的进程。这类情况多半不是应用问题而是进程处于 D 状态不可中断睡眠等待磁盘 IO 或内核锁释放。云盘性能突然下降、本地盘出现坏道、NFS 挂载点失联这些情况都可能导致 D 状态堆积。排查这一步有两个实用命令# 查看处于 D 状态的进程数量 ps -eo state,pid,comm | awk $1 D {print} # 查看进程对应的系统调用栈确认阻塞在内核的哪个位置 cat /proc/PID/stack echo w /proc/sysrq-trigger dmesg | tail -50/proc/PID/stack能输出内核调用栈但某些内核版本会限制普通用户查看需要 root 权限。写入/proc/sysrq-trigger的w参数可以让内核 dump 出所有 D 状态进程的调用栈到内核日志这是定位内核层面阻塞的终极手段。云环境里遇到 D 状态堆积先检查云监控里磁盘延迟和 IOPS 指标是否出现明显上涨再联系云厂商确认是否有底层宿主机故障一般不要轻易重启服务器重启后堆栈信息会丢失。5.3 故障预案的关键不在“想到”而在“演练”能够熟练使用排错命令只是基本功云计算运维的真正壁垒在于故障应急预案的完整性和可演练性。很多团队写了厚厚的应急预案文档但实际故障发生时发现文档里的命令已经过时、责任人联系方式失效、备用的云服务器没有预配置好。我建议团队把焦点放在“最短可恢复路径”上为每个核心业务准备独立的“一键检查”脚本输出服务状态、依赖资源、最近变更记录并默认追加到故障工单中。每月做一次“注入式演练”比如手动将一台云服务器的安全组入方向规则全部清空观察告警链路是否及时触发运维人员能否在 10 分钟内定位到安全组变更。云资源的备份策略要区分“数据备份”和“整机可恢复性”。定期做一次完整的恢复演练从备份创建出新实例、挂载数据盘、恢复服务验证的不是备份文件存在而是恢复动作本身能跑通。混沌工程实践在条件允许时可以引入生产环境的小流量场景比如随机杀掉一个后端节点验证负载均衡的摘除和重调度逻辑是否符合预期。排错能力的成长路径不是靠读文档而是靠每一次故障的事后复盘。把每次线上事故的根因、时间线、恢复动作记录成一份结构化的“排错记录”半年后回头看这些记录比任何培训课程都有价值。本文还有配套的精品资源点击获取