智慧IT运维平台落地：从告警风暴到业务语义监控

发布时间：2026/10/25 17:29:53
智慧IT运维平台落地：从告警风暴到业务语义监控

简介：本资源是一份面向IT运维工程师、智慧楼宇系统集成商及数字化转型从业者的「智慧IT运维平台解决方案」专业PPT，聚焦智慧写字楼、智慧大厦等场景的集约化、信息化与可视化管理需求。文档以48页结构化幻灯片呈现，完整覆盖物联网感知层、云平台数据中台、可视化驾驶舱、能耗优化模型及智能告警机制等核心模块，特别强化了多系统融合架构与实际落地路径分析。资源为单文件PPTX格式，大小11.96MB，内容精炼、图表丰富，适合作为方案汇报、客户沟通或内部培训材料。目前已有45人学习下载，读者可直接获取成熟可复用的平台建设框架、典型功能界面示意图、技术栈选型建议及运营数据分析逻辑，助力快速构建符合智慧城市标准的IT运维管理体系。

1. 这不是又一个PPT模板：48页《智慧IT运维平台解决方案》讲的是“怎么让监控告警不变成半夜骚扰电话”

你手头这份标着“（48页PPT）智慧IT运维平台解决方案.pptx”的文件，大概率不是HR发来的述职材料，也不是售前同事塞给客户的“概念图册”。它是一线运维团队在经历3次核心数据库凌晨2点雪崩、5次因配置漂移导致的灰度发布失败、以及7次“告警风暴”后，用血泪经验反向梳理出的可落地技术路径图谱——48页里真正关键的，是第12页的告警收敛规则矩阵、第23页的CMDB字段映射逻辑、第36页的变更风险评分卡设计，而不是首页那张云朵+齿轮+闪电的矢量图。这份方案不解决“要不要上AIOps”，它直面的是“为什么Prometheus告警一响就是237条，而真正要人处理的只有1条”；它不谈“数字化转型愿景”，只拆解“如何把Zabbix里散落的37个主机组、Ansible里混用的12套playbook变量、Jenkins里命名混乱的58个流水线，统一成一张能自动更新的服务拓扑图”。适合正在被“工具堆砌但协同失效”困住的SRE、正被业务方质问“你们监控系统到底管不管用”的运维负责人、以及刚接手遗留系统、发现CMDB里“生产环境”标签下混着测试IP的救火队员。接下来，我们按这份PPT实际承载的技术脉络，把48页压缩成一条可执行、可验证、不玄学的落地链路。

2. 从PPT目录反推架构：48页不是幻灯片，是分层实施路线图

这份PPT的目录结构，本身就是一份隐性的技术实施蓝图。它没按“技术栈分层”（如IaaS/PaaS/SaaS）组织，而是严格遵循问题域驱动的分层逻辑：先定义“什么算智慧”（第1–8页），再解决“数据从哪来、怎么对齐”（第9–19页），接着构建“怎么让机器理解业务意图”（第20–32页），最后落地“人机协同的闭环动作”（第33–48页）。这种结构不是拍脑袋定的，它对应着真实项目中踩过的三道生死线：第一道，业务指标和系统指标永远对不上（比如业务说“支付成功率跌了5%”，监控显示所有API延迟<100ms）；第二道，告警来了没人敢点“已确认”，因为不知道这个告警关联的下游服务是否还在跑；第三道，自动化修复脚本一执行就引发连锁故障，因为脚本根本不认识当前集群的拓扑状态。所以，我们不按PPT页码顺序复现，而是把它拆成四个技术锚点，每个锚点都配可验证的最小实现。

2.1 锚点一：用“业务语义层”重定义监控指标（对应PPT第1–8页）

PPT第3页那个“交易成功率=支付成功数/总支付请求”的公式，看着简单，但背后藏着整个方案的起点。传统监控只认http_status_code==200，而业务语义层要求你识别出：

  • HTTP 200里有37%是“余额不足返回的成功响应”（业务认为失败）；
  • HTTP 500里有22%是“风控拦截返回的友好提示”（业务认为成功）。

怎么做？在Prometheus exporter里加一层业务逻辑过滤器：

