华泰证券智能运维体系探索与实践

彭小阳

作者简介：

苏凯，2015年加入华泰证券，进入公司的时候最早是渠道业务研发团队，那时候是做业务开发，主要负责股票期权业务系统开发。后来领导说，我们监控要加强一下，后来又分了一部分的时间去为团队做了监控系统，这也算是我第一次接触到运维这个领域。再后来，因为工作的关系，就加入了现在所在的运维技术开发团队。
从那时候开始，我真真正正地成为了一名运维人，这几年过下来也体会到了运维工作的酸甜苦辣，真的都有。套用网络流行的话“一入运维深似海，从此XXX是路人。”加入运维工作之后，主要负责运维平台、日志系统、网管平台、性能管控平台等的落地。目前主要是配合公司整体的智能运维平台的建设，做设计、规划和相应的落地工作。

概述：今天要给大家分享的内容，主要是四个方面：一是券商运维的痛点；二是基于痛点和挑战的思考；三是在监控层面是怎么做到体系化的构建；四是分享在智能运维方面的尝试。

一、券商运维的痛点

先讲讲券商运维的特点，相信大家对证券业务很熟悉，我们的业务就是强周期性的业务，对实时性要求很高。右边的图是我截取监控系统的某一个业务趋势图，大家可能会看到，钱老师也提到了会有大数、秒杀，对于我们证券行业来说，我们的系统每天都在秒杀，每天都面临两场秒杀。

我们有开市和闭市，这是我们的压力时间，是闲时压力的上百倍，这个周期性很强。我们的系统有这么多用户秒杀，我们在系统设计上就要做到高并发、高可用，所以，对稳定性要求也是非常高的。因为历史的原因，券商早期在信息系统方面还是依赖于厂商的建设，所以，我们的系统架构并不统一，有各种各样的架构，有基础的组件，这些都没有达到统一。
我们有和厂商开发的、外部供应商还有自研的，还有最新的技术AI的发展，各种框架都会有。应用系统也有很多，有面向终端客户、机构客户、头部等等各种各样的系统，种类会非常多。这对于我们运维来说并不是太好的事情，要求运维的经验和运维的工具平台要相对来说比较成熟。随着近年来客户量不断的提升、扩大，包括业务种类的增多，系统的规模无论是从基础资源的规模，还是到上层的中间件、业务系统，都在急剧的增加。
最后我想强调的是，我们的行业特点是严监管的行业，核心的交易系统一旦发生事故的时候，超过几分钟是要及时向上级监管部门去备案和汇报的，并且达到一定程度就会对公司整体的信用评价、信息技术的评分都有影响的。
我们的客户来说，默认的就是我们提供的系统是高效、时延很低。跟券商同行吃饭的时候聊起，前一段时间某某券商APP慢还上了新闻。从客户还是新闻媒体来说，对于我们这一行的要求都很高。这是券商运维面临的几个挑战。

接下来我想讲讲运维的发展阶段，我分为了四个阶段，这不一定准，这是我自己的划分。
第一个阶段是手工运维，纯人肉，扔到设备上来操作，下发的时候就做配置修改，显而易见是很低效，依赖于运维人员个人的技能和经验。随着系统的增大，运维人员肯定不会一直这样做下去。所以，聪明的运维人员想到，对于重复、高频的操作，可以用一些脚本和小工具辅助我们完成，来提高效率.
就有了第二个阶段：脚本运维。有什么特点呢？当时各个运维的系统、小组和组织架构都有一套自己的小工具帮助他来完成，但是，由于不是专业做平台的，各个系统之间的工具差异化还是比较大的，做好的确实很稳定，功能也比较完善，但其他的就没有那么好了，差异性比较大，整体的数据上，数据打通是不现实的。
随着系统的发展就到了第三个阶段：平台阶段。我们把脚本时代的一些通用点都抽取出来，来搭建公司级的运维平台提供给运维人员使用，这个主要代表着统一监控平台、自动化平台，这个时候是有了质的飞跃，各个系统的差异是能达到摸平，大家都觉得用起来比较顺。但是，很多的操作、很多的判断还是要依赖于一些工作来做。
就进入了第四个阶段：智能运维阶段。这也是随着用户的需求，我们的用户就是运维人员和部分的研发人员。用户需求的增长，监控体系的不断完善，数据量的上升，包括大数据AI平台的建立，我们渐渐尝试用引入智能化的算法解决某些复杂场景下人工都无法判定和察觉的问题。总体上是这四个阶段。对华泰证券的运维来说，也就是从这四个阶段经历过来的。

二、 运维体系介绍

前面简单介绍了券商运维的痛点，下面讲一下华泰证券是怎么思考和解决这些问题的。

