运维改革探索(二)：构建可视化分布式运维手段
2016-11-15 13:35:00   来源：来源：DBAplus社群   评论：0 点击：

作者介绍

朱祥磊，山东移动BOSS系统架构师，负责业务支撑系统架构规划和建设。获国家级创新奖1项、通信行业级科技进步奖2项、移动集团级业务服务创新奖3项，申请发明专利13项。

工具篇：构建可视化分布式运维手段

工欲善其事，必先利其器。上篇我们已经详细分享了监控相关的知识，然而运维可视化，除了构造可视化监控外，还要建立相应的运维手段，云化下的运维工具和传统架构的有较大不同，对集群式、分布式提出了更高的要求。

1、自动化巡检

从2011年开始推行巡检，最初，我们的武器仅仅是一个word文档、一些excel表格和大量的SHELL脚本，检查靠人工敲击命令或者查看表数据，内容也多数都仅限于日常维护中已经存在的主机，数据库，中间件，进程状态等，执行效率较差，并且未真正涉及业务类的健康检查。

从2014年12月开始，正式引入自动化巡检工具，工具对原来积累的脚本进行整合，提供可视化操作局面，能够定期自动执行、自动生成巡检分析报告，巡检内容涵盖主机、数据库、中间件、应用在内的所有监控对象，并且随着巡检的深入，在2015年起又增加了业务级别的巡检内容，对于一些关键业务关键点也定期进行巡视分析。

1)自动化巡检内容

目前自动化巡检对象涵盖了所有的生产主机，固定巡检内容主要包括常见的系统安全隐患、入侵攻击检查，安全补丁检查，系统配置、加固检查，数据库安全配置检查，详细如下：

巡检工具把历史积累的SHELL脚本参考上面内容进行逐步归类，作为巡检工具的基础项，也可以随时对巡检内容进行修改，所有的巡检动作全部可视化，并且巡视项、巡检方式、巡检主机等全部可以进行定制，巡检任务结束后会自动生成巡检报告，并能通过邮件、短信等渠道第一时间告知关注人。

2)自动化巡检效果

从2014年底以来，通过将日常巡检报告自动化，不断来提升运维的自动化程度，通过脚本管理、故障诊断、拓扑图执行远程命令调用等功能规范日常运维操作。通过巡检可以保存系统性能数据、容量信息、配置信息为系统维护、升级、扩容提供决策数据支持;同事通过灵活的工具定制，达到了对各种等资源全面的监控、多级钻取实现性能分析，提升运维的专业化水平。

2015年中开始，在实现系统自动化巡检后，我们再接再厉，终于实现了业务巡检的工具化，目前业务相关的巡检包已涵盖了系统安全、无纸化、服开配置、业务规则等巡检内容共计10类28项业务，能够随时掌控关键业务监控度，具体的业务巡检内容和界面如下：

2、自动化JOB

在系统日常运维中，存在大量重复并且简单的运维操作，包括最常见主机、中间件、数据库等不同类型的软、硬件平台运维。这些运维操作重复而机械，却易于出错，占用了大量日常运维人员的精力和时间。

通过运维自动化工具，将运维操作场景化、可视化、自动化和标准化，将以前需要编辑大量脚本和命令进行的维护操作变为只需要点击相关的场景调用以及输入合适的参数，大幅减少运维人员在编写脚本和命令分发执行所带来的资源投入。

日常运维场景

日常运维场景是将系统管理员的日常工作项目，集成于同一界面，可对自动执行的任务进行处理，并提供统一接入入口和监控界面。

首先，系统管理员先进行任务配置，系统管理在任务配置页面，进行任务分类与任务的配置。使用日常任务之前，需要先配置在相应的任务分类下配置任务，才能使用。

此后，系统管理员在任务视图是各分类的任务的执行页面。配置任务完成后，打开任务视图，可看到不同任务分类下已配置的任务，点击执行，进入参数输入页面，选择执行的目标设备，输入参数后，点击立即执行完成运维场景所需要执行的运维操作。