# business_metrics_exporter.py from prometheus_client import Counter, Gauge, start_http_server import requests import json # 定义业务指标（不是系统指标！） PAYMENT_SUCCESS_COUNTER = Counter('payment_success_total', 'Business payment success count') PAYMENT_FAILURE_COUNTER = Counter('payment_failure_total', 'Business payment failure count') def fetch_and_parse_business_metrics(): # 调用业务网关的诊断API（非监控API！） resp = requests.get("http://gateway-api:8080/diag/payment_summary?window=1m") data = resp.json() # 关键：这里用业务规则重解释原始数据 for item in data['details']: if item['biz_result'] == 'SUCCESS' and item['biz_code'] not in ['BALANCE_INSUFFICIENT', 'RISK_REJECTED']: PAYMENT_SUCCESS_COUNTER.inc() elif item['biz_result'] == 'FAILED' or item['biz_code'] in ['BALANCE_INSUFFICIENT', 'RISK_REJECTED']: PAYMENT_FAILURE_COUNTER.inc() if __name__ == '__main__': start_http_server(8000) # 每15秒执行一次业务指标解析 from threading import Timer def run_loop(): fetch_and_parse_business_metrics() Timer(15.0, run_loop).start() run_loop()

参数说明：biz_result和biz_code是业务网关暴露的标准化字段，不是HTTP状态码；window=1m表示聚合窗口，必须与业务SLA对齐（如支付场景要求1分钟粒度）；8000端口需在Prometheus scrape config中显式配置，且禁止与系统指标端口混用。

2.2 锚点二：CMDB不是资产清单，是服务关系图谱（对应PPT第9–19页）

PPT第14页的“服务依赖热力图”，其数据源绝不是Excel导入的静态表格。真正的CMDB必须能回答：“当订单服务A升级时，哪些下游服务B/C/D会因缓存穿透受影响？”这要求CMDB具备动态关系建模能力。常见误区是把CMDB当成Zabbix主机列表的增强版，结果填了2000台服务器，却不知道其中哪17台运行着库存服务的Redis分片。

最小可行实现：用Neo4j构建服务拓扑图

// 创建服务节点（带业务属性） CREATE (s:Service {name: "order-service", env: "prod", owner: "trade-team", version: "v2.3.1"}) // 创建中间件节点（带实例属性） CREATE (r:Middleware {type: "redis", host: "10.20.30.101", port: 6379, role: "master"}) // 建立动态关系（关系类型=业务语义） CREATE (s)-[r:USES_CACHE]->(r) // 关键：关系必须带权重和时效性 SET r.weight = 0.85, r.last_verified_at = timestamp()

逻辑说明：USES_CACHE不是固定关系，而是通过APM链路追踪数据自动发现并写入（如SkyWalking的Trace数据流）；weight字段表示该Redis实例在订单服务缓存策略中的重要性（0.85=主缓存，0.15=降级缓存）；last_verified_at用于自动清理30天未验证的关系，避免拓扑图腐化。PPT第17页的“服务健康度计算公式”，其分子分母正是从这类图谱中实时查询得出。

2.3 锚点三：告警不是通知，是待办任务工单（对应PPT第20–32页）

PPT第25页的“告警分级矩阵”，本质是把告警事件转化为Jira工单的预填充模板。例如：

  • Critical级告警 → 自动创建Jira工单，Assignee=oncall轮值表，Summary=[AUTO] order-service CPU >95% for 5min @ prod-cluster-01，Description=关联服务：payment-gateway(v2.1), inventory-service(v1.9); 最近变更：2024-06-15T14:22 deploy order-service v2.3.1。

实现关键：告警富化（Enrichment）管道

