前言
信息系统的运行虽然遵循一定的运行规律，但也呈现出动态的、易干扰、难以预测的特征。对于 IT 系统运维人员来说，我们最关注的是系统的稳定运行，有时会过于担忧系统的运行风险，有时也对某些运行中的风险麻痹大意，甚至在面对潜在的、未知的故障时，还会十分恐慌。恐惧源于未知， IT 运维人员需要克服这种恐惧，让运维从容不迫。本文将从个人运维实践经验出发，研究设计备份系统运行数据采集及分析方法，从而能更加洞察系统的运行规律，希望对同行有一定的借鉴和参考价值。
1. 需求
数据备份是为应对潜在的数据丢失风险，而将业务系统中的数据加以复制并转储到备份存储的工作。为统一调度不同的数据备份作业，集成管理数据备份服务器以及不同类型的备份存储介质，企业需要规划建设与业务系统架构相适应的数据备份系统。文章源自玩技e族-https://www.playezu.com/224933.html
作为数据安全的一道重要防线，稳定运行的数据备份系统是至关重要的。备份系统运维侧重于关注备份作业是否出现报错，备份存储是否存在异常，出现异常或故障时如何去排查、分析、干预等方面。基于备份系统运行数据的收集及分析，来构建备份系统较全面的数字模型，主要用于解决以下三个痛点：文章源自玩技e族-https://www.playezu.com/224933.html
缺乏有效的故障预警：粗粒度、滞后性的运维方式增加了备份系统的故障率，进而影响了备份作业的成功率。文章源自玩技e族-https://www.playezu.com/224933.html
故障溯源困难：故障会导致运行错误，故障分析定位的过程则是从运行错误回溯到故障，找出错误源头，这也是传统运维方式的痛点之一。文章源自玩技e族-https://www.playezu.com/224933.html
系统管控能力不足：备份系统 不同于一般的业务系统，往往会忽略了运维的过程管理，包括配置管理、变更管理、容量管理等。如果系统管控能力不足，会大大增加运维风险，严重影响系统的稳定运行。文章源自玩技e族-https://www.playezu.com/224933.html
2. 设计策略
部分大数据、智能化运维项目更注重于形，即先搭平台，数据收集起来，再慢慢看能做什么样的数据分析和应用。这样的设计策略没有认识到数据质量的重要性，也轻视了系统运行规律和运维经验的指导作用，系统的有效性大大降低。如果数据质量不高或缺失了某些关键指标数据，数据分析的结果必然会有偏差。文章源自玩技e族-https://www.playezu.com/224933.html
因此，总体设计策略应先关注领域分析，即有必要深入分析备份系统的整体架构，了解系统各组件之间的关系、数据流路径；然后是数据的场景化设计，针对具体的运维场景确定数据分析及应用场景，再追溯确认需要采集的指标数据；最后详细设计数据收集和数据分析方法。整体设计流程如图 1 所示：文章源自玩技e族-https://www.playezu.com/224933.html
图 1. 设计策略流程图文章源自玩技e族-https://www.playezu.com/224933.html
3. 领域分析
3.1 备份系统整体架构
备份系统主要包括备份管理系统、备份客户端、备份网络以及备份存储介质这几种组件，如图 2 所示：文章源自玩技e族-https://www.playezu.com/224933.html
图 2. 备份系统整体架构图
- 备份管理系统
包括备份管理软件和备份管理服务器，承担备份作业调度管理、备份存储介质管理等责任，是典型的 C/S 架构，读取备份客户端数据，并将数据写入备份介质中。
- 备份客户端
执行备份任务的业务主机，是用户感知层，一般需安装备份软件客户端代理程序，并与备份服务端通信。
- 备份网络
承担备份数据流的传输任务，一般分为基于 TCP/IP 的备份 LAN 和基于 FC 的备份 SAN 。
- 备份存储介质
承担备份数据存储的备份设备或介质，常见的包括磁带库，虚拟带库， NAS 存储等。
3.2 备份数据流
备份系统的数据流主要包括备份作业数据流和数据恢复数据流，如图 3 和图 4 所示。需要强调的是，数据流传输并不是一个直接调用返回的动作，而是一个持续的数据传输过程，在数据流传输路径的任意一个环节出现堵塞或者故障，备份或恢复作业即会受到影响；另外，由于源端或目的端重复删除技术的应用，备份与恢复的数据流并不对称，需要分别分析。
图 3. 备份作业数据流图
图 4. 恢复作业数据流图
4. 场景设计
4.1 故障管理场景
故障管理是运维场景中最重要的一环，一般可分为事前、事中、事后三个阶段。事前阶段的重点是评估分析，做好故障预防；事中阶段则包括故障告警、故障处理和恢复；事后阶段需要做好分析改进。下文将对备份系统常见的故障场景做具体分析。
4.1.1 作业时长增加
数据备份和恢复作业的时长增加是一种隐性故障，一般影响较小。但对于关键业务系统来说，超出备份时间窗口，带来的影响有时也是无法容忍的；而数据恢复作业时长有时也决定了故障恢复时间长短。
数据备份恢复时长一般随数据量的增长而缓慢增长，但异常情况下，备份恢复速度也会降低。在事前阶段，我们可以判断数据量是否有突增，可以提前调整备份时间；事中阶段可关注数据吞吐量，如达不到速度预期，甚至严重超出备份时间窗口，可能需要及时中止备份恢复作业；事后阶段主要是排查定位速度下降的原因，主要排查方向是备份网络带宽被占用、读取数据源的速度下降以及写入备份存储的速度下降这三类。
4.1.2 硬件故障
硬件故障的影响依赖于硬件冗余情况，备份服务器、备份网络、磁带机、磁带等等硬件都需要有冗余，这种问题对备份系统的影响一般是一次性的。除了硬件设备自身故障以外，还可能存在兼容性问题导致的硬件故障问题，这类问题可能会间歇性的影响到备份作业的成功率，定位难度也比较高。
在事前阶段，我们需要关注硬件自身的状态，可提前预防硬件故障带来的影响；事中阶段，一般来说硬件故障会导致作业报错，即使硬件自身状态正常，但通过运行日志能判断到硬件故障的可能性较大，需要及时将故障硬件排除出去，先保障备份作业的成功率；事后阶段，综合运行日志情况和故障处理情况，可进一步去定位是硬件自身故障还是兼容性问题，为故障最终处理提供依据。
4.1.3 软件异常
一般软件异常指的是软件提供的服务不达预期，可能是代码缺陷或服务异常终止，可以分为前端和后端异常，前端异常会导致备份恢复作业报错，后端异常主要是影响 server 后端作业。前端异常涉及到备份软件 server 和 client ， client 影响的是使用该代理的备份作业， server 端的影响较大。
在事前阶段，我们需要确认备份软件进程和服务端口是否正常，防患于未然；在事中阶段应根据作业报错或受影响情况，结合运行日志去判断异常的软件组件，从而权衡需要如何去干预软件运行中异常；事后阶段则需要复盘运行状态和运行日志，为后续类似的软件异常能预防和定位，提供更多数据依据。
4.1.4 资源争用
备份系统是一种 C/S 架构系统，会共享备份服务器和备份存储资源。资源共享会带来资源争用，也是资源容量不足引起的。典型的资源争用引起的故障场景主要有磁带机可用数量不足、备份服务器计算资源或网络资源占满、备份存储容量不足或服务能力不足，会带来备份作业报错或性能下降导致的作业超出时间窗口等不利影响。
在事前阶段，我们需要做好资源调度规划，合理配置不同时间段的备份任务；在事中阶段，可以通过监视资源调度情况和运行日志中的资源等待情况，及时判断出是否发生了资源争用，可及时中止以确保优先级更高的作业任务的完成；事后阶段则是根据运行中出现的资源争用情况来修改资源调度规划，必要时也可以申请更多的备份资源。
4.2 运维管理场景
运维管理是通过制度化、流程化、标准化的运维手段来指导 IT 系统的运维，是一套持续改进的机制。相比故障管理场景，运维管理场景更关注的是在平时运维工作中如何去应用备份系统运行数据，以达到持续改进优化的目的。通过数据收集及数据分析，可以更好地实现对备份系统管控，主要集中在下面几个场景。
4.2.1 数据管理
数据管理的目标是保障数据安全可靠，对备份系统来说，个人认为主要是三点内容需要关注：一是定时备份作业是否成功，可通过收集备份作业结果来确认；二是重要的备份数据通常还会做数据复制，保持主备站点两到三份相同的数据备份，需要定期确认数据是否成功同步；三是备份的数据需要有数据恢复验证机制，可定期确认备份介质中数据的完整性，并针对不同数据类型的备份做数据恢复，以验证数据正确性。
4.2.2 容量管理
备份系统容量管理工作中主要关注的是数据存储和性能两方面的容量场景。数据存储容量场景关注多的是备份数据源的容量增长趋势、备份存储介质可用容量等，及时做好容量预估，容量估算过程中还需要考虑到重复数据删除和数据压缩技术的应用；性能容量场景是对备份系统整体的服务能力做评估，评估备份作业并发的能力、数据传输的吞吐、备份客户端和服务端的计算资源消耗情况等等。
4.2.3 配置管理
配置管理场景可以关注新增或优化的备份策略信息以及备份介质中存储的备份数据信息。备份策略信息包括主控服务器、备份服务器、备份客户端、备份策略集、存储策略、定时策略以及存储库等的详细配置信息，是备份管理软件的核心逻辑信息，需要妥善保存；备份介质主要包括在线介质和离线介质，备份介质离线保存后，更需要关注备份介质中存储的备份数据信息，以便及时调取访问，该配置信息变化频率较快，需要保持最新版本的配置信息。
4.2.4 监控优化
监控优化场景主要关注三个方向：一是丰富监控指标，二是监控阈值优化，三是告警关联。原有的备份系统监控指标主要集中在备份系统软硬件的运行状态、备份作业的成功失败情况，这些监控指标对于潜在故障的覆盖程度不够，系统运行日志中的部分关键字也是监控的重点；监控指标中部分阈值设置时可能采用的是通用经验方式，会出现告警误报的情况，是需要更加系统运行情况来动态调整的；告警关联则更利于故障溯源，利用运维经验、系统规则可将分散的监控告警信息关联起来，便于定位故障。
4.2.5 统计报表
统计报表是运维工作中一项重要工作，可定期回顾系统运行情况。统计报表场景中，可结合运行数据订制每日、每周、每月的运行情况定时报表，包括特定时间段内的不同备份数据对象的备份作业统计信息，包括完成作业数、失败作业数、运行中的作业数、备份存储消耗情况等等。
5. 数据收集设计
场景设计确定了数据分析的应用场景，也进一步可以确定所需收集的数据。那么数据收集设计的目标是至少涵盖到已设计场景中所需的指标数据，并且这些指标数据可在多种数据源中获得。
设计总体目标是数据收集能够兼顾到高效和低开销，同时对 IT 系统来说是低影响、无风险的。具体设计方面可按照数据源的不同进行分类，并针对不同数据源设计不同的数据收集方法、数据采集周期以及采集的数据指标信息。
5.1 运行日志
备份软件的运行日志一般针对记录不同的组件的运行日志及其错误日志，是研究备份系统运行的重要数据源。日志文件有一定的固定格式，每一行日志一般可分为日期、时间、日志级别、详细信息等字段，对应于一条记录信息，发送到 Kafka ，并最终存储到 ELK 。
备份软件是 C/S 架构， server 与 client 的日志采集方法和周期设置上会做区分。Server 端日志数据较多，产生速度快，且不属于一般业务系统，可以在 server 端服务器上安装 Log agent （可自己编写日志代理程序，也可使用 filebeat 等轻量级日志采集工具）去实时采集；client 端服务器上一般运行着业务系统，为降低对其他系统的影响，可设置定时任务，每分钟执行脚本将 client 日志发送到日志服务器上，再有日志代理程序发送数据。日志采集的整体架构设计如图 5 所示：
图 5. 日志采集架构图
5.2 硬件设备信息
硬件设备主要指的是备份存储、磁带库、虚拟带库、 SAN 交换机等专有硬件设备，一般可通过 snmp 轮询、访问硬件设备 API 以及 CMD 命令输出等方法来收集硬件状态信息，适宜于设置定时任务定时采集硬件设备信息。
硬件设备上可采集的指标数据包括硬件整体及其各部件状态信息、硬件的逻辑配置拓扑和容量信息、备份存储控制器 CPU 负载、备份存储 IO 带宽和延时、 SAN 交换机对应端口的吞吐数据、网络端口 IO 错误计数器信息等。
5.3 备份软件接口数据
备份软件也会有对应的 API 接口或 CMD 接口来获取备份软件的具体信息，可自行编程定期抓取相关数据。备份软件接口数据可分成配置数据和运行数据，其中配置数据的频度较低，可以每天抓取一份信息即可；而运行数据是动态的，变化频率较高，定时抓取频率可设为分钟级。配置数据主要包括主控服务器、备份服务器、备份客户端、备份策略集、存储策略、定时策略以及存储库等的详细配置信息；运行信息主要包括每日的定时备份作业以及其他后台作业完成信息、备份作业关联的备份介质信息、备份介质中存储的备份数据信息、软件运行事件及告警信息。
5.4 其他监控数据源
其他监控数据源中需要收集的数据主要是备份客户端和服务端的操作系统性能数据 , 包括 CPU 负载、磁盘 IO 、网卡 IO 吞吐信息等监控系统中通用的监控数据指标，另外还需要收集备份软件相关的进程和服务端口信息。监控软件一般都留有数据接口，也可以直接访问监控数据库直接获取监控数据，数据的采集周期则依照其他监控数据域的更新频率来设定。
6 数据分析设计
数据分析是处理加工收集到的数据，并对数据加以详细研究和概况总结，提取有用信息并形成结论。抛开一些具体的工具方法，我总结了一下日常运维中通用的数据经验，主要是两点：一是对技术的深入理解，我们会对不同类型的组件做分类，也会找出组件之间的各种关联，这样才能对一些技术更加了解；二是对数据变化的敏感性，比较典型的例子是我们对一个系统每日做巡检， CPU 负载可能稳定在某些值附近或者在特定时刻才会发生数值突变，如果某一天 CPU 负载数据不再遵循这样的波动规律，这种数据的变化就是我们需要捕获并深入关注的。
在备份系统的具体数据分析工作中，可以从上文提到的数据场景出发来应用不同的数据分析方法，但我个人觉得也可以以场景为辅助，而从数据类型入手。上文已设计了不同数据源的数据收集方法，个人觉得也可以分为静态配置数据、动态运行数据以及日志数据这三种类型数据。下文将详细介绍这三种类型数据的数据分析方法。
6.1 静态配置数据
在备份系统的数据分析中，静态配置数据是骨。静态配置数据的数据分析最适宜采用的方法是详细分类和关联分析，理清配置不同种类的数据元素以及它们之间关联关系。
备份系统的配置数据主要包括硬件设备及其组件的配置信息、备份软件层的备份策略信息以及网络拓扑信息等。关联可分为简单关联、时序关联、因果关联。优先对配置数据进行分析，可以帮助我们理清备份作业的静态时序信息、备份作业和存储资源的关系、硬件设备间的联系、不同备份客户端的基础信息以及架构拓扑信息等。
6.2 动态运行数据
在备份系统的数据分析中，动态运行数据则是血肉。在静态配置数据的分析结果的基础上，动态运行数据可以提供更加详细的关联关系，不再是元素种类之间的关联，而是具体元素之间的关联；根据时序信息，回溯历史数据可以刻画同一元素的数据趋势图；结合数据详细分类结果，运用数据对比的分析方法，横向比较可以刻画出同类型元素之间的数据趋势对比图，纵向比较可以将现时与历史一段时间内的数据趋势做对比。
备份系统的动态运行数据主要包括硬件状态、软件进程运行状态、作业运行信息、网络 IO 信息、备份存储 IO 信息、备份存储使用信息、备份服务器系统资源使用信息、事件及告警等。除了进一步完善分类与关联关系外，备份系统运行数据的做单维度分析可以得到每日作业完成情况图、整体存储使用趋势图、备份网络 IO 趋势图、单个备份作业存储资源使用趋势图、备份存储 IO 趋势图等，如图 6 所示；多维度分析可以得到不同客户端使用的存储资源对比趋势图、不同备份存储使用情况对比图及 IO 对比图、不同备份作业 IO 与历史数据对比图等，如图 7 所示。
图 6 单维度分析 - 存储使用趋势图
图 7 多维度分析 - 多类型客户端存储使用趋势图
6.3 日志数据
在备份系统的数据分析中，日志数据可以说是重要宝藏。目前主流的日志分析工具解决了日志存储的方法，但主要是基于 Web 日志分析，采用关键词搜索、词频统计等方法来做分析。而在备份系统运行的场景中，这方便了日志检索，我们还需要做的是基于日志信息来抽象串联出备份系统运行中一个个子工作流程。
静态与动态数据的数据分析已经相对生动了，但还是缺少很多细节信息。我们就以一个备份作业的运行日志为例，来串联出这个例子的工作流程细节，如图 8 所示：首先定时调度计划被触发，会先检查客户端状态，然后按照定时计划脚本中的配置和备份策略信息开启备份作业会话，每一个备份作业会话会去申请磁带机或其他备份数据存储路径，这时会话会处于等待状态，直到申请的资源被满足；介质管理组件接到资源申请后，会根据当前的资源使用情况和申请的优先级，分配磁带机及磁带给对应的作业会话；一旦作业会话发现其申请的资源已被分配并被挂载后，这时客户端会读取 源数据，并 将数据传输到已挂载的备份存储，直到作业会话结束；当所有作业会话都成功完成后，该作业才会返回成功。
图 8. 备份作业工作流程细节
整个工作流程中，会以作业 ID 、作业会话 ID 、备份设备 ID 等信息与实际组件相对应，从而能还原出该备份作业的运行情况。如果其中某个子流程出现问题，通过日志分析就能还原该故障过程，迅速定位故障对应的作业 ID 、会话 ID 、客户端或备份设备 ID 等。
结语
数据收集及分析工作是一项长期性的工作，需要持续改进、不断优化，这正如 IT 系统不断演化，也如我们所从事的运维工作一样，需要日积月累，才能日益精进。
评论