自动化告警处理

传统告警处理，主要靠人工值守进行操作，告警响应速度受到多方面因素的制约，如告警信息发布及时性，运维人员响应及时性，运维人员对系统熟悉程度等;一旦运维人员错过了告警，本来有很简单有效的运维操作没有被执行，就可能导致系统故障。

自动化运维工具通过告警消息自动触发故障处理流程，主动高效地识别和解决故障，极大的提升运维对故障的响应速度和缩短故障时间。

• 快速高效地识别、解决和消除服务中断的根源
• 通过工具来查看、管理、诊断和解决问题
• 整合运维团队积累的、厂商的专业工具和知识来加速事件和问题的诊断和解决
• 自动进行故障问题定位并启用对应

一键快速诊断定位性能问题：

• I/O性能问题
• 并发问题
• 低效SQL或者高负载SQL
• 对象争用
• 锁阻塞或HANG

运维管理人员可以通过自动化工具，根据告警触发或手工调度诊断流程，自动化工具自动进入诊断模块，首先自动判断系统所存在问题:如IO问题、并发堵塞问题、低效SQL或高负载SQL问题、hang等。自动化工具根据问题类型自动调度预定处理流程或方案(预定处理脚本集)，最后返回诊断结果。

3.自动可视化发布

随着云化后机器数十倍的增长，传统“烟囱式”系统应用部署模式耗时耗力，并且手动发布出错的机率也非常大，我们尝试引入互联网自动配置部署工具SaltStack，并考虑到SaltStack无WEB配置界面的缺点，在其外面定制开发了一层WEB可视化界面，从而实现了云化系统下自动化可视化部署。

1)自动化配置管理平台SaltStack整体架构

SaltStack是一个服务器基础架构集中化配置管理平台，具备配置管理、远程执行、监控等功能，易于安装使用，便于扩展，可支撑管理上万台服务器或者虚拟机。依托云计算平台资源池实施部署了SaltStack管理平台。截至目前，SaltStack管理共计47套Linux系统，涵盖测试域36套系统以及生产域11套系统，并且还在不断的扩展。基于C/S架构，划分为主控端和被控端，分别称为Master和Minion。两者基于证书认证，安全可靠，其整体架构如下：

2)SaltStack安装配置

SaltStack可采用多种方式安装，通过源码安装，将SaltStackMaster部署在RHEL6.5主机，启动Master进程，并在全部受控机安装SaltStack，启动Minion进程。

Master和Minion在通信时需要进行认证，因此需在/etc/salt/master中配置Master节点的IP地址，在/etc/salt/minion中指明Master端的地址以及本机的唯一标示。这样在Master端认证和统一配置时可以通过唯一标示进行。配置文件使用YAML$key:$value格式。

3)SaltStack应用

在我们的业务系统中，主要按照操作系统以及应用进行分组，具体分组方式如下：

cat/etc/salt/master.d/nodegroup.conf  
nodegroups:  
redhatDatabase:‘redhat-db’  
redhatAPP:‘redhat-app’  
suseAPP:‘suse-app’  
suseDatabase:‘suse-db’ 

受控机器的信息展现是通过grain组件进行展现的，基本使用方法如下：

salt'redhat-db1'grains.ls查看grains分类

salt'redhat-db1'grains.items查看grains所有信息

salt'redhat-db1'grains.itemosrelease查看grains某个信息

4)可视化界面发布

通过在SaltStack外部，定制开发WEB界面，使得整个发布部署过程和发布结果全部可视化，具体的应用步骤如下图所示：

目前在多台服务器上实现了并行批量执行命令，根据不同业务特性进行配置集中化管理、分发文件、采集服务器数据、操作系统基础及软件包管理等。

4、自动化数据管理

云架构下的IT系统越来越多，数据库管理员需要面对成百上千的数据库，另外随着云架构下的大数据平台等技术的不断深入，数据存储将迈入EB级别，传统手工数据管理的难度越来越大。同时云架构中出于开发、测试、培训以及数据对外共享变现等环节需要从生产环境中同步和迁移大量数据，其中亦会涉及大量用户隐私数据。而之前整体IT系统数据流和业务流的关系不太清晰，业务数据可视化展示程度很低，缺少可视化的企业整体数据地图，对于数据的维护困难重重。