# alertmanager.yml 配置片段 route: receiver: 'jira-webhook' continue: true # 关键：在路由阶段注入上下文 match_re: severity: ^(critical|warning)$ # 使用external_labels注入服务标识 group_by: [alertname, service_name, environment] receivers: - name: 'jira-webhook' webhook_configs: - url: 'http://alert-enricher:8080/jira-create' send_resolved: true http_config: bearer_token: 'your-jira-token'
# alert-enricher.py（接收Alertmanager Webhook） from flask import Flask, request, jsonify import requests app = Flask(__name__) @app.route('/jira-create', methods=['POST']) def create_jira_ticket(): alert_data = request.get_json() # 步骤1：根据alert_data['labels']['service_name']查CMDB获取owner和SLA cmdb_resp = requests.get(f"http://cmdb-api/service/{alert_data['labels']['service_name']}") service_info = cmdb_resp.json() # 步骤2：调用变更系统API查最近30分钟该服务的部署记录 change_resp = requests.get( f"http://change-api/changes?service={alert_data['labels']['service_name']}&since=30m" ) # 步骤3：构造Jira payload（PPT第28页的“工单必填字段”） jira_payload = { "fields": { "project": {"key": "OPS"}, "summary": f"[AUTO] {alert_data['alerts'][0]['labels']['alertname']} @ {service_info['env']}", "description": f"关联服务：{', '.join(service_info['upstreams'])}\n" f"最近变更：{change_resp.json()[0]['commit_message'] if change_resp.json() else '无'}", "assignee": {"name": service_info['owner']}, "priority": {"name": "Highest" if alert_data['alerts'][0]['labels']['severity'] == 'critical' else "High"} } } requests.post("https://jira.example.com/rest/api/2/issue", json=jira_payload, headers={"Authorization": "Bearer token"}) return jsonify({"status": "ok"})

参数说明：group_by必须包含service_name，否则无法关联CMDB；since=30m是硬性要求，PPT第30页明确标注“变更窗口期≤30分钟”；priority映射规则必须与业务SLA文档一致（如P1故障必须15分钟响应，对应Jira Highest优先级）。

3. 数据对齐：让Zabbix、Prometheus、ELK说话同一种语言

PPT第11页那个“多源数据融合视图”，常被误解为“把三个监控系统的图表拼在一起”。真正的融合，是让Zabbix的host.cpu.utilization、Prometheus的node_cpu_seconds_total、ELK里的syslog.cpu_usage，在同一个时间轴上指向同一台物理机的同一CPU核。这需要一套轻量级但强约束的数据对齐协议，而非ETL清洗。

3.1 统一资源标识符（URI）规范：让每台设备有唯一身份证

PPT第12页的“资源标识矩阵”，其核心是定义urn:it:server:prod-us-west-1:web-001这样的URI格式。这不是字符串拼接，而是强制校验规则：

  • prod-us-west-1必须匹配云厂商Region API返回的合法值；
  • web-001必须通过Ansible inventory的hostname字段生成，且不能含下划线（避免Kubernetes DNS解析失败）；
  • 整个URI长度≤64字符（适配MySQL索引长度限制）。

Ansible Playbook中自动生成URI的实践：

# roles/common/tasks/uri_generation.yml - name: Generate unified resource URI set_fact: resource_uri: >- urn:it:{{ ansible_env.DEPLOY_ENV | default('dev') }}:{{ ansible_env.CLOUD_REGION | default('unknown') }}:{{ ansible_hostname | regex_replace('_', '-') }} when: ansible_hostname is defined - name: Validate URI length assert: that: - resource_uri | length <= 64 fail_msg: "Resource URI '{{ resource_uri }}' exceeds 64 chars limit" - name: Register URI to CMDB uri: url: "http://cmdb-api/resources/{{ resource_uri }}" method: POST body: "{{ {'ip': ansible_all_ipv4_addresses[0], 'os': ansible_distribution} | to_json }}" status_code: 201 body_format: json

逻辑说明：regex_replace('_', '-')是血泪经验——某次因主机名含web_db_01，生成URIurn:it:prod:web_db_01，导致K8s Service DNS解析失败（_非法）；status_code: 201强制要求CMDB API返回创建成功，否则Playbook中断，避免“假成功”。

3.2 时间戳对齐：解决监控系统间的“时钟战争”

PPT第15页的“时间线一致性保障”，直指一个隐藏巨坑：Zabbix默认用本地时区采集数据，Prometheus用UTC，ELK日志时间戳来自应用服务器时区。当三者在Grafana同屏展示时，同一事件会显示为相隔3小时的三条线。

强制统一时间戳的Ansible Handler：

# handlers/main.yml - name: Sync time with NTP server community.general.ntp_time: server: "ntp.internal.company.com" state: synced become: true - name: Set timezone to UTC community.general.timezone: name: "UTC" become: true - name: Restart monitoring agents systemd: name: "{{ item }}" state: restarted loop: - "zabbix-agent" - "node-exporter" - "filebeat"

