私有云运维实战：从架构搭建到监控告警与自动化脚本

简介：面向企业IT运维与云计算架构人员，这份PDF系统梳理了大企业私有云运维的整体落地方案，围绕云数据中心稳定运行与管理效益提升，解决基础设施规模扩大后的运维效率问题。资源为单个PDF文档，压缩包仅304KB，内容精炼，适合快速阅读或作为内部方案参考。目前已有450人学习浏览，说明具备一定参考价值。文档重点介绍云运维的目的、用友云运维管理方案、云运维服务内容与模式，并展开基础设施运维、云应用运维、综合服务三大模块，同时给出由运维制度、流程、组织、队伍、技术平台和运维对象构成的总体架构，兼顾制度规范、技术手段与人员保障，便于企业运维团队借鉴并搭建或优化自有私有云运维体系。

1. 私有云运维的出发点：让团队从“救火”转向“控盘”

私有云建完只是开始，真正决定业务体感的是后续运维。用友这套私有云运维方案把目标定在“云数据中心价值最大化”，本质上是在回答一个问题：当计算、网络、存储都走向资源池化之后，运维到底管什么？答案不是哪一台服务器，而是承载业务的服务链路。方案从制度、平台、队伍三条线展开，对正在自建云数据中心的企业和承接交付的集成商都有参考价值。与传统机房不同，私有云故障半径从单机变成资源池，运维人员必须先理解架构，再谈工具和流程。

2. 用友云运维平台：总体架构与部署角色拆解

2.1 “制度—流程—平台—队伍”四层建设模型

云运维最容易犯的错误是直接上监控工具，等平台搭完才发现告警没人处理、流程没人认领。用友方案里把“制度流程”放在“技术平台”前面，意图很明确：运维平台是执行层，制度和流程是控制层。落地时我一般会把事件管理、变更管理和问题管理先写成书面规范，再映射到平台的工单状态机，例如“已登记—处理中—待升级—已解决—已关闭”。没有这张状态表，平台上线后只会多一个看板，不会改善响应速度。

第二点是强调管理平台作为手段。统一采集层需要同时具备 agent、API 和 syslog 三种接入方式，既能纳管服务器上的代理，也能对接云平台暴露的 REST API，还能接收网络设备主动日志。建设时要避免每个小团队自建一套采集器，否则后面做告警关联和变更影响分析时，数据口径完全不一致。常见做法是先定义一套 metric 命名规范，再要求所有设备接入同一套管理监控服务器。

第三点是队伍保障。这里我不建议把“运维培训”做成产品功能介绍，而是围绕故障场景做演练。比如模拟某台宿主机宕机，让运维人员从收到告警、查询 CMDB、迁移虚拟机的完整动作全部走一遍。用友方案提到协助用户建立高素质队伍，实际执行中，至少要让每名运维工程师熟悉云管平台的 API，能写脚本完成重复操作，而不是只会点控制台。

2.2 六要素架构：制度、流程、组织、队伍、平台、对象的配合方式

用友云运维平台的总体架构由六部分组成。拆开看，制度和流程属于管理面，组织和队伍属于责任人面，技术平台属于执行面，运维对象属于被管面。四类因素缺一不可，其中最容易漏掉的是“运维对象”的梳理。很多团队把对象理解成 IP 列表，但更合理的最小单位应该是“一个可独立恢复的业务组件”，比如 Nginx 实例、MySQL 主从组、Redis 集群，甚至一块云硬盘。

下表是我根据方案整理的六要素落地表，方便后续做岗位和平台模块的映射。

实际做映射时，建议把“变更窗口”也放进去。私有云里很多故障不是设备损坏，而是变更操作引起的，没有变更流程约束，后面做根因分析就会变成相互推诿。云平台的权限树最好按组织架构隔离，比如 PaaS 团队只能操作容器节点，DBA 团队只能执行数据库命令，权限变更需要走流程审批。

2.3 部署架构的角色划分与 LVS 入口设计

方案里的部署架构图给出了几个关键服务器角色：文件服务器、Web 服务器、DB 服务器、应用服务器、LVS 服务器、管理监控服务器、VM 云管理平台服务器、ISM 服务器。先别急着看数量，重点是网络分区：这些角色不应全部躺在同一个业务 VLAN 里。

按常见做法，我把它们分成管理网段和业务网段。文件服务器、DB 服务器、管理监控服务器放管理网，只接受管理跳板机访问；Web 服务器和应用服务器放在 DMZ 或业务接入网，对外只开放 HTTPS 443 端口；LVS 作为统一入口，将请求分发到多台应用服务器。ISM 服务器负责和存储设备的管理口通信，往往单独划一个存储管理 VLAN，避免存储控制器的管理流量和业务流量互相干扰。

