本文来自微信公众号“twt企业IT社区”，作者/白东旭、王向虎，民生银行科技部工程师。
现有运维体系的建设现状
随着银行数字化转型升级进程的加快，IT系统架构越来越复杂，软件更新迭代越来越快。银行信息化建设中的大量业务和数据需要依靠信息系统来完成，这使得构建稳定可用的IT系统成为业务发展的基础条件，而IT运维管理也随之成为银行信息化建设的重要环节。
近年来，因为IT系统突然出现故障导致业务瘫痪甚至造成巨额损失的现象频出不穷。而银行大型数据中心由于对系统、数据的高度依赖，IT风险更大，对IT运维管理的重视也就更高。
在银行IT基础架构层中最重要的就是存储设备，存储最基本的功能就是对外提供高可靠、高性能的数据存取能力。完善的存储运维不仅要对所有IT系统以数据容量超PB级别的快速精准管理，更要面对年增长超20%的设备/容量增长，不仅包括SAN/NAS/IPSAN，更包括上千个SAN端口、异构设备的挑战，时刻面对呈指数级增长的应用的压力。就当前的现状来看，基于存储的复制，系统恢复仍然需要较长时间，高可用方案，包括存储层面的高可用，OS层的卷镜像，Oracle的ASM，基于应用的复制方案等，管理上也更复杂。
云平台下运维的变革
随着云计算、大数据以及新兴的区块链等技术体系的迅猛发展，数据中心的扩容建设进入高峰期，云数据中心运维需求应运而生。传统的运维直接接触硬件，如服务器、存储设备和网络设备；但是在云数据中心时代，运维已经从面向物理设备，转变为面向虚拟化、云的管理方式。
因此，云平台下的运维提出了新的能力要求——不仅要熟悉传统硬件设备，同时要掌握虚拟化、云系统的部署、监控和管理等运维能力。存储系统作为IT基础设施的主要部件，也在探索如何利用AI技术提升其各项能力。
银行的业务千差万别，而不同的业务对可靠性、性能的需求也不尽相同。为满足这些需求，存储设备提供了不同的介质、缓存、特性选项。如何合理配置这些选项，实现存储设备的最大化利用，就成为了云平台存储运维复杂性的重要来源。
云平台下存储运维实践
1.存储选型：
针对云下存储，首先需要划定对接不同业务类型的存储服务。
交易类服务器：裸机+FC SAN,适用于核心交易类、数据库类应用，要求极致高性能的传统关键应用；
OpenStack云平台：1）集中式块存储资源池：对接裸金属服务器和KVM云主机；2）分布式块存储资源池：对接KVM云主机；3）分布式对象存储资源池；
容器平台：1）分布式块存储资源池：对接无状态容器主机；2）集中式文件资源池：对接有状态高性能容器需求；
大数据平台：使用服务器本地盘，存算分离场景使用对象存储；
数据共享与交换：1）集中式NAS用于文件共享、票据影像等小文件场景，性能更优；2）分布式NAS：用于视频监控、HPC等大文件场景；
数据备份：1）分布式对象存储池：用于存储数据在线备份；2）磁带库或蓝光存储：用于存储数据离线归档；
如图1所示。
图1：不同业务类型的存储方案
2.基于应用感知的存储运维优化
通过存储设备内置的控制器、缓存、盘等使用情况去实时感知应用的特征、存储的性能、消耗的资源等数据，并基于获取的海量实时数据的进行数据分析、挖掘、建模和预测，准确的判断出应用的业务特点和行为模式，也就是应用的“DNA”。在后期新业务或者未知业务的识别和分析中，通过业务特有的“DNA”，便可准确获知其应用类型（如OLTP、OLAP、文件共享、VDI等）。更进一步，基于长周期序列数据的分析和预测，存储可以预测应用性能需求的峰值和低谷，甚至是某个时刻的具体IOPS值，以及应用的趋势变化。
例如，以应用读写的IO大小分布作为横坐标，时间作为纵坐标，颜色深浅表示所占比例大小，可画出应用在一个业务周期内IO大小的热力图。将不同应用若干天的热力图放在一起比较，可以清晰的看到不同应用的特征区别显著，而同一个应用特征相对稳定，如下图（图2）所示。显而易见，通过这些特征可以准确区分出不用应用。
图2：不同应用业务周期内IO大小热力图
具备了感知应用的能力，在云环境中就可以清楚的知道运行在不同存储上的应用类型。而基于应用的特征，配合存储设备内置的接口，来调整和优化存储的配置、参数、前台特性、后台任务等等，最终保障应用高效，平稳地运行。
3.提前预警和快速消除隐患
通过设备隐患的主动识别和提前预防，提高系统的稳定性和数据的可靠性，是每个银行云平台存储运维人都十分关心的内容。
故障预测：整个存储系统是各类子硬件模块如控制器、盘、接口卡、缓存和软件构成的复杂系统，每个部件都有可能出现故障，从而影响整个系统的稳定性。虽然存储系统做了很多的容错机制，如不同类型的RAID，阵列双活等，防止出现数据不可用或数据丢失等情况，但是若能提前获知某个部件即将发生故障，如硬盘的失效，通过硬盘的SMART信息，学习硬盘在失效前的模式，构建机器学习模型，提前预测出故障盘，及时进行更换，可极大程度避免由于多盘故障导致的数据丢失问题。
基于云端的智能存储运维，通过收集大量的存储上报信息，可实时获知每个阵列设备的健康状态。当发生故障时，云端ML/AL可以迅速进行根因分析，指导故障修复，同时总结故障指纹，立即在全网积极排查，避免同类故障在其它局点出现。
系统瓶颈识别：基于历史数据对存储设备的运行情况进行预测，如容量和性能的预测，给出建议。可以清楚业务在未来一段时间的容量和性能需求，并提前进行相应的扩容或SLA（Service Level Agreement）等级调整等工作，避免临时出现资源不足导致的生产事故。
4.主动识别并准确定位问题
大部分情况下，当存储设备出现故障时，往往都有一些异常征兆：如控制器CPU占用率上升，或许是短时间内大量告警日志。若这些异常能够被提前预警，将会极大提升云下存储系统可靠性，降低运维风险。
对于云下存储设备来说，需要识别的异常有两类，一类是KPI（Key Performance Indicator）异常，如CPU占用率、时延、IOPS、带宽等指标异常；另一类是日志异常，如异常打印。
KPI异常通常分为三类：点异常(Point anomalies),上下文异常(Contexture anomalies)和群集异常(Collective anomalies)。点异常和上下文异常较好理解，群集异常略显复杂。例如，在存储设备中，通常控制器的CPU利用率会随着IOPS的增高或后台任务的增多而增高，当IOPS以及后台任务不变的情况下，CPU利用率增高（但尚未到达告警的阈值），这就是一个群集异常现象。识别这类异常的方法很多，简单的方法是基于规则，通过设定阈值来检测。但是，当监控指标很多，业务特征很复杂时，管理这些规则和阈值就成了不可完成的任务。更智能的方法，是利用传统的ARIMA、Holt winter方法，或LSTM，CNN等深度学习方法，学习出预测模型，监控预测值与实际值的偏差；或者通过最近邻、聚类和马尔科夫链等方法直接找出异常点。
日志异常：日志类的异常检测在运维已有不少成功的先例。其核心思想如下：通过分析大量日志，将类似的日志标记为一个事件。通过学习正常日志来归纳总结这些事件的正常模式。当系统发生异常，产生不正常的日志时，就可判断出这时的事件发生模式有异常，可将其标记为不正常的时间段，如图3所示。
图3：机器学习在问题定位中的应用
监控升级，云存储运维向AIOps演进
随着堆栈变得越来越复杂和关键，在云平台存储运维流程建立完备后，需要整体的AIOps的功能。特别是在云下混合、虚拟化和异构环境中，应用于基础设施性能管理(IPM)的AIOps能够有效地确保最佳性能，可以监督业务关键型面向客户的应用程序的运行状况和利用率，能够在数据中心基础设施中出现任何潜在阻塞或延迟问题之前提供警报。
未来存储监控平台可结合整体智能运维分层立体的监控体系，实现从基础设施到租户业务的端到端的全覆盖的立体监控，提供基础监控、业务监控、链路监控等方面通用平台能力，将监控平台+云服务+一线运维等各云服务监控整合基于监控平台实现自己特定业务监控。
针对未来IaaS规模急速增长，监控平台需结合SRE数据平台制定基于Region，基于资源的集群隔离及解耦方案，平滑应对未来现网的规模增长。