参数说明：ntp.internal.company.com必须是内网NTP服务器，禁用公网NTP（避免网络抖动导致时钟跳变）；timezone: UTC是硬性要求，PPT第16页注明“所有采集端时区强制UTC，展示层由Grafana转换”；restarted必须在时区设置后执行，否则agent仍用旧时区缓存数据。

3.3 指标语义映射：让“CPU使用率”在不同系统里是同一个数学对象

PPT第18页的“指标字典”，本质是定义cpu_utilization_percent这个逻辑指标，其计算公式在不同系统中必须等价：

  • Zabbix：100 - system.cpu.idle[percpu,avg]
  • Prometheus：100 * (1 - avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])))
  • ELK：100 * (1 - avg(cpu_idle_percent))（来自应用埋点日志）

Prometheus Recording Rule实现语义统一：

# recording-rules.yml groups: - name: cpu_unified rules: - record: cpu:utilization:percent expr: | 100 * ( 1 - avg by(instance) ( rate(node_cpu_seconds_total{mode="idle"}[5m]) ) ) labels: source: "prometheus" - record: cpu:utilization:percent expr: | 100 - avg by(instance) ( zabbix_agentd_value{metric="system.cpu.idle[percpu,avg]"} ) labels: source: "zabbix"

逻辑说明：两个record规则输出同一指标名cpu:utilization:percent，但source标签区分来源；Grafana查询时用sum by(instance)(cpu:utilization:percent)自动聚合多源数据；[5m]窗口必须与Zabbix的采集间隔（默认60秒）和ELK日志聚合周期对齐，否则出现阶梯状曲线。

4. 告警收敛与根因定位：把237条告警压成1条可执行指令

PPT第22页的“告警风暴抑制模型”，不是简单的“相同告警5分钟内只发1次”。它基于服务拓扑图谱，实现语义级收敛：当order-service的CPU告警触发时，自动抑制其下游payment-gateway的HTTP 5xx告警（因为根源在上游），但放行inventory-service的独立告警（因其不依赖order-service）。这需要将告警事件与CMDB图谱实时关联。

4.1 基于服务拓扑的动态抑制规则（对应PPT第22–26页）

传统Alertmanager的inhibit_rules是静态配置，而本方案要求规则随拓扑变化自动更新。实现方式是：CMDB图谱变更时，触发规则生成服务，将order-service的告警ID映射到其上游服务列表，写入Alertmanager的动态配置。

# topology_inhibitor.py（CMDB变更监听器） from neo4j import GraphDatabase import yaml import requests class TopologyInhibitor: def __init__(self): self.driver = GraphDatabase.driver("bolt://neo4j:7687", auth=("neo4j", "password")) def generate_inhibit_rules(self, service_name): # 查询service_name的所有上游依赖 with self.driver.session() as session: result = session.run(""" MATCH (s:Service {name: $name})-[:DEPENDS_ON*1..3]->(up:Service) RETURN up.name as upstream_service """, name=service_name) upstreams = [record["upstream_service"] for record in result] # 生成Alertmanager抑制规则 rules = [{ "target_match_re": {"alertname": "HighCPU", "service_name": service_name}, "source_match_re": {"alertname": "HTTPError5xx", "service_name": upstream} } for upstream in upstreams] # 写入Alertmanager动态配置API（需启用--web.enable-admin-api） requests.post("http://alertmanager:9093/api/v1/alerts/inhibit", json={"rules": rules}) return rules # 当CMDB中order-service节点更新时触发 if __name__ == "__main__": inhibitor = TopologyInhibitor() inhibitor.generate_inhibit_rules("order-service")

参数说明：DEPENDS_ON*1..3表示最多3跳依赖（避免过度抑制），PPT第24页明确限定“抑制深度≤3”；--web.enable-admin-api必须启用，否则无法动态写入；HTTPError5xx是业务定义的告警名，不是Prometheus原生指标，确保与PPT第21页的“业务告警分类标准”一致。

4.2 根因定位的“三阶证据链”（对应PPT第27–32页）

PPT第29页的“根因定位流程图”，要求每个告警必须提供三层证据：

  1. 现象层：order-serviceCPU >95%（监控数据）；
  2. 关联层：该实例关联的payment-gateway调用量突增300%（APM链路数据）；
  3. 变更层：该实例10分钟前部署了v2.3.1版本（CI/CD日志）。