下面是一段在 LVS 节点上配置 DR 模式的示例，两台 Web 服务器共用同一个 VIP：

# 配置 IPVS 虚拟服务：VIP 10.10.10.10:443，加权轮询 ipvsadm -A -t 10.10.10.10:443 -s wrr # 后端 Web 服务器，DR 模式(-g)，权重分别设为 1 和 2 ipvsadm -a -t 10.10.10.10:443 -r 192.168.1.11:443 -g -w 1 ipvsadm -a -t 10.10.10.10:443 -r 192.168.1.12:443 -g -w 2 # 查看当前连接数，验证转发是否生效 ipvsadm -L -n --stats

-s wrr表示加权轮询调度，适合后端配置不一致的场景；-g是 DR 模式，要求后端服务器禁止回包走 LVS，必须在 Web 服务器的 lo 接口绑定 VIP；-w指定权重，权重高的服务器承担更多请求。--stats输出的 active/inactive 连接数能帮你判断是否有一台后端连接堆积。很多云平台自带的负载均衡器底层就是类似逻辑，但需要直接暴露 Linux 服务时，LVS 仍是最轻量、可控的方案。

注意：DR 模式下后端服务器的 ARP 要设置抑制，否则会出现 VIP 地址冲突。这个细节是运维排障时的高频深坑。

2.4 管理监控服务器与云管理平台的对接边界

管理监控服务器的职责是“采集+告警+展示”，而 VM 云管理平台服务器的职责是“资源编排+生命周期管理”，两者不能混用。用友方案里把这两个角色独立部署，就是为了避免监控系统占用资源调度接口。实际对接时，监控服务器通过云管理平台开放的 API 拉取虚拟机清单，不直接操作计算节点，这样即使监控服务器宕机，也不会影响云平台调度。

比如从 OpenStack 或 VMware 拉取虚拟机状态，常用做法是调用 REST API，将返回的 JSON 写入监控系统标签，让告警规则可以按项目或租户维度分组。用 Python 脚本定期同步是常见方案，这里不展开。有一点值得记住：监控系统的账号只给只读权限，千万别拿 admin 账号去接监控。

3. 基础设施、云应用与综合服务：三层运维内容的操作清单

3.1 基础设施运维：先盯硬件，再看资源池

基础设施在私有云里包含计算节点、分布式存储和网络设备。运维目标不是保证某台设备不出故障，而是保证资源池在任意单点故障时仍能继续对外提供服务。因此基础设施运维的第一步是全面采集底层硬件健康数据，比如 RAID 卡日志、磁盘 SMART 信息、光模块收发光功率、交换机端口丢弃率。管理监控服务器上的告警至少要覆盖下面这张表。

巡检命令不建议全部手工敲，写一个批量脚本会更高效。下面这段脚本从 hosts.txt 逐台读取 IP，通过 SSH 采集负载、内存、磁盘和 RAID 状态，并把结果追加到统一日志文件。

#!/bin/bash # hosts.txt 每行一个宿主机 IP，需要预先配置免密登录 while read ip; do { echo "===== $ip $(date '+%F %T') =====" # uptime 采集 1/5/15 分钟负载 ssh "$ip" "uptime" # 内存使用量/总量，free -m 以 MB 输出 ssh "$ip" "free -m | awk 'NR==2{printf \"Mem: %d/%dMB\\n\", \$3, \$2}'" # 根分区使用率，容量超过 80% 时高亮提示 ssh "$ip" "df -h / | awk 'NR==2 && \$5+0>=80 {print \"Root disk warning: \" \$5}'" # 检查 RAID 卡是否异常，常见型号使用 megacli 或 storcli ssh "$ip" "storcli /c0 show alarm | grep -E 'Alarm|State'" 2>/dev/null || echo "RAID tool not found" } >> /var/log/ops/host_check.log done < hosts.txt

脚本中NR==2是 awk 里的行号判断，跳过标题行；\$5+0把 df 输出的百分比转成数字再比较；2>/dev/null用于忽略未安装存储工具的报错。实际使用时要根据 RAID 卡厂商调整命令，比如 MegaRAID 用MegaCli64，LSI 后期版本用storcli。这个脚本解决的是“有没有问题”，定位根因还需要看 dmesg 和管理监控服务器的历史趋势。

3.2 云应用运维：把告警从机器级别提升到业务级别