1)云架构下数据管理规划

为解决传统数据管理上的痛点，让数据管理相关工作更加标准化和流程化，我们借鉴国内外IT业界先进的数据管理和运营经验，着手在数据管理领域的自动化运营工具作出了规划。整体规划如下：

在此规划的基础上，着手建设了在云架构下的数据安全管理以及数据生命周期管理两个主要运营场景的自动化工具化建设，其他还处在建设阶段。

2)云架构下数据生命周期管理

根据核心生产系统中数据的特点建立多层次数据存储体系，将用户访问频率较低的远期历史数据按规划从生产环境转移到历史数据中心和大数据平台中，在不影响绝大部分用户应用感知的情况下，有效管控系统整体数据增长，既降低系统运营成本，又满足最终用户的数据需求。我们的数据生命周期管理自动化工具，由数据管理员针对不同种类的数据梳理的数据生命周期策略进行可视化的管理，以自动化方式按不同周期识别历史数据并将历史数据完整地迁移到历史数据中心或其他大数据平台中。

通过作业化自动化的思路，以自动化平台方式实现数据生命周期管理的全程，减少人力在策略管理、数据迁移和数据清理中的人工投入，主要目标在于：

• 策略管理：在平台中对数据生命周期管理策略进行有效管理;策略定义包括数据生命周期定义，数据迁移策略定义，数据清理策略定义;定义数据生命周期作业，定时进行数据生命周期作业调度
• 数据迁移：根据平台中的配置的数据生命周期策略定义，请理作业实施数据的自动化迁移，数据迁移过程无需人工干预，不同数据平台间数据迁移
• 数据清理：数据重要程度，清理过程可以通过配置为自动执行和人工确认执行。根据平台中的配置的数据生命周期策略定义，作业实施数据的自动化清理

3)云架构下数据安全管理

根据生产系统中敏感数据分布情况，建立敏感数据策略化管理。在数据从生产环境中向未安全环境，包括开发、测试、培训和对外数据共享等，进行数据迁移和同步的过程中，因应数据安全管理员制定的敏感策略对数据进行自动化安全脱敏，减少敏感数据外泄的可能。

目前数据安全自动化管理工具，实现从敏感数据识别，脱敏策略配置，数据迁移配置，以及数据在线和离线脱敏全程，自动化安全地将数据从生产环境向非安全环境迁移，同时在迁移过程中实施敏感数据脱敏。

分析篇：利用大数据实时分析助力运维

数据是金矿，随着云化的深入，价值数据之间分散到海量机器中，需要采用大数据技术进行集中化处理，并助力运维。我们公司进行了积极尝试，引入flume+kafka+spark+分布式内存库redis等开源技术自主进行大数据运维分析，取得了一定的效果。

整体架构如下图所示。考虑到来自业务系统的数据是多元化的，既包括了软、硬件基础设施日志数据，也包括各类应用服务的日志数据，这两类日志数据通过主机和分布式软件代理服务、分布式消息采集服务和分析服务处理后，以流数据的方式转给大数据平台和报表平台：

分布式数据(应用日志等)采集

整个分布式采集分为如下四个部分：

• 数据采集：负责从各个节点上实时采集日志数据，可以指定目录或文件，通过flume实现，仅增量采集数据。
• 数据接入：由于上述采集数据的速度和数据处理的速度不一定同步，增加分布式消息曾作为缓冲，防止丢失数据，采用kafka。
• 流式处理：对采集的数据进行实时分析，选用spark-streaming+redis实现。
• 数据输出：对分析结果存储在mysql数据库中，并进行告警展示。