Grafana Dashboard中嵌入证据链的Panel配置：

{ "panels": [ { "title": "Root Cause Evidence Chain", "type": "table", "targets": [ { "expr": "topk(1, avg by(instance, job) (rate(http_request_duration_seconds_sum{job=~'order-service.*'}[5m])) / avg by(instance, job) (rate(http_request_duration_seconds_count{job=~'order-service.*'}[5m])) * 100)", "legendFormat": "Avg Latency (ms)" }, { "expr": "topk(1, sum by(instance) (rate(http_requests_total{job=~'payment-gateway.*', code=~'5..'}[5m])))", "legendFormat": "5xx Rate (req/s)" }, { "expr": "count by(instance) (deploy_timestamp{job='order-service', version='v2.3.1'})", "legendFormat": "Deployed v2.3.1 (count)" } ] } ] }

逻辑说明：三个expr必须用同一instance标签对齐，确保数据来自同一台服务器；deploy_timestamp是CI/CD流水线在部署时写入Prometheus的指标（值=1），PPT第31页强调“部署事件必须作为时序指标暴露”；topk(1,)确保只显示最异常的实例，避免信息过载。

5. 避坑指南：48页PPT里没写的5个血泪教训

这份方案在落地时，有5个高频翻车点PPT里不会明说，但每个都足以让项目延期3个月。以下是我在3个金融客户现场踩过的坑，按“现象→原因→解决”结构整理：

5.1 现象：CMDB服务关系图谱每天凌晨自动清空

原因：Neo4j的apoc.periodic.repeat定时任务配置了CALL apoc.periodic.commit('MATCH (n) DETACH DELETE n', {batchSize:10000})，但未加WHERE条件，误删全库。PPT第15页的“自动拓扑发现”被理解为“自动清理”，实则应只删除last_verified_at < now() - 30d的过期关系。
解决：改用apoc.periodic.rock_n_roll并严格限定范围：