云应用运维关心的是虚拟机和容器里运行的业务系统。监控不能只停留在 CPU 80% 这样的资源指标，因为资源饱和不等于业务故障，业务故障也不一定由资源饱和引起。更稳妥的做法是分层设置探针：第一层探测进程或容器是否存活，第二层探测关键接口的往返时延，第三层分析日志中的错误码。私有云场景下，虚拟机的健康检查可以由云管理平台来做，应用的健康检查则需要运维人员自己定义。

以 Prometheus 为例，一套常见的云应用告警规则可以这样描述：

groups: - name: cloud-app-health rules: # 虚拟机 CPU 使用率超过 90% 且持续 10 分钟 - alert: CloudAppHighCPU expr: 100 - (avg by(instance, job) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90 for: 10m labels: severity: warning annotations: summary: "{{ $labels.instance }} CPU usage > 90%" # 黑盒探针检测到 HTTPS 状态码非 200 - alert: CloudAppHttpDown expr: probe_success == 0 for: 2m labels: severity: critical annotations: summary: "{{ $labels.instance }} HTTPS probe failed"

第一段expr里的rate(node_cpu_seconds_total{mode="idle"}[5m])计算的是 5 分钟 idle 时间占比，用 100 减去后就是 CPU 使用率。by(instance, job)限定聚合维度，避免把多台机器混成一个值。for: 10m表示指标持续异常 10 分钟才触发，用来过滤瞬时抖动。第二段的probe_success == 0来自 blackbox_exporter，一旦探针失败就视为业务入口不可用。告警规则写完后，还要在 Alertmanager 里配置接收路由，按严重级别分发给云平台组和应用运维组。

常见误区是直接给每条告警都配一个负责人，导致一个人同时收 20 个告警。我会把告警按业务优先级分组，核心交易系统的 P0 告警发给第一梯队，资源水位类 P2 告警只在值班群展示。

3.3 综合服务：CMDB、堡垒机与备份验证要连成闭环

综合服务在方案里包含 IT 资产管理、网络管理和安全管理，我把它理解为“运维的运维”。CMDB 记录每一台虚拟机的归属项目、规格、变更记录，没有 CMDB，告警找人就只能靠群发；堡垒机统一接管 SSH 和虚拟化平台登录，操作有审计回放；备份系统和恢复演练决定故障发生后能不能平安落地。

这里用一个 Ansible 任务示例说明如何把综合服务落到日常操作：统一管理云主机的时间同步配置。时间偏差是所有认证和日志故障的常见根因，必须作为基线配置。

- name: 同步所有云主机的 NTP 配置 hosts: cloud_hosts become: true tasks: - name: 写入 chrony 配置 ansible.builtin.template: src: chrony.conf.j2 dest: /etc/chrony.conf owner: root group: root mode: 0644 notify: restart chronyd handlers: - name: restart chronyd ansible.builtin.service: name: chronyd state: restarted enabled: true

template模块把本地的 chrony 配置模板推送到目标机器，notify会在配置变更时触发restart chronydhandler。如果有多台机器，Ansible 会并行执行，比逐台登录效率高很多。这里注意：所有操作都要记录到审计日志，谁在什么时间改了什么配置，事后都能追溯。没有审计的操作，在私有云环境里很难通过安全合规检查。

4. 私有云运维模式选型：自运维、托管运维与混合分工

4.1 私有云与公有云的运维边界差异

私有云运维和公有云运维的本质区别是控制面归属。公有云场景下，计算虚拟化、块存储、负载均衡等能力以 API 和托管服务形式暴露，用户不需要接触底层硬件，很多基础设施故障由云厂商直接消化。私有云恰好相反，机房的每一台服务器、每一根光纤都在企业内部，出了问题只能在自己的运维体系里解决。好处是定制空间大，坏处是没有规模化红利，小问题也可能需要自己排查。

用友方案把运维模式分成私有云运维和公有云运维两种，实际企业往往走的是混合路线：核心系统和数据放在私有云，弹性扩展和对外引流用公有云。这种情况下，私有云部分的监控、告警、容量管理必须比公有云更严谨，因为你不可能把服务器故障甩给云厂商。团队规模不大的企业，至少要让一到两个人专职负责私有云资源池，其余人员按业务系统划分。

4.2 用责任矩阵确定自运维和托管运维的边界

私有云的“自运维”不等于所有事都自己干。硬件维保、机房动环、带外管理这些工作可以交给设备厂商，平台层和应用层的关键操作留在企业内部。下面是我基于方案和常见实践整理的责任矩阵，适合作为预算和招聘的依据。