以往，业务支撑网中的日志分布在各服务器上，每次检索要逐一登陆到各服务器操作，严重影响效率;同时，日志留存于操作系统本地，会受到存储空间限制而循环覆盖，导致重要数据丢失;由于对关键日志缺乏保护，也给监控、审计带来诸多困难。

随着业务发展，来自硬件、操作系统和中间件的日志量不断膨胀，独立而分散的日志管理模式已不能满足日益增长的维护需求，特别在事件回溯、问题分析及报表统计相关工作中，其基础数据均源自这些纷繁芜杂的日志单元，亟需形成统一管理、综合分析、集中展现的新型一体化管理机制。为此一直进行着日志集中化改造的尝试。

起初，以HTTP服务器日志统计为例，传统解决方式是定期(按5分钟、小时或天)截断日志，然后通过FTP上传到一台服务器统一处理，在有些日志的计算处理前需要考虑日志排序问题。这样的日志同步可以支持几台到几十台规模的并发服务，但当管理的服务器达到几十台，而有大量的服务器中间会有下线、上线或变更时，集中的日志定期同步更显得难于管理，且日志同步要避开白天的高峰，往往需要用凌晨的低峰时段同步，24小时下来，上G的日志同步也是风险很高的操作。而成为瓶颈的日志排序合并操作也会妨碍其他后续计算的周期。其逻辑架构如下所示。

目前实现了应用分布但日志集中的远程存储模式，通过UDP协议实现小局域网内的日志广播，然后在多台汇聚服务器上实现各种日志的并发计算。如图所示：

为保证日志流传输的可靠性，对整个传输链进行了改造，实现了多个特性：非阻塞的适配器、网络划分、负载均衡、传输高可用性、传输监控能力及可以动态调整的Push/Polling模式。

无论是网络设备、应用服务器还是中间件，其日志需要与Flume节点对接，这就涉及到协议适配的问题，为此专门针对企业总线(eBus、UAP)、前端Web容器及交易中间件配置协议适配驱动，将日志以流的方式传输给Flume代理，协议适配层提供了较丰富的协议适配驱动，能够支持来自各层面基础设施的日志数据对接，目前已成功接入的基本组件有交换机、负载均衡器、各刀片服务器操作系统及应用程序，如图所示：

当采用适配器连接Flume代理时，应用服务会调用异步附加组件AsyncAppender输出日志流，如果Flume代理宕机，且无备份节点时，会导致应用服务器阻塞，我们针对一些适配器配置了non-Blocking特性参数，当启用此参数时，即使日志流写入失败，不会影响正常业务运行。

为确保基于UDP广播的传输模式不会形成网络风暴，我们按照不同的业务范畴、不同的组件类型划分子网，同一子网内的应用服务器仅与当前子网的Flume代理通信。在高可用性方面，应用服务器以UDP协议在子网内广播日志数据，UDP包被多个Flume代理节点截获，某一时刻仅有一个Flume Agent处于Active状态，其他为Standby，当Flume节点宕机时，其他节点可以无缝接替继续工作，所有Flume Agent通过Flume Master节点管理，实现主备接管和配置同步功能。如图所示：

(灰色框为备机)

为便于维护人员及时了解日志传输的工作状态，对Flume的相关命令进行了封装，在统一界面上展现来自Flume不同端口的数据接收情况。

对于超大规模的营业厅前端用户交互日志采集，采用UDP、FTP方式可能会导致过高的网络、磁盘I/O资源消耗，因此首先保证整个架构过程中，除在汇聚服务器和日志中心外的Flume节点上均不产生文件落地，仅在汇聚服务器中实现了对来自多个Flume代理的数据聚合和排序。同时在业务高峰时段，日志采集处理能力有限，Flume代理会从Pushing模式切换为Pulling模式，即从采集转为采样。

2、实时数据聚合+分组

利用大数据集中处理平台的处理流程主要分两部分，通过消息队列处理Flume采集的日志，再通过ElasticSearch建立索引，最终将数据、索引导入在mysql集群。如下：