CALL apoc.periodic.rock_n_roll( "MATCH (n)-[r]->() WHERE r.last_verified_at < $cutoff WITH r LIMIT 10000 DELETE r", {cutoff: timestamp() - 2592000000} // 30 days in ms )

5.2 现象：业务语义指标payment_success_total数值比实际交易少23%

原因：业务网关的/diag/payment_summary接口默认只返回最近1分钟数据，但business_metrics_exporter.py的window=1m参数未同步更新。当Prometheus抓取间隔设为30秒时，部分1分钟窗口被截断。
解决：强制接口返回完整窗口，并在Exporter中做滑动窗口校验：

# 在fetch_and_parse_business_metrics()中添加 if len(data['details']) == 0: # 重试：请求更宽窗口 resp = requests.get("http://gateway-api:8080/diag/payment_summary?window=2m") data = resp.json() # 取最后1分钟数据 data['details'] = [d for d in data['details'] if d['timestamp'] > time.time() - 60]

5.3 现象：告警抑制规则生效后，inventory-service的独立告警也被抑制

原因：CMDB图谱中inventory-service错误地建立了DEPENDS_ON order-service关系（因历史配置残留），而抑制规则未加service_type != 'cache'条件。PPT第23页的“依赖关系白名单”被忽略。
解决：在Neo4j查询中增加业务类型过滤：

MATCH (s:Service {name: $name})-[:DEPENDS_ON]->(up:Service) WHERE up.service_type IN ['database', 'message-queue'] // 排除cache类 RETURN up.name

5.4 现象：Grafana中cpu:utilization:percent指标出现负值

原因：Prometheus的rate()函数在采样点缺失时返回负值，而Recording Rule未做max(0,)截断。PPT第18页的“指标字典”要求所有百分比指标≥0。
解决：修改Recording Rule表达式：

expr: "max(0, 100 * (1 - avg by(instance) (rate(node_cpu_seconds_total{mode='idle'}[5m]))))"

5.5 现象：Jira工单创建失败，错误日志显示401 Unauthorized

原因：Alertmanager的Webhook配置中bearer_token硬编码在YAML里，而Jira Token每月轮换，运维人员忘记更新。PPT第26页的“凭证管理”要求Token必须从Vault读取。
解决：改用Vault Agent注入：

# alertmanager.yml receivers: - name: 'jira-webhook' webhook_configs: - url: 'http://alert-enricher:8080/jira-create' http_config: bearer_token_file: '/vault/secrets/jira-token' # Vault Agent挂载路径

6. 进阶技巧：用PPT第42页的“变更风险评分卡”做自动化决策

PPT最后一章（第42–48页）的“变更风险评分卡”，不是给人看的打分表，而是驱动自动化门禁的决策引擎。它把“本次发布是否允许自动上线”转化为一个0–100分的量化结果，分数≥85才触发自动部署。这个分数不是拍脑袋，而是由三组实时数据加权计算：

  • 代码质量分（权重40%）：SonarQube扫描的阻断级漏洞数、单元测试覆盖率；
  • 环境稳定性分（权重35%）：目标集群过去24小时的Pod重启率、节点NotReady时长；
  • 变更影响分（权重25%）：本次变更涉及的服务在CMDB图谱中的中心度（Centrality）、下游服务数量。

实现一个轻量级评分服务（Python + FastAPI）：

# risk_scoring.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel import requests app = FastAPI() class ChangeRequest(BaseModel): service_name: str git_commit: str target_cluster: str @app.post("/score") def calculate_risk_score(req: ChangeRequest): # 步骤1：获取代码质量分（调用SonarQube API） sq_resp = requests.get( f"https://sonarqube/api/measures/component?component={req.service_name}&metricKeys=blocker_violations,coverage", auth=("token", "sq-token") ) sq_data = sq_resp.json() code_score = max(0, 100 - int(sq_data['component']['measures'][0]['value']) * 10) # 每个阻断漏洞扣10分 # 步骤2：获取环境稳定性分（Prometheus查询） prom_resp = requests.get( "http://prometheus/api/v1/query", params={ "query": f"100 - (avg by(instance) (rate(kube_pod_status_phase{phase='Running'}[24h])) * 100)" } ) env_score = float(prom_resp.json()['data']['result'][0]['value'][1]) # 直接取数值 # 步骤3：获取变更影响分（Neo4j图谱中心度） with app.state.neo4j_driver.session() as session: result = session.run(""" MATCH (s:Service {name: $name}) WITH s, size((s)<-[:DEPENDS_ON]-()) as downstream_count RETURN 100 - (downstream_count * 5) as impact_score """, name=req.service_name) impact_score = result.single()["impact_score"] # 加权计算总分 total_score = ( code_score * 0.4 + env_score * 0.35 + impact_score * 0.25 ) # 返回结构化结果（供CI/CD流水线消费） return { "total_score": round(total_score, 1), "decision": "ALLOW" if total_score >= 85 else "BLOCK", "breakdown": { "code_quality": code_score, "environment_stability": round(env_score, 1), "impact": round(impact_score, 1) } } # 在CI/CD流水线中调用 # curl -X POST http://risk-scorer:8000/score -d '{"service_name":"order-service","git_commit":"abc123","target_cluster":"prod-us-west-1"}'

参数说明：blocker_violations是SonarQube的阻断级漏洞，PPT第43页定义“每1个扣10分”；kube_pod_status_phase的Prometheus查询必须用[24h]窗口，与PPT第44页的“环境稳定性评估周期”一致；downstream_count * 5中的5是经验值，PPT第45页注明“中心度每增加1，风险分扣5分，上限扣50分”。

这个评分服务部署后，我们把它的/score端点接入Jenkins Pipeline：

stage('Risk Assessment') { steps { script { def scoreResp = sh(script: "curl -s http://risk-scorer:8000/score -d '{\"service_name\":\"${SERVICE_NAME}\",\"git_commit\":\"${GIT_COMMIT}\",\"target_cluster\":\"${CLUSTER}\"}'", returnStdout: true) def scoreJson = readJSON text: scoreResp if (scoreJson.decision == "BLOCK") { error "Risk score ${scoreJson.total_score} < 85. Deployment blocked." } } } }

血泪经验：第一次上线时，我们把total_score >= 85写成了> 85，导致85.0分的变更被拒绝——浮点数精度问题。后来改成>= 84.95，并加了日志记录：“Score: ${scoreJson.total_score} -> Decision: ${scoreJson.decision}”。PPT第48页的“决策审计日志”要求必须记录原始分项值，不能只记总分。

希望帮到你。

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