数据中台运维的特殊挑战
数据中台不同于传统的单体应用系统。一个典型的数据中台包含 Hadoop、Hive、Spark、Flink、Kafka、Nacos、MySQL、Oracle 等数十个组件,组件之间的依赖关系错综复杂。任何一个环节的异常都可能引发连锁反应——Kafka 消费延迟导致 Flink 任务堆积,Flink 任务堆积又导致下游 Hive 表产出延迟,最终业务报表无法按时呈现。
在国网某省级电力公司的大数据反窃电分析系统中,技术栈涵盖了 Hadoop + Hive + Oracle 三层架构,仅核心服务就超过 40 个微服务,日均处理用电量数据超过 2 亿条。这样的系统规模意味着:
- 组件多:一个完整数据中台通常包含 20-50 个独立组件,每个组件都有自己的配置、日志和监控体系
- 依赖复杂:服务注册发现(Nacos)、消息队列(Kafka)、计算引擎(Spark/Flink)、存储层(HDFS/Hive/RDBMS)之间存在多层级联依赖
- 数据量大:日处理数据量从 GB 级到 PB 级不等,存储和计算资源的弹性伸缩成为刚需
- 多数据库共存:MySQL 8.0、达梦 7/8、Oracle 12、人大金仓等数据库在同一套系统中共存,运维复杂度成倍增加
面对这些挑战,零散的运维手段已经捉襟见肘。需要一套工程化的运维体系,从组织架构、巡检制度、监控告警、故障处理到故障自愈,形成完整的闭环。
运维组织架构设计:三组协作模型
在国网项目的实践中,运维团队被划分为三个职能组,各司其职又紧密协作:
业务运维组
业务运维组直接面向最终用户,核心职责包括:
- 响应业务方提出的功能问题和数据疑问
- 验证数据准确性,排查数据链路异常
- 协调业务需求与技术实现之间的沟通
- 管理业务侧的变更申请和发布审批
系统运维组
系统运维组聚焦于基础设施层,覆盖范围包括:
- 服务器硬件、操作系统、网络设备的日常维护
- 存储资源的容量规划和扩容操作
- 操作系统补丁更新和安全加固
- 设备巡检和故障硬件的更换协调
平台运维组
平台运维组是数据中台运维的核心力量,职责涵盖:
- 大数据集群(Hadoop/Hive/Spark/Flink)的运行状态监控
- 微服务注册中心(Nacos)、网关、配置中心的维护
- 数据库实例的运维(MySQL/Oracle/达梦/人大金仓)
- 集成接口的连通性监控和异常处理
- 平台版本的升级和补丁部署
三组之间的协作遵循明确的事件升级路径:业务运维接到问题后进行初步分类,系统级问题转交系统运维,平台级问题转交平台运维。重大问题由三组联合响应。
日常巡检体系:日/周/月三级制度
巡检是运维的第一道防线。在国网项目中,巡检制度被严格量化为三个层级:
日巡检(每日 9:20 前提交)
日巡检覆盖最基础、最高频的检查项,要求在每个工作日上午 9:20 之前完成并提交日巡检表。核心检查内容包括:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
# 检查Nacos服务注册状态
curl -s http://nacos-server:8848/nacos/v1/ns/service/list?pageNo=1\&pageSize=100 | jq '.count'
# 检查各微服务进程是否存活
for svc in gateway auth data-service report-service ai-service; do
pid=$(pgrep -f "$svc" | head -1)
if [ -z "$pid" ]; then
echo "[ALERT] $svc is DOWN"
else
echo "[OK] $svc is running (PID: $pid)"
fi
done
# 检查HDFS存储空间使用率
hdfs dfs -du -h / | head -5
hdfs dfsadmin -report | grep "DFS Used%"
# 检查关键目录日志是否有ERROR
grep -c "ERROR" /data/logs/data-service/$(date +%Y-%m-%d).log
grep -c "ERROR" /data/logs/gateway/$(date +%Y-%m-%d).log
|
周巡检(每周五 17:00 前提交)
周巡检在日巡检基础上增加趋势分析和容量评估:
- 本周服务可用性统计(目标 ≥ 99.9%)
- 数据库连接池使用率趋势
- HDFS 存储增长趋势和预计可用天数
- Kafka 消费 lag 趋势
- 本周告警统计和 Top 5 告警分析
- 待处理问题清单和跟进计划
月分析报告(每月最后一个工作日提交)
月度报告是最高层级的巡检产出,内容包括:
- 月度 SLA 达成情况(可用性、响应时间、数据延迟)
- 容量规划建议(存储、计算、网络)
- 故障统计与根因分析
- 性能优化建议
- 下月运维重点计划
- 系统变更和版本升级记录
巡检检查清单
以下是数据中台日常巡检的核心检查项汇总:
| 检查类别 |
检查项 |
检查方法 |
正常标准 |
异常处理 |
| 服务注册 |
Nacos 服务列表数量 |
REST API 查询 |
与基线一致 |
检查未注册服务日志 |
| 服务注册 |
服务健康实例比例 |
Nacos 控制台 |
100% 健康 |
重启异常实例 |
| 进程状态 |
微服务进程存活 |
pgrep / systemctl |
全部存活 |
按 SOP 重启 |
| 内存使用 |
JVM 堆内存使用率 |
JMX / Arthas |
< 80% |
调整 -Xmx 参数 |
| 内存使用 |
系统内存使用率 |
free -h |
< 85% |
排查内存泄漏 |
| 数据库 |
连接池活跃连接数 |
数据库管理视图 |
< 连接池上限 70% |
排查慢 SQL |
| 数据库 |
慢查询数量 |
慢查询日志 |
0 条新增 |
分析并优化 SQL |
| 大数据 |
HDFS 使用率 |
hdfs dfsadmin -report |
< 80% |
清理过期数据/扩容 |
| 大数据 |
YARN 队列利用率 |
YARN ResourceManager UI |
< 90% |
调整资源配额 |
| 大数据 |
Hive Metastore 状态 |
systemctl status hive-metastore |
Active |
重启 Metastore |
| 消息队列 |
Kafka 消费 Lag |
kafka-consumer-groups.sh |
< 1000 |
增加消费者/优化处理 |
| 消息队列 |
Kafka Broker 状态 |
kafka-broker-api-versions.sh |
全部在线 |
检查 Broker 日志 |
| 日志 |
ERROR 日志数量 |
grep -c "ERROR" |
较昨日无激增 |
分析异常堆栈 |
| 接口 |
集成接口连通性 |
HTTP 健康检查 |
200 OK |
检查网络/服务状态 |
| 备份 |
数据库备份完成状态 |
备份日志/文件时间戳 |
当日备份存在 |
手动触发备份 |
监控告警设计
关键监控指标
数据中台的监控体系需要覆盖四个层面:
基础设施层:CPU 使用率、内存使用率、磁盘 IO、网络流量、磁盘空间
平台组件层:Hadoop NameNode/DataNode 状态、Hive Metastore 可用性、Kafka Broker 存活、Nacos 服务注册数
应用服务层:服务可用性(HTTP 状态码)、接口响应时间(P50/P95/P99)、QPS、错误率
数据链路层:数据同步延迟、ETL 任务完成时间、数据质量校验通过率、数据产出时效性
告警分级标准
| 告警等级 |
定义 |
响应时间 |
通知方式 |
典型场景 |
| P0 - 致命 |
核心业务完全不可用 |
5 分钟内响应 |
电话 + 短信 + 群通知 |
HDFS NameNode 宕机、核心数据库不可连接 |
| P1 - 严重 |
核心功能降级或部分不可用 |
15 分钟内响应 |
短信 + 群通知 |
30% 以上微服务不可用、Kafka 集群半数 Broker 离线 |
| P2 - 一般 |
非核心功能异常 |
30 分钟内响应 |
群通知 + 工单 |
单个非核心服务异常、消费 Lag 持续增长 |
| P3 - 提醒 |
潜在风险,暂无业务影响 |
4 小时内响应 |
工单 |
磁盘使用率超过 70%、证书即将过期 |
| P4 - 信息 |
状态变更通知 |
下一工作日处理 |
邮件 |
计划内维护通知、配置变更记录 |
告警抑制与收敛
在实际运维中,一个底层故障往往触发大量关联告警。为避免告警风暴,需要设计合理的抑制策略:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
# Prometheus Alertmanager 告警抑制配置示例
inhibit_rules:
# 当 NameNode 宕机时,抑制所有 HDFS 相关告警
- source_matchers:
- alertname = "NameNodeDown"
target_matchers:
- severity =~ "P2|P3"
- component = "hdfs"
equal: ['cluster']
# 当数据库不可达时,抑制该库所有连接相关告警
- source_matchers:
- alertname = "DatabaseUnreachable"
target_matchers:
- alertname =~ "SlowQuery|ConnectionPoolExhausted"
equal: ['instance']
|
故障处理 SOP
故障处理的核心原则是"先恢复、后定位、再复盘"。以下是标准化的故障处理流程:
| 阶段 |
步骤 |
操作内容 |
责任人 |
产出物 |
| 发现 |
1. 告警触发 |
监控系统自动告警或用户反馈 |
值班人员 |
故障工单创建 |
| 发现 |
2. 初步确认 |
确认告警真实性,排除误报 |
值班人员 |
故障等级初判 |
| 定位 |
3. 影响评估 |
确认影响范围和业务受损程度 |
业务运维 |
影响评估报告 |
| 定位 |
4. 根因定位 |
查看日志、监控、链路追踪 |
平台运维 |
根因初步判断 |
| 修复 |
5. 应急恢复 |
执行预案恢复服务(重启/切换/降级) |
平台运维 |
服务恢复确认 |
| 修复 |
6. 根因修复 |
针对根因进行代码/配置修复 |
开发团队 |
修复补丁 |
| 复盘 |
7. 故障复盘 |
时间线梳理、根因分析、改进措施 |
全体参与人 |
故障复盘报告 |
| 复盘 |
8. 改进落地 |
落实改进项,更新预案 |
平台运维 |
改进项跟踪表 |
常用故障排查命令
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
# 查看微服务最近500行日志并过滤ERROR
tail -n 500 /data/logs/data-service/application.log | grep -A 20 "ERROR"
# 查看Nacos注册中心日志
tail -f /data/nacos/logs/nacos.log
# 检查数据库连接状态(MySQL)
mysql -e "SHOW PROCESSLIST;" | awk '{print $1, $2, $3, $4, $5, $6, $7}' | sort -k6 -rn | head -20
# 检查Oracle活跃会话
sqlplus / as sysdba <<EOF
SELECT s.sid, s.serial#, s.username, s.status, s.machine, s.program
FROM v\$session s WHERE s.status = 'ACTIVE' AND s.type != 'BACKGROUND';
EOF
# 查看Kafka消费组Lag
kafka-consumer-groups.sh --bootstrap-server kafka-broker:9092 \
--describe --group data-consumer-group
# 查看Hive正在执行的任务
hive -e "SHOW INSTANCES;"
# JVM内存实时查看(使用Arthas)
java -jar arthas-boot.jar <PID>
# 进入Arthas后执行:
# memory -- 查看内存分配
# dashboard -- 实时面板
# thread -n 5 -- CPU最高的5个线程
|
Nacos 服务健康检查自动化
Nacos 作为微服务注册中心,其服务注册状态是巡检的核心指标之一。以下是一个完整的健康检查脚本:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
|
#!/bin/bash
# nacos_health_check.sh - Nacos服务健康检查脚本
# 用法: ./nacos_health_check.sh [nacos_addr] [namespace]
NACOS_ADDR=${1:-"http://nacos-server:8848"}
NAMESPACE=${2:-"public"}
EXPECTED_SERVICES=${3:-42} # 预期注册服务数量基线
ALERT_WEBHOOK="https://hooks.dingtalk.com/xxx"
TIMESTAMP=$(date "+%Y-%m-%d %H:%M:%S")
echo "=========================================="
echo "Nacos Health Check - $TIMESTAMP"
echo "=========================================="
# 1. 检查Nacos自身可用性
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" "$NACOS_ADDR/nacos/v1/ns/operator/servers")
if [ "$HTTP_CODE" != "200" ]; then
echo "[CRITICAL] Nacos server is unreachable (HTTP $HTTP_CODE)"
exit 1
fi
echo "[OK] Nacos server is reachable"
# 2. 获取已注册服务列表
SERVICE_LIST=$(curl -s "$NACOS_ADDR/nacos/v1/ns/service/list?pageNo=1&pageSize=200&namespaceId=$NAMESPACE")
SERVICE_COUNT=$(echo "$SERVICE_LIST" | jq -r '.count')
echo "[INFO] Registered services: $SERVICE_COUNT (baseline: $EXPECTED_SERVICES)"
if [ "$SERVICE_COUNT" -lt "$EXPECTED_SERVICES" ]; then
echo "[WARNING] Service count below baseline! Missing: $((EXPECTED_SERVICES - SERVICE_COUNT))"
fi
# 3. 逐服务检查健康实例
UNHEALTHY_SERVICES=()
for svc in $(echo "$SERVICE_LIST" | jq -r '.doms[]'); do
INSTANCES=$(curl -s "$NACOS_ADDR/nacos/v1/ns/instance/list?serviceName=$svc&namespaceId=$NAMESPACE")
TOTAL=$(echo "$INSTANCES" | jq '.hosts | length')
HEALTHY=$(echo "$INSTANCES" | jq '[.hosts[] | select(.healthy == true)] | length')
if [ "$HEALTHY" -lt "$TOTAL" ]; then
UNHEALTHY_SERVICES+=("$svc ($HEALTHY/$TOTAL healthy)")
echo "[WARNING] $svc: $HEALTHY/$TOTAL instances healthy"
fi
done
# 4. 输出汇总
if [ ${#UNHEALTHY_SERVICES[@]} -eq 0 ]; then
echo "[OK] All services have healthy instances"
else
echo ""
echo "=== UNHEALTHY SERVICES ==="
for svc in "${UNHEALTHY_SERVICES[@]}"; do
echo " - $svc"
done
# 发送告警
curl -s -X POST "$ALERT_WEBHOOK" \
-H "Content-Type: application/json" \
-d "{\"msgtype\":\"text\",\"text\":{\"content\":\"[Nacos告警] 以下服务存在不健康实例:\n$(printf '%s\n' "${UNHEALTHY_SERVICES[@]}")\"}}"
fi
echo "=========================================="
echo "Check completed at $(date '+%Y-%m-%d %H:%M:%S')"
|
将此脚本配置为定时任务,每日 9:00 自动执行,结果写入巡检日志:
1
2
|
# crontab 配置
0 9 * * 1-5 /opt/scripts/nacos_health_check.sh >> /data/logs/inspection/nacos_$(date +\%Y\%m\%d).log 2>&1
|
故障自愈探索
自动化恢复策略
故障自愈的核心思想是将已知的、高频出现的故障模式固化为自动化恢复脚本,在故障发生时自动触发,无需人工干预。
常见的自愈策略包括:
服务重启自愈:当检测到微服务进程消失或健康检查失败超过阈值时,自动触发服务重启。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
# systemd 服务自愈配置示例
# /etc/systemd/system/data-service.service
[Unit]
Description=Data Service
After=network.target nacos.service
[Service]
Type=simple
ExecStart=/opt/data-service/bin/start.sh
Restart=always
RestartSec=10
StartLimitBurst=3
StartLimitInterval=300
# 5分钟内最多重启3次,防止无限重启
[Install]
WantedBy=multi-user.target
|
连接池自愈:当数据库连接池耗尽时,自动释放空闲连接并重建连接池。
磁盘空间自愈:当磁盘使用率超过阈值时,自动清理过期日志和临时文件。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
#!/bin/bash
# disk_auto_heal.sh - 磁盘空间自愈脚本
THRESHOLD=85
LOG_RETAIN_DAYS=7
USAGE=$(df -h /data | awk 'NR==2{print $5}' | tr -d '%')
if [ "$USAGE" -gt "$THRESHOLD" ]; then
echo "[AUTO-HEAL] Disk usage ${USAGE}% > ${THRESHOLD}%, triggering cleanup..."
# 清理过期日志
find /data/logs -name "*.log" -mtime +$LOG_RETAIN_DAYS -delete
find /data/logs -name "*.log.gz" -mtime +30 -delete
# 清理Hive临时文件
hdfs dfs -rm -r /tmp/hive/* 2>/dev/null
# 清理YARN应用日志
yarn logs -applicationId ALL 2>/dev/null | head -1
hdfs dfs -rm -r /app-logs/*/logs/* 2>/dev/null
NEW_USAGE=$(df -h /data | awk 'NR==2{print $5}' | tr -d '%')
echo "[AUTO-HEAL] Disk usage after cleanup: ${NEW_USAGE}%"
fi
|
AI 运维 Agent 辅助诊断
随着大语言模型在运维领域的应用,AI 运维 Agent 正在成为故障诊断的有力辅助工具。SREWorks、SRE-Copilot 等平台的实践表明,AI Agent 在以下场景中可以显著提升效率:
日志智能分析:将异常日志片段输入 AI Agent,自动识别错误模式、关联历史故障、推荐处理方案。相比人工逐行阅读堆栈信息,AI Agent 可以在秒级完成初步分析。
根因推断:在复杂的多组件故障场景中,AI Agent 可以综合分析多个组件的日志、指标和变更记录,推断最可能的根因节点。
变更风险评估:在执行配置变更或版本升级前,AI Agent 可以评估变更的影响范围和潜在风险,给出风险等级和回滚建议。
运维知识检索:将历史故障复盘报告、运维手册、组件文档等构建为知识库,AI Agent 可以作为运维人员的智能助手,快速检索相关知识和最佳实践。
蚂蚁集团在其 SRE 实践中引入了"故障演练 + AI 辅助诊断"的模式:定期通过混沌工程注入故障,训练 AI Agent 识别故障模式,逐步扩大自愈覆盖面。美图 SRE 团队则通过构建故障知识图谱,将故障现象、根因和处置方案结构化关联,使 AI Agent 的诊断准确率从初期的 45% 提升至 78%。
数据库运维要点:多数据库环境的差异化运维
在国产化替代的大背景下,数据中台往往需要同时支持多种数据库。不同数据库在运维操作上存在显著差异:
各数据库运维差异对比
| 运维维度 |
MySQL 8.0.27 |
达梦 DM7/DM8 |
Oracle 12c |
人大金仓 KingbaseES |
| 连接方式 |
mysql -h host -P 3306 |
disql SYSDBA/password |
sqlplus user/pass@tns |
ksql -U system -d dbname |
| 配置文件 |
my.cnf |
dm.ini |
init.ora / spfile |
kingbase.conf |
| 慢查询日志 |
slow_query_log=ON |
SVR_LOG 参数 |
AWR/ASH 报告 |
log_min_duration_statement |
| 备份工具 |
mysqldump / xtrabackup |
dexp / 物理备份 |
expdp / RMAN |
kdump / 物理备份 |
| 字符集 |
utf8mb4 |
UTF-8 |
AL32UTF8 |
UTF8 |
| 最大连接数 |
max_connections |
MAX_SESSIONS |
processes |
max_connections |
| 连接池推荐 |
HikariCP / Druid |
Druid(达梦适配版) |
UCP / HikariCP |
HikariCP |
| 分页语法 |
LIMIT offset, count |
LIMIT count OFFSET offset |
ROWNUM / FETCH FIRST |
LIMIT count OFFSET offset |
| 序列 |
AUTO_INCREMENT |
IDENTITY / SEQUENCE |
SEQUENCE |
SEQUENCE / SERIAL |
| 事务隔离 |
默认 RR |
默认 RC |
默认 RC |
默认 RC |
多数据库环境下的常见问题与处理
数据源注册失败:在数据中台中添加数据源时,连接测试失败是最常见的问题之一。排查步骤如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
# 1. 网络连通性检查
telnet db-host 3306 # MySQL
telnet db-host 5236 # 达梦
telnet db-host 1521 # Oracle
telnet db-host 54321 # 人大金仓
# 2. 数据库用户权限验证
# MySQL
mysql -h db-host -u data_platform -p -e "SHOW GRANTS;"
# 达梦
disql SYSDBA/password@db-host:5236 -e "SELECT * FROM DBA_ROLE_PRIVS WHERE GRANTEE='DATA_PLATFORM';"
# 3. 驱动版本兼容性检查
# 确认JDBC驱动版本与数据库版本匹配
# MySQL Connector/J 8.0.x → MySQL 8.0.x
# DM JDBC Driver → 对应DM7/DM8版本
# ojdbc8.jar → Oracle 12c+
# kingbase8-8.6.0.jar → KingbaseES V8
|
序列号/许可证问题:部分国产数据库(达梦、人大金仓)采用许可证授权机制,过期后服务将受限。需要在巡检中加入许可证有效期检查:
1
2
3
4
5
|
# 达梦许可证到期检查
disql SYSDBA/password -e "SELECT EXPIRED_DATE FROM V\$LICENSE;"
# 人大金仓许可证检查
ksql -U system -d dbname -c "SELECT * FROM sys_license_info();"
|
服务启动内存调优:数据中台各组件的 JVM 内存参数需要根据实际负载进行调优,避免 OOM 或资源浪费:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
# 微服务JVM参数推荐配置
# 轻量服务(网关、认证服务)
JAVA_OPTS="-Xms512m -Xmx1024m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m"
# 中等服务(数据服务、报表服务)
JAVA_OPTS="-Xms1024m -Xmx2048m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m -XX:+UseG1GC"
# 重型服务(AI推理服务、BI分析服务)
JAVA_OPTS="-Xms2048m -Xmx4096m -XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=1024m -XX:+UseG1GC -XX:MaxGCPauseMillis=200"
# 大数据组件(Spark Driver)
SPARK_DRIVER_MEMORY="4g"
SPARK_EXECUTOR_MEMORY="8g"
SPARK_EXECUTOR_CORES=4
|
SSH 连接配置与远程运维
在分布式部署的数据中台环境中,运维人员需要通过 SSH 连接到多台服务器执行操作。规范的 SSH 配置可以提升运维效率和安全性:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
# ~/.ssh/config - SSH连接配置示例
Host nacos-server
HostName 192.168.1.101
User ops
Port 22
IdentityFile ~/.ssh/id_rsa_ops
ConnectTimeout 10
ServerAliveInterval 60
ServerAliveCountMax 3
Host hadoop-nn
HostName 192.168.1.110
User hdfs
Port 22
IdentityFile ~/.ssh/id_rsa_ops
Host hadoop-dn-*
HostName 192.168.1.%h
User hdfs
Port 22
IdentityFile ~/.ssh/id_rsa_ops
# 批量检查集群节点状态
for i in $(seq 110 120); do
echo -n "192.168.1.$i: "
ssh -o ConnectTimeout=5 hdfs@192.168.1.$i "uptime" 2>/dev/null || echo "UNREACHABLE"
done
|
大数据集群运维要点
对于 Hadoop + Hive + Spark 组成的大数据集群,运维重点集中在以下方面:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
# HDFS健康状态检查
hdfs fsck / -files -blocks -locations 2>/dev/null | tail -20
# 查看HDFS各目录空间占用
hdfs dfs -du -h -s /user /tmp /data /app-logs 2>/dev/null
# YARN资源使用概览
yarn top -delay 5 2>/dev/null | head -30
# Spark历史任务状态
curl -s http://spark-history-server:18080/api/v1/applications?status=completed\&limit=10 | jq '.[].name'
# Hive Metastore数据库检查
mysql -e "SELECT COUNT(*) as table_count FROM TBLS;" metastore_db
mysql -e "SELECT COUNT(*) as partition_count FROM PARTITIONS;" metastore_db
# 检查NameNode HA状态
hdfs haadmin -getAllServiceState
# Expected: One active, one standby
|
故障复盘模板
每次故障处理完成后,应在 48 小时内完成故障复盘。复盘报告的标准结构如下:
| 复盘维度 |
内容要求 |
| 故障时间线 |
精确到分钟的事件时间线:发现时间 → 响应时间 → 定位时间 → 恢复时间 → 确认时间 |
| 影响范围 |
受影响的业务、用户数、持续时间、数据损失 |
| 根因分析 |
使用"5 Whys"方法逐层追溯,直至找到可改进的系统性原因 |
| 处置过程 |
详细记录每一步操作和决策依据 |
| 做得好的 |
哪些环节表现优秀,值得固化为标准流程 |
| 待改进的 |
哪些环节可以优化,包括监控覆盖、告警规则、应急预案、工具能力 |
| 改进项 |
具体的 Action Item,指定责任人和完成时间 |
| 预案更新 |
根据本次故障经验更新应急预案和自愈策略 |
运维工具链推荐
构建高效的运维体系,离不开合适的工具链支撑:
| 工具类别 |
推荐工具 |
用途 |
| 监控采集 |
Prometheus + Grafana |
指标采集和可视化 |
| 日志平台 |
ELK (Elasticsearch + Logstash + Kibana) |
集中式日志采集和检索 |
| 链路追踪 |
SkyWalking / Jaeger |
分布式调用链追踪 |
| 告警管理 |
Alertmanager / PagerDuty |
告警路由、分组和抑制 |
| 自动化运维 |
Ansible / SaltStack |
批量配置管理和任务执行 |
| 混沌工程 |
ChaosBlade / Litmus |
故障注入和韧性测试 |
| AI 运维 |
SREWorks / SRE-Copilot |
智能诊断和知识检索 |
| 巡检管理 |
自研巡检平台 |
巡检任务调度和报告生成 |
结语
数据中台运维是一项需要体系化建设的工程。从组织架构的三组协作,到日/周/月三级巡检制度,再到监控告警、故障处理 SOP 和故障自愈,每一个环节都是运维体系中不可或缺的组成部分。
关键的经验教训可以总结为几点:巡检制度必须量化并严格执行(如每日 9:20 提交日巡检表),告警需要合理分级避免风暴,故障处理必须遵循"先恢复后定位再复盘"的原则,多数据库环境需要建立差异化的运维手册,而故障自愈则是运维自动化的终极目标——通过将高频故障模式固化为自动化恢复脚本,逐步减少人工干预,最终实现运维效率的质变。
运维的本质不是救火,而是通过工程化手段让系统越来越不需要救火。每一次故障都是完善运维体系的机会,每一次复盘都是向故障自愈迈进的一步。