大数据平台主要分析营业厅与用户交互日志，其中包括实时的用户体验、服务器请求记录。用户体验日志是用户在浏览器中每一步操作的性能评估，主要包括用户每一步操作的名称(如点击按钮、键盘录入、下拉框的选择、复选框的勾选及页面刷新等);用户操作整体响应时间及其构成部分：客户端响应时间(包括页面元素渲染时间、页面JavaScript脚本执行时间)、网络耗时(包括网络中的传输时延及第三方内容服务CDN的处理时间)、服务器运行时间。通过用户体验日志可以了解到用户每一步操作的感知状况，准确了解性能故障对用户操作的影响;此外，用户操作和用户请求是相互关联的，通过关联关系可以找到每一步用户操作的具体含义，如(某一步操作是在缴费业务的录入用户号码操作)。

然后就是对用户操作业务聚合，即按时间顺序、用户操作的业务名称、用户号码等对用户真实的操作情景予以重建，这样做的好处是从整体上了解某一笔业务的操作繁琐程度(难易度、友好性);了解某一笔业务在哪一步较慢，是慢在网络层面、客户端层面、服务器层面还是用户自身原因(如间歇性停留)导致的;了解业务分布情况及成功率、转化率等。为确保业务聚合的并行计算高效，我们采取了spark流处理机制完成。目前主要应用了如下几个场景：

场景1：以下图为例，通过大数据的数据聚合+分组手段，实现对用户行为的模式匹配，将多个操作归结到一笔业务中，实现用户体验不好根本原因是IT原因造成还是非IT因素造成(用户问题、营业员操作问题)：

场景2：结合大数据的分析，掌握用户的操作规律、操作习惯，并基于这些分析进行页面优化，如在合适位置投放广告，发布符合大众需求的产品与优惠：

场景3：实现基于业务监控的入侵检测机制，我们基于集中日志分析，利用大数据技术实现基于业务聚合的CC攻击分析方法，将用户操作与浏览器请求建立关联，首先将URI请求按用户操作聚合，形成用户操作序列，再按照时间先后顺序及一定的业务规则将用户操作聚合为业务单元，通过对业务单元数据分析判断是否存在入侵检测。大大提高了针对仿真式DDos攻击的鉴别准确度。

下图是近期发现的感染木马病毒的终端列表：

3、深入性能诊断

我们基于集中日志实时分析，可用于性能诊断等场景，并总结了一些宝贵经验：如网络故障关联分析和诊断、诊断企业总线调用外部域时发生的故障、基于接口报文的后端交易调优、针对RPC的性能分析等。

1)网络故障诊断

网络延迟故障一般可以从用户体验的网络耗时一项直接诊断定位，但有时很难一下子定位，也需要从用户请求中，如从HTTP服务器和WAS服务器的耗时份额对比中推导，亦可以从用户请求服务器代码路径中推导出来。

从下图1看，某用户请求在IHS(HTTP服务器)上耗费的时间为14.69s，而端到端路径分析，在WAS(APP服务器)上的耗费时间为2.57ms，因此分析可知时间主要耗费在HTTP服务器上，而HTTP服务器主要作为一个代理与用户终端交互，因此分析得知有2种可能：在终端用户到HTTP服务器之间的链路上出现了网络故障，或HTTP服务器出现了性能问题，而经过监控发现其他业务运行均正常，HTTP服务器线程池使用正常，如图2所示，因此通过排除法得知网络故障可能性较大。

图1 端到端路径分析

图2 HTTP服务器的线程池使用情况

另外通过服务器响应字节数进一步证实之前的推论，返回大小相比其他同类请求来说较大，如下图所示。

2)基于接口报文进行的后端交易优化