在这里还是讲讲这三个平台，最初在平台运维的时代有运维三剑客：监控、自动化和IOTM。这是厂商外购的，存在的问题是：监控平台是什么东西都放进来做，做得也还可以，问题在于每一个层面做得都不细致，颗粒度不够细，我们就做了开闭式，和自动化和ITOM是比较割裂的。
流程管理平台当时真是流程管理平台，比如说申请服务器、发布版本、开通防火墙端口都是在上面处理，处理了也就是处理了，什么都没有留下来，当时我们ABB是空的，面对这样的现状，我们运维人员也确实面临着很大的压力，要想提高效率必须转型。怎么做呢？大体上总结了六个方向：

1.从要求和理念上就要做转变。会推动传统的运维管理向运维分析的转型。运维管理是什么呢？就是给我一个任务，我把它完成，这就够了。平时对系统运行来说，盯着监控和完成保障就可以了。
我们经过一番思考之后，觉得这样是不行的，要推动主动式的运维，无论基础架构、网络、上层的应用，每一个领域都要主动分析系统、运营系统。要做到这个就得了解你的系统，得掌握你的容量，得知道你的性能变化情况，得了解你的客户，所以，我们在组织上要求每个层面的运维人员要做到定时的分析。
2.成立了专门的运维技术开发团队。用专业的人干专业的事，打造了属于公司平台化的运维系统，专门为各个层面的运维人员做服务。
3.我们技术是很弱的，讨论之后基于流程的IT资源管理体系。为什么“基于流程”？CMBB的核心是在于数据的准确性，就在流程性把控，再辅助监控的手段完善存量资源的数据。
4.做到全新的自动化运维平台。来更加丰富我们的场景。除了早年的开闭式，做到巡检、持续部署、持续发布等等的事情。
5.精细化的监控体系。我们希望各个层面都有自己的监控特色，在更高的体系层面上做到了统一。
6.也建立了自己的IT支持团队，来统一的受理和解决客户和公司内部反馈的系统问题。
通过这六个方面的转变是不是就够了？我们还差一个平台。于是，我们就规划了智能运维工作台。

我们的思路也是一样，在构建自己的运维终台，分为三个终台能力场景：监控终台。结合其他监控能力，打造监控平台；用自动化终台解决日常操作部署的问题；运营终台，会做很多标准化流程管控的温控。我们前面说了这么多的标准和规范还要落地，就借助这个智能化的工作台，把我们的理念给落地。

三、层次化监控的建设

前面简单介绍了整体的规划和思路，第三章我想重点讲一下监控方面是怎么完善的。

前面提过了，我们认为监控是要分层分级做的，结合证券行业的特点，从应用运维的角度来说，我们从上之下，把监控分为了五个维度的监控，它就包括了业务层的监控、应用层的监控、中间层和数据库、服务器及操作系统、网络及网络设备的监控。
每一层都看到了它的标准、指标和解决的范围及能力，把指标做到清晰化。做的过程当中，光有指标和标准还不够，还需要解决一个问题，就是关联关系的问题。关联关系在两个层面：
一是网络层。我们要掌握全网网络的状况，这个数据要拿到，并且是方便、准确的非人工的拿到；
二是应用层。我的业务系统和应用是有映射关系的，也许是一对一或者是一对多的关系，应用和服务器是有关联的，把这些数据给弄准了，我对公司整体的系统运营状况才能做到评估和判断。

我们的监控就分为这五个层次。每个层次都有相应的系统或者是产品的落地，在网络层，主要是上了NPM型，就是解决网络丢包、零窗口、实验的监控。基于行业的经验，上了网络质量感知，后面会单独给大家介绍。
在服务器室，我们上了基础资源监控系统，能把所有的服务器性能监控起来；带外监控系统，发现硬件故障；打造云桥管理平台，把共有云和私有云管理起来。
再往上层，ESS有数据管理平台；到上层就更多了，比如说业务监控、性能监控、用户感知，这些和我们的统一监控平台打通，立足于通过统一监控平台来对用户统一服务形成一体化的监控体系。
最后讲讲日志分析系统，这也是我们纯自研的系统。最初做的时候是在应用层，后面发现大家都想用这个系统，我们的中间件、数据库和操作系统、服务器、网络设备、存储，渐渐大家都把日志往我们的系统收集，就用核心的能力提供运行的保障。除了图上画这些还有各种各样的系统，我们的思路是利用于各种监控系统和监控平台的能力，给用户提供一致的监控体验。