判断标准很简单：如果某个组件的故障会直接导致核心业务不可用，它的“操作权”必须留在企业内部；如果只是运行环境问题，可以交给托管或原厂。混合运维模式下，最忌讳的是边界只停留在口头约定，应该在运维平台的工单系统里给外部支持人员配置独立的角色和权限，所有操作留痕。

4.3 用代码把运维模式变成可验证的 SLO

定了模式之后，还需要有量化指标证明运维模式是有效的。这里说的不是看故障次数，而是看可用性是否达到服务等级目标。下面脚本统计最近 30 天健康检查日志的成功率，并输出是否达标。

#!/bin/bash # health.log 每行格式：2025-01-01 12:00:00 200 LOG=${1:-/var/log/ops/health.log} TOTAL=$(wc -l < "$LOG") SUCCESS=$(grep -c " 200" "$LOG") if [ "$TOTAL" -eq 0 ]; then echo "无健康检查数据，请检查探针任务" exit 1 fi RATE=$((SUCCESS * 10000 / TOTAL)) echo "可用性: ${RATE:0:-2}.${RATE: -2}%" if [ "$RATE" -ge 9990 ]; then echo "达到 99.9% SLO" else echo "未达到 SLO，需分析失败时间窗口" fi

脚本把SUCCESS除以TOTAL后乘以 10000，用整数表示成功率。10000代表 100%，9990代表 99.90%。${RATE:0:-2}和${RATE: -2}只负责显示，不参与判断。如果连续多个周期未达标，就要回溯对应时间段内的告警记录和变更记录，看是容量不足、发布失误还是基础设施故障。建议把这个脚本接进 crontab，每天输出一次到独立文件，再由监控平台读取该文件生成趋势图。这样运维模式的改进会有数据支撑，而不是凭感觉觉得“最近还行”。

5. 落地私有云运维：告警收敛与轻量脚本技巧

5.1 把 linux 常用命令聚合成一个可留痕的巡检脚本

一线运维最容易陷入的误区是到处找现成工具，今天下载一个网络运维工具箱，明天又装一个来源不明的采集器。实际上私有云环境的巡检逻辑非常固定：看负载、看内存、看磁盘、看网卡错误。把这些 linux 常用命令写进一个 20 行的脚本，放到管理监控服务器上由 cron 定时执行，效果比频繁切换工具更稳定。

#!/bin/bash # 轻量巡检：追加写日志，每次运行只输出一圈结果 HOST=$(hostname) LOAD=$(uptime | awk -F'load average:' '{print $2}') MEM=$(free -m | awk '/^Mem:/{printf "%d/%dMB", $3, $2}') DISK=$(df -h / | awk 'NR==2{print $5}') ERR=$(ip -s link | grep -A1 "RX:" | grep errors | head -1) echo "$(date '+%F %T') $HOST load:$LOAD mem:$MEM disk:$DISK err:$ERR" >> /var/log/ops/check.log

date提供时间戳，load:$LOAD输出 1/5/15 分钟负载；MEM提取内存使用量和总量；DISK只取根分区使用率；ERR取自ip -s link的输出，快速确认网卡是否有丢包。配合 cron 每五分钟执行一次：

*/5 * * * * /usr/local/sbin/quick_check.sh

脚本放在管理监控服务器上，日志统一写入/var/log/ops/。注意不要在这里写死 root 密码，运维账号通过 SSH 密钥登录，脚本本身只读系统状态，不做变更操作。这样即使不登录机器，也能事后从日志还原故障发生前的状态。多网卡服务器需要按接口名过滤，不能直接用head -1取第一块。

5.2 用告警状态机避免风暴

告警收敛比告警规则本身更重要。Prometheus 中for可以过滤瞬时抖动，但当同一条告警在恢复后再次触发时，Alertmanager 仍会重复通知。我会配置两组路由：severity=critical直接走电话或 IM，severity=warning合并成周期汇总。每条告警都要携带 instance 和业务标签，这样值班人员可以从标题直接判断影响的是哪个资源池。

更实际一点的做法是把告警状态机与变更登记联动。恢复告警后不要急着关闭工单，先看故障时间窗口内是否有堡垒机登录、Ansible 执行记录或配置变更。私有云中的很多 P2 告警是变更操作引起的，把告警时间轴与变更时间轴对齐，往往比分析监控曲线更快找到根因。等这套机制稳定后，再把变更数据接入到 AIOps 平台的根因关联，效果会更明显。

本文还有配套的精品资源，点击获取