我们CRM交易处理程序基于C/C++实现，这导致交易中间件无法向基于JVM的前端Web服务一样实现运行时环境注入并动态改变监控行为，只能通过捕获应用程序触发的操作系统底层业务逻辑实现，这种情况下无法实现前端与后端的单笔交易关联。为解决此问题，首先对CICS应用服务进程启动多线程跟踪，将truss日志输出流重定向到UDP，发送给外部服务器，truss会跟踪到一些极基础的函数调用，使用truss跟踪的好处是，当和被跟踪进程依附和解除依附时，对被跟踪的进程不会造成影响，因此可以在生产环境中使用。此外，可以对CICS连接到Oracle的会话，在数据库中启动10046事件跟踪，跟踪数据库的调用轨迹，这种方式的好处是：填补了CICS跟踪的空白，实现了对业务的梳理;坏处是：只能小范围开启，需要在生产隔离出单独的一套中间件，并在此环境中回放报文处理过程。

下图是通过启用数据库10046事件跟踪后，梳理出的合约机校验接口的业务逻辑(部分)。

服务篇：建立面向云服务的运维架构

目前我们的运维模式是基于ITIL的，从服务台、时间管理、变更管理、可用性管理、容量管理、CMDB等思路逐步建设整个系统，这种运维思路在传统架构下没问题，但在云计算下大规模运维的时候，越来越难以应对，或者说过多的聚焦于流程和规范的情况下，很难提升运维敏捷性和精细性。当前，IT支撑系统正在向资源池、SOA架构快速演进，系统支撑能力逐步具备了服务化的能力。通过对系统能力组件化和服务化，并配合系统弹性伸缩等能力，将支撑系统的能力以“服务”的形式提供，屏蔽内部过多的细节，可以实现“IT即服务的新型敏捷支撑与运维模式。

为适应“IT即服务”的新型运维模式，尝试打破原有按照专业(主机、存储、数据库、中间件、网络……)和项目划分的组织架构，按照资源池运营管理模式进行架构重构，把运维工作划分为服务运营、资源运营两个核心维度，并以此为核心组织进行基础设施层面的构建和上层的管理运营，如下：

经过上述调整，大大降低了之前各个专业之间协同难度以及不同专业间的专业壁垒，例如支撑一个项目，原来需要主机组提供主机资源、网络组提供网络、数据库组提供数据库等，现在提前建好资源池，资源池的运维人员通过云管理平台几乎可实现一切底层设施，每个人对各个专业门槛也大大降低了要求，适应了大规模环境下的运维要求。

考虑到资源池初始阶段还有很多传统架构和云架构并存，且资源池需要提前建设，上述划分仅适应运营阶段需要，我们在运营团队中横向构建了跨专业的虚拟团队，作为项目小组，人员跨资源运营和服务运营的成员组成，例如扩容项目组、工程项目组、业务连续性项目组等，作为临时需要时的一个扁平化团队，如下图所示：

通过上述组织架构调整，结合我们在资源池管理平台实现的IAAS和PAAS的自动管理功能，大大降低了运维难度，同时规避了繁琐的运维流程，初步实现了敏捷运维能力。同时根据测算，在人员配备上，如果按照传统运维架构，2000台服务器规模需要不同专业运维人员12人以上，而采用新的运维架构，只需3-4人即可。

上述是在组织架构上适应云服务的运维，在技术上，我们公司积极推进企业级资源池、第三代CRM的IAAS和PAA融合架构建设，实现应用节点容量通过服务方式自动扩展，做到集中统一管控，深入运维提升核心掌控能力，目前本项目正在建设中，如下图所示：

效果和后续计划

通过近两年的持续探索，引入了较多的互联网开源运维工具，并经过定制化改造，目前已经初步搭建了面向云化架构下的系统运维架构。通过完善相应的监控、维护工具和数据分析，简化了系统运维难度，大大提升了系统维护效率;另外通过系统建设，运维人员接触到很多新的互联网化运维工具，人员自身的能力和工作积极性有了较大提升;而新工程项目建设时，。因为从各层级有了可视化操作工具，项目建设难度大大降低，减少了较多的项目协调工作，人员投入也从之前的8-9人变为2-3人承担。

尽管目前引入了较多的云化运维工作，但目前各个工具还相对比较分散，未来我们计划对各个运维工具统一建设，能够集中到一个统一的操作平台上，各个工具也能够作为一个整体相互协调运作。

【编辑推荐】