几个系统给大家介绍一下。这就是我们的统一监控平台，现在所纳入的对象分为四类：业务系统、中间件、计算资源、网络环境。这所有的监控系统和监控数据都会统一的纳入运维数据中心里面，会在运维数据中心做数据的标准化、数据的统一，然后会利用上层的应用，给运维人员提供场景化的落地。
比如说我们给一线的运维人员提供大屏展示功能，让他知道运行的情况。还提供了日志搜索，让他快速处理遇到的问题等等。对二线运维人员提供的功能更多一些，可以详细看到整体的业务情况，不光看到自己，还有上下游的关系，性能管理、容量管理、故障感觉等等都有相应的模块功能提供。
我简单截取了两张图放在这里，左边是灵活的数据分析仪表盘。通过统一监控平台形成了运维数据中心，我们的用户在平台上可以快速的定制自己想要的监控页面配出来，他关心的指标和上下游的指标都可以快速的展现出来，能帮助他提升日常保障的效率。
另外，把所有的报警汇聚过来，不光是我们的平台产生的报警，而是所有的平台产生报警，做到标准化，从制度上、规范上的要求，大家都要用这个平台做报警的处理，我们也会基于这种报警的数据做分析。

接下来讲一讲日志分析系统，这个是我们完全自研的系统。为什么做这个系统呢？大家面临的问题都是类似，就是日志真是分散到各个服务器，没有做到统一收集。经常有客户说我们的系统出错了，业务人员要登到每台机器上查找。还有监管机构说某某公司的交易流水需要你快速提供给我，我们当时很苦恼。
我们当时调研了很多产品，就搭建了自己的日志分析平台。日志分析最早提供的功能是通过快速把日志标准化，收集之后存到日志库里面，提供了秒级搜索功能、日志报警功能。做着发现，就发现日志做了当初没有想到的事情，比如说加入了运营分析，可以从日志中提取了大量的运营数据来给我们的业务人员和运维人员，让他们实时知道每天的系统运行情况，还做了更细腻的性能监控。
我以前也知道这个系统跑得怎么样，我现在能知道每一个组件运行的情况。有了日志系统之后，很多场景都能快速的落地，也提升了故障应对的能力。还有一个是故障的速率，日志系统不仅仅是监控系统，已经深入到业务系统，我们很多业务的场景，比如说客户每天的交易记录、登陆记录的核对都要日志系统，不仅仅是在监控领域了，已经深入到业务领域，我们和数据中心、柜台都做了打通。
右边的图是大体的分布图，有很多公司都是这么去用的，日志接触是Kafka，Storm是ES，搜索与分析、日志告警。我们日志做了“两地三中心”的活，我们花了比较多的力气做这个工作。首先，我们的业务系统特点是在南京有两个机房，在深圳有备份。由于异地传输宽带的特性，我们不能把所有的数据拿到南京，我们就把每个数据到各自中心，只要是正常运行都能知道情况，但是，有一个中心发现问题的时候没有关系，其他两个中心的数据是连通的，这个是我们特别有效率的事情。

这个是我们大体的规模，采集端超过了3000个；60+的ES存储节点，每日采集1TB日志，也随着用户请求的增多和业务增多，每天都在增大；我们能给用户提供秒级搜索和秒级报警的能力。
做了日志分析系统有什么好处？最直观是监管机构找我们来拿交易流水数据的时候，我们能快速的导入和提供，并且能做比较丰富的数据过滤。另外是定位的问题，更快地发现各个系统关联的情况，也能快速定位到某一台系统的某一台机器情况。
还丰富了业务层的监控，很多系统通过日志抓取再到运维中心里面去，来做更多丰富的展示和使用。最后是运营分析方面有了很大的进步。

这是监控大屏，是截取了一个场景下的大屏，我们实施在大厅都在用的，把我们运维中心的数据做聚合，实时的展现，我们有各种层面的数据。有服务器层、网络层、核心业务层都会展现。
我们的运维人员，特别是一线运维人员，通过大屏可以很直观知道当天公司整体的信息系统运行的情况。这是我们的运维大屏，除了运维之外，还有多种模式，还做了切换的试图，会在自己公司内部组织几次系统切换演练，包括行业也会组织演练，我们的大屏就能实时了解整体公司切换的进度。
还有参观大屏，每年协会、行业来我们公司参观，我们会展示公司的信息技术发展的情况。我们的大屏能在每个季度各个模块有更新迭代的过程，每个月也有新的场景加入。这个大屏也是我们纯自研的。

四、智能运维的案例

