简介面向企业IT运维与云计算架构人员这份PDF系统梳理了大企业私有云运维的整体落地方案围绕云数据中心稳定运行与管理效益提升解决基础设施规模扩大后的运维效率问题。资源为单个PDF文档压缩包仅304KB内容精炼适合快速阅读或作为内部方案参考。目前已有450人学习浏览说明具备一定参考价值。文档重点介绍云运维的目的、用友云运维管理方案、云运维服务内容与模式并展开基础设施运维、云应用运维、综合服务三大模块同时给出由运维制度、流程、组织、队伍、技术平台和运维对象构成的总体架构兼顾制度规范、技术手段与人员保障便于企业运维团队借鉴并搭建或优化自有私有云运维体系。1. 私有云运维的出发点让团队从“救火”转向“控盘”私有云建完只是开始真正决定业务体感的是后续运维。用友这套私有云运维方案把目标定在“云数据中心价值最大化”本质上是在回答一个问题当计算、网络、存储都走向资源池化之后运维到底管什么答案不是哪一台服务器而是承载业务的服务链路。方案从制度、平台、队伍三条线展开对正在自建云数据中心的企业和承接交付的集成商都有参考价值。与传统机房不同私有云故障半径从单机变成资源池运维人员必须先理解架构再谈工具和流程。2. 用友云运维平台总体架构与部署角色拆解2.1 “制度—流程—平台—队伍”四层建设模型云运维最容易犯的错误是直接上监控工具等平台搭完才发现告警没人处理、流程没人认领。用友方案里把“制度流程”放在“技术平台”前面意图很明确运维平台是执行层制度和流程是控制层。落地时我一般会把事件管理、变更管理和问题管理先写成书面规范再映射到平台的工单状态机例如“已登记—处理中—待升级—已解决—已关闭”。没有这张状态表平台上线后只会多一个看板不会改善响应速度。第二点是强调管理平台作为手段。统一采集层需要同时具备 agent、API 和 syslog 三种接入方式既能纳管服务器上的代理也能对接云平台暴露的 REST API还能接收网络设备主动日志。建设时要避免每个小团队自建一套采集器否则后面做告警关联和变更影响分析时数据口径完全不一致。常见做法是先定义一套 metric 命名规范再要求所有设备接入同一套管理监控服务器。第三点是队伍保障。这里我不建议把“运维培训”做成产品功能介绍而是围绕故障场景做演练。比如模拟某台宿主机宕机让运维人员从收到告警、查询 CMDB、迁移虚拟机的完整动作全部走一遍。用友方案提到协助用户建立高素质队伍实际执行中至少要让每名运维工程师熟悉云管平台的 API能写脚本完成重复操作而不是只会点控制台。2.2 六要素架构制度、流程、组织、队伍、平台、对象的配合方式用友云运维平台的总体架构由六部分组成。拆开看制度和流程属于管理面组织和队伍属于责任人面技术平台属于执行面运维对象属于被管面。四类因素缺一不可其中最容易漏掉的是“运维对象”的梳理。很多团队把对象理解成 IP 列表但更合理的最小单位应该是“一个可独立恢复的业务组件”比如 Nginx 实例、MySQL 主从组、Redis 集群甚至一块云硬盘。下表是我根据方案整理的六要素落地表方便后续做岗位和平台模块的映射。要素典型落地产物平台支撑模块运维服务制度事件/问题/变更管理制度工单引擎、审批流运维服务流程事件升级路径、变更窗口表流程编排运维服务组织云平台组、基础架构组、应用运维组角色与权限树运维服务队伍值班表、技能矩阵、演练记录培训管理、认证管理技术服务平台监控、自动化、日志、CMDB管理监控服务器、ISM 服务器运行维护对象宿主机、虚拟机、容器、存储卷、网络设备配置管理库、拓扑视图实际做映射时建议把“变更窗口”也放进去。私有云里很多故障不是设备损坏而是变更操作引起的没有变更流程约束后面做根因分析就会变成相互推诿。云平台的权限树最好按组织架构隔离比如 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 信息、光模块收发光功率、交换机端口丢弃率。管理监控服务器上的告警至少要覆盖下面这张表。监控对象关键指标建议阈值典型动作宿主机 CPU使用率 / CPU steal使用率 85%steal 10%检查邻居虚拟机迁移负载内存可用率 / SWAP可用率 15%查看是否有内存泄漏进程存储链路磁盘延迟 / IOPSIO 时延 20ms检查存储控制器和网络拥塞文件系统空间使用率根分区 80%数据盘 85%清理日志或扩容云硬盘网络交换机端口 error/drop错包率持续增长检查光模块、双工模式、网线巡检命令不建议全部手工敲写一个批量脚本会更高效。下面这段脚本从 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 NR2{printf \Mem: %d/%dMB\\n\, \$3, \$2} # 根分区使用率容量超过 80% 时高亮提示 ssh $ip df -h / | awk NR2 \$5080 {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脚本中NR2是 awk 里的行号判断跳过标题行\$50把 df 输出的百分比转成数字再比较2/dev/null用于忽略未安装存储工具的报错。实际使用时要根据 RAID 卡厂商调整命令比如 MegaRAID 用MegaCli64LSI 后期版本用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{modeidle}[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{modeidle}[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: truetemplate模块把本地的 chrony 配置模板推送到目标机器notify会在配置变更时触发restart chronydhandler。如果有多台机器Ansible 会并行执行比逐台登录效率高很多。这里注意所有操作都要记录到审计日志谁在什么时间改了什么配置事后都能追溯。没有审计的操作在私有云环境里很难通过安全合规检查。4. 私有云运维模式选型自运维、托管运维与混合分工4.1 私有云与公有云的运维边界差异私有云运维和公有云运维的本质区别是控制面归属。公有云场景下计算虚拟化、块存储、负载均衡等能力以 API 和托管服务形式暴露用户不需要接触底层硬件很多基础设施故障由云厂商直接消化。私有云恰好相反机房的每一台服务器、每一根光纤都在企业内部出了问题只能在自己的运维体系里解决。好处是定制空间大坏处是没有规模化红利小问题也可能需要自己排查。用友方案把运维模式分成私有云运维和公有云运维两种实际企业往往走的是混合路线核心系统和数据放在私有云弹性扩展和对外引流用公有云。这种情况下私有云部分的监控、告警、容量管理必须比公有云更严谨因为你不可能把服务器故障甩给云厂商。团队规模不大的企业至少要让一到两个人专职负责私有云资源池其余人员按业务系统划分。4.2 用责任矩阵确定自运维和托管运维的边界私有云的“自运维”不等于所有事都自己干。硬件维保、机房动环、带外管理这些工作可以交给设备厂商平台层和应用层的关键操作留在企业内部。下面是我基于方案和常见实践整理的责任矩阵适合作为预算和招聘的依据。运维内容自运维混合运维全托管服务器硬件 / RAID / 固件企业自维硬件厂家免费维保托管方负责虚拟化 / 云管理平台企业自维平台原厂远程支持托管方负责虚拟机 / 镜像 / 快照企业自维企业自维托管方负责中间件与数据库企业应用运维DBA 外包或内部托管方负责网络设备与安全设备企业网络组网络原厂支持托管方负责备份与恢复演练企业自维企业自维工具外采托管方负责判断标准很简单如果某个组件的故障会直接导致核心业务不可用它的“操作权”必须留在企业内部如果只是运行环境问题可以交给托管或原厂。混合运维模式下最忌讳的是边界只停留在口头约定应该在运维平台的工单系统里给外部支持人员配置独立的角色和权限所有操作留痕。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 -Fload average: {print $2}) MEM$(free -m | awk /^Mem:/{printf %d/%dMB, $3, $2}) DISK$(df -h / | awk NR2{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.logdate提供时间戳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 仍会重复通知。我会配置两组路由severitycritical直接走电话或 IMseveritywarning合并成周期汇总。每条告警都要携带 instance 和业务标签这样值班人员可以从标题直接判断影响的是哪个资源池。更实际一点的做法是把告警状态机与变更登记联动。恢复告警后不要急着关闭工单先看故障时间窗口内是否有堡垒机登录、Ansible 执行记录或配置变更。私有云中的很多 P2 告警是变更操作引起的把告警时间轴与变更时间轴对齐往往比分析监控曲线更快找到根因。等这套机制稳定后再把变更数据接入到 AIOps 平台的根因关联效果会更明显。本文还有配套的精品资源点击获取 
长河君 · 2026/9/19 11:16:02 · 阅读 1.2k 私有云运维实战：从架构搭建到监控告警与自动化脚本
简介面向企业IT运维与云计算架构人员这份PDF系统梳理了大企业私有云运维的整体落地方案围绕云数据中心稳定运行与管理效益提升解决基础设施规模扩大后的运维效率问题。资源为单个PDF文档压缩包仅304KB内容精炼适合快速阅读或作为内部方案参考。目前已有450人学习浏览说明具备一定参考价值。文档重点介绍云运维的目的、用友云运维管理方案、云运维服务内容与模式并展开基础设施运维、云应用运维、综合服务三大模块同时给出由运维制度、流程、组织、队伍、技术平台和运维对象构成的总体架构兼顾制度规范、技术手段与人员保障便于企业运维团队借鉴并搭建或优化自有私有云运维体系。1. 私有云运维的出发点让团队从“救火”转向“控盘”私有云建完只是开始真正决定业务体感的是后续运维。用友这套私有云运维方案把目标定在“云数据中心价值最大化”本质上是在回答一个问题当计算、网络、存储都走向资源池化之后运维到底管什么答案不是哪一台服务器而是承载业务的服务链路。方案从制度、平台、队伍三条线展开对正在自建云数据中心的企业和承接交付的集成商都有参考价值。与传统机房不同私有云故障半径从单机变成资源池运维人员必须先理解架构再谈工具和流程。2. 用友云运维平台总体架构与部署角色拆解2.1 “制度—流程—平台—队伍”四层建设模型云运维最容易犯的错误是直接上监控工具等平台搭完才发现告警没人处理、流程没人认领。用友方案里把“制度流程”放在“技术平台”前面意图很明确运维平台是执行层制度和流程是控制层。落地时我一般会把事件管理、变更管理和问题管理先写成书面规范再映射到平台的工单状态机例如“已登记—处理中—待升级—已解决—已关闭”。没有这张状态表平台上线后只会多一个看板不会改善响应速度。第二点是强调管理平台作为手段。统一采集层需要同时具备 agent、API 和 syslog 三种接入方式既能纳管服务器上的代理也能对接云平台暴露的 REST API还能接收网络设备主动日志。建设时要避免每个小团队自建一套采集器否则后面做告警关联和变更影响分析时数据口径完全不一致。常见做法是先定义一套 metric 命名规范再要求所有设备接入同一套管理监控服务器。第三点是队伍保障。这里我不建议把“运维培训”做成产品功能介绍而是围绕故障场景做演练。比如模拟某台宿主机宕机让运维人员从收到告警、查询 CMDB、迁移虚拟机的完整动作全部走一遍。用友方案提到协助用户建立高素质队伍实际执行中至少要让每名运维工程师熟悉云管平台的 API能写脚本完成重复操作而不是只会点控制台。2.2 六要素架构制度、流程、组织、队伍、平台、对象的配合方式用友云运维平台的总体架构由六部分组成。拆开看制度和流程属于管理面组织和队伍属于责任人面技术平台属于执行面运维对象属于被管面。四类因素缺一不可其中最容易漏掉的是“运维对象”的梳理。很多团队把对象理解成 IP 列表但更合理的最小单位应该是“一个可独立恢复的业务组件”比如 Nginx 实例、MySQL 主从组、Redis 集群甚至一块云硬盘。下表是我根据方案整理的六要素落地表方便后续做岗位和平台模块的映射。要素典型落地产物平台支撑模块运维服务制度事件/问题/变更管理制度工单引擎、审批流运维服务流程事件升级路径、变更窗口表流程编排运维服务组织云平台组、基础架构组、应用运维组角色与权限树运维服务队伍值班表、技能矩阵、演练记录培训管理、认证管理技术服务平台监控、自动化、日志、CMDB管理监控服务器、ISM 服务器运行维护对象宿主机、虚拟机、容器、存储卷、网络设备配置管理库、拓扑视图实际做映射时建议把“变更窗口”也放进去。私有云里很多故障不是设备损坏而是变更操作引起的没有变更流程约束后面做根因分析就会变成相互推诿。云平台的权限树最好按组织架构隔离比如 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 信息、光模块收发光功率、交换机端口丢弃率。管理监控服务器上的告警至少要覆盖下面这张表。监控对象关键指标建议阈值典型动作宿主机 CPU使用率 / CPU steal使用率 85%steal 10%检查邻居虚拟机迁移负载内存可用率 / SWAP可用率 15%查看是否有内存泄漏进程存储链路磁盘延迟 / IOPSIO 时延 20ms检查存储控制器和网络拥塞文件系统空间使用率根分区 80%数据盘 85%清理日志或扩容云硬盘网络交换机端口 error/drop错包率持续增长检查光模块、双工模式、网线巡检命令不建议全部手工敲写一个批量脚本会更高效。下面这段脚本从 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 NR2{printf \Mem: %d/%dMB\\n\, \$3, \$2} # 根分区使用率容量超过 80% 时高亮提示 ssh $ip df -h / | awk NR2 \$5080 {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脚本中NR2是 awk 里的行号判断跳过标题行\$50把 df 输出的百分比转成数字再比较2/dev/null用于忽略未安装存储工具的报错。实际使用时要根据 RAID 卡厂商调整命令比如 MegaRAID 用MegaCli64LSI 后期版本用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{modeidle}[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{modeidle}[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: truetemplate模块把本地的 chrony 配置模板推送到目标机器notify会在配置变更时触发restart chronydhandler。如果有多台机器Ansible 会并行执行比逐台登录效率高很多。这里注意所有操作都要记录到审计日志谁在什么时间改了什么配置事后都能追溯。没有审计的操作在私有云环境里很难通过安全合规检查。4. 私有云运维模式选型自运维、托管运维与混合分工4.1 私有云与公有云的运维边界差异私有云运维和公有云运维的本质区别是控制面归属。公有云场景下计算虚拟化、块存储、负载均衡等能力以 API 和托管服务形式暴露用户不需要接触底层硬件很多基础设施故障由云厂商直接消化。私有云恰好相反机房的每一台服务器、每一根光纤都在企业内部出了问题只能在自己的运维体系里解决。好处是定制空间大坏处是没有规模化红利小问题也可能需要自己排查。用友方案把运维模式分成私有云运维和公有云运维两种实际企业往往走的是混合路线核心系统和数据放在私有云弹性扩展和对外引流用公有云。这种情况下私有云部分的监控、告警、容量管理必须比公有云更严谨因为你不可能把服务器故障甩给云厂商。团队规模不大的企业至少要让一到两个人专职负责私有云资源池其余人员按业务系统划分。4.2 用责任矩阵确定自运维和托管运维的边界私有云的“自运维”不等于所有事都自己干。硬件维保、机房动环、带外管理这些工作可以交给设备厂商平台层和应用层的关键操作留在企业内部。下面是我基于方案和常见实践整理的责任矩阵适合作为预算和招聘的依据。运维内容自运维混合运维全托管服务器硬件 / RAID / 固件企业自维硬件厂家免费维保托管方负责虚拟化 / 云管理平台企业自维平台原厂远程支持托管方负责虚拟机 / 镜像 / 快照企业自维企业自维托管方负责中间件与数据库企业应用运维DBA 外包或内部托管方负责网络设备与安全设备企业网络组网络原厂支持托管方负责备份与恢复演练企业自维企业自维工具外采托管方负责判断标准很简单如果某个组件的故障会直接导致核心业务不可用它的“操作权”必须留在企业内部如果只是运行环境问题可以交给托管或原厂。混合运维模式下最忌讳的是边界只停留在口头约定应该在运维平台的工单系统里给外部支持人员配置独立的角色和权限所有操作留痕。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 -Fload average: {print $2}) MEM$(free -m | awk /^Mem:/{printf %d/%dMB, $3, $2}) DISK$(df -h / | awk NR2{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.logdate提供时间戳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 仍会重复通知。我会配置两组路由severitycritical直接走电话或 IMseveritywarning合并成周期汇总。每条告警都要携带 instance 和业务标签这样值班人员可以从标题直接判断影响的是哪个资源池。更实际一点的做法是把告警状态机与变更登记联动。恢复告警后不要急着关闭工单先看故障时间窗口内是否有堡垒机登录、Ansible 执行记录或配置变更。私有云中的很多 P2 告警是变更操作引起的把告警时间轴与变更时间轴对齐往往比分析监控曲线更快找到根因。等这套机制稳定后再把变更数据接入到 AIOps 平台的根因关联效果会更明显。本文还有配套的精品资源点击获取