最后跟大家分享的是网络质量感知系统。早两年大家做得不多，但是，现在越来越多的人在做这个事情了。原因很简单，就是微软在2015年的时候发表了一篇文章，大家可以搜一下。内容是实时了解网络运行中心的情况。
大家知道运维人员很容易背锅，但是，我觉得运维人员的网络人员最容易背锅，出了什么问题，系统慢就说到是不是 网络变慢了。用APP的时候，“网络慢，请稍等”。
我们的网络人员也有这样的苦恼，别人经常说“网有没有问题”，这是比较难以拿到证据作证这个事情的。网管系统只能监控CPU、内存，网络数据是高还是低，但是CPU低不代表网络感知是好的。所以，我们参照业界经验搭建了自己的平台。
我们和别人有什么不同呢？我总结了以上几点：
一是全网覆盖。这个是很关键，一定要做到全网覆盖，漏了一个点，你的效果就会大打折扣。
二是会做到分层监控。同一个交换机下的Ping探针也是不一样的，同一个数据中心、跨数据中心Ping的监控也是不一样的。
三是自动配置。我们完成了自己的管理体系和CMDB，我们就和CMDB打通。真实的数据中心是在变的，服务器会上下架，网络服务器也会变更。
四是多地部署。
五是智能告警。特别是在网络延时方面，我们做到不同区域之间的智能告警。
左轴的图是各个网段，下面的轴就是目标检测网段。从左边的轴往下面的轴做Ping侧的监控。这是网络质量感知。这是IDC演练的时候，看到所有IDC的网络已经断掉了，这是很直观。另外是单设备故障，你能发现是某一个设备出了问题。
前面讲了在监控领域的一些体系规划之后，我们自研落地的系统，最后想迎合这个场景，就说一下在智能运维的案例和尝试。
智能运维近几年很火，我们也想做，也在尝试，但确实在工业级的成果上没有太大的进展。换个思路讲，我们觉得谈智能化和智能运维，不仅仅是强制谁一个算法或者是上一个AI，在监控的标准化和自动化也是智能的范围之一。我们前面做了很多标准化、自动化的动作，就是为了后面更深层次的做智能化。
简单介绍一下各个场景。在日志方面有了日志分析系统，基于日志数据做异常的检测。业务前面讲到了有很明显的周期性，大家也都看到了。从整体上是有周期性，但是，再细一步的看下去，它也有不一样，是分种类的。有些业务是有周期性，有些业务也不存在周期性。
所以，我们想要了解每个业务的运营状况，还是有一定的挑战。我们用传统的方法做不同指标的日常检测，它的效果也不是很好。所以，我们选择了这个领域突破一下。在业务层面上，同个业务在不同的时间点也有差异，比如说发售新股新债等等，它的指标变化情况也就不一样。

这是异常检测的框架，也很好理解，就是我们会把日志通过数据采集做一些数据的清洗，把信息拿到时序数据库，再到模型调节器，再到模型参数做检测，这个模型是依赖于数据库的信息，包括标签的信息做检测。现在渐渐做到了自动的，有一些场景是自动的调节，之后就是异常的告警。
我们最初还是选择简单的工作，后面发现效果还可以，模型越来越丰富了。做到这个之后有什么好处呢？
我大体上回溯了一下产生的告警中，在生产环境当中发现了一些系统的隐患，比如说发现了某天请求负载突然变大了，我们的系统给抓出来了；某个用户突然对我们的系统进行了大量的高频访问；某一天硬件出问题了，影响了我某一些业务的成功率，这个我们也发现了；包括垃圾和旧的数据下线业务，都通过这个模型抓出来。
同时，结合历史的数据，回溯到2018年的故障事件，对它做了回溯匹配，发现超过60%的故障通过模型是能发现和匹配出来的。
我们做了日志异常的检测，但是，觉得离真正的工业化和期望提高效率的地方还是有一定的距离。

一是告警准确率和召回率，这是很难两全其美的事情。现在也采用了尽可能地让它告出来，准不准后面再说。
二是很难用同一个办法来解决所有的问题，还是要结合场景来选择合适的算法。
三是普世性的问题，解决了日志的异常检测，其他的怎么办？我们也希望和厂商合作，打造公司平台级的异常检测的平台，这还依赖于业界技术的发展。四是不是所有的时序都要智能检测。能用传统的办法解决问题就用传统办法，只有解决不了的时候，尝试用智能解决的办法。

最后讲一下未来发展的方向。我用四个词总结：
1.自动化。这是效率提升的关键，我们正在打造智能化能力的终台，结合城市的发展，把我们的管理、持续发布的能力发展起来；
2.体系化的建设。未来不管是监控层面的体系化，还能做到监控和CMDB之间的交互、监控和内部流程管理、效率管理平台的整体方案推出；
3.运维人员要有专属的工作台，提升他的效率；
4.智能化。我们会在智能化的道路上探索，不光局限于时序检测，还有更多的领域做探索和尝试。

这是我们的建设规划，大家可以看看。2018年介绍了；2019年是运维数据中心、智能算法库和计算平台、业务全景监控、资源效能分析与画像、自动化服务平台。2020年参考，不一定准，比如说：智能故障预测有一些成果、尝试移动化运维，在核心的场景上做到真正的无人值守。